📚 패스트캠퍼스 데브캠프 프론트엔드 서비스 기획과 애자일 특강 학습 내용
📚 프로덕트가 어떻게 만들어지는가? 서비스 기획의 과정을 알아보쟈

쏟아지는 정보에 정신을 못 차리고 있지만, 그래도 해야지요.

이번 서비스 기획 및 애자일 특강에서 소개된 내용들은 이미 많이 들어본 개념들이었지만, 유독 낯설게 느껴졌... 강사님께서 너무 알차게 준비해오셔서 그런가? 발표 자료가 무려 100페이지가 넘더라고요. (ㅎㄷㄷ)

특강 녹화본을 다시 듣는 중인데, 여전히 와닿지 않는 현 상황 ㅎㅎ
남은 프로젝트에서 직접 적용해보면 "아하!" 하는 순간이 올 거라 믿으며 두고두고 꺼내볼 수 있도록 학습내용 정리 시작.


서비스 기획의 시작

"비즈니스 전반을 이해하고 프로덕트의 뾰족한 문제점을 찾아 빠르게 시장에서 영향력을 갖추는 능력이 중요하다."

강사님께서 강의 내내 계속해서 강조하신 부분은 "관찰, 쪼개기, 반복" 이었던 것 같다.

  • 사용자를 관찰하고, 뾰족한 문제를 정의한다.
  • 이후 문제 해결을 위해 작은 단위로 개발을 진행한다.
  • 이를 계속 반복한다.

Product Market Fit (PMF)

❖ Product Fit - 우리의 제품이 문제를 정말 해결해 주는가
❖ Market Fit - 이 제품에 대해 돈을 지불할 용의가 있는 사람이 충분히 많은가

☑︎ 집중 포인트

  • 사용자들이 자주 오래 사용하는가?
  • 스케일업 했을 때 Profitable 한가? (시간에 따라 튼튼한 수익성)
  • 이를 지속가능하게 한다

애자일과 폭포수 모델

  • 요즘처럼 변화가 잦은 시대에는 애자일한 프로세스가 폭포수 모델 보다 위험 관리 측면에서 이점이 있다.

☑︎ 애자일한 제품 사이클

  • 시장의 문제나 가설들을 작은 규모의 사이클로 반복한다.
  • 작지만 사용자의 페인포인트를 적절하게 타겟팅해서 해결해주는 프로덕트들이 앞으로도 각광 받지 않을까, 이런 면에서 프로덕트를 많이 기획해보자.

    ※ 애자일은 무조건 작게 만드는 것이 아님, 적게 일하면서 큰 임펙트를 내려고하는 태도로 생각하자!

더블 다이아몬드 프로세스

4단계 구성 : 리서치 - 문제 정의 - 개발 - 전달

  • 리서치 : 기본 자료 조사, 시장 조사, 경쟁사 분석, 사용자 조사 등 관찰의 단계
  • 문제 정의 : 조사를 바탕으로 문제를 정의, 사용자 페르소나 작성
  • 개발 : 아이디어 구체화
  • 전달 : 최종 결과물 전달

    ※ 다양한 디자인 방법론이 존재하기 때문에 항상 해당 프로세스를 따르는 것은 아니다.

☑︎ [리서치] 사용자 니즈는 어떻게 파악할까?

  • 몸으로 뛰어라.
  • 직접 경험해 보자.
  • 사용자들이 어떤 맥락에서 어떤 행동을 하는지를 관찰!!하는 것에서 시작한다.

☑︎ [리서치] 경쟁사 분석 프레임워크

  • 가장 기본적인 양식이고, 포지셔닝 맵 등 다양한 방법이 있다.

🔗 참고하면 좋은 사이트
Product Hunt
Y Combinator
혁신의 숲
더브이씨(THE VC)
스타트업얼라이언스 리포트
낭만투자파트너스
Disquiet

☑︎ [문제 정의] 비타민 vs 페인포인트

  • 비타민 : 문제해결 보다는 추가적인 가치나 이점을 제공 (감이 뛰어난, 센스의 영역)
  • 페인포인트 : 불편한 점을 해결
  • 페인포인트를 잘 설정하기 위해서는 관찰이 중요하고, 사용자의 말을 듣기보다 어떤 행동을 많이 하느냐를 관찰하는게 좋은 제품을 만드는 초석이 된다.

☑︎ [문제 정의] 5 Whys : 문제정의에 유용한 프레임워크

  • 특정 현상이 발생한 이유를 파고들면 본질적인(뿌리) 원인을 찾을 수 있다.
  • 근본 원인을 찾았다면, 이미 문제를 해결한 제품이 나와있을 것이다.
  • 이때 경쟁사 분석, 마켓 리서치를 통해 차별점을 만들어 내보자.

☑︎ [문제 정의] 사용자 페르소나 작성 프레임워크

