IT 프로젝트 관리 이해 2

< IT 프로젝트 주요보고 >

IT 프로젝트 관리 과정에서 가장 중요한 것 중에 하나가 보고이다.

보고의 종류       # 참석 대상에 따라 보고 종류가 구분 된다!

1. 정기보고: 진척을 위한 정규적인 보고

- 주간보고: 보통 TFT멤버 참석

- 월간보고: TFT멤버 + 프로젝트 이해관계자

2. 비정기보고: 문제상황으로 인한 수시 보고

- 이슈 및 위험 관리 보고: 주간/월간 보고를 통해 이미 관리되던 이슈나 위험요소가 심각할 경우 별도 보고를 진행하여 문제 해결

▪ 기본적으로 보고(회의) 자체가 해결을 위한 명확한 주제가 있음

▪ 반드시 사전에 문제에 대한 내용을 정리하여 참석자들에게 사전 공유하는 것이 중요함

3. 주요보고: 전체 관계자들에게 하는 주요 보고

- 착수보고:

▪ 프로젝트 시작 시, 수행사 PM이 사업과 관련된 고객사 전원에게 진행하는 보고

▪ 사업의 개요 설명을 통해 이런 사업이 진행되고 있고, 이런 개발이 될 것인데, 이런 일정으로 될 것이며, 이때 여러분들은 이런 것을 도와줘야 합니다.

▪ 제안 발표 자료를 토대로 만드는 게 좋음

# 다양한 이해관계자들이 참석하기 때문에 프로젝트 및 역할을 설명하는 목적이 큼

- 중간보고:

▪ 프로젝트 중간에, 수행사 PM이 사업과 관련된 고객사 전원에게 진행하는 보고 (통상 분석 설계 단계 이후, 본격적 개발 시작 시점)

▪ 착수보고를 통해 진행된 사업이 어떠한 상황 (진행의 안정성)으로 되고 있으며, 여러분과 협의를 통해 어떻게 진행되고 있음을 공유합니다.

- 종료보고:                 # 중요도가 떨어짐

▪ 프로젝트 종료 시점에, 수행사 PM이 사업과 관련된 고객사 전원에게 진행하는 보고

(통상 시스템 오픈 전, 상황에 따라서 오픈 안정화 후)

▪ 전체 프로젝트가 어떠한 일정과 협의를 통해 진행되었으며, 최종적으로 어떠한 결과로 진행되었는지 보고 드립니다.

 

주간보고 작성방법

왼쪽 부분은 기본 내용, 오른쪽 부분까지 상세하게 적는 걸 추천!

 

착수 보고 작성 방법

1. 프로젝트 개요: 추진 배경, 시스템 개요, 도입 이점 등

2. 프로젝트 구축 범위: 시스템 구성, 주요 개발 내용, 개발 방법 등

3. 프로젝트 관리 방안: 보고 및 회의, 품질보증, 교육계획 등

4. 프로젝트 추진 계획: 진행 조직, 진행 일정, 투입인력, 기타 사항 등

- 참석자들의 역할, 지원 일정, 지원 필요 내용 공유 (구체적으로 작성)

 

중간 보고 작성 방법

목적은 현재 진행이 원활히 잘 되고 있는지에 대한 중간 공유

1. 프로젝트 진행 상황: 계획일정, 현재 단계, 진행 상태(원활, 이상 등)

2. 프로젝트 구축 내용: 시스템 구성, 주요 개발 내용, 개발 방법, 주요 이슈 등

- 착수보고=계획: “전자 계약을 잘 하려고 계획 중입니다.”

- 중간보고=결과: “판매계약은 모바일 및 PC로, 매입 계약은 모바일로만 진행중입니다.”

3. 이후 진행 계획: 잔여 진행 일정에 대한 계획 및 이후 고객사 담당자들의 역할

 

종료 보고 작성 방법

구축된 구체적인 결과 보고 (고객사 상황에 따라서 자유롭게 조절)

참고로 시스템 구축의 결과에 따라 보고의 느낌이 달라짐 (실패 시 생략될 수도…)

1. 프로젝트 개요: 추진 배경, 시스템 개요, 도입 이점 등

2. 프로젝트 구축 범위: 시스템 구성, 주요 개발 내용, 개발 방법 등

3. 프로젝트 관리 방안: 보고 및 회의, 품질보증, 교육계획 등

4. 프로젝트 추진 계획: 진행 조직, 진행 일정, 투입인력, 기타 사항 등

 

주요 보고의 핵심

1. 보고할 내용에 대한 사전 공유

2. 보고 및 협의 후 결과를 상세히 정리

3. 정리된 결과를 반드시 공유 확인

 

 

< 요구사항 분석단계 관리 >

▪ 고객으로부터 개발할 시스템의 기능 요구 사항을 듣고, 분석하는 것

▪ TFT팀끼리만 분석하면 안됨!

→ 먼저 요구사항 의견을 내고, 검토/승인할 업무 담당자 정의(승인) 필요

▪ SI/웹에이전시 프로젝트 : 요구사항 분석서(고객의 요구사항을 처음부터 듣고 진행)

# 보통 SI와 웹이전시는 협업을 함(개발자<->디자이너)

▪ 솔루션 : GAP 분석서(이미 존재하는 시스템의 일부만 커스터마이징 개발)

시장에 따른 요구사항 분석

1. 프로젝트형 개발

▪ 고객: 고객사 직원 → 요구사항 분석 미팅

2. 프로덕트형 개발

▪ 고객: 타겟화, 비대면 고객 → 팀내 분석 회의(데이터기반, 문제정의)

3. 기술 개발

▪ 내부 기술 리더 → 기술 리더의 요구

 

요구사항 분석 단계 이해관계자 종류

