Uzavření smyčky zpětné vazby ze strany changelogu

Smyčka zpětné vazby zákazníka je uzavřena, když se osobě, která zpětnou vazbu dala, řekne, co se s ní stalo. Ne když je zaznamenána. Ne když je prioritizována. Ani ne když je vydána. Když jí to řeknou. Většina týmů dobře provádí první tři kroky a poslední vůbec, a pak se diví, proč lidé, kteří posílají zpětnou vazbu, přestávají ji posílat.

Tento článek je o tom posledním kroku, a o konkrétním tvrzení: changelog je správné místo, odkud uzavřít smyčku, protože je to jediný artefakt, který už existuje přesně v okamžiku, kdy lze smyčku uzavřít.

Co je smyčka zpětné vazby zákazníka?

Smyčka zpětné vazby zákazníka je cesta od uživatelky, která vám něco řekne, k té uživatelce, která se dozví, co jste s tím udělali. Má čtyři kroky: sběr zpětné vazby, rozhodnutí, co s ní udělat, vydání výsledku, a informování žadatele. Smyčka je otevřená, dokud se nestane čtvrtý krok. Tým, který sbírá zpětnou vazbu a vydává opravy, ale nikdy nikoho neinformuje, má poštovní schránku, ne smyčku.

Čtvrtý řádek je to, o čem je tento článek. Trhá se ze strukturálního důvodu, ne kulturního: v okamžiku vydání funkce žije požadavek, který ji způsobil, v jiném systému než vydaná věc, a spojení jich není ničím úkolem. Smyčka začíná dřív, tím, jak se o požadavek vůbec žádá; jak žádat o zpětnou vazbu zákazníků pokrývá formulaci a načasování.

Proč zůstávají smyčky zpětné vazby otevřené?

Smyčky zpětné vazby zůstávají otevřené, protože požadavek a vydaná změna žijí na různých místech, a spojení mezi nimi se dělá ručně, pokud vůbec. Požadavek je v nástroji zpětné vazby, schránce podpory nebo tabulce. Změna je v pull requestu. Oznámení je v changelogu nebo e-mailu. Tři systémy, tři vlastníci, a odkaz od třetího zpět k prvnímu je člověk, který si měsíce později pamatuje, kdo se ptal.

Je tu druhý důvod. Krok informování je obvykle rámován jako marketingový úkol («oznámit funkci») místo úkolu podpory («odpovědět osobě»). Oznámení jdou všem a nedosáhnou nikoho konkrétně. Osoba, která požádala o funkci v březnu, čte oznámení v červnu, pokud vůbec, jako novinku, ne jako odpověď. Smyčka se uzavře jen tehdy, pokud je zpráva adresována jí.

Proč uzavírat smyčku ze strany changelogu?

Protože záznam changelogu je jediný artefakt, který existuje přesně ve správný okamžik, obsahuje přesně správná slova, a je napsán přesně správnou osobou. Existuje, když je změna na živo, a ne dříve. Říká, co se změnilo, slovy čtenářky, což je zpráva, kterou žadatel potřebuje. A je napsán někým, kdo právě přečetl pull request, což je jediný okamžik, kdy je odkaz na původní požadavek ještě viditelný.

Porovnejte alternativy. Uzavření smyčky z nástroje zpětné vazby znamená, že nástroj zpětné vazby musí vědět, kdy byla funkce vydána, což znamená, že někdo ručně aktualizuje stav. Uzavření z pull requestu znamená informovat zákaznici při merge, než je změna na živo, porušený slib s časovým razítkem, jakmile se nasazení zpozdí. Uzavření z marketingového oznámení znamená čekat na jedno, a většina vydaných změn ho nikdy nedostane.

Changelog sedí uprostřed: po merge, v okamžiku vydání, s hotovou formulací.

Jak se smyčka uzavírá, krok za krokem

Toto je mechanismus, který provádíme. Je zde popsán jako specifikace spíše než prohlídka produktu, protože každý krok lze udělat ručně nebo jinými nástroji; záleží na pořadí.

1. Zpětná vazba se stane issue v repozitáři, který ji opraví. Odeslání přes widget se zaznamená jako označené issue na GitHubu (feature-request nebo bug, priorita, a from-widget), přičemž e-mailová adresa odesílatele se do těla issue nedostane. Issue žije vedle kódu, aby ho krok tři mohl najít. Issue založené ručně, například ze šablony požadavku na funkci, je mimo tuto cestu: krok pět ho nekomentuje, takže tuhle smyčku uzavřete sami.
2. Oprava odkazuje na issue. Pull request říká Fixes #142, vlastní klíčové slovo pro uzavření od GitHubu. Nic nového se učit nemusí, a je to stejná věta, kterou vývojářky už píší.
3. Záznam changelogu se sestavuje ze sloučeného pull requestu a nese odkaz. Při merge se koncept vytvoří, a #142 se čte z těla PR a připojí ke konceptu. Odkaz se vytváří, dokud je ještě levný, strojem, z dat, která už tam jsou.
4. Člověk záznam revizuje. Formulaci, publikum, zda by se to vůbec mělo zveřejnit. Zahozený koncept nic neuzavírá, což je správné: interní refaktoring, který náhodou odkázal na issue, není novinka.
5. Při schválení je žadatel informován. Komentář se zveřejní na issue, kterým se stala jeho zpětná vazba, «Shipped —» pak titulek záznamu a odkaz na zveřejněný záznam, a widget odesílateli ukáže stejný vydaný záznam. Jednou, nikdy dvakrát, a jen poté, co člověk záznam zveřejnil. Stejný záznam vychází přes kanál a widget všem, kteří se neptali.

