brunch

매거진 기획자 다이어리

라이킷 27 댓글 2

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 박세호 Aug 18. 2020

매년 당신의 로드맵이 실패하는 이유

"수단"이 아닌 "결과"를 기반으로 하는 계획 설계의 중요성

이제 올해의 반기하고도 오랜 시간이 지낫네요. 많은 분들이 올해의 계획을 잘 지내고 계신지, 반기 회고라든지, 평가를 진행하셨을 텐데요, 오늘은 회사의 로드맵에 대한 이야기를 해보려 합니다.

왜 IT 프로젝트는 실패할까요?

리서치 결과에 따르면, 약 2.5%의 IT 프로젝트만이 100% 목적에 맞춰서 달성된다고 합니다.

프로젝트의 실패는 다양한 이유가 존재할 텐데, 대표적인 사례로는

1. 초반 설정한 요구사항과 스코프의 지속적인 변경 (Khaled El Emam and A. Güneş Koru, 2008)

2. 설계 초반 요구정의 구현 전 기획에서 예측에 실패(PWC, 2012)

3. 비즈니스단에서의 싱크와 결과에 대한 이해 차이(Geneca,2017)

4. 프로젝트에 대한 과한 긍정적인 접근과 명확치 않은 목표(Hnkpmgciosurvey, 2017)

가 있습니다.

그리고 우리는 이런 문제를 해결하기 위해 1년의 계획 또는 분기 또는 반기의 업무 계획을 프로젝트 로드맵을 그려서 진행사항과 전략 방향을 기반으로 해결해 보려고 하죠.

이런 식의 로드맵을 짜곤 하죠(출처: https://www.jibranelbazi.com/blog/what-is-a-product-roadmap)

자, 그렇다면 올해 로드맵을 작성한 분들은 한번 꺼내봅시다. 지난 반기는 어떠셨나요?

프로젝트 로드맵은 처음 설정한 대로 잘 진행되고 있나요?...

말잇못.....

지금 말을 잇지 못하고 계시다면, 오늘 이야기드리는 부분이 도움이 되리라 생각됩니다.

우선 앞에서 나온 문제를 우선 확인해 봅시다.

1. 우리가 과연, 시작도 해보지 않은 일을 계획 중 완벽하게 진행을 확인할 수 있을까요?

같은 일만 하는 사람들이라면 가능할 수도 있죠, 아니 제품을 만드는 일은 사람의 공수가 들어가는 일이기 때문에 생길 수 있는 다양한 물리적, 심리적 변화가 생기기 때문에 계획이 100% 수행될 수 있다는 것은 불가능하다고 생각합니다.

2. 결과가 "A 기능 개발."이라는 형식으로만 정해진다면, 기능을 통해 얻고자 하는 값에 대한 것을 비즈니스 오너와 제품울 만드는 사람과의 목표가 일치할 수 있을까요?

기능을 통해 무엇을 얻고자 한다에 대한 목적이 단지 기능의 구현이 될 경우, 해당 기능을 통해 진짜 얻고자 하는 본질을 전사적으로 일치시키지 않고 업무를 진행하는 것은 큰 위험이 따른다고 생각합니다.

어떻게 제품에 대한 계획을 세워야 할까요?

완벽하게 이뤄지는 계획은 저도 아직 모릅니다. 그리고 못합니다(헤헷).

하지만, 어떤 식으로 계획을 짜야 그나마 근접하게라도 모든 팀원들이 로드맵을 이해하고, 진행할 수 있을지에 대해 설명드리도록 할게요.(글 마지막에 프로덕트 로드맵의 템플릿을 공유드릴게요!)

1. 기능이 아닌, 결과를 기반으로 계획해야 합니다.

당신의 로드맵은 당신의 전략을 실현시키기 위해 어떻게 진행할 것인지 보여줍니다.

"A 기능의 개발"이 비즈니스에 미치는 영향은 단지 기능 개발이 아닌, A 기능을 통한 "재구매율의 n% 향상" 또는 "신규가입 회원의 n명 증가" 같은 달성하고자 하는 가치를 기반으로 계획하게 되면, 우린 A 보다 더 효율적이고 효과적인 방안들을 그때그때 찾아낼 수 있습니다.

2. 기능보다 사용자가 얻게 되는 가치가 더 중요합니다.

당신의 로드맵은 단지 기능의 완수가 아닌, 이를 통해 얻게 되는 사용자들의 가치에 집중해야 합니다. 아까와 마찬가지로 "A 기능의 개발"이 아닌, "고객들이 더 많은 제품 정보를 노출시킬 수 있는 방법의 추가"등이 주제가 되어야 하고, 이를 기반으로 작업 시 더 빠르고 유연하게 해결방법을 찾아낼 수 있습니다.

3. 비전은 고집 있게 가져가되, 디테일에는 유연해야 합니다.

기존의 로드맵은 수년에 걸쳐 디테일한 기능과 끝나는 시점에 대해서 적혀있고, 명확하게 분석되어 있지 않은 예측에 기반한 ROI로만 가득한 계획들을 본 적이 있을 겁니다.

빌드-검증-교육에 대한 사이클을 기반으로 하는 애자일한 프로덕트 팀은 계획에 있어 다른 접근을 가져가야 합니다. 그 어떤 계획도 첫 현실을 마주치면 살아남을 수 없습니다. 우리는 계획을 기반으로 한 프로덕트를 빌드하고 릴리즈 하는 과정에서의 습득을 통해 개선해야 합니다.