제품 관리자를 위한 제품 배포 계획수립 문서를 Confluence로 작성하는 방법을 확인해 보십시요

제품 관리자를 위한 배포 계획 수립 안내서

어릴 때 우리 스키 코치는 항상 '계획하지 않으면 실현되지 않는다'라고 말하곤 하셨습니다.

그는 우리가 목표를 세우고 그 목표에 도달하기 위한 경로를 설계하라고 하셨습니다. 소프트웨어 구축에도 같은 정서가 적용될 수 있으며, 소프트웨어 구축은 스키와 비교하면 팀이 훨씬 중심이 되는 스포츠이긴 합니다. 팀 동료들은 물론 마케팅 및 기술지원 등 관련 업무를 담당하는 이해관계자들에게도 내가 무엇을 왜 구축하려 하는지, 예상 소요시간은 어느 정도인지, 배포 시까지 프로젝트를 어떻게 추적할 것인지를 반드시 알려야 합니다.

팀이 지리적으로 분산된 경우, 계획 수립과 소통은 더욱 어려워지고 프로젝트의 성공에도 더 중요한 요소로 작용하게 됩니다. 이때 중앙 집중식 배포 계획 수립 페이지가 필요합니다.

Atlassian의 팀들이 사내 위키에서 페이지를 사용하여 기능 배포 계획을 수립하는 방식을 알려드리겠습니다. 내부 위키는 현황 파악이 필요한 모든 사람과 해당 팀이 접속할 수 있는 중심 공간 내에 모든 관련 정보를 정리합니다.

이런 방식으로 계획을 세우고 소통하면 한 번에 많은 문제를 해결할 수 있습니다.

• 개발자들은 정보를 검색하는 데 시간을 낭비하지 않습니다. 제품 요건 및 디자인은 한 공간에 취합되며, 쉽게 이용할 수 있도록 이슈에 링크됩니다.
• 임원진 현황보고 회의는 더 이상 필요 없습니다. 이해관계자들이 프로젝트 현황을 직접 확인할 수 있어서 매주 1시간씩 시간을 벌 수 있습니다.
• 부주의로 빠지는 것도 없습니다. 해당 페이지가 세부사항을 '기억'해서 나는 어머니 생일에 꽃다발 보낼 일 같은 것만 기억하면 됩니다.

일종의 홈 기반 역할을 하는 고급 개요 페이지로 시작한 후, 하위 페이지에서 세부 작업을 하게 됩니다. 다음 4가지 단계에 따라 효율적이고 투명한 소프트웨어 프로젝트 계획을 세울 수 있습니다.

1단계: 아이디어 수집('왜')

단순 기능이건 신제품 출시건 모든 소프트웨어 프로젝트에는 수많은 요소가 투입됩니다. 영감을 주는 제품 및 디자인에 끊임없이 링크를 공유하고, 고객들의 피드백을 구해 공유하며, MVP(최소 존속 제품)를 함께 해킹합니다.

사내 위키에서 이 모든 아이디어에 관한 피드백을 공유하고 제공함으로써 필요할 때 언제라도 해당 아이디어 및 관련 논의 내용을 참조할 수 있도록 하고 있습니다.

(Confluence를 만들기 때문에 자연스럽게 위키를 툴로 사용하고 있지만, 여러분 각자 팀에서 사용하는 위키 또는 인트라넷 툴을 사용하시면 됩니다.)

새로운 기능에 대한 계획 수립을 시작할 때 우리는 모든 관련 배경 정보를 한 페이지에 수집합니다.

제품 관리자는 수집된 배경 정보를 토대로 우리가 고객을 위해 어떤 문제를 처리하는지와 그 처리 이유를 판단합니다.

실제로 이 페이지는 배경 정보 조사 요약 및 추가자료(고객 인터뷰 내용, 시장조사 결과, 경쟁사 분석 결과, 기능 요청서 등) 링크, 해당 기능의 고급 가치에 대한 제안서로 이루어져 있습니다.

이 배경 정보 페이지는 배포 계획 수립 페이지의 하위 페이지이므로 나머지 배포 정보와 함께 취합되며 참조 경로 단축을 위해 계획 수립 페이지 상단에서 자동 링크됩니다.

