계속 쌓이는 기능 요청에 우선순위를 매기는 방법

기능 요청을 추적하는 것은 그것들이 어디에 있는지를 해결해준다. 어떤 것을 먼저 내보낼지는 해결해주지 않으며, 팀이 실제로 막히는 지점은 바로 이 두 번째 질문이다. 그룹으로 묶이고 라벨이 붙은 요청 삼백 개짜리 백로그도 여전히 결정 규칙이 필요한데, “가장 많이 요청받은 것을 만들어라”는 두 요청이 비슷할 때, 그리고 세 번째 요청에 목소리 큰 지지자가 있을 때까지만 통하기 때문이다. 그런 일은 대부분의 주에 일어난다. 아래의 프레임워크들은 같은 질문에 대한 경쟁하는 답이 아니다. 각각은 서로 다른 유형의 요청에 맞으며, 모든 것에 하나만 쓰는 것이 보통 진짜 실수다.

기능 요청 우선순위 매기기는 로드맵 우선순위 매기기와 무엇이 다른가

로드맵 결정은 전략에서 시작해서 무엇을 만들지 묻는다. 기능 요청 결정은 이미 존재하는 수요에서 시작해서 그것에 대응할지 묻는데, 이 둘은 충분히 자주 서로 다른 방향으로 당기기 때문에 어떤 요청은 수요가 높으면서도 만들기에는 잘못된 것일 수 있고, 수요가 낮으면서도 전략적 계정을 열어준다는 이유로 그럴 가치가 있을 수 있다. 모든 요청을 로드맵 투표처럼 다루는 것은 이 확인 과정을 건너뛴다.

RICE란 무엇이고, 기능 요청에도 통하는가

RICE는 아이디어를 도달 범위, 영향, 확신, 노력으로 점수 매긴 다음, 앞의 셋을 넷째로 나누어 비교 가능한 숫자를 얻는다. 이것은 팀이 이미 믿고 있는 로드맵 아이디어를 위해 만들어졌으며, 어려운 부분은 서로 다른 베팅들을 비교하는 것이다. 기능 요청은 이미 도달 범위 숫자, 즉 요청한 사람 수를 갖고 시작하는데, 이것은 갓 나온 로드맵 아이디어가 보통 갖는 도달 범위보다 더 구체적이다. RICE가 요청과 마찰을 빚는 지점은 확신과 영향이다. 팀은 요청이 진짜라고 확신하면서도, 그것이 지표를 얼마나 움직일지에 대한 근거는 없을 수 있는데, 이미 이름과 실제 사용자의 흔적을 가진 요청의 “영향”은 방 밖의 아무도 아직 보지 못한 아이디어의 영향과는 다른 종류의 추정이기 때문이다.

RICE는 진지하게 고려되고 있으면서 아직 결정되지 않은 요청에 써라. 들어오는 모든 요청에 적용하지는 말라. 점수 매기는 노력은 동점자를 가려낼 만큼 가까운 요청들에서만 값어치를 한다.

매출로 가중해야 하는가, 아니면 누가 요청했는지로 가중해야 하는가

누가 요청했는지로 가중하되, 매출만으로는 안 된다. 갱신이 가까운 계정, 이미 한 번 에스컬레이션한 계정, 그리고 그 요청이 진행 중인 거래를 열어주는 계정은 단순한 매출 숫자 하나로는 담아낼 수 없는 긴급성을 지니며, 체험판 가입에서 온 요청도 곧 매출이 될 결정을 막고 있다면 여전히 중요할 수 있다. 매출 가중은 이 모든 방법 중 계산하기 가장 쉬운 것이며, 바로 그래서 과신하기도 가장 쉽다. 진짜 이해관계가 없는 계정에서 오는 소음을 정확히 걸러내는 동시에, 아직 파이프라인에 있는 훨씬 더 큰 계정을 데려올 요청을 똑같이 쉽게 낮춰 평가할 수도 있다.

투표는 실제로 어떤 역할을 하는가

이미 존재하는 요청에는 저렴하고 지속적인 신호지만, 애초에 어떤 요청이 존재해야 하는지를 발견하는 데는 나쁜 방법이다. 투표 수는 이미 그 요청을 찾아내서 클릭할 가치가 있다고 판단한 사용자에게만 도달하는데, 이것은 공개 로드맵의 투표 합계가 수요만큼이나 가시성도 반영한다는 뜻이다. 목록 상단 근처의 오래된 요청은 부분적으로 찾기 쉽다는 이유만으로 계속 투표를 모으고, 그만큼 진짜인 더 새로운 요청은 0에서 시작한다. 공개 로드맵 글은 로드맵에서 투표를 아예 빼자고 주장한다. 투표를 순서대로 쌓아 올리는 순위표가 아니라, 그룹으로 묶고 최신성으로 가중해야 하는 신호로 다뤄라. 지원 티켓 대 기능 요청은 투표 수의 또 다른 사각지대를 다룬다. 그것을 마주치는 사용자가 게시판을 결코 찾지 못한다면 진짜 격차는 투표를 거의 만들어 내지 못할 수 있는 반면, 지원팀에서는 시끄럽게 나타난다.

