애자일 로드맵: 만들기, 공유, 사용, 발전

요약: 제품 로드맵은 시간이 지나면서 제품 또는 솔루션이 어떻게 발전할 것인지에 대한 실행 계획입니다. 제품 팀은 로드맵을 사용하여 향후 제품 기능과 새로운 기능이 출시될 시기를 개괄적으로 설명합니다. 애자일 개발에 사용되는 로드맵은 팀의 일상 업무에 중요한 컨텍스트를 제공하며 경쟁 환경의 변화에도 대응할 수 있어야 합니다.

애자일 개발 방식에는 장기 계획이 없다는 주장은 네스호의 괴물 이래로 가장 허황된 생각일 것입니다. 로드맵은 팀의 일상적인 업무, 장기적인 비전에 컨텍스트를 제공하고 경쟁 환경의 변화에 대응하므로 워터폴 팀에 중요한 만큼 애자일 팀에도 중요합니다. 그러나 스코틀랜드 전설 속의 괴물과 달리 올바르게 수행하는 애자일 로드맵은 찾기 쉽고 이해하기도 쉽습니다.

제품 로드맵은 시간이 지나면서 제품 또는 솔루션이 어떻게 발전할 것인지에 대한 실행 계획입니다. 제품 팀은 로드맵을 사용하여 향후 제품 기능과 새로운 기능을 출시할 시점을 개괄적으로 설명합니다. 애자일 개발에서 사용하는 로드맵은 팀의 일상적인 업무 및 미래 비전에 중요한 컨텍스트를 제공하며 경쟁 환경의 변화에도 대응할 수 있어야 합니다. 여러 애자일 팀이 단일 제품 로드맵을 공유하거나 각 팀이 자체 제품 로드맵을 가질 수 있습니다.

로드맵을 만들려면 제품 팀은 시장 예측, 회사 목표, 고객 피드백 및 인사이트와 엔지니어링 제약을 고려합니다. 이런 요소가 합리적으로 잘 이해되었으면 로드맵에 이니셔티브 및 타임라인으로 표현합니다. 다음은 제품 팀을 위한 매우 간단한 로드맵입니다. 일반적으로 제품 로드맵은 특정 날짜를 지정하는 것보다 월 또는 분기와 같이 더 큰 기간을 지정하는 것이 가장 좋습니다. 우선 순위 지정 대화에서 타임라인 대신에 목표와 전략에 초점을 맞추려면 이니셔티브를 지금, 다음 및 나중으로 매핑해 볼 수도 있습니다.

로드맵을 만들었으면 모두가 비전 및 방향을 이해할 수 있도록 전체 제품 팀, 리더십 및 제공 팀과 공유해야 합니다. 많은 조직에서 제품 소유자는 PowerPoint 및 스프레드시트에서 로드맵을 만든 다음 슬라이드 및 스프레드시트를 팀에 이메일로 보냅니다. 의도는 좋지만 이 전략에는 처음부터 결함이 있습니다. 각 팀원이 각자 로드맵 복사본을 가지고 있으므로 로드맵이 변경되는 경우 모두가 최신 상황을 파악하도록 하는 것은 시간이 오래 걸리고 어렵습니다.

그렇다면 제품 팀은 어떻게 조직에 더 좋은 방식으로 정보를 계속 제공할 수 있습니까? 간단합니다.

대부분의 공동 작업 도구는 프로젝트의 모든 참가자에게 로드맵이 변경되었음을 자동으로 알립니다.

로드맵에 이니셔티브를 추가할 때 다음 질문을 고려하세요.

동적 예측 솔루션에 대해 이야기하기 전에 집짓기 비유를 사용하여 장기적인 애자일 계획을 세우는 단계에 대해 이야기하겠습니다.

• 각 이니셔티브의 상대적 우선 순위는 무엇입니까?
  • 각 이니셔티브는 제품 및 회사 목표에 어떤 영향을 미칩니까?
  • 각 이니셔티브에 얼마나 많은 노력이 필요합니까?
  • 이니셔티브를 추진하는 데 도움이 되는 인사이트 및 데이터가 충분합니까?
• 각 이니셔티브를 수행하려는 시기는 언제입니까?
  • 팀이 지켜야 하는 특정 날짜가 있습니까?
  • 프로그램에 어떤 종속성이 있습니까(내부 팀 또는 다른 팀)?
