Una dintre cele mai mari provocări cu care se confruntă echipele de dezvoltare de produse este pur și simplu cum să decidă ce produs să construiască. În cazul echipelor care lucrează pornind de la o specificație de produs, în special în dezvoltarea de hardware, inginerilor nu li se permite de obicei să înceapă să lucreze până când aceasta nu este finalizată și aprobată. Și având în vedere că majoritatea termenelor de dezvoltare sunt incredibil de scurte, deseori nu există suficient timp pentru a lua în considerare soluții alternative odată ce apar noi informații.
Un mod de a privi această provocare este prezentat aici. Vă puteți imagina că cercul reprezintă toate modurile posibile în care echipa ar putea construi produsul. Iar acel mic punct albastru este specificația pentru un anumit produs. Această specificație a produsului definește exact asupra cărui produs dezvoltatorii ar trebui să se concentreze și să construiască.
În acest post, voi descrie mai întâi câteva dintre metodele comune utilizate pentru a conveni asupra unei specificații a produsului. Apoi voi explora problemele legate de aceste metode și modul în care acestea pot duce la construirea de produse pornind de la o specificație care nu rezolvă de fapt problemele clientului dumneavoastră.
Ar trebui să spun că perspectiva mea provine din 10 ani de experiență de lucru în industria semiconductoarelor analogice și cu semnale mixte, mai întâi ca inginer de aplicații și mai târziu ca definitor de produse. Acum, sunt consultant aici la Jama.
Cele mai proaste moduri de a crea o specificație de produs:
Întrebați-vă clientul ce vrea să construiți
O modalitate de a începe este să vă întrebați clienții de ce au nevoie. Acest lucru ar putea fi făcut așteptând o cerere de ofertă (RFQ) emisă de client sau, mai puțin formal, prin întâlniri și discuții. În mod obișnuit, ceea ce veți afla prin această abordare este ce soluție sau produs folosesc în prezent și ce ar dori să vadă schimbat în viitorul foarte apropiat. Într-un fel, acționați ca un antreprenor, iar clientul este responsabil pentru toate detaliile specificației.
Datorită faptului că acest scenariu solicită iterația asupra unui produs existent, există o mare probabilitate să ajungeți la o idee foarte specifică pe care cu siguranță o puteți implementa.
Cu toate acestea, există mai multe probleme cu această abordare:
- Ceea ce vă spune clientul dvs. cu privire la strategia de produs probabil că spune și concurenței, iar un obiectiv cheie al proiectului este probabil să facă ceva mai ieftin decât soluția existentă. Vă veți afla într-un război al prețurilor.
- Clientul dvs. este deja setat pe un tip de soluție, pe baza a ceea ce a cumpărat înainte, ceea ce face dificil să sugerați ceva care ar putea răspunde mai bine nevoilor sale.
- Programul este probabil extrem de agresiv, lăsând puține posibilități de a construi ceva nou sau de a permite o inovație adevărată.
- Clientul dvs. s-ar putea să nu fie la curent cu noile tehnologii sau pur și simplu să nu știe de ce are nevoie.
În acest caz, vă bazați pe clientul dvs. pentru a traduce cerințele sale interne într-o specificație pentru dvs., mai degrabă decât să scrieți dvs. cerințele pentru un produs de care piața mai largă are nevoie și pe care îl va cumpăra.
În timp ce dezvoltați produsul, echipa dvs. va trebui în mod inevitabil să facă compromisuri din diverse motive. Singura modalitate de a vă asigura că se face cea mai bună alegere este să revizuiți cu clientul dumneavoastră modificările aduse specificației produsului rezultat. Dacă nu o faceți, atunci riscați să construiți un produs pe care acesta nu îl va accepta. Dar, deoarece echipa de proiectare se va afla sub o presiune extremă pentru a executa un program agresiv, există o mare probabilitate ca aceasta să facă compromisuri pentru produs fără a avea toate informațiile cele mai bune. Acest lucru crește și mai mult riscul de a construi un produs greșit.
Această abordare funcționează în sensul că se livrează un produs. Dacă sunteți în afacerea de a livra componente de bază, atunci acest lucru este în regulă. Dacă sunteți în căutarea unei soluții unice care să apere marja brută, atunci aceasta nu este cea mai bună abordare.
RELATED POST: How to Perform Better Impact Analysis on Upstream and Downstream Relationships
2. Puneți un inginer să scrie întreaga specificație
Un alt scenariu comun este cel în care un inginer, sau un alt membru al echipei care se confruntă cu clientul, are în vedere o soluție pe baza conversațiilor pe care le-a avut cu unul sau câțiva clienți. Echipa se reunește în jurul acestei idei și, cu un impuls intern, cerințele sunt rapid documentate, iar eforturile echipei se îndreaptă rapid către scrierea specificațiilor produsului și dezvoltarea soluției.
După ce o soluție este completă și pregătită pentru a intra pe piață, unele echipe își vor valida ideea cu clienții, dar, deoarece echipa prezintă o soluție – nu explorează o nevoie – discuția tinde să fie în jurul detaliilor din specificațiile produsului. Aceste echipe nu vor avea ocazia să afle dacă soluția rezolvă o problemă.
Tipic, în acest scenariu, cerințele produsului vin direct din capul unei persoane și sunt apoi capturate într-o foaie de specificații lungă, iar restul echipei tranzacționează folosind specificația documentată. Ori de câte ori echipa se confruntă cu un conflict în care trebuie făcut un compromis, individul care a redactat cerințele trebuie să decidă compromisurile corecte în mod independent, cu puține sau deloc informații noi. În plus, dacă acea persoană nu a cercetat și nici nu a validat cerințele, atunci echipa va construi un produs greșit.
De ce aceste abordări nu duc la succes
Ceea ce au în comun ambele abordări anterioare este faptul că accentul se pune pe obținerea unei specificații a produsului finit cât mai repede posibil. Echipele sunt atât de grăbite să înceapă să construiască ceva și să respecte termenul limită al clientului, încât nu se asigură mai întâi că acel ceva este acel ceva potrivit.
În plus, cunoașterea cerințelor există doar la un singur individ din echipă. Acel individ este fie persoana care face interfața cu clientul sponsor, fie este persoana care a venit cu ideea produsului. În oricare dintre cazuri, restul echipei este lipsit de orice context al soluției, de motivul pentru care construiesc acest produs și, prin urmare, nu poate face recomandări.
Rezultatul este că, adesea, produsele sunt omorâte mai târziu decât ar fi trebuit, după ce s-a pierdut mult timp și bani, sau echipele creează produse care nu au succes sau produse „me-too” care concurează în mare parte pe bază de preț. Niciuna dintre acestea nu este bună pentru afaceri.
RELATED POST: 8 Do’s and Don’ts for Writing Requirements
Cele mai bune moduri de a crea o specificație de produs:
Cel mai bun mod de a crea produse pe care clienții dvs. le vor cumpăra este să ieșiți în lume și să vorbiți cu piața dvs. țintă cu mult înainte de a începe să scrieți specificațiile. În primul rând, trebuie să vă articulați enunțul problemei dumneavoastră.
Un enunț al problemei produsului este format din câteva propoziții sau paragrafe care descriu o nevoie a pieței. Ele sunt scrise din perspectiva persoanei care are problema și – acest lucru este critic – nu spun nimic despre cum să rezolve efectiv problema. Scopul acestei etape de explorare este de a transmite o înțelegere a problemei și un sentiment al valorii asociate cu rezolvarea acesteia.
O declarație de problemă este, în general, alcătuită din trei părți:
- Prima este persona, sau o descriere a persoanei care are problema. Este util să descrieți persoana în mare detaliu separat și apoi să faceți referire la o anumită persoană în enunțul problemei pentru a nu repeta aceeași descriere a persoanei.
- În continuare este o descriere a problemei. Cu cât mai multe detalii, cu atât mai bine aici. Vreți să vă asigurați că nevoia este foarte clară. De asemenea, dați problemei un nume. Acest lucru face ca echipele să se poată referi mai ușor la ea în timpul proiectului.
- În final, scrieți o descriere a frecvenței cu care apare problema. Dacă problema se întâmplă rar și are un impact scăzut, atunci rezolvarea ei are o valoare scăzută. Dacă problema se întâmplă frecvent și are un impact ridicat, atunci valoarea rezolvării ei va fi ridicată.
Puteți începe prin a întreba clienții ce probleme au pe care cred că le puteți rezolva, dar trebuie să săpați mai adânc pentru a ajunge la declarațiile de probleme cu adevărat valoroase sau la pepitele de aur. Aceste pepite de aur provin, în general, din dezvoltarea unei înțelegeri profunde a pieței și din punerea laolaltă a informațiilor dintr-o gamă largă de surse.
Dacă faceți acest lucru cu succes, veți ajunge să identificați o problemă pe care o puteți rezolva și pentru care clientul dvs. va plăti.
În timpul procesului, aveți grijă să nu vă loviți de falsuri pozitive sau negative. Faptul că ascultați prea mult oamenii din interiorul companiei dvs. sau doar un număr mic de clienți vă poate determina să validați sau să abandonați în mod fals o problemă. Vorbiți cu cât mai mulți clienți posibil și colectați cât mai multe date.
Să ne întoarcem la diagrama noastră cu toate produsele posibile pe care le putem construi.
De data aceasta am adăugat linii care se intersectează și care reprezintă constrângeri. Dacă ne gândim la enunțurile de problemă ca la liniile care intersectează cercul, atunci un enunț de problemă bun, fundamentat pe înțelegerea pieței, va delimita o zonă din cerc care reprezintă toate soluțiile acceptabile. Orice lucru din această zonă rezolvă problema și ar fi acceptabil pentru client.
Vă veți da seama că dimensiunea acestei zone este mult mai mare decât cercurile anterioare ale cererii de ofertă și ale ideii de produs. Acest lucru se datorează faptului că aceste enunțuri ale problemei și contextului delimitează în mod intenționat soluția cât mai lejer posibil pentru a permite apariția de noi idei.
Ideea este de a oferi echipei de proiectare flexibilitate maximă în crearea celei mai inovatoare soluții posibile în cadrul constrângerilor.
RELATED POST: Lista de verificare: Selectarea unui instrument de gestionare a cerințelor
Cum se ajunge la o declarație finală a problemei?
Iată care sunt recomandările mele:
- Începeți prin a atribui cuiva pentru fiecare proiect responsabilitatea de a fi vocea clientului.
- În continuare, însărcinați această persoană cu identificarea problemelor de piață numai pe baza informațiilor colectate de pe piață.
- Asigurați-vă că aceste probleme de piață sunt documentate și împărtășite într-un loc la care are acces întreaga echipă.
- Scrieți o justificare pentru fiecare declarație de problemă de piață care să explice de ce este o problemă și cât de importantă este rezolvarea ei
- Adaugați o etapă în planul proiectului în care declarațiile de problemă trebuie să fie revizuite și aprobate de echipă împreună cu un studiu de caz.
- În timp ce echipa începe să dezvolte o soluție, reveniți periodic la lista de enunțuri ale problemei pentru a reaminti tuturor care este ținta.
- Pentru fiecare problemă, capturați o listă a caracteristicilor produsului care vor rezolva problema.
- Dacă o problemă nu poate fi rezolvată în totalitate, reanalizați cazul de afaceri pentru a vă asigura că produsul este încă viabil.
De la enunțarea problemei la specificație
Acum că aveți enunțurile problemelor și echipa s-a familiarizat cu ele, începeți să dezvoltați în colaborare o specificație a produsului. Deoarece toți membrii echipei înțeleg problema care se rezolvă, fiecare poate contribui la specificație.
Pentru că ați făcut munca inițială de identificare a problemei pe care o rezolvați, în cadrul constrângerilor identificate, iar echipa dvs. a luat în considerare mai multe modalități de a livra soluția, aveți suficiente informații pentru a scrie specificația produsului.
Liberați specificația produsului în loturi mici
Cea mai bună abordare în acest caz este să eliberați echipei bucăți mici din specificație cât mai devreme posibil pentru a obține feedback rapid. Acest lucru va ajuta la evitarea pierderii de timp pe o cale greșită și va face mult mai ușor pentru echipă să ofere un feedback de înaltă calitate.
Nu sunteți convins? Luați în considerare acest lucru: Ce se întâmplă dacă primiți o foaie de specificații de 200 de pagini pentru a o revizui? Probabil că vă uitați la primele câteva pagini și apoi răsfoiți restul.
Acum, ce se întâmplă dacă primiți un document de o pagină? Probabil că îl examinați în întregime. Două sute de documente de o pagină vor avea ca rezultat un feedback mult mai bun decât un singur document de 200 de pagini.
Referiți-vă la enunțul problemei pentru a vă asigura că sunteți pe drumul cel bun
De asemenea, pe măsură ce dezvoltați specificația, verificați din nou pentru a vă asigura că produsul este încă o soluție valabilă la problemă. Este ușor să te lași prins în compromisul inerent dezvoltării unui produs și să uiți să verifici dacă ești încă pe țintă.
Această abordare gestionează, de asemenea, așteptările părților interesate. Deoarece procesul este controlat, există un cadru și o transparență care împiedică pe oricine să anuleze deciziile. În orice moment al proiectului, veți putea explica exact ce valoare oferă produsul dvs. și de ce trebuie să aibă caracteristicile pe care echipa le-a specificat.
Proiectarea produselor în funcție de nevoile pieței este esențială pentru succes
Recunosc că în unele industrii aceasta este o mare schimbare față de modul în care au fost proiectate și construite produsele. Dar, pe măsură ce piețele devin mai competitive, iar produsele devin din ce în ce mai complexe, simpla livrare a unei alte iterații a ceva ce ați construit înainte nu vă va menține în afaceri pentru mult timp.
Pentru a afla mai multe despre cum să scrieți cerințele astfel încât toate părțile interesate să aibă o înțelegere clară a nevoilor de dezvoltare, descărcați cartea noastră electronică, Best Practices for Writing Requirements.
READ THE EBOOK