화해 제품팀이 일하는 방법

화해, 화장품을 해석하다
© BirdView Inc. All Rights Reserved
No.1 모바일 화장품 정보 플랫폼
화해 Product Way
2018/12
화해 Product Group

* 버드뷰에서 화해 제품을 만들어 가고 있는 팀의 일하는
방식에 대한 이해를 돕고자 작성된 문서입니다.
* 2018년 11월부터 만들어가고 있는 “화해 Product Way”에
대한 고민과 실제 실행하는 모습을 담았습니다.

Agenda
1. Product Way
2. 화해 Product Way의 방향
3. 화해 Product Way
4. 실행 방법
5. 화해 제품팀의 일하는 모습

1. Product Way
5
원칙 일하는 방식
핵심가치 문화
방법
태도/DNA

1. Product Way
6
제품 비전과 목표 달성을 위한,
1) 화해 제품 팀의 일하는 방식과,
2) 세 가지 실행 방법(People/Product/Process)

1. Product Way
7
This is about the last of these: how we as a product team work together, how our
teams are structured, and what we believe. We’re trying to build a company that
makes great software - software that’s reliable and fast and secure, that solves
real problems, that feels like it was made by humans with personalities who care
about design and craftsmanship.
다른 기업들의 사례

1. Product Way
8
조직구조
아키텍처
자율성
책임

1. Product Way
9

1. Product Way
10

화해
Product
Way
비지니스 / 제품 전략
현재 제품 개발의
도전과제
제품 조직의 성장
Agile
Strong Product
Culture

“Agile”
“How to Make Tech Products
Customers Love”
Two References

Agile
Agile은 무엇인가?
우리 조직은 Agile한가?
애자일은 왜 필요한가?

애자일 소프트웨어 개발 선언문
(Manifesto for Agile Software Development)
우리는 직접 소프트웨어를 개발하면서,
또 남이 개발하는 것을 도와주면서
더 나은 소프트웨어 개발 방법을 발견하고자 한다.
이 과정에서 우리는 다음을 가치있게 여기게 되었다:

4가지 가치
공정과 도구보다 개인과 상호 소통을,
포괄적인 문서보다 제대로 동작하는 소프트웨어를,
계약에 대한 협상보다 고객과의 협력을,
계획을 따르는 것보다 변화에 대응하는 것을 더 중요시한다.
왼쪽에 있는 것들이 비록 가치있긴 하지만,
우리는 오른쪽에 있는 것들에 더 큰 가치를 둔다는 것이다.

12가지 원칙
1. 고객 만족은 항상 우선순위가 가장 높으며 신속하고 지속적인 제공을 통해 달성한다.
2. 환경 변화는 고객에 경쟁 우위를 제공하기 위해 프로세스의 아무 단계에서도 도입된다.
3. 제품 또는 서비스를 더 높은 빈도로 제공된다.
4. 이해당사자 및 개발자는 매일 긴밀하게 협업한다.
5. 모든 이해당사자 및 팀원은 최적의 프로젝트 결과를 통해 동기 부여를 유지하면서 팀에는 필요한 모든 툴과 지원을
제공하고 프로젝트 목표를 달성할 수 있다는 신뢰를 얻는다.
6. 면대면 회의는 프로젝트 성공을 위한 가장 효율적이고 효과적인 형태로 간주한다.
7. 최종 동작 제품은 궁극적인 성공의 지표이다.
8. 지속 가능한 개발은 개발팀과 이해당사자가 지속적인 속도를 유지할 수 있는 애자일 프로세스를 통해 달성한다.
9. 민첩성은 기술적 우수성과 적절한 디자인에 대한 지속적인 집중을 통해 향상된다.
10. 간결성은 필수적인 요소이다.
11. 자기 조직 팀은 최고의 아키텍처와 디자인을 개발하고 요건을 충족할 가능성이 가장 높다.
12. 팀들은 미세 조정 행동을 통해 효율성을 개선하기 위해 정기적인 주기를 활용한다.

