상세 컨텐츠

본문 제목

프로젝트 전 과정

PM

by 개발일지작성 2024. 2. 17. 19:20

본문

728x90

<프로젝트 진행 단계>

프로젝트 제안 및 수주 -> 프로젝트 계획 및 시작 -> 기획 -> 디자인 -> 퍼블리싱 -> 개발 -> 테스트 -> 오픈 안정화

 

- 출저 : 불꽃남자25 IT도서관 유튜브

 

 

프로젝트 제안 및 수주

사전 분석 (RFI)

  • 사업 발주를 위한 사전 정보 수립 과정
  • 직접 정보 조사 & 관련 사업자들에게 RFI 요청을 통해 정보 조사

   - 분석단계 RFI 발송은 고객사측은 정보수집, 공급관련 기업측은 사업기회의 윈-윈 구조가 이루어짐

 

사업 공고 제안요청 (RFP)

  • 사업 공고
  • 공개 공고 & 사업 대상업체 우선 선정 참석 요청

제안 및 견적(RFQ)

  • 사업 제안 및 견적 (투입인력 공수 및 비용 산정)
  • 보통은 제안서 및 견적서 제출, 제안 발표를 통한 최종 심사

- 제안서 작성 (회사가 잘하는 점)

- 투입 공수 산정 (정확한 공수 산정)

- 견적 산정 (경쟁사보다 높지않게, 대신 최대한)

- 입찰 진행

 

낙찰

  • 제안 내용 및 견적 검토를 통한 업체 낙찰
  • 낙찰된 업체와 계약 수행

프로젝트 계획 및 시작

팀구성

  • 계약 이후 사전 계획된 투입 공수에 합한 팀 구성
  • 팀 구성은 자회사 인려그 외주 인력, 외부 협력사 등으로 구성

- 사전 제안시 팀 구성 정보를 보내긴 하지만 PM, PL  정도 주요 인력만 픽스, 나머지는 확정 후 교체하는 식

 

프로젝트 진행 전반 계획

  • [현업] 프로젝트 TFT 구성 (보통은 미리 구성해 둠)
  • 프로젝트 관련 현업 TFT 들과 전반적인 진행 계획 수립 (제안 기준 일정 검토)

- TFT 리더와 진행방식 공유 후 일정 정리

주요 협의 사항

- 현업 도움 사항 정리 (현업 담당배치, 주요 고려사항 파악)

- 기본적인 진행 일정에 대한 정리 (크게 본 일정에 대한 상호확인)

- 개발 시스템에 대한 기능 검토 (제안서 기반 간략 검토)

- 착수 보고 준비 시작

 

진행일정 구성(대략적)

  • 현업 TFT 들과 협의된 계획 기반 대략적인 일정 구성
  • 상세 요구사항 분석이 나오지 않았으므로 사에 일정은 분석 후 진행

- 위의 일정은 전체 프로젝트를 거시적으로 보고 진행되는 일정이며, 향후 개발의 상세 일정은 WBS 기반으로 정리

 

프로젝트 본격 시작

  • 프로젝트 진행에 대한 전반적인 계획 수립 후 착수 계획 문서 작성
  • 프로젝트 관계자들에게 착수보고 진행

- 착수 보고 준비 후 일정 확정

착수보고 주요내용

- 모든 관계자들과 프로젝트 개요 공유 (개념, 목적, 이점 등)

- 구축 내용에 대한 사전 설명 (나중에 엉뚱한 말 나오지 않도록)

- 전체 진행 일정 공유 (간략한 일정에 대한 동의 확인)

- 관계자들의 업무 협조 요청 (현업 담당자, 임원, TFT 등)

- 착수보고는 진행에 대한 계획을 관련자들에게 보고하는게 주 목적, 이때 관계자들의 R&R을 명확히 전달 필요

 

회식 등을 통하여 관계자들 끼리 좋은 분위기와 관계유지가 중요함

기획

요구사항 분석

  • 실제 서비스를 쓰는 현업들 대상 개발 요구사항 청취
  • 확인된 요구사항에 대한 분석 및 정리

- PM과 기획자는 현업 담당자에게 요구사항분석을 전달받고 기획자는 요구사항 명세서 or GAP 분석서 를 작성 (주로 SI 에서는 요구사항분석으로 사용)

필수 요소

- 기능명 (화면명)

- 요구사항 명 (내용)

- 상세 내용

- 중요도

- 난이도

- 분석일자

- 관련부서

- 합의자

- 이슈사항

 

요구사항 분석은 가능한 상세하게, 내용 공유 및 확인은 철저하게 (반드시 이메일 등을 통해 도출된 요구사항 공유 및 컨펌)

 

