탈락의 구조 5화. 설계는 첫 줄 전에 시작된다
5편 완료
출처 : 구글 제미나이, 저자 직접 작성5화, 마지막 편입니다.
계획서를 언제 쓰기 시작하십니까?
공고문이 뜨면 쓰기 시작하는 팀이 있습니다. 마감 2주 전부터 쓰는 팀이 있어요. 컨설턴트에게 맡기는 팀도 있습니다. 그런데 이 팀들에게는 공통점이 있어요. 모두 너무 늦게 시작했다는 겁니다.
계획서 작성은 문서 작업이 아닙니다. 리스크 설계입니다.
대부분의 팀은 이 순서로 움직입니다.
아이디어가 있다. 사업을 시작한다. 어느 정도 진행되면 정부 지원을 알아본다. 공고문을 찾는다. 계획서를 쓴다.
이 순서의 문제는 계획서를 쓰는 시점에 이미 구조가 굳어져 있다는 거예요. 타임라인은 정해졌고, 팀 구성은 완료됐고, 기술 방향도 잡혀 있습니다. 이 상태에서 공고문을 보면 트리거가 보이기 시작해요. 그런데 고칠 수가 없습니다. 이미 늦었거든요.
리스크는 발견하는 게 아닙니다. 처음부터 설계하는 겁니다.
그렇다면 설계는 어디서 시작합니까?
첫째, 지원할 사업을 먼저 정합니다. 아이디어가 있으면 그 아이디어에 맞는 트랙을 먼저 찾아야 해요. 우리 기술이 사업 기간 내에 매출을 만들 수 있는가. 우리 팀이 이 사업이 요구하는 실행력을 증명할 수 있는가. 이 질문에 답할 수 없으면 그 트랙은 맞지 않습니다.
둘째, 탈락 트리거를 먼저 파악합니다. 공고문을 점수표로 읽지 말고, 이 사업에서 무조건 탈락하는 조건이 무엇인지를 먼저 찾아야 해요. 트리거를 피하는 구조를 먼저 설계하고, 그 위에 점수를 쌓는 겁니다.
셋째, 증거를 먼저 만듭니다. 유료 고객이 없으면 만들어야 해요. 수치가 없으면 확보해야 합니다. 팀 실적이 약하면 보강해야 해요. 계획서를 쓰기 전에 계획서에 들어갈 증거가 먼저 있어야 합니다. 증거 없이 계획서를 쓰면 주장만 가득한 문서가 됩니다.
Audit과 Architecture는 다릅니다.
Audit은 발견입니다. 이미 만들어진 계획서에서 문제를 찾는 거예요. Architecture는 설계입니다. 문제가 생기지 않도록 처음부터 구조를 짜는 거예요.
제출 직전 점검은 Audit입니다. 발견은 할 수 있지만 고치기 어려워요. 처음부터 Architecture로 접근한 팀과 마감 직전 Audit으로 접근한 팀의 결과는 다릅니다.
합격하는 계획서는 잘 쓴 문서가 아닙니다. 처음부터 잘 설계된 구조입니다.
이 시리즈를 통해 하고 싶었던 말은 하나입니다.
계획서를 점수로 읽지 마십시오. 리스크 구조로 읽어야 합니다. 그리고 그 구조는 첫 줄을 쓰기 전에 이미 설계돼 있어야 합니다.
저는 이 구조를 7단 리스크 소거 설계, 7R이라고 정리했습니다. 탈락의 구조를 분해하고, 트리거를 제거하고, 합격 가능한 설계를 만드는 프레임입니다. 단순한 문서 작업이 아니라 고도의 문서구조설계 작업입니다.
계획서는 문서가 아닙니다. 구조입니다.
제출 직전이 아니라, 구조부터 다시 보고 싶다면 그때 연락하십시오.