Unii fac diferenţa între inovaţie de la Zero la Unu şi inovaţie de la Unu la O Mie. Noi am ales să ne concentrăm pe a lucra în proiecte de la Zero la Unu

Cred cu tărie că avem cu toţii o responsabilitate: să schimbăm lumea din jurul nostru în mai bine.
Şi cred că mai avem responsabilitatea să învăţăm şi să creştem în fiecare zi, pentru a schimbă lumea din jurul nostru în mai bine.
Timp de secole, puterea de a schimbă lumea a fost concentrată în mâinile unui număr relativ mic de oameni, în principal regi, generali, capi ai bisericii, artişti, oameni de ştiinţă şi apoi proprietarii marilor corporaţii.
Pentru toţi ceilalţi, viaţă însemna în primul rând supravieţuire şi supunere în faţa celor care aveau putere.
În ultimele decenii însă, am trecut printr-o transformare radicală.
Odată cu avansul democraţiei şi a tehnologiei în toată lumea, puterea de a schimba ceva semnificativ este acum în mâinile a zeci sau poate chiar sute de milioane de oameni.
Noi suntem printre cei norocoşi.
Noi, cei care lucrăm în industria IT&C în Iaşi. Cei care facem software.
Suntem norocoşi, pentru că putem avea un impact, dacă ne propunem asta.
Sunt mulţi oameni cu idei bune, cu iniţiativa şi energie.
Unii, din ce în ce mai mulţi, aleg calea antreprenoriatului. Alţii, şi mai mulţi poate, aleg să fie intraprenori şi să schimbe companii, instituţii şi sisteme existente lucrând din interior.
Unii încearcă să transforme o comunitate. Alţii vor să revoluţioneze o industrie.
Majoritatea vor să schimbe ceva în bine.
Multe din aceste iniţiative au o componentă software.
Dar, aşa cum ştim deja cu toţii, e foarte dificil să construieşti software de calitate.
Cu atât mai mult dacă vorbim de proiecte pornite de la zero.
De cele mai multe ori însă, are buget doar pentru fundaţie, primele 2 etaje şi 5 locuri de parcare.
În discuţiile cu clienţii noştri despre ideile lor, comparăm de multe ori procesul de construcţie al unei clădiri cu procesul de a construi produsul lor software.
Când un antreprenor cu o idee începe un proiect software, are deja în minte echivalentul unei clădiri cu 100 de etaje. De cele mai multe ori însă, are buget doar pentru fundaţie, primele 2 etaje şi 5 locuri de parcare.
Astfel că echipa de development trebuie să lucreze din prima zi ştiind că urmează să construiască o clădire cu 100 de etaje, fără să ştie însă dacă acea clădire va găzdui apartamente, birouri, magazine, muzee sau de toate la un loc.
Şi trebuie să clădească o fundaţie care să fie extrem de rapid de construit, să susţină toată greutatea clădirii şi în acelaşi timp să poată fi modificată în timp, pe măsură ce tehnologia avansează şi nevoile utilizatorilor clădirii se schimbă.
Este extrem de dificil să construieşti software de calitate într-un mediu impredictibil, unde nu ştii exact ce ar trebui să construieşti, unde nevoile utilizatorilor şi chiar utilizatorii se pot schimba de la o luna la alta, unde tehnologia evoluează atât de repede încât versiunea de anul trecut este deja învechită astăzi.
Nu e de mirare că multe proiecte software începute de la zero nu ajung nicăieri.
De fapt, marea majoritate a proiectelor începute de la zero ajung în situaţii în care bugetul e depăşit semnificativ, totul durează de 3 ori mai mult decât era planificat iniţial şi mai sunt şi probleme de calitate.

 
Şansele statistice nu sunt deloc de partea celor cu idei care au nevoie de software de calitate.
Sunt mult mai mulţi oameni cu idei bune în lume decât sunt oameni cu experienţă şi expertiză care să construiască software de calitate.
Factori cheie de succes – unde poti interveni
Sunt extrem de multe aspecte care ar putea să nu funcţioneze într-un proiect şi care ar putea duce la un eşec. După ce am lucrat în mai mult de 50 de proiecte cu startupuri de tehnologie cu echipe din Thinslices, noi am identificat câteva puncte esenţiale în care poţi interveni pentru a creşte semnificativ şansele de succes ale unui proiect software pornit de la zero.
Pentru că este un domeniu complex, am încercat să sintetizăm aceşti factori cheie de succes într-un instrument care să poată fi folosit de oricine. L-am numit “SaaS Execution Map” (Software as a Service Execution Map).
1. Roluri şi membri ai echipei

