제품/서비스 로드맵 짜기(* 애자일 조직의 제품 설계 방식)

Medium(미디움)에서 제품/서비스 로드맵 관련한 글을 관심깊게 읽었다.

로드맵은 방향성과 리스크 관리 차원에서 중요하다.

로드맵은 중요하다.

PM이든 CEO입장에서 "유저에게 가치를 제공하는 것"과 "측정가능한 수준으로 만드는 것"은 비즈니스 상에서 중요한 가치이기 때문이다.

하나의 서비스를 런칭한다고 가정해보자.

우리는 누가 겪고 있는 문제를 어떻게, "왜", 어디서(대부분 온라인), 누구를 위해서, 누가, "언제(유저/비즈니스 측면)" 제공할 것인지를 고려할 것이다.

Problem과 Solution 그리고 Target은 적절히 고려하겠지만, 이를 왜, 언제까지 달성할 것인지는 명확히 정의내리기 어렵다.

또한 초기 스타트업에서는 누가 해당 업무를 담당할 것인지 리소스를 분배하는 것이 중요하다.

목적을 달성하기 위해서 중간 도착지는 언제든 변경할 수 있으나, 이에 대한 리스크는 관리할 수 있는 수준으로 만들어야하기 때문이다.

 

최근 업무를 진행하고 있는 회사에서 제품/서비스의 로드맵을 만드는 업무도 진행하고 있어서 이 글은 도움 되었던 것 같다.

로드맵을 짜면서 단기적/장기적 관점에서 접근하였는데, 이런 업무는 처음이라 올바르게 하고 있는지 확신이 부족했다.

 

단기/장기적인 로드맵을 고려하다.

단기적인 로드맵을 고려할 때는 비즈니스 목표에따라 하나의 피쳐를 기획하고, 유저들이 사용할 수 있는 정도의 수준으로 어떻게 배포할지에 대한 고민이 컸다. 완벽하게 배포하기에는 시간이 너무 지체되었고 경쟁사가 너무 많은 시장이었다.

장기적인 로드맵을 고려할 때는 미래에 우리가 속해있는 시장이 어떻게 변화할 것인지에 대한 예측과 미래의 수요를 생각하여 어떠한 피쳐들이 갖춰져야 하는지를 고민하였다.

 

두 개의 로드맵에서 모두 고려해야할 것은 이해관계자들을 설득(* Psychological Safety를 위해)하고, 논리적인 타당성이 뒷받침되어 있어야 한다는 것이었다.

또한 유연하게 로드맵을 변경할 수 있어야 하는데, 이 과정들 속에서 이해관계자들이 불만이 생길 수 있는 요인들이 너무 많았다.

 

기능보다는 목적 중심의 로드맵이 필요하다.

하나의 목적을 위해 달리는 조직에서 조직원들에게 "내가 이 일 하는 이유"는 동기부여 측면, 완성도 측면에서 중요하다.

누군가에게 "이 일을 왜 하나요?"를 물었을 때, "누군가 시켜서요"라는 답변이 나오기보다는 "이것을 통해서 유저들에게 어떤 가치를 전달하여 ~~목적을 이루기 위해서요"라고 답변할 수 있을 때, 더 바람직한 조직이 되지 않을까 싶다.

단순히 "이 기능을 언제까지 개발해야 돼!" 보다는 "무엇을 위하여 왜 언제까지 해당 기능을 개발해야 돼"라고 답변할 수 있는 조직이 건강할 것이라 생각된다.

개인 입장에서는 Self-Motivation에 도움이 될 것이고, 조직 측면에서는 조직의 성장 속도와 건강함에 도움이 될 것이라 생각된다.

-----

제품/서비스 로드맵 짜기(* Medium 본문중)

로드맵은 하나의 인공물로서 애자일 조직에서 방어하기가 점점 더 어려워지고 있다.

이해 관계자가 나에게 일정에 관련된 질문을 하고, 답변을 요청하면, 마치 누군가에게 영국에서 미국까지 수영하는 데 얼마나 걸리는지 묻는 것과 같았다.

 