제품 관리자는 이 페이지를 개발 관리자 및 팀원들과 공유해 그들에게 필요한 기초정보를 제공할 뿐만 아니라 피드백을 주고 문제점 및 기회에 대한 가정과 평가를 테스트할 기회를 제공합니다.

이 페이지는 하나의 살아 있는 문서이기 때문에 팀원들은 다른 관련 정보에 대한 링크를 추가할 수 있으며 PM은 필요에 따라 제안서를 수정할 수 있습니다.

모두가 배경 정보에 어느 정도 동의하면 그 다음 단계는 배포 계획 관련 대략적인 윤곽을 그리는 것입니다..

2단계: 배포 계획 윤곽 스케치('누가' 그리고 '언제')

그다음 체크 포인트는 이 기능을 고객에게 제공하는 데 필요한 조건과 배포 예정 시기를 설정하는 것입니다. 이 단계에 수행할 작업은 다음과 같습니다.

• 팀 정의. 누가 디자인, 구축, 마케팅, 기술지원을 담당할 것인가?
• 목표와 비 목표(non-goals)를 분명히 표현. 내가 할 일은 무엇인가? 내가 하지 않을 일은 무엇인가(마찬가지로 중요함)?
• 로드맵 구축. 목표를 어떻게 달성할 것인가?

이 모든 사항을 배포 계획 페이지에 포함해 나 자신과 팀원들에게 지속해서 상기시키고 내 프로젝트에 관심 있는 다른 사람들이 쉽게 참조할 수 있도록 해야 합니다. 해당 페이지는 다음과 같은 모습일 것입니다.

하나씩 보겠습니다.

팀

우리는 개발자부터 마케팅 담당자, QA, 기술지원까지 고객에게 가치를 전달하는 데 필요한 여러 직능에 따라 섹션을 나누어 해당 팀 관련 정보를 표에 기록합니다.

이렇게 하면 한 사람도 빠지지 않으며, PM에게 관련 제품 마케팅 담당자와 점검하라고 상기가 되며, 지원 엔지니어가 버그 관련 자세한 정보가 필요할 때 연락해야 하는 개발자를 파악할 수 있습니다(버그를 보내는 일은 절대 없으니 안심해도 됨  ).

각 팀원의 프로필 사진을 등록하여, 분산 배치된 팀과 일할 경우 특히 한 번도 직접 만난 적 없는 동료와 더 친밀하게 작업할 수 있도록 하고 있습니다.

목표와 비 목표

그 다음은 내 목표와 함께 이번 배포에서 처리하지 않기로 한 관련 항목들을 설정합니다.

이렇게 하면 집중해야 할 부분이 분명해지고 범위 추가를 피할 수 있습니다. 중요 항목만 간단히 차례대로 나열하면 됩니다.

시각적 서식에는 신경 쓰지 않아도 됩니다. 분명하고 간결하며, 어느 정도 괜찮은 수준이면 됩니다.

로드맵

배경 정보, 제안서, 팀, 목표 및 비 목표를 설정한 후에는 프로젝트 로드맵의 윤곽을 그려야 합니다. 목적은 다음과 같습니다.

• 즉각적인 정상성 점검. 제시된 일정으로 업무 흐름을 시각화하면 일정 안에 목표를 달성하는 것이 현실적인지 파악하는 데 도움이 됩니다.
• 명확한 우선순위. 업무 흐름 실행 범위를 확대해 순서를 설정하면 팀원들이 프로젝트의 우선순위와 흐름을 파악하는 데 도움이 됩니다.
• 소통은 셀프서비스. 이해관계자들이 내 자리에 들러 직접 묻지 않고도 배포 일정에 대해 전반적으로 파악할 수 있습니다.

화이트보드나 스티커 메모지를 이용해 윤곽을 그린 후 사진을 찍는 방법도 있지만, 우리는 Confluence의 로드맵핑 툴을 선호합니다.

이 툴을 사용하면 로드맵을 간편하게 수정할 수 있으며, 추가적인 배경 정보가 있는 페이지에 로드맵 항목을 링크할 수도 있습니다. 또한, 로드맵을 메인 계획설정 페이지에 올립니다. 해당 페이지를 통해 대략적인 배포 일정이 페이지 접속자들에게 전달되기 때문입니다. (참고: 각 배포에 대한 데이터 중심 용량 계획이 완료되면, JIRA Portfolio로 가서 주어진 리소스로 계획을 실행하는 것이 정말 가능한지 확인합니다.)

