Cum am început să lansăm funcții de două ori mai rapid (studiu de caz)

Când companiile se bazează pe aplicația dvs. pentru munca lor de zi cu zi, trebuie să fiți suficient de agil pentru a le răspunde rapid nevoilor. Dacă nu, cu siguranță alții o vor face. În lumea neiertă a SaaS, amânarea unei funcții critice (sau grăbirea unei bucăți de cod pline de erori) va însemna pierderea clienților. Un flux de lucru agil solid poate face toată diferența.

Suntem echipa din spatele Active Collab , o aplicație de management de proiect cu un set de funcții în continuă creștere și o bază de utilizatori considerabilă. Aceasta înseamnă că și cea mai mică modificare a funcționalității va afecta un număr mare de oameni.

Citiți suplimentare despre SmashingMag:

• Cum să lansați funcții noi fără a răni utilizatorii fideli
• Lista de verificare a lansării site-ului web – 15 verificări esențiale înainte de a începe
• O abordare centrată pe utilizator a designului web pentru dispozitive mobile
• Cum să lansați orice
  

Prin urmare, procesul de dezvoltare trebuie să se desfășoare fără probleme și la un standard, cu întârzieri reduse la minimum. Înainte ca orice schimbare să ajungă la utilizatorul final, aceasta trece prin cinci faze cruciale: feedback, proiectare, dezvoltare, asigurare a calității și implementare . În acest articol, voi împărtăși ceea ce am învățat (pe calea grea) despre fiecare dintre etapele de peste opt ani în afacere.

Un apel de trezire

Înainte de a intra în detalii, să vedem cum s-a întâmplat totul. După ani în care am adăugat funcții fără un control suficient, aplicația noastră suferea de balonare a funcțiilor. Am adăugat atât de multe funcționalități de-a lungul anilor, încât utilizatorii noi au fost intimidați de complexitatea absolută a interfeței de utilizare (să nu se mai întoarcă niciodată). Știam că trebuie să reconstruim de la zero, chiar dacă asta însemna să rescriem fiecare caracteristică de la zero.

Apoi au venit întârzierile. Funcțiile pentru noile versiuni au rămas constant în urmă programului. De exemplu, un dezvoltator junior trebuia să dezvolte o integrare cu QuickBooks. Nu am prezis cu exactitate complexitatea, abilitățile sau cunoștințele necesare. În plus, el a fost singurul repartizat cu această sarcină și nimeni nu a putut sări rapid să-l ajute. Drept urmare, ceea ce trebuia să fie un loc de muncă de două săptămâni a ajuns să ia cinci. Au fost câteva steaguri roșii.

Era clar momentul să trecem la o abordare mai agilă. Am luat ceea ce ne-a plăcut din diverse metode agile (și nu atât de agile), am combinat-o cu experiența și am venit cu propria noastră versiune, care a dat rezultate grozave de atunci.

Să aruncăm o privire mai atentă asupra drumului pe care trebuie să o parcurgă o funcție înainte de a fi oferită utilizatorului final.

De la sugestie la caracteristică

În fluxul nostru de lucru, o nouă caracteristică începe să prindă contur cu mult înainte de a ajunge la echipa de dezvoltare și, de obicei, se naște din feedbackul utilizatorilor. Aceasta nu este o coincidență – obișnuiam să lansăm funcții de care nimeni nu avea nevoie, de obicei doar pentru că un utilizator era deosebit de tare sau pur și simplu ne-am gândit că ar fi grozav să avem ceva. În loc să ne imaginăm de ce funcții ar putea avea nevoie utilizatorii noștri, luăm acum decizii în funcție de cererea reală.

Dacă vă interesează producția slabă, ați spune că clienții noștri „trag” anumite funcții solicitându-le mai des decât altele. Echipele noastre de asistență și vânzări reprezintă o parte importantă a procesului, deoarece sunt în contact permanent cu utilizatorii care le împărtășesc nevoile și ideile.

Pe baza feedback-ului, echipele noastre actualizează un formular care arată astfel:

Când nu avem toate informațiile de care avem nevoie, vom contacta direct clienții. Acest lucru se face de obicei cu anchete direcționate pe un eșantion atent selectat. Ideea este că ascultăm. Niciun feedback nu se pierde cu privire la noi. Este întotdeauna recunoscut și documentat.

Următorul pas este analiza. Înregistrăm scorurile în fiecare lună pentru a vedea care funcție a primit cele mai multe voturi. De asemenea, cu o clasificare adecvată, obținem o perspectivă mai largă asupra părților software-ului nostru care trebuie să funcționeze. De exemplu, dacă calendarul primește multe reclamații, vom lua în considerare refacerea întregii secțiuni, în loc să introducem funcția care a obținut cele mai multe voturi (cum ar fi exportul calendarului).

Cu toate acestea, chiar și atunci când rezultatele sunt disponibile, decizia de a introduce o funcție nu este definitivă. Înainte de a trece pe lista noastră de lucruri de făcut, facem întotdeauna o verificare amănunțită:

• Ce beneficii va aduce această caracteristică utilizatorilor?
• Se potrivește cu filozofia noastră de produs?
• Va adăuga o complexitate inutilă?
• Se îmbină frumos cu interfața și funcționalitatea existente?
• Avem resursele pentru a-l livra într-un interval de timp rezonabil?

Când o caracteristică trece de lista de verificare și proprietarii produsului o aprobă, este timpul să mergeți la planșa de desen.

Proiectare pentru utilizator

Experiența ne-a învățat că adăugarea unei noi funcții nu înseamnă doar să o lipiți deasupra interfeței de utilizare - trebuie să o îmbinați cu designul existent, ținând cont de utilizator. Dacă nu faceți acest lucru, veți ajunge în curând cu o aplicație atât de complexă încât doar câțiva curajoși vor trece prin primele cinci minute ale procesului (da, am fost acolo). Estetica este, de asemenea, importantă pentru o primă impresie bună, dar principala noastră preocupare este ușurința în utilizare . O caracteristică trebuie adăugată într-un mod care să se simtă natural pentru utilizator.

Menținem lucrurile în perspectivă întrebând: Unde s-ar aștepta utilizatorul să fie această opțiune?

Pentru utilizatorii existenți, este important ca noul design să urmeze tiparele cu care sunt familiarizați și să nu le perturbe fluxul de lucru. De asemenea, există standarde și convenții din industrie cu care suntem cu toții (inconștient) obișnuiți. Nu vă așteptați niciodată ca utilizatorii să-și schimbe complet obiceiurile. Cel mai probabil vor căuta în altă parte dacă interfața nu este intuitivă.

Luați comenzi rapide de la tastatură. Puteți face propriul set de comenzi rapide și vă așteptați ca utilizatorii să le învețe (probabil că nu o vor face). Sau le puteți adăuga pe cele pe care oamenii deja le folosesc. Mulți dintre utilizatorii noștri folosesc deja Slack, de exemplu, așa că am adăugat o comandă rapidă cu care sunt deja familiarizați ( Command + K pentru sărituri rapide funcționează și în Active Colab ).

Când fluxurile de utilizatori sunt la locul lor, designerul nostru UX bate joc de design în Sketch. Rareori folosim HTML în stadiile incipiente. Vizualizările Sketch bine gândite ne oferă suficientă flexibilitate încât nu trebuie să facem nicio întoarcere când începem să codificăm. Designul inițial ajunge de obicei să se potrivească cu aproximativ 80% din produsul final. Restul este adăugat și ajustat pe parcurs.

Un alt pas important al procesului de proiectare este copierea. Copywriterii noștri acordă o mare atenție fiecărui cuvânt. Avem chiar și propriul nostru ghid de stil, să sune cât mai accesibil și să fie cât mai ușor de înțeles. De exemplu, a spune „certificat de securitate” în loc de „certificat SSL” transmite în termeni profani ceva cu care un utilizator obișnuit ar putea să nu fie familiarizat.