가장 목소리 큰 고객이 언제 이기며, 그것은 문제인가

때로는 그렇고, 아무도 그것을 알아채지 못할 때만 문제가 된다. 자주 에스컬레이션하고, 상세한 티켓을 쓰고, 팀 안의 누군가와 직접 연락선이 있는 고객은 똑같이 타당한 요청을 가진 더 조용한 고객보다 자신의 요청이 더 빨리 검토되는 것을 보게 되며, 그것을 한 번도 확인하지 않는 우선순위 결정 프로세스는 가장 강한 사례를 가진 사람이 아니라 가장 끈질기게 밀어붙이는 사람을 체계적으로 편애하게 된다. 목소리 큰 고객은 고쳐야 할 문제가 아니다. 그들의 요청은 흔히 정말로 중요하다. 고쳐야 할 것은 습관이다. 주기적으로 출처별로 백로그를 훑어보고, 같은 소수의 계정이 최근 출시된 것의 대부분을 설명하는지 확인하고, 그것이 실제 수요가 있는 곳과 맞는지 자문하는 것이다.

우선순위 결정은 어떻게 답변으로 바뀌는가

여기서 내려지는 모든 결정은 승자와 패자를 함께 만들어내며, 둘 다 설명 없는 상태 변경이 아니라 실제 논리를 명시한 답변을 받을 자격이 있다. 기능 요청을 거절하는 방법이 진 요청에게 무엇을 말해야 하는지를, 상투적인 거절처럼 들리지 않고 관계를 온전히 유지하는 방식으로 다룬다. 이 모든 것을 애초에 가능하게 만드는 그룹화와 라벨링 작업은 기능 요청 추적에서 다룬다. 우선순위 결정은 이미 기록되어 있고 비교할 수 있을 만큼 잘 그룹으로 묶인 요청에 대해서만 작동한다.

FAQ

기능 요청 우선순위를 매기는 데 가장 좋은 프레임워크는 무엇인가? 어느 것도 혼자서는 충분하지 않다. 가장 목소리 큰 신호를 찾기 위해 순수 요청 수를 쓰고, 진지한 후보 짧은 목록을 비교하기 위해 RICE를 쓰고, 전략적 계정의 조용한 수요가 더 목소리는 크지만 덜 중요한 그룹보다 무거운 경우를 잡아내기 위해 매출이나 계정 확인을 써라.

기능 요청도 로드맵 아이디어와 같은 방식으로 우선순위를 매겨야 하는가? 아니다. 로드맵 아이디어는 전략에서 시작하고, 기능 요청은 이미 존재하는 수요에서 시작한다. 둘을 함께 점수 매기면, 근거는 탄탄하지만 기존 수요가 적은 전략적 베팅이 그저 더 많은 사람이 요청했다는 이유만으로 계속 패배하게 된다.

공개 로드맵의 투표는 수요를 정확하게 반영하는가? 이미 그 요청을 찾아낸 사람들 사이에서만 그렇다. 더 오래되고 더 눈에 띄는 요청은 더 새로운 요청 뒤에 얼마나 진짜 수요가 있는지와 무관하게 더 빨리 투표를 모으므로, 투표 합계를 순서대로 쌓아 올리는 순위표가 아니라 그룹으로 묶고 최신성으로 가중된 신호로 다뤄라.

기능 요청 우선순위는 얼마나 자주 다시 평가해야 하는가? 누군가 에스컬레이션할 때만이 아니라 고정된 주기로 하라. 요청을 다시 그룹으로 묶고 가중치를 다시 확인하는 월간 또는 분기별 검토는, 무엇이 출시되는지를 좌우하는 소수의 계정처럼 순수하게 반응적인 프로세스가 스스로는 결코 드러내지 못하는 편차를 잡아낸다.

이 글의 기술적 내용은 독립적으로 검토되지 않았습니다. 잘못된 부분이 있으면 알려 주세요. 바로잡겠습니다.

changeloop 관련 페이지: 개발자 문서, changelog 도구 비교