brunch

매거진 공대생 기획자의 사이드 프로젝트

라이킷 32 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by FameLee Sep 02. 2021

프로젝트를 리드할 때, 이건 꼭 다루자!

인덱스 덱으로 모두가 같은 걸 그리게 만들자

목차.
1. 프로젝트를 시작할 때, 이건 꼭 집고 넘어가자.
2. 목표와 핵심 가치.
3. 같은 그림을 그려줘요, 인덱스 덱!
3. 인덱스 덱의 모든 것을 논할 필요는 없다.

하나라도 해당되면, 재밌게 읽을 수 있어요!
1. 팀을 리드하는 PO, PM가 되길 원한다.
2. 아이디어를 잘 발산하지만, 하나의 아이디어로 수렴하기 어렵다.
3. 목표나 핵심 가치를 명확히 하고 싶다.

프로젝트를 시작할 때, 이건 꼭 집고 넘어가자

회사에서 기획 업무를 주로 맡았지만, 궁극적으로 목표하는 커리어는 팀과 서비스의 방향을 설정하는 PO다. PO 경험을 어느 정도 쌓기 위해서 사이드 프로젝트나 학회 등에서 PO 포지션을 도맡고 있다. 대학교가 이제 개강을 한 만큼, 조만간 학회나 사이드 프로젝트 시즌이 도래할 것이다. PO 꿈나무로서, 프로젝트를 리드할 때마다 꼭 집고 넘어가는 요소들이 있다. 팀을 처음 리드해보는 대학생이나 초기 창업자에게 어느 정도의 도움이 되지 않을까 싶다. 참고로 저도 회사를 퇴사하고 학교로 돌아갑니다 ㅠㅠ

이번에 복학생 아저씨로 학교로 돌아갔다... 개강 싫어 ㅠ

목표와 핵심 가치는 꼭 집고 넘어가자!

프로젝트를 처음 시작할 때, 각 팀원이 서로 다른 프로덕트를 그리는 게 가장 큰 문제다. '아! 다르고, 어! 다르다'라는 말이 있듯이, 단어 하나로 프로덕트의 의미가 확 바뀐다. 각자가 같은 프로덕트를 그린다고 생각했는데 시간이 지나고 보면, 서로가 전혀 다른 걸 생각했음을 깨닫는 경우가 종종 있다. 이런 생각의 차이를 처음부터 잡아줘야지 나중에 의사결정이나 소통에서 부채가 생기지 않는다. 따라서, 모든 팀원이 같은 프로덕트를 그릴 수 있게 하기 위해 프로젝트 초기에 프로덕트의 '목표'와 '핵심 가치'를 논의 및 명시화하는 시간을 무조건 갖아야 한다.

목표와 핵심 가치

어떤 프로덕트를 만들지 대략적으로 이야기해보자

프로덕트의 목표와 핵심 가치를 논의하기에 앞서서, 프로덕트가 어떤지 대략적으로 스케치해야 한다. 근데 프로젝트를 함께 할 팀이 갓 생성된 상태에서, 프로덕트를 구체적으로 논의하기엔 데이터가 부족하다. 따라서, 프로덕트를 구체적으로 스케치하기보다, 대략적 방향을 설정하는 걸 목적으로 논의를 진행한다. "어떤 프로덕트를 만들까?"에 대한 아이디어를 마구마구 던지는 발산 과정을 통해 아이디에이션을 진행한다. 각 아이디어를 여러 기준을 적용해서 평가하고, 가장 순위가 높은 아이디어를 기준으로 프로덕트의 방향을 잡는다. 나 같은 경우, 각 아이디어를 평가할 때 크게 3가지 기준을 적용한다.

(1) 니즈의 유무 - 고객이 정말로 필요한가?
(2) 시장의 크기 - 이걸 필요로 하는 고객이 충분히 많은가?
(3) 설루션 구현 가능성 - 우리가 이걸 구현할 수 있을까?

창업 학회에서 진행한 아이디에이션

프로덕트의 목표와 핵심 가치는 무엇일까?

앞선 발산 과정이 끝나면, 이제 수렴 과정을 거친다. 프로덕트 대략적 방향을 '목표'와 '핵심 가치'를 통해 날카롭게 만든다.

(1) 목표 : 우리가 만드는 프로덕트가 사람들의 삶을 어떻게 바꿀까?
(2) 핵심 가치 : 고객은 우리 프로덕트를 무엇 때문에 쓸까?

