기능 요청을 놓치지 않고 추적하는 방법

기능 요청 추적은 거의 항상 두 가지 방식 중 하나로 실패한다. 요청이 갈 곳이 없어서 받은편지함과 슬랙 스레드에 살다가 하나씩 잊히거나, 갈 곳은 있지만 아무도 다시 들여다보지 않아서 한꺼번에 잊힌다. 작동하는 체계는 이 두 실패를 모두 견뎌내야 한다. 모든 요청이 도착하는 하나의 장소와, 다음 달에 그 장소를 다시 열어볼 이유가 필요하다.

기능 요청은 실제로 어디서 오는가

대부분의 추적 체계가 고려하는 것보다 더 많은 채널에서 온다. “이런 게 있으면 좋겠다”가 담긴 지원 티켓. 공개 로드맵에 달린 댓글. 잠재 고객이 거래를 막는 바로 그 한 가지를 언급하는 영업 통화. 제품 안의 위젯. 각 채널에는 각자의 담당자와 각자의 도구가 있으며, 바로 그래서 요청이 흩어진다. 지원 티켓 큐와 제품팀 백로그는 같은 체계인 경우가 드물고, 둘 중 하나에만 도달한 요청은 실제로는 부서 하나에만 도달한 것이다.

채널마다 하나씩의 인테이크 폼은 작동하지 않는다, 아무도 채택하지 않기 때문이다. 작동하는 것은 모든 채널이 흘러드는 하나의 목적지다, 라우팅이 자동화되기 전까지는 하루 5분의 복사 붙여넣기를 사람이 처리하는 방식이더라도.

기능 요청 추적을 실제로 망가뜨리는 것은 무엇인가

거의 항상 두 가지다. 첫째는 목적지의 부재다. 요청은 도착한 채널에서 답변을 받고 어디에도 지속적으로 기록되지 않아서, 세 명의 다른 고객에게서 온 같은 요청이 하나의 신호가 아니라 세 개의 고립되고 무관한 일회성 답변처럼 보인다. 둘째, 더 흔한 것은 가득 차서 더 이상 읽히지 않는 목적지다. 필터링되지 않은 400행짜리 스프레드시트는 더 이상 추적 체계가 아니다. 우연히 편집 가능한 보관소일 뿐이다.

두 번째 실패가 더 위험하다. 추적이 작동하는 것처럼 보이기 때문이다. 요청은 기록된다. 누군가 “몇 명이 X를 요청했나”라고 물을 때까지는 아무것도 고장 나 보이지 않으며, 정직한 답은 “알려면 400행을 전부 읽어야 한다”이다.

기능 요청은 실제로 무엇을 기록해야 하는가

나중에 원본 메시지를 다시 읽지 않고도 세 가지 질문에 답할 수 있을 만큼이다. 무엇을 요청했는지, 가능하면 요청한 사람 본인의 말로. 누가 요청했는지, 그리고 답이 결국 “우리가 만들었다”가 된다면 어떻게 연락할지. 그리고 이것이 흔한 요청인지 일회성 사례인지 알려면 무엇이 필요한지. 직접 인용은 바꿔 쓴 것보다 더 가치 있다. 요청을 분류한 사람이 쓴 바꿔 쓴 문장은 이미 그 사람 자신의 해석을 담고 있으며, 바로 그 해석이야말로 여섯 달 후 두 번째 사람이 확인할 수 없는 것이기 때문이다.

어떤 라벨이 가치 있는가

두 가지가 있고, 서로 다른 질문에 답한다. 유형 라벨은 기능 요청을 버그 신고와 분리한다. 둘 다 다른 담당자와 다른 일정이 필요하며, 하나의 큐에 섞으면 가장 시끄러운 불만이 요청을 앞지르게 된다. low, medium, high 같은 작은 집합으로 유지되는 우선순위 라벨은 “누군가 제품을 사용하는 것을 막는다”와 “있으면 좋겠다”를 분리한다. 둘 다 매우 다른 응답 시간을 받을 만하며, 어느 쪽도 다른 쪽의 속도를 물려받아서는 안 되기 때문이다. 유형 라벨을 올바르게 붙이는 것은 그 요청이 스스로 주장하는 그대로라고 가정한다. 기능 요청이 실제로는 버그 신고일 때는 고객 자신의 말이 그 라벨을 엉뚱한 방향으로 향하게 하는 경우를 다룬다.

자동 분류는 요청이 도착하는 순간 둘 다 적용할 수 있다. changeloop에서는 위젯 제출이 같은 단계에서 feature-request 또는 bug 라벨과 priority:low|medium|high 라벨을 받고, 항목을 열지 않아도 출처가 보이도록 from-widget 태그가 붙는다. 이것만으로 오후 내내가 아니라 1분 만에 백로그를 필터링할 수 있다. 이번 달 위젯에서 온 우선순위 높은 기능 요청을 전부 보여달라는 식으로.

