Замыкание петли обратной связи со стороны changelog

Петля обратной связи клиента замкнута, когда человеку, давшему обратную связь, сообщают, что с ней произошло. Не когда она зарегистрирована. Не когда приоритизирована. Даже не когда выпущена. Когда ему говорят. Большинство команд хорошо выполняют первые три шага и совсем не выполняют последний, а потом удивляются, почему люди, отправляющие обратную связь, перестают её отправлять.

Эта статья о том последнем шаге, и о конкретном утверждении: changelog — верное место для замыкания петли, потому что это единственный артефакт, уже существующий именно в тот момент, когда петлю можно замкнуть.

Что такое петля обратной связи клиента?

Петля обратной связи клиента — это путь от пользователя, говорящего вам что-то, до этого пользователя, узнающего, что вы с этим сделали. У неё четыре шага: сбор обратной связи, решение, что с ней делать, выпуск результата, и уведомление запросившего. Петля открыта, пока не произойдёт четвёртый шаг. У команды, собирающей обратную связь и выпускающей исправления, но никогда никого не уведомляющей, есть почтовый ящик, а не петля.

Четвёртая строка — то, о чём эта статья. Она рвётся по структурной причине, а не культурной: к моменту выпуска функции запрос, вызвавший её, живёт в другой системе, чем выпущенная вещь, и соединение их — не чья-то обязанность. Петля начинается раньше, с того, как запрос вообще запрашивается; формулировки и время описаны в статье как попросить обратную связь у клиентов.

Почему петли обратной связи остаются открытыми?

Петли обратной связи остаются открытыми, потому что запрос и выпущенное изменение живут в разных местах, а связь между ними устанавливается вручную, если вообще устанавливается. Запрос в инструменте обратной связи, ящике поддержки или таблице. Изменение в pull request. Объявление в changelog или письме. Три системы, три владельца, и ссылка от третьей обратно к первой — это человек, вспоминающий месяцы спустя, кто спрашивал.

Есть вторая причина. Шаг уведомления обычно оформляется как маркетинговая задача («объявить функцию») вместо задачи поддержки («ответить человеку»). Объявления идут всем и не достигают никого конкретно. Человек, попросивший функцию в марте, читает объявление в июне, если вообще читает, как новость, а не как ответ. Петля замыкается, только если сообщение адресовано ему.

Почему замыкать петлю со стороны changelog?

Потому что запись changelog — единственный артефакт, существующий именно в правильный момент, содержащий именно правильные слова, и написанный именно правильным человеком. Она существует, когда изменение в эфире, и не раньше. Она говорит, что изменилось, словами читательницы, что и есть сообщение, в котором нуждается запросивший. И написана кем-то, кто только что прочитал pull request, что является единственным моментом, когда ссылка на исходный запрос всё ещё видна.

Сравните альтернативы. Замыкание петли из инструмента обратной связи означает, что инструменту обратной связи нужно знать, когда функция выпущена, что означает, что кто-то вручную обновляет статус. Замыкание её из pull request означает уведомление клиентки при merge, до того как изменение в эфире, нарушенное обещание с временной меткой, как только развёртывание задерживается. Замыкание её из маркетингового объявления означает ожидание такового, а большинство выпущенных изменений его никогда не получают.

Changelog находится посередине: после merge, в момент релиза, с готовой формулировкой.

Как замыкается петля, шаг за шагом

Это механизм, который мы выполняем. Он описан здесь как спецификация, а не как тур по продукту, потому что каждый шаг можно выполнить вручную или другими инструментами; важен порядок.

1. Обратная связь становится issue в репозитории, который её исправит. Отправка через виджет регистрируется как помеченный issue на GitHub (feature-request или bug, приоритет, и from-widget), причём адрес электронной почты отправителя в тело issue не попадает. Issue живёт рядом с кодом, чтобы шаг три мог его найти. Issue, созданный вручную, например по шаблону запроса функции, находится вне этого пути: шаг пять его не комментирует, так что эту петлю замыкайте сами.
2. Исправление ссылается на issue. Pull request говорит Fixes #142, собственное ключевое слово закрытия GitHub. Ничего нового учить не нужно, и это то же предложение, которое разработчицы уже пишут.
3. Запись changelog составляется из объединённого pull request и несёт ссылку. При merge черновик создаётся, а #142 читается из тела PR и прикрепляется к черновику. Ссылка создаётся, пока ещё дёшево, машиной, из данных, которые уже там есть.
4. Человек рецензирует запись. Формулировку, аудиторию, стоит ли вообще публиковать. Выброшенный черновик ничего не замыкает, что верно: внутренний рефакторинг, случайно сославшийся на issue, — не новость.
5. При одобрении запросивший уведомляется. Комментарий публикуется в issue, которым стал его отзыв, «Shipped —» затем заголовок записи и ссылка на опубликованную запись, а виджет показывает отправителю ту же выпущенную запись. Один раз, никогда дважды, и только после того, как человек опубликовал запись. Та же запись выходит через ленту и виджет всем, кто не спрашивал.

