프리모템, 제대로 실행하기: 팀이 이미 알고 있는 위험 드러내기

너무 늦게 온 레트로

12개월 후, 당신은 지금 승인하려는 계획에 대한 회고에 앉아 있습니다. 출시가 실패했고, 숫자는 좋지 않으며, 방은 회고에서 방들이 하는 일을 하고 있습니다: 왜 항상 잘못될 수밖에 없었는지를 유창하고 자세하게 설명하고 있습니다. 모두가 개인적으로 의심했던 공급업체 의존성. 아무도 믿지 않았던 채용 가정. 한 엔지니어가 한 번, 조용히 언급했지만 다시는 언급하지 않았던 통합 위험.

여기 불편한 부분이 있습니다: 그 지식의 대부분은 오늘날, 그 회의에 앉을 사람들의 머릿속에 존재합니다. 당신의 팀은 위험을 보지 못하는 것이 아닙니다. 그것을 말하지 못하고 있습니다 — 왜냐하면 계획에는 후원자가 있고, 후원자가 방 안에 있으며, 아무도 상사의 계획이 실패할 이유를 나열한 사람으로 경력을 쌓지 않기 때문입니다.

프리모르템은 바로 이를 위해 만들어진 의식입니다. 게리 클라인은 2007년 하버드 비즈니스 리뷰에서 이를 설명했습니다: 방에 계획이 이미 실패했다고 말하고, 12개월 후에 왜 그런지 모두에게 적어보라고 요청합니다. 시제 변경은 실제로 효과를 발휘합니다 — 예측적 회고에 대한 연구는 결과를 단순히 가능성이 아닌 확실한 것으로 상상하는 것이 사람들이 생성하는 원인의 수와 구체성을 증가시킨다는 것을 발견했습니다. 그리고 이러한 프레이밍은 사회적 작업도 수행합니다: 이제 더 이상 후원자의 계획을 비판하는 것이 아니라, 허구의 과거를 설명하는 것입니다. 모든 사람은 갑자기 자신이 아는 것을 알 수 있게 됩니다.

사람들이 이미 알았던 이유

사전 사망 분석이 무엇을 수정하는지에 대해 정확히 아는 것이 중요합니다. 이는 분석 기법이 아닙니다. 그것이 드러내는 실패 모드는 거의 항상 결정 이전에 누군가에게 알려져 있었습니다. 그들이 막힌 이유는 집단의 존중이라는 표준 기계 때문입니다: 반대 의견은 사회적으로 비용이 많이 들고, 초기 의견이 나중의 의견에 영향을 미치며, 결정적인 걱정을 가진 사람은 종종 통화에서 가장 주니어한 목소리입니다. 우리의 구조적 이견 및 스틸맨닝에 대한 글은 그 기계를 자세히 설명합니다 — 사전 사망 분석은 적용된 대응책입니다.

그것이 바로 올바른 메커니즘으로 실행하는 것이 열정으로 실행하는 것보다 더 중요한 이유입니다. 두 가지 하중 지지 특성은 독립성 — 모든 사람이 다른 사람의 원인을 보기 전에 글을 씁니다 — 그리고 부착 — 모든 원인은 위협하는 계획과 연결되어 있으며, 저자가 있어 질문하고 도전하며 완화할 수 있도록 하며, 화이트보드에 사진을 찍어 잊혀지지 않도록 합니다.

1단계: 계획을 주장으로 구성하기

계획을 주요 주장으로 삼아 논의를 시작하세요 — 질문이 아닌 확고한 주장으로 명시합니다: "우리는 Q2까지 Y 세그먼트에 X를 배송할 것입니다." 표현이 중요합니다. 질문("X를 배송해야 할까요?")은 배송 여부에 대한 논의를 초대하지만, 주장은 실패 원인이 공격할 수 있는 대상을 만듭니다. 한 문장, 날짜가 기재되고, 계획의 후원자가 소유합니다.

그럼 클라인의 프레임을 방에 전달하세요, 원문 그대로 하셔도 좋습니다: "지금으로부터 12개월 후입니다. 이 계획은 실패했습니다 — 심각하게. 10분 동안 혼자서 모든 이유를 적어보세요."

