Am auzit și-am văzut atât de multe experiențe nefericite de consultanță în IT, încât am ajuns să cred că apelul (nepregătit) la consultanță este similar cu jucatul la loto. Ca să-mi susțin afirmația de mai sus voi face mai multe paralele între mersul la consultantul în IT și mersul la medic.
Consultantul generalist
Dacă lucrați în IT, foarte probabil că vi s-a întâmplat să participați la măcar o discuție lungă și plictisitoare despre cel mai bun limbaj de programare, open source sau Microsoft, Java față de .NET, PHP și paradigma POO, ș.a.m.d. Aceste polemici scot în lumină dificultatea unor decizii cu care ne întâlnim des în IT. Multitudinea posibilităților scade considerabil șansa unei păreri obiective și utile, șansă care din punctul meu de vedere, este invers proporțională cu nivelul de geekiness al consultantului din fața ta. De fapt, în căutarea unui răspuns optim, cultura generală este crucială. Însă este aproape imposibil să te ții la curent cu toate tendințele și să rămâi în același timp un practician excepțional. Sub influența cărților lui Craig Larman, am botezat acești teoreticieni ca arhitecții astronauți. Un fel de medici de familie în IT. Acei oameni obositori, indisponibili și capabili să-ți piardă mult timp cu întrebări triviale. Și eu intru în această categorie.
IT-iști
Problemă (exprimarea clientului): Suntem o echipă de 100 de persoane și avem un volum impresionant de defecte și anomalii. Ce să facem? Soluție: Oamenii nu sunt responsabili, măsurați! creșteți echipa, sistem de bonus... Gânduri: în niciun caz nu poate fi vorba despre o tehnologie greșită, despre o nevoie client prost înțeleasă sau despre management defectuos. Realitate: Problemele sunt încă acolo. Încă vorbesc despre presiune și că nu se livrează în termenii stabiliți. Ce surpriză!?
Doctori
Olga merge la doctor cu antibiograma lui Corneluș. Cu antibiograma în față, doctorița îi recomandă un antibiotic marcat ca fiind ineficient împotriva bacteriei respective.
Alt exemplu despre alegerea soluției
IT-iști
Problemă (era prin 2009, exprimarea clientului): Avem nevoie de un modul de chat pe care să-l integrez în soluția noastră... Soluție: Consultantul propune o aplicație web HTML/JS/CSS. S-a și arătat un exemplu de site public care demonstra că orice risc tehnic este implementabil. S-a pornit cu realizarea acestui chat de la nimic. Gânduri: Din discuțiile mele cu clientul, nici măcar nu conta pentru el dacă este o aplicație web sau nu. Cel puțin nu imediat. Și nimeni nu știe de ce a fost nevoie de HTML, când exista Flash și Flex. iPhone-ul nu se punea în discuție. Și cât de mare ar fi fost efortul de implementare și de testare pe toate browser-ele? Realitate: Dezvoltarea s-a oprit din lipsă de buget. Chat-ul era parțial funcțional. Aplicația nu era stabilă, iar efortul necesar testării pe toate configurațiile a condus la decizia de a înceta proiectul.
Doctori
Merg la Medicover cu rezultatul analizelor. Doctorul nu schița nicio grimasă. Între timp îmi sună telefonul și mă duc să-l iau din giacă. Când mă uit mai atent la ecranul doctorului, îl văd cum caută pe google. Când i-am spus că poate n-ar fi rău să revin mai târziu, mi-a spus că nu este nevoie și mi-a propus o rețetă pe care n-am folosit-o niciodată. În câteva zile simptomele mi-au trecut.
Parteneriatele
Chestiunea parteneriatelor în servicii, fie ele medicale sau IT, este foarte delicată. Majoritatea parteneriatelor contravine ideii de a aduce valoare mai multă clienților sau utilizatorilor finali. De exemplu, programul public de parteneriat Microsoft, duce la căutarea de specialiști și de clienți în tehnologiile Microsoft pentru a beneficia de licențe gratuite. Și deși eu nu pot să spun că am simțit presiunea aceasta, sunt convins că există firme care vor fi tentate să-și ghideze soluțiile propuse ca să-și mențină programul. Acesta a fost un exemplu de parteneriat suficient de decuplat, și cred că rareori ajunge să fie unul strategic. Totodată vine și cu anumite beneficii, cel puțin pentru angajații firmei: nevoia permanentă de a forma și de a certifica angajații. Eu cred că problemele mari vin din parteneriatele cuplate puternic, în special acelea care forțează vânzările, însă nu-mi trec exemple prea multe prin cap, în afara celor nescrise.
Parteneriatele nescrise
IT-iști
Există niște legende potrivit cărora multe din firmele de IT care vând software statului sunt corupte. Deși sunt convins că nu se poate generaliza, tind să cred că aceste legende sunt adevărate. Dar revenind la subiectul nostru, în astfel de cazuri nu mai contează expertiza în IT.
Doctori
Mi s-a întâmplat să cunosc un tip responsabil cu vânzările unei companii farmaceutice în zona Moldovei și Munteniei. Misiunea sa era să ducă sistematic doctorii la domnișoare prin Poiana Brașov. De ce? pentru că existau medicamente mult mai bune pe piață, însă acest lucru nu prea contează atât timp cât doctorul îți propune ce vrea el.
La specialist
Problema specialiștilor este că mereu îți vor da un răspuns bazat doar pe experiența lor. Mai sus am dat exemplul cu implementarea unui chat online. Dacă mă duc la un specialist pe tehnologiile Microsoft, îmi va da un răspuns bazându-se pe ceea ce știe. Cel puțin așa sper. Ar fi culmea să-mi explice cum se adresează problemele respective în Cobol. Ceea ce apreciez mai mult la medici față de IT-iști, este că vei fi trimis la un alt specialist dacă problema ta iese din aria de expertiză. Rareori am văzut același reflex sănătos în IT. E drept că nici riscurile nu sunt aceleași.
Corectiv sau preventiv
O diferență fundamentală între cele două domenii este momentul în care clientul merge să fie consultat. Din nefericire, atunci când vine vorba de sănătatea noastră, mergem la doctor pentru că avem deja o problemă. Acesta este și unul din motivele pentru care simt că nu ar trebui să se poată face afaceri din orice.
Specialistul din tine
Cu Olga, am ajuns la concluzia că mai degrabă ne apucăm noi de învățat. Sau măcar să ne asigurăm că cerem mereu părerea mai multor medici. Și poate că de aici vine și neînțelegerea. Ne așteptăm ca medicii să fie atotștiutori și să ne salveze. În realitate, ei sunt niște oameni care fac greșeli ca noi toți ceilalți.
Nu știu de ce, dar am senzația că lumea merge mai des la stomatolog în scopuri preventive decât la alți medici. Iar înainte să-și înceapă orice lucrare, dentistul ne previne și ne cere explicit să luăm o decizie, ceea ce subliniază cine este responsabil și cu ce. Cred că așa ar trebui să fie și în IT. Să ai un minim de cultură generală astfel încât să-ți poți asuma decizia înainte să umbli la trezorerie.
Care este concluzia spuselor de mai sus?
Mă întrebam zilele trecute dacă nu cumva clienții fără cunoștințe generale în IT își asumă niște riscuri mult prea mari intrând în industria software. În niciun caz nu mă gândesc că ar fi de preferat să-și oprească investiția, însă cred că acel generalist trebuie să fie de partea clientului în căutarea unui partener cu care să-și producă software-ul.
Orchestrarea proiectelor IT
Exercițiul de mai sus mi-a adus aminte de articolul gânduri despre furnizorii IT și orchestrarea performanței prin externalizarea Scrum Master-ilor, pentru că am senzația că se repetă și celelalte scenarii posibile. Generalistul este un consultant extern specializat în identificarea celei mai bune soluții sau în construirea ansamblului de elemente necesare apelului de ofertă. Bineînțeles că în acest scenariu, generalistul, ca să aducă un maxim de valoare dar și să suporte consecințele propriilor decizii, acompaniază clientul cel puțin până în faza incipientă a primei livrări.
Și-ar mai fi scenariul ideal în care clientul are cunoștințe bune în IT:
Cât de diferiți sunt consultanții în IT de medici? Gânduri despre furnizorii IT și orchestrarea performanței – partea a doua. Unde este bine să avem consultantul generalist?
Dacă doriți să aflați mai multe despre mine, Cornel Fătulescu, sau proiectele în care sunt implicat, vă invit să mă descoperiți și ca Chief Platform Officer la Pentalog, să mă urmăriți pe Facebook, ca investitor la wanttolearn, să citiți unul dintre primele articole despre mine și să mă contactați urmând ghidul de pe pagina de contact.
Acest articol a fost citit de 1461 ori