Închiderea buclei de feedback din partea changelog-ului

O buclă de feedback a clientului e închisă când persoana care a dat feedback-ul e anunțată ce s-a întâmplat cu el. Nu când e înregistrat. Nu când e prioritizat. Nici măcar când e lansat. Când i se spune. Majoritatea echipelor fac bine primii trei pași și pe ultimul deloc, apoi se întreabă de ce oamenii care trimit feedback se opresc din a-l trimite.

Acest articol e despre acel ultim pas, și despre o afirmație concretă: changelog-ul e locul potrivit de unde să închideți bucla, pentru că e singurul artefact care există deja exact în momentul în care bucla poate fi închisă.

Ce e o buclă de feedback a clientului?

O buclă de feedback a clientului e drumul de la o utilizatoare care vă spune ceva până la acea utilizatoare care află ce ați făcut în legătură cu asta. Are patru pași: colectarea feedback-ului, decizia ce să faceți cu el, lansarea rezultatului, și anunțarea persoanei care a cerut. Bucla e deschisă până se întâmplă al patrulea pas. O echipă care colectează feedback și lansează corecții dar nu anunță niciodată pe nimeni are o cutie poștală, nu o buclă.

A patra linie e cea despre care e acest articol. Se rupe dintr-un motiv structural, nu cultural: până la lansarea unei funcții, cererea care a cauzat-o trăiește într-un sistem diferit de lucrul lansat, și conectarea lor nu e treaba nimănui. Bucla începe mai devreme, cu felul în care e cerută cererea de la bun început; cum ceri feedback clienților acoperă formularea și momentul.

De ce rămân buclele de feedback deschise?

Buclele de feedback rămân deschise pentru că cererea și schimbarea lansată trăiesc în locuri diferite, iar legătura dintre ele e făcută manual, dacă e făcută. Cererea e într-o unealtă de feedback, o cutie de suport sau o foaie de calcul. Schimbarea e într-un pull request. Anunțul e într-un changelog sau un e-mail. Trei sisteme, trei proprietari, iar link-ul de la al treilea înapoi la primul e o persoană care-și amintește, luni mai târziu, cine a cerut.

Există un al doilea motiv. Pasul de anunțare e de obicei încadrat ca o sarcină de marketing (“anunțarea funcției”) în loc de o sarcină de suport (“răspunsul persoanei”). Anunțurile merg la toată lumea și nu ajung la nimeni în particular. Persoana care a cerut funcția în martie citește anunțul în iunie, dacă îl citește, ca știre, nu ca răspuns. Bucla se închide doar dacă mesajul îi e adresat.

De ce închideți bucla din partea changelog-ului?

Pentru că intrarea de changelog e singurul artefact care există exact în momentul potrivit, conține exact cuvintele potrivite, și e scris de exact persoana potrivită. Există când schimbarea e live și nu înainte. Spune ce s-a schimbat în termenii cititoarei, ceea ce e mesajul de care are nevoie solicitantul. Și e scris de cineva care tocmai a citit pull request-ul, ceea ce e singurul moment în care link-ul către cererea originală e încă vizibil.

Comparați alternativele. Închiderea buclei din unealta de feedback înseamnă că unealta de feedback trebuie să știe când funcția a fost lansată, ceea ce înseamnă că cineva actualizează manual un status. Închiderea ei din pull request înseamnă anunțarea clientei la merge, înainte ca schimbarea să fie live, o promisiune ruptă cu marcaj temporal de îndată ce implementarea întârzie. Închiderea ei din anunțul de marketing înseamnă așteptarea unuia, iar majoritatea schimbărilor lansate nu primesc niciodată unul.

Changelog-ul stă la mijloc: după merge, la momentul lansării, cu formularea gata.

Cum se închide bucla, pas cu pas

Ăsta e mecanismul pe care-l rulăm. E descris aici ca o specificație, nu ca un tur de produs, pentru că fiecare pas poate fi făcut manual sau cu alte unelte; ce contează e ordinea.

1. Feedback-ul devine un issue în repository-ul care-l va rezolva. O trimitere prin widget e înregistrată ca un issue etichetat pe GitHub (feature-request sau bug, o prioritate, și from-widget), iar adresa de e-mail a persoanei care a trimis nu ajunge în corpul issue-ului. Issue-ul trăiește lângă cod, ca pasul trei să-l poată găsi. Un issue creat manual, de exemplu dintr-un șablon de cerere de funcție, e în afara acestui drum: pasul cinci nu-l comentează, deci închideți voi acea buclă.
2. Corecția face referire la issue. Pull request-ul spune Fixes #142, propriul cuvânt cheie de închidere al GitHub. Nimic nou de învățat, și e aceeași propoziție pe care dezvoltatoarele o scriu deja.
3. Intrarea de changelog e redactată din pull request-ul integrat și poartă link-ul. La merge, ciorna e creată, iar #142 e citit din corpul PR-ului și atașat ciornei. Link-ul e creat cât timp încă e ieftin, de o mașină, din date care sunt deja acolo.
4. O persoană revizuiește intrarea. Formularea, audiența, dacă ar trebui publicată deloc. O ciornă aruncată nu închide nimic, ceea ce e corect: un refactor intern care întâmplător a făcut referire la un issue nu e o știre.
5. La aprobare, solicitantul e anunțat. Un comentariu e publicat pe issue-ul în care s-a transformat feedback-ul lui, “Shipped —” urmat de titlul intrării și un link către intrarea publicată, iar widget-ul îi arată celui care a trimis aceeași intrare lansată. O dată, niciodată de două ori, și doar după ce o persoană a publicat intrarea. Aceeași intrare iese prin flux și widget tuturor celor care n-au cerut.

