ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 149
Numărul 148 Numărul 147 Numărul 146 Numărul 145 Numărul 144 Numărul 143 Numărul 142 Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 11
Abonament PDF

OPTIONSABILITY O caracteristică discretă a proiectelor IT

Bogdan Matei
Senior Php Developer
@3Pillar Global



DIVERSE

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:

  • crește eficiența prin reducerea timpului petrecut pentru "reinventarea roții";
  • se realizează o bază de cunoștiințe și unelte (re)utilizabile;
  • scade necesitatea rescrierii proiectelor (coșmarul clienților);
  • ajută la realizarea mult doritelor "best practice";
  • scade timpul dezvoltărilor, compensate de adaptări și integrare a ceea ce există facut;
  • integrarea juniorilor sau a noilor veniți se face mai rapid;
  • estimarile sunt mai precise.

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.

LANSAREA NUMĂRULUI 150

Noile tehnologii SAP ABAP

Marți, 10 Decembrie, ora 18:00

sediul MHP - A Porsche Company

Facebook Meetup StreamEvent YouTube

NUMĂRUL 149 - Development with AI

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Cognizant Softvision
  • Colors in projects

Bogdan Matei a mai scris