체인지로그 쪽에서 고객 피드백 루프를 닫는 방법

고객 피드백 루프는 피드백을 준 사람이 그것이 어떻게 되었는지 통보받았을 때 닫힌다. 접수되었을 때도 아니고, 우선순위가 매겨졌을 때도 아니며, 심지어 출시되었을 때도 아니다. 통보받았을 때다. 대부분의 팀은 처음 세 단계는 잘 해내지만 마지막 단계는 전혀 하지 않으며, 그러고 나서 왜 피드백을 보내던 사람들이 더 이상 보내지 않는지 궁금해한다.

이 글은 그 마지막 단계에 관한 것이며, 하나의 구체적인 주장에 관한 것이다. 체인지로그는 루프를 닫기에 알맞은 자리다. 그것이 루프를 닫을 수 있는 순간에 이미 존재하고 있는 유일한 산출물이기 때문이다.

고객 피드백 루프란 무엇인가

고객 피드백 루프는 사용자가 여러분에게 무언가를 말하는 것에서, 그 사용자가 여러분이 그것에 대해 무엇을 했는지 알게 되기까지의 경로다. 여기에는 네 단계가 있다. 피드백을 수집하고, 그것으로 무엇을 할지 결정하고, 결과를 출시하고, 요청한 사람에게 알리는 것. 네 번째 단계가 일어나기 전까지 루프는 열려 있다. 피드백을 수집하고 수정 사항을 출시하지만 아무에게도 알리지 않는 팀은 루프가 아니라 받은편지함을 갖고 있는 것이다.

이 글이 다루는 것은 네 번째 행이다. 그것이 끊어지는 이유는 문화적인 것이 아니라 구조적인 것이다. 기능이 출시될 무렵이면, 그것을 유발한 요청은 출시된 것과는 다른 시스템 안에 있으며, 그 둘을 연결하는 것을 자기 일로 삼는 사람은 아무도 없다. 루프는 더 앞에서, 요청을 애초에 어떻게 받느냐에서 시작되며, 문구와 타이밍은 고객 피드백을 요청하는 방법에서 다룬다.

왜 피드백 루프는 열린 채로 남는가

피드백 루프가 열린 채로 남는 이유는 요청과 출시된 변경이 서로 다른 곳에 살고 있고, 그 둘 사이의 링크가 만들어진다면 손으로 만들어지기 때문이다. 요청은 피드백 도구, 지원팀 받은편지함, 혹은 스프레드시트 안에 있다. 변경은 pull request 안에 있다. 발표는 체인지로그나 이메일 안에 있다. 세 개의 시스템, 세 명의 소유자, 그리고 세 번째에서 첫 번째로 돌아가는 링크는 누군가 몇 달 후에 누가 요청했는지 기억해내는 것으로 만들어진다.

두 번째 이유가 있다. 통보 단계는 보통 지원 업무(“그 사람에게 답하기”)가 아니라 마케팅 업무(“기능을 발표하기”)로 여겨진다. 발표는 모두에게 가고 특정한 누구에게도 닿지 않는다. 3월에 그 기능을 요청한 사람이 6월의 발표를 읽는다면, 그것을 답장이 아니라 뉴스로서 읽는다. 루프는 그 메시지가 본인에게 향해 있을 때만 닫힌다.

왜 체인지로그 쪽에서 루프를 닫는가

체인지로그 항목이야말로 정확히 알맞은 순간에 존재하고, 정확히 알맞은 말을 담고 있으며, 정확히 알맞은 사람에 의해 쓰이는 유일한 산출물이기 때문이다. 그것은 변경이 공개되었을 때 존재하며 그 이전에는 존재하지 않는다. 그것은 무엇이 바뀌었는지를 독자의 언어로 말하며, 그것이 바로 요청자가 필요로 하는 메시지다. 그리고 그것은 방금 그 pull request를 읽은 사람에 의해 쓰인다. 그것이 원래 요청으로의 링크가 여전히 보이는 유일한 순간이다.