• ✓루트 주장 생성됨 — 후원자가 작성한 하나의 확정된 문장으로서의 계획. 체크포인트: 공격할 수 있는 주장으로 읽혀야 하며, 질문이 아니다.

2단계: 조용한 10분

각 참가자는 이제 계획 아래에 반대 주장으로 실패 원인을 독립적으로 추가합니다. 이 도구가 화이트보드보다 우위를 점하는 이유는 여기입니다: 원인은 제출된 후에만 다른 사람에게 보이므로, 누구도 첫 번째 자신감 있는 목소리에 고정되지 않고, 누구도 후원자의 얼굴을 보고 위험을 완화하지 않습니다. 각 참가자에게 최소 세 가지 원인을 요청하며, 구체적인 주장("SSO 통합이 파일럿 날짜를 지나친다")으로 작성해야 하고, 범주("기술적 위험")로 작성해서는 안 됩니다.

선택적으로 AI 스윕을 함께 실행하세요: 여러 모델에서 생성된 추가 실패 모드를 가져옵니다. 이들은 기계가 제안한 것으로 눈에 띄게 라벨이 붙어 있으며, 모든 주장은 출처가 명시되어 있어 방에서는 항상 엔지니어의 실제 걱정과 모델의 패턴 일치를 구별할 수 있습니다. 읽을 때도 이들을 구분하세요: AI는 후보 위험의 범위를 넓히지만, 귀하의 조직을 알지 못합니다.

• ✓침묵의 세대 완료 — 모든 사람이 독립적으로 제출했습니다. 체크포인트: 참가자당 ≥3 원인; 아무도 다른 사람을 수정하지 않았습니다; AI 원인(있는 경우)은 명확하게 표시되었습니다.

3단계: 드러난 것에 대해 질문하기

이제 방은 나무를 읽습니다 — 그리고 가장 큰 소리로 읽는 사람이 이기는 공개 토론 대신, 원인은 세 가지 구조화된 단계로 진행되며, 각 단계는 도전자와 원인의 저자 간의 네 번의 대화입니다:

하나의 특징은 주목할 가치가 있는데, 이는 AI 스윕의 가치가 변하기 때문이다: 기계가 제안한 원인 응답한다. 모델이 작성한 주장은 그 주장을 작성한 동일한 모델로 라우팅되어 자동으로 응답한다 — 따라서 기계가 제안한 실패 모드를 교차 검증하고 즉시 실질적인 답변을 받을 수 있다. 이것이 "왜 단순히 챗봇에게 위험 목록을 요청하지 않나요?"라는 질문에 대한 구체적인 답변이다: 목록은 질문할 수 없다.

4단계: 평가하고 스프레드를 읽으세요.

모든 참가자는 각 원인에 대해 평가를 내립니다 — 각 원인에 대해 하나의 평가, 레이블이 있는 값. 분포에 따라 정렬한 다음, 대부분의 방에서 건너뛰는 작업을 수행합니다: 평균뿐만 아니라 분포를 살펴보세요. 모든 사람이 8로 평가한 원인은 우선 사항입니다. 방의 절반이 9로 평가하고 나머지 절반이 2로 평가한 원인은 더 나은 것입니다: 세상이 어떻게 작동하는지에 대한 진정한 이견이 드러나고 명명된 것입니다. 이러한 분할은 보통 전체 세션에서 가장 가치 있는 발견입니다.

• ✓우선순위 지정 완료 — 모든 사람이 평가한 원인. 체크포인트: 주요 원인 식별; 높은 변동성을 가진 원인은 이견으로 표시되며 중간값에 평균되지 않음.

단계 5: 반론으로서의 완화 조치

각 주요 원인에 대해 완화 조치를 추가하세요 — 여기서 트리는 목록이 할 수 없는 일을 합니다. 완화 조치는 원인의 단점으로 추가됩니다: 실패 모드를 공격하는 주장을 나타냅니다. 그리고 찬반은 부모에 상대적이기 때문에, 단점의 단점은 계획을 지원합니다 — 구조가 본질적으로 논리를 인코딩합니다. 각 완화 조치에는 저자가 있으며, 저자는 소유자입니다.