Good Product Team
vs Bad Product Team

. 강력한 제품 비전과 열정이 있다. vs 용병처럼 일한다.
. 데이터와 새로운 기술을 활용하여 아이디어를 모은다. vs 요구사항을 수집하여 아이디어를 모은다.
. 핵심이해관계자와 자주 대화한다 vs 핵심관계자에게 요구사항을 수집한다.
. 팀이 같이 모여앉아서 토의한다 vs 문서로 커뮤니케이션한다
. 아이디어를 검증하는 테크닉에 능숙하다 vs 로드맵을 통해 아이디어를 검증한다.
. 매출과 브랜드를 지키면서 새로운 아이디어를 시도한다 vs 의사결정 권한만 기다린다.
. 다기능 제품팀 스스로 필요한 능력을 갖춰나간다 vs 제품 디자이너가 무엇을 하는 사람인지 잘 모른다
. 엔지니어와 협업하며 프로토타이핑을 만들어낸다. vs 프로토타이핑을 보여주고 추정을 한다.
. 고객을 자주 만난다 vs 자신이 고객으로 생각한다.
. 출시 후 몇 번의 이터레이션이 필요함을 인정한다. vs 일정과 품질달성에 집착한다.
. 이터레이션과 테크닉을 통해 속도를 향상한다. vs 동료가 속도가 느린 원인이라고 생각한다.
. 분석도구를 근거로 활용한다 vs 있으면 좋은 것으로 생각한다.
. 연속적인 출시가 고객을 위해 안정적인 실행이라고 믿는다. vs 마지막에 한번에 출시한다.
. 고객에 집착한다 vs 경쟁사에 집착한다
. 비지니스 성과 달성을 목표로 한다 vs 출시를 목표로 한다.

<린과 애자일을 뛰어넘는 세가지 원칙>
1) 위험은 마지막보다는 초기에 대응한다.
뛰어난 팀들은 어떤 것에 대한 구현을 결정하기 이전에 위험을 먼저 발견하고 대응한다. 이러한 위험의 종류는 다음과 같다.
. 가치 위험(value risk): 고객이 과연 이 제품을 구매할 것인가?
. 사용성 위험(usability risk): 사용자가 이 제품의 사용 방법을 쉽게 이해할 수 있는가?
. 실현 가능성 위험(feasibility risk): 우리 엔지니어가 보유한 시간/역량/기술로 필요한 것들을 만들어 낼 수 있는가?
. 사업 유효성 위험(business viability risk): 이 솔루션이 우리 사업의 다양한 측면을 고려했을 때 제대로 효과를 발휘할 수 있는가?
2. 제품은 순차적인 방식보다는 함께 협업하며 정의되고 설계된다.
오래된 모델은 제품 관리자가 요구사항을 정의하고, 디자이너가 그 요구사항을 만족하는 솔루션을 디자인하고, 그 후 엔지니어는
요구사항들을 실제로 구현한다. 각 담당자는 해당하는 단계에서의 제약과 의사결정에 갇힌 채로 업무를 실행한다.
하지만 훌륭한 팀은 마침내 이 오래된 모델을 넘어서는 방식으로 일을 한다. 제품 관리자, 디자이너, 엔지니어가 함께 붙어서 활발히
의견을 주고받으며, 고객이 사랑하고 비즈니스 성과를 이룰 수 있는 기술 중심의 솔루션을 만들어 낸다.
3. 끝으로, 기능을 구현하는 것이 아니라 문제를 해결한다.
전통적인 제품 로드맵은 생산량에 대한 것이다. 강한 팀은 그것이 단순히 솔루션을 구현하는 것이 아니라고 이해한다.
그들은 솔루션은 근원적인 문제를 반드시 해결해야 한다고 믿는다. 바로 사업적인 성과에 대한 것이다.