기능개발 정의(WBS)

  • 정리된 요구 사항 기반 기능 정의 (3단게 메뉴 레벨 수준 상세하게 (대분류, 중분류, 소분류로 기능정리))
  • 정의된 기능 기반 전체 개발 일정 상세 계획 (WBS 작성)

- 요구사항분석 정리가 끝난 후 기획자와 PM은 기능 개발 정의(WBS)를 작성

 WBS

개발 기능(업무) 리스트업

업무의 분배 및 검토(투입 공수대비 개발 일정에 문제 없는지)

상세 일정 계획 산정

프로젝트 진행 관리 (상세일정 관리를 통한 확인) 

 

wbs 작성시, 개발하기로 한 범위와 예정된 투입 공수의 분석 철저, 혹시 이슈 발생시 빠른 협의 필요

 

프로세스 정리

  • 정리된 기능에 대해 업무 프로세스 상세 정의
  • 상제 정리된 프로세스 기반 IA작성 (Information Architecture)

- 기획 : 설계 진행을 위한 IA 및 프로세스 흐름도 작성

IA

전체 프로세스 구조 정의 (각각의 세부 메뉴를 정리하고 이 기능이 어떠한 기능이고 얘를 클릭하면 어떻게 작동하고 등등을 정리한 문서)

 

프로세스 흐름도

각 기능 별 상세 업무 흐름도

 

PM : 작성된 걸 받고 수정사항을 거친 후 현업 검토 및 컨펌을 받음

 

프로젝트 초반 분석 설계 시 제일 중요한 것은 각각의 디테일에 대해서 현업의 확인 및 컨펌을 확실히 받을 것

 

상세화면 기획

  • 정의된 기능에 대한 화면으로 분해정의
  • 정의된 화면 별 상세 기획 (이쯤 중간보고 진행)

- 화면설계서 (SB : Story Board) (IA를 이미지화 시킨 것)

 

- 기획된 시스템에 대한 주요 정보 공유 (메뉴는 이렇게 기능은 저렇게)

- 상세 일정 공유 (상세 일정은 이렇게 진행될 것임)

- 주요 이슈 사항 공유 (사전에 이슈 파악 중요)

- 상세 일정을 공유하고 구두로만 하지말고 이메일 등 증거를 남길것

디자인

디자인 컨셉 확인

  • 디자인을 위한 기본 컨셉 확인
  • 각 회사의 CI 혹은 주요 의사 결정자들의 디자인 컨셉 확인

- 현업 컨셉에 대한 상세 정보

- 시안 준비용 화면 정의 (로그인, 메인, 리스트, 상세 등)

- 디자인은 퍼블리싱 개발이 스타트 라인이므로 일정이 지연될 경우, 퍼블 개발이 많이 힘들어짐

 

디자인 시안 작업

  • 확인된 디자인 컨셉 기반 주요화면 시안 작업 (로그인, 메인 등)
  • 3개 정도의 다른 컨셉으로 디자인 시안 작성

- 디자인 시안을 가지고 약간의 수정 후 현업에 전달

- 디자이너의 시안을 현업에게 주시 전에 확인하고 검토는 하되 너무 많은 의견은 피하기 (윗분들의 꼰대짓 하지 말기)

 

시안 확정 및 Develop

  • 디자인 시안 확인 및 확정 (힘든과정, 높은 의사 결정자 의견 수렴)
  • 확정된 디자인 시안을 좀더 정교하게 Develop

- 피곤해도 가능한 윗 선까지 가전에 컨펌 받도록

- 윗 분들의 디자인 센스 의견을 적절히 가지치는 기술

- 시안 확정 일전은 미리 여유있게 잡을 것

- 디자인 일정 밀릴 때 퍼블, 개발 일정 이슈 생김

 

전체 화면 디자인 작업

  • 디자인 시안에 따른 상세 가이드 확정 및 가이드 문서 작성
  • 디자인 가이드에 따른 기획 문서 화면 별 디자인 작업 수행

- 시안 확정 이후로는 디자인 작업의 속도가 나도록 최대한 지원할 것

퍼블리싱

일정에 따른 퍼블리싱

  • 디자인 문서 수령 후 일정에 따른 퍼블리싱 작업 시작
  • 기본 가이드 작성 후 상세 화면 퍼블리싱 작업

유저 SIDE 우선작업

  • 개발 일정에 따른 퍼블리싱 진행
  • 일반적으로 사용자 (B2B 고객, B2C 고객) 쪽 화면 퍼블리싱 먼저

관리 SIDE 다음작업

  • 개발 일정에 따른 퍼블리싱 진행
  • 일반적으로 관리자 쪽 화면 퍼블리싱 나중

