[5 Why 기법은 잘못되었다]

• 존 올스포(John Allspaw)는 '왜?(Why?)'로 시작하는 질문이 한 문제에 관한 하나의 원인만 찾으려 하거나 비난거리를 찾으려는 시도로 이어질 수 있다고 설명했습니다. 그에 따르면 '왜?(Why?)'라는 질문은 기본적으로 '누구(Who)'를 향하도록 되어 있습니다. 

• 질문) "왜 잘못된 방식으로 사용되었나요?"
  답변) "엔지니어가 제대로 사용하는 방법을 몰랐기 때문입니다."

  
  이러한 진행 상황에서 우리가 찾을 수 있는 원인은 다음과 같습니다.

  • 잘못된(혹은 불완전한) 지식을 가진 엔지니어

  • 엔지니어에 대한 교육 부족

  • 신입 엔지니어를 철저히 교육하지 않은 관리자.

• 그렇기 때문에 '왜?(Why)' 질문법의 대상은 종종 비난의 대상이 되곤 합니다. 이 경우 질문을 받은 사람은 자신을 지켜야겠다는 생각에 자연스럽게 방어 본능이 발동하여 문제와는 점점 거리가 멀어지게 됩니다.

• 또한, '왜?(Why?)' 질문 기법은 문제의 원인을 지나치게 단순화시킨다고 지적합니다. '왜?(Why?)'라는 질문은 기본적으로 단 하나의 원인 혹은 단 하나의 조건에 성립하는 원인을 찾도록 유도합니다. 하지만 우리의 실제 현실은 그렇지 않습니다.

[Why 대신 How로 물어라]

• 우리에게 필요한 건 다양한 관점에서 출발한 ‘이야기’입니다. '어떻게'로 시작하는 질문은 보다 서사적인 원인으로 이어질 수 있습니다. 특히, 애자일 코치이자 전문 퍼실리테이터인 아이노 본 코리는 5 Whys가 아닌 5 Hows를 추천합니다.

• 질문1) "특정 서버가 왜 실패했나요?" (X)

  질문2) "새로운 코드를 어떻게 구현했나요?" (O)

  
  

  답변)

  • 코드를 작성할 때 취한 접근 방식.

  • 코드를 배포하기 전에 코드가 예상한 대로 작동할 것이라는 확신을 얻은 방법(테스트, 코드 검토 등)은 무엇인가요?

  • 유사한 코드에 대해 어떤 성공 또는 실패를 경험한 적이 있나요?

  • 새로운 기능을 설계할 때 어떤 절충안을 만들거나 관리했나요?

  • 프로젝트의 범위를 어떻게 판단했는지.

  • 프로젝트에서 시간 압박을 얼마나(그리고 어떤 방식으로) 경험했는지.

https://brunch.co.kr/@p3tree784/105