이것이 일반적으로 화이트보드 형태에서 사전 사망이 끝나는 순간입니다: 위험이 나열되고, 고개가 끄덕여지지만, 아무도 책임을 지지 않습니다. 여기서 체크포인트는 구조적입니다 — 완화 조치 없이 상위 원인이 드러나면 명백히 노출됩니다.

• ✓첨부된 완화책 — 모든 주요 원인은 최소한 한 개의 저자가 명시된 반론을 가지고 있습니다. 체크포인트: 노출된 상위 등급 원인이 없습니다.

여섯 달 후에 당신이 여전히 가지고 있는 것

유물은 핵심입니다. 지금으로부터 6개월 후, 무언가 잘못되었을 때 누군가 "이것을 고려했나요?"라고 묻는다면, 그 대답은 한 번의 검색으로 찾을 수 있습니다: 계획, 그에 대한 모든 반대 의견, 각 반대 의견을 제기한 사람, 각 반대 의견이 극복한 도전 과제, 그리고 첨부된 완화 조치(또는 첨부되지 않은 것). 사진으로 찍은 화이트보드는 그 질문에 답할 수 없습니다; 이것이 답할 수 있습니다 — 90분 만에 구축된 결정 품질 체인의 작동 사례입니다.

정직한 한계

• ✗도구는 심리적 안전을 창출하지 않습니다. 독립적인 제출은 고정 문제를 제거하지만, 반대 의견을 처벌하는 관리자는 제거하지 않습니다. 사람들이 후원자를 두려워한다면, 먼저 그것을 해결하세요.
• ✗AI 생성 위험은 사고를 위한 자극이지 위험 등록부가 아닙니다. 그 이유로 정확히 그렇게 라벨이 붙어 있습니다. 아무도 소유하지 않을 원인은 발견이 아닙니다.
• ✗평가는 단일 레이블 값이며, 확률 × 영향 행렬이 아닙니다. 공식적인 위험 행렬이 필요하다면, 다른 곳에서 내보내고 구축하세요 — 평가가 그것이라고 가장하지 마세요.
• ✗체인은 네 번의 회전 후에 완료됩니다. 이는 끝없는 실이 아닌 구조화된 교환입니다. 만약 의견 불일치가 더 필요하다면, 회의가 필요합니다.
• ✗사전 사망 분석은 아무것도 결정하지 않습니다. 그것은 문제를 드러내고 우선순위를 정합니다; 결정은 — 그리고 계획을 변경할 용기는 — 여전히 당신의 것입니다.

이들을 운영하면서 얻은 실용적인 교훈

• ✓침묵을 엄격하게 시간 제한하라. 10분, 발표하고, 시행한다. 그 가치는 독립성에 있다; 논의가 시작되는 순간, 그것은 더 이상 축적되지 않는다.
• ✓구체적인 문장을 요청하세요, 범주가 아닙니다. "통합 위험"은 아무것도 우선시하지 않습니다; "SSO 통합이 파일럿 날짜를 지나친다"는 도전할 수 있고, 평가할 수 있으며, 완화할 수 있습니다.
• ✓후원자도 글을 씁니다. 계획의 소유자가 자신의 세 가지 실패 모드를 기여하는 것만큼 정직을 보장하는 것은 없습니다 — 첫 번째로.
• ✓다음 계획 세션에서 루프를 닫으세요. 트리를 다시 열고 어떤 완화 조치가 이루어졌는지 확인한 후 원인을 다시 평가하세요. 두 번째 검토는 20분이 소요되며 이때 의식이 복합적으로 진행됩니다.

레트로로 돌아가기

그 12개월 전 회고로 돌아가 보자. 두 가지 버전 모두 발생할 수 있다. 하나는 방이 조용히 예측한 실패를 유창하게 설명하고, 기록에는 아무것도 남지 않는다. 다른 하나는 사전 사망 트리로 시작한다: 여기 우리가 잘못될 수 있다고 말한 것, 여기 우리가 그것에 대해 한 것, 여기 우리가 놓친 것. 두 번째 회고는 더 짧고, 더 친절하며, 다음 계획을 더 좋게 만드는 유일한 방법이다. 이번 주에 90분이 필요하다.