❖ 사용자 페르소나
특정 제품이나 서비스의 이상적인 사용자를 구체적으로 묘사한 가상의 인물
디자인, 개발, 마케팅 등 다양한 분야에서 고객의 요구와 행동을 이해하고, 사용자 중심의 의사 결정을 내리기 위해 사용

☑︎ Aha Moment (아하 모먼트)

  • 좋은 것을 발견했을 때 아하!하게되는 순간들이 있다.
  • 사용자 여정에서 제품이 제공하는 가치를 최대한 빠르게 경험할 수 있도록 해야한다.
  • 사용자의 인내심은 부족하다!
  • 프로덕트 기획 시 아하 모먼트를 빨리 줄 수 있고, 유의미한 경험인지 생각해보자.

실무에서 제품이 만들어지는 과정

제품 개발 프로세스

  • 회고를 통해 생산성과 스프린트 점수를 측정하고 개선, 유지해 나간다
  • 보통 개발 스프린트 보드와 QA(테스트) 보드는 분리하는 편이다

User Story

❖ Features, 혹은 더 작은 기능 단위를 사용하는 주체, 기능, 목적을 정의한다
❖ 프로젝트에 연관된 심루자들을 위한 커뮤니케이션 도구 역할을 한다
❖ 문서에서 모든 내용을 정의할 수 없으므로, 유저 스토리를 통해 무엇을 구현해야 하는 지에 대해 합의점을 이끌어 낸다

  • 다양한 이해관계자들은 모두 다른 생각을 할 수 있다
  • 팀의 합의를 맞추기 위한 수단으로 사용자 스토리를 사용
  • 사용자 스토리가 하나의 티켓, 태스크라고 볼 수 있다
  • 티켓의 볼륨은 팀마다 상이, 정답이 있는 것은 아님
  • 기획이 완료되면, 하나의 티켓에 서브 티켓을 생성해서 업무 배정, 진행, 완료 단계로 흘러간다.

☑︎ Gerkin 문법을 활용한 사용자 스토리 작성

Gerkin 문법이란

Gherkin은 비즈니스 요구사항을 이해하기 쉽게 표현하기 위한 도메인 특화 언어라고한다.
비즈니스 요구사항을 명확히 하고 이해관계자와 소통하는 데 유용하며, 주로 다음과 같은 키워드를 사용하고 키워드별 의미는 다음과 같다.

  • Feature: 기능이나 요구사항을 설명한다
  • Scenario: 특정 상황이나 테스트 케이스를 설명한다
  • Given: 특정한 상황이나 배경을 설정한다
  • When: 특정 행동이나 이벤트를 발생 시킨다
  • Then: 기대하는 결과나 상태를 설명한다
  • And, But: 추가적인 조건이나 행동을 연결한다

사용자 스토리 적용 예시

참고 : https://itssonyong.tistory.com/3

PRD(Product Requirement Doc)

  • 제품 요구사항 정의서
  • IPM(Iteration Planning Meeting, 스프린트 회의)에서 PM 분들이 주로 사용, 공유하는 문서 양식

개발자가 IPM 회의에서 협업하는 방법

  • 개발 전에 필요한 요소와 예상되는 복잡성 정도를 파악
  • 정의된 사용자 스토리를 검토하고 추가로 필요한 데이터/화면은 없는지
  • 목표 달성을 위한 핵심 요소가 아닐 것 같거나 불필요한 내용에 대한 피드백 등

강사님이 공유해주신 PRD 양식도 있는데 노션 페이지를 타고타고 들어가봐야해서 한눈에 보기 어려웠다..ㅠ
그래서 그런지 노션 양식은 이런게 있구나 정도로 훑어봤고, 아래 아티클로 개념을 정리하는데 많은 도움이 돼서 첨부해 두었다!

[코드스테이츠 블로그] prd-제품요구사항정의서

회고

  • 강사님 피셜 "애자일의 꽃"
  • 회고는 서로를 탓하기 위한게 아니다
  • 더 나은 방향으로 나아가기 위한 회의다

☑︎ 회고의 형식

KPT

  • Keep : 지속할 것
  • Problem : 해결할 것
  • Try : 시도할 것
  • Action Item : 프로젝트가 끝난 후 작성, 명확하고 구체적이고 담당자가 존재해야한다
    • 누가 무엇을 언제까지 하기로 했어요
    • 누가 무엇을 개선하면 좋겠어요
    • 에러케이스를 초반에 잘 잡았으면 좋겠어요 등,,

4Ls

  • Liked : 좋았던 것
  • Lacked : 부족했던 것
  • Learned : 배운 것
  • Longed for : 원했던 것
  • Action Item

🔗 프로젝트 회의에 적용하면 좋을 내용
출처: 요즘IT(토스에서 요즘 '애자일'하는 방법(feat.EoA))

profile
📚 배움의 과정을 기록해요 | 💬 가보자고

0개의 댓글