[Chapter 07] 프로젝트 관리 방법

1️⃣ 프로젝트 우선순위 결정

🔷 프로젝트는 왜 실패하는가?

🅰 조직 우선순위의 불안정성

한정된 리소스 안에서 모든 요구사항을 반영하기 어렵기때문에 불안하고 불명확한 우선순위는 실패할 확률이 높임.

🅱프로젝트 방향성의 불안정성 

서비스의 방향성이 매일 변경이 된다면 제품의 퀄리티가 낮아 지며, 이도저도 아닌 서비스가 나올 확률이 높음

서비스 기획자는 중간 관리자로서 상위 매니저/경영진들과 지속적인 커뮤니케이션을 통해, 프로덕션 팀에 정당한 요구사항이나 고객들의 목소리를 지속적으로 전달하므로써 정확한 방향성/우선순위를 가지고 프로젝트 진행

즉, 프로젝트를 성공적으로 이끄려면 방향성과 우선순의를 변경할 만한 이유가 없다면 명확한 근거, 이유, 사유를 가지고 "NO"를 외칠 수 있어야함!

 

🔷 프로젝트의 우선순위란?

서비스의 컨셉을 구현하는데 가장 필요한 기능을 기준으로 우선순위가 설정되야함!

킬러 피쳐 : 서비스의 방향성을 결정짓는 것

서비스 컨셉 : 킬러피처로 정의하고자 하는 것

 

🔷 프로젝트 우선순위 설정기법

❗ 고려사항

1. 서비스 컨셉
   • 컨셉에 맞는 킬러피쳐는 무엇인가?
2. 서비스 일정
3. 가용가능한 리소스

🔵 MoSCoW 방법론

애자일 프로덕트 관리방법에서 중요한것과 그렇지 않는 것을 구별하기 위한 기법

인스타그램 예시

용어	간단힌 정의	예시
Must Have	서비스의 킬러 피쳐	이미지 업로드 및 공유 기능
Should Have	킬러 피쳐는 아니지만 우선순위가 높은 케이스	이미지 필터 기능
Could Have	있으면 좋은 기능	스토리
Won't Have	당장은 필수가 아닌 기능	샵 기능

• 계속해서 우선순위가 변경
• 제일 많이 쓰이는 방법론
• C, W가 구분하기 어렵다면 사용자의 입장에서 제품의 메리트를 고민해야 함.

 

🔵 Walking Skeleton 방법론

구현하고자 하는 기능 혹은 서비스의 PoC(Proof of Concept) 버젼이며 주로 MVP의 우선순위를 정의하는데 사용되는 기법

• 사용자 스토리에 순위 책정필요. 
  1. 사용자가 어떤 플로우에 의해 어떤 기능을 사용할지 플로우를 그려봄(IA와 유사)
  2. 우선순위 측정
  3. 낮은 우선순위는 잘라냄
  4. 높는 우선순위 중에서도 컨셉을 증명할 수있는 꼭 필요한 기능만 남기고 모두 제거
• 완전하게 동작하는 제품의 형태를 갖고 있어야함.
• 비즈니스 가치를 내포해야함.

 

🔵 RICE 방법론

우선순위 설정을 위한 등급 점수 모델을 사용하여 높은 순대로 우선순위를 결정하는 기법

점수 모델을 사용하여 좀더 객관적인 판단이 가능

• MoSCoW와 함께 가장 많이 쓰이는 방법론
• 상대적으로 객관적인 평가 가능
  • Impact는 주관적인 평가가 들어감
• 계산해야할 것이 너무 많으면 비효율적이라 대형 프로젝트에선 선호되지 않음
• 소규모에서 일정이나 리소스가 많이 부족하여 필요하다 생각될 경우 자주 사용

 

---

2️⃣ 프로젝트 프로세스 관리

🔷 요구사항 정리

상위기획서

상위 매니저와 경영진에서 앞으로 이런 방향성의 제품을 만들어야 되고 서비스의 역할과 프로젝트 진행 계획대한 설계도

 

🔷 개발 필요사항 정리

서비스의 구현에 필요한 요구사항 및 예산 비용을 선정하는 단계

🔵 백로그 

서비스의 스펙 리스트 정리한 내용

서비스에 방향성에 부합하는 결과물을 만들기 위한 To-Do list

 

🅰 작성 단계

1. 상위매니저와 상위 기획서에서 합의된 서비스의 요구사항을 정리하여 1차 백로그 작성
2. 1차 백로그를 가지고 피드백을 수도 없이 받으며 스크리닝 작업을 함
   1. 스펙변경
   2. 개발, 디자인팀에게 리뷰(최대한 상세히하여 정확한 피드백을 받자)
   3. 비용산정
   4. 상위매니저와의 의사결정
3. 백로그 최종본을 리뷰 후 검토
4. 개발 준비(비용산정, 담당자 지정 등이 포함)
5. 담당자들과 일정을 산정하여 초안 작성

🅱 구성요소

