PM / PO / 서비스 기획 / 프로젝트 관리

은아·2024년 9월 7일

PM

프로덕트 매니저는 제품을 정의하며, 개발 조직은 그렇게 정의된 제품을 실제로 잘 구현하는 역할

  • 여러 제품 아이디어 중 어떤 아이디어가 시장에서 가장 필요로 하는지
  • 타깃 시장은 어디인지, 시장의 규모가 충분한지
  • 경쟁 제품과 비교하여 우위가 있는지
  • 제품의 비전과 목표는 무엇인지 등

-> 프로덕트 매니저는 Product Strategy(제품에 대한 전략), Priorization(우선순위), Excecution(실행) 하는 포지션

PO

PO는 Mini CEO다

  • PO는 특정한 서비스나 제품을 책임지는 사람

  • 하는 일:

    • 디자이너를 비롯한 엔지니어들과 함께 기존 서비스를 개선하거나 신규 서비스를 출시한다.
    • 수 많은 사람과 소통하고 방향을 제시하며, 질문에 답하고 설득하는 사람
    • 고객이 무엇을 필요로 하는지 끊임없이 분석하고, 사업의 목표와 부합되는 서비스를 발굴, 검증하는 사람

프로덕트 오너는 말 그대로 하면 '제품의 주인'으로서, 담당 제품에 대한 오너십을 가지고 지속적인 제품의 성장을 이끄는 포지션이라고 할 수 있다.

고민과 소통을 시간을 가지고 예상되는 리스크들을 알아보며 보다 멀리 내다보고 결정할 수 있다.

무언가 바뀌어야 할 때에는 설명하자.

사용자에게 집착하라. 사용자가 있는 현장에서 경험하는 것이 중요하다.

Why에 대한 집착.

PO는 제품의 로드맵을 기반으로 방향을 정하는 사람

사용자의 우선순위 , 회사의 우선순위 -> 고객의 요구사항들이 굉장히 다양했을 때 회사의 중장기 로드맵과 맞춰서 가장 우선순위 될 만한 요구사항들을 꺼내고 거기에 순서를 붙여주는 역할을 해야한다.

-> 사용자의 우선순위가 높다고 해서 바로 해결하는 것은 아니다. 법률이슈, 개발의 레거시, 난이도, 운영 인력, 비용등을 고려해야한다.

-> 회사가 이 비용을 지금 감당할 수 있는 지, 정말 이 요구사항을 해결하는 게 장기적으로 이익인지를 고려해봐야 한다.(아무래도 개발쪽을 고려하게 됨: 제품의 완성도, 속도)

-> 제품을 추진하는 데 조금 더 힘을 받고 빠르게 추진하고 싶다면 제품에 대한 개발 계획을 가지고 개발팀과 논의를 해봐야 한다. 개발팀을 잘 설득하고 서로 같은 방향으로 동의를 하게 될 시에 제품의 완성도, 속도가 빠르게 올라갈 수 있다.

Agile

애자일 프로세스는 워터폴 방식과 반대되는 개념(명확히 반대는 아니다.)

불확실성을 기반으로 하는 프로세스
-> 변동으로 인한 충격을 최소화하기 위한 장치

애자일 조직의 지향점

  • 프로세스나 도구보다는 각 개인과 개인의 상호작용에 중점을 둔다.
  • 포괄적인 문서화보다 실제 작동하는 소프트웨어를 신뢰한다
  • 계약과 협상보다 협업을 중시한다.
  • 계획을 따르기 보다는 변화에 적응한다.

Sprint

스프린트란

구글 벤처스의 서비스 기획 방식으로 서비스를 개선하거나 아예 새롭게 만들어내기 위해 관계자들이 5일 안에 프로토타입을 만들어 실용적인 서비스 전략을 얻어내는 방식

  • 1일차: 주요 관계자가 모여 해결하려는 문제의 구조와 이면 이슈 분석 - 핵심 주제 및 타깃 선정

  • 2일차: 해결 방식을 각자 스케치

  • 3일차: 아이디어를 내어 최적의 솔루션을 선정하고 서비스 흐름을 만듦

  • 4일차: 1~3개의 현실적인 프로토타입을 만듦

  • 5일차: 사용자 테스트(타깃 대상) 및 피드백

