---
type: template
domain: product
role: 사업·제품책임
status: active
last-reviewed: 2026-07-27
---

# 문제·대상사용자 정의

> RFP를 그대로 믿지 말고 **재서술**한다 — 발주사의 언어로, 발주사가 놓친 함의까지. 제안서의 절반은 "이 사람이 우리 문제를 이해했는가"의 증명이다 ([[SI 수주와 범위 관리]] §제안서). 대상 사용자는 세그먼트가 아니라 **발주사 조직의 실명 구조**(결재권자·검수자·현업)다.

## 문서 정보

| 항목 | 값 |
|---|---|
| 프로젝트·계약 | `{이름}` |
| 발주사·RFP 원문 | `{발주사명 · RFP/회의록 링크}` |
| Accountable Owner | `{한 명}` |
| 상태·버전 | `Draft / Review / Approved · v{N}` |
| 근거 기준일 | `{YYYY-MM-DD}` |
| 관련 결정 ID | `{BIZ-DEC-001}` |

## 문제 재서술

> **{발주사 현업}이 {업무 상황}에서 {업무 목표}를 하려는데 {장애물} 때문에 {시간·비용·위험}을 치르고 있다. 발주사는 이를 {RFP 표현}으로 요구했다.**

| 질문 | 답 |
|---|---|
| RFP가 명시한 요구는? | `{원문 인용·항목 번호}` |
| RFP에 없지만 발주사가 기대할 것은? | `{숨은 기대 — 착수 전 확인 또는 제외 명시 대상}` |
| 마지막으로 실제 발생한 업무 사례는? | `{언제, 누가, 무슨 일이 있었는가}` |
| 빈도·규모는? | `{일/주 N건, 현업 N명, 월 N원 등}` |
| 발주사가 이 시점에 발주한 계기는? | `{감사·규제·시스템 노후·조직 개편 등}` |
| 요구가 증상인지 원인인지 확인했는가? | `{5 Whys 요약 — 재서술로 발주사와 합의}` |

## 발주사 조직과 대상 사용자

| 역할 | 소속·이름 | 프로젝트에서 하는 일 | 우리와의 접점 | 우선순위 | 근거 |
|---|---|---|---|---|---|
| 결재권자 | `{임원·부서장}` | `계약·잔금 승인` | `{보고 주기}` | `Key` | `{조직도·회의록}` |
| 검수자 | `{담당자}` | `산출물 검수·서명` | `{검수 회의}` | `Key` | `{근거}` |
| 현업 사용자 | `{부서·인원}` | `실제 시스템 사용` | `{인터뷰·교육}` | `Primary` | `{인터뷰·현장}` |
| 운영·전산 담당 | `{담당자}` | `이관 후 운영` | `{인수인계}` | `Secondary` | `{근거}` |

> 검수자와 현업 사용자가 다르면 위험 신호다 — 현업이 만족해도 검수자가 서명하지 않으면 종료되지 않는다. 검수자의 기준을 착수 전에 확인한다.

### 명시적 비대상

| 사용자·부서·상황 | 이번 계약에서 제외하는 이유 | 처리 |
|---|---|---|
| `{비대상 부서·업무}` | `{RFP 범위 밖 / 예산·기간 밖}` | `계약서 제외 목록(Out of Scope)에 명기` |

## AS-IS 업무 분석 (현재 행동과 대안)

| 단계 | 현업이 지금 하는 일 | 사용 도구·대안 | 마찰·비용 | 관찰 근거 |
|---|---|---|---|---|
| 1 | `{업무 행동}` | `엑셀 / 수작업 / 레거시 시스템 / 타 부서 의뢰` | `{시간·오류·위험}` | `{현업 인터뷰·현장 기록·샘플 데이터}` |

> "이렇게 쓸 것 같다"는 현업의 미래 의견보다 마지막 실제 업무 처리 방식을 우선한다. AS-IS를 모르고 만든 TO-BE는 검수일에 "우리 업무랑 다른데요"로 돌아온다.

## TO-BE 업무 정의

| 구분 | 문장 |
|---|---|
| 도입 상황 | `{어떤 업무 계기로 시스템을 쓰는가}` |
| 핵심 업무 | `{시스템으로 완결되어야 하는 업무 단위}` |
| 업무적 결과 | `{처리 완료의 정의 — 검수 기준의 원형}` |
| 조직적 결과 | `{보고 가능성, 감사 대응, 책임 소재 명확화 등}` |
| 병행·대체 방식 | `{시스템 밖에 남는 업무 — 범위 경계}` |

## 확인된 사실과 미확인 가정 분리

| ID | 내용 | 구분 | 출처·근거 | 확신도 | 착수 전 확인 방법 | Owner·기한 |
|---|---|---|---|---|---|---|
| `E-01` | `{확인된 사실}` | `Evidence` | `{RFP·인터뷰·데이터}` | `높음` | `해당 없음` | `{이름}` |
| `A-01` | `{아직 확인 안 된 믿음}` | `Assumption` | `{없음}` | `낮음` | `{현업 인터뷰 / 발주사 질의 / 샘플 확인}` | `{이름 · 날짜}` |

> 미확인 가정은 견적의 리스크 버퍼 근거이자, 계약서의 "발주사 제공 사항·전제 조건" 항목의 원본이다. 가정을 계약 문구로 바꾸지 못하면 우리 리스크로 남는다.

## 문제 이해 판정

- 결정: `제안 진행 / 발주사 질의 먼저 / 수주 검토 중단`
- 가장 강한 이해 근거: `{한 줄}`
- 가장 위험한 미확인 가정: `{한 줄}`
- 착수 전 확인 계획: `{질의·인터뷰 · 대상 · 기한}`
- PM·UX에 전달할 핵심: `{한 문장}`

## 관련 문서

- [[SI 수주와 범위 관리]]
- [[기획 원리]]
- [[02_제품 목표·KPI]]