From 8fdc6d3d84f8fc020e3294b114a240a30555db4a Mon Sep 17 00:00:00 2001
From: 2unhi <ironhak1106@gmail.com>
Date: Thu, 19 Sep 2024 13:50:40 +0900
Subject: [PATCH] =?UTF-8?q?2=EC=9E=A5=20=EC=9D=B4=EC=9D=80=ED=95=99?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 .../\354\235\264\354\235\200\355\225\231.md"  | 53 +++++++++++++++++++
 1 file changed, 53 insertions(+)
 create mode 100644 "2\354\236\245/\354\235\264\354\235\200\355\225\231.md"

diff --git "a/2\354\236\245/\354\235\264\354\235\200\355\225\231.md" "b/2\354\236\245/\354\235\264\354\235\200\355\225\231.md"
new file mode 100644
index 0000000..f52bff4
--- /dev/null
+++ "b/2\354\236\245/\354\235\264\354\235\200\355\225\231.md"
@@ -0,0 +1,53 @@
+### 🌱 중요하다고 생각한 내용
+
+> 협력을 통한 추상화
+
+- 이제까지 전문 프로그래머 연구에서 가장 관심을 받지 못했던 분야는 소프트 스킬(커뮤니케이션/협력 능력 등)이다.
+- 실력이 뛰어난 프로그래머는 보통 정도의 실력을 가진 프로그래머에 비해 소프트 스킬이 더 뛰어나다.
+- 톱니바퀴 실험에서 추상화된 규칙을 찾아낼 때 혼자 작업한 경우는 14%, 둘이서 함께 작업한 경우 58%로 한 사람의 차이가 엄청난 결과를 만든다.
+
+> 객관성의 주관성
+
+- 설득을 효과적으로 할 수 있는 방법에 대한 질문을 받을 때, "상대방에 대해 얼마나 이해를 하고 계신가요? 얼마나 대화를 해보셨나요?"라는 질문으로 다시 되물어본다.
+- 설득에서 중요한 것은 상대방과의 관계이며, 만약 별로 이야기를 못해봤다면 설득에 성공할 확률은 매우 낮다.
+- 결국 결정하는 것은 사람이고, 감정을 배재할 수는 없다.
+
+> 이것도 모르세요?
+
+- 해당 챕터에서 사수와 부사수의 총 3가지 대화 방식을 소개했습니다.
+
+1. 관심 없는 대화: 앞으로 질문을 안 할 가능성이 많고, 문제가 커지는 상황에서 혼자 애를 쓰며 결국 팀 전체에 타격을 주는 상황이 올 수 있다.
+2. 공감하고 이해하려는 대화: 상대방을 공감하면서 들어주고 어떤 멘탈 모델(개인이 갖고 있는 믿은과 생각)을 갖고 있는지 파악하려고 했다. 질문자가 특정 상황에서 왜 이런 접근을 할 수밖에 없었는지 알기 때문에 더 정확하고 효과적인 제안을 해줄 수 있다.
+3. 행동을 유도하는 대화: 질문자는 자기주도적으로 공부하고, 책임감을 갖을 뿐 아니라 관계 역시 더욱 좋아질 것이다. 또한 목표를 달성할 확률과 만족도도 높을 것이다.
+
+> 하향식 접근의 함정
+
+- 개발자가 외친다. "어..? 이거 뭐뭐 안 되는데 아는 사람 있어요?"
+- 건너편에 있던 디자이너가 답을 해주다가 옆에 있던 기획자도 "아, 그런 문제가 있었나요?" 하면서 끼어들어 새롭고 가치 있는 정보를 준다.
+- 한번에 처리되는 일의 양을 줄여 지속적인 흐름을 만들고, 짧은 시간내에 탑/바텀을 오가게 한다.
+  - 이 아이디어를 웹개발 쪽에 적용한다면?
+  - 제시 제임스 개럿의 저서 <사용자 경험의 요소>에서는 웹개발의 추상화의 단계를 다섯 면으로 나눈다.
+    - 전략, 범위, 구조, 뼈대, 표면/비주얼
+
+```
+전략이 깔끔히 완료되고 나서야 범위(어떤 기능이 들어갈지 결정)를 정하고, 구조(기능들을 어떻게 연결할지, 흐름은 어떻게 될지 등)를 정한 후 거기에서 뼈대(화면에 들어갈 요소, 배치)가 나오고, 마지막에 이르러서 비주얼 디자인에 도달할 수 있다.
+```
+
+하지만 사실은 위의 흐름과 다르다. 어느 한 단계를 한 번에 완료하는 것은 더 낮은 품질로 가는 지름길이고, 더 좋은 결과를 얻기 위해서는 위 단계를 여러번 오르락내리락 반복하는 것이 필요하다. >>> **애자일**
+
+### 🙋🏻‍♂️ 경험적인 내용
+
+하나의 팀프로젝트를 수행할 때 목표했던 방향대로 진행이 매끄럽지 못했던 경험이 있다. 물론 실력적인 부분도 있겠지만 되돌아보면 팀원들끼리의 소통의 문제가 있었던 것 같다. 2장을 읽으며 서로 공감하고 이해하면서 여러 질문을 통해 뒤늦게 많은 부분을 처리하지 않는 협력이 필요할 것이다.
+
+최근 기업프로젝트 팀 활동에서 기획 > 디자인 > 백엔드 > 프론트엔드 순서대로 진행이 되었다. 책에서 언급한대로 한 번에 하나의 파트가 모두 끝날 수는 없지만 프로젝트 기간이 상대적으로 짧은 시간이었기에 프론트엔드 파트를 맡았던 나는 후반부에 엄청나게 힘든 경험을 했다. 백엔드 파트는 디자인이 꼭 나오지 않아도 시작할 수 있었는데, 아무래도 웹페이지 UI가 어느정도 완성이 되어야 시작할 수 있었다.
+
+✅ 프론트엔드 개발자는 팀프로젝트 진행 초기에 어떤 것을 중점으로 시작하면 좋을까? 아직 경험이 많지 않아서 스터디원들의 여러 조언이 필요합니다!
+
+- 기획, 디자인 회의에 참여하며 현실적인 개발 가능성을 고려하기.
+- 프로젝트 세팅 및 협동 규칙 정하기.
+- 사실 해야할 일은 아주 많을 거에요 😂
+
+### 🔎 논의하고 싶은 내용
+
+- 다함께 협력을 해야하는 상황에서 각자 스타일이 다르고 시공간적인 문제가 발생한다면 어떻게 가장 효율적으로 진행할 수 있을까?
+- 프로젝트 진행 초기에 파트 팀원들과 모든 규칙을 정해야할까?