최근 회사에서 로드맵을 작성할 일이 생겼다.

이전까지는 클러스터링 전략, 클러스터 구성 변경에 따른 리펙토링 등 제품 전략에 따른 로드맵을 어떻게 실제로 처리할 지 생각해봤다면, 이번 기회를 통해서 여러 이해관계속에서 서로가 이해되는 전략을 구성하는 것에 대해서 생각을 하게 되었는데, 아직 매우 복잡하게 느껴졌다.

이전 사내 자료에서 글로 작성된 로드맵을 보았다. 어떻게 제품을 팔 것이며, 이해관계자는 니즈가 어떤 것이 있을 것이며, 기술 스펙을 어떻게 잡아나갈 것인지에 대한 자료가 정리되어 있었다. 그런 정보들을 보면서 아직 내가 작성한 로드맵에는 부족한 것이 많고, 어떤 점을 필요로 하는지 관심이 가서 이번 책에 눈이 들게 되었다.

윌 라슨의 엔지니어링 리더쉽 책에서 본 책을 읽을 때 추천하는 방식은 실제로 문제가 있는, 혹은 필요로 하는 부분이 있으면 그때마다 책을 들여야 보라는 것이였다. 이런 부분은 왠지 The Goal 과 마찬가지로 그때 필요한 것들을 직접 부족한 면들을 스스로 깨달아 가면서 인사이트를 얻고, 스스로의 환경에 맞춰 깊은 생각을 하게 된다는 장점이 있는 것 같다.

내가 읽은 부분은 C3) 엔지니어링 전략 세우기, C4) 계획하는 방법 에 대해서 읽어봤다.

엔지니어링 전략 세우기에서 처음부터 어떻게 로드맵을 작성할 지 기술할 줄 알았는데, 의외로 엔지니어링 전략 자체를 문서화하자는 내용이였다. 로드맵과 비슷하겠지만, 상황 인지, 정책 지침, 일관된 행동 등 엔지니어링 전략 차제를 문서화 하는 것이였다. 엄청 간단하게 예를 들면, 안정화 정책을 몇년간 고수했지만, 잘 되지 않으니, 제품 엔지니어링/인프라 엔지니어링 비율을 4:1로 유지하고 이를 위해서 비율에 맞게 채용 또는 팀 재편성 등의 전략이다. 방법중에 하나겠지만, 이러한 전략 자체를 문서화하고 그 전략을 기반으로 로드맵 등을 작성하는 것도 업무의 피로도를 줄여주는 방법이라고 생각된다.

계획하는 방법 에서는 재무계획, 기능적 포트폴리오 할당, 로드맵 순서로 계획을 작성하는 법을 보여줬다.

임원이 되기 전까지는 사실 재무 계획에 대해서 접할 기회가 없다. 엔지니어링 관점에서 볼 때 다행인 점은 재무 계획을 직접 책임지는 것이 아니라 하나의 이해관계자로 참여한다는 것이다.

• 엔지니어링 조직 내 인건비
• 운영 비용
• 개발 비용

등을 예로 들었다.

기능적 포트폴리오 할당 은 사실 별로 와닿지는 않았지만, 외부 작업과 내부 작업의 할당량을 고루 분배하는 것이다. 어떤 작업을 우선순위로 두고 작업할 것인지 였는데, 나의 경우에는 대부분의 경우 외부 작업이 우선 순위가 높아 할당량과는 별개로 먼저 작업을 하는 경우가 많았던 것 같다.

드디어 로드맵, 여기에서는 의외로 로드맵 작성에 실패하는 사례들을 나열했다…

• 로드맵 작성과 예산/기능별 포트폴리오 할당 변경을 결합하여 작성
• 제품과 엔지니어링 관련 부서 그리고 이해관계자 간의 갈등
• 구체적이지 않거나 범위가 정해지지 않은 프로젝트를 혼합하여 로드맵 작성
• 너무 세세하게 계획을 세워 팀의 권한을 약화

형식은 너무 많아서 로드맵을 작성하는데 참고할 것은 많지만, 이걸 로드맵에 참고했더니 실패더라 라는 것만 나열했다고 얘기한다.

목표는 확실하게, 세부 목적은 논의로, 로드맵은 주기적으로 작성해서 업데이트 하는 방식을 추구하는 것으로 보인다.

이 책을 읽고 내가 좀 더 개선해야 하는 점은 로드맵의 목표에 있어서 각 이해관계자의 갈등이 적도록 이해시킬 요소들을 좀 더 작성해야 할 것 같다. 실패 사례 및 함정만 읽어서는 많이 작성해본 편이 아니라서, 감이 와닿지는 않고, 더 수정할 시간도 부족하지만, 이번 발표 이후에 드는 생각을 정리해보는 것도 내 엔지니어링 성장 요소에 포함될 것 같다.