Pořadí v pátém kroku je celý design. Informování žadatele při merge by bylo dřívější a snazší, a bylo by nesprávné asi tak často, jak se zpožďují nasazení. Feature flag rozbíjí i tohle pořadí, protože schváleno a zveřejněno se může stát, zatímco funkce je pro účet žadatelky pořád neviditelná; feature flagy a požadavky na funkce rozebírá dodatečnou kontrolu, kterou tenhle krok potřebuje, jakmile je v tom flag.

Jak vypadá uzavřená smyčka pro zákaznici?

Vypadá jako odpověď. Zákaznice poslala požadavek přes widget, a jednoho dne ho widget ukáže jako vydaný, s odkazem na záznam, který to popisuje jejími slovy; na GitHubu dostane issue stejnou zprávu jako komentář. Nepřihlásila se k odběru newsletteru, nekontrolovala roadmapu, nehledala v changelogu. Bylo jí to řečeno.

To je zkušenost, díky které se stane další kus zpětné vazby. Lidé posílají zpětnou vazbu produktům, které odpovídají. Stránka příklady changelogu obsahuje záznamy od týmů, jejichž uživatelé se viditelně vracejí s požadavky, a společné vlákno není v nástroji; je v tom, že se záznamy čtou jako odpovědi.

Jak se měří smyčka zpětné vazby?

Měřte podíl vydaných změn, které informovaly alespoň jednoho žadatele, a čas od vydání do informování. Dvě čísla, obě snadná, jakmile odkaz existuje, a nemožná předtím.

• Míra uzavření: z záznamů changelogu zveřejněných tento měsíc, kolik odkazovalo alespoň na jeden požadavek, a z těch, kolik informovalo žadatele. Pokud je druhé číslo mnohem nižší než první, oznámení selhávají; pokud je první nízké, požadavky se neodkazují z pull requestů, a oprava je jedna věta v šabloně PR.
• Čas od vydání do informování: kolik času uplyne mezi tím, co záznam jde na živo, a informováním žadatele. S mechanismem výše jsou to sekundy. Ručně jsou to typicky týdny, nebo nikdy, a «nikdy» je číslo, na kterém záleží.

Neměřte smyčku podle objemu sesbírané zpětné vazby. Sběr je snadný krok, a tým, který ho měří, ho bude optimalizovat, což produkuje více otevřených smyček.

Kam se hodí roadmap?

Veřejná roadmap je způsob, jak uzavřít smyčku brzy: říká žadatelům, že jejich požadavek byl vyslyšen, než je vydán. Je užitečná, a nenahrazuje poslední krok. «Plánováno» je slib o budoucnosti; «Vydáno» je fakt o přítomnosti. Provozujte veřejnou roadmapu ze stejných issue, s jedním štítkem na sloupec, aby se stejný požadavek pohyboval z plánovaného na vydaný, aniž by byl kdekoli znovu zadán. Přesun do vydaného je změna štítku (roadmap:shipped), kterou za vás po schválení záznamu nic neudělá, takže ji udělejte při stejné revizi.

FAQ

Jaké jsou čtyři kroky smyčky zpětné vazby zákazníka? Sběr, rozhodnutí, vydání, informování. Smyčka je otevřená, dokud se nestane čtvrtý krok. Většina frameworků přidává kroky analýzy a prioritizace uprostřed; jsou to zpřesnění «rozhodnutí», a žádný z nich nic neuzavírá.

Měli by být zákazníci informováni, když je požadavek odmítnut? Ano, a je to nejvíce zanedbávaná zpráva ve smyčce. Jasné «tohle neuděláme, a tady je proč» ukončí čekání. Ticho nechává smyčku otevřenou navždy a zákaznici kontrolující.

Jak se uzavření smyčky liší od oznámení funkce? Oznámení jde všem. Uzavření smyčky je odpověď lidem, kteří se ptali, kanálem, kterým se ptali. Dělejte oba; jsou to různé zprávy pro různé čtenářky.

Co když žadatel není na GitHubu? Většina není, a to je v pořádku. Widget jim dál ukazuje stav toho, co poslali, včetně vydaného záznamu a odkazu na něj, takže nepotřebují nic kromě stránky, ze které psali. Komentář na issue je pro lidi, kteří repozitář vidí.

Funguje tahle smyčka i na GitLabu nebo Bitbucketu místo GitHubu? Widget a changelog ano; automatický komentář z pátého kroku zatím ne. Tým na GitLabu nebo Bitbucketu pořád dostane každé podání, pořád ho založí jako issue, a pořád ukáže žadateli stav ve widgetu, ale uzavření téhle konkrétní smyčky zpět na samotný issue je krok, který dělá ručně, dokud taková integrace neexistuje.

Technická tvrzení v tomto článku nikdo nezávisle neověřil. Pokud tu něco nesedí, dej nám vědět a opravíme to.

Související na changeloop: Dokumentace pro vývojáře, Příklady changelogu