패스트캠퍼스 PM강의 7주(3) O2O서비스 역기획: 직방

Initiating을 하는 방법

- 컨텍스트 맞추기: 과거에는 기획자가 기획서를 작성해서 일방적으로 해결
                             👉🏻 지금은 애자일 방법론에 따라서 기획자가 문제 자체에 대한 공감과 컨텍스트를 충분히 맞춘다음 initiating!

    ✅ 개발자를 움직이는 마법의 단어 : "고민이 있어요." ► WHY? 에 대한 공감!

 

- 데이터를 이용한 문제를 정의해서 공유! 공통의 언어인 데이터를 기반으로 개선안 initiating을 설득

    👉🏻 설득이 불가해도 새로운 문제점 인식으로 이어질 수 있어 보통 아이디에이션으로 이어짐

📌 내가 발견한 문제점(데이터에 기반)을 공감하고 개선안을 만들 때 일사분란하게 움직일 수 있음

► 애자일에 맞는 PM: 문제 초반부터 공유해서 함께 개선안을 발견해나가는 방식으로 업무를 진행!
( 물샐틈 없는 기획서? 👉🏻 개발자들이 참여할 수 없기 때문에 문제가 있어도 공감하기 어렵고 문제제기 하기 쉽지 않음)

 

Ideation 준비하기

문제 공감 후에는 보통 아이디에이션으로 이어져 기획자는 아이디에이션 미팅을 주도, 인사이트를 주기 위해 준비!

👉🏻 벤치마킹이 도움이 많이됨

1. 동일 업계에 있는 경쟁사의 서비스

2. 다른 업계지만 비슷한 UI.UX를 제공하는 서비스

► 시장을 주도하고 있는 서비스 일수록 구성원들을 설득하기 편하지만 맹목적으로 따라할 필요는 없다.

👉🏻 정의된 문제 해결에 가까운 서비스를 벤치마킹해야함! 따라하다보면 멋있긴한데 속도가 느리거나, 사용자들이 안씀...

 

►자유롭게 이런저런 케이스를 상상해보며 의견을 자유롭게 주고 받는다.

디자인 조직의 지원을 받으면 보다 직관적인 아이디에이션이 가능👉🏻아이디에이션을 진행하면서 인사이트를 공감

►재미있는 케이스를 찾아서 다양한 방법을 시도해보기

►끊임없는 벤치마킹 아이디어를 PM이 제공해야함.

그러나

아무리 준비해도 아이디에이션이 아름답게 되지는 않음 👉🏻리더십 또는 A/B테스트를 통해서 선택하게 됨

 

개선안 수립하기

► 방향성만 수립되어도 됨! 세부안은 아님. 👉🏻개선안은 = 상위기획

 

사용자 스토리를 정의하는 상위기획(일정관련리뷰) + 세부스펙을 정의하는 세부기획(세부사항 리뷰) ► 계속 기획안 리뷰가 들어감!

✅ 도서 추천: 사용자 스토리 맵 만들기(스토리와 스토리 매핑을 통해서 애자일 조직이 제품을 개선해나가는 과정)

 

사용자 스토리?

-과거: 사업팀에서 제품팀으로 요구사항을 시스템 기능 단위로 정리하여 전달 

           👉🏻 기능이 모두 개발되어야 프로젝트 오픈이 가능

-현재: 애자일 방법론에 따라서 프로젝트의 거대한 기능요건들이 사용자 중심의 스토리로 분화

👉🏻 모든 기능을 다 개발할 필요 없고 우선순위에 따라 사용자에게 꼭 필요한 기능을 먼저 개발하여 점진적, 지속적 개선을 추구

✅맹점? 제품에 대한 큰 그림을 놓치기 쉬운 단점

    ►사용자 스토리를 만들어 사용자 스토리와 프로덕트의 목표, 방향성에 대한 얼라인을 맞추고 지속적으로 체크해야 함.

 

📌사용자 스토리 정의 ► 유저들이 ~하고싶다. 가설을 유저 경험에 추가하기.

 

✅ 상위기획: 가설 👉🏻 사용자 스토리 정의 👉🏻 목표: 다양한 지표를 기반으로 AS-IS,TO-BE를 정의

 

여기까지 공감하게 되면 세부스펙을 정의하게 된다!

