새 기능을 어떻게 발표해야 하는가 (침묵 없이)

대부분의 기능 발표는 아무도 두 번 읽지 않는 채널에서 죽는다. 스크롤을 지나쳐 사라지는 트윗, 구독자가 그 주에 받은 다른 열두 통 아래 묻힌 출시일 이메일, 팀 절반이 몇 달 전에 음소거한 채널의 슬랙 메시지. 기능은 출시되었다. 그것을 썼을 사람들 대부분은 몰랐다. 이것을 고치는 일은 더 나은 발표문을 쓰는 것보다는 올바른 독자에게 올바른 채널을 고르는 것, 그리고 명시적으로 요청한 사람들이 일반적인 메시지를 알아채기를 기대하는 대신 그들에게 직접 닿는 것에 더 가깝다.

새 기능은 실제로 어디에서 발표되어야 하는가

한 곳 이상에서, “모두가 같은 채널을 읽는다”는 결코 사실이 아니기 때문이다. 체인지로그나 피드 항목은 자신의 속도로 확인하며 영구적이고 날짜가 적힌 기록을 원하는 독자를 위한 것이다. 앱 내 알림은 이미 제품을 쓰고 있고 그 기능이 존재한다는 걸 알면 오늘 당장 쓸 독자를 위한 것이다. 이메일은 현재 제품에 없지만 알맞은 업데이트를 위해 돌아올 독자를 위한 것이다. 소셜 미디어는 거의 타겟팅 없이 기존 사용자를 넘어서는 도달을 위한 것이다.

넷 중 어느 것도 혼자서는 충분하지 않다. 체인지로그는 크기와 상관없이 모든 릴리스를 담아야 하는 유일한 문서다. 나머지 모든 것이 다시 참조하는 기록이기 때문이다. 나머지 셋은 그 위에 더해지는 증폭이며, 기능이 실제로 얼마나 큰지에 따라 선택된다.

발표는 무엇을 먼저 말해야 하는가

메커니즘이 아니라 결과다. “보고서 엔드포인트에 캐시 레이어를 추가했다”는 팀이 무엇을 만들었는지 설명한다. “보고서가 이제 1초 안에 로드된다”는 독자에게 무엇이 바뀌었는지 설명하며, 바로 이 문장이 클릭을 얻는다. 세 번째 절이 아니라 첫 번째 절에서 “이게 나한테 무슨 소용인가”에 답하기 때문이다. 메커니즘은 체인지로그 항목이나 상세 페이지에 속하지, 제목에 속하지 않는다.

형용사보다 구체성을 앞세워라. “더 빠르고 더 강력한 보고서 경험”은 독자에게 행동할 만한 어떤 것도 말해주지 않는다. “보고서가 이제 1초 안에 로드되고 상태로 필터링할 수 있다”는 정확히 무엇이 바뀌었고 무엇을 시도해야 하는지 말해준다. 두 번째 버전은 더 믿을 만하게도 느껴지는데, 막연한 주장은 구체적으로 할 말이 없을 때 마케팅 문구가 들리는 것과 정확히 똑같이 들리기 때문이다.

제품 업데이트 이메일과는 어떻게 다른가

겹치지만 동일하지는 않다. 제품 업데이트 이메일이 빈도, 제목, 그리고 다이제스트가 단발성 발송을 이길 때를 포함해 이메일 채널을 구체적으로 다룬다. 새 기능 발표는 근본적인 사건이다. 이메일은 그것을 담을 수 있는 위 네 채널 중 하나이며, 기능이 다음 다이제스트에 실리는 대신 전용 발송을 정당화할 만큼 클 때 선택된다. 작은 기능은 체인지로그 항목과 어쩌면 앱 내 알림을 받을 만하다. 중요한 기능은 시간을 맞춘 네 채널 모두를 받을 만하다.

그것을 요청한 바로 그 사람들에게는 어떻게 닿는가

이것은 노력 대비 효과가 가장 좋은 발표이며, 거의 모든 팀이 건너뛴다. 열 명의 고객이 이름으로 기능을 요청했다면, 그 열 명은 나가는 어떤 더 넓은 발표와도 상관없이 출시되는 순간 직접적이고 개인적인 메모를 받을 만하다. 고객과의 피드백 순환 닫기가 그 메커니즘을 완전히 다룬다. 여기서 요약하면, 이것은 원래 요청이 요청한 사람과 계속 연결되어 있을 때만 작동하는데, 이는 발표 문제라기보다는 추적 문제에 가깝다. changeloop에서는 위젯 피드백이 GitHub 이슈가 되고 병합된 pull request가 그것을 닫으면(fixes #142), 체인지로그 항목을 승인할 때 그 이슈에 “Shipped —

항목 자체는 어떻게 쓰는가

다른 릴리스 노트 항목과 같은 원칙이다. 독자가 이제 할 수 있는 것으로 시작하고, 필요한 설정으로 이어가고, 내부적인 정당화는 건너뛴다. 릴리스 노트 쓰는 법이 완전한 방법을 다룬다. 새 기능 발표는 판돈이 가장 큰 경우다. 제품의 체인지로그를 한 번도 본 적 없는 누군가에 의해 캡처되고, 전달되고, 읽힐 가능성이 가장 높은 항목이기 때문이다.

언제 널리 발표하지 말아야 하는가

기능이 아직 계정 일부에만 롤아웃 중일 때, 정말로 베타일 때, 또는 가격이나 접근 제한 때문에 넓은 발표를 읽는 독자 열 명 중 아홉 명이 아직 쓸 수 없을 때다. 열 명 중 아홉 명이 쓸 수 없는 기능의 넓은 발표는 미끼처럼 읽히며, 지금의 관심보다 다음 발표에 대한 신뢰를 더 많이 태워버린다. 해법은 침묵이 아니라 범위다. 자격이 있는 계정에는 직접 알리고, 가용성이 발표를 따라잡을 때까지 넓은 채널을 미뤄라.

FAQ

모든 새 기능이 자체 발표를 받을 만한가? 모두 체인지로그 항목을 받을 만하다. 누군가 제품을 쓰는 방식을 바꿀 만큼 중요하거나 이름으로 명시적으로 요청된 것만이 이메일이나 소셜 미디어 같은 더 넓은 채널을 받을 만하다.

작은 기능에 가장 좋은 채널은 무엇인가? 체인지로그만, 그리고 사용자가 이미 있는 흐름 안에서 기능을 발견할 수 있다면 앱 내 알림도. 이메일과 소셜 미디어는 관심을 요청할 만한 기능에 대해 그만한 가치가 있다.

구체적으로 요청한 사람들에게는 기능을 어떻게 발표하는가? 등록되는 순간부터 요청을 요청한 사람과 연결된 상태로 유지하고, 어떤 더 넓은 발표와도 별개로 출시 시 개별적으로 알려라. 요청한 사람이 스스로 확인할 수 있는 공유 상태 라벨도 애초에 필요한 개별 메시지 수를 줄여준다.

기능 발표에 스크린샷이 필요한가? 시각적인 모든 것에는 그렇다. 설명은 되었지만 보이지 않은 기능은 독자가 미리보기를 볼 수 있는 기능보다 훨씬 더 자주 건너뛰어진다. API나 백엔드 기능이라면 짧은 코드 예제가 UI 변경에 대한 스크린샷과 같은 일을 한다.

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

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