Cele trei elemente definitorii pentru strategia unui produs software enterprise

luni

3

sept.

Strategia de produs a firmei de software, care vinde produse software, este constrânsă de trei elemente principale:

  1. Realitatea curentă a produsului.
  2. Viziunea asupra viitorului.
  3. Experiența de utilizare a produsului.

Viziunea asupra viitorului

Atunci când proiectezi un produs software, te bazezi pe o viziune asupra viitorului.

De exemplu, când SIVECO Romania a proiectat AEL, platoforma LMS destinată Ministerului Educației, a analizat situația existentă și a constatat că numeroase școli nu dispuneau de conexiune Internet. Apoi a făcut o previziune, anume că pe termen mediu majoritatea școlilor nu vor avea acces la Internet și a proiectat o soluție care să funcționeze distribuit, nu centralizat și care să poată fi actualizată în absența conexiunii Internet.

Când o companie decide să creeze o soluție enterprise de tip on-premise și nu SaaS, face previziunea că în viitor această variantă va fi preferată de un număr mai mare de clienți decât alternativa SaaS. Această decizie are la bază viziunea companiei asupra viitorului pe durata estimată de viață a soluției.

Realitatea produsului

Firmele care fac produse software au o viziune despre produs înainte de versiunea inițială, 1.0. Această viziune influențează viitorul produsului prin arhitectura inițială.

Orice produs evoluează sub acțiunea cererii clienților, a modificărilor legislative, evoluției tehnologiei, dar o face limitat de arhitectura si tehnologia decise atunci cand a fost proiectat. În timp, majoritatea produselor software ajung să arate ca un palton vechi, peticit, cu buzunare aplicate nefiresc, dar funcționale.

Deciziile luate în etapa de proiectare a produsului vor acționa ca și constrângeri în tot cliclul de viață al produsului.

Arhitectura inițială și toate modificările survenite ulterior reprezintă realitatea produslui.

Experiența de utilizare a produsului

Produsele software se vând pe bază de demo. Vânzarea și adopția unei soluții software depind foarte mult de experiența de utilizare a produsului.

Proiectarea produsului și evoluția sa ar trebui să fie centrate pe experiența de utilizare a produsului, în aceeași măsură cu beneficiile aduse de utilizarea acestuia.

Problemele apar pentru că viziunea asupra viitorului poate fi inexactă, iar constrângerile pe care le impune realitatea produsului pot intra în contradicție cu experiența de utilizare a produsului.

De exemplu, să zicem că firma a mizat pe o durată mai lungă decât ciclul de viață al produsului său pentru trecerea de la preferința pentru on-prem la SaaS și a mizat pe o arhitectură on premise. Cererile clienților (experiența de utilizare) sunt clare: doresc să opereze de acasă, de pe mobil, de pe tabletă etc.

Dată fiind arhitectura existentă a produsului, firma poate decide să creeze un modul care să extindă o parte dintre funcționalități pentru lucru pe tablete și afișare pe telefonul mobil. Este un caz în care trebuie să reconcilieze experiența de utilizare cu realitatea produsului, în condițiile unui viitor care adesea este diferit de viziunea inițială asupra viitorului. Nu vor fi toate funcționalitățile, nu va fi un acces direct la produs, ci doar funcționalități esențiale, cele mai importante pentru client.

Acum vine momentul în care așteptați soluția acestei probleme.

Ei bine, nu există o soluție minune, care să împace o dată pentru totdeauna toate cele trei laturi ale problemei.

Tot ce puteți face este să vă perfecționați în aplicarea unor petice tot mai elegante, pe o arhitectură proiectată de la început cât mai flexibil posibil, având în vedere mereu experiența de utilizare pentru că, nu-i așa, până la urmă clientul hotărăște cine trăiește și cine moare în piața produselor software.

Lasă un răspuns

Adresa ta de email nu va fi publicată. Câmpurile obligatorii sunt marcate cu *

Acest sit folosește Akismet pentru a reduce spamul. Află cum sunt procesate datele comentariilor tale.