• Back-end developer.
• Front-end developer.
• DevOps engineer.
• Mobile developer (iOS, Android sau hybrid).
• QA automation engineer.
• Tester.
• Database Designer / Administrator
• Business Analyst.
• Designer (Grafic, UX, identitate).
• Project Manager.
• Product Manager.

În funcţie de complexitatea proiectului, sunt şanse mari ca la un moment dat să fie nevoie de fiecare din aceste competenţe în echipa.
În funcţie de proiect, e posibil să fie nevoie şi de o expertiză mai specializată, de genul gestionarea unor seturi mari de date, machine learning sau imagistică medicală.
Însă nu ai nevoie de toată această echipa din prima zi.
Şi nu ai nevoie de toată echipa pe tot parcursul proiectului.
Este însă foarte important să poţi anticipa când vei avea nevoie de fiecare, pentru a putea planifica munca pe proiect.
2. Metodologie – la ce lucrează echipa şi în ce moment
Este mult prea simplist să spui că singura metodologie de care ai nevoie pentru a livra un proiect este Scrum, cu sprinturi de 2 săptămâni şi cu ceremoniile pe care le cunoaştem cu toţii.
Scrum este doar primul pas şi doar Scrum nu garantează nimic.
Din experienţa proiectelor la care am lucrat noi (şi din greşelile pe care le-am făcut), am învăţat că sunt 3 faze distincte în primii ani ai unui proiect software început de la zero:

• De la Zero la Product Design
• Lansarea unui MVP (Minimum Viable Product)
• Dezvoltarea până la Unu.

În acest context, noi facem diferenţa între inovaţie de la Zero la Unu şi inovaţie de la Unu la O Mie.
Alegerea pe care am făcut-o a fost să ne concentrăm pe a lucra în proiecte de la Zero la Unu şi pentru acest gen de proiecte sunt aplicabili factorii de succes pe care noi i-am identificat.
Fiecare din aceste 3 etape este caracterizată de un mod specific de lucru şi de livrabile diferite pentru care ar trebui să lucreze echipa.

Ideea pe scurt

Problema: E din ce în ce mai dificil să construieşti un produs software de la zero cu succes. Fie că este un startup sau un proiect nou într-o companie consacrată, şansele de a livra la timp şi în buget sunt relativ mici.

Oportunitatea: Ca urmare a schimbărilor din ultimii ani, suntem într-un moment în care noi, cei din industria IT&C din Iaşi, putem avea un impact pozitiv semnificativ în jurul nostru, la nivel local, naţional sau chiar global.

O Posibilă Soluţie: Pe lângă energie şi idei bune, e nevoie de o disciplină a execuţiei. SaaS Execution Map este un instrument care poate creşte simţitor şansele de succes pentru proiectele începute de la zero care au şi o componentă software majoră.

Product Design: momentul viselor
Cuvântul cheie în această prima etapă este “creativitate”. Acum este momentul viselor, al punerii pe hârtie a viziunii pe termen lung pentru produs sau proiect.
Cu cât sunt mai multe idei discutate şi puse pe hârtie în echipă în primele săptămâni, cu atât cresc şansele ca membrii echipei, care ajung să lucreze în proiect în diferite momente, să înţeleagă mai bine contextul şi să poată contribui într-un mod productiv.
Conceptele care sunt atinse la această faza trebuie de asemenea să acopere gama completă şi să fie bine distribuite între următoarele faze ale proiectului.
Un exemplu în acest sens este conceptul sau instrumentul “Personas”. Am învăţat şi noi de-a lungul timpului că este extrem de important să defineşti bine cine sunt utilizatorii ideali pentru produs, pentru cine este acesta construit. Am învăţat că e nevoie să răspunzi de la început la întrebări de genul:

• Sunt utilizatorii diferiţi de cumpărătorii produsului?
• Au nevoi şi/sau comportamente diferite?
• Care este segmentul de clienţi pe care ar trebui să ne concentrăm pentru prima versiune a produsului, ştiind că nu avem nici timpul, nici resursele pentru a construi un produs care face de toate pentru toţi?
• La ce momente plănuim să adresăm nevoia fiecăruia dintre categoriile de utilizatori sau cumpărători ai produsului nostru?

Nu contează ce template foloseşti pentru a descrie “personas” pentru produs. În unele contexte ar putea fi utilă o abordare care pune accent mai mult pe aspecte demografice, în altele una care se uită mai ales la comportamentul de utilizare a produsului.

