[제로베이스 PM스쿨 18기 학습일지 #07] Ch 07. 프로젝트 관리 방법

강지영·2023년 9월 17일
0

PM 학습 일지

목록 보기
6/26

프로젝트 우선순위 설정

😥 프로젝트는 왜 실패할까요?

  • 조직 우선 순위의 불안정성 (39%)
  • 프로젝트 방향성의 불안정성 (37 %)
  • 정확치 않은 커뮤니케이션 (29%) etc...
    ⇨ 조직의 리소스는 한정되어 있으며 모든 요구사항을 반영하는 것을 어려움
    서비스 기획자는 명확한 우선순위를 설정하고 그에 따라 프로젝트를 진행해야 한다

🔥프로젝트의 우선순위는
제품 혹은 서비스의 컨셉을 구현하는 데 가장 필요한 기능(킬러 피처)을 기준으로 우선순위가 설정되어야 한다!

  • ex)
    카카오톡 > 사용자간 커뮤니케이션 서비스 - 메시지 전송 기능
    인스타그램 > 이미지 공유 서비스 - 이미지 업로드
    에어비앤비 > 숙박 예약 서비스 - 숙소 예약
    넷플릭스 > OTT 서비스 - 영상 재생

❗우선순위 선정 시, 고려해야 하는 것❗

1. 서비스 컨셉
서비스의 방향성을 정하는 것이 킬러피처이고, 킬러 피처를 통해서 정의하고자 하는 것이 서비스 컨셉이기때문에 이 킬러피처를 무엇으로 생각하느냐에 따라서 서비스 컨셉, 방향성이 달라진다
2. 일정
모든 프로젝트는 무한정 끌어갈 수 없기 때문에 데드라인이 정해져 있다
일정 안에 제품, 기능 혹은 서비스를 제공/만들어 내야 한다
3. 가용 가능한 리소스
리소스 > 인력, 서버 자원 등 서비스 제품 개발에 필요한 모든 자원을 의미
자원은 한정되어 있기에 더욱 우선순위 선정이 중요하다

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

📌 MoSCow 방법론(다수 사용)

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

  • Must Have 이 기능을 빼고 제품 런칭을 생각할 수 없는 것들
  • Should Have 높은 우선순위의 기능이지만 당장 적용하지 않아도 서비스에 영향이 없는 기능
  • Could Have 있으면 좋은 정도의 기능
  • Won't Have 중요도가 떨어지고 적용 했을 때 효과도 미미한 수준의 기능
  • 서비스 개편, 전체 개편, 서비스 신규 릴리즈 등 대형 프로젝트를 위한 방법론

📌 워킹 스켈레톤 방법론

  • 구현하고자 하는 기능 혹은 서비스의 PoC(Proof of Concept_컨셉을 증명하는 요소)버전
    ⇨ MoSCow 방법론의 'M'에서도 가장 중요한 것들만 추려서 만든 것
  • 주로 MVP(Minimum valuable Product)의 우선순위를 정하는데 사용되는 기법
  • 사용자 스토리를 중점으로 우선순위 선정
  • 완전하게 동작하는 제품의 형태를 갖추고 있어야 함
  • 비즈니스 가치를 충분히 보여주는 형태를 갖출 것

📌 RICE 방법론

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

  • 운영중 or 성숙기에 제품, 서비스 개선에 우선순위를 측정하기 위한 방법론

프로젝트 프로세스의 관리

🤓 프로젝트 프로세스의 관리(순서)

[가장 많이 커뮤니케이션 진행하는 부서 ⇨ 경영진, 사업팀, 개발팀]
01. 요구사항 정리 - 상위 기획서 작성
02. 개발 필요사항 정리 - 백로드 작성

[가장 많이 커뮤니케이션 진행하는 부서 ⇨ 개발팀]
03. 리소스 산정 - WBS 작성
04. 프로젝트 운영 - 간트 차트 작성

📜 백로그(Back Log)

  • 제품 및 서비스 구현에 필요한 요구사항 및 예상 소요 비용을 산정하는 단계
  • 제품 및 서비스 방향성에 부합하는 결과물을 만들기 위한 To-Do Lis

    백로그 - 개발 요구사항 (스펙)리스트 작성 단계

    1. 상위 매니저 사업팀 등과 함께 서비스 요구사항에 대해서 상위 기획서를 통해 합의한 내용에 대해 서비스 요구사항을 정리
    2. 해당 요구사항에 맞는 1차 백로그(초안) 나옴
    3. 여러 피드백을 통해 백로그가 지속적으로 업데이트
    • 해당 초안을 가지고 스크리닝 작업 ⇨ 1) 스펙 변경 작업
    • 변경된 내용으로 프로덕트팀(개발, 디자인팀)과 2) 리뷰 진행
    • 3) 비용 산정
    • 상위 매니저에게 이에 따른 4) 의사결정

🪢 WBS(Work Breakdown Structure)

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

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

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

