Dezvoltare condusă de misiune

Pe măsură ce companiile cresc, dezvoltarea de produse Agile la scară devine mai dificilă. Potrivit a 52% dintre respondenții din cel de-al 13-lea Raport privind starea Agile, diferențele dintre cultura organizațională și valorile Agile sunt principalul dezavantaj în munca lor.

Liderii organizaționali sunt capabili să folosească cultura Agile pentru a îmbunătăți dezvoltarea produselor. O cultură Agile robustă implică autonomie de echipă în abordarea problemelor complexe, lucru strâns cu clienții și viziune și strategie pe termen lung.

Aceste valori abstracte sunt dificil de evaluat și implicat. Într-o organizație, implementarea unei strategii eficiente pentru a le valorifica devine o muncă netrivială. Abordarea Mission Driven Development (MDD) a luat naștere de la startup-uri la mijlocul stadiului ca o alternativă pentru a dezvolta o astfel de cultură.

Scalare provocări

La scalare pot apărea mai multe modele de încetinire. Motivația echipei poate scădea în cazul proiectelor care au un final neclar. Managerii de produs se pot simți pierduți în întâlnirile operaționale și, astfel, pierd timp pentru a proiecta trasee strategice ale produselor. Implementarea de noi funcții și produse poate încetini pe măsură ce sistemele devin din ce în ce mai complexe.

Aceste bariere ar trebui abordate dintr-o perspectivă culturală și practică. Depășirea lor implică renunțarea la control, creșterea autonomiei echipei, implementarea transparenței radicale și stabilirea unui cadru eficient de dezvoltare a produselor pentru a genera rezultate.

Provocări ale scalării cadrelor tradiționale Agile

Când scalați Agile, nivelurile de management și de echipă trebuie să fie sincronizate. Nivelul de management este responsabil pentru dezvoltarea strategiei companiei, crearea și comunicarea viziunii despre produs, executarea deciziilor privind personalul și promovarea dezvoltării echipei. Nivelul de echipă îndeplinește sarcinile necesare pentru a traduce eficient această viziune și strategie în produse și caracteristici valoroase.

Cadrele Agile tradiționale (XP, Scrum și Kanban) sunt optimizate pentru a funcționa la nivel de echipă, lăsând relațiile de management în principal neabordate. Un nou val de cadre Agile scalate a evoluat pentru a umple acest gol, adică SAFe, LeSS, Scrum of Scrums, Nexus, DAD etc. Cu toate acestea, aceste abordări necesită multă planificare pentru implementare și efort pentru a le gestiona și menține.

O abordare ușoară, cadrul de dezvoltare determinată de misiune oferă suficiente linii directoare pentru a implementa o structură robustă în jurul dezvoltării la scară și valorificarea valorilor Agile.

Elementele de bază ale dezvoltării bazate pe misiune

Misiuni

Punctul de plecare este Mission Discovery. O misiune de afaceri necesită timp și efort și ar trebui să identifice o problemă latentă, un spațiu de soluții și rezultatul dorit de afaceri. Atunci când este definită cu precizie, o misiune stimulează motivația, încurajează colaborarea și promovează cercetarea pe spații de design mai largi.

Echipe

Actorii responsabili pentru succesul fiecărei misiuni sunt echipele. În colaborare cu managerii de produs, echipe mici de 2-4 persoane desfășoară activitățile necesare pentru a oferi soluții care se potrivesc scopului misiunii și restricțiilor de timp.

Ciclu de 6 săptămâni

Caseta de timp de 6 săptămâni permite tuturor echipelor să urmeze aceeași cronologie pentru planificarea de bază, oferind totodată suficient timp pentru a oferi un rezultat semnificativ.

Perioada tampon

Cadrul MDD include de obicei o perioadă tampon de una sau două săptămâni pentru integrările și implementările finale, formarea și dezvoltarea competențelor, activitățile de inovare și planificarea ciclului următor, printre altele.