Care sunt cuvintele cheie pentru fiecare etapă

Product Design: Creativitate

MVP: Focus (pe livrare cât mai rapidă şi funcţionalităţi cât mai limitate)

Unu: Creştere (a numărului de utilizatori, a echipei, a code-băse-ului, a numărului de potenţiale probleme)

Ce este foarte important e ca cineva din echipă să-şi pună problema “pentru cine construim produsul?” şi răspunsul la această întrebare să fie vizibil şi înţeles de toţi cei care vor contribui la proiect.
Un alt rezultat vizibil al fazei de Product Design ar trebui să fie un prototip al produsului.
Prototipul poate lua multe forme şi poate servi unor scopuri diferite, în funcţie de proiect şi de context.
Sunt cazuri în care e foarte utilă construirea unui Prototip Vizual, cu design-ul final al flow-urilor principale din aplicaţie sau platforma. Avantajul enorm pe care îl aduce este că nu e nevoie să scrii toată aplicaţia, să depui o muncă care ar putea dura luni de zile cu cel puţin 4 sau 5 oameni, pentru a putea valida ideea cu potenţiali clienţi sau investitori.
Un prototip vizual poate fi făcut în câteva zile până la 2 săptămâni şi va salva cu siguranţă mult timp şi resurse, care ar fi fost cheltuite pentru a dezvoltă funcţionalităţi care nu creează valoare pentru utilizatori.

Şansele statistice nu sunt deloc de partea celor cu idei care au nevoie de software de calitate

În alte cazuri e posibil să fie nevoie de construirea unui Prototip Funcţional. Atunci când se folosesc tehnologii foarte noi, netestate, sau la limita dintre soluţii teoretice şi tehnologii funcţionale, este nevoie de prototip, de un “proof of concept”, pentru a reduce pe cât posibil riscul ca tehnologia aleasă să nu fie potrivită pentru problemele care trebuie rezolvate sau pentru echipa care lucrează la proiect. Şi cred că suntem cu toţii de acord că e mai bine să ştii asta după primele 2 săptămâni din proiect decât după 6 sau 12 luni.
Lansarea unui MVP (Minimum Viable Product): cuvintul cheie este “focus”
În cea de-a două faza, de lansare a unui MVP, accentul se mută de la creativitate la livrarea cât mai rapidă şi pe limitarea cât mai mult a scopului proiectului la un set mic de funcţionalităţi foarte valoroase.
Cuvântul cheie este “focus”.
O regulă empirică la care am ajuns noi e că poţi face un MVP cu o echipa mică în 3 luni. Orice MVP planificat pentru mai mult de 6 luni nu mai e MVP şi are prea multe funcţionalităţi.
În mod evident, faţă de etapa de Product Design, lucrurile se complică. Sunt mai mulţi membri ai echipei, sunt mai multe mecanisme în mişcare şi subiecte pe care pot apărea surprize. Multe dintre ele sunt deja standarde acceptate şi preluate de majoritatea companiilor: backlog, medii separate de dezvoltare, sprinturi, cerinţe non-funcţionale.
Dacă ne uităm în trecut, la momentele când am făcut greşeli care ne-au costat mult, sunt 2 lecţii importante:

• NU
• Acoperirea produsului cu suite de teste automate

