반응형
프로젝트 매니저가 관리해야 하는 핵심 문서
PM 문서는 프로젝트의 진행을 기록하고, 의사결정을 명확히 하며, 협업 속도를 높이는 역할
① 프로젝트 헌장(Project Charter)
- 프로젝트의 목적, 배경, 목표, 범위, 일정, 예산을 정의
- 프로젝트의 "공식 출발점"
- 경영진/리더 승인 필요
| 항목 | 내용 예시 |
| 프로젝트명 | 웹사이트 기능 고도화 |
| 배경 | 고객사 요구사항 변경 및 신규 요청으로 인한 개발 |
| 목표 | 고객사 요구사항의 구체적 목표 기입 및 신규 구체적인 추가 기능 기술 |
| 범위(In Scope) | 기능 추가가 되는 부분 작성 ex) A 기능 리펙토링을 통한 성능 향상 B 기능 신규 추가 |
| 제외 범위(Out of Scope) | C 기능, D 기능 |
| 일정 | 2025.01~2025.12 |
| 예산 | 10M |
| 주요 산출물 | UI 명세서, 운영 메뉴얼, API 문서, ERD (회사 별 필요한 산출물 구비) |
| 이해 관계자 | 개발 팀, QA 팀, ... |
② 범위 정의서(Scope Definition / SOW)
- 무엇을 할 것인지, 무엇을 하지 않을 것인지 명확하게 정리
- 의사소통 오류를 줄이는 가장 중요한 문서
| 프로젝트 개요 | |
| 항목 | 내용 |
| 프로젝트명 | 웹사이트 기능 고도화 |
| 작성일 | 2025-02-20 |
| PM | 홍길동 |
| 버전 | v1.0 |
| 범위 정의(In Scope) | ||
| 구분 | 상세 범위 | 비고 |
| 기능 | 대용량(20MB) 엑셀 업로드 기능 개선 | 기존 대비 속도 향상 |
| 기능 | 업로드 데이터 유효성 검사(스키마/필드 검증) | |
| 기능 | 오류 리포트 다운로드 기능 | Excel/CSV 지원 |
| UI | 입력 화면 개선 | DataTables 기반 |
| API | 비동기 업로드 API 신규 개발 | /component/upload-async |
| 백엔드 | 스트리밍 방식 파일 처리 | 메모리 절감 목적 |
| 로깅 | 업로드 이력 저장 | UPLOAD_LOG 테이블 |
| 제외 범위(Out of Scope) | |
| 제외 항목 | 설명 |
| UI 전체 리뉴얼 | 디자인 변경은 이번 범위에서 제외 |
| 운영지원 시스템 개선 | 기존 운영포털 업그레이드는 제외 |
| 모바일 화면 지원 | PC 버전만 지원 |
| 타 모듈 연동 | Github 연동은 별도 프로젝트 |
| 비기능 요구사항(NFR) | ||
| 항목 | 요구사항 | 기준 |
| 성능 | 1000라인 기준 5초 이내 처리 | 필수 |
| 안정성 | 서버 메모리 증가 없음 | 스트리밍 방식 적용 |
| 보안 | 파일 업로드 확장자 제한 | .xls/.xlsx |
| 가용성 | 장애 발생 시 자동 롤백 | 트랜잭션 기반 |
| 인수 기준 | ||
| 번호 | 기준 내용 | PASS 조건 |
| AC-01 | 20MB 파일 업로드 가능 | 업로드 완료 메시지 노출 |
| AC-02 | 1000라인 처리 시간 | 5초 이내 |
| AC-03 | 오류 리포트 제공 | 클릭 → Excel 다운로드 |
| AC-04 | UI 멈춤 없음 | 비동기 방식으로 처리 |
| AC-05 | 로그 저장 | DB 이력 조회 가능 |
| 제약 조건 | |
| 항목 | 설명 |
| 기술 제약 | Tomcat 9.x / Spring MVC 기반 유지 |
| 인력 제약 | FE 1명, BE 1명, QA 1명 |
| 일정 제약 | 개발 4주 + 테스트 2주 내 완료 필요 |
| 가정 | |
| 항목 | 설명 |
| 데이터 | 업로드 엑셀 구조는 기존 포맷 유지 |
| 인프라 | 서버 스펙 변경 없이 진행 |
| 협업 | 타팀 API 변경 없음 |
③ WBS(Work Breakdown Structure)
- 프로젝트를 단계별/업무별로 쪼개는 문서
- 일정/자원/예산 산정의 기준이 됨
예시)
| WBS ID | Task | 담당 | 기간 | 산출물 | 선행 작업 |
| 1.0 | 대용량 업로드 기능 개선 | PM | 6주 | - | - |
| 1.1 | 요구사항 정의 | PM | 1주 | 요구사항 정의서 | - |
| 1.2 | API 설계 | 개발 | 1주 | API 스펙 문서 | 1.1 |
| 1.3 | DB 구조 개선 | 개발 | 1주 | ERD | 1.2 |
| 1.4 | UI 입력 폼 개발 | FE | 1주 | JSP/JS 화면 | 1.2 |
| 1.5 | 테스트 및 QA | QA | 1주 | Test Report | 1.4 |
④ 일정관리표 (간트 차트, 일정 계획서)
- MS Project, Notion, Jira, Gantt Chart 등으로 작성
- Task 간 선행·후행 관계 설정
⑤ 요구사항 정의서 / 기능 명세서 (FRD / Spec)
- 고객/내부 사용자의 요구사항
- 기능 상세, UI, API 구조
- 변경 시 Change Request(CR) 문서 필요
| 항목 | 내용 |
| 요구사항 ID | FR-001 |
| 요구사항명 | 대용량 업로드 처리 |
| 설명 | 사용자는 1000라인 이상 Excel 파일을 업로드할 수 있어야 한다. |
| Actor | 관리자 |
| 우선순위 | High |
| 인수 기준 | 5초 이내 처리 시 PASS |
| 변경이력 | … |
⑥ 이슈 로그(Issue Log)
- 발생한 문제
- 담당자
- 해결 기한
- 우선순위
- 해결 여부 추적
| ID | 이슈 내용 | 영향도 | 우선순위 | 담당자 | 기한 | 상태 | 조치내용 |
| ISS-012 | 업로드 시 UI 멈춤 현상 | 중 | H | FE팀 | 2/15 | 진행중 | 비동기 처리로 개선 예정 |
⑦ 리스크 관리 문서 (Risk Register)
- 발생 가능성 / 영향도
- 대응 전략
- 리스크 트리거(징후)
| Risk ID | 리스크 | 가능성 | 영향도 | 대응 전략 | 담당 |
| R-003 | 파일 크기 증가로 서버 메모리 부족 | 중 | 높음 | 스트리밍 방식 적용 | 개발 |
⑧ 커뮤니케이션 계획서
- 누구에게 어떤 내용으로 언제 무엇을 보고할지 정리
→ PM의 보고 품질이 달라짐
| 대상 | 보고 내용 | 방식 | 주기 | 비고 |
| 팀장 | 프로젝트 현황 | 주간 보고서 | 매주 | PPT |
| 개발팀 | Task 진행률 | 스크럼 | 매일 | 5분 |
| QA팀 | 테스트 일정 | 회의 | 주 2회 | 테스트 기간 |
⑩ 테스트 계획서/Test Case(SIT, UAT)
- 기능 검증 기준
- 테스트 일정
- Pass/Fail 기준
| TC ID | 테스트 항목 | 입력 | 기대 결과 | 담당 | 결과 |
| TC-001 | 엑셀 업로드 | 1000라인 파일 | 성공, 5초 이내 처리 | QA | PASS |
⑪ 회고(Retrospective) 및 종료 보고서
- 프로젝트 종료 시 작성
- 잘한 점, 부족한 점, 다음 프로젝트 개선 항목 정리
이거 문서 관리 잘하는게 찐고수
반응형
'소프트웨어 공학' 카테고리의 다른 글
| 프로젝트 매니저 (Project Manager) (0) | 2025.11.20 |
|---|