프로젝트 관리 포맷으로 돌아가기

프리모템 템플릿

실패를 상상해 미래를 예측하세요. 프리모템 템플릿을 사용해 출시 전에 잘못될 수 있는 모든 것을 브레인스토밍하고 팀이 예방책을 세워 재난을 미연에 방지할 수 있게 합니다.

6 팀의 템플릿

더 둘러보기

Pre-mortem 템플릿이란 무엇인가?

A Pre-mortem 템플릿은 프로젝트 시작 전에 맹점을 찾아내기 위해 사용하는 구조화된 워크스페이스입니다. 심리학자 Gary Klein이 대중화한 이 방식은 전통적인 "무엇이 잘못될 수 있나?"라는 질문을 다음과 같은 단정문으로 바꿉니다: "지금으로부터 1년 후, 이 프로젝트는 재앙이 되었습니다. 무슨 일이 있었나요?" 이러한 인지적 전환은 종종 낙관론자들로 가득한 방에서 회의론자를 침묵시키는 "과잉확신 편향"과 "집단사고"를 우회합니다.

"Fail-Safe" 감사: 숨겨진 위험을 드러내는 3가지 방법

Pre-mortem은 팀이 거침없이 솔직해질 수 있다고 느껴야만 효과적입니다. Miro에서 세션을 시작하기 전에 다음 세 가지 전문가용 "건강 점검"을 적용하세요:

1. "Prospective Hindsight" 감사

점검: 팀이 표준 RAID 로그처럼 "리스크"만 나열하고 있나요? 해결책:Imagined Certainty를 점검하세요. 전문 템플릿은 팀이 에서 시작하도록 만듭니다. '경쟁사가 출시할 수도 있다'라고 말하는 대신 '경쟁사가 절반 가격에 더 나은 버전을 출시했다'라고 작성해야 합니다. 실패를 역사적 사실로 간주하면 실패로 이어진 현실적 경로를 찾아내기 훨씬 쉬워집니다.

2. "Spectacular Failure" 테스트

점검: 팀이 파악한 "실패"가 너무 작거나 쉽게 고칠 수 있는 수준인가요? 해결책:Scale를 점검하세요. 팀에게 "Total Catastrophe"를 상상해보라고 권하세요—법적 소송, 이탈률 90%, 또는 브랜드의 완전한 붕괴. 대규모 실패를 상상하면 소규모 리스크 사고로는 놓치기 쉬운 시스템적 약점(예: "우리 서버 아키텍처가 트래픽 2배를 처리하지 못한다")을 드러낼 수 있습니다.

3. "집단사고 방지" 가드레일

점검: 프로젝트 매니저나 리드가 브레인스토밍 중에 프로젝트를 '방어'하고 있나요? 해결책:독립적 브레인스토밍을 점검하세요. 처음 10분은 'Silent Writing'(침묵 작성)를 활용하세요. 공유하기 전에 모두가 각자 '실패 원인'을 적어야 합니다. 이렇게 하면 기술적 결함을 발견한 주니어 개발자가 선임 매니저의 낙관에 위축되어 침묵하지 않도록 합니다.

전략적 프레임워크: 어떤 프리모템 템플릿이 필요할까요?

프로젝트 복잡도에 맞는 프레임워크를 선택하세요:

  • 기본 프리모템 캔버스:

    • 추천 대상: 소규모 팀 또는 기능 출시.

    • 진행 흐름: 1. 실패를 가정합니다. 2. 원인을 브레인스토밍합니다. 3. 정리합니다. 4. 대응책을 계획합니다.

  • “Trio of Trouble” 템플릿:

    • 추천 대상: 전략적 비즈니스 전환.

    • 카테고리: 실패를 기술적(작동하지 않음), 시장(수요 없음), 운영(지원 불가)로 분류합니다.

  • “Post-It” 무덤:

    • 추천 대상: 프로젝트의 '끝'을 시각화할 때.

    • 목표: 프로젝트의 '묘비'를 실제로 그리고 그 위에 '사망 원인'을 적어 아이디어에 대한 감정적 애착을 끊습니다.

프리모템 템플릿의 핵심 구성 요소

성과를 내는 프리모템 보드에는 다음 다섯 가지 핵심 요소가 필요합니다:

  • 재난 시나리오: 실패한 미래 상태를 생생하게 묘사합니다.

  • “후보” 원인: 실패의 가능한 모든 원인을 있는 그대로 나열한 목록.

  • “임박한” 위협: 가능성이나 영향력이 큰 상위 3–5개 위험을 우선순위로 정한 목록.

  • 완화 로드맵: 상상한 실패를 방지하기 위해 현재 프로젝트 플랜에 추가하는 구체적인 작업.

  • “레드 플래그” 지표: “조기 경고 신호” 목록(예: "2개월 차까지 사용자 1,000명을 확보하지 못하면 실패로 가는 길에 들어선 것입니다").

프리모템에서 흔한 함정

  • “체크-더-박스”식 절차: 절차상 해야 한다는 이유로만 진행하고, 이후 프로젝트 플랜은 실제로 변경하지 않습니다.

    • 해결책: 모든 "실패 원인"은 반드시 액션 항목으로 이어져야 합니다. 만약 "문서화 부족"이 프로젝트를 실패로 만들었다면, 이번 주에 문서를 작성할 담당자를 지정해야 합니다.

  • 방어적 태도: 사전 실패 분석을 프로젝트 비전에 대한 "공격"으로 느끼는 것.

    • 해결책: 이를 “궁극적인 지원 행위”로 제시하세요. 사전 실패 분석을 하는 팀은 프로젝트의 실제 성공을 자신의 편안함보다 더 중요하게 생각합니다。