De ce “NU”? Pentru că ştim cu toţii cât e de greu să spui NU. Fie că vorbim de contexte profesionale, când trebuie să spunem unui manager care ne cere ceva că nu avem timp să ne ocupăm şi de asta, sau de contexte personale, între prieteni sau în familie, e foarte dificil să spui nu cuiva.
Şi totuşi, aici este de foarte multe ori cheia pentru a construi un MVP într-un mod eficient.
Nu.
Nu avem timp şi pentru această funcţionalitate la care te-ai gândit aseară, fără să facem vreo analiză asupra impactului pe termen lung în produs.
Nu, nu avem nevoie de acest buton cerut de un singur client, care ameninţă că dacă nu-l punem în aplicaţie nu mai cumpără de la noi.
Nu, nu mai putem schimbă acum tehnologia. Trebuie mai întâi să lansăm MVP-ul live, să validăm produsul în piaţă, şi abia apoi ne putem gândi la schimbări fundamentale în produs.
A două lecţie învăţată în timp se referă la necesitatea acoperirii produsului cu teste automate.
Nu contează dacă vorbim de “unit tests”, teste automate de interfaţă, teste de integrare sau de regresie, teste pe API sau de orice alt fel.
MVP-ul este fundaţia şi primele 2 etaje pentru clădirea de 100 de etaje pe care vrem să o construim. Dacă nu avem teste scrise pentru MVP, va fi extrem de costisitor şi dureros apoi să facem schimbări în produs, să adăugăm funcţionalităţi sau să mărim echipa cu oameni noi.
Şi dacă testele nu sunt scrise la început, sunt şanse mari că nu vor mai fi scrise niciodată.
Dezvoltarea până la Unu: În această etapă, accentul se mută pe “creştere”
Dacă totul merge conform planului, creşte echipa, creşte numărul de roluri din ea, creşte numărul de utilizatori ai produsului, creşte code-base-ul şi creşte numărul de probleme şi dificultăţi care pot apărea.
Echilibrul care trebuie acum găsit este între cele 2 extreme care ştim cu toţii că nu funcţionează.
Pe de o parte, o abordare gen “waterfall”, în care încerci la început să scrii documentaţie extrem de detaliată pentru tot produsul, pentru tot ce ar trebui dezvoltat în primul an. În acest mediu impredictibil, în permanentă schimbare, nu este deloc realist să crezi că poţi anticipa perfect toate nevoile pe care trebuie să le satisfacă produsul.
În celălalt colţ este abordarea pur “agilă”, în care începem direct să lucrăm la produs, să scriem software, fără să gândim un plan, fără să ne punem în vreun fel problema de cum ar trebui să funcţioneze o versiune 1 sau 2 a produsului.
Ca de cele mai multe ori în viaţă, extremele sunt periculoase şi de cele mai multe ori nu duc la nimic bun.
Modelul la care am ajuns după destule iteratii este reprezentat de un proces elastic, ce depinde foarte mult de tipul produsul la care lucrăm. În toate cazurile este vorba de un efort comun al întregii echipe de a găsi cea mai eficientă soluţie la o anumită problema, variaţia apărând la etapele în care validăm soluţia cu beneficiarul proiectului.
3. Cum să lucrezi ca o echipa adevărată
Ar fi ideal ca atunci când începem un proiect nou să lucrăm cu alţi colegi cu care am mai lucrat împreună cel puţin 2-3 ani înainte şi ca toţi membrii echipei să se cunoască şi să lucreze foarte bine împreună din prima zi.
Ştim însă cu toţii că este complet nerealist să ne aşteptăm să se întâmple asta.
Şi totuşi, de comunicarea şi colaborarea în echipa depinde în mare măsură succesul proiectului. Cel puţin asta am învăţat noi de-a lungul anilor: dintre cei 3 factori cheie de succes, acesta este absolut critic. Dacă cei din proiect lucrează ca o echipa adevărată, au şanse mari de succes.
Cum arată o echipa adevărată?
O definiţie, la fel de bună ca oricare alta, spune că o echipa adevărată este un grup de oameni
care au un scop comun,
care au competenţe şi abilităţi complementare,
care au valori şi credinţe comune
care sunt responsabili de acţiunile lor în faţă colegilor din echipa.
Dacă ne uităm la modul în care se fac şi desfac grupurile de oameni care lucrează împreună la proiecte şi la viteza cu care oamenii îşi schimbă rolurile, poziţiile şi chiar compania la care lucrează, este evident că, dacă lăsăm lucrurile să evolueze într-un ritm normal, natural, şansele de a ajunge la o echipa adevărată sunt foarte aproape de zero.
Şi totuşi, dacă ne uităm la definiţia unei echipe adevărate, putem vedea că nu e chiar atât de dificil pe cât pare.
Nu ar trebui să dureze luni de zile pentru ca un grup de oameni care lucrează împreună să agreeze care este scopul lor comun.
Persoana sau persoanele care formează echipa se pot asigura că membrii ei au competenţe şi abilităţi complementare, dar şi valori şi credinţe comune.
Cât despre responsabilitatea în faţă colegilor, aceasta ţine foarte mult de încrederea din echipa.
O echipa fără încredere nu este o echipa, este doar un grup de individualităţi care lucrează împreună. Nu-şi împărtăşesc unul altuia cunoştinţele, sunt competitivi între ei pentru obţinerea unor poziţii mai bune, nu cooperează unul cu celălalt.
Nu contează cât de capabili sau talentaţi sunt oamenii din grup, ei nu-şi vor atinge niciodată adevăratul potenţial dacă nu există încredere. Gândire creativă, eficientă, productivitate, colaborare – toate acestea nu pot exista fără încredere.
E poate mai dificil decât ne-am dori.
Dar dacă succesul proiectului sau companiei depinde de asta, cu siguranţă e un efort care merită depus.