세부 개선안으로 디밸롭하기

탑다운 프로젝트?

탑다운으로 내려오는 경우 빠르게 킥오프 미팅을 시작으로 개선안 마련!

►킥오프미팅: 정의된 문제를 담당자에게 공유하고 함께 공감하는 자리
👉🏻PM은 미리 예상 가능한 문제를 정의, 킥오프 미팅에 필요한 컨텐츠들을 사업부와 함께 준비, 최대한 많은 정보와 컨텐츠, 문제점을 킥오프 미팅 전에 반드시 정리하기
👉🏻참석자: 사업부와 제품담당자 모두 ► 애자일한 방법론으로 커뮤니케이션 코스트를 줄일 수 있음

✅ 개선안을 initiating 할수 있는 킥오프 미팅을 준비해야함!

 

✅ 상위 기획안 리뷰 시 꼭 해야할 것 👉🏻대략적인 일정 협의하기

디자인과 개발 작업 일정은 세부 기획안 리뷰에 맞춰 미리 블락(확보)해두기
►세부기획안을 언제까지 드릴테니까 디자인, 개발작업을 언제 시작해주세요! 👉🏻그들의 일정을 당연히 확인하고 일정관리!

 

세부 기획

-서비스정책, 상세스펙, 화면설계, 운영메뉴얼 4가지 문서가 필요함

 

EPIC(정의된 사용자 스토리)를 기반으로 문서 작성

►서비스정책: 상세 스펙을 정의하기 전에 의사결정이 필요한 사항들을 정리(계속해서 업데이트) 👉🏻 컨플루언스, 노션

►서비스 프로세스: 기능단위로 어떻게 구현되는지 프로세스를 정리 👉🏻 Figma, Lucidchart,Draw.io

►상세 스펙과 화면설계: 스토리와 정책을 기반으로 상세스펙과 화면(UI)를 설계(스토리보드) 👉🏻Figma, Axure, Sketch, XD

►서비스 운영메뉴얼: 사용자에게 가이드가 필요하다면 운영메뉴얼을 작성 👉🏻 Figma, Axure, PowerPoint 

 

서비스 정책서

► 아이콘기획같은 컴포넌트는 추가화면설계가 필요없고 꼼꼼하게 적을 필요는 없지만 
정책에 세부스펙을 최대한 꼼꼼하게 반영, 수정사항을 기존 정책에 업데이트!

 

서비스 프로세스

👉🏻각각의 프로세스에 따라서 노출정책이 어떻게 되는지 정리해서 공유

 

세부 스펙과 화면 설계

세부스펙 👉🏻화면설계 👉🏻비고 : 좌우로 왔다갔다 하면서 기획서를 볼 수 있도록 설계

👉🏻 백엔드 기획에는 각각의 영역을 세분화해서 적는 게 좋다!

 

세부기획안 작성하기

(필요하다면 운영메뉴얼 작성하기)

오프라인 프로세스상 개선사항이 있으면 중개사항으로 배포할 운영 메뉴얼을 작성함►O2O의 특성에 따라 PM이 기획

 

세부기획안 기반 일감 나누기

-영역별 일감 분류하기

► 스토리 하위로 실제 작업을 진행할 일감을 영역별로 정리 ►일감 담당자를 지정하고 일정을 정리

*mapi: 껍데기 + 로직상으로 돌아가도록 서버에서 앱쪽으로 정보를 전달할 수 있게해주는 것

👉🏻 주40시간 5일! 애자일 방법론의 핵심인 스프린트 운영을 위해서는 스프린트별 작업자의 리소스를 고려하여 일감을 분배해야 한다

👉🏻 작업자가 작업물에 스토리 포인트 등록 👉🏻관리자는 적절하게 일감이 분배되어 있는지 파악, 시간/일수를 기반으로 파악

? 스토리포인트는 어떻게 남기나요?

👉🏻각 담당자에게 스토리 포인트 입력을 요청하고 일정을 협의! 

 

작업 진행과 QA리소스 확보

PM 세부기획안 리뷰 👉🏻 협의된 일정을 정리,담당자에게 공유 👉🏻 동시에 QA리소스를 확보해야함

►품질검증 리소스 확보 시 세부 기획안 리뷰 진행, QA에서는 보다 세부적인 피드백을 줌.

