프로덕트 전략에서 프로덕트 로드맵으로
<프로덕트 리더십>을 읽고 생각 정리하기
이 글은 지난 글에 이어 <프로덕트 리더십>의 3장 '훌륭한 프로덕트 리더' 중에서 88~92쪽에 등장하는 '전략에서 로드맵으로 전환'을 소화하며 느낀 내용을 씁니다.
변화에 대한 두려움과 개선(?)의 기쁨
제조법에 지나치게 충실해서 정해진 프로세스에만 매달리면, 개선의 기회나 기쁨의 순간을 경험할 수 없게 된다. 이것이 바로 최고의 요리사가 엄격하고 규율 있는 주방을 운영하는 동시에 실험과 개선을 위한 공간을 만드는 이유다.
자주 보던 표현이라 그런지 문자 그대로 이해보다는 작업자 내면의 감정과 작용으로 생각이 미쳤습니다. '제조법' 혹은 '정해진 프로세스'가 조직 수준에서도 존재하지만 개인 차원에서도 존재합니다. 자기 루틴이라는 것이 있는 경우가 많고, 분명하게 보이지는 않지만 변화에 대한 저항도 어렵지 않게 발견할 수 있습니다.
최근에 MSA 기술 이전 사업 중에 경험한 내용 중에 주로 외주 개발 영역에서 일했던 개발자들이 기피하는 패턴이 보였습니다.
테스트 자동화 코드 작성 (백엔드는 짤 수 있지만, 프론트는 ...)
새로운 언어(코틀린 채용)나 프레임워크
반면에 배우고자 하는 의지가 분명한 신입사원은 시간은 더딜지 몰라도 거부감 없이 받아들였습니다. 같은 이유로 조환 님은 팀원을 모두 연차가 길지 않은 이들만 뽑았다고 합니다. 이러한 내용은 책 내용과는 거리가 있습니다만, 변화에 대한 거부감을 극복하고 긍정적인 상태를 유지할 수 있어야만 변화하는 시장에서 살아남는 프로덕트를 만들 수 있습니다.
템플릿이나 프레임워크와 같은 프로세스
그렇다고, 변화의 파급효과가 일파만파로 퍼지는 상황이라면 아무리 도전 의식을 가진 사람이라도 지칠 수밖에 없을 듯합니다. 그래서 '엄격하고 규율 있는 주방'에 비유한 것이 아닌가 싶습니다. 저런 주방을 떠올리면 저는 만화 원피스에서 상디가 있던 주방이 생각납니다. 그런 엄격함은 부작용을 막는 장치들입니다. 아이러니하게 엄격한 프로세스가 실험을 감행할 때 부작용을 최소화하여 자유도를 주는 면도 있습니다.
스프링 프레임워크에서 널리 쓰이는 템플릿 메소드 패턴 등을 보면, 딱 필요한 부분에만 변화를 줄 수 있도록 제한하는데 주방의 비유와 함께 떠올리게 됩니다. 어떤 점에서 스프링은 유사 패턴의 조합으로 만들어진 프레임워크인데, 프로세스를 코드 덩어리로 구현한 것이라 할 수 있습니다.
프로세스를 생각하고 구현할 때에도 어떤 부분이 수정이 가능하게 하고, 어떤 부분은 그렇지 못하게 막을지 등을 생각하는 일은 매우 중요합니다. 이는 프로세스의 활용도나 수명을 결정하기도 하죠.
로드맵은 프로덕트 작업에 어떤 도움을 주나?
최근에 우리가 하는 일 중에서 이슈가 많은 프로젝트를 개선하는 일이 있습니다. 프로덕트를 만드는 상황은 아니지만 한 달간의 노력으로 우선 13개의 이슈 목록을 뽑았습니다. 이걸 기준으로 누가 어떻게 할 것인지 그리고 해결안을 무엇인지를 논의하고 있는데, 이슈 목록을 로드맵의 기준으로 삼은 일이라고 볼 수도 있겠습니다.[1]
아무튼 저자는 6가지 측면으로 로드맵의 이점을 정리하였는데, 이를 간단히 요약한 리스트입니다.
포커스: 오직 최고의 업무만 실행하기 위해 초점이 필요하다. 로드맵은 주의를 잃지 않게 돕는다.
역할 조정: 팀 전체가 같은 목표를 향해 노력하게 한다.
우선순위: "그건 우리의 성공에 중요하지 않아"
가시성: 잠재적 문제와 기회를 시각화
협업: 팀원 모두가 자신의 기여가 다른 사람들과 어떻게 공존하는지 알아야 한다. 팀이 리듬에 맞춰 협업하는 것은 추진력을 만들고 유지하는데 중요하다. (중복된 업무와 잘못된 계획으로 취소된 업무는 스트레스와 낭비 초래)
비전
비즈니스 가치의 증가와 개발 결과의 출시를 일치시키기
협업을 설명하는 문구를 보니 Cadence란 표현이 떠오릅니다. 로드맵을 명시적으로 만들어 쓰고 있지 않지만, ART를 차용하는 탓인지 동료가 SAFe의 개념인 Cadence란 표현을 종종 썼습니다. 아래 그림을 보면 CI가 개발자 수준에서의 통합을 만들어 낸 개념이자 활동이라면 Cadence는 비즈니스 가치 확인까지 층을 얹은 진일보된 개념이자 활동이란 점을 볼 수 있습니다.[2]
하지만, 주의할 사항은 로드맵과 출시 계획이 같은 것은 아니란 점입니다. 개념적인 이정표와 구체적인 실행 일자를 동일시하면 폭력적인 직무 공간과 경직된 소통이 발생하기 쉽습니다. 모든 도구가 그러하듯 '용어'나 '개념' 역시 목적에 맞게 써야 합니다. 이에 대해 저자는 다음과 같이 충고합니다.
로드맵은 출시 계획과 완전히 분리된 문서로 언제, 누가 무엇을 실행할지를 서술하는 내용은 포함하지 않는다.
비전 구체화와 출시 계획을 위한 모델
저자는 또한 로드맵에 대한 오해를 막기 위해 다음과 같은 부연을 하고 있습니다.
로드맵은 출시 계획이 아니다. 특정 날짜와 타임라인을 생략하자.
기능이나 구성 요소 목록이 아니며
헌장이 아니다. 새로운 정보에 반응하는 살아 있는 가이드다.
로드맵 수준의 계획에는 종속성과 상하 연결이 작동하지 않는다.
꽤 괜찮은 실용적인 설명이란 생각이 듭니다. 더불어 '느슨한 결합'이라는 제가 좋아하는 표현도 떠오릅니다. 비전이라는 확고한 방향성에 대해 각자 역할에 맞춰 나아갈 수 있도록 느슨한 결합을 만드는 (개념적) 도구가 로드맵이란 생각이 듭니다. 더불어 역할별로 할 일이 달라지는 출시 계획을 논하기 위한 모델 역할도 해 주는 듯합니다.
로드맵은 팀의 방향에 대해 이해하고 협상하는 과정이다. 문제와 문제 해결을 완료하기 위한 프로세스, 그것이 진정한 목적이다. <중략> 각 팀 소유의 유기적이고 생생하며 협업적인 트렐로 모드로 만들어 훨씬 유용하게 활용할 수 있다.
주석
[1] 물론, 로드맵을 떠올린 것은 아니고 현장의 문제를 해결하려고 논의하고 고안하 결과물로 도출할 것입니다.
[2] 물론, 모두에게 보이지는 않겠지만, 나에게는 분명하게 보인다.
지난 <프로덕트 리더십>을 읽고 생각 정리하기
