제품 백로그는 특정 지점에서 해결해야 하는 항목을 포함하므로 조직의 민첩한 제품 개발의 기본 구성 요소입니다.
새로운 제품을 만드는 것은 팀이 특별한 것을 만들 수 있게 해주는 아이디어에서 시작됩니다. iPhone조차도 전담 팀 덕분에 프로토 타입으로 처음 나왔고 인기를 얻었습니다.
팀을 관리하는 동안 제품 관리자는 중요한 할 일 목록을 체계적으로 관리해야 합니다. 글쎄, 그것은 보이는 것처럼 쉽지 않습니다.
할 일 목록을 유지하고 먼저 할 일을 결정하는 것은 매우 어려운 작업입니다. 그리고 이해관계자가 여러 명일 때 더욱 압도적입니다.
결과적으로 조직은 많은 시간과 리소스를 잃게 됩니다.
여기에서 제품 우선 순위를 지정하면 모든 작업이 단순해지고 할 일 목록을 적절하게 유지하는 데 도움이 됩니다.
이 기사에서는 제품 백로그, 일반적인 요소, 이점 등에 대해 자세히 설명합니다.
목차
제품 백로그란 무엇입니까?
제품 백로그는 제품 목표를 달성하고 개발자 팀 간에 유효한 기대치를 설정하는 데 도움이 되는 우선순위가 지정된 기능 또는 작업 항목의 목록입니다. 간단히 말해서 개발 단계의 각 제품에는 전용 제품 백로그가 있습니다.
마찬가지로 모든 제품 백로그에는 전담 팀이 있습니다. 일반적으로 여러 팀이 더 큰 제품을 작업하는 여러 제품 백로그가 있습니다.
예를 들어 큰 제품은 ‘제품’으로, 작은 제품은 ‘제품 A’, ‘제품 B’, ‘제품 C’로 이름을 지정해 보겠습니다. 제품 A, 제품 B 및 제품 C에는 자체 제품 백로그와 개발을 위한 특정 팀이 있습니다. 지정된 각 팀은 더 작은 제품을 작업하여 최종적으로 더 큰 제품을 만듭니다.
따라서 제품 로드맵과 개발 팀의 요구 사항에서 파생된 작업의 우선 순위 목록으로 정의할 수 있습니다. 가장 필수적인 항목은 백로그의 맨 위에 있으므로 개발 팀은 어떤 항목을 먼저 제공해야 하는지 알 수 있습니다.
그러나 제품 백로그는 제품 관리자가 일반적인 문제와 제품을 제공하는 데 필요한 솔루션을 더 잘 이해할 수 있도록 하는 실시간 문서입니다.
백로그 항목의 우선 순위는 누가 지정합니까?
제품 백로그는 제품 소유자 또는 제품 관리자가 소유합니다. 제품 소유자는 백로그 유지 관리를 담당하고 다른 팀원은 제품 개발에 노력과 시간을 투자합니다.
따라서 제품 백로그의 주요 목적은 다음과 같습니다.
- 개발팀이 가치 있는 사용자 스토리를 구현할 수 있도록 팀과 이해관계자를 조정하기 위한 기반 개발
- 현실과 필요에 적응할 수 있는 유연성 제공
- 다양한 팀에서 공통 분모를 사용하여 단일 제품에 결합하여 제품 출시 예측의 효율성을 높입니다.
제품 백로그의 일반적인 요소
제품 백로그에는 버그 수정, 기능, 지식 습득 및 기술적 부채가 포함됩니다. 이러한 항목은 제품 완성을 위해 전달해야 하는 주요 작업의 개별 부분입니다.
#1. 버그 수정
결함 및 버그는 최종 사용자가 발견한 문제로 품질 관리 프로세스 중에 빠져나갑니다. 버그가 시간 내에 해결되지 않으면 시간이 지남에 따라 누적되는 경향이 있습니다.
귀하의 팀은 버그 수정을 신속하게 해결하여 제품 무결성을 유지합니다. 일부 버그는 팀의 현재 스프린트를 방해할 만큼 필수적인 반면 다른 버그는 다음 스프린트를 기다릴 수 있습니다. 개발 팀이 버그 수정을 잊지 않도록 제품 백로그의 맨 위에 남아 있습니다.
#2. 특징
기능은 사용자가 가치 있다고 생각하는 제품의 기능입니다. 사용자 스토리라고도 합니다. 기능은 복잡하거나 단순할 수 있습니다. 하지만 사용자의 니즈를 이해하기 위해서는 스토리맵을 만들어야 합니다.
새로운 기능에 대한 요청은 다양한 소스에서 발생합니다. 기능에는 제품 관리, 지원, 영업, 최종 사용자 등이 포함됩니다. 다음과 같은 경쟁 요구 사항의 균형을 유지해야 하므로 새 기능의 우선 순위를 정하는 것이 어려울 수 있습니다.
- 이전 고객 만족 유지
- 기간 판매 기회 충족
- 제품의 더 높은 비전을 향한 노력
제품 관리자는 이러한 소스를 모니터링하고 충돌하는 요청을 해결합니다. 일상적으로 그렇게 하면 제품 백로그에 고객을 유치하고 기존 고객을 만족시킬 수 있는 새로운 기능이 있는지 확인할 수 있습니다.
#삼. 지식 습득
여기에서 향후 작업을 완료하기 위한 정보를 수집합니다. 중요한 것은 지식 습득이 연구 단계라는 것입니다. 더 많은 조사가 필요한 기능을 감지하면 개념 증명, 실험 또는 프로토타입과 같은 지식 획득 작업을 생성할 수 있습니다. 이렇게 하면 해당 기능에 대한 작업을 시작하기 위한 정보를 얻는 데 도움이 됩니다.
#4. 기술 부채
기술 부채는 금융 부채와 같습니다. 부채를 무시하면 이자가 발생합니다. 이것은 개발자가 이 단계를 백로그의 맨 아래로 밀면 발생하며, 그러면 달성하기가 더 어려워집니다.
제품 백로그를 효과적으로 관리하면 기술적 부채를 예방할 수 있습니다. 개발 팀이 목록을 체계적으로 유지하고 기술 작업을 매일 또는 더 작은 단위로 수행하면 작업에 대한 관심이 증가할 가능성이 적습니다.
기술 부채는 다음을 기반으로 한 변경 결과입니다.
- 확장성 및 성능 기대치
- 범위 및 방향
- 기술 및 모범 사례
제품 백로그: 이점
제품은 확실히 영업사원, 개발자, 가장 중요한 사용자와 같은 다양한 출처의 피드백을 나타냅니다. 피드백을 받고, 관리하고, 우선 순위를 지정하고, 향후 제품 제공을 위해 철저히 작업할 준비가 되어 있어야 합니다.
적절한 프로세스가 없으면 제품 개발이 어려워집니다. 따라서 잘 관리되고 잘 처리된 백로그는 제품에 집중하고 보다 효율적인 팀으로 이끄는 데 도움이 됩니다.
조직에서 제품 백로그를 유지 관리할 때의 이점에 대해 논의해 보겠습니다.
- 향상된 집중력: 제품 백로그를 통해 중요한 작업에 집중하고 방해 요소를 피할 수 있습니다.
- 향상된 효율성: 항목의 우선 순위를 지정하면 팀이 작업을 철저히 수행하여 효율성이 향상됩니다.
- 더 나은 위험 관리: 제품 백로그는 개발 프로세스 초기에 위험을 식별하고 해결할 수 있으므로 위험 없이 관리할 수 있습니다.
- 더 나은 고객 만족: 최종 사용자의 만족이 주요 목표입니다. 따라서 백로그 우선 순위 지정은 조직이 제품에서 추가하거나 제거하는 데 필요한 사항을 확인하여 조직을 만족시켜 사용자에게 가치 있는 제품으로 만드는 데 필수적입니다.
- 의사소통 증가: 제품 백로그는 팀 간의 협업과 의사소통을 장려하여 제품을 개발하는 동안 더 집중하고 더 나은 결과를 얻을 수 있습니다.
- 향상된 팀 사기: 제품 백로그는 팀의 목적과 방향 감각을 제공하여 사기를 높입니다.
- 유연성 촉진: 개발자의 진행 및 작업 완료율에 따라 제품 백로그가 변경됩니다. 제품 상태의 개발이 변경되면 제품 관리자는 작업의 우선 순위를 다시 지정합니다. 이러한 유연성은 근무 시간에 공허함을 피하기 위해 필요합니다.
이 외에도 가장 빠른 투자 수익, 고객 만족도 향상, 위험 최소화 등과 같은 많은 이점을 찾을 수 있습니다.
제품 백로그를 만드는 방법
제품 소유자는 우선 순위 지정 작업에 대한 전적인 책임이 있습니다. 잘 관리되는 제품 백로그를 만들려면 다음 단계를 따라야 합니다.
1단계: 제품 백로그에 아이디어 추가
제품 백로그는 아이디어 목록입니다. 여기에는 팀 구성원, 이해 관계자 및 고객이 제공한 진술 또는 피드백이 포함됩니다. 간단한 방법으로 기존 제품 또는 새 제품에 대해 이해 관계자, 팀 및 고객과 논의한 후 목록에 아이디어를 추가해야 합니다.
처음에는 아이디어가 제한적이지만 개발 과정에서 제품의 시장 관련성과 경쟁을 염두에 두고 새로운 아이디어를 얻게 됩니다.
2단계: 설명 받기
이해 관계자가 제품 추가 또는 수정에 대해 일부 변경을 필요로 하는 경우 사전에 이를 명확히 하는 것이 중요합니다. 제품 소유자는 추가의 중요성을 이해하기 위해 다음 기본 사항을 명확히 해야 합니다.
- 수정 이유: 이것은 실제로 문제가 무엇인지, 원인이 무엇인지, 해결 방법을 나타냅니다.
- 기여하는 가치: 팀은 새로운 추가가 전체 제품에 기여하고 품질을 향상시키는 데 도움이 되는지 분석합니다. 추가는 제품의 가치를 높여야 합니다. 따라서 비즈니스 가치가 증가하고 투자 수익이 향상됩니다.
- 항목 사양: 사양은 개발자가 개발 과정에서 어려움을 느끼지 않도록 제품 소유자 측에서 명확해야 합니다.
3단계: 우선순위 지정
모든 것이 준비되면 제품 소유자의 책임은 백로그의 우선순위를 가장 높은 우선순위에서 가장 낮은 우선순위로 지정하는 것입니다. 이 단계는 정보의 전략적 분석을 기반으로 합니다. 목록을 잘 관리하면 서로 다른 팀 간의 커뮤니케이션을 향상시킬 수 있습니다.
제품 소유자는 특정 기준에 따라 백로그 항목의 우선 순위를 지정합니다.
- 수익: 더 나은 수익으로 이어질 수 있는 모든 기능이나 항목은 높은 우선 순위 목록에 있어야 합니다.
- 시장 고유성 및 수정: 추가하기로 결정한 기능이 시장에서 고유한 경우 시장에서 눈에 띌 가능성이 높습니다. 또한 기존 기능이 사용자의 문제를 해결할 수 있는지 확인해야 합니다. 그것이 실제 목표입니다.
- 복잡성: 백로그 항목의 우선 순위를 정하기 전에 제안된 기능의 복잡성과 개발 및 릴리스에 걸리는 시간을 확인해야 합니다.
4단계: 정기적으로 제품 백로그 업데이트
제품 백로그는 제품 소유자가 적시에 업데이트해야 하는 살아있는 문서입니다. 백로그 항목을 수정하고 우선 순위를 지정하고 최신 상태로 유지하는 프로세스는 개발 프로세스의 필수 부분입니다.
제품 백로그에는 수많은 아이디어가 포함되어 있습니다. 이러한 아이디어를 다듬고 관련 없는 아이디어는 폐기해야 합니다. 마지막 단계에서는 백로그 항목의 우선순위가 지정되고 우선순위 수준에 따라 정렬됩니다.
일부 우선 순위 지정 방법
백로그 항목의 우선 순위를 지정하는 데 사용할 수 있는 방법은 많습니다. 그 중 몇 가지를 논의해 보겠습니다.
#1. MoSCOW 기술
이미지 출처: StoriesOnBoard
MoSCoW는 해야 할 필수 사항과 그렇지 않은 사항을 이해하기 위해 제품 관리에서 일반적으로 사용되는 분석 유형입니다. 작업 중인 내용과 그 이유에 대해 이해 관계자와 소통하는 데 유용한 방법입니다.
이름에는 네 가지 우선 순위 범주가 포함됩니다.
- Must have: 절대적으로 필요한 요구 사항
- 있어야 함: 우선 순위가 높은 기능
- 가질 수 있는 기능: 가능한 기능
- 없을 것: 구현되지 않음
“Must have”는 제품에 있어야 하는 절대적인 기능을 나타냅니다. 이는 안전 문제, 사업상의 이유 및 법적 이유 때문일 수 있습니다. 이를 위해 목록에 기능을 포함하는 최상의 경우와 최악의 시나리오를 나열하고 그림을 그립니다.
“해야 한다”는 포함할 수 있지만 필수는 아닌 기능을 의미합니다.
“Could have”는 조직에 필요한 리소스가 있지만 성공을 위해 필요하지 않은 경우 추가할 수 있는 항목에 대한 것입니다.
“없을 것”은 해당 기능이 더 이상 필요하지 않거나 휴지통 항목임을 나타내지 않습니다. 대신 프로덕트 매니저는 ‘이번엔 아니야’라는 뜻이다. 시간이나 자원 부족과 같은 몇 가지 이유가 있습니다.
#2. 아이젠하워 매트릭스
이 방법은 시간을 적절하게 관리하는 간단한 방법입니다. Dwight D. Eisenhower의 의사 결정 매트릭스에서 유래했습니다. 이것은 나중에 백로그 목록에서 작업의 우선 순위를 지정하는 데 사용할 수 있는 4사분면 시각화로 변경됩니다.
이미지 출처: ModelThinkers
매트릭스에는 중요도와 긴급도라는 두 가지 우선 순위 차원이 포함되어 있습니다. 이 기술을 사용하면 다음을 포함하는 매트릭스의 네 섹션에 작업을 할당할 수 있습니다.
- 높은 우선순위
- 중간 우선순위
- 긴급하지만 중요한
- 낮은 우선 순위
#삼. 카노
Kano 모델은 고객 기쁨과 만족을 찾는 조직을 위한 훌륭한 옵션 중 하나입니다. 제품 관리자의 기능 백로그는 끝이 없지만 완벽한 기능으로 제품 로드맵을 구축하기를 원합니다. Kano 모델은 제품 관리자를 안내하는 강력한 기술입니다. 이 기술은 1980년대에 Noriaki Kano에 의해 개발되었습니다.
이 모델에는 세 가지 전제가 포함됩니다.
- 고객의 행복을 반영하는 만족
- 고객 반응은 제품의 특징과 기능에 따라 달라집니다.
- 고객 감정
#4. 가중 최단 작업 우선(WSJF)
WSJF는 팀이 이니셔티브 목록의 우선 순위를 지정하는 데 도움이 되는 도구입니다. 일반적으로 이 도구는 SAFe(Scaled Agile Framework)에서 사용됩니다. 팀은 지연 비용을 작업의 크기 또는 기간으로 나누어 각 이니셔티브 점수의 수학을 수행합니다. 가장 높은 점수를 받은 항목이 높은 우선 순위로 상위 목록에 있습니다.
백로그 관리 방법
적절한 백로그 관리를 보장하고 백로그를 건전하게 유지하려면 아래 언급된 사례를 따르십시오.
- 반복 계획 전에 제품 백로그를 검토하여 우선순위를 지정한 작업이 올바르고 이전 피드백도 구현되었는지 확인하십시오.
- 백로그가 커지면 항목을 단기 또는 단기 및 장기로 분류해야 합니다.
- 혜택에 따라 항목을 유지할지 삭제할지 결정합니다.
- 적절한 계획 없이 작업을 추가하지 마십시오.
- 이 우선 순위 지정 프로세스를 조직의 우선 순위로 만드십시오.
또한 고객 피드백에 따라 개발 프로세스 중에 작업의 우선 순위를 쉽게 다시 지정할 수 있습니다. 또한 이전 문을 수정하고 새 요구 사항을 추가할 수 있습니다.
스프린트 백로그 대 제품 백로그
- 제품 백로그에는 시간 내에 개발 프로세스를 완료하기 위해 완료해야 하는 모든 항목이 나열됩니다. 스프린트 백로그에는 스프린트 내에서 완료해야 하는 백로그의 항목이 포함됩니다.
- 제품 소유자는 백로그 목록을 결정하는 반면 개발 팀은 스프린트 백로그 항목을 결정합니다.
- 제품 백로그는 제품 목표를 기반으로 구축됩니다. 그러나 스프린트 백로그는 특정 스프린트와 일치합니다.
- 제품 백로그는 시간이 지남에 따라 변경될 수 있지만 스프린트 백로그는 설정된 후에 변경되지 않습니다.
- 제품 백로그는 유지 관리가 필요하며 프로젝트가 완료될 때까지 유지됩니다. 그러나 스프린트 백로그는 끝날 때까지 남아 있지 않습니다. 스프린트로 끝납니다.
결론
제품 백로그를 유지하는 것은 제품 개발 프로세스에서 필수적인 단계입니다. 진행 중인 작업, 완료된 작업 및 향후 계획에 대한 명확한 보기를 제공합니다. 따라서 효과적인 제품 백로그를 생성 및 유지 관리하고 게임에서 우위를 점할 때입니다.
최고의 CFD 분석 소프트웨어 및 Scrum 도구를 탐색할 수도 있습니다.