구성요소	정의	예시 유튜브
ID	각 스토리를 분류하기위한 순번	1
분류	페이지 뎁스 구분	구독탭
사용자 스토리	사용자가 제품을 이용하는 케이스	사용자는 구독한 채널의 신규 동영산 업로드 알림을 받을 수 있다
제약사항	사용자 스토리에 대한 예외케이스	알림설정을 off한 케이스
상세	스토리에 서술된 내용을 구현하기 위해 필요한 작업 내용	신규 동영상 업로드 체널 표기 동영상 최신순으로 내림차순 정렬
우선순위	각 스토리의 구현 우선순위	1

 

🔷 리소스 산정

🔵 WBS(Work Breakdown Structure)

프로젝트의 범위와 최종산출물 기준으로 세부요소로 분할하는 문서

 

🅰 얻고자 하는 정보

프로젝트 수행을 위한 업무 식별	프로젝트 구현을 위한 작업단위를 세분화 함으로서 업무 식별 가능 이를 통해 누락된 작업으로 인한 불필요한 비용지출 예방
일정 계획 및 산정	직부 할당표를 상정함으로서 담당자 식별 용이 및 작업 세분화에 따른 일정소요기간 수집 용이
팀 간 의사소통	각 할당 작업분야를 벗어나 전체 작업범위를 공유함으로서 서비스 구현에 대한 방향성 공유 및 진행상황 공유 용이

 

🅱 구성요소

구성요소	정의
Depth	제품 구현 단위
Jira	해당 페이지 구현 요청내역
기획서 페이지	상세 기획서 내 해당 내용이 기술된 페이지
담당자	해당 스펙 담당자

 

🔷 프로젝트 운영

🔵 간트 차트(Gantt Chart)

업무 일정의 시작-끝을 Bar 형태의 그래프로 표기하여 전체 일정을 한눈에 볼 수 있게 만드는 차트

WBS에서 작성된 워크페이지 기준으로 일정 산정 관리

프로젝트 관리	전체 일정을 한눈에 볼 수 있게 함으로 팀 맴버간 협업 증진 개발 일정 병목원인 확인 용이
간트 차트 작성 툴	내부에 사용하는 프로젝트 관리 툴의 경우 간트 차트를 제공하고 있으며, 각 워크패키지를 등록하는 과정에서 자연스럽게 간트 차트가 생성됨(Jira Plans)

 

---

3️⃣ 프로젝트 진행을 위한 커뮤니케이션

 

서비스 기획자는 프로젝트 내 모든 커뮤니케이션의 중심

조직 내/외부	커뮤니케이션 상대			주요 문서
External-Comunication	조직 외에서의 커뮤니케이션 고객, 파트너			✔ 제품 홍보 페이지 - 제품 특징 : 타 서비스와의 차별점 장점 제시 - 이용가이드 : 제품 설명 및 이용 가이드 제시 ✔ 고객관리 - 고객센터 운영 : 문의사항 대응 가이드 제시 - 공지사항 : 고객에게 신제품 출시/업데이트 공지 ✔리서치 - 사용자 분석 : 기존 고객의 사용 데이터를 추출하고 분석하여 개선점 도출
Inner-Comunication	조직 내에서의 커뮤니케이션
	수직적 커뮤니케이션	상위매니저		✔ 상위 기획서 - 시장 현황 분석 서비스의 구현방향 기술 - KPI 기준으로 구현하고자 하는 서비스 목표 - 페르소나 유저의 사용 동선 ✔ 서비스 구현 방향 변경 ✔ 조직간의 이슈 보고
	수평적 커뮤니케이션	Production	디자인팀 개발팀	✔ 상세 기획서 - IA : 서비스의 전체 설계도 - 와이어프레임 설계 : 사용자 동선을 고려한 UX 시안 정리 - 스펙 상세 : 서비스의 스펙 정리 ✔ 일정 관리 - 간트 차트 관리 : 서비스 상세 스펙 정의 ✔ 사용자 요구사항 청취
		Support	사업팀 운영팀

 

---

4️⃣ 프로젝트 커뮤니케이션 용어정리 

프로덕트 팀은 각 팀별로 전문적인 영역을 다르고 있기때문에 용어를 잘 알고있어야 커뮤니케이션 비용을 줄일 수 있음.

프로젝트에서 자주 사용하는 용어는 통일하고 가는것이 프로젝트 진행에 용이

🔷 UX용어

용어	의미
드롭다운 리스트	화살표를 누르면 숨어있던 항목들이 아래로 펼쳐지머 원하는 항목을 선택할 수 있는 요소
콤보 박스	입력 필드에 직접 정보를 입력하거나 나열된 항목 중 하나를 선택할 수 있도록 하는 요소 입력하기 좋은 대부분 숫자 요소에 사용
버튼	active	클릭 가능한 버튼이며 아직 클릭상태 전
	hover	마우스가 올라가 있을 때 (= mouse over)
	click	클릭할때