Când toate acestea sunt făcute, caracteristica este atribuită unei echipe de dezvoltare. Echipa este formată dintr-un manager de proiect, un dezvoltator principal și un număr de dezvoltatori back-end și front-end, în funcție de volumul de muncă. Managerul de proiect se asigură că totul funcționează fără probleme și conform programului, în timp ce dezvoltatorul principal se ocupă de partea tehnică a lucrurilor. De asemenea, ei coordonează și îndrumează dezvoltatorii juniori.

E timpul să dai startul lucrurilor

Întâlnirile noastre de lansare nu sunt întâlniri motivaționale plictisitoare. Sunt oportunități pentru o echipă de dezvoltare (formată din dezvoltatori juniori și seniori) de a se întâlni cu managerul de proiect și proprietarul produsului.

În loc să permitem monologuri goale, ne concentrăm pe a pune cuvintele tuturor în sarcini acționabile. Pe parcursul zilei au loc trei întâlniri importante :

• Proprietarul produsului prezintă echipei caracteristica dată, ideile din spatele acesteia, design-urile inițiale și rezultatele așteptate.
• Apoi, echipa are propria întâlnire în care discută planul de acțiune, problemele potențiale și programul de testare.
• La întâlnirea finală participă toți cei implicați, iar planul ia forma finală. La sfârșitul acestei întâlniri, echipa oferă estimări pentru demonstrații și o dată finală.

Trei întâlniri ar putea să sune mult pentru o zi, dar așa ne asigurăm că problemele sunt rezolvate din timp. Completarea spațiilor libere în această etapă economisește dezvoltatorilor noștri mult timp, porniri false și întoarcere. Întâlnirile încurajează, de asemenea, munca în echipă și îi fac pe toți să simtă că contribuțiile lor sunt binevenite.

După întâlniri, echipa va avea toate informațiile necesare:

1. Ce? Acesta este domeniul de aplicare al funcției și include tot ceea ce trebuie făcut, precum și potențiale blocante și blocaje. Încercăm să anticipăm cât mai multe scenarii și cazuri marginale. Să le prezici pe toate nu este ușor; ele apar adesea pe măsură ce mergem.
2. De ce? Proprietarul produsului estimează valoarea comercială a unei caracteristici și explică de ce merită efortul. În acest fel, echipa obține o imagine clară a beneficiilor pentru clienți și produs. Principalul motiv de motivare aici este că toată lumea ar trebui să înțeleagă de ce contează munca lor și cum contribuie aceasta la companie în ansamblu.
3. Cum? Prezentând pașii necesari pentru a finaliza o funcție , ne asigurăm că dezvoltatorii noștri nu își pierd niciodată busola. De asemenea, stabilim așteptări realiste prin adăugarea unei etichete de complexitate. Am optat pentru mărimi de tricouri - S poate fi rezolvat în câteva ore, în timp ce XXL durează săptămâni sau mai mult.
4. OMS? Șeful echipei este responsabil pentru finalizarea la timp a unei funcții sau a unei sarcini și pentru actualizarea proprietarului produsului cu privire la progres. Alți membri ai echipei sunt alocați propriului set de subsarcini, astfel încât să fie perfect clar cine este responsabil pentru ce. Păstrând acest lucru cât mai transparent posibil, ne ajută să vedem dacă cineva se luptă sau provoacă întârzieri.
5. Când? Luând în considerare totul, se estimează o dată scadentă . Dacă o sarcină este întârziată, analizăm motivele și folosim această experiență data viitoare. În acest fel, un termen limită ratat devine o oportunitate de învățare și nu o sursă de stres.

Ziua de start poate deveni agitată, dar este și foarte fructuoasă. Toată lumea prezintă idei și comentarii. O sarcină se transformă dintr-o listă goală într-un centru pentru comentarii, editări și actualizări. Până la sfârșitul zilei, echipa de dezvoltare are o imagine clară a lucrărilor care urmează și un teren solid pe care să se construiască.

Trecem prin această listă de verificare înainte de a începe lucrul:

• caracteristica explicată,
• pașii de finalizare descriși,
• valoarea comercială atribuită de proprietarul produsului,
• complexitate atribuită de echipă,
• dependențe de caracteristici și erori identificate,
• criteriile de performanță identificate (dacă este necesar),
• demonstrații programate,
• datele de începere și de sfârșit stabilite de liderul echipei.

Acesta este momentul în care o sarcină trece în coloana „În curs”.

Este timpul de codare!

Munca în echipă pe ecran

Dezvoltatorii noștri nu lucrează niciodată singuri – este întotdeauna un efort de echipă și este de departe cel mai eficient mod de a lansa noi funcții. Înainte ca echipele să fie introduse, un dezvoltator (junior) rămânea blocat cu o problemă și s-ar fi putut învârti în cerc zile întregi (fără ca cineva să-și dea seama). Sau, dacă nu ar fi de tipul lone-ranger, ar distra în mod constant colegii și managerii.

Pe de altă parte, cu echipe, amestecăm oameni cu seturi de abilități și niveluri de experiență diferite. Aceasta înseamnă că fiecăruia i se atribuie un set de sarcini adecvate nivelului său. În plus, seniorii beneficiază de a învăța cum să gestioneze și să antreneze colegii de echipă juniori, iar juniorii pot cere ajutor. Pentru că este un efort de echipă și toată lumea lucrează pentru același scop, întrebările nu sunt privite ca distragere a atenției, iar echipa poate aborda orice problemă mult mai eficient. Echipa devine o entitate auto-organizată, împărțind munca în faze (sau sprinturi) și prezentându-și munca în cadrul demonstrațiilor.

Arată și spune

Conform programului, echipa va face o demonstrație pentru proprietarul produsului. Scopul demonstrațiilor este de a arăta cât de bine funcționează o funcție în starea ei actuală și unde are nevoie de mai multă lustruire. Este o verificare a realității care nu permite scuze precum „Este nevoie doar de câteva retușuri finale” (tușuri care ar dura încă o lună). De asemenea, dacă lucrurile încep să ia o întorsătură greșită, proprietarii de produse ajung să reacționeze rapid.

Întâlniri săptămânale

Am început cu întâlniri zilnice scurte la care participă toți dezvoltatorii. Fiecare dezvoltator ar descrie pe scurt la ce lucrează, problemele, blocanții și dacă avea nevoie de ajutor. Curând a devenit evident că aceste întâlniri trebuiau să fie mai concentrate și să ofere rezultate tangibile. Deci, am trecut la întâlniri cu echipe individuale aproximativ o dată pe săptămână. Acesta este modul în care proprietarii de produse și managerul de proiect sunt ținuți la curent și toate problemele potențiale sunt rezolvate pe loc.

Punând-o la încercare

Codul este scris, demo-urile au avut succes, totul pare să se încheie frumos... până când eliberați funcția și vedeți că aplicația se blochează. De aceea, fiecare caracteristică pe care o realizăm trece prin asigurarea calității (Q/A). Mereu. Testerul nostru trece meticulos prin fiecare scenariu posibil, verificând toate opțiunile și executând teste în diferite medii. O caracteristică trece rareori întrebări/răspunsuri din prima încercare.

Pentru a crește productivitatea, obișnuiam să lăsăm dezvoltatorii să înceapă cu funcții noi în această fază, dar asta a dus la o mulțime de funcții întârziate, pe jumătate terminate. Deci, acum echipa de dezvoltare se menține ocupată lucrând la sarcini mici de întreținere în timp ce funcția lor este revizuită. Dacă Q/A găsește o problemă, dezvoltatorii o rezolvă imediat și o retrimite. Procesul se repetă până când caracteristica trece Q/A și trece la revizuirea codului.

Acesta este momentul în care un dezvoltator senior se asigură că codul este scris conform standardelor noastre. Un ultim pas înainte de lansare este scrierea documentației - nu doriți să fiți copleșit de e-mailurile de asistență după lansarea unei funcții pe care nimeni nu știe cum să o folosească. De asemenea, redactorii noștri actualizează notele de lansare și scriu materiale de marketing, cum ar fi anunțuri prin e-mail și postări pe blog.