팀 내 리소스가 한정돼있다 보니 모든 액션을 취할 수 없으므로, '하지 말아야 할 일'을 아는 게 '해야 할 일'을 아는 것만큼이나 중요하다. 여기서, 설정한 목표와 핵심 가치가 '하지 말아야 할 일'을 정하는 기준이 된다. 즉, 목표와 핵심 가치가 명확할수록, 팀 내 우선순위를 쉽고 빠르게 내릴 수 있다. 참고로, 이때 정한 목표와 핵심 가치는 나중에 바뀔 수 있다. 프로덕트에 대한 평가는 고객이 내려야 하며, 그전까지 목표나 핵심 가치 모두 가설일 뿐이다.

목표와 핵심 가치를 정하는 단계에서 핵심은 '모두가 같은 그림을 그리느냐?'이다. 이 둘은 앞으로 팀 액션의 판단 기준이 되는데, 이를 위해 팀원 모두가 같은 것을 그려야만 한다. 근데 앞서 말했듯이, 단어 한 끝 차이로 서로 다른 그림을 그릴 수도 있다. 나는 핵심 가치를 A로 생각했는데, 다른 팀원은 B로 생각할 수도 있다. 따라서, 모든 팀원이 같은 목표와 핵심 가치를 생각할 수 있도록, 이를 명시적으로 기술해야 한다.

같은 그림을 그려줘요, 인덱스 덱!

인덱스 덱이란?

모든 팀원이 같은 목표와 핵심 가치를 그릴 수 있게 하는 방법이 무엇이 있을지 자주 고민하고, 관련된 공부를 하고 있다. 최근에 읽은 <애자일 마스터>라는 책을 우연히 접하게 됐는데, 큰 도움이 됐다. 여기서 팀원 모두가 같은 그림을 그리게 만드는 방법론으로 '인덱스 덱'을 언급했다. 프로젝트를 리드하면서 인덱스 덱을 사용해봤는데, 단순히 '우리 프로덕트의 목표와 핵심 가치가 무엇일까?'를 묻고 브레인스토밍 하는 것보다 논의를 훨씬 효율적으로 진행할 수 있도록 도왔다. 책의 링크는 최하단에 있습니다.

인덱스 덱이란?
프로젝트를 시작하기 전, 반드시 물어야 하는 열 개의 질문으로 구성된 카드

인덱스 덱은 10장의 덱으로 구성됐다. 10장의 덱에 적힌 내용을 순서대로 이야기한다. 10장의 덱 중에서 5장은 '왜?'를 다룬다. 이를 통해, 모든 팀원이 프로젝트를 더 넓은 차원에서 볼 수 있게 돕는다. 이제 '왜?'를 모두가 같은 그림으로 그린다고 생각하면, 나머지 5장으로 넘어간다. 나머지 5장은 '어떻게?'를 다루는며, 이 덱이 끝나면 모두가 비슷한 결의 프로덕트를 그릴 수 있게 된다.

5장의 "왜?" 덱
1. 우리가 왜 여기에 모였을까?
2. 엘리베이터 피칭을 만들라
3. 제품의 광고를 디자인하라
4. Not 리스트를 작성하라
5. 프로젝트와 관계된 다양한 사람들과 알고 지내기

5장의 "어떻게?" 덱
6. 해결책 보여주기
7. 리스크
8. 규모를 정하라
9. 우선순위 정하기
10. 미리 알아야 할 비용

5장의 "왜?" 덱

1. 우리가 왜 여기에 모였을까?

프로젝트를 성공적으로 진행하려면, 이 프로덕트를 왜 만들어야 하는지 알아야 한다. 팀원들 각자가 "이 프로젝트를 하기 위해, 모인 이유가 무엇일까?"로 가볍게 워밍업을 하고, "이 프로덕트가 고객의 삶을 어떻게 바꿀까?"를 이야기해간다. 모두가 동의하는 '왜?'가 모였다면, 이 답이 프로덕트의 '목표'가 된다.

2. 엘리베이터 피칭을 만들기

모든 팀원이 같은 프로덕트를 그리게 만들기 위해 엘리베이터 피칭을 진행한다. 엘리베이터 피칭을 진행해보면, 고객 관점에서 프로덕트를 평가하고, 프로덕트의 핵심 가치를 명확히 할 수 있다. 나는 아래의 엘리베이터 피칭 템플릿을 사용한다. [ 빈칸 ]에 어떤 내용이 들어갈지 팀원과 이야기해서, 엘리베이터 피칭을 완성한다.

[고객이 필요로 하는 것]를 원하는 [목표 고객]를 위해 [제품의 카테고리]인 [제품명]은 [제품의 혜택]을 제공한다. [경쟁사 제품의 기능]과 다르게, 우리 제품은 [제품의 차별점]이다.

