제품 작업을 중심으로 팀을 하나로 모으는 로드맵 만들기
로드맵은 제품의 현재뿐만 아니라 끊임없이 변화하는 방향에 따라 팀이 함께 나아갈 수 있게 해주는 역동적인 공유 도구입니다.
로드맵은 리더십부터 고객 대면 팀에 이르기까지 다양한 그룹에 우선 순위 및 우선 순위를 지정한 방식을 알려줍니다. 이렇게 하면 각 그룹은 제품 로드맵에 대해 고유한 관점을 갖고 향후 작업을 간편하게 구체적으로 시각화할 수 있게 됩니다.
계속 변화하는 우선 순위에 따라 로드맵 문서도 끊임없이 수정되고 업데이트됩니다. 하지만 계획이 달라지더라도 여전히 제품 여정을 위한 단일 정보 출처의 역할을 하며, 어떤 아이디어가 언제 실행될 것인지에 대한 현재의 비전을 공유합니다.
로드맵을 만드는 방법
로드맵을 만드는 방법에는 정답이 없습니다. 로드맵을 만들 때 겪는 많은 어려움 중 하나는 로드맵이 포괄적인 용어이므로 공동 작업, 커뮤니케이션, 우선 순위 결정, 우선 순위 전달, 기대치 설정 등 다양한 작업을 의미할 수 있다는 것입니다.
로드맵을 만드는 작업에는 주로 팀 및 회사 내 직원들이 참여하며 고객이나 파트너 같은 외부 관계자가 참여하는 경우도 있습니다. 참여하는 대상에 따라 각기 다른 형식 및 접근 방식이 필요할 수 있습니다.
그럼에도 기본적으로 참고할 수 있는 로드맵 만들기 모범 사례가 있습니다. 이 섹션에서는 효과적이었던 로드맵 만들기 기법 및 전략과 다소 미흡했던 사례를 공유하겠습니다.
좋은 로드맵을 만드는 요소
Jira Product Discovery 작업을 시작한 이래로 많은 로드맵을 살펴보았습니다.
성공적인 로드맵에는 몇 가지 공통된 특성이 있습니다.
- 최신 상태로 유지: 이는 무조건 지켜야 할 요소입니다. 다른 사람들이 로드맵을 참조하여 각자의 작업 방향을 정하고 중요한 결정을 내리기 때문입니다.
- 모두가 이해하는 용어 사용: “비즈니스 영향” 또는 “위험 수준”과 같은 모든 필드와 값에는 명확한 정의가 있어야 합니다. 이렇게 하면 대화에 집중하며 생산적으로 이끌 수 있습니다.
- 큰 그림 제시: 효과적인 로드맵은 공유하는 우선 순위의 “이유”를 설명합니다. 작업과 세부적인 실행 항목이 아닌 큰 그림에 초점을 맞춥니다.
- 결과와 목표에 기반: 성공적인 로드맵은 최종 목표를 보여줌으로써 대화의 흐름을 “X는 언제 제공되나요?”가 아닌 큰 그림으로 유도합니다.
- 현실적인 기대치 설정: 로드맵에는 허황된 약속이 아닌 각 아이디어에 대한 커밋 수준을 정직하게 나타냅니다.
- 간결한 모양: 모든 내용을 한 페이지에 담습니다.
로드맵이 효과적인지 확인하는 방법
로드맵이 효과적이라면 향후 제품 계획에 대한 셀프 서비스 방식의 단일 정보 출처가 됩니다.
- 로드맵이 셀프 서비스 정보 출처가 되므로 사람들은 어떤 제품이 언제 출시되는지 직접 물어볼 필요가 없어집니다.
- 팀원들은 전용 채널을 통해 새로운 인사이트와 아이디어를 독자적으로 공유합니다.
- 이해 관계자들은 가시성을 확보하기 위한 임시 프레젠테이션을 요청하는 대신 전용 로드맵 보기를 참조하게 됩니다.
모든 사람이 로드맵으로 직접 이동하여 질문에 답할 수 있으므로 우선 순위를 다시 살펴보고 반복하느라 시간을 낭비하지 않아도 됩니다.
더욱 전략적이고 생산적인 대화를 나눌 수 있습니다. 제품 팀은 자율성을 얻게 되며 각 팀원은 본래 채용된 목적, 즉 성과를 보여줄 수 있는 업무에 주력할 시간을 다시 확보하게 됩니다.
로드맵과 계획의 차이점
Jira의 계획에 연결된 Jira Product Discovery의 로드맵.
로드맵은 제품 백로그에서 만들어집니다. 이는 각 아이디어에 우선 순위를 지정한 방식과 이유를 전달합니다. 이 정보는 고객, 파트너, 회사 내 모든 사람과 손쉽게 공유할 수 있습니다.
→ Jira Product Discovery에 반영된 로드맵 확인.
그런 다음 Jira에서 이러한 아이디어를 실행하기 위한 계획을 세웁니다.
Jira 계획에 아이디어가 에픽 또는 이니셔티브 내의 필드로 표시됩니다. 각 아이디어를 사용자 스토리, 작업, 하위 작업으로 나누고 종속성, 제약 조건, 추정치를 고려하여 모든 것이 잘 어우러질 수 있는 방식을 계획합니다.
→ Jira에 반영된 제공 계획 확인.
Jira 계획의 아이디어 필드.
Jira 계획의 타이밍 및 종속성.
Jira 계획의 종속성.
Jira Product Discovery 및 Jira 계획이 함께 작동하는 방식
Jira Product Discovery 및 Jira 플랜이 함께 작동하는 방식을 설명하는 Loom:
여러 이해 관계자 그룹을 위한 다양한 로드맵
리더십부터 고객에 이르기까지 모든 이해 관계자 그룹은 각기 다른 질문과 우려 사항이 있을 것입니다. 이들과 효과적으로 커뮤니케이션하려면 제품 팀에서 다양한 로드맵을 마련해야 합니다.
Jira Product Discovery를 사용하면 수월해집니다. 로드맵을 여러 버전으로 만들 수 있으므로 매번 처음부터 새로 만들거나 변경 사항이 있을 때마다 모두 업데이트하지 않아도 됩니다.
각 이해 관계자 그룹에 맞춰 관련 데이터를 세분화하는 사용자 지정 보기를 설정할 수 있습니다. 보기는 동적으로 업데이트되므로 아이디어 하나를 변경하면 로드맵의 모든 버전에 자동으로 반영됩니다.
계속 쏟아지는 “X는 언제 제공되나요?”라는 질문을 더 이상 받고 싶지 않다면, 로드맵도 셀프 서비스 방식으로 만들어야 합니다. 모든 사람이 각자의 로드맵 링크를 통해 쉽게 액세스할 수 있는 방식으로 필요한 정보를 공유할 수 있어야 합니다.
Jira Product Discovery에서는 두 가지 방법으로 로드맵을 공유할 수 있습니다.
내부 이해 관계자를 프로젝트에 기여자로 초대하는 방법입니다. Jira 계정이 필요하지만 액세스 권한이 ‘기여자’ 역할로 제한된 경우 유료 라이선스가 필요하지 않습니다.
보기를 게시하고 내부 이해 관계자, 파트너, 고객, 최종 사용자 등 모든 사람과 공유하는 방법입니다. 이 보기는 읽기 전용이며 하나의 링크를 통해 회사 내부와 외부에서 쉽게 공유할 수 있습니다.
각 그룹에 대한 보기를 디자인할 때 그룹에 중요하다고 생각되는 질문은 미리 다루어 봅니다. 대상에 따라 다음을 강조하는 것도 좋습니다.
- 인사이트, RICE 점수, 영향 및 노력 비교 등 사용한 우선 순위 프레임워크
- 여러 분야에 걸쳐 투자 균형을 이룬 방법
- 각 아이디어에 대한 커밋 수준과 확실성
- 항목 상태에 대한 정보(계획대로 진행 중, 계획에서 벗어남, 위험)
- 커밋 수준 및 작업 수용량 지표
- 순서 결정에 대한 개념(특정 날짜 없음)
리더십 로드맵
리더십과 제품 팀은 일반적으로 주요 관심사가 다르며, 상황을 바라보는 세부 수준도 다양합니다.
제품 팀의 직위별로 다르게 적용되는 로드맵.
리더십 수준의 대화는 보통 목표, 투자 분야, 사용 가능한 리소스와 전략적 목표를 기반으로 각 아이디어에 할당된 작업 수용량에 초점이 맞춰집니다.
리더십 로드맵에는 팀원의 확실성 수준도 전달되어야 합니다. 예를 들어 급진적인 아이디어를 실현하려고 하지만 결과에 대한 확신이 없는 경우, 로드맵 항목을 안전한 투자와 즉시 구별할 수 있어야 합니다.
리더십과 공유하는 로드맵은 이 모든 정보를 명확하게 보여줘야 합니다.
이해 관계자의 관심이 기능 제공 시기에만 집중된 경우
기능이 제공되는 정확한 날짜를 알려주겠다는 약속은 지켜지지 못하게 되어 있습니다. 소프트웨어 엔지니어링은 예측 불가능한 프로세스이기 때문입니다. 로드맵을 만드는 대화에서 특정 날짜를 지정하면 무리한 기대치를 설정하게 되고 약속한 날짜를 지키지 못해 리더십 팀의 신뢰를 잃을 위험이 있습니다.
이렇게 입게 되는 손상은 복구하기 어려우며 사실상 특정 날짜는 그다지 중요하지 않습니다. 중요한 것은 업무의 영향력, 그리고 그 영향이 회사 성공에 얼마나 큰 도움이 되느냐입니다.
세부적인 실행 항목에 대해 고민하기 보다는 리더십 대화의 방향을 큰 그림으로 유도하는 것이 좋습니다.
다음과 같은 질문을 참조하세요.
- 현재 진행 중인 투자가 올바르다고 생각하십니까?
- 회사 목표에 대해 파악한 정보를 토대로 다른 영역에 투자해야 합니까?
- 현재 사용 가능한 리소스와 제약 조건을 고려했을 때 이러한 계획이 현실적으로 보여집니까?
새 로드맵을 만들 때마다 모든 이해 관계자가 생산성을 높일 수 있는 방식으로 기대치를 재설정하고 논의를 구성할 수 있습니다.
이해 관계자 그룹마다 우선 순위가 다릅니다. 좋은 로드맵을 사용하면 이해 관계자에게 중요한 것, 즉 이해 관계자의 목표, 그리고 이해 관계자가 달성하려는 결과를 중심으로 논의의 틀을 잡을 수 있습니다.
그런 다음 이해 관계자가 목표를 실현하도록 팀이 도울 수 있는 방법 및 위치를 중심으로 논의를 진행하면 됩니다.
Jira Product Discovery의 리더십 로드맵
Jira Product Discovery를 만드는 동안 2024년 중반에 Atlassian 리더십 팀에 공유한 로드맵은 다음과 같습니다.
Jira Product Discovery의 리더십 로드맵.
Jira Product Discovery의 리더십 로드맵에 있는 하나의 항목.
이 로드맵은 몇 가지 주요 문제를 강조 표시합니다.
- 기간: 향후 6개월에 대해서만 이루어진 확실한 이행 약속
- 예상 영향: 선택한 이유를 뒷받침하는 강력한 확신 및 근거
- 투자 수준: 팀이 각 아이디어에 투자할 리소스의 양
중요한 점은, 이 로드맵에 있는 모든 아이디어에 날짜가 언급되지 않았다는 것입니다.
제품 팀 및 스쿼드를 위한 로드맵
제품 팀 로드맵에서는 '예' 또는 '아니요'라고 대답할 내용이 분명하고 작업 순서가 명확해야 합니다. 항목을 개략적으로 유지하면서 제품 팀이 해결 중인 문제 및 그 문제가 기능으로 전환되는 방식을 보여줍니다.
이 보기의 목적은 Jira에서 일어나는 팀의 일상 업무를 안내하는 것이 아니라 팀이 맡은 미션을 명확히 이해하고 특정 문제를 효과적으로 해결하도록 돕는 것입니다.
Jira Product Discovery의 제품 팀 로드맵
다음은 Jira Product Discovery에서 작업 중인 한 스쿼드에서 공유한 로드맵입니다.
Jira Product Discovery의 스쿼드 로드맵.
Jira Product Discovery의 스쿼드 로드맵에 있는 하나의 항목.
보시다시피 Atlassian은 Jira Product Discovery에서 2가지 수준으로 구성된 로드맵을 사용합니다. 전체 제품의 로드맵 하나가 경영진과 공유됩니다. 그런 다음 보조 로드맵이 각 스쿼드의 범위를 표시합니다.
다음 두 개의 동영상에서는 Jira Product Discovery에서 2가지 수준으로 구성된 로드맵을 만드는 방법을 보여줍니다.
2가지 수준으로 구성된 로드맵 만들기 - 1부.
2가지 수준으로 구성된 로드맵 만들기 - 2부.
고객 대면 팀을 위한 로드맵
고객 대면 팀에는 고객과 공유할 수 있는 내용을 즉시 명확하게 파악할 수 있는 로드맵이 필요합니다. 즉, 다음 사항을 전달해야 합니다.
- 전념하려는 아이디어
- 제공하려는 기능 및 아이디어와 제공 시기
- 이행 약속에 대한 확실성 수준
확실성 수준과 함께 이행 약속을 반드시 자세히 설명해야 합니다. 그렇지 않으면 고객은 지킬 수 없는 날짜 및 마감 날짜를 기대하거나, 제공되지 않을 기능을 약속받았다고 오해할 수 있습니다.
고객 대면 팀을 위한 Jira Product Discovery 로드맵.
고객 및 최종 사용자를 위한 로드맵
공개 로드맵은 제품의 향후 계획을 공유하고 유용한 피드백을 장려하여 고객 신뢰를 높이고 관계를 강화할 수 있습니다.
특히 엔터프라이즈 고객은 제품을 구입할 때 장기적인 여정을 시작한다는 것을 잘 알고 있으며, 그 여정이 향하는 방향을 알고 싶어 합니다.
하지만 이러한 개방성에는 단점도 있습니다. 제품 팀이 더 많은 감시 및 압박을 받게 된다는 점입니다. 로드맵을 변경할 경우 고객은 우선 순위의 변화 또는 예측할 수 없는 문제 때문이라고 생각하기보다 약속을 어긴 것으로 여기고 실망감을 느낄 수 있습니다.
이로 인해 제품 및 개발 팀에 대한 신뢰가 떨어질 수 있습니다. 따라서 시나리오에 맞게 장단점을 잘 따져야 합니다.
Jira Product Discovery를 사용하여 고객 및 최종 사용자와 로드맵을 공유할 수 있는 방법은 다음과 같습니다.
- 전체적으로 공개하는 대신 특정 사용자만 보도록 안전하게 공유할 수 있는 보기를 만듭니다.
- 온라인에 게시하여 누구나 액세스할 수 있는 진정한 공개 로드맵 보기를 만듭니다.
- 로드맵을 게시할 때는 다른 도구를 사용하되 공개적인 이행 약속을 제품 백로그에서 추적합니다. 그러면 우선 순위를 재작업할 때 어떤 이니셔티브를 약속했는지 알 수 있습니다.
Atlassian Cloud 공개 로드맵
Atlassian에서는 엄선된 Cloud 제품을 위한 공개 로드맵을 게시합니다.
Atlassian Cloud 공개 로드맵(2024년 5월).
Atlassian Cloud 보안 팀이 이 로드맵에 많은 기여를 합니다. Atlassian Cloud 보안 팀은 Jira Product Discovery 프로젝트에서 특정 보기를 사용하여 공개적인 이행 약속을 추적합니다.
고려해야 할 로드맵 형식
엄밀하게 선형적인 로드맵은 오해의 소지가 있습니다. 미래를 더 멀리 내다볼수록 이행 약속의 확실성은 낮아집니다. 효과적인 로드맵은 그 점을 반영해야 합니다.
대신 로드맵을 정직하고 전략적으로 만드는 것을 목표로 하세요.
오해의 소지가 있는 로드맵, 정직한 로드맵 및 전략적 로드맵. 출처: @spavel.bsky.social🐀(Twitter/X)
데이터를 사용하여 팀이 반복 중인 작업 및 작업 목표를 스토리로 전달하는 최적의 로드맵 형식을 설계할 수 있습니다.
하지만 영감을 얻을 수 있는 기본 로드맵 형식이 몇 가지 있습니다. 다음은 Atlassian 고객이 자주 사용하는 몇 가지 형식입니다.
결과 기반 로드맵
훌륭한 로드맵은 제품 팀이 달성하고자 하는 결과를 명확히 보여주고 그 결과에 도달하기 위해 노력하는 방법을 알려줍니다.
예를 들어, Jira Product Discovery 리더십 로드맵이 있습니다. 이 로드맵은 모든 스쿼드에 걸쳐 전체 제품에 대한 투자를 어떻게 생각하고 있는지 자세하게 설명합니다.
이 형식은 Atlassian 팀에게 효과가 있었지만, 제대로 해내기 위한 단 하나의 공식만 있는 것은 아닙니다. 실험을 통해 로드맵이 논의를 이끄는 방식을 살펴보고 각 조직에 맞는 방식을 찾아보세요.
Jira Product Discovery의 결과 기반 리더십 로드맵.
현재/다음/나중 로드맵
현재/다음/나중 로드맵은 팀의 확신 및 각 이니셔티브의 확실성 수준에 맞춰 모두를 정렬시키고, 작업 순서에 대한 아이디어를 제공할 수 있는 효과적인 방법입니다.
이 로드맵 스타일은 결과, 불확실성 및 역량에 대한 논의에 집중하기 때문에 제품 팀 사이에서 매우 인기가 있습니다. 하지만 Gantt 차트 같은 기타 일반적인 형식과 달리 현재/다음/나중 로드맵은 제공 세부 정보 및 날짜에 얽매이지 않습니다.
Jira Product Discovery 팀은 각 스쿼드별 로드맵에 다음 형식을 사용합니다.
Jira Product Discovery의 현재/다음/나중 스쿼드 로드맵.
현재/다음/나중 로드맵에서 흔히 빠지는 함정은 '이 작업을 먼저 하고, 이 작업은 다음에 하고, 이 작업은 나중에 하겠다'는 의미로 해석하는 것입니다. 모든 항목을 결국 제공하는 이행 약속으로 인식하는 것입니다. 이는서 지나친 단순화입니다.
대신, 다음과 같이 생각해 보세요.
- 현재: 검증된 기회이며, 팀이 솔루션을 적극적으로 검증 중이거나 이미 검증된 솔루션을 구현 중. 탐색, 제작 및 영향 단계의 아이디어.
- 이 아이디어는 제공하거나, 솔루션을 검증할 수 없는 경우 '다음' 열로 넘어가거나, 배운 점을 바탕으로 완전히 포기할 수 있습니다.
- 다음: 검증된 기회이며, 팀이 이에 대한 잠재적 솔루션을 잘 이해하고 있음. 탐색 단계의 아이디어.
- 이 아이디어는 '다음' 열로 이동하거나 더 유망한 솔루션을 찾기 위해 '나중'으로 넘어가거나 배운 점을 바탕으로 완전히 제거될 수 있습니다.
- 나중: 검증된 기회이며, 팀이 이에 대해 아직 잠재적 솔루션을 평가 중. 발견 또는 탐색 단계의 아이디어.
- 이 아이디어는 '지금' 또는 '다음'으로 넘어가거나 '나중'에 남아 있거나 배운 점을 바탕으로 로드맵에서 제거될 수 있습니다.
시간 기반 로드맵
Gantt 차트는 제품 로드맵에서 절대 금물입니다. 이 차트는 결과 또는 '애초에 X를 작업하는 이유'와 같은 질문에 집중하기보다 산출물 또는 가장 우려되는 질문인 'X를 제공하는 날짜'와 같은 엉뚱한 질문에 대화를 집중합니다.
그렇다고 시간 기반 로드맵을 완전히 무시해야 한다는 뜻은 아닙니다. 다른 팀이 나의 업무에 의존하거나 마케팅 및 고객 대면 팀과 정보를 공유할 때는 여전히 유용할 수 있습니다. 로드맵에 접근하는 모두가 각 아이디어에 대한 신뢰 및 약속의 수준을 이해하기만 하면 됩니다.
Jira Product Discovery 팀에서는 시간 기반 로드맵을 사용하지 않습니다. 날짜를 중심으로 한 논의가 제품 결정에 가장 비생산적이라는 사실을 경험했기 때문입니다. 하지만 시간 기반 로드맵을 사용한다면 다음과 같이 사용할 것입니다.
시간 기반 로드맵의 예.
시간 기반 로드맵을 설계할 때는 주의하세요. 먼 미래에 확실성을 투영하고 불합리한 기대치를 설정하기 쉽습니다.
다음 로드맵은 오해를 부를 가능성이 높습니다. 마치 팀이 향후 6개월에서 1년 후에 일어날 일을 명확하게 알고 있는 것처럼 보이기 때문입니다.
이해 관계자가 시간 기반 로드맵을 요구한다면 현재/다음/나중 로드맵을 타임라인과 결합하여 다음과 같이 더욱 솔직한 이야기를 들려주는 것이 좋습니다.
- 현재/다음/나중 로드맵은 팀이 약속할 수 있을 만큼 확실성이 높은 사항을 명확히 보여줍니다
- 타임라인의 '현재' 열에 아이디어만 표시하여 구현이 이루어질 특정 달 또는 분기를 대략적으로 보여줍니다
- '다음' 및 '현재' 열에 있는 아이디어는 이행하기 어려운 약속을 하지 않아도 일반 계획 내에서 찾을 수 있습니다.
현재/다음/나중 로드맵의 타임라인 보기.
타임라인 보기를 너무 세분화하지 마세요. 구체적인 날짜 및 작업보다는 중요한 아이디어에 초점을 맞춰야 합니다. 타임라인의 목표는 이해 관계자들에게 일상적인 업무를 세세하게 보여주는 것이 아닌 앞으로 나아갈 방향에 대한 전반적인 개요를 제공하는 것입니다.
Jira Product Discovery의 타임라인 보기 및 날짜
다음은 기간이 각기 다른 로드맵을 만드는 두 가지 방법을 설명하는 데모입니다. 두 번째 보기가 더 많이 사용됩니다.
날짜 설정의 문제점은 제공 과정에서 알게 된 내용에 따라 날짜가 쉽게 변경될 수 있다는 것입니다. 이 보기에서 아이디어에 해당하는 제공 티켓이 있으면 그 아이디어의 날짜 필드가 자동으로 에픽/이니셔티브의 날짜 필드로 재정의되도록 구성할 수 있습니다.
이렇게 하면 작업 중 에픽에 발생하는 모든 변경 사항이 로드맵에 즉시 반영됩니다.
Jira Product Discovery의 로드맵 내 동적 타임라인 보기 .
Jira Product Discovery의 Jira 에픽에서 날짜를 가져오도록 구성된 날짜 필드 하나.
제품 이니셔티브 대시보드
이 제품 전체 로드맵 형식을 사용하면 계획 중이거나 진행 중인 모든 제품 이니셔티브를 한눈에 볼 수 있습니다. 이 형식은 엔지니어링 리더십과 공동 작업할 때 특히 유용합니다.
이 로드맵은 항상 제품 백로그에 보관하는 것이 좋습니다. 탐색 및 제공 업무는 서로 연결되어 있지만, 명백히 탐색 영역(잠재적 솔루션 평가)에 속하는 업무가 있고 제공 영역(스프린트 실행)에 속하는 업무가 있으며 두 업무를 이어주는 영역(기술 부채 및 새로운 기능의 우선 순위를 지정하는 방법 결정)에 있는 업무가 있습니다.
이 로드맵 형식은 제품 백로그를 우선시할 때 이러한 범주 전반의 투자를 시각화하기에 좋은 방법입니다.
