O privire de ansamblu asupra actualității sociale și profesionale ne relevă o evoluție mai degrabă exponențială, mai ales pe ultimii douăzeci de ani, care face ca astăzi beneficiile și standardele pentru persoana noastră să fie foarte ridicate. Dincolo de schimbările evident perceptibile, dinamica și amploarea acestor evenimente a făcut ca în ultimii ani să aibă loc și o importantă, dar subtilă, schimbare a poziționării accentului: contează realizările, dar, mai mult decât atât, astăzi, contează opțiunile pe care le ai. Dacă mai sunt și domenii în care acest lucru este mai puțin valabil, în IT această concluzie este cât se poate de reală și prezentă.
Revenind la proiectele IT, probabil majoritatea, clienți și furnizori de soluții, ar defini o relație de succes când livrarea produsului s-a făcut la timp, în bugetul alocat și a îndeplinit așteptările legate de funcționalitate și calitate. Majoritatea managerilor ar considera că proiectul s-a terminat cu bine și și-ar îndrepta atenția spre o nouă provocare. În realitate însă, perioada imediat următoare livrării este un punct critic, acolo unde oportunitățile apar, atât pentru client (beneficiarul produsului software), cât și pentru furnizor. Scopul acestui articol este să demonstreze de ce este important acest moment, cui îi revine responsabilitatea lui și de ce merită tratat că un scop în sine al proiectului încă din faza inițială a semnării contractului.
În general, la modul complet generic, înțelegerea și realizarea unui proiect software adună împreună, ca echipa funcțională, trei părți:
Analizând proiectele de succes și mai detaliat, se constată însă că, dincolo de diferențele de tehnologie, metodologie și de process, succesul lor se datorează unei proprietăți căreia, negăsindu-i un nume definitoriu, i-am spus "optionsability". Se definește ca proprietatea de a avea și furniza opțiuni. Relația funcțională între părți se transformă puțin și încearcă astfel să anticipeze drumul proiectului:
Cum nehotărârea clientului este un fapt destul de comun iar managementul riguros și pragmatic, componenta tehnică își cunoaște în schimb rolul precis. Dacă pentru obiectiv sau produs toate părțile se îngrijesc consecvent, responsabilitatea pentru "optionsability" revine: ….developerilor și arhitecților ca și o echipă. Subliniez rolul developerilor pentru că un plan bun poate avea o implementare corectă, dar rigidă, iar ei sunt cei care iau această decizie, voluntar sau imperceptibil. Așadar, la nivel local, are loc construcția unei proprietăți importante a proiectului, fiind un eveniment continuu, atașat fazei dezvoltării proiectului.
Ideal ar fi ca și clientul să contureze direcții de deschidere ale unor viitoare opțiuni, dar în practică acest lucru este mai rar ceea ce face ca rolul tehnicienilor cu atât mai important. Și managerii au un rol important, prin atenția continuă pentru menținerea proiectului în timp, buget și functionalitatea cerută.
Am definit proprietatea, i-am exprimat durata de viață, am găsit responsabilii, dar de ce este ea importantă și pentru cine? Pentru a răspunde de ce este suficientă o privire mai atentă asupra produselor care se bucură azi de succes: SUVs, smartphones, smart TVs, mobilierul modern (gen Ikea), articolele pentru sport, uneltele de bricolaj etc. și chiar tendințele din IT (Facebook, WhatsApp, iTunes etc). Aspectul unui produs (designul) și calitatea materialelor (sau implementarea) de obicei califică un produs spre atracția și afectivitatea consumatorilor (devin interesați de el), însă cele care construiesc legătura de succes sunt opțiunile pe care produsul le oferă. Uneori opțiunile oferite reușesc singure să decidă asupra succesului. Majoritatea avem sau vom avea copii. După ce am realizat mai multe rateuri la cumpărarea jucăriilor, am constatat că, inclusiv de la vârste mici, alegerile se fac în mod natural după opțiunile disponibile. Nu cred că are rost să detaliez ce opțiuni au Spiderman, Batman, Ironman, eroii din Star Wars și Transformers…
În ceea ce privește răspunsul la întrebarea "pentru cine?", rezultatul este simplu dar surprinzător: pentru toți.
Pentru client, implicat în comunitatea afacerilor, opțiunile sunt mai importante decât realizările în sine, în special în momente de criză, când posibilitățile scad. Un argument în acest sens este evoluția acțiunilor Apple în ultimul an, deși compania a raportat record la profitabilitate. A avea optiuni a ajuns să reprezinte un avantaj mai important decât a avea realizari în sine. Opțiunile sunt pentru afacere un rezervor de siguranță, o margine de flexibilitate, iar pentru proprietarul ei un confort care furnizează sentimentul încrederii și libertății. În sine, aceste detalii pot parea lucruri nesemnificative, însă ele sunt motoarele care produc consecințe în deciziile importante.
Prin îndreptarea atenției și dincolo de scopul proiectului, către opțiuni, pe termen scurt este posibil să apară și o creștere a costurilor, datorită necesităților de calificare mai ridicată și a schimbărilor de mentalitate necesare. Această mentalitate de a te gândi la opțiuni, nu implică neapărat implementarea lor, ci doar o pregătire prealabilă, încă din faza concepției tehnice, pentru unele dintre ele - cele mai susceptibile să fie cerute sau avantajoase. Pentru selectarea lor este nevoie de comunicare între părți și o cunoaștere atentă. Pe termen lung însă (peste 1 an), câștigurile sunt incomparabile:
Un motiv deloc de neglijat este și cresterea aprecierii clienților, care ajung să se consulte cu tine, să te recomande și să aibă încredere în relația de afaceri avută împreună. În timp, rezultatele gândirii cu "optionsability" se transpun în reputația companiei.
Pentru echipa tehnică, avantajele sunt de asemenea considerabile: crește nivelul de profesionalism, cu implicare mai mare inclusiv în contextul de business (developerul se pune mai concret în pielea clientului și caută solutii și posibilități), scrierea de cod devine mai provocatoare. A face o arhitectură flexibilă sau a scrie cod usor de citit, reutilizabil și robust este mai entuziasmant și mai folositor. Odata codul scris astfel se adună o baza reutilizabilă, crește încrederea și se reduce stresul necunoscutelor, estimările sunt o mai mică problemă. Juniorii au de asemenea un model mai bun decât clasicul "încercare-greșeală".
Pentru echipa marketing, opțiunile sunt materie primă de cea mai bună calitate. Luați spre exemplu cele mai cunoscute produse: Coca-Cola, BMW, Audi, Starbucks etc. Aproape că nu se promovează produsele în sine, ci direct opțiunile sau emoții aduse de opțiunile produselor. Opțiunile ajută specialiștii în marketing să conceapă reclame mai atractive și mai eficiente, prin focalizarea mesajelor pe opțiunile pe care oamenii le apreciază cel mai mult, dar, atenție, oferite de produs.
Pentru consumatorul final a avea opțiuni este o justificare retorică. Cu cât sunt mai educați, cu atât oamenii realizează importanța optiunilor în detrimentul activelor concrete (bunuri, bani etc.). Opțiunile sunt văzute ca o soluție sau speranță spre eficiență, performanță sau divertisment.
Probabil până în acest moment am lămurit aspectele definitorii ale acestei proprietăți, dar ceea ce este mult mai important este punerea în practică. Ca orice schimbare de mentalitate nu cred că este realist de așteptat o aderență imediată și generală la toate persoanele implicate. Această mentalitate necesită mai multă creativitate și pasiune (sau responsabilitate mai ridicată). Întrucât principalii responsabili sunt tehnicienii, adeziunea lor la acest mod de a gândi este determinantă. Ei trebuie să aibă o bună cunoaștere a scopului proiectului, de asemenea și o înțelegere măcar prealabilă a domeniului proiectului, și să-și valorifice competențele tehnice punându-se mai ales în poziția utilizatorilor acelui produs. Trebuie să caute permanent înțelegerea unor posibile evoluții a proiectului, să le sintetizeze în idei care se transpun în implementări clare și ușor gestionabile (citire, utilizare, verificare, monitorizare, reutilizare, adaptare, extindere, (dez)activare). Tehnologic există multiple ajutoare în acest sens, de la "design patterns" la metodologii și procese. "Agile" are o mare contribuție.
Cea mai bună, scurtă și concretă recomandare pe care pot s-o dau în acest sens este că implementarea unei soluții software este direct proporțională cu usurința comunicarii ei pe înțelesul părților implicate în acel domeniu. Codul este oglinda unei exprimari ideologice, relative la o cerință sau caracteristică naturală. Metaforic vorbind scrierea unei porțiuni de cod ar trebui făcută precum realizarea unui reportaj asupra unui peisaj. De obicei, peisajele au o construcție închegată și astfel se concepe un proiect.
Implementarea proiectelor cu "optionsability" ca al doilea scop nu este aplicabilă tuturor proiectelor! Nu vine ca o rețetă prestabilită. Ea depinde foarte mult de context, de o analiză obiectivă a câștigurilor și costurilor. Din experiență, ea se pretează foarte bine proiectelor cu durată de viață mare, cu necesități de actualizare și mentenanță frecvente sau proiectelor de tip fundație pentru alte proiecte. Deciziile asupra opțiunilor pregătite se iau pas cu pas și argumentat, iar confirmarea că drumul este bun se observă prin o stabilitate ridicată a calității proiectului, o ușurare în adaptarea la schimbări și o cunoștință de cauză mai bună asupra implicațiilor.
de Simplex team