사이드 프로젝트에서 팀원 모두를 동기화하기 위해 엘리베이터 피칭을 자주 사용한다. 최근 진행한 사이드 프로젝트의 예시를 갖고 왔다. 프로덕트의 동기화를 위해 각자가 엘리베이터 피칭을 직접 작성해보고, 어떤 걸 문서로 명시화할지를 결정한다.

[카페에서 주문]을 하는 [20대 아이폰 여성 유저]에게 [weQ]는 [QR코드를 통해 자리에서 간편한 디지털 결제]를 가능케 해준다. [네이버나 배민의 테이블 오더]와 다르게, WeQ은 [통합 혜택 관리와 메뉴의 입체적 정보]를 제공한다.

3. 제품의 광고를 디자인하라

여기서 '광고 디자인'이 진짜 미적으로 이쁘고 아름다운 광고를 뜻하는 게 아니고, 종이 프로토타입처럼 A4 한 장에 끄적이는 걸로 충분하다. 이 과정에서 핵심은 "고객이 무엇에 끌리는가?"를 돌아보는 데 있다. 즉, 광고를 직접 디자인해보면서, 고객이 우리 제품에 무엇을 보고 끌릴지 알아낸다.

프로덕트를 고객에게 판매할 때, "프로덕트는 이런 기능을 갖고 있어"가 아니라, "이 프로덕트로 이런 것을 할 수 있어"를 보여줘야 한다. 즉, 프로덕트가 제공하는 기능이 아니라, 혜택에 집중해야 한다. 미니벤을 어떤 가족에게 팔아본다고 해보자! "크루즈 컨트롤 기능과 안티 록 브레이크 기능이 있다."라고 말하는 게 좋을까? 아니면, "연비가 저렴하고, 가족의 안전을 위해 부드럽고 안전하게 멈춘다."라고 말하는 게 좋을까? 당연히 후자가 더 친숙하고 이해하기 쉽다. 여기서, 무작정 혜택을 모두 적는 게 아니라 핵심 혜택을 파악하는 게 중요하다. 최대 3개의 핵심 혜택을 적는 게 좋다.

4. Not 리스트를 작성하라

프로젝트를 진행할 때, '하지 않을 것'이 무엇인지 정확히 아는 게 '할 것'을 아는 것만큼 중요하다. Not 리스트를 작성하면, 어떤 것이 프로젝트 범위에 포함되는지 혹은, 포함되지 않는지 분명히 알 수 있다. Not 리스트는 '범위 내 항목', '범위 외 항목', '미해결 항목', 이렇게 3가지 영역으로 구성된다.

1. ['범위 내 항목'] : 프로젝트를 할 때 초점을 맞춰야 할 사항들을 적는다.
2. ['범위 외 항목'] : 에선 하지 않아도 괜찮은 사항들을 적는다. 크게 '다음 릴리스로 연기해도 무리가 없는 것'과 '도저히 해결할 수 없는 것'이 여기에 포함된다. 이 항목에 있는 사항들은 아예 고민도 하지 말아야 한다.
3. ['미해결 항목'] : 지금 판단하기 어려우며, 좀 더 더 고민해보고 결정을 내려야 할 사항들을 적는다. 이 항목에 있는 사항들은 가능한 빠르게 '범위 내 항목'이나 '범위 외 항목'으로 옮겨야 한다.

5. 프로젝트와 관계된 다양한 사람들과 알고 지내기

프로젝트에서 팀원이 아니지만, 프로젝트에 관련된 사람이 있을 수 있다. 처음부터 이들을 고려하지 않고 넘어가면, 추후에 프로덕트를 제작하다가 이들과 조율을 해야만 해서 딜레이가 발생한다. 예를 들어, IT 회사에서 프로젝트로 어떤 기능을 구현했다고 해보자. 딱 맞춰 QA까지 끝났고, 오늘 배포만 하면 된다. 이때, 갑작스럽게 보안 담당자로부터 이슈가 들어온다면? 배포일이 그만큼 늦춰지게 된다.

나머지 5장의 '어떻게?' 덱

여기서부터 '어떻게?'를 다룬다.

6. 해결책 보여주기

해결책을 다이어그램이나 시나리오 등으로 간단히 시각화해본다. 이 시각화 과정을 통해 기술적으로 성취하려는 것이 무엇인지 한눈에 파악하고, 어떤 리스크가 있는지 예상 가능하다. 마지막으로, 모두가 이 해결책에 동의하는지 쉽게 확인할 수 있다.

7. 리스크

프로젝트 초기에 리스크를 논의하지 않으면, 부채로 남아있다가 나중에 큰 문제로 이어질 수 있다. 모든 리스크를 완벽히 대응할 순 없을지라도 가능한 리스크를 미리 생각해본다면, 막상 그 상황이 들이닥칠 때 빠르게 햇징할 수 있다.

