[ ] 소통은 원래 어렵고 실수하기 쉬운 부분이다

• 진지하게 고민하되 부담을 느끼지는 말것
• 말을 할때는 그말이 침묵 보다 나은 것이야 한다
• 일을 잘하는 방법중 한가지는 최고의 결과를 내는 방법과 지극히 현실적인 것 사이에서 타협하는 것이다

[ ] 소통의 목적

• 회사 생활이나 실무상의 리스크를 조기에 발견하거나 발생한 이슈의 해결
• 본인이나 상대방이 한 일에 대한 확인

[ ] 좋은 소통이란

• 빠른 회신

  → 기다리는 동안 일이 진행 안되는 경우가 많다.

• 정확한 의사 표현

  → 불명확한 표현이나 단어 사용은 오해를 불러 일으킬 소지가 크다.

• 필요한 경우 중간 보고

  → 한번에 많은 것을 한번에 소통하는 것은 서로 힘들어 진다.

  → 수정이 필요할 경우 진행된 일이 무위로 돌아갈 수가 있다.

• 혼자 판단 내리지 않기 → 자신이 보기에는 큰일이 아닌 것 같지만 그 판단은 상대방이 해야 하는 경우가 생각보다 많다.

• 스스로 한계를 명확하게 인지하기

  → YES맨이 되어서는 안된다.

• 요청 사항이나 확인이 필요한 부분을 공유 받았을 경우 내용을 확인 했다는 회신은 필수

  → 보낸 사람이 확인 사실을 인지하는 것은 중요한 부분이다.

• 질문에 대한 답변

  → 질문의 의도를 파악하는 것이 중요하다. (Insight가 필요)

  → 질문의 핵심에 대해 우선 답변하고 부가 설명하는 것이 좋다.

[ ] 질문하는 방법

• 회사는 학원이 아니다.
• 하고자 하는 것을 먼저 정의해라
• 자신이 시도해 본 것들을 말하고 어떤 결과 또는 오류가 일어났는지 알려라
• 새로 배운 부분은 항상 기록으로 남겨라

[ ] 소통방향

• F ↔ B,D,C
• D ↔ F,C
• B ↔ F,C

[ ] 서비스 개발 과정에서의 소통

1. 디자인 ↔ 개발

   1. 기본적으로 디자인에서 온 내용 그대로를 반영한다는 전제로 개발을 진행한다.

   2. 디자인 사항에 대해 구현 가능 여부는 개발자에게 꼭 확인을 받도록 한다.

   3. 개발자들은 디자인 된 사항의 구현 가능 여부에 대해 회신을 줘야 하고 불가능하거나 구현에 시간이 필요한 경우 대안을 제시할 수 있도록 한다.

      특히 안된다와 못한다는 구분해서 표현해라.

   4. 상대방을 배려한다고 피드백을 소홀히 해서는 안된다.

   5. 주어진 피드백에 대해서는 진지하게 받아 들여야 한다.

2. 업체 ↔ 기획, 개발, 디자인 : UI나 기능에 대한 변경 요구
   1. 변경 된 요구사항에 대해서는 꼭!! 따로 정리가 필요하다.
   2. 개발자나 기획을 통해 변경 사항이 들어온 경우 그 사항에 대해 디자이너와 소통 후 개발에 반영하도록 한다.
   3. 변경 및 추가 요구 사항에 대해 개발자가 임의로 디자인을 변경해서는 안된다.
   4. 지급 사항일 경우 선 개발 반영 후 꼭 추후에 기획이나 디자이너에게 전달을 해야 한다.