국내에서의 스프린트 - 2주 단위로 기획 - 개발 - QA - 출시 까지의 업무로 Water Fall 방식과 달리 짧은 제품 주기를 갖는다.

Sprint 준비

스프린트 준비 = 기획

  1. 서비스의 재료가 되는 것 부터 생각한다. -> 데이터 (DATA) / 경험(experience)

    • CTA(Call to Action) = 예약 <- 제품 개발의 최종 목적

  2. 백오피스를 어떻게 구성할 지 정한다 ex) 앞서 설정한 항목에 대해 어드민을 구성 CRUD

  3. 요구사항 정의서를 만들자

    • 개발자와의 사전 커뮤니케이션으로 기획의 내용을 구체화할 수 있다.
    • 개발자와의 공감대 형성이 중요(개발 레퍼런스까지 제공할 수 있으면 좋다)

    3-1. 개발자와의 공감대 형성

    • 복잡도가 높은 제품일수록 보수적일 수 있다.
    • 개발 시간이 증가한다.
    • 오류가 증가할 수 있다.

    요구사항 정의서를 사전에 공유하면?

    • 리소스 배분을 사전에 할 수 있다.
    • 개발 난이도에 따라 인력을 배치하고 예상되는 문제를 사전에 논의할 수 있다.
    • 더 나은 대안을 찾을 가능성이 높아진다.
    • 개발 진행 속도와 완성도가 달라진다.

  4. 와이어프레임 & 디자인

  • 와이어프레임을 하기 전에 대략적인 틀을 종이에 그려보자 - 주의: 초기에 잡은 틀에 갖혀 사고하지 말라.

  • 스케치 단계: 기본적인 틀은 이미 정해져 있다 - (Human Interface guidline, Material design)

  • 와이어프레임
    - 스타일, 컬러는 생각하지 않고 대략적인 틀만 제공

  1. 와이어프레임이 완성되면 이제 본격적인 기획서를 써보자
  • 워터폴에서는 스토리보드 또는 화면 설계서 같은 형태의 산출물이 나온다.
  • 애자일에서는 스토리와 백로그가 만들어진다.
    -> 스토리 & 백로그는 엑셀, 노션, Jira로 만들 수 있다.

Jira의 이슈 유형

이슈: 지라에서 만들어지는 항목

하나의 목표인 에픽(로드맵이라고도 한다. 제품이 가야 할 방향을 설정)을 달성한다.

  • 스토리
    Title: 문장으로 간략하고 명확하게 작성한다. (ex: 지도에서 내 주변 병원을 찾을 수 있는 화면을 개발한다.(화면단위로 한 것))
    Discription:

    • 이유, 목적, 누구를 위한 것인지 작성한다.
    • 디자인 요소는 배제한다. 디자이너와 협의가 된 상태라면 무방하다. 간혹 디자인이 미리 완성되고 스토리가 생성될 수도 있다.
    • 디자이너의 창의성에 방해가 되지 않게 필수 요소만 작성한다.

    첨부문서: 와이어 프레임 또는 API 가이드 문서 등 첨부 가능한 문서

    • 칸반보드 구성

    • 백로그에서 스토리 생성, 설명 기입

    • 하위이슈(서브 테스크) 생성

    • 타임라인에서 스토리 생성, 백로그의 보드에서 타임라인의 에픽과 연결 가능

    • 스프린트 단위로 운영하는 회사일 경우에는 스크럼으로 만든다.
      스토리 생성 후 스프린트 시작(여기서는 3주 단위로 임시 설정)
      새로운 스프린트를 미리 생성해놓을 수 있다.
      -> 스프린트를 시작해야 보드에서 확인할 수 있다.

    • Notification 설정을 통해 팀에서 쓰는 슬랙으로 알림을 받을 수 있다.

출처

profile
은아
Junior Developer 개발 기술 정리 블로그
이전 포스트

Linux 기초 명령어 정리

다음 포스트

VBA 코드 변경사항 분석 문서(mod_FileData_Copy모듈, mod_Menu01_DSD_File 모듈)

0개의 댓글