Team Ramp Up garantează o viteză crescută a caracteristicilor?
Publicat: 2020-03-28Unul dintre elementele esențiale cheie în timpul creșterii echipelor pentru a crește viteza de lansare este transferul de claritate de la echipele de produse la echipele de sprint.
O execuție ușoară a sprintului este rezultatul contribuțiilor notabile venite atât din partea echipelor de produs, cât și a celor de sprint
Filozofia „first-time-right (FTR)” ajută toți membrii echipei să se alinieze la un obiectiv comun
Când startup-urile trec de la stadiul incipient la cel de creștere, prioritățile lor se schimbă într-o măsură semnificativă. Printre toate celelalte, viteza caracteristicilor iese în evidență ca o prioritate și joacă un rol crucial în urmărirea lor de creștere.
Fondatorul unui startup finanțat din seed cu care lucram, care și-a ridicat recent seria A rundă, mi-a cerut să dublez echipa de ingineri pentru a lansa noi funcționalități în șase luni. Cu toate acestea, acesta este singurul factor relevant în reducerea timpului de ciclu? Pentru a răspunde, am decis să abordez aspectele ignorate din spatele acestei „concepții greșite” predominante.
Deși capacitatea resurselor este unul dintre factorii critici care determină lansările frecvente în producție, acest lucru singur nu poate garanta durata de ciclu redusă. În timp ce construiam produse pentru mai mult de 16 startup-uri, am asistat de mai multe ori la tranziția de la stadiul incipient la cel de creștere. Din această experiență, iată câțiva factori cruciali pe care îi împărtășesc pentru ca fondatorii de startup-uri să ia în considerare.
Transmite claritatea: esențialul de sus în jos
Unul dintre elementele esențiale la creșterea echipelor pentru a crește viteza de lansare este transferul de claritate de la echipele de produse la echipele de sprint. Când un sprint începe cu ambiguitate sau nu are suficiente povești pentru a începe, rata de livrare a sprintului este afectată negativ. Poveștile vag definite sau includerea sarcinilor la mijlocul sprintului încetinesc ritmul, ca urmare echipele de sprint nu reușesc să ofere așa cum a fost planificat.
O execuție ușoară a sprintului este rezultatul contribuțiilor notabile venite atât din partea echipelor de produs, cât și a celor de sprint. Echipa de produs își poate juca rolul prin pregătirea și împărtășirea foii de parcurs echipei de sprint cel puțin pentru trimestrul, astfel încât echipa să își poată planifica rezultatele în consecință.
Pe de altă parte, echipa de sprint ar trebui să continue să împingă echipa de produse pentru a obține un stoc de produse și să-l îngrijească săptămânal/săptămânal pentru a asigura o livrare concentrată.
Automatizați pentru a lansa „Fără erori”
„Eficiența înseamnă a face lucrurile corect; eficiența înseamnă a face lucrurile corect.” – Peter Drucker
Când te gândești la automatizare, este un exemplu al acestei din urmă categorii. În momentul în care dezvoltarea caracteristicilor crește, este foarte probabil ca producția să se întrerupă dacă nu există procesele potrivite. Dacă produsul nu este suficient de stabil pentru a face față noilor dezvoltări de funcții, echipa dvs. petrece mai mult timp rezolvând problemele decât construind noi funcții. În consecință, viteza dvs. de inginerie scade.
Aici intervine CI/CD (integrare continuă și implementare continuă). Aici, acoperirea exhaustivă a testelor de unitate, integrare și automatizare asigură că orice este livrat nu distruge sistemul.
Recomandat pentru tine:
Nu doar construi mai mult, altfel spargi mai mult
Reprelucrarea este un mare ucigaș al productivității și ar putea fi rezultatul diverșilor factori, cum ar fi poveștile vag definite, lipsa testării dezvoltatorilor, lipsa acoperirii testelor și așa mai departe. Relucrarea poate consuma productivitate, deoarece ar consuma timpul și eforturile inginerilor QA în testare și regres, dezvoltatorilor în depanare și managerilor de lansare în relansare.
Încetinirea un pic vă poate ajuta echipa să livreze mai rapid și să adauge valoare, deoarece viteza efectivă este întotdeauna foarte plină de satisfacții decât viteza.
Filosofia „first-time-right (FTR)” îi ajută pe toți membrii echipei să se alinieze la un obiectiv comun - furnizarea de cod robust și stabil chiar de prima dată. Este întotdeauna sănătos să petreci ceva timp suplimentar pentru a determina calitatea codului, mai degrabă decât să te grăbești și apoi să te blochezi cu reluarea.
Unele dintre modalitățile încercate și testate de a îmbunătăți raportul FTR sunt îngrijirea regulată a restanțelor, o reiterare a poveștilor, demonstrații regulate pentru managerul de produs. În loc să doar adune cerințe, echipa de sprint ar trebui să se concentreze mai mult pe elucidarea acestora pentru a îmbunătăți raportul FTR.
Structurați-vă echipa pentru sprinturi paralele
Când startup-ul dvs. are o echipă mică de produse, toată lumea lucrează în principal la una sau două funcții în același timp (aplicabil în general pentru o echipă de 4-6 membri). Cu toate acestea, pe măsură ce crește așteptările de a oferi mai multe funcții, este foarte recomandat să formați mai multe sub-echipe care au zone de focalizare distincte. În acest fel, fiecare sub-echipă poate să-și alerge sprintul și să-și definească foaia de parcurs.
În comparație cu o echipă mare, echipele mai mici născute dintr-un cadru de „separare logică” sunt mai eficiente și dau rezultate mai bune. Echipele individuale pentru microservicii, diferite linii de produse și diverse componente se numără printre câteva exemple ale abordării „separarii logică”.
În timpul restructurării, este întotdeauna esențial să includeți cel puțin un membru din echipa de bază anterioară în fiecare dintre aceste sub-echipe pentru a menține ADN-ul. Deși coordonarea între echipe pentru livrări implică un cost suplimentar suplimentar, acesta este un compromis justificat.
Urmăriți utilizarea funcției împreună cu viteza
Experiența utilizatorului este cea mai importantă măsură pentru a măsura succesul unei noi versiuni de funcții. Pe măsură ce începeți să oferiți mai multe funcții cu viteză, experiența utilizatorului ține adesea un ban în spate. Când produsul dvs. are caracteristici limitate, interacțiunea utilizatorului continuă să fie o curbă neîntreruptă.
Cu toate acestea, atunci când începeți să lansați noi funcții, există șanse mari ca utilizatorii să fie copleșiți și ca experiența lor să fie afectată.
Pentru a obține o mai bună adoptare a utilizatorilor, urmărirea implicării utilizatorilor împreună cu viteza caracteristicilor continuă să fie cea mai bună cale de urmat. În timp ce cercetarea exhaustivă a utilizatorilor este o modalitate dovedită, altele semnificative sunt lansate inițial pentru utilizatorii selectați prin intermediul semnalizatoarelor de caracteristici, testării AB și urmăririi călătoriei utilizatorului (prin amplitudine sau instrumente de analiză similare) după fiecare nouă lansare.
Nu vă pierdeți membrii de bază
Acesta ar putea fi un aspect foarte frecvent ignorat, dar rămâne ferm ca unul foarte crucial. Echipele mici nu au neapărat nevoie de procese și au o structură agilă, iar vocea tuturor este auzită. Când aceste echipe trec într-o stare în care procesele sunt configurate și se adaugă noi membri de inginerie și funcționali, managementul sănătos este singura modalitate de a evita haosul.
Pe măsură ce echipa dvs. de ingineri se extinde cu succes, o echipă de produse bine capabilă este esențială pentru a alimenta echipa de ingineri în mod continuu. O schimbare devine inevitabilă atunci când membrii echipei nu au o muncă semnificativă, dar niciun startup nu ar dori vreodată să-și piardă membrii de bază. În acest caz, managementul superior deține cheia pentru a asigura relații bune cu oamenii și pentru a înțelege bine dinamica.
Învățăturile pe care le-am împărtășit aici provin din experiența cu mai multe startup-uri de-a lungul anilor. Mă aștept să fie util fondatorilor de startup-uri, care au deja multe în farfurie, într-un mod în care să nu ajungă să reinventeze roata.