본문 바로가기

카테고리 없음

Ch 07. 프로젝트 관리 방법

프로젝트 우선 순위 설정1

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

  1. 조직 우선순위의 불안정성 - 39%
  2. 프로젝트 방향성의 불안정성 - 37%
  3. 정확치 않은 커뮤니케이션 - 29%
  4. 확실치 않은 리스크 관리 - 29%
  5. 매니저의 경험 미숙 - 22%
  6. 팀 멤버의 역량 부족 - 13%
  7. 리소스 부족- 12%

조직의 리소스는 한정되어 있으며 모든 요구사항을 반영하는 것은 어려움

서비스 기획자는 명확한 우선순위를 설정하고 그에 따라 프로젝트를 진행해야 함

프로젝트의 우선순위는 무엇인가?

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

프로젝트 우선 순위 설정2

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

프로젝트 우선순위를 결정할 때 고려해야 할 사항

  • 서비스 컨셉 - 킬러피처, 핵심 기능
  • 일정 - 프로젝트 task 관리
  • 리소스

MoSCoW 방법론

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

  • Must haveM에 해당하는 기능을 포함하지 않은 경우에도 제품 혹은 서비스의 성공이 상상 불가능한 케이스
  • 이 기능 혹은 제품이 사용자들에게 약속되어 잇거나 킬러 피처인 경우 이에 해당
  • Should Have하지만 필수 기능으로 포함되지 않은 케이스가 이에 해당함
  • 높은 우선순위의 기능 혹은 제품
  • Could Have충분한 리소스가 배정된 경우 시도가 가능하지만 없더라도 제품 혹은 서비스의 성공여부에 큰 영향을 끼치지 않음
  • 있으면 좋은 정도의 기능 혹은 제품
  • Won`t Have
  • 당장 필수로 포함될 필요가 없는 기능 혹은 제품

워킹 스켈레톤 방법론

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

  • 사용자 스토리에 순위 책정 필요
  • 완전하게 동작하는 제품의 형태를 갖고 있어야 함
  • 비즈니스 가치를 충분히 내포해야 함
  • 완전 초기 단계의 스타트업이나 제품에서 사용하는 방법론

RICE 방법론

우선순위 설정을 위한 등급 점수 모델을 사용하는 기법

  • Reach (도달범위)주로 DAU/MAU 등 사용자 지표를 활용
  • 특정 기간 동안 이 기능을 사용할 수 있는 사용자 수를 반영
  • Impact (영향력)매우 높은 영향력 - 3점, 높음 - 2점, 중간 - 1점, 낮음 - 0.5, 최소 - 0.25점
  • 절대 기준을 제공하지 않으며 상대적인 점수를 책정
  • Confidence (신뢰도)높은 신뢰도 - 80, 낮은 신뢰도 - 50
  • 구현하고자 하는 기능이 얼만큼 사용자에게 혜택을 줄 수 있는지에 대한 추정값
  • Effort (노력)
  • 각 담당자의 리소스 소요 시간을 나타냄

RICE Score = Reach * Impact * Confidence / Effort

프로젝트 프로세스의 관리

프로젝트 프로세스 관리 요소

  1. 요구사항 정리 - 상위 기획서 작성
  2. 개발 필요사항 정리 - 백로그 작성
  3. 리소스 산정 - WBS 작성
  4. 프로젝트 운영 - 간트차트 작성

백로그 (Back log)

제품 및 서비스 구현에 필요한 요구사항 및 예상 소요 비용을 산정하는 단계

백로그 예시

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

  • WBS (Work Breakdown Structure)

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

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

WBS 예시

  • Depth

제품 구현 단위

  • Jira

해당 페이지 구현 요청 내역

  • 기획서 페이지

상세 기획서 내 해당 내용이 기술된 페이지

  • 담당자

해당 스펙 담당자

간트 차트 (Gantt Chart)

업무 일정의 시작과 끝을 바(Bar) 형태의 그래프로 표기하여 전체 일정을 한눈에 볼 수 있게 만든 차트 WBS에서 작성된 워크패키지를 기준으로 일정 산정 및 관리

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

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

커뮤니케이션

수직적 커뮤니케이션

주요 대상 : 상위 의사결정권자

주요 문서 : 상위 기획서

목적 :

  • 서비스 방향성 결정
  • 서비스 성공 여부 진단
  • 조직간 이슈 보고

상위 기획서

  • 현황 분석 & 동기부여
  • 현 시장상황 분석 및 제품 및 서비스의 구현방향 기술
  • 목표
  • KPI를 기준으로 구현하고자 하는 서비스의 목표 기술
  • 유저 시나리오
  • 페르소나를 설정하고 해당 유저의 사용동선 기술

수평적 커뮤니케이션

주요 대상 : 실무자

주요 문서 :

  • 상세 기획서
    • IA : 구현하고자 하는 서비스 혹은 제품의 전체 설계도
    • 와이어프레임 설계 : 서비스 및 제품의 사용자 동선을 고려한 UX 시안 정리
    • 스펙 상세 : 구현하고자 하는 서비스 혹은 제품의 상세 스펙을 정의
  • 일정 관리
    • 간트 차트 관리 : 구현하고자 하는 서비스 혹은 제품의 상세 스펙을 정의

목적 :

  • 서비스 구현내역
  • 프로젝트 관련 이슈 발견
  • 제품 출시 및 성과 측정

외부 커뮤니케이션

주요 대상 : 고객

주요 문서 :

  • 제품 소개서
  • 이용 가이드
  • 공지사항

목적 :

  • 제품 사용 방법 전달
  • CS 접수

주요 업무 내용

  • 제품 홍보 페이지
    • 제품 특징 : 제공하는 제품 및 서비스와 타 서비스의 차별성 혹은 장점 제시
    • 이용 가이드 : 제품 설명 및 이용 방법에 대한 가이드 제시
  • 고객 관리
    • 고객센터 운영 : 고객의 문의사항에 대한 대응 가이드 작성 및 제시
    • 공지사항 : 신규 제품 출시 혹은 업데이트 시 고객에게 공지
  • 리서치
    • 사용자 분석 : 기존 고객의 사용 데이터를 추출하고 분석하여 개선점 도출

커뮤니케이션을 위한 용어정리1

Production Team 커뮤니케이션

UX 요소

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

커뮤니케이션을 위한 용어정리2

개발 요소

API (Application Programming Interface)

서버와 데이터베이스의 출입구 역할을 하며 허용된 인원에 대하여 데이터베이스에 접근할 수 있는 권한과 활용에 대한 권한을 부여함

  • Private API
  • Public API
  • Partner API

Application

사용자가 서비스 혹은 제품을 사용하기 위해 제공되는 형태

  • 네이티브 앱
  • 웹 앱
  • 하이브리드 앱

Json (JavaScript Object Notification)

HTTP 요청에서 사용되는 데이터 형식

Cookie

클라이언트 로컬에 저장되는 데이터 파일이며 일정 시간동안만 사용자의 클라이언트에 해당 데이터를 저장

  • 저장 공간 : 로컬 DB
  • 만료 시간 : 설정 가능

Session

쿠키를 기반으로 하지만 사용자 정보를 서버에서 관리하며 브라우저를 통해 웹 서버에 접근한 시점으로부터 종료시점까지 유지

  • 저장 공간 : 서버
  • 만료 시간 : 설정 가능하나 브라우저 종료 시 세션 종료

프로젝트 완료 후

서비스 운영

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

업무 CS 응대 개발 관리 데이터 분석 어드민 기획

  • 서비스 정책 기획
  • 파트너사 관리 | - 서비스 업데이트 버전 관리
  • 장애 대응
  • 고객 문의 확인 | - 데이터 추출
  • 데이터 분석
  • 대시보드 기획 | - 운영팀 요청사항 반영
  • 어드민 관리 |

어드민 기획

서비스 운영에 필요한 기능을 추가한 페이지로 주로 권한관리, 매출관리, 통계 등의 기능을 지닌다.

프로젝트 회고

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

  • KPT 회고 방법론

팀원들의 의견을 Keep/Problem/Try로 카테고리화하여 명시함으로써 프로젝트 회고를 진행하는 방법

Keep : 프로젝트 진행 시에 좋았던, 잘했던 부분이며 다음 차수에도 유지되어야 하는 부분

Problem : 프로젝트 진행 시에 잘 되지 않은, 못했던 부분이며 다음 차수에도 개선되어야 하는 부분

Try : Problem에서 확인된 내용을 개선하기 위해 취할 수 있는 액션

예시)

Keep

  • 주기적 코드리뷰를 통해 버그 발생률이 감소했다.
  • 새로 도입한 툴 덕분에 디자인 가이드라인 전달이 편리해졌다.
  • TC 작성 시 서비스 기획자 참여로 소요기간이 단축되었다.

Problem

  • 변경 스펙에 대한 공유가 늦어져서 업무량이 증가했다.
  • 고객센터 교육이 너무 늦게 시작되어 서비스 숙지 기간이 짧았다.
  • API 공유 시점이 늦어져서 후반에 프론트 작업에 부하가 걸렸다.

Try

  • 변경 스펙이 발생할 때마다 공유하는건 스케쥴 관리상 어려움으로, 주간 스크럼 일정을 별도로 설정하여 변경 및 이슈사항을 공유한다.
  • 고객센터 교육을 위한 일정을 별도로 설정한다.

학습 회고

- 프로젝트 관리 방법론에 대해서 학습.
- 관리 대상 문서가 상당히 많을 것으로 예상됨. 
- 프로젝트 회고 문화에 대해서도 중요성을 인식 -> 다양한 피드백 방법론에 대해서 학습해보자