Zamykanie pętli feedbacku od strony changelogu

Pętla feedbacku klienta jest zamknięta, gdy osoba, która dała feedback, dowiaduje się, co się z nim stało. Nie, gdy jest zarejestrowany. Nie, gdy jest priorytetyzowany. Nawet nie, gdy jest wydany. Gdy jej się to powie. Większość zespołów dobrze wykonuje pierwsze trzy kroki, a ostatniego wcale, i potem zastanawia się, dlaczego ludzie wysyłający feedback przestają go wysyłać.

Ten artykuł dotyczy tego ostatniego kroku, i konkretnego twierdzenia: changelog jest właściwym miejscem, by zamknąć pętlę, ponieważ to jedyny artefakt, który już istnieje dokładnie w momencie, gdy pętla może zostać zamknięta.

Czym jest pętla feedbacku klienta?

Pętla feedbacku klienta to droga od użytkowniczki mówiącej wam coś do tej użytkowniczki dowiadującej się, co z tym zrobiliście. Ma cztery kroki: zebranie feedbacku, decyzja, co z nim zrobić, wydanie rezultatu, i poinformowanie proszącej osoby. Pętla jest otwarta, dopóki nie nastąpi czwarty krok. Zespół, który zbiera feedback i wydaje poprawki, ale nigdy nikogo nie informuje, ma skrzynkę odbiorczą, nie pętlę.

Czwarty wiersz to ten, o którym mówi ten artykuł. Psuje się z powodu strukturalnego, nie kulturowego: zanim funkcja zostanie wydana, prośba, która ją spowodowała, żyje w innym systemie niż wydana rzecz, i połączenie ich nie jest niczyim zadaniem. Pętla zaczyna się wcześniej, od tego, jak w ogóle prosi się o prośbę; jak prosić klientów o feedback omawia sformułowania i moment.

Dlaczego pętle feedbacku pozostają otwarte?

Pętle feedbacku pozostają otwarte, ponieważ prośba i wydana zmiana żyją w różnych miejscach, a połączenie między nimi jest tworzone ręcznie, jeśli w ogóle. Prośba jest w narzędziu feedbacku, skrzynce wsparcia lub arkuszu kalkulacyjnym. Zmiana jest w pull requeście. Ogłoszenie jest w changelogu lub e-mailu. Trzy systemy, trzech właścicieli, a link od trzeciego z powrotem do pierwszego to osoba pamiętająca, miesiące później, kto pytał.

Jest drugi powód. Krok informowania jest zwykle ramowany jako zadanie marketingowe (“ogłosić funkcję”) zamiast zadania wsparcia (“odpowiedzieć osobie”). Ogłoszenia idą do wszystkich i nie docierają do nikogo konkretnie. Osoba, która poprosiła o funkcję w marcu, czyta ogłoszenie w czerwcu, jeśli je czyta, jako wiadomość, nie jako odpowiedź. Pętla zamyka się tylko, jeśli wiadomość jest skierowana do niej.

Dlaczego zamykać pętlę od strony changelogu?

Ponieważ wpis changelogu to jedyny artefakt, który istnieje dokładnie w odpowiednim momencie, zawiera dokładnie odpowiednie słowa, i jest napisany przez dokładnie odpowiednią osobę. Istnieje, gdy zmiana jest na żywo, i nie wcześniej. Mówi, co się zmieniło w słowach czytelniczki, co jest wiadomością, której potrzebuje proszący. I jest napisany przez kogoś, kto właśnie przeczytał pull request, co jest jedynym momentem, w którym link do oryginalnej prośby jest wciąż widoczny.

Porównajcie alternatywy. Zamykanie pętli z narzędzia feedbacku oznacza, że narzędzie feedbacku musi wiedzieć, kiedy funkcja została wydana, co oznacza, że ktoś ręcznie aktualizuje status. Zamykanie jej z pull requesta oznacza informowanie klientki przy merge’u, zanim zmiana jest na żywo, złamaną obietnicę ze znacznikiem czasu, gdy tylko wdrożenie się opóźnia. Zamykanie jej z ogłoszenia marketingowego oznacza czekanie na nie, a większość wydanych zmian nigdy go nie dostaje.

