[패스트캠퍼스 부트캠프 : PM 2기] Day 1

 

새벽엔 운동을 아침 먹은 후 부터 자기전까지는 강의와 특강을 하루가 길면서도 짧다

강의를 들으면서 느끼는 점은 하루 빨리 실습을 해보고 싶다는 생각이 들었다

 

프로덕트 라이프 사이클과 개발 프로세스

 

회사가 시작되거나 새로운 프로젝트가 시작되면 4단계를 거친다 

시간이 지남에 따라 수익 증가량, 월간 반복 수익률에 따라 단계가 정해진다 

 

도입단계

기업이 처음으로 상품을 시장에 출시하는 시점

경쟁이 거의 없다

얼리어답터들이 구매하는 시점이다

 

성장단계

시장에서 상품이 받아드려지고 판매가 증가하는 시점이다

얼리어답터의 끝 부분의 사람들의 구매시점에 해당한다

Product 항목 개선 가능

시장에서 도전하려는 도전자가 적다

 

성숙단계

판매가 최고점에 도달하는 시점이다

다른 경쟁자들은 비슷한 솔루션을 갖고 시장에 접근하기 시작한다

이 시장은 사이즈가 커지고 충분히 매력적인 것을 인식한다

업계에 다른 회사와 다 경쟁하기 힘들다고 생각되는 시점이다 

경쟁이 치열해지는 시점이다

 

쇠퇴단계 

판매 감소 시점

시장의 포화 지점

시장에서 퇴출하는 시기 

시장은 더이상 훌륭하지 않고 새롭지 않다는 평가를 받는다

 

Product Development Lifecycle

구상

어떤 상품을 만들어야하는지 결정

아이디어의 가장 큰 출처(소스)는 대게 회사 내부에서 구성원들

 

계획

시장조사를 시작함

아이디어에 대한 연구를 시작한다

돈을 벌 수 있는지 확인

고객 인터뷰

사람들이 문제라 생각하는지 확인 과정 거침

시간이 얼마나 걸릴지 실제로 이 작업을 수행 할 경우 어느 시점에 사용 해야하는지 로드맵을 그림

 

개발

타임라인을 만들고 프로덕트에 포함 될 내용을 작성

유저 스토리와 사양을 만듬

특정한 것이 개발하는데 얼마나 오래 걸리는지 개발팀과 대화를 해야 함

요구사항을 설정

완성된 프로덕트 or MVP 초기 부분에 대한 검증을 받을 때 까지 요구사항은 변경되면 안된다

 

반복

개발중인 프로덕트에 MVP, Prototype 만듬

사용자로 부터 초기 피드백 받음

처음에 설정한 가정을 테스트 함

알파 베타와 같은 릴리즈 사용

올바른 방향으로 제품이 잘되어 가고 있는지 확인

 

런칭

마케팅 팀 법무팀 홍보팀 세일즈팀과 일 함

릴리즈를 위해 프로덕트를 포지셔닝 하고 싶다

포지셔닝 - 마켓이 누구에게 가장 어필 할 수 있는지를 결정

대중에게 프로덕트를 보내고 반응을 기다림

 

Post Launch Maximize

사용자의 지표 수집

비즈니스 성장 만족도 평가

지표 최적화

투자에 대해서 최대 이득을 얻으려 함

마케팅을 지속적으로 실행

세일즈 팀이 판매에 집중 할 수 있도록 도와줌

지속적으로 판매해도 되는지 확인

 

유지 or Kill?

수집한 모든 데이터를 사용하여 결정한다

얼마나 많은 사람들이 구매 하는지

시장의 정상에 존재 할 수 있는지

경쟁력이 있는지

유지하기 위해 얼마나 많은 돈을 쓰고 있는가?

 

개발 방법

Lean

 

고객을 위해 해야한다고 확신 할 때 까지 불필요한 작업이나 노력을 제거하는 것을 중심으로 하는 프로덕트 개발 철학

실제로 사용에 해야한다는 것을 알기 전까지는 리소스를 사용하지 않는다

많은 돈 시간 비용을 절약 할 수 있다

SW만을 위한 것이 아니다 → Agile(SW 중심)

 

Agile

 

SW 방식에 Lean 방식을 도입 하는 것

일반적으로 Agile SW 개발이라고 한다

SW 개발 프레임 워크

리소스를 낭비하지 않기 위해 작은 배치로 그룹화하고 수행한다

이런 요청을 백로그라 한다

팀 구성원간의 협업을 통해 간결하고 반복적인 방식으로 SW개발 방법론이다

Kanvan, Scrum은 Agile 개발 프로세스

 

Scrum

 

스프린트 계획 회의

프로덕트 백로그로 시작

가장 중요한 기능 → 제일 중요한 기능을 프로덕트 백로그의 맨위에서 가져와서 스프린트 백로그로 옮김

백로그 : 프로덕트 백로그 스프린트 백로그

프로덕트 백로그 → 프로덕트 전체 목표를 전체를 이루기 위한 정리한 기능 요청 리스트

스프린트 백로그 → 특정 스프린트의 목표에만 해당한다

 

