2 day 2024.01.30.
13. 프로젝트 이해하기(2)
10. 프로젝트 PROCESS
0. 관리/착수
- 프로젝트를 시작하는 단계로, 프로젝트 목표와 비즈니스 모델 설정
- 환경 및 비용 고려
1. 프로젝트 계획
- 사전정보 요청서(RFI) 작성 및 제출
- 제안 및 견적 요청서(RFP, RFQ) 작성 및 제출
- 제안서, 견적서, 투입 계획서 등 제출
2. 분석
- 시스템 분석 및 개발 분석 진행
- 서비스 기획자는 이 단계에서 가장 바쁜 시기를 보내게 됨
3. 설계
- 정보 구조(IA) 설계
- 프로젝트 분석 바탕으로 서비스 프로세스 정의
4. 구현
- 스토리보드 리뷰를 통해 필요한 변경사항 보완
- 단위 테스트를 통해 기획안 및 디자인과 개발이 제대로 구현되었는지 확인
5. 검수/테스트
- 구현 단계보다 더 깊은 수준의 테스트 진행
- 전문 테스트를 통해 프로젝트의 완성도 향상
6. 종료
- 각 파트에서 진행된 문서를 최신화
- 운영 매뉴얼 작성 및 인수인계 진행
12. 프로젝트 계획
1. 업무분석
- 프로젝트의 목표와 범위를 파악하고, 이를 달성하기 위해 필요한 업무를 분석
2. 인력 구성
- 프로젝트의 성공을 위해 필요한 인력을 구성
- PM 또는 PMO가 각 프로젝트별로 필요한 인력과 예산을 배치하는데 중요한 역할
3. 환경 세팅
- 개발 단계부터 실서버 오픈까지의 단계별 환경을 세팅
- 시스템 설계, 스테이징 등의 단계별 절차가 필요
4. 프로세스 정의
- 인력, 산출물 등 모든 업무의 프로세스를 정
- 서비스 기획자는 이 단계에서 프로젝트의 이해와 서비스에 대한 분석을 통해 메인 시안용 기획을 진행
5. 산출물 정의
- 서비스 기획 결과물(공식적), 회의록, 근거자료, 히스토리(비공식적) 등을 작성
- 산출물은 초안 작성부터 중간 고도화 작업, 검수 후 보완, 최종 공유 전 버전 업데이트까지의 과정
- 사업수명계획서, 기술적용계획표, 작업분할체계도, 품질보증계획서, 프로그램개발가이드, 디자인 시안 등 다양한 산출물을 정의하고 작성
6. 일정 산정
- 프로젝트의 최종 마감일정을 산정하고, 세부적인 일정을 계획
- 상세 WBS(Work Breakdown Structure)를 통해 업무를 분류하고 일정을 관리
- 프로젝트는 일정이 가장 중요하므로 틈틈이 관리가 필요
7. 프로젝트 계획 근거 마련
- 제안서와 제안 견적서: 프로젝트 제안의 근거가 됨
- 투입인력 계획서: 세부적인 인력 배치와 일정 계획의 근거가 됨
8. 상세 WBS 작성
- 상세 WBS(Work Breakdown Structure): '일정표'로서 업무 분류 체계를 요약함
9. 메인 시안용 기획
- 프로젝트에 대한 이해와 서비스에 대한 분석이 어느 정도 완료된 사람이 메인 시안용 기획을 진행함
10. 제안 범위 재협의
- 제안서에 대한 내용을 확인하고 제안 범위를 재협의함
11. IA 초안 작성
- Information Architecture(IA)의 초안을 작성함
14. 프로젝트 계획_산출물 리뷰
1. 예시. 실투입 인력 계획 산출
- Division: 부서(개발/디자인 등)
- 타스크(Task): 모듈명, 프로덕트
- 맨머스(man/month, m/m): 한달에 몇명인지? → 해당 프로젝트는 12개월 프로젝트로 최종 13.75 맨머스
2. 예시. 산출물 정의
- 본인이 책임지고 최종적인 산출물을 만들어야 한다 (초안 → 중간 고도화 작업 → 검수 후 보완 → 최종 공유 전 버전 업데이트)
- 사업수명계획서, 기술적용계획표, 작업분할체계도, 품질보증계획서...프로그램개발가이드, 디자인 시안...
3. 예시. 상세 WBS(Work Breakdown Structure)
- 프로젝트는 일정이 가장 중요하므로 틈틈이 관리 필요
15. 프로젝트 분석
1. 환경 분석
- 네트워크 구조, 경쟁사, 시장 환경을 분석하여 서비스의 위치를 파악
- 예시: '패스트캠퍼스' 프로젝트는 경쟁사(클래스 101 등)와 시장 환경(온라인 강의 플랫폼 진행 현황) 분석이 필요
2. 요건 분석
- RFP에 기재된 TO-BE 업무를 작성한 기획자와 실무 담당자가 의견이 상이할 경우, 이를 논의하여 방안을 고민
- AS-IS(현재)를 분석하고, 요구사항 정의서를 바탕으로 TO-BE(미래)를 계획
- 가능한 범위 내에서 개발자와 함께 가능성을 확인
3. 콘텐츠 분석
- 서비스를 제공하는 모든 콘텐츠 (예: 회원가입, 강의 등)를 분석
- 현재(AS-IS)를 분석하고, 그에 따른 개선사항을 반영한 IA를 작성
4. 정책 정의
- 큰 그림에 대한 정책을 정의합니다. 이는 설계 단계에서 변경될 수 있다.
- 예시: 회원가입시, AS-IS에서는 본인인증을 하지 않았으나 TO-BE에서는 본인 인증을 진행하는 것으로 정책 변경이 이루어질 수 있다.
5. 가이드 정의
- 산출물에 대한 가이드를 정의하며, 기획자, 디자이너, 퍼블리셔, 개발자 각각에게 필요한 가이드를 작성
- 서비스 기획자는 가장 큰 산출물인 [화면 설계서, 스토리보드, 화면 정의서]를 도출하며, 각 담당자들과 함께 작성
6. 공수 재산정
- TO-BE 서비스로 변경될 경우, 필요한 인력 투입 및 비용 추가에 대해 사전에 논의
- 예시: A 서비스 개발을 위해 필요한 개발 인원이 더 필요한 상황 - 개발 인원 1명 추가, 기획자 1명 축소 등
16. 프로젝트 분석_산출물 리뷰
1. 예시. 타사 벤츠마케팅을 위한 '커머스 사이트별 MAll 구성표'
- 프로젝트 분석-환경분석으로, '벤치마킹'의 방식으로 타사 조사
: 한눈에 보이도록 일목요연하게 분석결과 도출
2. 예시. 타사 벤치마킹을 위한 '헤드라인' 분석 => 분석 후, 최종 요약표로 일목요연하게 정리 필요
1) LAZADA: GNB 변형구조 - 사용자 스크롤 시 GNB 변형
level 1 - app 다운로드
level 2 - 주요 제품 카테고리(햄버거 icon), 장바구니, 로그인/주문화인/도움말
level 3 - 검색창
2) blibli: GNB의 변형구조 - 없음(사용자 스크롤 시 GNB 간소화 없음)
level 1 - app 다운로드
level 2 - 주료 제품 카테고리 , 검색창, 장바구니
3) bhinneka: GNB 변형구조 - 사용자 스크롤 시 GNB 변형
level 1 - 주요 카테고리 메뉴, 장바구니
level 2 - 검색창
l 모르는 단어
- 타스크: 특정 목표를 달성하기 위해 수행해야 하는 작업을 의미. 일반적으로 프로젝트를 진행할 때, 여러 개의 타스크로 나누어 각각을 완료하면서 전체 목표를 이루어나간다.
- 맨먼스: 프로젝트를 수행하는 데 필요한 노력을 측정하는 단위. 프로젝트에 6맨먼스가 필요하다면 한 사람이 6개월 동안 일하거나, 6명이 한 달 동안 일하는 것을 의미.
- AS-IS & TO-BE: '현재 상태'를 의미하며, TO-BE는 '미래의 원하는 상태'를 의미. AS-IS는 현재의 문제점을 분석하고 이해하는 데 사용되며, TO-BE는 개선하고자 하는 목표 상태를 설계하는 데 사용.