이때 팀원들과 제품 리더(product leader) 등 이해관계자들과 해당 계획을 공유하여 피드백을 요청할 수 있습니다. 그들에게 계획에서 허점을 찾아내 개선방법을 제안해달라고 요청합니다.

원하는 순서대로 정말 필요한 문제를 처리하고 있습니까? 로드맵이 현실적입니까? 팀을 올바르게 구성했습니까? 몇 차례 반복해보고 목표 및 로드맵을 적절히 수정하면 됩니다.

3단계: 아이디어를 행동으로 현실화('무엇')

계획에 대한 동의를 얻은 후에는 해당 계획을 실천할 수 있도록 만들어야 합니다.

개발팀이 개발 시 반영할 제품 요건을 작성해야 한다는 뜻입니다. 전에 요건에 대해 쓴 적이 있으므로 여기서는 해당 작성 방법에 대해 논하지 않겠습니다.

중요한 것은 전체 배포 계획 수립 시 제품 요건을 계획 일부로 포함해야 개발자들이 이를 쉽게 참조하고, 다른 사람들이 필요할 때 프로젝트에 관한 세부사항을 확인할 수 있다는 것입니다.

우리는 간단한 제품 요건 문서를 작성하여 이를 내부 이슈 추적기의 사용자 스토리 요건에 연계시킵니다.

이 단계에서 다시 피드백을 요청해야 합니다. 코멘트를 남기는 방법으로 특정 요건에 대해 간편하게 설명이나 개선방법 제안을 요청할 수 있습니다.

요건은 자동으로 이슈에 링크되기 때문에 개발자들이 필요할 때 추가적인 맥락 정보에 빠르게 접근할 수 있으면서 스크럼 보드가 불필요한 내용으로 채워질 일도 없습니다.

반면 각 이슈 현황이 제품 요건 문서에 자동으로 업데이트되기 때문에 제품 관리자는 개발자를 성가시게 하거나 보고서를 실행하지 않고도 각 기능에 관한 변경사항을 언제든 확인할 양측 모두 자체로 해결되므로 시간을 절약하고 혼란을 줄일 수 있습니다.

4단계: 현황보고 회의 취소(와우!)

처음 세 단계에 충실하면 클릭 한 번에 배경 정보 및 목적 등을 포함한 내 프로젝트 내용을 확인할 수 있는 일련의 계획 페이지가 완성됩니다.

세밀한 부분까지 알고 싶은 경우를 위해 프로젝트의 에픽(epic) 및 개별 이슈로 연결되는 링크가 제공됩니다.

이 과정을 통해 프로젝트를 명확하게 정리하면서 올바른 방향으로 진행되고 있는지 확인할 수 있습니다. 따라서 나 자신과 팀원들이 시간을 절약하고 걱정도 덜 수 있게 됩니다.

• 제품 및 개발 관리자는 배포 관련 모든 면이 고려되도록 배포 관련 세부사항을 한 곳으로 취합합니다.
• 개발자는 배경 정보, 제품 요건, 디자인 등 필요한 모든 리소스를 이슈에 연결하여 자세히 분석하고 코딩할 수 있도록 합니다.
• 이해관계자들은 나의 페이지를 통해 프로젝트 및 프로젝트 현황을 전반적으로 잘 파악할 수 있습니다.

사람들이 질문이 생길 때마다 이메일이나 IM으로 물어보려는 본능을 고치는 데는 시간이 걸리겠지만, 중앙 리소스 한 곳에서 필요한 답변을 얻을 수 있다는 것을 알게 되면 사소한 질문이나 주간 현황 업데이트 요청 등으로 여러분을 성가시게 하는 일은 더는 없을 것입니다.

배포 계획 수립 웹 세미나에 참석하세요.

아직도 각 질문 및 현황 업데이트 관련 이메일이나 회의 내용에 따라 연관성 없는 수많은 텍스트 문서와 스프레드시트로 프로젝트 계획을 세우고 계신다면 이제 바꿀 때가 되었습니다. 

아래 세미나 내용을 확인해 보십시요.