라디오 버튼	선택 옵션 중 하나의 항목만 선택할 수 있도록 하는 요소
체크박스	동시에 여러 개를 선택할 수 있도록하는 요소 회원가입시, 관심사
입력 필드	직접 텍스트를 입력하는 역역(= 텍스트 상자)
토글 버튼	여러개의 옵션 중 하나의 선택지만 가능한 옵션 중 버튼형태로 제공
토글 스위치	주로 모바일사용 토글 버튼과 동일한 요소이나, 양자택일 형태로 제공 on/off 버튼
스피너	직접 입력하거나 필드 옆 화살표를 눌러 값을 조절
슬라이더	최소값, 최대값을 시각적으로 인지하며 드래그를 통해 값 조절 화면 밝기, 음량 등에 사용
프로그레스바	시각적으로 진행상황을 보여주는 요소 게임 로딩창, 성취률을 보여줄때 사용
툴팁	마우스 오버 시 해당영역에 대한 설명이 말풍선 형태로 나타나고 사라짐
노티피케이션	사용자가 확인하지 않은 정보가 있는 경우 아이콘 형식으로 알려주는 알림(= 노티)
얼럿	무언가를 진행하기 전 확인이나 승인을 필요로 하는 상황을 사용자에게 알려주는 창 사용자의 실수를 방지하는 역할
팟업	사용자로부터 단일 선택을 요구하는 대화상자의 가벼운 형태의 창

 

🔷 개발 용어

용어	의미
API	서버와 데이터베이스의 출입구 역할을 하며 허용된 인원에 대하여 데이터베이스에 접근/활용 권한 부여함
	Private API	주로 사내에서 사용되는 API 자체제품과 서비스 개선을 위해 발행되며, 제 3에게는 노출되지 않음
	Public API	개방형 API로 모두에게 공개됨. 누구에게나 제한 없이 API 호출이 가능함.
	Partner API	데이터 공유에 동의하는 특정인들만 사용하는 API. 비즈니스 파트너 간 소프트웨어 통합하기 위해 사용됨.
Application	사용자가 서비스를 사용하기 위해 제공되는 형태
	네이티브 앱	스마트폰 운영체제에 맞춰 개발된 프로그램. goolge playstore, apple appstore 정책에 맞춰 개발.
	웹 앱	링크를 통해 접근이 가능하며 웹브라우저를 통해 접근 가능
	하이브리드 앱	네이티브 안정성 + 웹 유연성  기본 틀을 네이티브로 구현하되 특정 영역에 대해서 웹 브라우저를 통해 웹앱으로 노출
Json	HTTP 요청에서 사용되는 데이터 형식 클라이언트와 서버 통신에 양식에서 제일 많은 쓰는 형태
Cookie	클라이언트 로컬에 저장괴는 데이터 파일로 일정 시간동안만 사용자의 클라이언트에 해당 데이터를 저장. 저장공간 : 로컬DB, 만료시간 : 설정 가능 자동 로그인
Session	쿠키를 기반으로하지만, 사용자정보를 서버에서 관리하여 브라우저를 통해 웹서버에 접근하는 시점부터 종료시점까지 유지 저장공간: 서버,만료시간 : 설정 가능하나 브라우저 종료시 세션 종료 자동 로그아웃

 

---

5️⃣ 프로젝트 완료 후

🔷 서비스 운영

고객이 서비스를 사용함에 있어 사용성을 파악하고 개선사항에 대한 대응을 하는 업무

업무	주요 협업 대상	업무 내용
CS 응대	사업팀 운영팀	- 고객의 요청사항에 대한 답변 : 사업팀은 파느너사, 운영팀은 개인고객 - 서비스 정책 기획 :  정책 관리 및 공지사항 업데이트 - 파트너사 관리 : 파트너사의 커스터마이징 요청사항 대응
개발 관리	개발팀	- 서비스 업데이트 버전 관리 : 버그, 파트너 요청사항에대한 서비스 업데이트 및 버전 관리 등을 통한 사용성 개선 - 장애 대응 - 고객 문의 확인
데이터 분석	개발팀	- 데이터 추출 - 데이터 분석 - 대시보드 기획 : 주로 어드민 페이지에 추가, 현서비스의 상태를 숫자/지표로 제공
어드민 기획	운영팀 개발팀	서비스 운영에 필요한 기능을 추가한 페이지로 주로 권한관리, 매출관리, 통계의 기능 내부 개발이기때문에 필요에따라 지속적으로 점진적 업데이트가 필요 실제 고객을 만나는 운영팀, 사업팀과 고객의 사용성을 제대로 확인하고 사용자적 요구사항들을 방영하기위해 업데이트 - 운영팀 요청사항 반영 - 어드민 관리

 

🔷 프로젝트 회고

프로젝트의 참여자 전원가 함께 진행하면서 겪은 본인의 소감 및 개선필요사항 등을 공유함으로서 다음 차수 프로젝트 프로세스 개선을 이루어내는 과정

🔵 KPT회고 방법론

Keep	프로젝트 진행시에 좋았던 부분이며 다음 차수에도 유지되어야 하는 부분
Problem	프로젝트 진행시에 잘 되지 못했던 부분이며 다음 차수엔 개선되야야하는 부분
Try	Problem 내용을 개선하기 위해서 취할 수 있는 액션