De ce proiectele software enterprise eșuează înainte ca dezvoltarea să înceapă măcar

Majoritatea proiectelor software de întreprindere care eșuează nu eșuează din cauza codului prost. Eșuează pentru că a fost construit lucrul greșit. Până când cineva scrie o linie de cod, rezultatul este deja fixat — modelat de deciziile luate în timpul descoperirii, pe care nimeni nu le-a pus sub semnul întrebării suficient de mult.

Acest lucru este inconfortabil, deoarece înseamnă că cele mai costisitoare greșeli se întâmplă atunci când încă pare că totul merge bine. Părțile interesate sunt aliniate. Documentul de cerințe este gros. Furnizorul a fost selectat. Și totuși, în liniște, proiectul se îndreaptă deja către un rezultat care va dezamăgi.

Iluzia clarității

Cea mai periculoasă fază a oricărui proiect de întreprindere este cea care se simte cea mai ordonată: colectarea cerințelor. Echipele organizează ateliere de lucru. Analistii de business produc documente de specificații. Părțile interesate aprobă. Toată lumea este de acord cu ceea ce trebuie construit.

Problema este că acordul nu este același lucru cu înțelegerea. În majoritatea organizațiilor, diferite părți interesate folosesc aceleași cuvinte pentru a însemna lucruri diferite. „Raportare în timp real” înseamnă un lucru pentru CFO și ceva complet diferit pentru echipa de inginerie. „Integrarea cu ERP” ar putea însemna o exportare zilnică în loturi sau un API live cu latență sub o secundă. Aceste ambiguități supraviețuiesc deoarece nimeni nu se simte suficient de în siguranță pentru a încetini lucrurile și a spune: „Stai — ce înțelegem exact prin asta?”

Documentele de cerințe creează un fals sentiment de precizie. Ele descriu caracteristici, nu probleme. Și când începeți cu caracteristici, omiteți pasul care contează cel mai mult: asigurarea că rezolvați problema corectă de la bun început.

Gândire axată pe soluție

Proiectele de întreprindere încep de obicei cu o soluție deja aleasă. Cineva a decis că compania are nevoie de o aplicație mobilă, un portal pentru clienți, un lac de date sau o migrare către cloud. Faza de descoperire devine un exercițiu de justificare a unei decizii care a fost deja luată, mai degrabă decât de a investiga dacă este decizia corectă.

Acest lucru se întâmplă din motive ușor de înțeles. Un lider senior a participat la o conferință. Un concurent a lansat ceva. Un furnizor a oferit o demonstrație convingătoare. Presiunea de a acționa este reală, iar „să studiem asta încă o lună” nu este ceea ce vrea să audă nimeni.

Dar costul omiterii unei încadrări autentice a problemei este enorm. Am văzut organizații care au petrecut optsprezece luni construind un portal orientat către clienți doar pentru a descoperi că blocajul real era un proces intern care ar fi putut fi rezolvat cu o automatizare a fluxului de lucru care costa o fracțiune din efort. Portalul era solid din punct de vedere tehnic. Pur și simplu nu a abordat problema reală.

Dezalinirea părților interesate este structurală, nu personală

În organizațiile mari, dezalinierea dintre părțile interesate nu este un eșec de comunicare — este o realitate structurală. Diferite departamente au stimulente diferite, definiții diferite ale succesului și toleranță diferită la schimbare.

Echipa de vânzări vrea viteză. Finanțele vor predictibilitate. Operațiunile vor stabilitate. IT vrea mentenabilitate. Acestea nu sunt priorități greșite. Sunt constrângeri reale care există în tensiune unele cu altele. Eșecul nu este că aceste tensiuni există, ci că majoritatea proceselor de descoperire pretind că nu există.

Când un proiect începe cu un singur document de cerințe care a fost „aprobat de toate părțile interesate”, ceea ce s-a întâmplat de obicei este că fiecare grup a citit părțile relevante pentru ei și a presupus că restul este problema altcuiva. Șase luni mai târziu, când trebuie făcute compromisuri, dezalinierea iese la iveală ca conflict — iar până atunci, schimbarea direcției este costisitoare.

Ce funcționează de fapt

Proiectele care reușesc tind să împărtășească câteva caracteristici care nu au nimic de-a face cu alegerile tehnologice.

Ele încep prin a defini cum arată succesul în termeni măsurabili.Nu „îmbunătățiți experiența clienților”, ci „reduceți timpul mediu de rezolvare a tichetelor de asistență de la 48 de ore la 8 ore”. Dacă nu îl puteți măsura, nu îl puteți gestiona și cu siguranță nu puteți spune dacă proiectul a adus valoare.

Ele separă validarea problemei de proiectarea soluției.Prima fază ar trebui să producă o înțelegere clară, comună a problemei și a constrângerilor sale — înainte ca cineva să înceapă să deseneze diagrame de arhitectură. Aceasta înseamnă intervievarea utilizatorilor reali, nu doar a managerilor lor. Înseamnă maparea fluxurilor de lucru existente, nu doar documentarea celor aspirative.

Ele scot la iveală dezacordurile devreme și le rezolvă în mod explicit.Acest lucru necesită tipul de facilitare pe care majoritatea organizațiilor îl subestimează. Nu este suficient să puneți părțile interesate într-o cameră. Cineva trebuie să pună întrebările incomode: Ce se întâmplă când termenul limită este depășit? Ce caracteristici tăiem mai întâi? Cine decide?

Ei investesc în prototipuri înainte de a se angaja la o construcție completă.Un prototip funcțional testat cu utilizatori reali în prima lună va dezvălui mai multe despre ceea ce ar trebui să livreze de fapt proiectul decât trei luni de ateliere de cerințe.

Ce înseamnă asta pentru lideri

Dacă sunteți un CEO sau CTO care aprobă o investiție software semnificativă, cea mai importantă întrebare pe care o puteți pune nu este despre tehnologie, furnizor sau cronologie. Este aceasta:Ce problemă rezolvăm și cum vom ști că am rezolvat-o?

Dacă echipa nu poate răspunde la această întrebare clar și specific, proiectul nu este gata să înceapă — indiferent cât de lustruit arată propunerea.

A doua întrebare este:Ne-am testat ipotezele cu persoanele care vor folosi efectiv acest sistem?Nu managerii lor. Nu sponsorii proiectului. Oamenii a căror muncă zilnică se va schimba.

Descoperirea nu este o formalitate. Este faza în care proiectul fie câștigă dreptul de a continua, fie dezvăluie că problema reală este diferită de cea pe care o presupunea toată lumea. Cel mai costisitor proiect software este cel care livrează exact ceea ce a fost specificat — și nu rezolvă nimic.