# 팀 맞춤 원칙: Launchpad 사전신청

- 작성: 2026-10-09, PM(gildong) / 검토: 스폰서(사업본부장), dev-kim, qa-park
- 참고한 표준과 방법론: PMBOK 가이드 8판, PRINCE2 7판, 스크럼 가이드 2020, 칸반 가이드
- 생애주기: 혼합형
- 생애주기를 고른 이유: 출시일(M1 11-06, M2 11-20)은 마케팅 일정에 묶여 바꾸기 어렵고, 신청 화면과 정책은 베타 피드백으로 바뀐다. 마일스톤은 예측형으로, 그 안의 업무는 2주 반복으로 운영한다.

## 1. 프로젝트 특성

| 요인 | 이 프로젝트의 값 | 맞춤에 주는 영향 |
| - | - | - |
| 규모(인원, 기간, 업무 수) | 4명(PM 1, 개발 2, QA 1), 6주, M1 업무 6건 | 위원회와 별도 문서는 두지 않는다 |
| 요구사항의 안정성 | 정책(LP-01)은 법무 의견에 따라 바뀔 수 있다 | 정책 결정을 결정 요청 이슈로 따로 관리한다 |
| 규제, 계약, 감사 요구 | 개인정보(이메일) 수집, 외부 발송 서비스 구독 1건 | 공개 전 법무·개인정보 확인을 관문 조건으로 둔다 |
| 팀의 경험 | GitHub 운영은 Level 1 수준, 스크럼 경험 1명 | 스크럼 이벤트를 줄여 시작하고 회고에서 늘린다 |
| 이해관계자 수와 거리 | 사내 5개 부서, 외부 업체 1곳 | 주 1회 상태 보고와 결정 요청 이슈로 소통한다 |
| 늦거나 틀렸을 때의 비용 | M1 지연 1작업일당 팀 비용 160만원, 개인정보 사고 | 일정 허용 범위와 공개 전 관문을 둔다 |

## 2. 요소별 결정

결정 열에는 가져옴, 줄임, 더함, 버림 중 하나를 쓴다. 이유 열을 비워 두지 않는다.

| 영역 | 요소 | 출처 | 결정 | 이유 | GitHub 기록 |
| - | - | - | - | - | - |
| 관문 | 단계 관문과 단계별 승인 | PRINCE2 단계별 관리, PMBOK 거버넌스 | 줄임 | 마일스톤 두 개를 단계로 보고, 마감 3작업일 전에 스폰서가 결정 요청 이슈로 진행 여부를 승인한다. 별도 위원회는 두지 않는다 | 마일스톤, 결정 요청 이슈 |
| 계획 | 작업 분해 구조 | PMBOK 범위 | 가져옴 | M1 범위가 업무 6건으로 빠짐없이 나뉘었는지 확인한다 | 상위 이슈와 하위 이슈 |
| 계획 | 일정망과 주경로 | PMBOK 일정 | 가져옴 | QA(LP-05)가 선행 3건을 기다리고 마감 여유가 2작업일뿐이다 | cpm.sh, Start date·Target date |
| 반복 | 고정 길이 반복(스프린트) | 스크럼 | 가져옴 | 2주마다 정책과 화면 피드백을 받는다 | Iteration 필드 |
| 반복 | 일일 점검 | 스크럼 일일 스크럼 | 줄임 | 개발 2명이 다른 업무를 겸한다. 화·목 15분으로 줄이고 막힘은 그날 blocked 라벨로 남긴다 | blocked 라벨, 운영 이슈 |
| 반복 | 리뷰와 회고 | 스크럼 | 가져옴 | 리뷰에 마케팅을 부르고, 회고에서 개선 업무 1건을 정한다 | 스프린트 운영 이슈 |
| 흐름 | 진행 중 업무(WIP) 한도 | 칸반 가이드 | 더함 | In Progress와 In Review를 합쳐 3건까지 둔다. 4명 팀에서 동시에 시작한 일이 늘면 하나하나가 늦게 끝난다(리틀의 법칙) | Project 보드 보기 |
| 진척 | 획득가치(EVM) | PMBOK 재무·일정 | 줄임 | SPI(t)와 예상 완료일만 주 1회 본다. Actual은 금요일에 누적값만 적는다 | Estimate, Actual 필드 |
| 진척 | 허용 범위와 예외 보고 | PRINCE2 예외에 의한 관리 | 더함 | 일정 허용 범위를 마감 여유와 같은 2작업일로 둔다. 넘을 것으로 예측되면 1작업일 안에 결정 요청 이슈를 연다 | 상태 보고, 결정 요청 이슈 |
| 보고 | 상태 보고 주기와 형식 | PRINCE2 진척, PMBOK 이해관계자 | 가져옴 | 매주 금요일 실습 16 양식으로 상위 이슈에 올린다 | 상위 이슈 댓글 |
| 변경 | 변경 요청과 승인 | PMBOK 변경 통제, PRINCE2 이슈 | 줄임 | 변경 통제 위원회 없이 범위 변경 기록 댓글로 받고, 마일스톤에 영향이 있으면 결정 요청 이슈로 스폰서가 정한다 | 범위 변경 기록 댓글 |
| 리스크 | 리스크 등록부 | PRINCE2 리스크, ISO 31000 | 가져옴 | 법무 정책, 외부 업체 승인, QA 배정이 일정을 위협한다 | kind:risk 이슈 |
| 리스크 | 정량 일정 위험 분석 | PMI 리스크 관리 표준 | 줄임 | M1 계획 때 한 번, 주경로가 바뀔 때만 다시 돌린다 | sra.sh 결과 |
| 품질 | 완료 정의와 검수 | 스크럼 완료 정의, PMBOK 품질 원칙 | 가져옴 | 체크박스, 검증 근거, 검수자 확인 세 조건을 업무마다 쓴다 | 완료 조건 체크박스, PR 리뷰 |
| 가치 | 비즈니스 케이스 | PRINCE2 비즈니스 케이스 | 줄임 | 한 쪽짜리 Product brief에 목표(사전신청 1,000건)와 중단 조건만 적는다 | 위키 Product brief |
| 교훈 | 교훈 기록 | PRINCE2 경험에서 배움 | 가져옴 | 마일스톤마다 회고 이슈를 남겨 다음 프로젝트의 추정에 쓴다 | 회고 이슈 |
| 조달 | 구매와 계약 관리 | PMBOK 부록, PRINCE2 상업 관리 | 버림 | 외부 발송 서비스 구독 1건이고 회사 구매 절차를 그대로 따른다 | (GitHub 밖) |

## 3. 다시 검토할 조건

- 팀이 6명을 넘거나 저장소가 둘 이상이 된다.
- 외부 업체와 개발 계약을 맺는다.
- 마감 여유가 0이 되거나 허용 범위를 두 번 넘는다.
- 결제 기능처럼 금융 규제를 받는 범위가 들어온다.

## 4. 합의

- 합의한 날과 참석자: 2026-10-09 계획 준비 회의, PM, 스폰서, dev-kim, dev-lee, qa-park
- 다음 검토일: 2026-11-06 M1 회고