Iată definiția noastră pentru „terminat”:

• teste automate scrise,
• Întrebări/Răspunsuri efectuate și toate sarcinile rezultate finalizate,
• revizuirea codului finalizată și codul fuzionat cu master,
• notele de lansare actualizate,
• dependențe de caracteristici și erori identificate.

Sarcina a ajuns la etapa finală, numită „Release Q”.

Data eliberarii

Când am ales o zi pentru noile lansări, ne-am hotărât imediat împotriva vineri și luni. Vinerea nu este bună pentru că eventualele probleme nu vor fi rezolvate până luni; în plus, echipa de asistență era deja destul de ocupată atunci. Luni nu este cel mai bun moment pentru că orice actualizare majoră necesită pregătire, care ar trebui făcută în weekend. Întotdeauna este bine să lași o zi pentru retușurile finale. Acest lucru restrânge opțiunile la trei zile - și am optat pentru marți. Iata de ce:

• Avem luni pentru a revizui lansarea și pentru a adăuga retușuri finale înainte de implementare.
• Dacă există expresii netraduse (aplicația noastră web este disponibilă în șapte limbi), avem suficient timp pentru a finaliza traducerea.
• Echipa de marketing are suficient timp pentru a trimite buletine informative și anunțuri prin intermediul rețelelor sociale.
• Suntem disponibili să oferim asistență pentru upgrade rapid și eficient pentru restul săptămânii.
• Dacă un termen limită a trecut din orice motiv, mai avem miercuri sau joi pentru a finaliza lucrarea.

Ziua de activitate gratuită

A doua zi după o lansare majoră este o zi liberă pentru echipă. Acesta este momentul în care învață noi abilități sau fac ceva legat de muncă pe care îl consideră interesant. Chiar dacă toată lumea este nerăbdătoare să știe ce caracteristică vom lansa în ziua următoare, echipa nu discută despre asta încă. În schimb, se vor relaxa și poate urmări o prezentare despre istoria Erlang, sau vor termina de citit acel articol despre de ce PSR-7 și middleware-ul sunt importante pentru dezvoltarea PHP modernă sau vor avea propria lor discuție retrospectivă. Este o zi binemeritată pentru a-și reîncărca bateria și a sărbători munca bine făcută.

Ziua vânătorii de insecte

Pe lângă dezvoltarea de noi funcții majore, există întotdeauna de lucru pentru cele existente. Fie că este vorba despre o remediere a erorilor, o actualizare a designului sau o mică schimbare a funcționalității, echipa trebuie să se ocupe de asta într-un timp rezonabil.

Acesta este motivul pentru care avem zile de vânătoare de insecte cel puțin o dată pe lună. Este momentul în care toți dezvoltatorii încetează să lucreze la proiectele lor principale și își îndreaptă atenția către întreținere. Acest efort concentrat sa dovedit a fi un mare succes. Când toată lumea lucrează numai la erori în aceeași zi și este disponibil să se ajute reciproc, echipa rezolvă un număr mare de probleme.

Care este rezultatul?

Lansarea unei funcții mari durează acum aproximativ trei săptămâni în medie, de la lansare până la dezvoltare, testare, revizuire a codului, documentare și lansare finală. O caracteristică de complexitate echivalentă obișnuia să ne ia 45 de zile. Din perspectiva noastră, aceasta este o creștere de 100% a productivității . Am realizat-o cu aceleași resurse și oameni, singura diferență fiind un flux de lucru îmbunătățit.

Așadar, dacă avem o concluzie pentru tine, aceasta este aceasta: cultivarea unei culturi a companiei care elimină teama de schimbare va face echipa ta mai bună în ceea ce face. Nu contează dacă îi numiți Scrum, Kanban sau Lean, atâta timp cât vă ajută compania să se dezvolte. Experimentarea și inovația se află în centrul oricărei abordări agile. Nu vă fie teamă să testați diferite soluții, să măsurați rezultatele și, pe baza rezultatelor, să modificați practicile existente. Vor urma rezultate bune.