사용자 불만에 대한 5-whys 근본 원인 분석 돌리기(Run a 5-whys root cause analysis on a user complaint)

Five Whys는 가장 저렴한 근본 원인 도구

증상을 패치하는 팀은 깨지기 쉬운 수정을 쌓고, 구조적 원인을 추적하는 팀은 불만율을 줄입니다. 5-whys 방법 — 제조업에서 시작해 소프트웨어에 널리 채택됨 — 은 거의 0 비용 근본 원인 도구입니다. Google re:Work의 문제 해결 가이드와 Atlassian의 사후 인시던트 실천 모두 각 단계가 추측이 아니라 증거로 뒷받침될 때의 신뢰성을 문서화합니다.

Run a 5-whys root cause analysis on a user complaint 프롬프트의 작동 방식

프롬프트는 모든 단계에 증거를 강제해 사슬이 추측으로 빠지지 않게 하고, 근본 원인을 5개 구조적 카테고리로 분류하며, 이슈를 더 일찍 잡았을 조기 경고 지표를 명명합니다. 구조적 vs. 증상 트레이드오프 매트릭스는 구조적 수정에 한 분기가 걸릴 때 실용적 단기 패치를 정당화합니다.

언제 사용할까

• 단일 고객 불만이 큰 소리이고 패턴 가능성이 있을 때.
• 사후 인시던트 리뷰가 인시던트 특정 수정이 아니라 구조적 원인이 필요할 때.
• 한 카테고리의 버그가 계속 재발하고 누구도 패턴을 추적하지 않았을 때.
• 새 PM이 팀을 증상 패치에서 근본 원인 수정으로 옮기고 싶을 때.
• CEO나 이사회가 "어떻게 이게 일어났는가"를 묻고 있을 때.

흔한 함정

• 증거 없이 추측. 모든 "왜" 답은 뒷받침 데이터가 필요합니다. 없으면 사슬이 자신감 있는 픽션을 만들어냅니다.
• "사람의 실수"에서 멈추기. 개인 실수는 보통 증상입니다. 계속 왜를 물으세요.
• 경고 지표 없음. 모니터링 가능한 선행 지표 없는 근본 원인은 반복할 수 없는 교훈입니다.

참고 자료

• Google re:Work — Google
• Agile Metrics — Atlassian
• Begin with Trust — Harvard Business Review
• Sprint Retrospectives — Atlassian