-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[이은학] 2장: 함께 #11
The head ref may contain hidden characters: "2\uC7A5/\uC774\uC740\uD559"
[이은학] 2장: 함께 #11
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,53 @@ | ||
### 🌱 중요하다고 생각한 내용 | ||
|
||
> 협력을 통한 추상화 | ||
|
||
- 이제까지 전문 프로그래머 연구에서 가장 관심을 받지 못했던 분야는 소프트 스킬(커뮤니케이션/협력 능력 등)이다. | ||
- 실력이 뛰어난 프로그래머는 보통 정도의 실력을 가진 프로그래머에 비해 소프트 스킬이 더 뛰어나다. | ||
- 톱니바퀴 실험에서 추상화된 규칙을 찾아낼 때 혼자 작업한 경우는 14%, 둘이서 함께 작업한 경우 58%로 한 사람의 차이가 엄청난 결과를 만든다. | ||
|
||
> 객관성의 주관성 | ||
|
||
- 설득을 효과적으로 할 수 있는 방법에 대한 질문을 받을 때, "상대방에 대해 얼마나 이해를 하고 계신가요? 얼마나 대화를 해보셨나요?"라는 질문으로 다시 되물어본다. | ||
- 설득에서 중요한 것은 상대방과의 관계이며, 만약 별로 이야기를 못해봤다면 설득에 성공할 확률은 매우 낮다. | ||
- 결국 결정하는 것은 사람이고, 감정을 배재할 수는 없다. | ||
|
||
> 이것도 모르세요? | ||
|
||
- 해당 챕터에서 사수와 부사수의 총 3가지 대화 방식을 소개했습니다. | ||
|
||
1. 관심 없는 대화: 앞으로 질문을 안 할 가능성이 많고, 문제가 커지는 상황에서 혼자 애를 쓰며 결국 팀 전체에 타격을 주는 상황이 올 수 있다. | ||
2. 공감하고 이해하려는 대화: 상대방을 공감하면서 들어주고 어떤 멘탈 모델(개인이 갖고 있는 믿은과 생각)을 갖고 있는지 파악하려고 했다. 질문자가 특정 상황에서 왜 이런 접근을 할 수밖에 없었는지 알기 때문에 더 정확하고 효과적인 제안을 해줄 수 있다. | ||
3. 행동을 유도하는 대화: 질문자는 자기주도적으로 공부하고, 책임감을 갖을 뿐 아니라 관계 역시 더욱 좋아질 것이다. 또한 목표를 달성할 확률과 만족도도 높을 것이다. | ||
|
||
> 하향식 접근의 함정 | ||
|
||
- 개발자가 외친다. "어..? 이거 뭐뭐 안 되는데 아는 사람 있어요?" | ||
- 건너편에 있던 디자이너가 답을 해주다가 옆에 있던 기획자도 "아, 그런 문제가 있었나요?" 하면서 끼어들어 새롭고 가치 있는 정보를 준다. | ||
- 한번에 처리되는 일의 양을 줄여 지속적인 흐름을 만들고, 짧은 시간내에 탑/바텀을 오가게 한다. | ||
- 이 아이디어를 웹개발 쪽에 적용한다면? | ||
- 제시 제임스 개럿의 저서 <사용자 경험의 요소>에서는 웹개발의 추상화의 단계를 다섯 면으로 나눈다. | ||
- 전략, 범위, 구조, 뼈대, 표면/비주얼 | ||
|
||
``` | ||
전략이 깔끔히 완료되고 나서야 범위(어떤 기능이 들어갈지 결정)를 정하고, 구조(기능들을 어떻게 연결할지, 흐름은 어떻게 될지 등)를 정한 후 거기에서 뼈대(화면에 들어갈 요소, 배치)가 나오고, 마지막에 이르러서 비주얼 디자인에 도달할 수 있다. | ||
``` | ||
|
||
하지만 사실은 위의 흐름과 다르다. 어느 한 단계를 한 번에 완료하는 것은 더 낮은 품질로 가는 지름길이고, 더 좋은 결과를 얻기 위해서는 위 단계를 여러번 오르락내리락 반복하는 것이 필요하다. >>> **애자일** | ||
|
||
### 🙋🏻♂️ 경험적인 내용 | ||
|
||
하나의 팀프로젝트를 수행할 때 목표했던 방향대로 진행이 매끄럽지 못했던 경험이 있다. 물론 실력적인 부분도 있겠지만 되돌아보면 팀원들끼리의 소통의 문제가 있었던 것 같다. 2장을 읽으며 서로 공감하고 이해하면서 여러 질문을 통해 뒤늦게 많은 부분을 처리하지 않는 협력이 필요할 것이다. | ||
|
||
최근 기업프로젝트 팀 활동에서 기획 > 디자인 > 백엔드 > 프론트엔드 순서대로 진행이 되었다. 책에서 언급한대로 한 번에 하나의 파트가 모두 끝날 수는 없지만 프로젝트 기간이 상대적으로 짧은 시간이었기에 프론트엔드 파트를 맡았던 나는 후반부에 엄청나게 힘든 경험을 했다. 백엔드 파트는 디자인이 꼭 나오지 않아도 시작할 수 있었는데, 아무래도 웹페이지 UI가 어느정도 완성이 되어야 시작할 수 있었다. | ||
|
||
✅ 프론트엔드 개발자는 팀프로젝트 진행 초기에 어떤 것을 중점으로 시작하면 좋을까? 아직 경험이 많지 않아서 스터디원들의 여러 조언이 필요합니다! | ||
Comment on lines
+42
to
+44
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 말씀하신 것에 공감되며, 많은 개발자들 그리고 조직이 공감하고 해결하려는 문제 중 하나라고 생각해요 이를 일부해소 하기 위한 msw 같은 도구들도 있으니, 계속해서 더 잘(효과적으로) 일할 수 있는 방법을 고민해보시면 좋을 거 같아용 👍 |
||
|
||
- 기획, 디자인 회의에 참여하며 현실적인 개발 가능성을 고려하기. | ||
- 프로젝트 세팅 및 협동 규칙 정하기. | ||
- 사실 해야할 일은 아주 많을 거에요 😂 | ||
|
||
### 🔎 논의하고 싶은 내용 | ||
|
||
- 다함께 협력을 해야하는 상황에서 각자 스타일이 다르고 시공간적인 문제가 발생한다면 어떻게 가장 효율적으로 진행할 수 있을까? | ||
- 프로젝트 진행 초기에 파트 팀원들과 모든 규칙을 정해야할까? | ||
Comment on lines
+52
to
+53
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 은학님은 어떻게 생각하시는지 궁금해용 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 저는 정할 수 있는 규칙은 최대한 정하고 가는 게 프로젝트을 원활하게 진행할 수 있다고 생각합니다! 하지만 진행하면서 당연히 수정해나가야한다고 생각해요 :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
결국 사람이 중요한거죠