Când o cerere de funcționalitate e de fapt o eroare

“Puteți adăuga o setare care să crească limita de export?” se citește ca o cerere de funcționalitate, iar majoritatea sistemelor de triaj o etichetează așa pe loc. Uneori chiar e. Uneori exportul eșuează la un număr sub limita documentată din cauza unei erori, iar clienta, incapabilă să vadă codul, a inventat cea mai plauzibilă soluție pe care o poate descrie: dați-mi un număr mai mare și poate merge. Ce etichete merită folosite acoperă eticheta de tip care împarte un backlog în cereri de funcționalități și erori; acesta e cazul în care cuvintele înseși ale unei cliente îndreaptă eticheta în direcția greșită, iar costul greșelii e o derivă lentă către un backlog plin de cereri pe care nimeni nu le vrea cu adevărat odată ce te uiți dedesubt.

Cum arată o cerere de funcționalitate care e de fapt o eroare?

Numește o soluție ocolitoare în loc de problemă. O cerere de funcționalitate genuină descrie de obicei un rezultat pe care produsul nu-l suportă deloc: “lăsați-mă să planific asta pentru mai târziu”, “adăugați un mod întunecat”. O eroare clasificată greșit descrie un număr, un prag sau un comportament specific care sună ca o setare lipsă dar e de fapt un simptom: “măriți timeout-ul”, “adăugați o opțiune de reîncercare”, “lăsați-mă să exportez mai multe rânduri odată”. Semnul e că solicitanta propune o implementare, o setare, un comutator, o suprascriere, în loc să descrie un obiectiv, pentru că a încercat deja funcționalitatea așa cum e documentată și n-a făcut ce spune documentația că ar trebui să facă.

De ce contează asta mai mult decât pare?

Pentru că cele două cozi au responsabile, termene și criterii de succes diferite, iar o eroare înregistrată drept cerere de funcționalitate e prioritizată împotriva cererilor de funcționalități, concurând pentru atenție cu lacune reale ale produsului în loc să fie reparată în termenul pe care-l merită o eroare. Cum se urmăresc cererile de funcționalități acoperă de ce amestecarea erorilor și funcționalităților într-o singură coadă lasă plângerile cele mai zgomotoase să treacă înaintea cererilor reale; o cerere de funcționalitate care e pe ascuns o eroare face daunele inverse, rămâne în backlog-ul produsului adunând voturi pentru o “funcționalitate” care ar dispărea de îndată ce eroarea de bază e reparată, ceea ce irosește semnalul de prioritizare pentru oricine citește acel backlog.

Cum se distinge când cuvintele înseși ale clientei indică în direcția greșită?

Întrebați ce se aștepta să se întâmple, nu ce vrea să adăugați. “Exportul s-a blocat la 500 de rânduri și am nevoie de 2.000, puteți crește limita” sună ca o cerere de funcționalitate de creștere a limitei până când întrebarea de urmărire, “500 e limita documentată,” dezvăluie că numărul documentat era 5.000 și exportul eșuează devreme. Această singură întrebare, ce se aștepta față de ce s-a întâmplat, face cea mai mare parte a muncii de sortare, pentru că o cerere de funcționalitate genuină nu are un comportament documentat sub care să cadă; nu e nimic de așteptat pentru că posibilitatea încă nu există.

Ar trebui agentele de suport sau inginerele să decidă asta?

Agentele de suport fac prima trecere, pentru că văd tichetul primele, dar eticheta ar trebui să fie ușor de schimbat și ieftin de greșit, nu o decizie unică ce fixează elementul în coada greșită pentru totdeauna. O a doua verificare ușoară, o inginera care scanează săptămânal etichetele noi de “cerere de funcționalitate” pentru orice miroase a eroare deghizată, prinde pe cele pe care o agentă de suport fără context de cod n-ar fi putut să le recunoască. Nu trebuie să fie formală; e mai degrabă o privire de cinci minute decât un proces de revizuire.

Se schimbă închiderea buclei odată ce e găsită eroarea reală?

Da, și îmbunătățește mesajul pe care-l puteți trimite. Închiderea buclei de feedback a clientului acoperă anunțarea solicitantei când cererea ei e lansată; o eroare reclasificată primește o versiune mai bună a acelui mesaj, pentru că “am găsit și am reparat eroarea din spatele acestui lucru” sună a competență, în timp ce “am construit funcționalitatea pe care ați cerut-o” ar fi fost adevărat doar din întâmplare, pentru că cererea reală de funcționalitate, o limită de export cu adevărat mai mare, poate să nu fie niciodată construită odată ce eroarea dispare și limita originală de 5.000 de rânduri e suficientă.

Ce se întâmplă dacă clasificarea greșită nu e niciodată prinsă?

Backlog-ul se umple cu cereri care par cerere reală și nu sunt, iar deciziile de prioritizare luate împotriva acelui backlog moștenesc distorsiunea. O “funcționalitate” cu patruzeci de voturi ar putea fi de fapt patruzeci de persoane care întâlnesc aceeași eroare, iar construirea cererii literale, o setare pentru a crește o limită care n-a fost niciodată de fapt constrângerea, livrează complexitate care nu repară nimic, în timp ce eroarea de bază continuă să genereze noi “cereri de funcționalități” de la cliente care încă n-au găsit acest fir.

FAQ

Merită adăugat un pas formal pentru a verifica fiecare cerere de funcționalitate față de erori cunoscute? Nu un pas formal, mai degrabă un obicei: oricine triază o cerere nouă de funcționalitate ar trebui să întrebe “comportamentul documentat pretinde deja că face asta” înainte de a aplica eticheta, pentru că doar această întrebare prinde majoritatea clasificărilor greșite fără să adauge supraîncărcare de proces.

Ce se întâmplă dacă clienta insistă că e o cerere de funcționalitate chiar și după ce eroarea e găsită? Explicați ce ați găsit și de ce setarea pe care a propus-o n-ar mai fi necesară odată ce eroarea e reparată. Majoritatea clientelor cer o soluție ocolitoare pentru că au presupus că reparația reală nu era disponibilă, nu pentru că voiau anume acea setare.

Un element reclasificat pierde voturile sau comentariile pe care le-a adunat ca cerere de funcționalitate? Ar trebui să le păstreze, vizibile, pentru că acele voturi sunt dovada care a dus la găsirea erorii în primul rând, iar ascunderea acelei urme face aceeași clasificare greșită mai greu de prins data viitoare, pe un tichet diferit.

Se poate întâmpla și invers, un raport de eroare care e de fapt o cerere de funcționalitate? Mai rar, dar da: “asta e stricat” înseamnă uneori “asta nu face ce am presupus că va face,” ceea ce e o capacitate lipsă, nu un defect. Aceeași întrebare, ce se aștepta față de ce e documentat, sortează și în această direcție.

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