Порядок в пятом шаге — весь дизайн. Уведомление запросившего при merge было бы раньше и легче, и было бы неверным примерно так же часто, как задерживаются развёртывания. Feature flag ломает даже этот порядок, потому что одобрено и опубликовано может произойти, пока функция всё ещё невидима для аккаунта запросившего; feature flag и запросы на функции разбирает дополнительную проверку, которая нужна этому шагу, как только задействован флаг.

Как выглядит замкнутая петля для клиентки?

Она выглядит как ответ. Клиентка отправила запрос через виджет, и однажды виджет показывает его выпущенным, со ссылкой на запись, описывающую это её словами; на GitHub issue получает ту же новость в виде комментария. Она не подписалась на рассылку, не проверяла roadmap, не искала в changelog. Ей сказали.

Это опыт, заставляющий случиться следующий кусок обратной связи. Люди отправляют обратную связь продуктам, которые отвечают. Страница примеры changelog включает записи от команд, чьи пользователи явно продолжают возвращаться с запросами, и общая нить не в инструменте; она в том, что записи читаются как ответы.

Как измерить петлю обратной связи?

Измеряйте долю выпущенных изменений, уведомивших хотя бы одного запросившего, и время от выпуска до уведомления. Два числа, оба лёгкие, как только ссылка существует, и невозможные до этого.

• Коэффициент замыкания: из записей changelog, опубликованных в этом месяце, сколько связаны хотя бы с одним запросом, и из них, сколько уведомили запросившего. Если второе число намного ниже первого, уведомления проваливаются; если первое низкое, запросы не связываются из pull request, и исправление — это одно предложение в шаблоне PR.
• Время от выпуска до уведомления: сколько времени между выходом записи в эфир и уведомлением запросившего. С механизмом выше это секунды. Вручную это обычно недели, или никогда, и «никогда» — число, которое важно.

Не измеряйте петлю по объёму собранной обратной связи. Сбор — лёгкий шаг, и команда, которая его измеряет, будет его оптимизировать, что производит больше открытых петель.

Где вписывается roadmap?

Публичная roadmap — это способ замкнуть петлю раньше: она говорит запросившим, что их запрос услышан, до его выпуска. Она полезна, и не заменяет последний шаг. «Запланировано» — это обещание о будущем; «Выпущено» — это факт о настоящем. Ведите публичную roadmap из тех же issue, с одной меткой на колонку, чтобы один и тот же запрос переходил от запланированного к выпущенному без повторного ввода где-либо. Перевод в выпущенное делается сменой метки (roadmap:shipped), которую никто не сделает за вас при одобрении записи, так что делайте это в том же ревью.

FAQ

Каковы четыре шага петли обратной связи клиента? Сбор, решение, выпуск, уведомление. Петля открыта, пока не произойдёт четвёртый шаг. Большинство фреймворков добавляют шаги анализа и приоритизации в середине; это уточнения «решения», и ни один из них ничего не замыкает.

Следует ли уведомлять клиентов, когда запрос отклонён? Да, и это самое пренебрегаемое сообщение в петле. Чёткое «мы не будем это делать, и вот почему» заканчивает ожидание. Молчание оставляет петлю открытой навсегда, а клиентку — проверяющей.

Чем замыкание петли отличается от объявления функции? Объявление идёт всем. Замыкание петли — это ответ людям, которые спрашивали, по каналу, через который они спрашивали. Делайте оба; это разные сообщения для разных читательниц.

А если запросившего нет на GitHub? Большинства там нет, и это нормально. Виджет продолжает показывать им статус того, что они отправили, включая выпущенную запись и её ссылку, так что им не нужно ничего, кроме страницы, с которой они писали. Комментарий в issue предназначен для тех, кто видит репозиторий.

Работает ли эта петля с GitLab или Bitbucket вместо GitHub? Виджет и changelog работают; автоматический комментарий на шаге пять пока нет. Команда на GitLab или Bitbucket всё равно получает каждую заявку, всё равно заводит её как issue и всё равно показывает запросившему статус в виджете, но замыкание именно этой петли обратно на сам issue приходится делать вручную, пока такая интеграция не появится.

Технические утверждения в этой статье не проходили независимую проверку. Если здесь что-то не так, сообщите нам, и мы исправим.

По теме на changeloop: Документация для разработчиков, Примеры changelog