20 motive pentru care proiectele software eșuează
fiecare proiect software începe cu vise mari și viziuni mărețe. Undeva într-un univers alternativ, există un proiect care îndeplinește fiecare vis, dar prea des proiectele software din universul nostru se împiedică spre linia de sosire și uneori îl traversează.
desigur, prin definiție, eșecul proiectului software nu este un lucru binar. Puteți termina cu un cod care rulează bine, dar nimeni nu folosește. Sau puteți termina cu un cod care nici măcar nu va compila. Uneori puteți salva ceva util din epava în flăcări și alteori este mai bine să fugiți înainte să explodeze.
când mizeria mocnită se răcește, încep autopsiile, deoarece oamenii vor să știe ce a mers prost. Iată cei mai comuni vinovați.
prea puțini membri ai echipei
încercarea de a face prea mult cu prea puțini programatori este o problemă obișnuită. Dezvoltatorii pot șterge atât de mult cod înainte de a se arde. Am lucrat odată la o echipă în care managerul a crezut că modul corect de a stoarce mai multă muncă de la echipele agile este de a programa fiecare „sprint”, așa că a început imediat după cel precedent. Nicio pauză atentă pentru a afla ce funcționa și ce nu. Sprint 42 s-a încheiat miercuri la 1:59pm, iar Sprint 43 a început miercuri la 2:00pm. Întâlnirile de analiză retrospectivă au fost programate după începerea următorului sprint. Un tip inteligent a sugerat să fie redenumit” maratoane ” și în curând a găsit un alt loc de muncă.
desigur, este greu de știut câți programatori sunt suficienți. Uneori, blocajele rutiere și problemele stau în cale. Este posibil să nu fie vina managerului că locul de muncă își dublează dimensiunea, dar dacă nu aveți suficienți oameni la locul de muncă, proiectul dvs. este probabil sortit.
prea mulți membri ai echipei
dacă prea puțini programatori pot fi răi, prea mulți ar putea fi mai răi, deoarece efectele de rețea pot distruge un proiect software. Mai mulți oameni înseamnă mai multă coordonare și asta înseamnă mai multe întâlniri, luând timp departe de scrierea codului. Dar dacă nu țineți suficiente întâlniri, veți descoperi în curând API-ul echipei a nu Interfață microserviciile echipei B.
ar fi frumos dacă am putea arunca doar bani la o problemă de overstaffing un proiect, dar nu se poate.
prea mult de comunicare
scris software-ul este o artă solitară. Oamenii pot lucra împreună, dar numai în crize limitate. Mulți dezvoltatori urăsc întâlnirile, deoarece trebuie să-și schimbe uneltele mentale de la gândirea logică profundă imersivă în modul mai deschis, social. Acest lucru necesită timp. Unii lideri de echipă încearcă să lupte împotriva eșecului organizând mai multe întâlniri pentru a-i menține pe toți sincronizați. Este un efort nobil, dar puteți auzi angrenajele măcinând. Echipa trebuie să împărtășească suficiente informații pentru a rămâne sincronizate, dar orice mai pierde doar ciclurile creierului.
schimbări fundamentale ale caracteristicilor
în teorie, dezvoltatorilor le place să se considere agili. De aceea îmbrățișează cuvântul. Dar, uneori, agilitatea poate arunca pe toată lumea în afara echilibrului. Totul depinde dacă schimbarea necesită modificări fundamentale ale cadrului de bază. Este ușor să fii agil atunci când miști un buton sau schimbi o culoare. Dar când implică refacerea schemei bazei de date sau înfundarea cu sharding și replicare, nu există o modalitate ușoară de a pivota grațios.
alegerea tehnologiei greșite pentru lucrare
chiar dacă planificați cu atenție și întocmiți lista corectă de caracteristici, lucrurile pot eșua dacă utilizați tehnologia greșită. Bazele de date, de exemplu, sunt concepute pentru a fi generale și flexibile, dar au limitări arhitecturale. Împingeți-i să livreze ceva ce nu sunt proiectați să facă și vor încetini la o oprire virtuală atunci când li se va cere să se scaleze. Sau puteți începe cu o bază de date NoSQL, deoarece sună cool doar pentru a descoperi mai târziu că aveți cu adevărat nevoie de tranzacții de calitate acidă pentru a menține lucrurile consecvente și baza de date nu le oferă. Hopa.
prioritizare slabă
planificatorii buni întocmesc o listă de caracteristici și le acordă prioritate. Dar, uneori, prioritățile nu se aliniază realității implementării lor. În cele mai grave cazuri, cele mai importante caracteristici sunt cele mai greu de creat.
ce trebuie să facă dezvoltatorii tăi? Dacă se concentrează pe cea mai importantă caracteristică, nu vor face progrese și pot ajunge să nu ofere nicio funcționalitate. Dar dacă încep să-i bată pe cei ușori, s-ar putea să ajungă la ceva lipsit de valoare.
o bună planificare necesită mai mult decât o listă de verificare. Viziunea arhitecturală trebuie să țină seama de nevoile și costurile livrării acestora.
fereastra de piață se închide
uneori nu este vina programatorului. Unul dintre proiectele mele a fost să transform o carte de referință best-seller într-o aplicație. Cartea s-a vândut ca niște prăjituri fierbinți în anii dinaintea Internetului. Planul a fost de a atinge această cerere și de a face o versiune interactivă care să permită oamenilor să sorteze și să caute prin date. Echipa de programare a livrat software care a inclus totul în carte, dar a fost mai rapid, mai frumos și mult mai ușor decât cartea în sine. Dar nimeni nu a mai vrut-o. Au existat suficiente alte surse și nimeni nu avea nevoie de o altă aplicație care să facă același lucru ca și site-urile de știri de pretutindeni.
uneori o idee pare grozavă, dar piața a mers mai departe.
decizii arhitecturale proaste
la un proiect, mi s-a dat sarcina de a schimba un număr într-un rând în baza de date. Când utilizatorul a terminat înregistrarea, trebuia să adaug numărul de identificare al utilizatorului la cea mai recentă comandă. Sună simplu, nu? Dar sistemul a fost construit pe o arhitectură microservices și nu am putut rezolva acest lucru scriind o linie de cod care să spună bazei de date să actualizeze acea coloană. Nu. Planul arhitectural a fost de a adăuga un nou apel microservice la stiva existentă și chiar acest lucru a fost greu, deoarece primul meu apel microservice necesar pentru a declanșa un alt apel microservice și așa mai departe.
în cele din urmă, fluierul arhitectural care a creat această rețea de microservicii mi-a spus că totul este foarte simplu și a conturat o cale serpentină prin cinci straturi ale arhitecturii. Treaba mea a fost să adaug cinci noi apeluri API la cinci microservicii diferite, ceea ce a însemnat și adăugarea a cinci seturi de teste automate pentru fiecare strat. Și fiecare API a fost dezvoltat de o echipă diferită de-a lungul anilor, cerându-mi să înțeleg și să imit cinci stiluri diferite de codificare. Toate pentru a schimba un număr.
deciziile arhitecturale pot dura o viață — mai ales dacă ego-ul tău este investit temeinic în ele și nu le poți schimba. Managerii de proiect trebuie să fie gata să observe când planul arhitectural principal nu funcționează, astfel încât să poată fi luate decizii mari.
conflictele politice
Blamarea factorilor politici pentru o defecțiune tehnică poate părea nevăstuică, dar este din ce în ce mai adevărat. Pe măsură ce proiectele cresc și acoperă mai multe organizații, nu ar trebui să fie o surpriză faptul că apar facțiuni și grupuri jockey pentru control, resurse și, în cele din urmă, putere.
fracțiunile politice sunt diferite de diferențele tehnice reale. Există adesea standarde tehnice sau baze de cod care fac același lucru în moduri diferite. Ia XML și JSON. Acum că am scris asta, simt fanii fie se grăbesc să explice de ce nu sunt la fel și alegerea lor preferată este cea potrivită. Dar când o parte a unei echipe iubește o alegere și alta ține fracțiunea concurentă în cea mai mare considerație, Ei bine, fricțiunea îi va sfâșia.
acest lucru a devenit și mai frecvent pe măsură ce arhitecții împart aplicațiile în mai multe servicii și API-uri mai mici. Diferite grupuri vor ajunge să le controleze și nu se vor înțelege întotdeauna. Dacă grupului A îi place JSON și grupului B se agață de XML, Ei bine, echipa dvs. va trebui fie să le implementeze pe ambele, fie să le schimbe pe una dintre ele. Toate cele trei sunt o durere pentru orice echipă care trebuie să lucreze atât cu grupa A, cât și cu grupa B.
pariuri pe tehnologie care nu este pregătită pentru producție
programatorii adoră cele mai noi instrumente și cadre. Ei vor să creadă că noua abordare va îndepărta toată cruftul care împiedică generația anterioară.
dar de multe ori, următoarea generație nu este pregătită pentru utilizare în producție. Noile caracteristici pot părea perfecte, dar există adesea lacune care nu sunt imediat evidente. Uneori, codul acceptă doar câteva tipuri de fișiere sau interfețe cu doar câteva baze de date. Ceilalți vin în curând, vă asigură, dar proiectul dvs. trebuie să fie livrat luna aceasta și „în curând” ar putea însemna șase sau mai multe luni înainte ca funcțiile de care aveți nevoie să fie complete.
pariuri pe tehnologie care va fi în curând depășită
din experiența mea, lucrurile vechi sunt de obicei mai fiabile și testate în luptă, dar asta nu înseamnă că tehnologia veche este perfectă. Caracteristici pot fi lipsesc, care sunt vitale pentru proiectul software-ul odată ce merge direct. Mai rău, pariurile pe tehnologia veche vă pot determina să pierdeți oportunitățile viitoare bazate pe schimbări pe linie. Apar noi idei, protocoale și formate de fișiere și pot fi neimplementate. Și dacă cineva dintr-o echipă concurentă insistă să susțineți un nou protocol, atunci vechea tehnologie va răni.
termene nerealiste
termene sunt dificile. Multe proiecte trebuie să ajungă pe piață după un anumit sezon sau eveniment. Cu toate acestea, atunci când termenele limită sunt scrise pentru prima dată, dezvoltatorii dvs. nu au început să descopere obstacolele și obstacolele din calea lor. Apoi, dacă proiectul alunecă și evenimentul trece fără ca software-ul să fie lansat, întregul proiect este văzut ca un eșec, chiar dacă codul este pe cale să ruleze fără probleme. Termenele limită îi ajută pe toți să se concentreze și să se unească, dar creează și așteptări care pot fi nerealiste.
concurență neprevăzută
un bun manager de produs studiază concurența înainte de a se scufunda, dar nimeni nu poate prezice ce concurență poate apărea de nicăieri. Dacă noii concurenți introduc noi caracteristici pe care trebuie să le duplicați, consultați secțiunile privind modificările caracteristicilor și nepotrivirile de prioritate, de mai sus.
grăbirea procesului
multe proiecte software încep ca viziunea unei persoane sau a unei echipe care dorește să repare ceva. Ei vin cu o frază precum „Snapchat pentru Y” sau „Uber pentru Y” și apoi se așteaptă ca echipa de produse să fie la fel de receptivă ca Snapchat sau Uber. Problema este că imaginind domeniul de aplicare al proiectului, schițarea fluxurilor de date și imaginarea UI sunt adesea de zece ori mai multă muncă decât scrierea codului. Dar imaginarii vor să treacă imediat de la idee la cod.
wireframes, schema bazei de date și poveștile utilizatorilor nu sunt doar fluturarea mâinilor, ci o parte esențială a lucrării. Dar majoritatea oamenilor vor să creadă că un proiect software scrie doar cod pentru a implementa o idee.
credința falsă în puterea software-ului
visătorii au adesea credințe nerealiste în puterea software-ului de a schimba lumea. Mulți și-au imaginat că social media ne va uni, dar cumva sunt doar expuse linii de eroare care erau întotdeauna evidente. Proiectele Software încep adesea cu punți de diapozitive care promit să revoluționeze un colț al lumii. Când împingerea de biți într-o bază de date nu transformă pe nimeni, ei bine, oamenii se enervează, se plictisesc, se confundă sau mai rău. Ei spun că software-ul este rupt, deoarece nu reușește să livreze transformarea magică pe care toată lumea o aștepta.
multe proiecte software pot compila, transmite AC, Livra și chiar obține recenzii decente, dar în cele din urmă nu reușesc să realizeze niciuna dintre promisiunile de pe puntea de diapozitive, deoarece, ei bine, acele promisiuni de schimbare a lumii sunt imposibile.
subcontractori răi
ne plac vânzătorii care produc bibliotecile și instrumentele care ne permit să creăm magie cu doar câteva linii de cod. Ocazional, ei obține vânt de puterea lor și să-l utilizați pentru a distruge un proiect. Foaia de buget pentru versiunea 1.0 a fost atât de bună încât conducerea nu a ezitat să aprobe versiunea 2.0. Apoi vânzătorul decide să ne stoarcă prin triplarea sau cvintuplarea prețului.
acest efect poate fi simțit chiar și atunci când vânzătorii nu o fac intenționat. Nivelurile gratuite pot face ca un proiect să pară foarte ieftin. Apoi, când cererea crește și a doua versiune extinde cererea, prețurile reale intră.
schimbarea Mării
într-un an cu pandemii și proteste, nimic nu s-a schimbat mai repede decât zeitgeistul. Proiectul a făcut din protecția puternică a confidențialității o caracteristică centrală? Hopa. Pandemia A făcut pe toată lumea interesată de urmărirea contactelor. A vrut cineva să se concentreze pe călătoriile de afaceri? Hopa. Industria hotelieră s-a prăbușit. Proiectele software mai mari care pot dura un an sau mai mult riscă să fie răsturnate de evenimente cataclismice. Ceea ce părea o idee minunată la început poate părea pierdut și deconectat fără speranță atunci când este timpul să mergem în direct.
schimbări tehnice
nu sunt doar schimbări în lume în general. Schimbările de maree în comunitatea tehnologică pot avea același efect. NoSQL a fost odată o idee genială care ne-ar elibera de schema relațională. Apoi cineva și-a dat seama că fișierele se umflă pentru că fiecare înregistrare avea o schemă locală. O echipă bună de dezvoltare agilă se poate schimba atunci când schimbările tehnologice ale mării schimbă atitudinile conducerii și ale clienților. Dar chiar și cele mai agile Echipe nu pot face față schimbărilor mari care aspiră tot aerul din planurile lor arhitecturale. Sistemul a fost construit presupunând că X a fost o idee grozavă și brusc X este murdărie. Uneori este mai bine să-l arunce în aer și stele din nou.
prea multe adăugiri
unele proiecte software încep bine și chiar expediază cu succes. Apoi, cineva adaugă o caracteristică suplimentară sau trei, altoire nou cod pe versiunea existentă într-un mod care codul continuă să șchiopăteze de-a lungul. Dezvoltatorii eroici pot scoate acest lucru de mai multe ori, mai ales dacă arhitectul inițial a planificat bine. Dar, la un moment dat, Fundația se prăbușește. Poate că baza de date nu se poate ocupa de sarcină. Poate că există prea multe se alătură necesare pentru a satisface diverse interogări. Software-ul bun poate deveni prea gras, uneori datorită îmbunătățirilor mici care l-au împins peste margine.
mutarea posturilor de obiectiv
planurile inițiale au solicitat o bază de date pentru a urmări cheltuielile clienților pentru a ajuta la planurile de marketing. Apoi, un geniu a adăugat o caracteristică care folosește inteligența artificială pentru a corela cheltuielile cu prognoza meteo. Sau altcineva a vrut software-ul pentru a licita automat pentru anunțuri motor de căutare. Schimbarea destinației poate upend un proiect.
este rar ca schimbările să strice lucrurile pe cont propriu. Dar noile obiective pot dezvălui punctele slabe și pot declanșa moduri de eșec. Poate că echipa este acum prea mică pentru a finaliza cu succes proiectul. Poate că fundațiile tehnice sunt extrem de ineficiente pentru noua abordare. Este greu pentru toată lumea să anticipeze combinatorica nervoasă atunci când se ia decizia de a schimba obiectivele.