Changelog siedzi pośrodku: po merge’u, w momencie wydania, z gotowym sformułowaniem.

Jak zamyka się pętla, krok po kroku

To mechanizm, który prowadzimy. Jest tu opisany jako specyfikacja, a nie wycieczka po produkcie, ponieważ każdy krok można wykonać ręcznie lub innymi narzędziami; ważna jest kolejność.

1. Feedback staje się issue w repozytorium, które je naprawi. Zgłoszenie z widgetu jest rejestrowane jako oznakowane issue na GitHubie (feature-request lub bug, priorytet, i from-widget), a adres e-mail osoby zgłaszającej nie trafia do treści issue. Issue żyje obok kodu, żeby krok trzeci mógł je znaleźć. Issue założone ręcznie, na przykład z szablonu prośby o funkcję, jest poza tą ścieżką: krok piąty go nie komentuje, więc tę pętlę zamknijcie sami.
2. Poprawka odwołuje się do issue. Pull request mówi Fixes #142, własne słowo kluczowe zamykania GitHuba. Nic nowego do nauczenia się, i to to samo zdanie, które deweloperki już piszą.
3. Wpis changelogu jest przygotowywany ze zmergowanego pull requesta i niesie link. Przy merge’u szkic jest tworzony, a #142 jest odczytywane z treści PR i dołączane do szkicu. Link jest tworzony, gdy jest jeszcze tani, przez maszynę, z danych, które już tam są.
4. Osoba recenzuje wpis. Sformułowanie, odbiorcy, czy w ogóle powinien zostać opublikowany. Odrzucony szkic niczego nie zamyka, co jest poprawne: wewnętrzny refaktoring, który przypadkiem odwołał się do issue, to nie wiadomość.
5. Po zatwierdzeniu proszący jest informowany. Komentarz jest publikowany na issue, którym stał się jego feedback, “Shipped —” po którym następuje tytuł wpisu i link do opublikowanego wpisu, a widget pokazuje zgłaszającemu ten sam wydany wpis. Raz, nigdy dwa razy, i tylko po tym, jak osoba opublikowała wpis. Ten sam wpis wychodzi przez kanał i widget do wszystkich, którzy nie pytali.

Kolejność w kroku piątym to cały projekt. Informowanie proszącego przy merge’u byłoby wcześniej i łatwiej, i byłoby błędne mniej więcej tak często, jak opóźniają się wdrożenia. Feature flag psuje nawet ten porządek, bo zatwierdzone i opublikowane może się zdarzyć, gdy funkcja wciąż jest niewidoczna dla konta proszącej; feature flagi i prośby o funkcje opisuje dodatkową weryfikację, jakiej ten krok potrzebuje, gdy w grę wchodzi flaga.

Jak wygląda zamknięta pętla dla klientki?

Wygląda jak odpowiedź. Klientka wysłała prośbę przez widget, i pewnego dnia widget pokazuje ją jako wydaną, z linkiem do wpisu, który opisuje to jej słowami; na GitHubie issue dostaje tę samą wiadomość jako komentarz. Nie zapisała się na newsletter, nie sprawdziła roadmapy, nie szukała w changelogu. Powiedziano jej.

To doświadczenie sprawia, że następny kawałek feedbacku się dzieje. Ludzie wysyłają feedback do produktów, które odpowiadają. Strona przykłady changelogu zawiera wpisy zespołów, których użytkownicy widocznie wracają z prośbami, a wspólnym wątkiem nie są narzędzia; to, że wpisy czyta się jak odpowiedzi.

Jak mierzy się pętlę feedbacku?