@ Workshop
1. Agile, 훌륭한 제품팀 요약 읽기(2m)
2. 그룹 토의하기(20m)
“현재의 일하는 방식을 돌아보고, 앞으로 일하는 방식을 함께 논의”
- Agile 조직, 훌륭한 제품 팀에서 얘기하는 일하는 방식
- Plus: 우리가 잘 하고 있는 점
- Minus: 우리의 방식에서 아쉬운 점, 개선이 필요한 점
- Interest: 우리의 방식에서 흥미로운 점
3. 결과 공유하기(15m)

화해 Product Way
# 9가지 원칙
Value
Deliver Team

#1 빠른 실험과 고객을 통한 검증
Value
- 많은 실험 수행과 실패를 통한 빠른 학습만이 지속가능한 성장을 담보한다.
- 아이디어가 성공할 확률은 낮다. 개발하고 테스트하고 출시하는 일련의 제품 실행
Cost는 매우 크기 때문에 아이디어는 검증되어야 한다.
- 아이디어는 고객을 통해 다양한 기법을 통해 검증할 수 있다.

Value
- 브랜드/고객/비지니스 가치를 중요하게 생각하며, 높은 품질을 유지해야 한다.
- 팀은 고객, 비지니스 맥락과 이에 따른 목표를 잘 이해하고 있다.
- 계획보다는 목표달성과 고객 문제해결을 지향한다.
#2 고객과 비지니스 문제해결 지향

#3 반복적인 개선과 분명한 의사결정
Value
- 고객 만족과 비지니스 가치는 최소 몇번의 이터레이션을 통해 완성된다.
- 학습과 반복(Iteration)을 통해 끈질기게 성과를 달성한다.
- 적시에분명한 의사결정을 통해 목표를 달성한다.

#4 작고 꾸준한 출시
Deliver
- 작은 단위로 꾸준한 출시가 고객 문제를 안정적으로 해결한다.
- 변경사항과 인터럽트를 효과적으로 수용하며 고객 문제를 해결한다.

#5 공동 학습
Deliver
정성적, 정량적 학습의 결과를 지속적으로 공유한다.
└ 고객과 시장을 많이, 빠르게 학습하는 팀이 승리한다.
└ 그리고 “공유된 학습”만이 팀으로서 문제해결 역량을 높인다.
└ 데이터와 근거 기반으로 논의하고 의사결정하는 팀

#6 지속적인 속도
Deliver
속도를 중요한 가치로 생각하고, 지속적으로 개선한다.
└ 일정한 속도, 흐름을 유지한다.
└ 가능한 작고, 단순하고, 빠른 시도로 문제를 해결한다.
└ 주도적으로 흐름을 측정, 문제를 진단, 개선한다.

#7 자율적인 문제해결과 전문성
Team
목표달성을 위한 How는 팀이 자율적으로 고민한다.
└ 문제해결을 위한 최선의 솔루션을 팀이 스스로 판단한다.
└ 팀의 업무 원칙, 일하는 방법을 스스로 만들어나간다.
팀과 개인이 모두 문제 해결을 위한 역량과 전문성을 스스로 갖춘다.
└ 목표 성과, 고객에 대한 자율적인 성장 팀이 된다.
└ 팀 스스로 필요한 Skill Set과 문제해결역량을 갖춘다.

#8 투명하고 긴밀한 상호협업
Team
프로세스는 최소화하고, 업무 상태를 효과적으로 나타낸다.
└ 프로세스와 시스템 도구는 없을 수록 좋다. 많은 대화가 꼼꼼한 문서보다 낫다.
└ 업무 상황을 투명하고 명확하게 드러낸다.

#9 이 모든 것에 대한 지속적인 개선
Team
우리는 언제나 더 나아질 수 있다.
위 모든 것들에 대해 “모두가” 지속적으로 관찰하고 개선한다.

