'Why' 대신 'How'로 물어라.
[질문을 잘하는 몇 가지 팁: '왜'로 시작하는 질문은 하지 않는다]
어리둥절할 수도 있다. (...) 하지만 '왜'로 시작하면 아이러니하게도 답하기가 더 어려워진다. 보통 "그 이야기가 당신한테 왜 중요한가요?"라고 물으면 순간적으로 말문이 막힌다. 우리의 뇌에서 언어를 책임지는 부분이 아닌, 생각을 담당하는 부분이 바쁘게 움직이기 때문이다.
- 사이먼 사이넥, <나는 왜 이 일을 하는가 2>
여기서 "왜 그 방법이 통하지 않았다고 생각하니?"나 "왜 그렇게 해야 한다고 생각하니?" 같은 질문들은 중요치 않다. 이러한 질문들은 당신과 그 팀원을 헷갈리게 할 뿐이다. 그 대신 "어떤 결과가 도출되기를 바라니?"나 "지금 당장 취할 수 있는 조치가 무엇이니?" 같은 질문들을 하라. 이러한 질문들은 구체적인 솔루션을 떠오르게 해, 그 팀원은 당장 해결해야 할 사안에 맞춰 일을 처리할 것이다.
- 마커스 버킹엄, 애슐리 구달, <피드백에 멍들다>
잘못된(혹은 불완전한) 지식을 가진 엔지니어
엔지니어에 대한 교육 부족
신입 엔지니어를 철저히 교육하지 않은 관리자.
[실수 예방]
실수 예방은 행동에서 실수로 가는 경로를 차단하려고 합니다. 즉, 실수를 저지르지 말라고 요구합니다. 근데, 사실 이것이 불가능에 가깝습니다. 전문가도 1시간에 평균 3~5개의 실수를 저지른다고 합니다. (...) 실수 예방 문화에서는 실수를 한 사람을 비난하고, 처벌하고, 따라서 실수를 감추고 그에 대해 논의하기 꺼리며 문제가 생겼을 때 협력도 덜하게 됩니다. 실수에서 배우지 못하겠지요.
[실수 관리]
반대로 실수 관리 문화에서는 실수가 나쁜 결과 내기 전에 빨리 회복하도록 돕고, 실수를 공개하고, 실수에 대해 서로 이야기하고 거기에서 배우는 분위기가 생깁니다. (...)
그런데 "이런 실수 관리 문화가 회사에 정말 도움이 될까" 하는 의문을 가질 수 있습니다. 여기에 대해서 연구가 있습니다. 우선 회사 문화가 실수 예방보다 관리에 가까울수록 회사의 수익성(총 자산이익률로 계산)이 더 높습니다. 왜 이런 현상이 나타날까요? 이유는 간단합니다. 실수가 없으면 학습하지 못합니다. 이는 학습이론의 기본입니다. 즉, 실수 관리를 하는 문화일수록 학습을 더 잘합니다.
- 김창준, <함께 자라기>
특히 상사와 부하, 교수와 학생의 관계와 같이 한쪽에 더 많은 파워가 있는 경우 이런 경향은 더욱 심해진다. 상사가 부하에게 "왜 일을 그렇게 했나요?"라고 물으면 부하는 '내가 일을 잘 못했나?'라는 생각부터 한다. 교수가 학생에게 "왜 이 방법을 사용하지 않았나요?"라고 물으면 학생은 교수가 자신을 꾸짖는 것으로 받아들일 수 있다. 이런 관계에서 파워가 약한 사람은 강한 사람에게 "왜?"라는 질문을 하기도 어렵다. 마치 대드는 것처럼 들릴 수 있기 때문이다.
- 이태복, 최수연, <임팩트 질문법>
"사고가 기계적 결함 때문인가, 아니면 사람의 실수 때문인가? 사고 발생 직후에 흔히 하는 질문입니다. 사실 이 질문은 매우 단순하고 순진한 질문처럼 보입니다. 사고를 당했다면 무엇이 고장 났는지 알아내는 것이 당연한 일이기 때문입니다. 그러나 이 질문은 사고 발생 방식에 대한 특정한 이해를 담고 있으며, 인과관계 분석을 그러한 이해에 국한시킬 위험이 있습니다. 이는 우리를 고정된 해석 레퍼토리에 갇히게 합니다. 이 레퍼토리에서 벗어나기는 어려울 수 있습니다. 이는 우리가 던지는 질문을 설정하고, 우리가 추적하는 단서와 조사할 단서를 제공하며, 결국 우리가 도출할 결론을 결정합니다."
- Sidney Dekker, <The Field Guide to Understanding Human Error>
"우리는 사고의 원인(때로는 근본 원인 또는 주요 원인이라고 부르기도 함)과 같은 것이 있다고 생각하며, 잔해 속을 열심히 들여다보면 그 원인을 찾을 수 있을 것이라고 생각합니다. 실제로는 원인이나 주요 원인 또는 근본 원인 같은 것은 존재하지 않습니다. 원인은 우리가 구성하는 것이지 찾는 것이 아닙니다. 그리고 원인을 구성하는 방법은 우리가 믿는 사고 모델에 따라 달라집니다."
- Sidney Dekker, <The Field Guide to Understanding Human Error>
답하기 쉬운 질문은 '어떤'이나 '무슨'으로 시작하는 질문이다. 예컨대 "그 이야기의 어떤 면이 당신한테 정말로 중요한가요?"라고 물으면, 기본적으로 같은 질문이지만 답하기는 더 쉽다. 상대는 스토리에서 의미 있는 부분을 좀 더 구체적으로 이야기하게 되고, 결국에는 '왜?' 질문에 대한 답을 내놓게 된다. 실제로 두 가지 방식을 다 사용해 보면 무슨 말인지 알 것이다.
예1) 이번 실수가 발생하게 만든 조직의 결함을 무엇일까요? (O)
예2) 우리가 그 상황에서 어떻게 하는 게 더 나았을까요? (O)
- 사이먼 사이넥, <나는 왜 이 일을 하는가 2>
(...) 그러나 '어떻게'로 시작하는 질문은 그보다 서사적인 원인으로 이어질 수 있다. 원인을 찾아야 할 때 비난의 대상을 찾는 것은 바람직하지 않으며, 소프트웨어 개발이나 팀워크처럼 복잡한 시스템에서 단 하나의 원인을 찾을 수 있다고 생각하는 것 역시 지나치게 낙관적이다. 이 방법은 개인 수준에서도 적용할 수 있다. 무언가 여러분이 의도한 대로 되지 않았을 때 '왜' 대신 '어떻게'로 시작하는 질문을 던져보라.
- 아이노 본 코리, <좋은 팀을 만드는 24가지 안티패턴 타파 기법>
그렇다고 "왜?"를 묻지 말라는 말이 아니다. 다만 상황에 따라 역효과를 내지 않도록 좀 더 부드러운 말로 바꾸어 물으면 더 좋다는 말이다. 구체적으로 '어떻게'나 '무엇'이 들어가는 질문으로 바꾸면 된다.
이해가 안 되는 의견을 내는 동료에게
"왜 그런 의견을 내나요?" (X) / "어떻게 해서 그런 결론에 도달하게 되었나요?" (O)
업무 마감을 지키지 못한 직원에게
"왜 마감을 지키지 못했나요?" (X) / "마감을 하는 데 무엇이 부족했나요?" (O)
새로운 방식으로 업무를 하라고 말하는 상사에게
"왜 그 방식을 사용해야 합니까?" (X) / "그 방식을 채택하신 이유를 설명해 주실 수 있습니까?" (O)
- 이태복, 최수연, <임팩트 질문법>
코드를 작성할 때 취한 접근 방식.
코드를 배포하기 전에 코드가 예상한 대로 작동할 것이라는 확신을 얻은 방법(테스트, 코드 검토 등)은 무엇인가요?
유사한 코드에 대해 어떤 성공 또는 실패를 경험한 적이 있나요?
새로운 기능을 설계할 때 어떤 절충안을 만들거나 관리했나요?
프로젝트의 범위를 어떻게 판단했는지.
프로젝트에서 시간 압박을 얼마나(그리고 어떤 방식으로) 경험했는지.