Mierzcie ułamek wydanych zmian, które poinformowały przynajmniej jedną proszącą osobę, i czas od wydania do poinformowania. Dwie liczby, obie łatwe, gdy link istnieje, i niemożliwe wcześniej.

• Wskaźnik zamknięcia: z wpisów changelogu opublikowanych w tym miesiącu, ile linkowało przynajmniej jedną prośbę, i z tego, ile poinformowało proszącego. Jeśli druga liczba jest znacznie niższa niż pierwsza, powiadomienia zawodzą; jeśli pierwsza jest niska, prośby nie są odwoływane z pull requestów, a poprawka to jedno zdanie w szablonie PR.
• Czas od wydania do poinformowania: ile czasu między wejściem wpisu na żywo a poinformowaniem proszącego. Z powyższym mechanizmem to sekundy. Ręcznie to zwykle tygodnie, lub nigdy, a “nigdy” to liczba, która ma znaczenie.

Nie mierzcie pętli objętością zebranego feedbacku. Zbieranie to łatwy krok, a zespół, który go mierzy, będzie go optymalizował, co produkuje więcej otwartych pętli.

Gdzie pasuje roadmapa?

Publiczna roadmapa to sposób na wczesne zamknięcie pętli: mówi proszącym, że ich prośba została wysłuchana, zanim zostanie wydana. Jest użyteczna, i nie zastępuje ostatniego kroku. “Zaplanowane” to obietnica na przyszłość; “Wydane” to fakt o teraźniejszości. Prowadźcie publiczną roadmapę z tych samych issue, z jedną etykietą na kolumnę, żeby ta sama prośba przechodziła od zaplanowanej do wydanej bez ponownego wprowadzania nigdzie. Przejście do wydanych to zmiana etykiety (roadmap:shipped), której nic nie zrobi za was po zatwierdzeniu wpisu, więc zróbcie ją w ramach tej samej recenzji.

FAQ

Jakie są cztery kroki pętli feedbacku klienta? Zbieranie, decydowanie, wydanie, informowanie. Pętla jest otwarta, dopóki nie nastąpi czwarty krok. Większość frameworków dodaje kroki analizy i priorytetyzacji pośrodku; to udoskonalenia “decydowania”, i żaden z nich niczego nie zamyka.

Czy klienci powinni być informowani, gdy prośba jest odrzucona? Tak, i to najbardziej zaniedbywana wiadomość w pętli. Jasne “nie zrobimy tego, i oto dlaczego” kończy oczekiwanie. Cisza pozostawia pętlę otwartą na zawsze, a klientkę sprawdzającą.

Czym zamykanie pętli różni się od ogłaszania funkcji? Ogłoszenie idzie do wszystkich. Zamykanie pętli to odpowiedź dla ludzi, którzy pytali, kanałem, którym pytali. Rób oba; to różne wiadomości dla różnych czytelniczek.

A jeśli proszący nie korzysta z GitHuba? Większość nie korzysta, i to w porządku. Widget dalej pokazuje im status tego, co wysłali, łącznie z wydanym wpisem i linkiem do niego, więc nie potrzebują niczego poza stroną, z której pisali. Komentarz na issue jest dla osób, które widzą repozytorium.

Czy ta pętla działa na GitLabie albo Bitbuckecie zamiast GitHuba? Widget i changelog tak; automatyczny komentarz w kroku piątym na razie nie. Zespół na GitLabie albo Bitbuckecie wciąż dostaje każde zgłoszenie, wciąż zapisuje je jako issue i wciąż pokazuje proszącemu status w widgecie, ale zamknięcie tej konkretnej pętli z powrotem na samym issue to krok, który do czasu powstania takiej integracji robi się ręcznie.

Twierdzenia techniczne w tym artykule nie zostały niezależnie zweryfikowane. Jeśli coś się nie zgadza, daj nam znać, a poprawimy to.

Powiązane w changeloop: Dokumentacja dla deweloperów, Przykłady changeloga