프로젝트 개발에서 이해관계자는 다양한 관점의 다양한 사람이 있음

그중 가장 중요한 이해관계자 종류 중 하나가 요구사항을 분석 정의하는 이해관계자임

1. 관리자 그룹 (TFT멤버)

▪ 시스템 구축 중심 멤버

▪ 구체적인 설계 가능한 상세 요구 사항 확인

▪ 전체적인 시스템의 기능 설계 정보 획득

2. 사용자 그룹 (현업자) – 자기 입장에서 유리한 의견을 낼 확률 높음 주의

▪ 구축 시스템 이용자 그룹

▪ 시스템에 핵심 요구 사항 확인

▪ 개별 기능 중 사용자 편의-중요 사항 검토

3. 정책 수렴 그룹 (법무팀, 전략기획팀 등)

▪ 정책 검토 그룹

▪ 구축 시스템 관련 정책 및 법률적 검토

4. 의사 결정 그룹 (팀장, 부장, 임원)

▪ 고객사 의사 결정 담당자

▪ 취합 분석된 요구사항 정리 및 보고 방식

▪ 요구 사항 및 이슈 사항에 대한 의사결정

이해관계자 분석 작성법

가장 먼저 그룹 역할 부분에 이해관계자의 종류를 고객과 협의하여 확정함

확정된 이해 관계자 및 해당 관리 정보를 아래와 같이 상세 작성

1.     담당자 지정

▪ 역할만 정의 하는 것이 아니라, 실제 그 업무를 진행할 담당자를 상세 정의해야 함

▪ 주관(고객)측과 수행 측 모두 부서, 이름까지

2.     역할 작성

▪ 역할 컬럼에 실제 그 이해관계자가 해야 할 역할을 상세하게 적음

(예시는 화면 크기 문제로 역할 컬럼 좁지만, 실제로 넓게 상세하게)

3.     요구사항 분석 진행 방식

▪ 각각의 이해관계자와 요구사항을 분석할 방법(대면/비대면 등)과 시점(가능한 정확한 일시)을 정리함

4.     비고

▪ 비고란은 필요에 따라 작성하면 되지만, 기본적으로 최종 요구사항에 대한 의사결정 확인을 받는 방법을 작성하면 유용함

 

요구사항 분석 개념

요구사항 정의와 분석은 다른 개념!!

-      요구사항 정의: 보통 RFP에 뭘 만들지 적은 것.

-      요구사항 분석: 요구사항 분석서에 고객의 상세한 기능 요구사항을 적은 것. (gap 협의)

n  요구사항이 단순할 때는 엑셀과 같은 간단한 양식 복잡할 때는 PPT와 같은 상세 정보 작성 가능 양식 (도구는 다양함 프로젝트 관리도구, 노션 등)

실제 IT 현장에서 고객이 RFP에 정확한 요구사항을 작성하지 않는 경우 요구사항정의서/분석서를 큰 분리 없이 쓰기도 함

 

요구사항 분석 관리 핵심

-      요구사항 분석 단계는 제일 중요한 단계 (요구사항 분석 → 기초 설계 → 개발)

-      고객으로부터 받은 요구사항은 정리 후 반드시 공유 및 확인

-      정리된 요구사항은 향후 검수 시 기준이 되므로 잘 관리

-      공공은 별도 요구 사항 추적표 관리, 민간은 규모에 따라서 다름

< 설계단계 관리 >

IT 설계단계 순서

→ 요구사항 분석이 끝나고 나면, 실제 해당 요구사항을 개발이 가능하도록 설계하는 과정을 설계단계라고 합니다. (4가지 단계로 진행.)

1.     구조 정의(IA)

▪ 고객의 요구사항을 분석하고, 이 내용을 시스템으로 만들 수 있도록 그 구조를 설계

▪ 간단하게 생각하면 메뉴 구조로 이해

2.     화면 설계(SB)

▪ IA에 정의된 전체 기능 및 화면에 대한 상세 설계를 진행

3.     설계 검토

▪ 설계의 과정이 완료되면, 해당 내용이 고객이 원하는 대로 잘 만들어 되었는지 검토

4.     설계 확정

▪ 설계 검토 이후 설계를 수정하는 과정을 반복해서 최종적으로 고객이 원하는 설계

확정

▪ 확정된 내용에 대한 협의 결과 남김

 

IA 개념

→ IA(Information Architecture, 정보구조도)는 시스템의 구조를 설계하는 것으로, 시스템의 메뉴 구조와 기능을 정의한 뼈대 문서

→ IA 작성법은 다양함

-      SI/솔루션 사업: IA를 작성하지 않고 프로그램 리스트, 명세서, 설계서 등 다수의 개발 중심의 문서로 작업 관리

-      웹에이전시: IA를 통해 설계의 기반을 구축

 

스토리보드(SB, Storyboard) 개념

→ IA 혹은 메뉴구조도 정리 후 실제 개발될 화면의 UI/UX와 기능 명세를 상세하게 설계한 문서

→ 일반적으로 PM이 직접 작성하지는 않고 업무를 맡은 기획자나 개발PL이 작성

→ SB, 스토리보드, 화면설계서, 사용자 인터페이스 설계서 등 동일한 작업에 대해 상당히 다양한 문서의 이름으로 불리움

→ PM은 기본적으로 문서를 보고 이해하고, 의사결정

 

설계 단계 PM 역할

IA 및 스토리보드는 꼭 필요

단, 회사마다, 개발 종류마다, 규모마다 이름도, 작성법도 조금씩 다름

해당 작업의 컨셉을 이해하고 상황에 맞춰 적용

PM은 직접 작성이 아닌 검토. PM이 기획 혹은 설계 겸업 시 직접 작업