답은 기껏해야 추측일 것이며, 며칠 동안 수영을 해도 나는 여전히 알 수 없다. 나는 아마 익사하고 결코 목적지에 도착하지 못할 것입니다.

'민첩하다는 점'은 당신이 아직 볼 수없는 지평을 약속하는 것이 아니다. 로드맵을 통해 새로운 정보가 도착할 때 코스를 유연하게 조정할 수 있다.

 

이해 관계자는 유지하거나 진행 상황을 측정하거나 의견을 갖기를 원한다는 문제가 있다. 하지만 미래의 기능 목록을 제공할 수는 없다. 이것은 기존 로드맵이라고 부르는 것이다. 최고의 개발 팀조차도 이를 싫어하며 종종 제품 관리에 더 많은 '비전'을 요구한다.

 

따라서 로드맵에는 확실히 가치가 있다. 로드맵이 실제로 정확하지 않다고 거의 확신할 수 있는 경우에도 마찬가지다. 우리는 조정하고 수정할 수 있는 능력을 잃지 않으면서 이해관계자들에게 동일한 위안과 통제력과 진보를 가져다주는 무언가가 필요하다.

 

전통적 VS 현대적 로드맵

기존 로드맵을 분해하면 구성 요소를 명확하게 볼 수 있다.

전통적 로드맵

이러한 기능이 속하는 다양한 범주의 대상, 시기 및 개요. 기본적으로 임계 경로가 없는 GANTT 차트이다. 타임라인의 변경은 원하는 모든 것을 제공할 수 있는 능력의 변경을 의미한다. 따라서 모든 변경은 깨진 약속을 의미다.

Product Roadmaps Relaunched 에서 제공하는 최신 제품 로드맵의 예는 완전히 새로운 관점으로 이어질 수 있다.

현재적 로드맵

이 예제는 훨씬 더 유동적인 구성 요소 세트를 보여준다!

• 비전: 제품의 궁극적인 목표는 북극성이다.
• 비즈니스 의도: 더 나은 제품을 달성하는 데 도움이 되는 영역에 중점을 둔다.
• 제품 이니셔티브: 비즈니스 의도와 관련된 기능이다. 이것은 제안된 모든 이니셔티브에 즉각적인 의도를 제공한다. 비즈니스 목적에 부합하지 않는다면 왜 구축합니까?
• 광범위한 기간: 기능이 완료되는 시점을 정확히 지정하는 대신 현재, 다음 및 이후에 작업하려는 내용을 간단히 말한다. 이것은 상황이 변하더라도 가장 중요한 것에 대한 유연성을 제공한다.
• 옵션: 가치가 있지만 다른 가치 있는 항목이 발생하면 먼저 건너뛸 수 있는 항목이다.

이러한 항목은 클라이언트 기반(누구를 위해 구축하는가?), 종속성(이를 구축하기 위해 무엇이 필요한가?) 및 리소스에 대한 정보로 풍부해질 수 있습니다. 그러나 유연성을 유지하기 위해 가능한 한 높은 수준으로 유지한다.

산출물 대신 결과에 초점을 맞춘 이 로드맵은 기존 로드맵보다 훨씬 더 가치 전달과 연결되어 있다. 또한 낮은 수준의 기능 구현에 대한 무익한 논의를 피하면서 더 이상 고정되어 있지 않는다. 이는 조직과 고객이 마감 시간을 놓쳤거나 미완성된 백로그 항목에 대해 다투기보다는 상호 성공으로 가는 실제 방법에 대해 논의할 수 있음을 의미다.

로드맵을 수정하는 것은 백로그를 수정하는 것처럼 자연스러워야 한다. 계약과 같은 전통적인 로드맵은 그러한 목적에 적합하지 않다.

우리는 다른 무엇인가, 현대적인 제품 로드맵이 필요하다!

 

출처 : https://medium.com/codex/modern-product-roadmapping-8891aae9daf6