ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
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 36
Abonament PDF

Să batem palma asupra soluțiilor în proiectele software

Raluca Radu
Product Owner
@Betfair



MANAGEMENT


Într-o lume dinamică, în care obiectivele de business se schimbă în funcție de tendințele din domeniu și de mereu fluctuantul interes al consumatorilor, înțelegerea cerințelor de către cei ce le formulează și de către cei care le implementează reprezintă cheia succesului în proiectele de dezvoltare a produselor software. Neînțelegerea, proasta interpretare a cerințelor, implementarea defectuoasă care generează deraierea proiectelor, costuri suplimentare și defecte descoperite prea târziu, au ca rezultat un produs implementat care nu folosește nevoii din care s-a născut. Există prea multe cazuri de funcționalități costisitoare neutilizabile sau care nu-și justifică costul.

Ca o soluție la problema neînțelegerii sau a slabei comunicări a cerințelor de produs, metoda "shake hands" aduce nu un răspuns definitiv ci o cale spre continua îmbunătățire a formulării și comunicării cerințelor și a oferiri soluțiilor viabile pentru a îndeplini aceste cerințe. Avem și alți termeni care să descrie această metodă precum "signing-off", "handing-over" sau validarea cerințelor/soluției. Mulți dintre noi fac asta implicit la fiecare discuție cu stakeholder-ii, însă devine evident în proiectele de mare amploare și cu o mai mare importanță pentru business că aceste metode sunt imperative pentru a beneficia de soluții eficiente. Mai pe scurt devine esențială ajungerea la un acord asupra soluțiilor propuse între cei ce formulează cerințele și cei care le îndeplinesc.

Pentru facilitarea implementării soluției expuse mai sus există mai multe artefacte ce ne oferă suport cum ar fi: "proof of concept", "prototyping and design", documente care descriu de exemplu un API (ApplicationPrograming Interface), modele UML a interacțiunilor dintre sisteme, diagrame arhitecturale, etc. . Voi descrie mai jos câteva dintre aceste artefacte folosite și în proiectele la care am avut norocul să lucrez. Voi insista asupra beneficiilor comunicării între cei ce formulează cerințele (clienți, stakeholder, product manager-i, product owner-i, business analiști, etc.) și cei ce le implementează (arhitecți, tech leads, delivery manageri, echipe de implementare, echipe SCRUM, etc.).

POC sau Proof of concept reprezintă o demonstrație cu scopul de a verifica faptul că anumite concepte sau teorii au potențial pentru aplicabilitate în lumea reală. O altă terminologie folosită este aceea de "proof of principle". POC în dezvoltarea de produse software descrie procese distincte cu diferite obiective și diferiți participanți; poate, de asemenea, să ofere soluții parțiale implicând un număr mai mic de utilizatori acționând în roluri de business pentru a stabili dacă un sistem satisface anumite cerințe de produs. Astfel obiectivul principal al POC-ului este de a găsi soluții la probleme tehnice, cum ar fi modul în care sistemele pot fi integrate sau cum ar fi obținerea de datele printr-o anumită configurare.

Acum câțiva ani lucram pentru o companie de software ce acționa pe piața de outsourcing, unde un client destul de mare al acestei companii avea nevoie de o funcționalitate complexă ce necesită mai multe echipe de development și mai multe luni de muncă. Pentru a ne asigura că am înțeles corect cerințele am decis să începem un POC cu acordul clienților. A fost un succes, clienții au văzut un prototip al soluției ce urma să le servească scopul, am descoperit lipsuri în cerințe, pe care altfel le-am fi descoperit mult prea târziu în procesul de dezvoltare. Am schimbat chiar părerea clienților cu privire la importanța unor cerințe, iar la altele am renunțat cu totul. POC-ul a ajutat la comunicarea dintre noi și clienți, noi fiind cei care implementăm soluția. Ne-am simțit owner-i pe soluția propusă mai ales având acordul deplin al clienților.

"Prototyping and design" reprezintă crearea de interfețe interactive care să prezinte vizual funcționalități. Este o metodă des folosită atât în lumea online-ului cât și în reprezentarea oricărui produs fie el fizic sau virtual fără a fi totuși necesară construcția per se a acestuia. O aplicație folosită în prototyping este de exemplu Axure, cât despre design, aceasta se face cel mai adesea în Adobe Photoshop. Există pe piață o multitudine de astfel de aplicații, însă indiferent de ele, importanța creării de prototipuri și de designe stă în impactul vizual. Oamenii percep mai bine ceva ce pot să vadă cu proprii ochi, par să înțeleagă mult mai bine, când li se pune în față un model cu care pot interacționa. La fel și clienții sau stakeholderi-i relaționează mult mai bine cu o interfață interactivă care să le permită înțelegerea și vizualizarea a ceea ce urmează să devină produsul în care vor investi. În proiectele la care lucrez, care necesită interfață vizuală, este o practică comună să se utilizeze prototyping pentru a exemplifica și a cere părerea stakeholder-ilor cu privire la deciziile de produs. Ca Product Owner folosesc acest artefact ori de câte ori pot, pentru a obține o înțelegere cât mai bună a soluției ce urmează a fi implementată, pentru ca stakeholder-ii proiectelor respective să beneficieze de ceea ce au nevoie și pentru ca aceștia să fie mereu la curent cu propunerile de a îmbunătăți produsul (în cazul acesta este vorba despre produsul Betfair).

Fig. 1 Prototyping

Multe alte metode pot fi alese pentru a facilita baterea palmei, "shaking hands" asupra soluțiilor ce vor implementa produsul necesar conform cerințelor. Prin folosirea lor ne putem asigura de o tranziție mult mai lină și sănătoasă de la cerințe la produsul final, trecând prin toate procesele de rafinare a cerințelor, de transmitere a acestora și în final de implementare și testare. Atunci când cerințele sunt înțelese și de o parte și de cealaltă în mod uniform și când soluția de implementare e universal acceptată de către părțile implicate, doar atunci poate să existe siguranța că produsul îndeplinește nevoile reale și le satisface printr-o implementare la obiect.

Conferință

NUMĂRUL 142 - Robotics & AI

Sponsori

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

INTERVIURI VIDEO