Ordinea în pasul cinci e tot designul. Anunțarea solicitantului la merge ar fi mai devreme și mai ușoară, și ar fi greșită aproximativ la fel de des cum întârzie implementările. Un feature flag rupe chiar și această ordine, pentru că aprobat și publicat se poate întâmpla în timp ce funcționalitatea tot e invizibilă pentru contul solicitantei; feature flag-uri și cereri de funcționalități acoperă verificarea suplimentară de care are nevoie acest pas odată ce apare un flag.

Cum arată o buclă închisă pentru clientă?

Arată ca un răspuns. Clienta a trimis o cerere printr-un widget, și într-o zi widget-ul o arată ca lansată, cu un link către o intrare care o descrie în termenii ei; pe GitHub, issue-ul primește aceeași veste ca un comentariu. N-a abonat la un newsletter, n-a verificat o roadmap, n-a căutat în changelog. I s-a spus.

Asta e experiența care face să se întâmple următoarea bucată de feedback. Oamenii trimit feedback produselor care răspund. Pagina exemple de changelog include intrări de la echipe ai căror utilizatori se întorc vizibil cu cereri, iar firul comun nu e unealta; e că intrările se citesc ca răspunsuri.

Cum se măsoară o buclă de feedback?

Măsurați fracția schimbărilor lansate care au anunțat cel puțin un solicitant, și timpul de la lansare la anunț. Două numere, ambele ușoare odată ce link-ul există și imposibile înainte.

• Rata de închidere: din intrările de changelog publicate luna asta, câte au legat cel puțin o cerere, și din acestea, câte au anunțat solicitantul. Dacă al doilea număr e mult mai mic decât primul, notificările eșuează; dacă primul e mic, cererile nu sunt referite din pull request-uri, iar corecția e o propoziție în șablonul PR.
• Timpul de la lansare la anunț: cât timp între intrarea devenind live și anunțul solicitantului. Cu mecanismul de mai sus sunt secunde. Manual sunt de obicei săptămâni, sau niciodată, iar “niciodată” e numărul care contează.

Nu măsurați bucla după volumul de feedback colectat. Colectarea e pasul ușor, iar o echipă care-l măsoară îl va optimiza, ceea ce produce mai multe bucle deschise.

Unde se potrivește roadmap-ul?

O roadmap publică e o modalitate de a închide bucla mai devreme: le spune solicitanților că cererea lor a fost auzită, înainte de a fi lansată. E utilă, și nu înlocuiește ultimul pas. “Planificat” e o promisiune despre viitor; “Lansat” e un fapt despre prezent. Rulați roadmap-ul public din aceleași issue-uri, cu o etichetă pe coloană, ca aceeași cerere să se miște de la planificată la lansată fără să fie reintrodusă niciunde. Mutarea la lansat e o schimbare de etichetă (roadmap:shipped) pe care nimic n-o face în locul vostru când intrarea e aprobată, deci faceți-o în aceeași revizuire.

FAQ

Care sunt cei patru pași ai unei bucle de feedback a clientului? Colectare, decizie, lansare, anunț. Bucla e deschisă până se întâmplă al patrulea pas. Majoritatea framework-urilor adaugă pași de analiză și prioritizare în mijloc; sunt rafinări ale “deciziei”, și niciunul nu închide nimic.

Ar trebui anunțați clienții când o cerere e respinsă? Da, și e mesajul cel mai neglijat din buclă. Un clar “nu vom face asta, și iată de ce” încheie așteptarea. Tăcerea lasă bucla deschisă pentru totdeauna și clienta verificând.

Cum diferă închiderea buclei de anunțarea unei funcții? Un anunț merge la toată lumea. Închiderea buclei e un răspuns pentru oamenii care au cerut, pe canalul prin care au cerut. Faceți ambele; sunt mesaje diferite pentru cititoare diferite.

Dar dacă solicitantul nu e pe GitHub? Majoritatea nu sunt, și e în regulă. Widget-ul continuă să le arate statusul a ce au trimis, inclusiv intrarea lansată și link-ul ei, deci nu au nevoie de nimic în afară de pagina din care au scris. Comentariul de pe issue e pentru oamenii care pot vedea repository-ul.

Funcționează bucla asta pe GitLab sau Bitbucket în loc de GitHub? Widget-ul și changelog-ul, da; comentariul automat de la pasul cinci, deocamdată nu. O echipă pe GitLab sau Bitbucket tot primește fiecare trimitere, tot o înregistrează ca issue, și tot arată solicitantei un status în widget, dar închiderea acelei bucle specifice înapoi pe issue e un pas pe care îl faceți manual până când există acea integrare.

Afirmațiile tehnice din acest articol nu au fost verificate independent. Dacă ceva nu e corect, spune-ne și vom corecta.

Pe changeloop: Documentație pentru dezvoltatori, Exemple de changelog