세 번째 라벨은 공개 로드맵이 생기는 순간 가치가 있다. 요청한 사람이 스스로 확인할 수 있는 상태다. 공개 로드맵이 planned, building, shipped 상태를 완전히 다룬다. 짧게 말하면, 이 라벨은 비공개 큐를 요청한 사람이 다시 묻지 않고도 확인할 수 있는 것으로 바꾼다.

다음에 무엇을 만들지는 어떻게 결정하는가

세기 전에 먼저 묶어라. 같은 근본 기능에 대해 서로 다르게 표현된 열 개의 요청은 스프레드시트에 흩어진 열 개의 행처럼 읽히지만, 묶으면 강한 신호가 된다. 그 묶음이 대개 빠진 단계이지 세는 것이 아니다. 묶지 않은 원시 개수는 뒤에 있는 실제 수요가 가장 큰 기능이 아니라 가장 눈에 띄는 이름을 가진 기능에 보상하는 경향이 있다.

몇 명이 요청했는지가 아니라 누가 요청했는지로 가중치를 둬라. 갱신이 임박한 계정의 요청은 체험판 가입의 같은 요청과는 다른 긴급성을 지니며, 이 맥락을 벌거벗은 숫자를 위해 버리는 추적 체계는 가장 유용한 숫자가 아니라 가장 계산하기 쉬운 숫자에 최적화하는 것이다.

여기서의 모든 결정은 지는 요청도 만들어내며, 그것들도 답변을 받을 자격이 있다; 기능 요청을 거절하는 방법이 성사되지 않은 요청을 한 사람에게 무엇을 말해야 하는지를 다룬다. 그룹으로 묶고 가중치를 매기는 것은 “다음에 무엇을 만들 것인가”의 절반일 뿐이다; 기능 요청 우선순위가 실제 프레임워크, RICE, 매출 가중, 순수 요청 수, 그리고 각각이 어디서 무너지는지를 다룬다.

무언가 출시되면 어떻게 순환을 닫는가

이것은 추적 체계가 가장 자주 건너뛰는 단계이며, 요청한 사람이 실제로 알아채는 단계다. 고객과의 피드백 순환 닫기가 그 메커니즘을 완전히 다룬다. 여기서 중요한 것은 원래 요청이 요청한 사람과 계속 연결되어 있을 때만 순환 닫기가 작동한다는 점이다. GitHub 이슈에서 만들어진 기능 요청 템플릿으로, 요청한 사람의 신원이 댓글에 묻히지 않고 이슈 자체에 붙어 있는 것이 누군가 기억해서 보내야 하는 알림 대신 자동 “출시됨” 알림을 가능하게 만드는 것이다. 기능 요청 템플릿이 구체적인 템플릿과 각 필드가 무엇을 위한 것인지 보여준다.

FAQ

기능 요청 추적에는 어떤 도구를 써야 하는가? 팀이 이미 매일 확인하는 것이 아무도 열지 않는 전용 도구를 이긴다. 엔지니어링이 이미 거기 있다면 GitHub 이슈 트래커가 잘 작동하고, 제품팀이 거기 있다면 가벼운 보드가 잘 작동한다. 도구 자체보다 다시 열어보는지 여부가 더 중요하다.

기능 요청이 중복되는 것을 어떻게 막는가? 표현으로 분류하기 전에 근본 기능으로 묶어라. 새로 만들기 전에 기존 요청을 검색하면 대부분의 중복을 잡아낸다. 매달 한 번의 묶음 작업이 나머지를 잡아낸다. 원래 목소리를 잃지 않고 중복 병합하기는 묶음 자체가 끝난 후 표현을 어떻게 처리해야 하는지 다룬다, 그래서 병합이 먼저 도착한 제출로 요청을 조용히 좁히지 않도록.

모든 기능 요청이 답변을 받아야 하는가? 모든 요청은 짧더라도 확인을 받아야 하지만, 모두가 즉시 결정을 필요로 하는 것은 아니다. 요청한 사람이 스스로 확인할 수 있는 로드맵 라벨 같은 보이는 상태가, 팀이 그렇지 않으면 개별적으로 해야 했을 대부분의 답변을 대체한다.

기능 요청 추적과 공개 로드맵의 차이는 무엇인가? 추적은 절대 출시되지 않을 것들을 포함해 모든 요청의 내부 기록이다. 공개 로드맵은 팀이 공개적으로 약속하는 부분집합으로, 요청한 사람이 다시 묻지 않고도 볼 수 있는 상태를 동반한다.

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

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