'사람 얘기 듣기'를 엔지니어링으로 치환하지 마라

• 저자가 소프트웨어 업계에서 반복해서 목격하는 패턴 — 문제의 뿌리는 두 가지
  • 사람들이 서로 얘기를 안 함
  • 얘기해도 듣지를 않음
• 디자이너·프로덕트 쪽에서 첫 번째 문제에 접근할 때 꺼내는 해법이 주로 "프레임워크", "시스템", 요즘 유행하는 "사회기술 시스템(socio-technical system)" 같은 용어들
  • 저자 왈 — 엔지니어가 친숙해할 단어로 포장해서 "사람 얘기 듣기"를 회피하는 짓
  • "더 나은 시스템이 필요한 게 아니라, 그냥 일을 안 하고 있는 것"

듣는다는 걸 오해하는 방식들

• 듣기 ≠ 요구한 걸 그대로 만들어주기
  • JTBD(Jobs To Be Done), Outcome Driven Innovation, UX 쪽의 공감 지도(empathy mapping) 등이 이 부분은 이미 충분히 다룸
• 전문 분야 편향 — "이건 당연히 알겠지?" 함정
  • 상대가 해당 영역 전문가라도 내가 아는 그 지점은 모를 수 있음
  • 상대가 "뭘 아는지"를 먼저 파악해야 제대로 들을 수 있음
• "기술적"이라는 단어를 하나로 취급하기
  • 소프트웨어 개발자들이 유난히 빠지는 함정
  • 기술은 광범위한 지식 영역의 스펙트럼이지 "내가 했던 개발자 경험"이 곧 "기술적"인 게 아님
  • 사람을 "기술자 vs 비기술자" 이분법으로 보는 순간 놓치는 인사이트가 생김
• 모두가 나랑 같은 자원을 갖고 있다고 가정
  • 같은 건강 상태라도 관리 방식·가용 에너지가 다름
  • 경제적 여유에 따른 리스크 선호도 차이
• 한 명의 특성으로 전체를 일반화
  • "나이 든 사람은 컴퓨터 잘 모른다" 같은 편견
  • "모든 여성이 네 엄마나 딸은 아니다"
• 사람(조직)이 정적이라는 가정
  • 거시적으로는 성격 자체가 시간에 따라 바뀜
  • 미시적으로는 회사에서의 페르소나와 집에서의 모습이 다름, 스트레스 상황에서 판단이 달라짐
  • 이게 바로 "고정형 프로젝트 관리가 소프트웨어 개발에서 안 통하는 근본 이유" — 요구사항 박아놓는 동안 사람이 변하고, 기대치가 누적되면서 결과물과 현실이 벌어짐
• 말한 것 = 생각한 것이라는 가정
  • 대다수는 자기가 의도대로 말한다고 믿지만 실제론 그렇지 않음
• 사람을 판단하기
  • 문서를 엉망으로 써놓고 이해 못 한 사람을 탓하는 버릇
  • 누군가를 무시하는 순간 제대로 듣는 건 사실상 불가능
• 80명을 "개인 1명 × 80"으로 취급
  • 오히려 B2B가 B2C보다 더 인간적임 — 지저분한 관계, 조직도와 실제 영향력의 괴리, 집단 역학이 추가로 얹힘

안 듣는 걸 방치하면

• 가장 돈 되는 인사이트를 놓치고, 경쟁사에 추월당함
• 의외로 기술 부채의 원천이 되기도 함 — 오해 하나가 코드에 새 로직을 추가시키고, 그게 나중에 짐이 됨
• 저자의 결론: "언제 우리가 안 듣고 있는지 알아차리는 단서 정도는 될 것" — 더 잘 듣자는 자기반성 글