이럴 때

지시가 해결책 모양으로 올 때("정확도를 높여라", "이 결제 수단을 쓰면 된다"). 외부 서비스를 붙일 때. 내 판단이 상대의 제약과 부딪칠 때. 기술 과제로 받아서 바로 성실하게 만들고 싶어질 때가 물어야 할 때다.

이렇게

• 세 질문을 던지고, 하나라도 "내가 정할 수 없다"가 나오면 묻는다.
• 외부 서비스는 API 문서보다 가입 요건을 먼저 본다. 결제·본인인증·해외 송금은 기술이 아니라 자격에서 막힌다.
• 계획서에는 그 계획의 근거가 어디서 왔는지 적는다.

멈출 신호·예외

"우리가 개발팀이니까" 같은 역할 진술을 근거로 들고 싶어지면 내 판단의 출처부터 의심한다. 성패를 내가 판정할 수 있는 순수 기술 판단이면 되묻지 않아도 된다.

설명

지시는 대개 누군가 이미 고른 해결책이다. 그 아래의 문제와 제약은 지시와 함께 오지 않는다. 정확도를 높이라는 요구를 기술 문제로 받아 성실하게 풀었지만, 정확도가 그 제품의 성패를 가르는 변수였는지는 끝내 확인하지 않았다. 쓰라고 받은 결제 수단은 한 달 반 동안 붙인 뒤에야 우리가 갖추지 않은 자격을 요구한다는 것이 드러났다.

이 원칙은 내가 내린 결정에도 적용된다. 내 판단이 상대의 제약과 부딪쳤을 때, 기술적으로 더 옳아 보이는 쪽이 내 판단이었고 조직의 맥락을 아는 쪽이 맞았던 일이 두 번 있었다.

반례

되묻는 것이 항상 옳지는 않다. 도메인 규칙을 깊이 파는 것처럼 성패를 내가 판정할 수 있는 일은 되묻지 않고 파는 것이 맞다.

판별법

"이 결정의 성패를 내가 판정할 수 있는가?"

판정할 수 없다면 묻는다. 무엇을 해결하려는가, 되면 무엇이 달라지나, 우리가 못 갖춘 전제가 있나. 셋 중 마지막이 확인하기 가장 싼데도 가장 자주 빠진다.