대안들과 비교해보자. 피드백 도구 쪽에서 루프를 닫으려면, 그 기능이 언제 출시되었는지를 피드백 도구가 알아야 하며, 이는 누군가 상태를 손으로 업데이트해야 한다는 뜻이다. pull request 쪽에서 닫으려면, 변경이 아직 공개되지 않은 병합 시점에 고객에게 알리게 되며, 배포가 지연되면 타임스탬프가 찍힌 깨진 약속이 된다. 마케팅 발표 쪽에서 닫으려면 발표가 나올 때까지 기다려야 하는데, 출시된 변경 대부분은 발표를 받지 못한다.

체인지로그는 그 중간에 있다. 병합 이후, 릴리스의 순간에, 문구는 이미 완성된 채로.

루프는 단계별로 어떻게 닫히는가

이것은 우리가 운영하는 메커니즘이다. 여기서는 제품 투어가 아니라 사양으로 서술된다. 모든 단계는 손으로도, 다른 도구로도 할 수 있기 때문이며, 중요한 것은 순서다.

1. 피드백은 그것을 고칠 저장소의 issue가 된다. 위젯 제출은 라벨이 붙은 GitHub issue로 접수된다(feature-request 또는 bug, 우선순위, 그리고 from-widget). 제출자의 이메일 주소는 issue 본문에 넣지 않는다. issue는 코드 바로 옆에 존재하므로, 세 번째 단계가 그것을 찾을 수 있다. 손으로 접수한 issue, 예를 들어 기능 요망 템플릿으로 만든 issue는 이 경로 밖에 있다. 다섯 번째 단계는 거기에 코멘트를 달지 않으므로, 그 루프는 직접 닫아라.
2. 수정 사항이 그 issue를 참조한다. pull request는 Fixes #142라고 적는다. GitHub 자체의 클로즈 키워드다. 새로 배울 것이 없고, 개발자가 이미 쓰고 있는 것과 같은 문장이다.
3. 체인지로그 항목은 병합된 pull request로부터 초안이 작성되며 링크를 운반한다. 병합 시점에 초안이 생성되고, #142가 PR 본문에서 읽혀 초안에 붙는다. 링크는 아직 저렴할 때, 기계에 의해, 이미 그곳에 있는 데이터로부터 만들어진다.
4. 사람이 그 항목을 검토한다. 문구, 대상 독자, 애초에 발행해야 하는지. 폐기된 초안은 아무것도 닫지 않으며, 그것은 옳다. 우연히 issue를 참조했던 내부 리팩터링은 뉴스가 아니기 때문이다.
5. 승인되면 요청자에게 알린다. 피드백으로 만들어진 issue에 코멘트가 게시된다. “Shipped —“에 이어 항목의 제목과 발행된 항목으로의 링크가 붙는다. 그리고 위젯은 제출자에게 같은 출시된 항목을 보여준다. 한 번만, 결코 두 번은 아니며, 사람이 그 항목을 발행한 후에만. 같은 항목은 요청하지 않았던 모든 사람에게 피드와 위젯을 통해 전달된다.

5단계의 순서가 이 설계의 전부다. 병합 시점에 요청자에게 알리는 것이 더 이르고 쉬웠겠지만, 그것은 배포가 지연되는 빈도만큼이나 자주 틀린 것이 되었을 것이다. 피처 플래그는 이 순서마저 깨뜨리는데, 승인과 게시가 기능이 요청자의 계정에는 여전히 보이지 않는 동안 일어날 수 있기 때문이다. 피처 플래그와 기능 요청은 플래그가 개입할 때 이 단계가 필요로 하는 추가 확인을 다룬다.

고객에게 닫힌 루프는 어떻게 보이는가

그것은 답장처럼 보인다. 고객은 위젯을 통해 요청을 보냈다. 그러던 어느 날 위젯이 그것을 출시됨으로 보여주고, 자신의 언어로 그것을 설명하는 항목으로의 링크가 함께 온다. GitHub에서는 issue에도 같은 소식이 코멘트로 달린다. 그들은 뉴스레터를 구독하지도, 로드맵을 확인하지도, 체인지로그를 검색하지도 않았다. 통보받은 것이다.

바로 그 경험이 두 번째 피드백을 일으킨다. 사람들은 답해주는 제품에 피드백을 보낸다. 체인지로그 예시 페이지에는 사용자들이 눈에 띄게 계속 요청을 보내오는 팀들의 항목이 담겨 있으며, 공통점은 도구가 아니다. 항목이 답장처럼 읽힌다는 것이다.

