Skip to content

Commit

Permalink
2장 이은학 (#11)
Browse files Browse the repository at this point in the history
  • Loading branch information
2unhi authored Oct 1, 2024
1 parent 5a643f0 commit f41396e
Showing 1 changed file with 53 additions and 0 deletions.
53 changes: 53 additions & 0 deletions 2장/이은학.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,53 @@
### 🌱 중요하다고 생각한 내용

> 협력을 통한 추상화
- 이제까지 전문 프로그래머 연구에서 가장 관심을 받지 못했던 분야는 소프트 스킬(커뮤니케이션/협력 능력 등)이다.
- 실력이 뛰어난 프로그래머는 보통 정도의 실력을 가진 프로그래머에 비해 소프트 스킬이 더 뛰어나다.
- 톱니바퀴 실험에서 추상화된 규칙을 찾아낼 때 혼자 작업한 경우는 14%, 둘이서 함께 작업한 경우 58%로 한 사람의 차이가 엄청난 결과를 만든다.

> 객관성의 주관성
- 설득을 효과적으로 할 수 있는 방법에 대한 질문을 받을 때, "상대방에 대해 얼마나 이해를 하고 계신가요? 얼마나 대화를 해보셨나요?"라는 질문으로 다시 되물어본다.
- 설득에서 중요한 것은 상대방과의 관계이며, 만약 별로 이야기를 못해봤다면 설득에 성공할 확률은 매우 낮다.
- 결국 결정하는 것은 사람이고, 감정을 배재할 수는 없다.

> 이것도 모르세요?
- 해당 챕터에서 사수와 부사수의 총 3가지 대화 방식을 소개했습니다.

1. 관심 없는 대화: 앞으로 질문을 안 할 가능성이 많고, 문제가 커지는 상황에서 혼자 애를 쓰며 결국 팀 전체에 타격을 주는 상황이 올 수 있다.
2. 공감하고 이해하려는 대화: 상대방을 공감하면서 들어주고 어떤 멘탈 모델(개인이 갖고 있는 믿은과 생각)을 갖고 있는지 파악하려고 했다. 질문자가 특정 상황에서 왜 이런 접근을 할 수밖에 없었는지 알기 때문에 더 정확하고 효과적인 제안을 해줄 수 있다.
3. 행동을 유도하는 대화: 질문자는 자기주도적으로 공부하고, 책임감을 갖을 뿐 아니라 관계 역시 더욱 좋아질 것이다. 또한 목표를 달성할 확률과 만족도도 높을 것이다.

> 하향식 접근의 함정
- 개발자가 외친다. "어..? 이거 뭐뭐 안 되는데 아는 사람 있어요?"
- 건너편에 있던 디자이너가 답을 해주다가 옆에 있던 기획자도 "아, 그런 문제가 있었나요?" 하면서 끼어들어 새롭고 가치 있는 정보를 준다.
- 한번에 처리되는 일의 양을 줄여 지속적인 흐름을 만들고, 짧은 시간내에 탑/바텀을 오가게 한다.
- 이 아이디어를 웹개발 쪽에 적용한다면?
- 제시 제임스 개럿의 저서 <사용자 경험의 요소>에서는 웹개발의 추상화의 단계를 다섯 면으로 나눈다.
- 전략, 범위, 구조, 뼈대, 표면/비주얼

```
전략이 깔끔히 완료되고 나서야 범위(어떤 기능이 들어갈지 결정)를 정하고, 구조(기능들을 어떻게 연결할지, 흐름은 어떻게 될지 등)를 정한 후 거기에서 뼈대(화면에 들어갈 요소, 배치)가 나오고, 마지막에 이르러서 비주얼 디자인에 도달할 수 있다.
```

하지만 사실은 위의 흐름과 다르다. 어느 한 단계를 한 번에 완료하는 것은 더 낮은 품질로 가는 지름길이고, 더 좋은 결과를 얻기 위해서는 위 단계를 여러번 오르락내리락 반복하는 것이 필요하다. >>> **애자일**

### 🙋🏻‍♂️ 경험적인 내용

하나의 팀프로젝트를 수행할 때 목표했던 방향대로 진행이 매끄럽지 못했던 경험이 있다. 물론 실력적인 부분도 있겠지만 되돌아보면 팀원들끼리의 소통의 문제가 있었던 것 같다. 2장을 읽으며 서로 공감하고 이해하면서 여러 질문을 통해 뒤늦게 많은 부분을 처리하지 않는 협력이 필요할 것이다.

최근 기업프로젝트 팀 활동에서 기획 > 디자인 > 백엔드 > 프론트엔드 순서대로 진행이 되었다. 책에서 언급한대로 한 번에 하나의 파트가 모두 끝날 수는 없지만 프로젝트 기간이 상대적으로 짧은 시간이었기에 프론트엔드 파트를 맡았던 나는 후반부에 엄청나게 힘든 경험을 했다. 백엔드 파트는 디자인이 꼭 나오지 않아도 시작할 수 있었는데, 아무래도 웹페이지 UI가 어느정도 완성이 되어야 시작할 수 있었다.

✅ 프론트엔드 개발자는 팀프로젝트 진행 초기에 어떤 것을 중점으로 시작하면 좋을까? 아직 경험이 많지 않아서 스터디원들의 여러 조언이 필요합니다!

- 기획, 디자인 회의에 참여하며 현실적인 개발 가능성을 고려하기.
- 프로젝트 세팅 및 협동 규칙 정하기.
- 사실 해야할 일은 아주 많을 거에요 😂

### 🔎 논의하고 싶은 내용

- 다함께 협력을 해야하는 상황에서 각자 스타일이 다르고 시공간적인 문제가 발생한다면 어떻게 가장 효율적으로 진행할 수 있을까?
- 프로젝트 진행 초기에 파트 팀원들과 모든 규칙을 정해야할까?

0 comments on commit f41396e

Please sign in to comment.