---
type: knowledge
domain: product
role: PM·PO·BA
status: active
last-reviewed: 2026-07-27
---

# PM·PO·BA 기획 가이드

> 외주·SI에서 PM·PO·BA는 계약·RFP를 **요구사항정의서(SRS)·WBS·RTM**으로 바꿔 Design·Tech Lead·QA에 인계하고, 범위 밖 요청을 CR 절차로 회부하며, 발주사 지연을 기록해 프로젝트를 검수 통과까지 끌고 간다.

## 미션

- 계약 범위·RFP를 기능·비기능 요구사항(SRS)과 기계 검증 가능한 검수 기준으로 구체화한다.
- WBS·일정계획으로 마일스톤(=지불 조건)까지의 실행 경로를 관리하고, 범위 밖 요청은 CR로 회부한다.
- 요구→설계→구현→테스트→검수가 RTM의 한 ID로 추적되게 한다 — RTM이 결과보고서의 본체다.

## 필수 입력

| 입력 | 확인할 내용 | 없을 때 처리 |
|---|---|---|
| 수주·계약 결정 | 계약 범위(포함/제외), 검수 기준, 마일스톤=지불 조건, CR 절차 | `확인 필요`와 Owner·기한 지정. 계약 근거 없는 요구는 SRS에 넣지 않음 |
| RFP·현업 근거 | RFP 원문·재서술, AS-IS 업무, 현업 인터뷰 | 가정과 사실을 분리해 발주사 질의 요청 |
| 기존 시스템·계약 | 레거시 동작, 연동 대상, SLA, 이전 계약 약속 | 원본 링크와 기준 버전 고정 |
| 기술·운영 제약 | 발주사 인프라, 외부 API, 보안 정책, 배포 창 | Tech Lead 검토 항목으로 등록 |
| 발주사 제공 사항 | 계정·데이터·정책·결정의 목록과 필요일 | 의존성 대장에 등록, 지연 시 기록·통지 |

## 결정 순서

1. [[01_PRD·범위 정의]]에서 요구사항정의서(SRS)의 골격 — 문제·업무 흐름·In/Out 범위 — 을 계약과 정합하게 고정한다.
2. [[02_요구사항·완료 조건]]에서 요구 ID, Given-When-Then, NFR과 검수 기준으로 쓸 수 있는 완료 조건을 작성한다.
3. [[03_우선순위·릴리스 계획]]에서 WBS·마일스톤과 계약 Must/CR 후보 구분, 단계 오픈 계획을 정한다.
4. [[04_리스크·의존성 대장]]에서 위험·발주사 제공 사항·발주사 지연 기록을 관리한다.
5. [[05_요구사항 추적표 RTM]]에서 각 요구의 설계·구현·테스트·검수 연결을 유지한다.
6. [[90_PM·PO·BA 완료 체크리스트]]를 통과한 뒤 [[99_PM·PO·BA 브리핑 템플릿]]으로 S-skills 실행 계약을 만든다.

## 파일 지도

| 파일 | 용도 | 주 소비자 |
|---|---|---|
| 현재 문서 | 역할 책임·입력·작성 순서 | PM·PO·BA |
| [[01_PRD·범위 정의]] | SRS 골격 — 문제·업무 흐름·In/Out 원본 | 사업책임, UX·UI, Tech Lead |
| [[02_요구사항·완료 조건]] | 기능·NFR·수용 기준·검수 조건 | UX·UI, Tech Lead, QA |
| [[03_우선순위·릴리스 계획]] | WBS·마일스톤·Must/CR 구분 | 사업책임, Tech Lead, Release |
| [[04_리스크·의존성 대장]] | 위험·발주사 제공 사항·지연 기록 | 전체 실행 역할 |
| [[05_요구사항 추적표 RTM]] | 요구부터 발주사 검수까지 추적 | QA, SI·문서화, 발주사 |
| [[90_PM·PO·BA 완료 체크리스트]] | 착수 가능성 자체 점검 | Reviewer, Approver |
| [[99_PM·PO·BA 브리핑 템플릿]] | `.state/pm-brief.md` 런타임 입력 | Tech Lead, QA |

## 필수 산출물과 소비자

> 이 역할의 산출물은 [[외주 개발 산출물]]의 착수·기획 마일스톤 납품물과 1:1이다: 요구사항정의서(SRS), WBS·일정계획서, RTM.

| 산출물 | 최소 내용 | 소비자의 행동 |
|---|---|---|
| 요구사항정의서(SRS) | 문제, 업무 흐름, In/Out, 기능·비기능 요구 | Design·Tech Lead가 화면정의서·기능사양서를 설계, 발주사가 확인·합의 |
| 요구·완료 조건 | ID, 행동, NFR, 검증법 | 구현자가 작업하고 QA가 PASS/FAIL 판정 — 테스트케이스의 원본 |
| WBS·일정계획 | 작업 분해, 마일스톤=지불 조건, 지연 시 처리 | Tech Lead가 실행 순서와 작업 카드를 설계 |
| 리스크·의존성 대장 | 확률·영향, 완화, 발주사 제공 사항·지연 기록 | 관련 역할이 선행 입력을 닫거나 에스컬레이션 |
| RTM | 요구↔설계↔구현↔테스트↔검수 | QA·SI·발주사가 누락 없이 검수 — 결과보고서의 본체 |

## 역할 경계

- PM·PO·BA는 **무엇과 검수 기준**을 책임진다.
- 특정 라이브러리·DB·서비스 분리는 SRS에 몰래 확정하지 않고 Tech Lead에 판단을 넘긴다.
- 화면정의서의 비주얼 방향·토큰은 UX·UI가 결정한다.
- 실제 구현법과 파일 소유권은 Tech Lead가 결정한다.
- QA의 최종 판정을 대신하거나 구현자 자기 보고로 완료 처리하지 않는다.
- 계약 범위·견적·마일스톤 지불 조건을 임의 변경하지 않는다 — 범위 밖 요청은 CR 절차로 회부하고 사업·제품책임자의 새 결정을 연결한다.

## 진입 게이트

- [ ] 계약(또는 확정 단계의 제안) 범위와 검수 기준이 연결됐다.
- [ ] 재서술된 RFP·발주사 요구 원문이 있다.
- [ ] SRS의 기준이 될 원본 계약·결정(BIZ-DEC)이 연결됐다.

## 종료 게이트

- [ ] 모든 요구에 고유 ID, 우선순위(계약 Must/CR 후보), Owner, 검증 방법이 있다.
- [ ] 기능·품질·회귀 완료 조건을 실행하면 PASS/FAIL이 나온다.
- [ ] 범위 밖(Out of Scope)과 미결·가정·발주사 제공 사항이 드러난다.
- [ ] RTM에 Design·Tech·QA·발주사 검수가 채울 열과 책임이 준비됐다.
- [ ] Tech Lead와 QA가 이전 대화나 PM의 의도를 추측하지 않고 착수할 수 있다.
- [ ] SRS·WBS·RTM이 그대로 착수 마일스톤 납품물·검수 근거로 쓰일 수 있다.

## 함께 읽기

- [[00_역할별 기획 허브]]
- [[00_역할별 기획 운영 가이드]]
- [[역할별 개발 산출물]]
- [[외주 개발 산출물]]
- [[요구사항과 완료 조건]]
- [[SI 수주와 범위 관리]]