피드백 루프는 어떻게 측정하는가

출시된 변경 중 적어도 한 명의 요청자에게 알린 비율과, 출시부터 통보까지의 시간을 측정하라. 두 개의 숫자이며, 링크가 존재하면 둘 다 쉽고, 존재하지 않으면 둘 다 불가능하다.

• 클로즈율: 이번 달에 발행된 체인지로그 항목 중 적어도 하나의 요청에 링크된 것이 몇 개이고, 그중 요청자에게 통보한 것이 몇 개인가. 두 번째 숫자가 첫 번째보다 훨씬 낮다면 통보가 실패하고 있는 것이고, 첫 번째가 낮다면 요청이 pull request에서 참조되고 있지 않은 것이며, 그 해법은 PR 템플릿에 한 문장을 추가하는 것이다.
• 출시-통보 시간: 항목이 공개된 시점부터 요청자가 통보받는 시점까지의 시간. 위의 메커니즘이 있으면 몇 초다. 손으로 하면 대개 몇 주, 또는 영원히 오지 않으며, 그 “영원히”가 중요한 숫자다.

수집된 피드백의 양으로 루프를 측정하지 마라. 수집은 쉬운 단계이며, 그것을 측정하는 팀은 그것을 최적화하게 되고, 그것은 더 많은 열린 루프를 만들어낸다.

로드맵은 어디에 들어맞는가

공개 로드맵은 루프를 일찍 닫는 방법이다. 요청자에게 그들의 요청이 출시되기 전에 이미 들려졌다고 말해준다. 유용하지만, 마지막 단계를 대신하지는 못한다. “계획됨”은 미래에 대한 약속이고, “출시됨”은 현재에 대한 사실이다. 같은 issue들로부터, 열마다 라벨 하나로 공개 로드맵을 운영하라. 그러면 같은 요청이 어디에도 다시 입력되지 않고 계획됨에서 출시됨으로 이동한다. 출시됨으로의 이동은 라벨 변경(roadmap:shipped)이며, 항목이 승인될 때 그것을 대신 해주는 것은 없으므로 같은 검토에서 처리하라.

FAQ

고객 피드백 루프의 네 단계는 무엇인가? 수집, 결정, 출시, 통보다. 네 번째 단계가 일어나기 전까지 루프는 열려 있다. 많은 프레임워크가 중간에 분석과 우선순위 지정 단계를 추가하지만, 그것들은 “결정”의 세분화일 뿐이며 그중 무엇도 아무것도 닫지 않는다.

요청을 거절할 때도 고객에게 알려야 하는가? 그래야 하며, 그것은 루프에서 가장 소홀히 되는 메시지다. “이것은 하지 않겠습니다, 그리고 이유는 이렇습니다”라는 명확한 말은 기다림을 끝낸다. 침묵은 루프를 영원히 열어두고 고객이 계속 확인하게 만든다.

루프를 닫는 것과 기능을 발표하는 것은 어떻게 다른가? 발표는 모두에게 간다. 루프를 닫는 것은 요청했던 사람들에게, 그들이 요청했던 경로로 답하는 것이다. 둘 다 하라. 그것들은 서로 다른 독자를 위한 서로 다른 메시지다.

요청자가 GitHub을 쓰지 않는다면 어떻게 하는가? 대부분은 쓰지 않으며, 그래도 괜찮다. 위젯은 그들이 보낸 것의 상태를 출시된 항목과 그 링크까지 포함해 계속 보여주므로, 그들은 글을 남긴 페이지 외에는 아무것도 필요 없다. issue의 코멘트는 저장소를 볼 수 있는 사람들을 위한 것이다.

이 루프는 GitHub 대신 GitLab이나 Bitbucket에서도 작동하는가? 위젯과 체인지로그는 작동하지만, 다섯 번째 단계의 자동 코멘트는 아직 작동하지 않는다. GitLab이나 Bitbucket을 쓰는 팀도 모든 제출을 그대로 받고, 그것을 issue로 등록하고, 위젯에 요청자의 상태를 계속 보여줄 수 있다. 다만 그 루프를 issue 자체에 다시 닫아 거는 것은 해당 연동이 생기기 전까지는 손으로 해야 하는 단계다.

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

changeloop 관련 페이지: 개발자 문서, changelog 예시