Importanța ciclului de 6 săptămâni

În timp ce perioada de șase săptămâni poate părea mult pentru unii practicieni Agile, conține câteva beneficii importante.

Echipele care lucrează în cicluri scurte tind să-și piardă implicarea față de viziunea produsului, deoarece simt că bifează o „listă de rufe” de remedieri, erori și caracteristici mici. Acest lucru amenință autonomia echipelor de a explora și alege cea mai bună modalitate de a furniza soluții.

Pe măsură ce ciclurile merg mai lungi, precizia estimării produselor scade. Ca urmare, necesită eforturi mari de planificare din partea echipelor de produse.

Șase săptămâni au fost numite „Blocurile de aur” ale intervalelor de timp ale produselor, oferind suficient timp pentru a oferi un produs minim viabil prin gândire inovatoare, prototipare rapidă și livrare continuă.

Ciclul de 6 săptămâni îmbunătățește și mai mult angajamentul viziunii echipei prin valorificarea autonomiei. Micromanagementul nu este necesar atâta timp cât misiunile sunt clar precizate și ciclurile sunt suficient de scurte pentru ca echipele să se concentreze doar pe rezultatele dorite.

În cele din urmă, managerii de produs se pot angaja în activități de planificare la fiecare șase săptămâni, menținând suficientă predictibilitate pentru ca echipele să poată urmări misiunea. Ca rezultat, mai mult timp se poate concentra asupra dimensiunilor strategice și exploratorii ale dezvoltării produsului.

Implementarea dezvoltării bazate pe misiune

Să luăm, de exemplu, un startup de mijloc care are un produs B2B care oferă optimizare a prețurilor de rețea care crește veniturile clienților prin utilizarea aplicațiilor de inteligență artificială. Compania a semnat recent o nouă rundă de finanțare, cu scopul de a se consolida ca actor relevant din industrie și de a crește cota de piață cu 300%.

În acest scenariu, există mai multe provocări de dezvoltare a produsului:

• Cum poate fi obținut feedback de la clienții actuali și potențiali pentru a valida ipoteza valorii în așteptare?
• Ce caracteristici ar trebui să fie construite sau eliminate de pe platformă pentru o experiență de utilizator convingătoare?
• Cum poate fi configurată structura de management pentru a gestiona scalarea și a valorifica valorile culturale pentru a accelera creșterea?

În final, pentru a evita cadrele complexe, compania decide să aplice cadrul de dezvoltare determinată de misiune. În dezvoltarea bazată pe misiune, detaliile „ultimul milă” sunt definite de fiecare organizație. Principalele elemente care trebuie definite sunt:

• Descoperirea misiunii
• Structura misiunii
• Adunarea echipei
• Inspectie si adaptare
• Iterație tampon
• Planificarea capacitatii

Descoperirea misiunii

Punctul de plecare este Mission Discovery. Tim Herbig descrie descoperirea ca fiind procesul iterativ de reducere a incertitudinii în jurul unei probleme sau idei pentru a se asigura că produsul potrivit este construit pentru publicul potrivit. Înainte ca orice misiune să fie angajată într-un ciclu de iterație, aceasta ar trebui să fie validată cât mai complet posibil.

Procesul de descoperire a misiunii este condus de echipe special alocate. Echipa de descoperire este condusă de managerul de produs și este formată din cercetători de produse, analiști de afaceri și designeri. Atunci când există mai mulți manageri de produs, aceștia raportează către Chief Product Officer (CPO), care asigură o viziune comună asupra produselor, potrivirea produselor și strategia globală a companiei și livrarea la timp.

Punctul de plecare recomandat pentru descoperirea misiunii sunt provocările, problemele sau oportunitățile. Pornirea de la o provocare, de exemplu, ajută echipa să exploreze în mai multe spații de design, lărgind în final posibilitățile de soluție.

Validarea misiunii implică mai multe activități care ajută compania să înțeleagă mai bine nevoile clienților:

1. Efectuarea cercetărilor de piață și analizei concurenței
2. Înțelegerea spațiului problemei în care este definită misiunea
3. Proiectarea schițelor și prototipurilor de joasă fidelitate
4. Definirea unui domeniu clar al misiunii
5. Colectarea feedback-ului și validarea clienților

Aceste activități ajută misiunea să fie un ghid solid pentru echipa de dezvoltare și să garanteze că va fi creată valoare pentru utilizatori.

Ca urmare, unele misiuni sunt validate pentru a intra în Backlog-ul Misiunii, care evoluează continuu cu activități de descoperire și colectare de feedback.

În exemplu, să luăm această provocare: Ce caracteristici ar trebui să fie construite de pe platformă pentru a produce o experiență de utilizator convingătoare? Doar o singură echipă de descoperire, condusă de managerul de produs, ar fi adecvată pentru a face față acestei provocări.

Să presupunem că în prezent, platforma companiei exemplu preia datele brute ale clientului și returnează o rețea optimizată de prețuri pe fișierele de date procesate. Cu toate acestea, platforma UX nu a fost optimizată pentru o experiență captivantă. Scopul în acest moment este de a determina dacă valoarea clientului va proveni din îmbunătățirea UX, dezvoltarea de noi caracteristici sau îmbunătățirea serviciilor platformei.

După cercetarea inițială a pieței, decizia este de a dezvolta noi caracteristici. Funcțiile candidate pentru platformă sunt:

• Repreciere ultra-rapidă
• Interfață rapidă și receptivă
• Reguli inteligente și avansate de repreciere
• Reprețuri și istoric de vânzări

În scop de descoperire, compania decide să adopte o abordare de design sprint: un proces de cinci zile pentru a răspunde întrebărilor critice de afaceri prin proiectare, prototipare și testare a ideilor cu utilizatorii. Procesul de descoperire este rulat pentru fiecare funcție candidată pentru a vedea care va crea mai multă valoare pentru clienții actuali și potențiali. Caracteristica de top selectată pentru dezvoltare sunt regulile inteligente și avansate de repricing.

Structura misiunii

Atingerea unei definiții solide a misiunii nu este o sarcină banală. Trebuie să descrie o provocare clară de afaceri și să stabilească limite pentru rezultatul acesteia, oferind în același timp suficient spațiu pentru ca echipele să ajungă la o soluție inovatoare și eficientă. O misiune clară, precisă:

• Afirmă în mod clar o provocare de afaceri, identificând și delimitând spațiul problemei.
• Sintetizează toate informațiile și perspectivele descoperite în fazele anterioare.
• Legături către un rezultat de afaceri dorit.
• Este orientat către rezultate, indicând clar imaginea succesului misiunii.
• Este realist și realizabil în cadrul oportunității unui ciclu de 6 săptămâni.
• Este suficient de îngustă pentru a garanta focalizarea și suficient de largă pentru a fi departe de detalii.

În exemplu, după o săptămână de descoperire, informațiile și feedback-ul utilizatorilor au fost colectate și sintetizate.

Utilizator țintă: analiști de prețuri pentru clienți.

Spațiu cu probleme: utilizatorii doresc să poată stabili și gestiona reguli inteligente și avansate pentru stabilirea prețurilor, astfel încât să poată ajusta automat prețul în anumite condiții.

Condițiile cele mai valoroase pentru reguli sunt prețul concurenței, urgența expedierii, totalul comenzii, inventarul disponibil și reducerea pentru clienții premium.

Perspective: regulile trebuie aplicate în priorități personalizate și pot fi modificate, dacă este necesar.

Analiștii ar dori să vadă cu ușurință ce reguli se aplică la anumite momente pentru un anumit produs.

Rezultatul de afaceri dorit: Creșteți implicarea utilizatorilor în platformă cu 25%, măsurat prin timpul petrecut pe platformă.

Adunarea echipei

