Cum urmărești cererile de funcționalități fără să le pierzi

Urmărirea cererilor de funcționalități eșuează aproape mereu într-unul din două moduri. Fie cererile nu au unde să ajungă, deci trăiesc în inbox-uri și fire de Slack unde sunt uitate una câte una, fie au un loc unde ajung pe care nimeni nu îl mai revizitează, deci sunt uitate toate odată. Un sistem funcțional trebuie să reziste la ambele eșecuri: are nevoie de un singur loc unde ajunge fiecare cerere, și de un motiv să deschizi din nou acel loc luna viitoare.

De unde vin de fapt cererile de funcționalități?

Din mai multe canale decât iau în calcul majoritatea sistemelor de urmărire. Un tichet de suport care include un “ar fi bine dacă”. Un comentariu pe un roadmap public. Un apel de vânzări în care o clientă potențială numește exact lucrul care blochează contractul. Un widget în produs. Fiecare canal are propria responsabilă și propriile unelte, și tocmai de aceea cererile se dispersează: coada de tichete de suport și backlog-ul echipei de produs sunt rareori același sistem, iar o cerere care ajunge doar la unul dintre ele, în practică, a ajuns doar la un departament.

Un singur formular de intake pentru fiecare canal nu funcționează, pentru că nimeni nu-l adoptă. Ce funcționează e o destinație spre care se scurge fiecare canal, chiar dacă rutarea înseamnă la început cinci minute pe zi de copiat și lipit, până devine automatizată.

Ce anume strică urmărirea cererilor de funcționalități?

Aproape mereu două lucruri. Primul e o destinație lipsă: cererile primesc răspuns în canalul în care au ajuns și nu sunt înregistrate durabil nicăieri, așa că aceeași cerere de la trei clienți diferiți pare trei răspunsuri izolate și nelegate, nu un singur semnal. Al doilea, mai frecvent, e o destinație care se umple și nu mai e citită. Un fișier de calcul cu 400 de rânduri nefiltrate nu mai e un sistem de urmărire; e o arhivă care se întâmplă să fie editabilă.

Al doilea eșec e mai periculos, pentru că pare că urmărirea funcționează. Cererile sunt înregistrate. Nimic nu pare stricat până când cineva întreabă “câți oameni au cerut X” și răspunsul onest e “ar trebui să citim toate cele 400 de rânduri ca să știm”.

Ce ar trebui să înregistreze de fapt o cerere de funcționalitate?

Suficient cât să răspundă mai târziu la trei întrebări fără să recitești mesajul original: ce s-a cerut, dacă se poate chiar cu cuvintele celei care a cerut; cine a cerut, și cum să fie contactată dacă răspunsul ajunge să fie “am construit-o”; și ce ar trebui știut ca să vezi dacă e o cerere comună sau un caz izolat. Un citat exact contează mai mult decât o parafrază, pentru că o parafrază scrisă de oricine a triat cererea poartă deja propria interpretare, și tocmai aceea e ceea ce o a doua persoană nu mai poate verifica șase luni mai târziu.

Ce etichete merită folosite?

Două, și răspund la întrebări diferite. O etichetă de tip separă o cerere de funcționalitate de un raport de eroare, pentru că amândouă au nevoie de responsabile și termene diferite, iar amestecarea lor într-o singură coadă lasă plângerile cele mai zgomotoase să treacă înaintea cererilor. O etichetă de prioritate, păstrată la un set mic precum low, medium și high, separă “blochează pe cineva să folosească produsul” de “ar fi frumos”, pentru că amândouă merită timpi de răspuns foarte diferiți și niciuna nu ar trebui să preia ritmul celeilalte. Punerea corectă a etichetei de tip presupune că cererea e ceea ce pretinde a fi; când o cerere de funcționalitate e de fapt o eroare acoperă cazul în care cuvintele înseși ale unei cliente îndreaptă acea etichetă în direcția greșită.

Triajul automatizat poate aplica ambele în momentul în care ajunge cererea. La changeloop, o trimitere prin widget primește eticheta feature-request sau bug și o etichetă priority:low|medium|high în același pas, plus un tag from-widget ca sursa să fie vizibilă fără să deschizi elementul. E suficient ca să filtrezi backlog-ul într-un minut în loc de o după-amiază: arată-mi fiecare cerere de funcționalitate cu prioritate mare venită prin widget luna asta.