퍼블리싱 보완 지원

  • 개발자에게 퍼블리싱 결과물 전달
  • 개발자의 요청에 따른 퍼블리싱 조정 및 보완 진행

개발

(사전) 서버-네트워크 환경구성

  • 기획-디자인 등 개발 사전 단계 진행중 서버 네트워크 환경 정의
  • 구성에 따른 장비 수급(기존장비, 신규발주 등) 및 환경 구성

- 사전 준비한 네트워크 구성도 검토

- 필요한 장비 확보 및 발주

- 실 사전 준비는 프로젝트 착수 시점부터 바로 진행해야함

 

(사전) 개발 환경 구성

  • 개발을 위한 프레임워크에 대한 고객(IT부서)과 협의
  • 협의된 구조에 따른 개발 환경 구성(서버, DB, 개인 등)

- 전체 시스템 구성도, HW 인프라 구성도  상세, 시스템 아키텍쳐 구조도 정리

고려 사항

- 유저 편의성

- 개발 자원 효율성

- 개발 일정

- 향후 운영 인력 상황

 

- 요구사항 분석과 관계없이 프로젝트 스타트 시점에 빠르게 정리

 

개발진행 (프론트/백)

  • 기획 문서 기반의 개발 진행
  • 개발 작업은 프론트/백 병행
  • 일반적으로 효율적 작업을 위해 백 개발을 먼저 진행
  • 기획확인 -> 개발 -> 완료 -> 검증 의 반복

- WBS : 계획 및 공유 목적 이용

- 간트차트 : 가시화된 진행 상황 파악

- WBS나 간트차트는 프로젝트 성행 혹은 PM, PL의 성향에 따라 다양한 개발 관리 툴을 이용해서 사용

테스트

테스트 케이스 작성

  • 테스트를 위한 상세 케이스 작성
  • 일반적으로 엑셀에 어느 화면에 어떤 기능을 테스트 해야 하는지 정리

- 현업 TFT에서 일정 조정, 개발팀에서 문서 받고 피드백 (기능과 관련없는 보안기능 등도 같이 진행)

테스트 시나리오 배포

- 테스트 기간을 주고 현업이 각자 업무를 하면서 테스트

- 특정 장소에 모여서 다같이 전체 기능에 대한 테스트

- 현업 TFT 중심 테스트, 현업 업무 담당자 중심 테스트

- 테스트 방식은 프로젝트 종류 및 고객사의 상황에 따라 각양 각색

- 테스트 단계는 현업의 지원이 절대적 중요, 가능한 다수의 다양한 테스트를 요청할 것 (테스트 대충하고 배포 후 처지면 낭패)

 

테스트 시나리오 작성(단위테스트, 총합테스트)

  • 테스트 케이스 기반으로 실제 테스트 시나리오 명세
  • 단위는 간단한 기능 검증, 통합은 전체 프로세스 수행 검증 (실데이터)

단위 테스트-보완

  • 개발 기능에 대한 검증 테스트
  • 테스트 후 오류 수정 및 보완 작업 수행

- 앞 뒤의 상관 관계가 아닌 각 단위 화면의 기능에 대한 테스트 (기능 하나하나만 테스트)

 

통합테스트-보완

  • 전체 서비스 프로세스에 대한 통합 테스트 후 오류 수정 및 보완
  • 최대한 실제 운영환경에 맞춰, 실데이터, 실 유저 환경으로 진행

- 각 단위별로 만들어진 기능을 업무 프로세스에 따라 테스트

오픈 안정화

사전 교육

  • 메뉴얼 작성 및 배포
  • 각 메뉴얼에 대한 실제 사용자 교육 (B2C의 경우 간편 메뉴얼)

- 메뉴얼을 미리 준비한 경우도 있고 개발을 마친 후 개발된 거에 맞게 메뉴얼을 만드는 경우도 있음

 

오픈 준비

  • 실제 오픈을 위한 오픈 시나리오 준비
  • 데이터 전환 계획, 배포 게획(웹/앱), 이행 계획 등

- 테스트하는 동안 들어간 데이터 정리 등

오픈

  • 오픈 직전 완료 보고 혹은 안정화 이후 완료 보고 (고객사에 따라 다름)
  • 서비스 운영 오픈

안정화

  • 서비스 오픈 후 안정화 될 때 까지, 안정화 지원
  • 안정화 기간 동안 오류 수정 및 기능 보완 수행
  • 프로젝트 완료 검수

'PM' 카테고리의 다른 글

IT 용어 (보고)  (0) 2024.02.22
IT 용어 (계획)  (0) 2024.02.21
IT 용어 (고객2)  (1) 2024.02.21
IT용어 (고객 1)  (0) 2024.02.20
IT 용어 (사업)  (0) 2024.02.20

관련글 더보기