👉🏻 세부기획안을 보완하여 작업자에게 추가로 공유

 

개선안 트래킹하기

트래킹 = 추적 👉🏻PM이 추적해야 할 대상은 사용자 : 내부사용자 + 외부사용자

► PM은 작업이 진행되는 중에도 진행사항을 끊임 없이 체크해야! 

► 작업일정이 다 끝날 때가 되어서야 일정이 더 필요하다고 논의하고 오픈 일정이 지연되는 것은
작업자의 책임도 있지만 트래킹하지 못한 Pm의 책임도 있다.

 

내부사용자

 

- 정기미팅 진행하기: 1개 이상의 스프린트를 초과하는 프로젝트성 개선안은 정기미팅일정을 블락해야함

► 미팅이라고 오래 이야기 할 필요 없이 이슈가 없으면 스킵해도 되고 모였다가 해산해도 됨
(일정을 블락해두는 게 중요!)
► 중간에 이슈가 무조건 발생하는데 일정을 협의하기 위한 협의를 해야하기 때문에 정기 미팅 일정을 블락해놓기!

► 회의록을 반드시 작성하고 공유 + 리마인드! 👉🏻 작업중이면 회의 내용을 잘 안들을 수 있기 때문에

 

사용자 행동 추적

 

- 프로세스상 새롭게 추가된 추적대상을 정의하고
사용자 행동 추적 시스템에 케이스를 추가해야 이후 성과측정과 가설검증 여부를 파악할 수 있다.

👉🏻 사용자 행동 추적을 위한 코드추가

트래킹할 사용자 액션마다 트래킹 코드를 심어야함

일반적으로 wev/app자사에서 서비스하는 모든 환경에 대해서 트래킹 위해서 양쪽에 코드를 심는다,

사용자 액션(이벤트)명과 코드 등 트래킹 기준은 모든 프로덕트에서 공통으로 활용하기 위해서 통일!

 

 ►사용자 액션과 코드는 어떻게 정의하고 심나요?

사용자 행동은 데이터 베이스에 데이터로 기록

사용자별 클릭,페이지뷰 등 대부분 사용자 행동 데이터는 너무 방대하여 DB에 저장이 어려워

사용자 액션을 분석하는 툴을 활용하여 사용자 행동 데이터를 분석해야함.

👉🏻어떤 데이터 분석툴을 사용하느냐에 따라서 방법다름

GA,Amplitude, 브레이즈, 직접 만든 툴 👉🏻 툴마다 제공하는 SDK를 설치하고 사용자 액션에 따라 정의된 코드를 심으면 된다.

 

성과 측정하기

성과측정과 가설 검증의 시간! 👉🏻 문제를 정의할 때 설정한 지표상 목표와 실제 집계된 데이터를 비교

 

성과측정에 필요한 데이터 ► DB에 저장되어 있거나 DB에 저장되기 어려운 사용자 행동 데이터는 데이터 분석 툴을 통해서 제공

 

✅ 트래킹 해놓은 사용자 행동 데이터를 적극 활용하자! 일반적으로 PM이 측정가능한 수준의 성과를 직접 측정

✅ DB 데이터 기반 성과측정: DB에 쿼리를 날려 데이터를 직접 뽑아야한다. 

     ►SQL을 배우자! 문제를 정의하는 과정에서 데이터를 살펴보기에 중요.

 

가정1. 좋은 성과가 나왔다 👉🏻데이터 분석 툴을 통한 성과 확인

문제를 정의했을 때 동일하게 퍼널 분석으로 성과를 측정 ► 왜? 이런 성과가 나왔는지 분석하기

 

가정2. 나쁜 성과가 나왔다 👉🏻목표를 달성하지 못했다.

► 성과가 어떻게 나왔던 인사이트, 교훈을 얻고 그 다음 서비스 개선에 반영해야 한다.

✅ 성과 측정 주기? 일반적으로 한달정도 추적! 앱이 업데이트 되는 주기를 보고나서 어느정도 사람들이 업데이트를 하고나서 측정

(충분히 객관적인 데이터를 뽑을 수 있도록)

 

[내일배움카드], [국비지원교육]을 활용한 교육일지입니다!

#패스트캠퍼스 #내일배움카드 #국비지원교육 #K디지털기초역량훈련