프로덕트 백로그

• 최종 프로덕트가 개발 될 수 있도록 완료해야하는 모든 항목의 목록
• PO 책임하에 있다 → 우선순위 정하고 해결해야하는 책임이 있다
• 프로덕트 전체 목표에 따라 달라진다
• 고객의 요구나 고객의 비전 혹은 기업 자체의 비전에 따라 달라 질 수 있다
• 프로덕트에 대해서는 동일하게 유지
• 프로덕트를 완벽하게 개발하기 위해 완료해야하는 전체 작업세트의 작업 목록
• 프로덕트 백로그의 전체적인 책임
• 스프린트 백로그와 완전 별개 스프린트 백로그의 소스는 프로덕트 백로그이기 때문에 프로덕트 백로그에 의존

스프린트 백로그

• 프로덕트 백로그에서 가져온 항목의 목록 각각의 스프린트를 해결하는 목표를 가지고 있음
• 선택한 항목이 상황에 따라 조금씩 변화한다는 계획도 포함
• 개발자의 책임 → 완료시간의 프레임 작업을 한다
• 특정 스프린트의 목표에만 해당
• 스프린트에 대해서는 스프린트에 따라 달라 질 수 있다
• 스프린트 도중 완료 해야한다

개발 시작

보통은 2~4주 시간 프레임으로 묶는다

보통은 2주의 타임 프레임이 일반적

컬럼에서 컬럼 단위로 옮겨지는 티켓

2주 안에 스프린트 백로그 작업을 다 끝내야 한다

 

스탠드업 미팅

아침에 모든 조직원이 모여서 하는 소규모의 데일리 미팅

앉아서 하는 회의가 아니어서 짧고 간결함

 

목표

• 모든 팀 구성원이 마지막으로 작업한 내용 어제 저녁까지 작업하는 내용 현재 작업하는 작업들 다음에 수행하는 작업에 대해서 말함
• 질문이나 도움 요청의 시기
• 매우 짧은 시간 동안 이루어진다

회고 회의

스프린트 플래닝 회의의 반대 개념

팀과 함께하는 회의

모든 사람들을 모으고 끝낸 스프린트에 대해서 말함

 

Kanvan

 

스크럼과 마찬가지로 회의 및 시간면에서 스크럼 만큼 엄격하지 않다

Agile를 개발하기 위한 프레임워크

수많은 칸반 보드를 본 적이 있을 것이다

Kanvan 핵심개념은 스프린트를 사용하지 않는다는 것이다

타임박스를 하지 않음(2-4주 시간을 지정x)

스프린트 백로그 존재하지 않음 프로덕트 백로그 자체만 있음

팀은 티켓 작업만 한다

특정 회의를 규정하지 않는다

한번에 특정양의 항목만 진행 중 이거나 주어진 상태 있을 수 있다

각 특정 상태에 있을 수 있는 항목의 수는 팀이나 개인이 정할 수 있음

 

Waterfall

 

우리가 원하는 기능 10가지를 가져와서 동시에 개발

모든 기능을 연구 설계 개발 출시

꽤 위험한 방법일수도 있다

시간이 오래 걸려서 경쟁자의 행동 파악 불가 소비자의 요구 파악 불가 (개발 도중) 어느 순간 사용자 입장에서 다른 것을 개발 할수도 있고 사용자가 원하지 않는 것을 만들었다는 것을 깨닫는 순간이 있다

상당히 유용한 경우가 많다 → 적용하는 프로세스는 중요한 경우가 많다

프로덕트가 통째로 나와야 하는 경우 효율적인 방법이다

MS, iOS 같이 큰 규모의 경우 폭포수 모델이 좋다

 

POC

• Prototype과 혼용하여 사용
• 초보단계에서 방법 아이디어 이론이 나타나는지 테스트하는 프로젝트
• 위험을 개발전 미리 테스트하는 과정
• 전혀 프로덕트와는 상관 없는 형태로 존재
• 스타트업의 경우 핵심 기능만을 사용자에게 테스트 하도록 하는 경우도 있음
• 빠르게 실현 가능하냐 아니냐를 통해서 추후에 나타날 위험이나 실패를 미리 경험하고 테스트함이 목적이다

Prototype

 

• 프로덕트에 대부분의 기능을 갖춘 모델
• 기능을 전체적으로 모아서 통합 테스트를 함
• MVP:단독 ↔ Prototype : Draft 거칠다
• 기존 고객이나 잠재고객에 의해서 테스트 됨
• 반복적인 테스트

MVP

• 생존 가능하겠는가?
• 생존을 위한 최소한의 기능만을 포함하고 있다
• 기능이 최소가 아니라 핵심적인 기능만을 포함하고 있다는 것을 의미
• 즉 코어기능만을 포함하고 있는 것이다
• 시장가치를 확인하기 위해 테스트
• 가치 확인을 하게 된다면 고객을 확보 할 수 있고 릴리즈 반복이 가능해지기 때문

빠른 실험과 실패를 통해 중간결과물이 아닌 성과에 집중 해야하기 때문에 테스트를 상황에 맞게 도입 해야한다