출시 전 위험 요소 점검표 만들기

여섯 영역에서 10행이 나왔고 부서는 자료에 적힌 네 곳만 쓰였다. 발생 가능성은 높음 3·보통 6·낮음 1로 갈렸다.

"높음"이 절반을 넘으면 기준을 다시 세워 재분류해 달라고 하면 된다.

리스크 점검을 프롬프트 한 줄로 부탁하면 "일정 지연", "예산 초과", "인력 부족"이 돌아옵니다. 틀린 말은 아니지만 어느 프로젝트에나 붙는 문장이라 점검표에 옮겨 적어도 아무도 확인하지 않습니다. 이 프롬프트는 그 일반론을 이번 프로젝트의 문장으로 바꾸는 데 초점이 있습니다.

첫 문단의 역할은 관리자이되 "부풀리지도 뻔하게 채우지도 않는" 사람입니다. 위험을 물으면 모델은 안전하게 많이 적는 쪽으로 기울기 때문에, 양쪽을 함께 막아 두어야 목록이 실제 크기로 나옵니다. 맥락 문단에 남은 기간과 함께 움직이는 부서를 넣은 이유는, 같은 위험도 3주 남았을 때와 3개월 남았을 때 할 일이 다르기 때문입니다.

가운데의 예시 두 줄이 항목의 눈높이를 정합니다. 좋은 예에는 "무엇이 무엇에 걸려 있어서 어떤 결과가 되는가"가 들어 있고, 나쁜 예에는 그것이 없습니다. 이 대비 하나로 위험 요소 목록의 구체성이 눈에 띄게 올라갑니다.

형식 문단의 "이런 신호가 보이면 위험" 열은 이 점검표의 쓸모를 결정합니다. 위험은 알아도 언제 움직여야 할지 몰라 늦는 경우가 많기 때문입니다. 확인할 부서 열을 마지막에 둔 것도 같은 이유입니다. 담당이 적혀 있지 않은 항목은 회의에서 읽히기만 하고 아무도 가져가지 않습니다.

제약 문단은 항목 수를 열둘로 묶고 담당자를 지어내지 못하게 합니다. 스무 개짜리 점검표는 아무도 끝까지 읽지 않고, 없는 부서 이름이 한 줄 섞이면 표 전체의 신뢰가 흔들립니다. 이미 끝난 일을 빼라는 문장은 지난 회의 자료를 그대로 복사해 오는 것을 막아 줍니다.

이렇게 물으면 "일정 리스크 / 기술 리스크 / 예산 리스크"라는 제목 아래 교과서 같은 설명이 문단으로 붙어 돌아옵니다. 우리 프로젝트에서 실제로 어긋날 지점은 들어 있지 않고, 담당 부서도 없어서 회의에서 읽어도 누가 무엇을 확인할지가 정해지지 않습니다.

발생 가능성을 "높음"으로만 채우는 경우가 있습니다. 표를 받은 뒤 "높음이 절반을 넘으면 기준을 다시 세워 재분류해 줘"라고 한 번 더 요청하면 균형이 잡힙니다.