고객을 잃지 않고 기능 요청을 거절하는 방법은 무엇인가

순환을 닫는다는 것은 보통 누군가에게 그들의 요청이 출시되었다고 말하는 것을 의미한다. 대부분의 추적 시스템이 전혀 절차를 갖고 있지 않은 더 어려운 절반은 거절하는 것이다. 대부분의 기능 요청은 절대 출시되지 않으며, 이는 제품이 사용자에게 실제로 빚지고 있는 순환 닫기의 대부분이 발표가 아니라 거절이라는 뜻이고, 잘못 처리된 거절은 침묵이 들었을 것보다 더 많은 호의를 잃게 만든다. 잘 처리하면 거의 아무것도 들지 않을 수 있는데, 요청한 사람이 대부분의 경우 가장 원하는 것이 기능 자체가 아니라 자신이 들렸다는 것을 아는 것이기 때문이다.

왜 잘 거절하는 것이 잘 출시하는 것만큼 중요한가

침묵은 설명 없는 거절로 읽히고, 설명된 거절은 관심으로 읽히기 때문이다. 아무것도 듣지 못한 사람은 요청이 무시되었거나 사라졌다고 추측하며, 두 결론 모두 그녀에게 다시 묻는 수고를 그만두도록 가르친다. 이는 진짜 거절에서 제품이 얻는 것과 같은 결과이며, 다만 더 느리게 도달하고 그 과정에 더 많은 원망이 따를 뿐이다. 명확하게, 이유와 함께 거절한다고 말하는 답변은 출시된 기능만큼이나 완전하게 순환을 닫으며, 그것을 더 빨리 해낸다.

무엇이 거절을 나쁘게 착지시키는가

거의 항상 세 가지가 결합되어서다. 일반성. 실제로 무엇을 요청했는지 언급하지 않는 정형화된 “피드백 감사합니다”는, 실제로 읽었더라도 전혀 읽지 않은 것처럼 읽힌다. 지연. 요청한 사람이 이미 물어봤다는 것을 잊은 후, 요청으로부터 6개월 후에 도착하는 거절은 빠른 거절보다 더 나쁘게 느껴지는데, 요청이 고려되고 거절된 것이 아니라 손대지 않은 채 방치되었음을 암시하기 때문이다. 그리고 버티지 못하는 이유. “저희 로드맵에 없습니다”는 아무것에도 답하지 않는 반면, “이것은 권한이 작동하는 방식을 재설계해야 하는데, 저희는 올해 그것을 건드릴 계획이 없습니다”는 요청한 사람에게 실제로 평가할 수 있고, 충분히 중요하다면 에스컬레이션하거나 우회할 수 있는 무언가를 준다.

좋은 거절은 실제로 무엇을 말해야 하는가

이 순서대로 네 가지. 일반적인 바꿔 말하기가 아니라 구체적인 요청을 명명하는 인정. 진짜 이유, 정직한 이유가 더 부드러운 변명 대신 “이것은 제품이 향하는 방향에 맞지 않습니다”일 때도 정직하게 진술된 것. 문이 닫혔는지 아니면 지금은 그냥 열려 있지 않은 것인지, 이것은 매우 다른 톤을 필요로 하기 때문이다. 그리고 존재한다면, 문자 그대로 요청된 기능이 아니더라도 근본적인 필요를 다루는 대안.

안녕하세요 Jamie,

팀 초대를 위한 대량 CSV 가져오기 추가 요청 감사합니다. 검토했지만,
저희는 이것을 만들지 않을 것입니다: 저희 초대 흐름은 보안상의
이유로 각 신규 구성원을 개별적으로 검토하는 것을 중심으로
설계되어 있고, 대량 가져오기는 실수가 아니라 설계상 그것에
어긋납니다.

만약 진짜 문제가 큰 팀을 빠르게 초대하는 것이라면, API는 스크립트로
작성된 개별 초대를 지원하며, 검토를 우회하지 않고도 거의 모든
속도를 제공합니다: [링크]. 설정하는 데 도움이 필요하면 알려주세요.

이것이 템플릿이 할 수 없는 것을 하고 있다는 점에 주목하라: 실제 기능을 명명하고, 모호한 정책 대신 실제 설계 결정에 연결된 이유를 제공하며, 티켓을 닫기만 하는 대신 근본적인 문제를 해결하는 경로를 제시한다.