Procesul de formare a echipei se face ad-hoc pentru fiecare ciclu de dezvoltare. Autonomia echipei și principiile de auto-organizare rămân centrale. Adunarea echipei este ghidată de o combinație de factori, variind de la complexitatea misiunii, abilitățile de dezvoltator și proiectant, interese și chimia echipei.

Procesul de formare a echipei este facilitat de antrenorii Agile. Înainte de orice decizie, fiecare persoană este întrebată ce tip de muncă ar dori să facă în următoarele șase săptămâni. Apoi, pe baza experienței, cunoștințelor și aptitudinilor, echipele sunt construite asigurându-se că au cunoștințele și abilitățile necesare pentru a aborda cu succes misiunea.

Antrenorii agili lucrează cu mai multe echipe de-a lungul ciclului de dezvoltare, ajutându-i să ridice impedimente și dependențe. Când există mai mulți antrenori Agile, aceștia raportează șefului Agile, care este responsabil pentru asamblarea echipei, îmbunătățirea continuă și livrarea produselor Agile.

Dimensiunea recomandată a echipei este de 2-4 persoane: de obicei, un designer și unul sau doi dezvoltatori, în funcție de complexitatea misiunii. Se consideră că un inginer QA ajută una sau mai multe echipe în atingerea standardelor de calitate dorite.

Echipele sunt adesea amestecate după fiecare ciclu, astfel încât toată lumea poate coopera cu oameni diferiți, poate răspândi cunoștințe și poate lucra la diferite dimensiuni ale produsului, deși o echipă de înaltă performanță poate lucra împreună pentru câteva cicluri.

Echipa specială din exemplu ar trebui să ia în considerare persoanele cu design UI, procesare și capabilități de vizualizare a datelor.

Inspectarea și adaptarea în cadrul ciclului

Transparența, inspecția și adaptarea ar trebui încurajate în mod continuu de către antrenorii Agile prin practici Agile standard.

Scurte întâlniri săptămânale sunt organizate pentru a organiza munca și pentru a facilita ridicarea impedimentelor și dependențelor. Îngrijirea se face, dacă este necesar, pentru a se asigura că echipele înțeleg pe deplin misiunea și poveștile utilizatorilor. Scurte retrospective sunt efectuate la sfârșitul fiecărei săptămâni pentru a identifica și implementa modificări și îmbunătățiri.

Practicile de livrare continuă trebuie menținute pe tot parcursul ciclului. Scopul misiunii ar putea fi atins mai devreme, deoarece intervalul de timp de 6 săptămâni este o abordare bazată pe cadență pentru a stabili reguli de bază, contribuind în același timp la realizarea predictibilității echipei.

O bună practică pentru a spori transparența este o demonstrație la sfârșitul celei de-a patra săptămâni, bazată pe o etapă convenită între echipe și managerii de produs. Scopul acestor demonstrații este adaptarea, reducerea sau creșterea domeniului de aplicare, după cum este necesar.

Pentru misiunea de exemplu, un plan de lansare a fost convenit între echipă și managerul de produs în patru versiuni diferite:

1. Lansarea 1:
   • Noua interfață de utilizare a regulilor
   • Regulile de preț ale concurenței
2. Lansarea 2:
   • Regula de urgență a expedierii
   • Regulă totală de comandă
   • Reguli priorități
3. Lansarea 3:
   • Regulă de inventar disponibil
   • Regula de aplicare a vizualizării
4. Lansarea 4:
   • Reducere pentru clienții premium

Versiunea 3 este acceptată ca demo pentru a patra săptămână. Deoarece lansările au fost efectuate pe tot parcursul ciclului de dezvoltare, rezultatul dorit de afaceri (în acest caz, implicarea utilizatorilor) ar trebui urmărit din momentul în care începe ciclul de dezvoltare. Grafic, progresul ar fi de așteptat după cum urmează:

Perioada tampon

