모든 것이 긴급할 때 기능의 우선순위를 지정하는 방법

FabricLoop 팀  ·  2026년 5월  ·  6분 읽기

대부분의 제품 팀에서 백로그는 긴급이 죽는 곳입니다. 입력되는 모든 것이 추가되었을 때 긴급했습니다. 고객 불평, 판매 요청, 경쟁사 기능, 내부 아이디어. 6개월 후, 그것은 모두 여전히 그곳에 있고, 모두 여전히 긴급하게 느껴지고, 아무도 다음에 무엇을 할지 정확히 알 수 없습니다.

문제는 도구의 부족이 아닙니다. 수십 개의 우선순위 결정 프레임워크가 있습니다: RICE, MoSCoW, Kano, ICE, 가중치 점수. 문제는 대부분의 프레임워크가 일종의 거짓 정확도를 요구한다는 것입니다. 미지수에 숫자를 할당하면 엄격한 느낌을 주지만 실제로는 스프레드시트를 통해 장세를 세탁하는 것입니다.

실제로 작동하는 것은 더 간단합니다: 2개의 차원, 정직하게 평가, 결과에 따른 규율.

중요한 유일한 2개의 차원

우선순위 결정은 2개의 질문으로 축소됩니다. 첫 번째: 이것이 우리가 신경 쓰는 결과를 얼마나 개선합니까? (영향.) 두 번째: 전달하는 데 얼마나 많은 비용이 들 것입니까? (노력.) 다른 모든 것은 이 두 가지의 정제이거나 산만함입니다.

신뢰도는 때때로 3번째 차원으로 추가됩니다. "영향에 대해 얼마나 확신합니까?" 그리고 염두에 두는 것이 좋습니다. 하지만 실제로는 대부분의 팀이 추측할 때를 압니다. 규율은 스코어를 1-5로 책정하고 공식에 추가하는 것이 아니라 추측을 정직하게 표시하는 것입니다.

어려운 부분은 그리드를 이해하는 것이 아니라 정직하게 채우는 것입니다. 모든 팀은 "시간 낭비"에 속하는 기능을 빌드하기를 원하지만 "큰 베트"로 계속 재분류합니다. 프레임워크는 팀이 영향에 대해 정직할 수 있을 때만 작동합니다.

거짓 정확도 없이 영향 평가

영향은 팀이 평가하기 가장 어려운 차원입니다. 미래를 예측해야 하기 때문입니다. 유혹은 수치 점수를 책정하고 그것에 대해 과학적으로 느끼는 것입니다. 더 나은 접근법은 정성적이지만 구조화되어 있습니다.

검토 중인 각 기능에 대해 3개의 질문을 묻습니다:

• 이것이 어떤 특정 사용자 문제를 해결합니까? 특정하고 반복적인 문제의 이름을 지을 수 없다면 영향 케이스는 약합니다.
• 몇 명의 사용자가 이 문제를 가지고 있으며 얼마나 자주입니까? 영향은 빈도에 강도를 곱합니다. 모두를 위한 약한 좌절은 소수에 대한 심각한 차단과는 다릅니다.
• 지금 이것을 빌드하지 않으면 어떻게 됩니까? 답이 "별로 아무것도 아니면" 재분류합니다. 답이 "사용자 이탈" 또는 "거래를 잃으면" 영향은 실제입니다.

과소평가 없이 노력 평가

팀은 체계적으로 노력을 과소평가합니다. 이것은 잘 문서화되어 있습니다. 계획 오류 및 낙관적 편향과 관련이 있습니다. 그리고 여러 시스템을 만지거나 팀 간 조정이 필요하거나 팀이 빌드하지 않은 기능이 포함된 기능에서 특히 두드러집니다.

더 정확하게 추정하는 방법:

• 이전 작업과 비교합니다. "이 기능은 마지막 기능보다 50% 더 복잡해 보인다"는 숫자를 할당하는 것보다 더 신뢰할 수 있습니다.
• 의존도를 찾습니다. 기능이 다른 작업의 완료에 의존하면 숨겨진 비용이 있습니다.
• 불확실성을 명확히 합니다. "우리는 정확히 어떻게 이것을 빌드할지 확실하지 않습니다"는 범위 불확실성이 있다는 신호입니다. 그것을 부자유하게 추정하거나 스파이크 작업으로 분해합니다.

그리드를 채운 후 행동하기

우선순위 그리드의 진정한 가치는 그것을 채운 후 실제로 그것을 사용한다는 것입니다. 대부분의 팀은 연습을 한 다음 여전히 느낌과 정치에 기반하여 계획합니다.

빠른 승리부터 시작합니다. 이것들은 영향 대 비용에서 최고의 비율입니다. 큰 베트로 진행하기 전에 프로토타입을 만들고, 검증하고, 높은 지출을 정당화합니다. 시간 낭비를 영원히 놔두세요.