Potrivit specialiştilor în resurse umane, în România IT-ul este unul dintre puţinele domenii în care numărul de poziţii disponibile a crescut după izbucnirea crizei economice şi unul în care companiile se află în competiţie pentru cei mai buni specialişti.
Se aude tot mai pregnant ideea că, în competiţia cu costurile reduse ale salariaţilor din alte zone geografice (cum ar fi, de exemplu, Asia) soluţia este să se migreze de la outsourcing la produse proprii, sau, într-un poces mai puţin radical, să se petreacă o schimbare în ceea ce priveşte relaţia cu clienţii şi să se transforme statutul de simplu executant (aşa cum ar putea fi el indus de modelul outsourcing) într-un statut de consultant (ce ar transforma firmele IT în parteneri pentru clienţii lor).
Product Mindset reprezintă o abordare modernă şi provocatoare având la bază ideea dezvoltării unui produs propriu aplicată într-o cultură specifică furnizării de servicii IT prin păstrarea principalele avantaje ale celor două direcţii.
Această abordare vine atât cu avantaje cât şi cu dezavantaje, iar articolul de faţă îşi propune să detalieze cele mai importante dintre ele.
Înainte de a oferi o imagine cât mai detaliată a ceea ce ar reprezenta product mindset pentru segmentul de outsourcing al industriei software, vom prezenta câteva definiții.
Product mindset se referă la ideea de a extrage informaţii despre ceea ce îşi doresc clienţii de la un produs, fără ca aceştia să precizeze direct sau foarte exact acest lucru, dezvoltând în final un rezultat care să le fie pe plac.
În contrast, services mindset reprezintă ideea de a realiza foarte bine ceea ce doreşte şi specifică un client anume. Clienţii enunţă cerinţele, iar dacă aceste cerinţe nu sunt bine definite se adresează întrebări succesive cu scopul de a clarifica toate aspectele.
Diferenţa majoră între cele două abordări constă în implicarea decisivă a celui care dezvoltă produsul în identificarea funcţionalitătilor si definirea formei sale finale. Dacă abordarea services mindset vede echipa de dezvoltare formată din simpli (dar foarte buni) executanţi, product mindset vede echipa de dezvoltare ca o echipă de consultanţi pentru dezvoltarea produsului, clientul şi echipa devenind astfel parteneri.
Vom detalia în cele ce urmează câteva aspecte definitorii ale companiilor orientate pe servicii (CoS) în contrast cu cele ale companiilor orientate pe produse (CoP). Pentru fiecare dintre cele două abordări am enumerat acele aspecte care ni s-au părut relevante pentru subiectul prezentului articol.
În cazul CoS se întâmplă deseori ca un proiect să dureze câteva luni după care membrii echipei de proiect să continue să lucreze (împreună sau nu) la proiecte total diferite, ce ţin de domenii diferite şi, de ce nu, cu tehnologii diferite (sau cu aceeaşi tehnologie dar cu framework-uri şi versiuni diferite). Aproximativ 50-60% dintre noii angajaţi vor învăţa şi vor face tranziţia către tehnologii noi încă de la început şi aproape toţi urmează să schimbe tehnologia pe durata angajamentului. Într-o proporţie foarte mare (90%) candidaţii pe poziţii deschise în CoS nu vor fi intervievaţi de echipa în care vor lucra.
În contrast, candidaţii în CoP sunt intervievaţi mult mai atent pentru a se vedea dacă se potrivesc echipei în care vor lucra atât din punct de vedere tehnic cât şi din punct de vedere al personalităţii. În plus, pe perioada angajamentului vor schimba mult mai greu echipa şi tehnologia.
CoP acordă în general o importanţă mare satisfacţiei angajaţilor şi consideră că plecarea unuia dintre angajaţii companiei constituie o pierdere importantă. Experienţa acumulată de-a lungul timpului în dezvoltarea produselor companiei face ca o anumită persoană să fie dificil de înlocuit. Pe de altă parte, în cazul CoS plecările angajaţilor sunt mai dese şi afectează rareori compania în mod semnificativ. Impactul scăzut asupra companiei se datorează faptului că în majoritatea CoS angajaţii dezvoltă rareori expertiză la nivelul unui produs, fiind suficiente doar cunoştinţele de programare pentru a-şi duce la bun sfârşit sarcinile. Pe de altă parte, frecvenţa acestor schimbări dese de loc de muncă se explică într-o oarecare măsură prin faptul că angajatul are ocazia să lucreze de-a lungul timpului cu proiecte diverse şi în echipe diferite în cadrul companiei ( tranziţia către o altă companie poată să pară un proces obişnuit ). Contextul tehnologic dinamic contribuie la rândul său schimbarea mai facilă a angajatorului. În CoP există posibilitatea de a lucra o perioadă lungă de timp pe o tehnologie foarte particulară. În acest context, angajaţii sunt mult mai interesaţi să rămână şi să se specializeze în cadrul companiei.
În companiile orientate pe servicii angajaţii sunt măsuraţi după cantitatea de muncă depusă, responsabilităţile asumate şi gradul de satisfacţie a clientului. Conexiunea dintre efort şi promovare sau remuneraţie este, în general mai clară. În cazul companiilor orientate pe produs efortul depus pentru a îndeplini obiectivele produsului este privit ca o activitate normală, de bază. Promovarea sau un salt mai consistent din punct de vedere salarial au loc atunci când se realizează activităţi ce nu sunt legate de activitatea normală de lucru, cum ar fi redactarea de articole sau întreţinerea unor bloguri de specialitate, susţinerea de prezentări tehnice la diverse evenimente, etc. .
În consecinţă există un oarecare contrast şi în ceea ce priveşte denumirea poziţiei/seniorităţii ocupate de angajaţi. Trecerea de la programator junior la intermediar şi apoi la senior se face mai rapid şi cu mai mare uşurintă în CoS şi într-o relaţie directă cu vechimea. În CoP o persoană rămâne pe o poziţie de senioritate constantă o perioadă lungă de timp, iar numărul de ani petrecuţi într-un domeniu nu constituie un argument suficient de promovare, principalul argument fiind cel al expertizei pe domeniul pe care angajatul activează.
Ca o paranteză trebuie spus că poziţia "câştigată" de o persoană într-o CoP rămâne continuă şi se solidifică în timp. În CoS la fiecare nou proiect poziţia trebuie reconfirmată şi încrederea clientului în persoana care joacă un anumit rol trebuie recâştigată. Spre deosebire de proiectele noi în CoP unde o persoană intră împreună cu reputaţia sa câştigată pe proiectele precedente, în CoS lucrurile pornesc de la zero şi clientul trebuie convins de calitateaechipei ca şi cum nu ar exista nici un istoric relevant în spate.
În altă ordine de idei, CoS câştigă contracte în faţa competitorilor asigurând o livrare mai rapidă la aceeaşi calitate (şi/sau costuri reduse). Aceasta se concretizează în multe cazuri printr-un efort susţinut al echipei şi finalul proiectului este sărbătorit de echipă. CoP livrează în foarte rare cazuri produsele la data planificată însă de multe ori sunt mai bogate în funcţionalităţi decât era planificat iniţial.
Un alt paradox interesant este dat de faptul că în CoS proiectele sunt obţinute pe baza demonstrării profesionalismului angajaţilor şi a istoricului referinţelor. Totuşi, pentru majoritatea proiectelor nou obţinute se vor angaja oameni noi pentru echipa de proiect şi al căror profesionalism nu este încă demonstrat.
Nu vom întâlni o companie orientată exclusiv pe produsele proprii încercând să obţină un certificat de maturitate. De ce ar avea nevoie de certificarea unei organizaţii externe când aceasta deja dezvoltă produse noi pe piaţă? Pe de altă parte o astfel de certificare asigură clienţii că produsele realizate de o CoS respectă anumite standarde de calitate.
Financiar, CoS cresc liniar cu creşterea numărului de proiecte şi a numărului de angajaţi. Necesarul de capital însă este scăzut, deoarece banii pe serviciile oferite vor intra încă de la începutul proiectului. În CoP creşterea financiară este în concordanţă cu numărul clienţilor şi a pieţelor de desfacere pentru produsele realizate, raportul dintre profit şi numărul de angajaţi fiind mult mai favorabil decât în cazul CoS. În plus este nevoie de un capital mai mare necesar în dezvoltarea, promovarea şi vânzarea produsului. Se alocă buget special pentru marketing şi vânzări.
În practică nu vom întâlni aproape niciodată implementată în mod pur una dintre cele două abordări. Pentru fiecare dintre caracteristicile discutate putem să ne gândim la contraexemple valide printre companiile pe care le vedem în jurul nostru. Acest lucru se întâmplă pe de o parte datorită vizunii pe care o au managerii unora dintre companii dar pe de altă parte şi lipsei de maturitate ale altor companii ce duce, uneori, la aplicarea unor strategii greşite ignorând contextul. Totuşi trăsăturile esenţiale se păstrează în marea majoritate a cazurilor şi reprezintă un foarte bun punct de start pentru discuţia despre product mindset.
Una dintre cele mai interesante provocări este aceea de a combina laolaltă avantajele celor două abordări amintite mai sus şi de a atenua dezavantajele ce derivă din fiecare dintre ele. Combinarea se referă la introducerea de elemente specifice abordării proiectelor bazat pe servicii în CoP sau la implementarea unei abordări centrate pe produse în CoS. Există şi un al treilea tip de combinare, şi anume acela în care avem de-a face cu o companie orientată atât pe servicii cât şi pe produse, însă acest caz se poate reduce la precedentele cazuri dacă discutăm independent de departamentele ce gestionează produsele şi serviciile unei astfel de companii.
Ne vom concentra în cele ce urmează pe cel de-al doilea tip de combinare lăsându-le pe celelalte două ca subiecte pentru un posibil viitor articol.
Product Mindset este un mod de abordare a serviciilor ce presupune o valoare semnificativă adăugată serviciilor prestate, asigură satisfacţii mai mari clienţilor, iar profitul obţinut este vizibil îmbunătăţit. În cazul industriei IT, produsul sau produsele clienţilor sunt "adoptate" de către compania ce implementează un astfel de product mindset iar implicarea companiilor software nemaifiind exclusiv axată pe execuţie. Apar roluri noi care dublează sau uneori chiar înlocuiesc roluri care în mod firesc intră în responsabilitaţile clientului (cum este, de exemplu, rolul de product owner).
Există două elemente caracteristice CoS ce impun o oarecare rigiditate în activitate şi care necesită o atenţie deosebită atunci când se doreşte implementarea unui product mindset. În primul rând avem rezistenţa echipei de a lucra cu specificaţii incomplete. În general, echipa se aşteaptă ca toate detaliile legate de o funcţionalitate (sau un user story) să fie clarificate de către client înainte de a începe dezvoltarea sa. Argumentându-se în acest fel se evită irosirea efortului de dezvoltare şi rescrierea unor porţiuni ale unei aplicaţii de două sau mai multe ori, echipa de proiect amână dezvoltarea unor elemente esenţiale ale aplicaţiei, efortul fiind concentrat pe un "ping-pong" de e-mail-uri sau şedinţe de clarificare ce pot dura nedefinit. Abordarea proiectului având un product mindset presupune implementarea de funcţionalităţi care nu au fost complet specificate de către client. Evident acest lucru presupune o cunoaştere cât mai bună a domeniului de business al clientului şi în acelaşi timp şi un grad mai ridicat de risc. În acest fel însă se deblochează dezvoltarea unor funcţionalităţi importante, deoarece clientul este mult mai în măsură acum să îşi clarifice nevoile plecând de la un exemplu deja implementat.
Al doilea element esenţial îl reprezintă incapacitatea echipei de proiect de a înţelege şi urma sugestiile clientului cu privire la finalizarea unui produs sau modul în detrimentul calităţii acestuia. O soluţie particulară şi nu una generică, flexibilă şi adaptabilă (dar care necesită o dezvoltare mai îndelungată), întreţinerea unor componente scrise într-o tehnologie "antică" în locul rescrierii şi "modernizării" acestora, o implementare parţială a unor funcţionalităţi sau testarea incompletă a produsului reprezintă uneori cerinţe exprese ale clienţilor pentru a forţa atingerea unor deadline-uri esenţiale pentru soarta produsului. Astfel de propuneri, în cazul în care nu întâlnesc o echipă cu un product mindset, au darul de a conduce la frustrarea membrilor săi şi chiar la refuzul unora dintre ei de a continua munca pe proiect acuzând o presupusă lipsă de profesionalism. Rezolvarea acestei situaţii presupune efort din ambele direcţii: clientul va trebui să fie deschis la a partaja cu echipa de proiect elementele ce ţin de viaţa produsului însă şi echipa trebuie sa fie interesată de aceste aspecte şi nu concentrată exclusiv pe execuţie.
O abordare product mindset ajută la colaborări pe termen lung între CoS şi clienţii lor, aceştia din urmă văzând echipa de dezvoltare ca parte a propriei organizaţii, creditând-o cu încredere şi respect. Această apropriere însă dezvoltă un ataşament, uneori exagerat, al membrilor echipei pentru client si produsul sau produsele acestuia, unii dintre ei considerându-se angajaţi ai clientului şi nu a companiei de servicii din care fac parte.
Trebuie acordată de asemenea o atenţie deosebită încheierii proiectelor, deoarece astfel de momente pot determina părăsirea companiei de către mulţi dintre cei care au dezvoltat un ataşament crescut pentru proiect.
Analiza implementării unei abordări orientate pe produs într-o companie a cărei activitate este preponderent orientată pe servicii este departe de a fi una exhaustivă. Totuşi, aspectele atinse sunt unele relevante ce influenţează hotărâtor parcursul şi succesul unei CoS în IT, iar avantajele implementării unei astfel de combinaţii sunt evidente. Modul de implementare a acestei combinaţii este, bineînţeles, o altă discuţie acesta depinzând, intr-o mare măsură de cultura organizaţională şi procedurile interne existente în fiecare companie în parte.
de Ovidiu Mățan