• 어떤 팀이 각 이니셔티브를 수행합니까?
  • 현재 팀이 사용 가능한 일정과 충분한 작업 수용량을 갖추고 있습니까?
  • 현재 애자일 팀을 안정적으로 유지할 수 있습니까?
    • 그렇지 않다면...
      • 팀을 어떻게 다시 구성하겠습니까?
        • 프로젝트 타임라인에 새로 조직된 팀의 증가를 고려하고 있습니까?

위에서 언급한 전체적인 "컨텍스트"를 파악할 수 있도록 팀의 제공 작업을 다시 제품 로드맵에 연결하는 것이 중요합니다. 검증된 방법은 제품 맵에서 우선 순위를 지정한 제품 아이디어를 매핑한 다음 그 아이디어를 제공 로드맵에서 에픽, 요구 사항 및 사용자 스토리로 세분화하는 것입니다. 대부분의 경우 각 아이디어에는 완료하기 위해 더 작은 작업으로 세분화해야 하는 에픽이 있습니다. 제품 로드맵의 아이디어를 제공 로드맵의 에픽에 연결하면 엔지니어가 사용자 피드백 또는 조사와 같이 우선 순위가 지정된 이니셔티브 이면의 컨텍스트에 쉽게 액세스할 수 있습니다. 또한 제품 팀과 개발 팀이 향후 작업에 영향을 주지 않는 단기적인 결정을 더 쉽게 내릴 수 있습니다.

예를 들어 웹 사이트에 광범위한 사용자 프로필 기능을 롤아웃한다고 가정해 보겠습니다. 고객이 이 기능을 사용하지 않는다는 것을 발견한다면, 계속하여 해당 기능에 투자해야 합니까? 그럴 수도, 그렇지 않을 수도 있습니다. 이 결정을 내리기 전에 사용도가 낮은 이유를 이해해야 합니다. 따라서 어떤 결정을 강행하기보다는 낮은 사용도에 대한 인사이트를 얻기 위해 일부 A/B 테스트를 구현하는 방법을 선택할 수 있습니다. 이 방법은 단순히 더 많은 기능을 추가했다면 더욱 어렵거나 불가능했을 방향을 가르킬 수 있습니다.

중요한 결정을 내리기 전에 한 걸음 물러서서 조사하는 능력은 애자일 로드맵의 핵심입니다. 인사이트 및 데이터를 수집하는 탐색 프로세스는 결정을 실현하기 전에 취하는 첫 번째 단계가 되는 것이 이상적입니다. 이렇게 하면 팀은 제품 및 시장에 대해 더 많은 정보를 확보하면서 기능을 발전시킬 수 있는 역량을 갖추게 됩니다.

워터폴 프로젝트에는 막대한 사전 투자가 필요합니다. 따라서 팀원들은 자신들이 이미 한 작업을 없었던 일로 만드는 것이 너무 힘들기 때문에 로드맵에 감정적으로 애착을 갖게 되어 올바른 결정을 내리지 못하게 됩니다.

애자일 개발에도 세 가지 위험이 따릅니다.

• 로드맵을 너무 자주 업데이트하면 팀이 전략적 결정을 내릴 수 있는 리더십의 능력에 대한 확신을 잃을 수 있습니다.
• 로드맵을 충분히 자주 업데이트하지 않으면 제품이 시장에 너무 늦게 도착하여 억눌렀던 수요를 놓칠 수 있습니다.
• 장기적인 노력은 짧게 반복하기에는 "너무 크고 어려워" 보일 수 있습니다. 팀은 작업을 매우 세밀하게 분할하여 과도하게 보상하고 결국 단기 결과에 너무 집중하게 됩니다.

"실패", 진부함, 근시안적인 사고를 극복하기 위해 로드맵을 단기적인 전술 및 전략과 장기적인 목표에 고르게 집중하도록 해야 합니다. 이를 위한 가장 좋은 방법은 분기별로 로드맵을 검토하고 필요에 따라 조정한 다음 공유하는 것입니다. 이것은 모든 규모의 조직에서 잘 작동하지만 단일 로드맵이 여러 애자일 팀에 걸쳐 있을 수 있으므로 그에 따라 검사, 조정 및 커뮤니케이션해야 합니다.

애자일 코치를 계속 읽고 여러 팀에 로드맵이 있는 애자일 포트폴리오를 관리하는 대규모 팀을 위한 특별 고려 사항에 대해 알아보세요. 제품 팀을 위해 만든 Jira Product Discovery에서 무료로 자신만의 로드맵을 만들어볼 수도 있습니다.