Bucla de feedback

Modelul Kano: sortează cererile după ce simt clienții

6 min de citit

Modelul Kano sortează funcționalitățile după felul în care reacționează clienții când le au și când le lipsesc, nu după câți oameni le-au cerut. A fost propus de Noriaki Kano în 1984 și așază fiecare funcționalitate în una dintre cinci grupe: obligatorii (must-be), de performanță, atractive (încântătoare), indiferente și inverse. Pentru o echipă cu un morman de cereri de funcționalități, partea utilă e că explică de ce o cerere cu zeci de voturi poate să nu adauge nimic la satisfacție, în timp ce o cerere pentru care nu a votat nimeni poate schimba felul în care vorbesc oamenii despre produs.

CategorieReacția clientului când existăReacția clientului când lipseșteCerere tipică
Obligatorie (must-be)Nimic, e de la sine înțelesNemulțumire puternicăResetarea parolei, exportul datelor
De performanțăSatisfacția crește cu cât e mai multSatisfacția scade cu cât e mai puținViteză, spațiu de stocare, limite
AtractivăÎncântareNimic, nimeni nu o așteptaO automatizare bine gândită
IndiferentăNimicNimicO setare pe care o ating puțini
InversăIritareUșurareUn tur ghidat forțat sau un pas în plus

Care sunt categoriile modelului Kano?

Funcționalitățile obligatorii sunt cele pe care clienții le presupun existente. Nimeni nu le laudă, dar toți observă când se strică. Funcționalitățile de performanță sunt cele la care mai mult înseamnă mai bine, în linie dreaptă, cum ar fi rapoartele mai rapide sau limitele mai mari. Funcționalitățile atractive sunt neașteptate, așa că absența lor nu costă nimic, iar prezența lor aduce entuziasm real. Funcționalitățile indiferente nu mișcă nimic în nicio direcție, iar cele inverse îi fac pe unii clienți mai mulțumiți atunci când sunt eliminate.

Categoria este o proprietate a unei funcționalități pentru un grup de clienți la un anumit moment, de aceea aceeași funcționalitate poate ajunge în grupe diferite pentru segmente diferite.

Cum rulezi un chestionar Kano?

Pune două întrebări despre fiecare funcționalitate. Întrebarea funcțională cere clientului să spună cum s-ar simți dacă produsul ar avea funcționalitatea. Întrebarea disfuncțională îl întreabă cum s-ar simți dacă nu ar avea-o. Ambele folosesc aceleași cinci răspunsuri: Îmi place, Mă aștept să existe, Sunt neutru, Pot trăi cu asta, Nu-mi place.

Combină cele două răspunsuri cu grila standard de evaluare, ca să clasifici părerea fiecărui respondent despre fiecare funcționalitate:

Funcțională \ DisfuncționalăÎmi placeMă așteptNeutruPot trăi cu astaNu-mi place
Îmi placeQAAAO
Mă așteptRIIIM
NeutruRIIIM
Pot trăi cu astaRIIIM
Nu-mi placeRRRRQ

M înseamnă obligatorie (must-be), O înseamnă de performanță (unidimensională), A înseamnă atractivă, I înseamnă indiferentă, R înseamnă inversă, iar Q este un răspuns îndoielnic, care se contrazice singur. Numără literele pe respondenți pentru fiecare funcționalitate și ia-o pe cea mai frecventă drept categorie. Când două categorii sunt apropiate, raportează-le pe amândouă, pentru că o împărțire 40/38 arată că segmentul e divizat, nu că un răspuns a câștigat.

Ce cereri de funcționalități merită într-un chestionar Kano?

Doar cele pe care le-ai lua cu adevărat în calcul și pe care nu le poți ordona din intuiție. Între cinci și cincisprezece funcționalități e o lungime de chestionar rezonabilă, iar fiecare are nevoie de o descriere într-o propoziție pe care clientul o poate vizualiza fără machetă. Alege candidații din backlog-ul urmărit, după ce ai grupat duplicatele, pentru că zece cereri pentru același lucru trebuie să ajungă în chestionar ca o singură funcționalitate. Pasul de grupare este tratat în urmărirea cererilor de funcționalități.

Lasă deoparte remedierile de erori și tot ce e deja promis printr-un contract. Un chestionar nu îți poate spune dacă să repari o cădere a aplicației.

Pe cine ar trebui să chestionezi?