O a treia etichetă merită adăugată odată ce există un roadmap public: un status pe care cea care a cerut îl poate verifica singură. Roadmap public acoperă integral statusurile planned, building și shipped; pe scurt, această etichetă transformă o coadă privată în ceva ce poate fi consultat de cea care a cerut fără să mai întrebe o dată.

Cum se decide ce se construiește în continuare?

Grupează întâi, numără apoi. Zece cereri formulate diferit pentru aceeași capacitate de bază se citesc ca zece rânduri împrăștiate într-un fișier de calcul, și ca un semnal puternic odată grupate, iar acea grupare e de obicei pasul lipsă, nu numărarea. Un număr brut fără grupare tinde să recompenseze funcționalitatea cu numele cel mai atrăgător, nu pe cea cu cea mai mare cerere reală în spate.

Ponderează după cine cere, nu doar câți cer. O cerere de la un cont aproape de reînnoire poartă o urgență diferită de aceeași cerere de la o înregistrare de probă, iar un sistem de urmărire care aruncă acest context în favoarea unui număr sec optimizează după cifra cea mai ușor de calculat, nu cea mai utilă.

Fiecare decizie de aici produce și cereri care pierd, iar acelea merită și ele un răspuns; cum refuzi o cerere de funcționalitate acoperă ce spui celor a căror cerere nu a trecut. Gruparea și ponderarea sunt doar jumătate din “ce construim mai departe”; prioritizarea cererilor de funcționalități acoperă cadrele reale, RICE, ponderarea după venit și numerele brute, și unde cedează fiecare.

Cum se închide bucla odată ce ceva e lansat?

Acesta e pasul pe care sistemele de urmărire îl sar cel mai des, și cel pe care cei care au cerut chiar îl observă. Închiderea buclei de feedback cu clientul acoperă mecanica integral; ce se potrivește aici e că închiderea buclei funcționează doar dacă cererea originală a rămas legată de cine a făcut-o. Un șablon de cerere de funcționalitate construit dintr-un issue GitHub, cu identitatea celei care a cerut legată de issue în loc de îngropată într-un comentariu, e ceea ce face posibilă o notificare automată de “lansat” în loc de una pe care cineva trebuie să-și amintească s-o trimită. Șablon de cerere de funcționalitate arată șablonul concret și la ce servește fiecare câmp.

FAQ

Ce instrument ar trebui folosit pentru urmărirea cererilor de funcționalități? Ce verifică echipa deja zilnic bate orice instrument dedicat pe care nimeni nu îl deschide. Un tracker de issues GitHub funcționează bine dacă ingineria trăiește deja acolo; un panou ușor funcționează bine dacă produsul trăiește acolo. Instrumentul contează mai puțin decât dacă e redeschis.

Cum previi duplicarea cererilor de funcționalități? Grupează după capacitatea de bază înainte de a tria după formulare. O căutare printre cererile existente înainte de a crea una nouă prinde majoritatea duplicatelor; o trecere lunară de grupare prinde restul. Combinarea duplicatelor fără a pierde vocea originală acoperă ce să faceți cu formularea odată ce gruparea în sine e gata, ca să nu îngusteze combinarea în tăcere cererea la orice a cerut trimiterea care a sosit prima.

Ar trebui fiecare cerere de funcționalitate să primească un răspuns? Fiecare ar trebui să primească o confirmare, chiar și scurtă, dar nu fiecare are nevoie de o decizie imediată. Un status vizibil, cum ar fi o etichetă de roadmap pe care cea care a cerut o poate verifica singură, înlocuiește majoritatea răspunsurilor individuale pe care o echipă ar trebui altfel să le dea.

Care e diferența dintre urmărirea cererilor și un roadmap public? Urmărirea e înregistrarea internă a fiecărei cereri, inclusiv a celor care nu vor fi lansate niciodată. Un roadmap public e subsetul la care o echipă se angajează public, cu un status pe care cea care a cerut îl poate vedea fără să mai întrebe o dată.

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, Comparație instrumente changelog