generated from muhandojeon/study-template
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
53 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,53 @@ | ||
### 🌱 중요하다고 생각한 내용 | ||
|
||
> 협력을 통한 추상화 | ||
- 이제까지 전문 프로그래머 연구에서 가장 관심을 받지 못했던 분야는 소프트 스킬(커뮤니케이션/협력 능력 등)이다. | ||
- 실력이 뛰어난 프로그래머는 보통 정도의 실력을 가진 프로그래머에 비해 소프트 스킬이 더 뛰어나다. | ||
- 톱니바퀴 실험에서 추상화된 규칙을 찾아낼 때 혼자 작업한 경우는 14%, 둘이서 함께 작업한 경우 58%로 한 사람의 차이가 엄청난 결과를 만든다. | ||
|
||
> 객관성의 주관성 | ||
- 설득을 효과적으로 할 수 있는 방법에 대한 질문을 받을 때, "상대방에 대해 얼마나 이해를 하고 계신가요? 얼마나 대화를 해보셨나요?"라는 질문으로 다시 되물어본다. | ||
- 설득에서 중요한 것은 상대방과의 관계이며, 만약 별로 이야기를 못해봤다면 설득에 성공할 확률은 매우 낮다. | ||
- 결국 결정하는 것은 사람이고, 감정을 배재할 수는 없다. | ||
|
||
> 이것도 모르세요? | ||
- 해당 챕터에서 사수와 부사수의 총 3가지 대화 방식을 소개했습니다. | ||
|
||
1. 관심 없는 대화: 앞으로 질문을 안 할 가능성이 많고, 문제가 커지는 상황에서 혼자 애를 쓰며 결국 팀 전체에 타격을 주는 상황이 올 수 있다. | ||
2. 공감하고 이해하려는 대화: 상대방을 공감하면서 들어주고 어떤 멘탈 모델(개인이 갖고 있는 믿은과 생각)을 갖고 있는지 파악하려고 했다. 질문자가 특정 상황에서 왜 이런 접근을 할 수밖에 없었는지 알기 때문에 더 정확하고 효과적인 제안을 해줄 수 있다. | ||
3. 행동을 유도하는 대화: 질문자는 자기주도적으로 공부하고, 책임감을 갖을 뿐 아니라 관계 역시 더욱 좋아질 것이다. 또한 목표를 달성할 확률과 만족도도 높을 것이다. | ||
|
||
> 하향식 접근의 함정 | ||
- 개발자가 외친다. "어..? 이거 뭐뭐 안 되는데 아는 사람 있어요?" | ||
- 건너편에 있던 디자이너가 답을 해주다가 옆에 있던 기획자도 "아, 그런 문제가 있었나요?" 하면서 끼어들어 새롭고 가치 있는 정보를 준다. | ||
- 한번에 처리되는 일의 양을 줄여 지속적인 흐름을 만들고, 짧은 시간내에 탑/바텀을 오가게 한다. | ||
- 이 아이디어를 웹개발 쪽에 적용한다면? | ||
- 제시 제임스 개럿의 저서 <사용자 경험의 요소>에서는 웹개발의 추상화의 단계를 다섯 면으로 나눈다. | ||
- 전략, 범위, 구조, 뼈대, 표면/비주얼 | ||
|
||
``` | ||
전략이 깔끔히 완료되고 나서야 범위(어떤 기능이 들어갈지 결정)를 정하고, 구조(기능들을 어떻게 연결할지, 흐름은 어떻게 될지 등)를 정한 후 거기에서 뼈대(화면에 들어갈 요소, 배치)가 나오고, 마지막에 이르러서 비주얼 디자인에 도달할 수 있다. | ||
``` | ||
|
||
하지만 사실은 위의 흐름과 다르다. 어느 한 단계를 한 번에 완료하는 것은 더 낮은 품질로 가는 지름길이고, 더 좋은 결과를 얻기 위해서는 위 단계를 여러번 오르락내리락 반복하는 것이 필요하다. >>> **애자일** | ||
|
||
### 🙋🏻♂️ 경험적인 내용 | ||
|
||
하나의 팀프로젝트를 수행할 때 목표했던 방향대로 진행이 매끄럽지 못했던 경험이 있다. 물론 실력적인 부분도 있겠지만 되돌아보면 팀원들끼리의 소통의 문제가 있었던 것 같다. 2장을 읽으며 서로 공감하고 이해하면서 여러 질문을 통해 뒤늦게 많은 부분을 처리하지 않는 협력이 필요할 것이다. | ||
|
||
최근 기업프로젝트 팀 활동에서 기획 > 디자인 > 백엔드 > 프론트엔드 순서대로 진행이 되었다. 책에서 언급한대로 한 번에 하나의 파트가 모두 끝날 수는 없지만 프로젝트 기간이 상대적으로 짧은 시간이었기에 프론트엔드 파트를 맡았던 나는 후반부에 엄청나게 힘든 경험을 했다. 백엔드 파트는 디자인이 꼭 나오지 않아도 시작할 수 있었는데, 아무래도 웹페이지 UI가 어느정도 완성이 되어야 시작할 수 있었다. | ||
|
||
✅ 프론트엔드 개발자는 팀프로젝트 진행 초기에 어떤 것을 중점으로 시작하면 좋을까? 아직 경험이 많지 않아서 스터디원들의 여러 조언이 필요합니다! | ||
|
||
- 기획, 디자인 회의에 참여하며 현실적인 개발 가능성을 고려하기. | ||
- 프로젝트 세팅 및 협동 규칙 정하기. | ||
- 사실 해야할 일은 아주 많을 거에요 😂 | ||
|
||
### 🔎 논의하고 싶은 내용 | ||
|
||
- 다함께 협력을 해야하는 상황에서 각자 스타일이 다르고 시공간적인 문제가 발생한다면 어떻게 가장 효율적으로 진행할 수 있을까? | ||
- 프로젝트 진행 초기에 파트 팀원들과 모든 규칙을 정해야할까? |