이것이 출시된 기능에서 순환을 닫는 것과 어떻게 다른가

메커니즘은 비슷하지만 톤은 다르다. 고객과의 피드백 순환 닫기가 출시된 경우를 다루는데, 거기서 메시지는 좋은 소식이고 주요 위험은 보내는 것을 잊는 것이다. 거절은 나쁜 소식이거나, 적어도 원하지 않은 소식이며, 주어지는 이유에 더 많은 주의가 필요하고 전달에서 자동화는 덜 필요하다. 출시된 기능 알림은 상태 변경으로 촉발되는 정형화된 댓글일 수 있지만, 정형화된 것처럼 읽히는 거절은 이 접근 전체가 피하려는 바로 그 실패 방식이다. 그래도 둘 다 하나의 요구사항을 공유한다: 원래 요청은 그것을 만든 사람과 계속 연결되어 있어야 하며, 이는 기능 요청 추적이 다루는 것과 같은 추적 원칙이다, 그렇지 않으면 두 메시지 중 어느 쪽도 개별적으로 보낼 방법이 없다.

거절은 공개 로드맵의 상태처럼 공개되어야 하는가

보통 구체적인 이유는 아니지만, 상태는 그럴 수 있다. 공개 로드맵이 요청한 사람이 다시 묻지 않고 확인할 수 있는 상태 라벨을 다루며, “거절됨”이나 “계획 없음” 상태는 그 시스템의 일부가 될 수 있다. 하지만 상세한 이유는, 특히 내부 우선순위나 그다지 좋지 않은 맥락을 건드릴 때, 보통 공개 상태 페이지보다 개별 답변에서 더 가치 있다, 거기서는 같은 표현이 실제로 물어본 그 한 사람이 아니라 모든 독자에게 통해야 하기 때문이다.

거절된 모든 요청이 개별 답변을 받을 자격이 있는가

이름이 있고 연락 가능한 사람의 모든 요청은 그렇다, 적어도 짧게라도. 대량, 중복, 익명 요청은 예외다: 비슷한 요청을 그룹화하고 그룹당 한 번 답변하거나 공유된 상태 라벨을 업데이트하는 것은 개별 답변이 정말로 확장되지 않을 때 합리적이다. 지켜야 할 선은 “모두에게 개별적으로 답변할 수 없습니다”가 실제 물량에 대비해 확인된 진짜 운영상의 제약이어야 한다는 것이지, 2분이면 끝났을 답변을 건너뛰기 위한 기본 변명이어서는 안 된다는 것이다.

FAQ

약한 이유로 빠르게 거절하는 것과 좋은 이유를 위해 시간을 들이는 것 중 어느 쪽이 나은가? 정직한 이유로 빠르게 하는 것이 둘 다 따로따로 이기는 것보다 낫다. 짧더라도 진짜 이유가 있는 빠른 답변이, 다듬어진 이유가 있는 느린 답변보다 낫다. 지연 자체가 신뢰를 해치는 요소의 일부다.

거절이 나중에 요청을 재고하겠다고 약속해야 하는가? 그것이 정말로 가능성이 있고 실제로 재고할 메커니즘이 있을 때만, 예를 들어 계획 주기에서 그것을 다시 떠오르게 하는 라벨 같은 것. 그런 메커니즘 없는 모호한 “염두에 두겠습니다”는 기능적으로 침묵과 같으며, 다만 더 친절하게 표현되었을 뿐이다.

정직한 이유가 경쟁상의 우려처럼 회사가 공유할 수 없는 것이라면 어떻게 해야 하는가? 더 부드러운 이유를 지어내는 대신 그것을 직접 말하라. “여기서 구체적인 근거를 공유할 수는 없지만, 이것은 저희가 만들 계획이 있는 것이 아닙니다”가 후속 질문에서 무너지는 지어낸 설명보다 더 정직하고 더 존중받는다.

요청을 거절하는 것이 추적에서 삭제해야 한다는 뜻인가? 아니다. 이유와 함께 거절됨으로 라벨을 붙여 보관하라, 그것이 다음 비슷한 요청이 그룹화되는 패턴의 일부가 되도록, 그리고 나중에 바뀐 맥락(새 통합, 새 팀 우선순위)이 평가를 처음부터 다시 시작하는 대신 그것을 다시 떠오르게 할 수 있도록.

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

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