4. 실행 방법
People(Who)
Product(What)
Process(How)

4. 실행 방법
People
“전담팀”, “지속가능한 팀”, “다기능 팀”, “상호협력팀”
1) 담당하는 고객 문제해결과 목표 달성에 집중하는 전담 팀
2) 안정적으로 학습하고 성장하는 지속가능한 팀
3) 필요한 문제해결을 스스로 할 수 있는 다기능 팀
4) 높은 신뢰와 책임감으로 상호협력하는 팀

4. 실행 방법
People
*어떤 기준으로 팀을 나누는가?
제품 비전과 전략
사용자 및 고객
비지니스
투자전략
상호 의존의 최소화
주인의식과 자율성
레버리지 극대화
팀의 규모
아키텍처(Skill Set)
*팀 구조는 움직이는 목표물이다(Moving Target) 정답은 없고 현재 회사의 상황에 가장 적합한 방식을 취해야 한다.
*팀을 조직화 하는데는 역량수준, 속도(중복제거), 통합, 혁신, 문화, 책임 수준 등이 함께 고려되어야 한다.

4. 실행 방법
People 화해 제품의 미션 조직 = “밴드”
- Product Manager + Product Designer + Engineer and Data Analyst
Be in a Band, not an Orchestra
: how to Grow an Agile Product Team

4. 실행 방법
Product
Product Vision
화해 Flywheel
Business Goal(OKR)
Idea / Projects

4. 실행 방법
Product
실험과제(의사결정)
일반과제(목표달성)
고객만족
개선활동
Hot-Fix
과제 목적
Normal
Uegent
Fixed
시의성
백로그 유형
Value / Impact
Job Size / Easiness
우선순위

4. 실행 방법
Process 1) Dual -Track Development
Discovery & Delivery
*Note
- 가설 검증이 필요한 아이디어는
Discovery 단계를 거침
- Idea Backlog vs Delivery Backlog
- 가설검증은 Cross-Functional한 팀이 함께
참여 필요

4. 실행 방법
Process 1) Dual -Track Development

4. 실행 방법
Process 2) Kanban Method
“변화 관리 도구”
칸반 Kanban 이란 전문 서비스, 창의성이 필요한
노력, 물리적 또는 소프트웨어 제품 설계 등과 같이,
지식 업무 knowledge work 를 제공하는 서비스
services 를 정의하고, 관리하고, 개선하는
방법입니다. 칸반은 조직의 목표와 일치하는 유익한
변화에 맞서는 저항을 줄이며, 신속하고 집중적인
조직 변화를 이루기 위한 촉매로써, “현재 상태
그대로 시작”하는 것이 특징입니다.

4. 실행 방법
Process 2) Kanban Method: Trello vs Offline Board
- 오프라인보드가 필요한가?
- “한눈에 현황을 알아 볼 수 있는가?” “쉽게 논의하고 의사결정 할 수 있는가?”

4. 실행 방법
Process 3) Iteration: Implement-Feedback Loop
a. 2주를 넘지않는 단위로 팀이 계획하고, 실행하고,
학습/리뷰(Plan -> Do -> Learn & Share)
b. 캘린더 기준 혹은 배포(Deploy) 기준
c. Daily Standup, Planning Meeting, Review Meeting

4. 실행 방법
Process 4) 위키 - Confluence
- 아이디어, 과제 단위로 정보를 체계적으로 정리
- 히스토리, 연결된 정보 표현
- 공유 학습을 위한 범용성/가독성

칸반보드
- 각 밴드별 Daily
Standup
- 2주 1회 전사공유

그룹 워크샵
- 화해 Product Way

그룹 토의
- 속도가 느려지는
이유

월간 리뷰
- Health Check

화해 제품팀이 일하는 방법

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (14)

Similaire à 화해 제품팀이 일하는 방법

Similaire à 화해 제품팀이 일하는 방법 (20)

화해 제품팀이 일하는 방법