팀원끼리 모여서 모든 리스크를 리스팅 하고, 이를 '해결할 만한 가치가 있는 리스크'와 '해결하기 힘들거나, 하지 않아도 괜찮은 리스크'로 분류한다. 해결하기 힘든 리스크는 아무리 신경 써도 마땅한 해결책이 당장 떠올릴 수 없다. 또한, 하지 않아도 괜찮은 리스크는 대비하기 위해 많은 리소스를 쓸 필요가 없다. 따라서, 이러한 유형의 리스크는 신경 쓰지 않고 일단 뒤로 넘겨둔다.

8. 규모를 정하라

처음부터 너무 큰 프로덕트를 만들려면, 속도가 늦어진다. 어느 정도 결과물이 나와야지 성취감을 느낄 수 있는데, 프로덕트가 너무 크다 보면 이야기만 하다가 텐션을 잃을 수 있다. 또한, ETA(Estimated Time of Arrival)를 정하지 않는다면, 욕심이 생겨서 하나, 둘 기능이 계속 기능이 추가되다가 몸집이 너무 커져서 실패하게 된다. 참고로 <애자일 마스터>라는 책에 따르면, 가장 이상적인 IT 프로젝트의 기간은 6개월이라고 한다.

9. 우선순위 정하기

<애자일 마스터>라는 책에서 프로덕트 출시에 가장 큰 영향을 주는 요소로 '기간', '비용', '품질', '범위'를 꼽았다. 근데, 이 각각의 요소를 모두 챙기기엔 현실적으로 불가능하며, 서로 충돌할 수밖에 없다. 예를 들어, 제작 기간이 짧으면, 프로덕트의 품질이 떨어지거나 구현 기능의 범위가 좁아질 수 있다. 반대로, 프로덕트의 품질을 높이거나 구현 기능의 범위를 넓히면, 기간과 비용이 비례해서 증가한다. 따라서, 서로 다른 요소 사이에 우선순위를 매겨야 한다. 이때, 핵심은 '고객'의 관점에서 우선순위의 기준을 내려야 하는 것이다. 예를 들어, 고객은 여러 기능이 필요 없이 단 1가지의 기능만 필요한다고 말한다면, '품질'이 '범위'보다 더 높은 우선순위에 있게 된다.

10. 미리 알아야 할 비용

이 덱에서 '누가 의사결정을 내릴 것인가?'와 '프로젝트를 위해 어느 정도의 비용이 소모될까?'를 이야기한다. 팀 내에서 다양한 의견과 아이디어가 오고 가는데, 이걸 궁극적으로 결정할 사람이 필요하다. 그렇지 않으면, 의미 없이 주먹구구식으로 대화가 진행될 뿐이다. 따라서, 모든 의견과 아이디어를 수합해 의사결정을 내릴 사람을 결정한다.

대략적인 비용을 가장 빠르게 계산하고 싶다면, '팀원의 수'를 활용하면 된다. 프로젝트 진행하다가 다양한 영역에서 비용이 발생할 수 있다. 프로젝트를 위해 새로운 툴을 도입해야 한다던지, 프로덕트를 홍보하기 위해 광고를 집행한다든지 말이다. 하지만, 이러한 비용 중에서 가장 큰 비율을 차지하는 것은 '사람'이다. 따라서, [팀원의 수 x 프로젝트 기간 x 시간당 비용]을 통해 대략적인 비용을 유추할 수 있다.

인덱스 덱의 모든 것을 논할 필요는 없다.

인덱스 덱은 큰 IT 기업에서 주로 사용하는 방법론이다. 이를 바꿔 말하면, IT 기업이 아닌 곳에서 인덱스 덱의 모든 것을 따를 필요가 없다. 가령, 사이드 프로젝트의 경우에 비용이 크지 않고, 팀원 외 관계자가 없기 때문에 5번 덱(프로젝트와 관계된 다양한 사람들과 알고 지내기)과 10번 덱(미리 알아야 할 비용)을 논의하지 않아도 된다. 따라서, 자신의 상황에 따라 필요한 덱만 추슬러서 사용해도 된다. 나 같은 경우, 1번, 2번, 8번 덱은 반드시 이야기하고, 그 외의 덱은 나중에 필요성을 느낄 때 사용한다. 결국, 이 방법론에서 어떤 걸 추출해서 사용할지는 개인의 영역이다.

다음 아티클로, PO 꿈나무로써 프로젝트 초기에 팀원이 열정적으로 참가하게 만들기 위해 짚고 넘어가는 부분에 대해 조만간 다루고자 한다.