아티클 카타) 존경받는 리더들이 가지고 있는 커뮤니케이션 패턴 8가지+오늘의 피드백

• 출처 : https://yozm.wishket.com/magazine/detail/152/

존경받는 리더들이 가지고 있는 커뮤니케이션 패턴 8가지 | 요즘IT

 

 

인사이트(양식 참고)

 

◾이 아티클의 주요 메시지

• 좋은 커뮤니케이션은 단순히 적절한 단어를 선택하는 것이 아니라, 상대를 이해하고 적극적으로 경청하며 공감하는 데서 시작한다. 또한 대화를 주도하는 능력과 적절한 바디랭귀지, 높은 직관력도 중요하다.

◾핵심 키워드

• 커뮤니케이션, 이해, 공감, 경청, 주도적 대화, 바디랭귀지, 직관력, 설득

◾흥미로운 점 / 새롭게 알게 된 점

• 읽으면서 가장 흥미로웠던 부분
  1. 상대를 납득시키기 위해서는 ‘왜?’에 대한 설명부터 시작해야 한다.
     → 결정 사항만 전달하는 것이 아니라, 배경과 맥락을 먼저 설명해야 한다.
  2. 취약한 부분을 먼저 공유하면 상대의 공감과 신뢰를 얻기 쉽다.
     → 어려움을 겪고 있는 지점을 솔직하게 드러낼수록 공감과 신뢰가 높아질 수 있다.
  3. 요청할 때는 NVC를 활용한다.
     → 관찰(Observation) → 감정(Feeling) → 욕구/필요(Need) → 요청(Request)
  4. 요점 설명은 40 단어 규칙을 준수한다.
     → 장황하게 설명하기보다 핵심을 짧고 명확하게 전달하는 것이 중요하다.
  5. 이야기 형식으로 전달하면 더 많은 관심을 끌 수 있다.
     → 스토리를 활용하면 공감과 몰입도를 높일 수 있다.
  6. 허락을 구하며 상황을 통제한다.
     → 상대를 존중하는 태도를 보이면서도 대화의 흐름을 주도할 수 있다.
     ex. 잠시 논점에서 벗어난 이야기를 해도 괜찮을까요?
  7. 코칭은 질문에서 시작된다.
     → 질문을 통해 팀원이 직접 사고하고 문제를 해결하도록 돕는다.
  8. 경청에 집중하고 마지막에 이야기한다.
     → 상대의 이야기를 충분히 들을수록 내 의견도 더 잘 전달될 수 있다.
• 이전에는 알지 못했거나 새롭게 배운 내용
  • 요청 시 NVC 활용에 대해 배웠다. 관찰과 니즈, 그리고 요청은 기존에도 해왔지만 감정을 함께 전달하지는 않았다.
    '내 감정을 굳이 궁금해할까?'라는 생각 때문이었는데, 추후에는 의식적으로 반영해 볼 생각이다.
  • 경제적 대화가 필요하다는 점도 새로웠다. 확실히 본론만 빠르게 이야기하는 방식을 선호하는데, 이를 '경제적 대화'라고 정의한 것이 신선하게 느껴졌다.
  • 강사로 활동할 당시 상대의 이해 수준을 확인하기 위해 질문을 하고 답변을 받는 방식으로 수업을 진행했었다.
    (원래 궁금한 걸 잘 못 참아서 '물음표 살인마'라는 이야기도 들었다(농담))
    그게 습관이 됐는데, 팀원이 직접 사고하고 문제 해결 능력을 갖출 수 있도록 돕는 효과까지 있다는 점은 새롭게 알게 됐다.

◾나의 한 문장 요약

• 상대를 납득시키기 위해서는 결정의 배경과 맥락을 먼저 설명한 뒤 핵심을 짧고 명확하게 전달해야 하며, 질문을 통해 팀원이 직접 사고하고 문제를 해결할 수 있도록 돕는 것이 중요하다.

 

---

 

오늘의 피드백
-
팀 공통 피드백이라 게시글 내용과 다를 수 있음

 

• 지표 관련 추천 아티클 : 서비스를 "진짜로" 성장시키는 지표 찾기
  → 서비스를 성장시키는 지표(북극성 지표)
• 화면설계서/기능명세서 관련 : 화면설계서 (Wireframe)와 기능명세서 (Functional Specification)
  • PRD 안에 기능명세서를 포함하는 경우도 있음
    → 세부 정보가 필요한 경우
    → PRD가 큰 개념이라면 기능명세서는 그 안의 세부 개념
• 유저 플로우에서 입력값(데이터 형태)이 API를 통해 어떻게 전달되는지 정도는 알아야 기획 시 도움이 됨
  → 개발자와 라포를 쌓으며 질문하기
  → 기본적인 워크플로우는 이해할 것
  → 복잡한 기술의 경우, 무엇을 참고하면 되는지 먼저 여쭤볼 것
• 사용자는 상황에 따라 다르게 정의될 수 있음
  → 번개장터의 경우 기능별·카테고리별로 타깃 사용자가 달랐음
  → 항공권 서비스처럼 이용 시간대까지 고려하는 경우도 있음
• 신입 PM은 보통 무엇부터 시작하는가?
  → 약 3개월 수습 기간 동안 프로덕트 이해도와 업무 역량 확인
  → 전체 QA 진행(오류 발견 및 프로덕트 이해도 확인)
  → PT 등을 통한 이해도 점검
  → 메인 화면은 영향 범위가 크므로, 초기에는 백오피스나 오래된 숙원 기능 개선 업무를 맡는 경우가 많음 → 상대적으로 영향도가 낮은 화면부터 작게 기획하며 점진적으로 역량을 키워감