A lua una sau două săptămâni ca perioadă tampon este o practică replicată prin implementările de dezvoltare determinată de misiune, precum și prin alte abordări de scalare, cum ar fi SAFe.

În SAFe, în fiecare ciclu de dezvoltare se realizează o inovație și planificare. Acesta servește ca un comutator de context, permițând procese și activități de explorare și inovare, de obicei lăsate afară de alte cadre axate pe livrare. Exemple de activități implementate în această săptămână tampon:

• Integrarea finală a soluției . Când implementați aproape de sfârșitul ciclului de 6 săptămâni, este probabil ca integrarea, verificarea, documentarea și validarea să rămână în așteptare. Timpul dedicat ajută la asigurarea unei integrări eficiente și fără probleme a noilor soluții în produsele existente.
• Planificarea și prioritizarea misiunii . Misiunile sunt rafinate, clasificate în loturi mici sau mari și prioritizate pentru următorul ciclu de dezvoltare. Atunci când prioritizează misiunile, unele companii implementează zile de prezentare în care misiunile de top sunt prezentate companiei și apoi, într-un mod colaborativ, angajate pentru următorul ciclu de dezvoltare.
• Hackathon-uri . Hackaton-urile au câștigat o popularitate din ce în ce mai mare în rândul startup-urilor și companiilor datorită capacității lor de a stimula inovația, de a crea comunitate și de a construi noi cunoștințe și abilități într-un mod distractiv. Rezultatele sunt prezentate altora și devin candidați pentru Backlog-ul Misiunii.
• Dezvoltare de prototipuri experimentale sau proiecte secundare . Este o practică obișnuită să se acorde inginerilor și proiectanților timp să lucreze la orice decid, atâta timp cât ei arată munca efectuată la sfârșitul timpului tampon.
• Lucrări de inginerie . Lucrări de inginerie pură, cum ar fi dezvoltarea infrastructurii, automatizarea testelor, reducerea datoriilor tehnice și migrarea sistemelor sunt de obicei efectuate.
• Dezvoltarea de noi abilități și cunoștințe . Ritmul rapid al evoluției cunoștințelor îi obligă pe dezvoltatori să rămână la curent cu tendințele globale. Timpul tampon este potrivit pentru a organiza cursuri la fața locului, comunități de practică și ateliere de tehnologie, printre altele.

Perioadele tampon ar trebui să se bazeze pe lacunele de cunoștințe identificate, obiectivele de inovare și nevoile pentru următorul ciclu. De exemplu, o perioadă tampon de o săptămână ar putea arăta astfel:

Planificarea capacitatii

Când decideți angajamentul misiunii pentru următorul ciclu de dezvoltare, o practică obișnuită, conform co-fondatorului Basecamp Jason Fried, este de a identifica mai întâi loturi mici sau mari. Loturile mari se referă la caracteristici sau funcționalități mari ale produsului, în timp ce loturile mici se referă la iterații sau sarcini mai mici. În exemplul dat, misiunea selectată pentru o nouă caracteristică ar putea fi considerată un lot mare.

Recomandarea aici este simplă: aveți întotdeauna un amestec de loturi mici și mari. Loturile mici sunt misiuni care se estimează că vor dura 3-4 săptămâni, iar loturile mari ar putea dura șase săptămâni sau mai mult.

Dacă o echipă cu loturi mici și-a îndeplinit misiunea până în săptămâna 3 sau 4, demonstrația convenită este oportunitatea de a evalua dacă echipa ar trebui să continue să lucreze la îmbunătățirea soluției implementate, să ajute o altă echipă, să ia o nouă misiune cu loturi mici sau să înceapă munca neplanificata.

Un amestec bun de loturi mari și mici împiedică oamenii să lucreze la capacitate de 100%, permițându-le astfel să manevreze și să se adapteze în cazul unei lucrări neplanificate. Echipele cu loturi mari se concentrează cât mai mult posibil în timpul ciclului, în timp ce echipele cu loturi mici se pot ocupa de sarcini ad-hoc care apar din munca neașteptată.