Pe oamenii care folosesc deja produsul, împărțiți pe segmentele care contează pentru tine. Un chestionar trimis întregii liste tinde să producă media mai multor grupuri diferite, iar media ascunde concluzia. Utilizatorii gratuiți și cei plătitori, conturile noi și cele vechi, echipele mici și cele mari așază adesea aceeași funcționalitate în categorii diferite. Ține separat rezultatele fiecărui segment și hotărăște pentru care segment este următoarea lansare.

Folosește ca public de pornire oamenii care au scris cererile și adaugă un eșantion aleatoriu de utilizatori activi, ca să nu răspundă doar minoritatea vocală. Cum formulezi și trimiți solicitarea este explicat în cum ceri feedback clienților.

Cum transformi rezultatele Kano într-o ordine de priorități?

Construiește în această ordine: întâi golurile la funcționalitățile obligatorii, apoi funcționalitățile de performanță la care ești în urma alternativelor cu care te compară clienții, apoi una sau două funcționalități atractive la fiecare lansare, iar pe cele indiferente și inverse la sfârșit sau deloc. Ordinea decurge din ce face fiecare categorie cu satisfacția. Închiderea unui gol la o funcționalitate obligatorie elimină un motiv de plecare, munca pe performanță ridică satisfacția constant, iar o funcționalitate atractivă este locul de unde vine diferențierea.

Kano spune ce fel de valoare aduce o funcționalitate, nu cât costă. Asociază categoria cu o estimare de efort înainte ca funcționalitatea să intre într-un plan. O metodă de scorare, cum este cea din scorarea RICE, se ocupă de partea de cost, iar cele două merg bine împreună: Kano alege lista scurtă, iar RICE o ordonează. Decizia mai largă este descrisă în cum prioritizezi cererile de funcționalități.

Se mută funcționalitățile între categorii în timp?

Da, și este lucrul cel mai util de ținut minte despre model. Funcționalitățile atractive alunecă spre performanță și apoi spre obligatoriu, pe măsură ce concurenții le copiază și clienții se obișnuiesc cu ele. Autentificarea în doi pași a fost cândva o surpriză plăcută și acum este o așteptare pentru software de business. Rezultatul unui chestionar e o fotografie de moment, așa că repetă-l, pentru orice categorie pe care mizezi, după un an sau ori de câte ori un concurent lansează ceva asemănător.

Spune-le clienților când lansezi o funcționalitate încântătoare. O funcționalitate din categoria atractivă încântă doar oamenii care află de ea, așa că anunțul face parte din funcționalitate. Închiderea acestei bucle este tema articolului cum scrii un anunț de funcționalitate nouă.

Care sunt limitele modelului Kano?

Măsoară sentimente declarate, nu comportament, deci poate supraestima lucruri pe care oamenii spun că le vor. Are nevoie de suficienți respondenți pe segment ca să se vadă un tipar, iar câteva zeci reprezintă adesea pragul practic. Evaluează funcționalitățile una câte una și nu spune nimic despre felul în care interacționează între ele. Tratează rezultatul ca pe o dovadă puternică pentru discuția despre roadmap și pune-l lângă datele de utilizare și venituri. Pentru transformarea listei ordonate într-un plan, vezi cum construiești o roadmap de produs.

FAQ

Ce este modelul Kano, pe scurt? Este o metodă care sortează funcționalitățile în grupe după cum se simt clienții când funcționalitatea există și când lipsește. Grupele sunt obligatorii, de performanță, atractive, indiferente și inverse, iar fiecare indică o altă prioritate de construcție.

Câți oameni îți trebuie pentru un chestionar Kano? Nu există un număr fix, dar fiecare segment pe care vrei să-l citești separat are nevoie de suficiente răspunsuri ca să arate o categorie majoritară clară. Câteva zeci pe segment sunt un minim practic frecvent, iar un rezultat împărțit, cu puține răspunsuri, trebuie citit ca nerezolvat.

Este modelul Kano mai bun decât RICE? Răspund la întrebări diferite. Kano clasifică tipul de valoare pe care o aduce o funcționalitate clienților, iar RICE ordonează munca după acoperire, impact, încredere și efort. Multe echipe folosesc Kano pentru lista scurtă și o metodă de scorare pentru a o ordona.

Cât de des ar trebui repetată o analiză Kano? Anual pentru produsele stabile și mai devreme când un concurent lansează o funcționalitate asemănătoare. Funcționalitățile încântătoare devin așteptări în timp, așa că un rezultat vechi te poate îndrepta spre o funcționalitate care nu te mai diferențiază.


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

changeloop
Echipa care construiește un changelog care închide bucla. Utilizatorii cer ceva, echipa ta livrează, cel care a cerut află.