🙏🏻 수직적 커뮤니케이션

주요 대상주요 문서목적
상위 의사결정권자상위 기획서서비스 방향 결정, 서비스 성공 여부 판단, 조직 간 이슈 보고

① 상위 기획서

  • 현황 분석 & 동기부여 > 현 시장 상황 분석 및 서비스의 구현 방향 기술
    ex) 헤어샵 예약의 경우 독점점 경쟁자가 없으며, 예약관련 프로세스를 편리하게
  • 목표 > KPI를 기준으로 구현하고자 하는 서비스의 목표 기술
    ex) 사용성에 기반한 알림을 통한 소비향 리마인드 제공
  • 유저 시나리오 > 페르소나 설정, 해당 유저 사용 동선 기술
    ex) 20대 남성이 지난 이용으로부터 n달이 지나면 알림메세지를 수신하여 재예약

② 서비스 구현 방향 변경

③ 조직 간 이슈 보고

🙌🏻 수평적 커뮤니케이션

주요 대상주요 문서목적
실무자(디자인/개발/사업/운영팀)상세 기획서서비스 구현 내역, 프로젝트 관련 이슈 발견, 제품 출시 및 성과 측정

① 상세 기획서

  • IA > 서비스 or 제품의 전체 설계도
  • 와이어 프레임 > 서비스 or 제품의 사용자 동선을 고려한 UX 시안 정의
  • 스펙 상세 > 구현하고자하는 서비스의 상세 스펙 정의
    ex) 얼럿 발생 시 백그라운드 딤드 처리

② 일정관리

  • WBS, 간트차트 관리 > 구현하고자 하는 서비스 혹은 제품의 상세 스펙 정의

③ 사용자 요구사항 청취

🫶🏻 외부 커뮤니케이션

주요 대상주요 문서목적
고객제품 소개서, 이용가이드, 공지사항제품 사용방법 전달, CS 접수

① 제품 홍보 페이지

  • 제품 특징 > 제공하는 제품 및 서비스와 타 서비스의 차별성 or 장점 제시
  • 이용가이드 > 제품 설명 및 이용방법 제시

② 고객 관리

  • 고객센터 운영 > 고객의 문의사항에 대한 대응 가이드 작성 및 제시
  • 공지사항 > 신규 제품 출시 혹은 업데이트 시 고객에게 공지

③ 리서치

  • 사용자 분석 > 기존 고객의 사용 데이터 추출, 분석 ⇨ 개선점 도출

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

  • 툴팁
    마우스 오버 시 해당 영역에 대한 설명이 말풍선 형태로 나타나고 사라짐
  • 노티피케이션
    사용자가 확인하지 않은 정보가 있는 경우 아이콘 형식으로 알려주는 알림
  • 네이티브 앱
    스마트폰 운영체제에 맞춰 개발된 프로그램
  • 웹 앱
    링크를 통해 접근 가능, 별도의 프로그램이 아닌 웹 브라우저를 통해 접근
  • 하이브리드 앱
    기본틀 > 네이트브 앱(안정성) + 특정 영역 >웹 앱(유연성)

프로젝트 완료 후

🤹🏻 서비스 운영

  • 고객이 서비스 및 제품 사용함에 있어 사용성을 파악, 개선사항 대응

🧫 어드민 기획

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

✍🏻 프로젝트 회고

  • 프로젝트 참여자 전원이 함께 진해아면서 겪은 본인의 소감 및 개선 필요 사항등을 공유함으로서 다음 차수 프로젝트 프로세스 개선을 이루어내는 과정
  • KPT 회고 방법론
    팀원 들의 의견을 Keep/Problem/Try 카테고리화하여 명시함으로써 프로젝트 회고 진행
    - Keep : 프로젝트 진행 시에 좋았던 점, 잘했던 점, 다음 차수에도 유지되어야 하는 부분
    - Problem : 프로젝트 진행 시에 잘 되지 않은, 못했던 부분, 다음 차수에도 개선되어야 하는 부분
    - Try : Problem에서 확인된 내용을 개선하기 위해 취할 수 있는 액션

🐣 오늘자 일기

서비스 기획자는 진짜 서류 작성만 하는 지가 의문일 정도로 작성하는 문서가 많다,,😅 알면 알게될 수록 작성할 문서들이 이렇게 산더미라니,,, 내가 과연 이걸 다 작성할 수 있을까,,? 개발할 때는 API 문서 위주로만 작성을 했는데,, 이젠 여러 문서들과 친해져야겠다! 지레 겁 먹지 말자!! 그래도 개발 공부를 해서 그런 지 커뮤니케이션을 위한 용어들은 좀 많이 알아서 다행 ㅎㅎ 역시 도움이 안되는 공부는 없다! ㅎㅎㅎㅎㅎ 이번 주차 강의도 끄읏!! 담주도 화이팅해보쟛!

함께 보면 좋은 블로그

profile
Hello World!

0개의 댓글