Combinarea loturilor mici și mari reduce, de asemenea, riscul. A avea doar loturi mari poate crește probabilitatea unui impact negativ asupra experienței utilizatorului. Dacă mai multe funcții noi sunt lansate aproape una de alta, acestea ar trebui să fie însoțite de un management bun al schimbărilor. În plus, în cazul lucrărilor neplanificate, capacitatea disponibilă va fi mai mică. În cele din urmă, dacă mai multe echipe de loturi mari eșuează, iterația ar putea fi simțită ca neproductivă și astfel demoralizează echipele.

Riscurile dezvoltării bazate pe misiune

Există multe beneficii ale implementării dezvoltării bazate pe misiune, dar, ca orice cadru prescriptiv, are câteva riscuri inerente care trebuie luate în considerare.

Scopul misiunii

Misiunile ar trebui să fie realiste, vizând o potrivire bună între complexitatea provocării și abilitățile echipei; în caz contrar, impactul asupra rezultatelor dezvoltării poate fi semnificativ.

O misiune prea ambițioasă ar putea ridica frustrare și anxietate, având un impact negativ asupra performanței echipei. Pe de altă parte, o misiune neentuziastă ar putea provoca demotivarea echipei și plictiseala. Astfel, o mentalitate de Produs Minim Viabil ar trebui să rămână constantă în cadrul cadrului.

De ce a unei misiuni

Misiunile de afaceri solide ar trebui să aibă o definiție cuprinzătoare a spațiului problemei și a relației sale cu viziunea companiei. Dacă această relație nu este clară, se pot pierde informații valoroase din cauza lipsei de înțelegere a modului în care rezolvarea problemelor afectează obiectivele companiei.

Capcană în cascadă

Căderea într-un model de cascadă în timpul celor șase săptămâni este o tendință naturală pentru echipe. Există doi factori principali pentru aceasta. În primul rând, presiunea pentru desfășurare este mai puternică aproape de sfârșitul ciclului. În al doilea rând, echipele doresc să stoarce cât mai mult posibil în cadrul unei misiuni, rezultând o urgență de desfășurare la sfârșitul ciclului de dezvoltare. Prin urmare, practicile de livrare continuă ar trebui încurajate pentru a obține versiuni Agile pe tot parcursul ciclului și pentru a evita riscurile legate de cascadă.

Operarea produsului

Sarcinile de operare a produselor, cum ar fi gestionarea infrastructurii, a serviciilor sau a componentelor de monitorizare, ar trebui păstrate în afara domeniului de aplicare a echipelor, deoarece ar putea afecta viteza. Bazându-se pe standarde și practici de dezvoltare, cum ar fi proiectarea atomică, reduce eforturile de dezvoltare și, în consecință, accelerează scalarea. O altă practică comună în acest cadru este o echipă centrală de operațiuni care se ocupă de infrastructură, pe lângă gestionarea operațiunilor și monitorizarea produsului.

Ciclul de 6 săptămâni ca cadru miopic

Unele scenarii nu vor fi adecvate pentru cadru. Acest lucru devine valabil mai ales atunci când aveți de-a face cu sisteme mari și complexe care pot avea un impact enorm asupra experienței clienților, cum ar fi proiectele de cercetare și dezvoltare sau migrarea sistemelor critice.

O opțiune ușoară pentru scalarea agilă

Scalarea Agile pentru a menține ritmul dezvoltării produselor și creșterii companiei este o provocare latentă pentru practicienii Agile. Ca abordare Agile dezvoltată recent, cadrul de dezvoltare bazată pe misiune a câștigat popularitate în rândul companiilor pentru ușurința în utilizare și implementare. Cadrul MDD pune în mișcare un proces transversal de inovare a produsului, de la descoperire până la livrare, care umple golurile prezente în structurile tradiționale Agile. Dezvoltarea bazată pe misiune are potențialul de a fi noul Scrum pentru companiile în creștere.