20 reasons why software projects fail
elk software project begint met grote dromen en grote visies. Ergens in een alternatief universum is er een project dat elke droom vervult, maar maar al te vaak struikelen softwareprojecten in ons universum naar de finishlijn en steken die soms over.
natuurlijk is falen van softwareprojecten per definitie geen binair iets. U kunt eindigen met code die goed loopt, maar niemand gebruikt. Of je kunt eindigen met code die niet eens compileert. Soms kun je iets nuttigs redden uit het brandende wrak en soms is het het beste om weg te lopen voordat het ontploft.
wanneer de smeulende puinhoop afkoelt, beginnen de autopsies, omdat mensen willen weten wat er mis ging. Hier zijn de meest voorkomende daders.
te weinig teamleden
te veel proberen te doen met te weinig programmeurs is een veel voorkomend probleem. Ontwikkelaars kunnen alleen maar slijpen zoveel code voordat ze burn-out. Ik heb ooit gewerkt aan een team waar de manager dacht dat de juiste manier om meer werk te persen van agile teams is om elke “sprint” te plannen, dus het begon onmiddellijk na de vorige. Sprint 42 eindigde woensdag om 13: 59 uur en Sprint 43 begon woensdag om 14: 00 uur. Nadat de volgende sprint al was begonnen, waren er bijeenkomsten voor retrospectieve analyse gepland. Een slimme man stelde voor dat ze werden omgedoopt tot “marathons” en al snel vond een andere baan.
natuurlijk is het moeilijk om te weten hoeveel programmeurs genoeg zijn. Soms staan wegversperringen en problemen in de weg. Het is misschien niet de schuld van de manager dat de baan verdubbelt in omvang, maar als je niet genoeg mensen op het werk, uw project is waarschijnlijk gedoemd.
te veel teamleden
als te weinig programmeurs slecht kunnen zijn, kunnen te veel mogelijk slechter zijn, omdat netwerkeffecten een softwareproject kunnen doomenâ. Meer mensen betekent meer coördinatie en dat betekent meer vergaderingen, waardoor het tijd kost om code te schrijven. Maar als je niet genoeg vergaderingen te houden, zult u snel ontdekken Team A API niet interface Team B ‘ s microservices.
het zou leuk zijn als we gewoon geld konden gooien naar een probleem door overbezetting van een project, maar dat kan niet.
te veel communicatie
software schrijven is een solitaire kunst. Mensen kunnen samenwerken, maar alleen in beperkte periodes. Veel ontwikkelaars haten vergaderingen omdat ze hun mentale versnellingen moeten verschuiven van de diepe, meeslepende logische gedachte naar de meer open, sociale modus. Dit kost tijd. Sommige teamleiders proberen falen te bestrijden door meer vergaderingen te houden om iedereen gesynchroniseerd te houden. Het is een nobele inspanning, maar je hoort de tandwielen slijpen. Het team moet genoeg informatie delen om gesynchroniseerd te blijven, maar meer verspilt hersencycli.
fundamentele feature changes
in theorie beschouwen ontwikkelaars zichzelf graag als agile. Daarom omarmen ze het woord. Maar soms kan Behendigheid iedereen uit balans brengen. Het hangt allemaal af of de verschuiving fundamentele veranderingen in het onderliggende kader vereist. Het is gemakkelijk om wendbaar te zijn bij het verplaatsen van een knop of het veranderen van een kleur. Maar als het gaat om het herwerken van de database schema of mucking rond met sharding en replicatie, er is geen gemakkelijke manier om sierlijk draaien.
het kiezen van de verkeerde technologie voor de taak
zelfs als u zorgvuldig plant en de juiste lijst met functies opstelt, kunnen dingen mislukken als u de verkeerde technologie gebruikt. Databases zijn bijvoorbeeld ontworpen om algemeen en flexibel te zijn, maar hebben wel architectonische beperkingen. Push hen om iets te leveren ze zijn niet ontworpen om te doen, en ze zullen vertragen tot een virtuele stilstand wanneer gevraagd om Schaal. Of u kunt beginnen met een NoSQL-database, omdat ze cool klinken alleen om later te ontdekken dat je echt nodig hebt ACID-grade transacties om dingen consistent te houden en de database biedt ze niet. Oeps.
slechte prioritering
goede planners stellen een lijst van functies op en geven deze prioriteit. Maar soms komen prioriteiten niet overeen met de realiteit van de uitvoering ervan. In het ergste geval zijn de belangrijkste functies het moeilijkst te creëren.
Wat moeten uw ontwikkelaars doen? Als ze zich concentreren op de belangrijkste functie, zullen ze geen vooruitgang boeken en kan uiteindelijk het leveren van geen van de functionaliteit. Maar als ze beginnen met het uitschakelen van de gemakkelijke, kunnen ze eindigen met iets dat waardeloos is.
goede planning vereist meer dan een checklist. Bij een architectonische visie moet rekening worden gehouden met de behoeften en de kosten van de uitvoering ervan.
het marktvenster sluit
soms is het niet de fout van de programmeur. Een van mijn projecten was om van een bestseller naslagwerk een app te maken. Het boek verkocht als hotcakes in de jaren voor het internet. Het plan was om die vraag aan te boren en een interactieve versie te maken waarmee mensen de gegevens konden sorteren en doorzoeken. Het programmeerteam leverde software die alles in het boek bevatte, maar sneller, mooier en veel lichter was dan het boek zelf. Maar niemand wilde het meer. Er waren genoeg andere bronnen en niemand had een andere app nodig die veel hetzelfde deed als nieuwssites overal doen.
soms lijkt een idee geweldig, maar de markt is verder gegaan.
slechte architectuurbeslissingen
bij één project kreeg ik de taak één nummer op één rij in de database te veranderen. Toen de gebruiker klaar was met registreren, moest ik het id-nummer van de gebruiker toevoegen aan de laatste bestelling. Klinkt simpel, toch? Maar het systeem is gebouwd op een microservices architectuur en ik kon dit niet oplossen door het schrijven van een regel code die de database zou vertellen om die kolom bij te werken. Nope. Het architecturale plan was om een nieuwe microservice call toe te voegen aan de bestaande stack en zelfs dit was moeilijk omdat mijn eerste microservice call nodig had om een andere microservice call en ga zo maar door.
uiteindelijk vertelde de architecturale whiz die dit netwerk van microservices creëerde me dat het allemaal heel eenvoudig was en een kronkelig pad schetste door vijf lagen van de architectuur. Mijn taak was om vijf nieuwe API-oproepen toe te voegen aan vijf verschillende microservices, wat ook betekende het toevoegen van vijf sets van geautomatiseerde tests voor elke laag. Elke API werd door de jaren heen door een ander team ontwikkeld, waarbij ik vijf verschillende stijlen van codering moest begrijpen en nadoen. Allemaal om één nummer te veranderen.
architecturale beslissingen kunnen een leven lang duren-vooral als je ego er grondig in is geïnvesteerd en je ze niet kunt veranderen. Projectmanagers moeten klaar staan om op te merken wanneer het hoofdarchitectuurplan niet werkt, zodat grote beslissingen kunnen worden genomen.
politieke conflicten
politieke factoren de schuld geven van een technische storing lijkt misschien zwak, maar het is steeds meer waar. Naarmate projecten groter worden en meerdere organisaties overspannen, zou het geen verrassing moeten zijn dat facties verschijnen en groepen jockey voor controle, middelen en uiteindelijk macht.
politieke fracties verschillen van echte technische verschillen. Er zijn vaak technische normen of code bases die veel hetzelfde doen op verschillende manieren. Neem XML en JSON. Nu ik dat heb getypt, kan ik de fans van beide haasten om uit te leggen waarom ze niet hetzelfde zijn en hun favoriete keuze is de juiste. Maar als een deel van een team van de ene keuze houdt en een ander de concurrerende factie in de hoogste achting houdt, nou, wrijving zal ze uit elkaar scheuren.
dit komt nog vaker voor doordat architecten applicaties opsplitsen in meerdere, kleinere diensten en API ‘ s. Verschillende groepen zullen deze uiteindelijk controleren en ze zullen niet altijd met elkaar overweg kunnen. Als groep A JSON leuk vindt en groep B zich vastklampt aan XML, moet je team beide implementeren of een van hen laten veranderen. Alle drie zijn een pijn voor elk team dat moet werken met zowel Groep A en groep B.
wedden op technologie die niet klaar is voor productie
programmeurs houden van de nieuwste tools en frameworks. Ze willen geloven dat de nieuwe aanpak alle cruft wegvaagt die de vorige generatie verzengt.
maar vaak is de volgende generatie niet klaar voor productie. De nieuwe functies lijken misschien perfect, maar er zijn vaak gaten die niet meteen duidelijk zijn. Soms ondersteunt de code slechts een paar bestandstypen of interfaces met slechts een paar databases. De anderen komen binnenkort, ze verzekeren u, maar uw project moet deze maand verzenden en” binnenkort ” kan betekenen zes of meer maanden voordat de functies die u nodig hebt zijn voltooid.
wedden op technologie die binnenkort verouderd is
in mijn ervaring is het oude materiaal meestal betrouwbaarder en getest, maar dat betekent niet dat oude technologie perfect is. Functies kunnen ontbreken die van vitaal belang zijn voor uw softwareproject zodra het live gaat. Erger nog, wedden op oude tech kan ervoor zorgen dat u te missen op toekomstige kansen op basis van veranderingen langs de lijn. Nieuwe ideeën, protocollen en bestandsformaten verschijnen, en ze kunnen niet worden geïmplementeerd. En als iemand van een concurrerend team erop staat dat je een nieuw protocol steunt dan zal de oude technologie pijn doen.
onrealistische deadlines
Deadlines zijn lastig. Veel projecten moeten het op de markt te maken door een bepaald seizoen of evenement. Maar wanneer deadlines voor het eerst worden opgeschreven, zijn uw ontwikkelaars nog niet begonnen met het ontdekken van de wegblokkades en hindernissen in hun weg. Dan als het project glijdt en het evenement voorbij gaat zonder dat de software wordt gelanceerd, wordt het hele project gezien als een mislukking, zelfs als de code op het punt staat om soepel te lopen. Deadlines helpen iedereen zich te concentreren en samen te trekken, maar ze creëren ook verwachtingen die onrealistisch kunnen zijn.
onvoorziene concurrentie
een goede productmanager onderzoekt de concurrentie alvorens in te duiken, maar niemand kan voorspellen welke concurrentie uit het niets kan verschijnen. Als nieuwe concurrenten nieuwe functies introduceren die u moet dupliceren, goed, zie de secties over functiewijzigingen en prioriteit mismatches, hierboven.
het proces versnellen
veel softwareprojecten starten als de visie van een persoon of team die iets wil repareren. Ze komen met een zin als “Snapchat voor Y” of “Uber voor Y” en dan verwachten dat het productteam zo responsief als Snapchat of Uber. Het probleem is dat het uitzoeken van de omvang van het project, het schetsen van de gegevensstromen en het verbeelden van de UI zijn vaak tien keer zoveel werk als het schrijven van de code. Maar de imagineers willen meteen van idee naar code.
de wireframes, databaseschema ‘ s en gebruikersverhalen zijn niet alleen handzwaai, maar een essentieel onderdeel van de taak. Maar de meeste mensen willen geloven dat een software project is gewoon het schrijven van code om een idee te implementeren.
vals geloof in de kracht van software
dromers hebben vaak onrealistische overtuigingen in de kracht van software om de wereld te veranderen. Velen dachten dat sociale media ons zouden verenigen, maar op de een of andere manier zijn er gewoon breuklijnen blootgelegd die altijd duidelijk waren. Software projecten beginnen vaak met dia decks die beloven om een revolutie in een aantal uithoeken van de wereld. Als het duwen van bits in een database niemand transformeert, nou, mensen worden boos, verveeld, verward of erger. Ze zeggen dat de software kapot is omdat het niet in slaagt om de magische transformatie te leveren die iedereen verwachtte.
veel softwareprojecten kunnen QA compileren, doorgeven, verzenden en zelfs fatsoenlijke beoordelingen krijgen, maar uiteindelijk slagen ze er niet in om een van de beloften op het slide deck te bereiken omdat, nou ja, die change-the-world Beloften onmogelijk zijn.
Evil subcontractors
we houden van de leveranciers die de bibliotheken en tools produceren die ons in staat stellen magie te creëren met slechts een paar regels code. Af en toe krijgen ze lucht van hun kracht en gebruiken het om een project te vernietigen. Het budget sheet Voor Versie 1.0 was zo goed dat het management niet aarzelde om Versie 2.0 goed te keuren. Dan besluit de verkoper ons te knijpen door de prijs te verdrievoudigen of te vervijfvoudigen.
dit effect kan zelfs worden gevoeld wanneer de verkopers het niet expres doen. Kosteloos tiers kan een project kijken erg goedkoop. Dan wanneer de vraag stijgt en de tweede versie breidt de vraag, de echte prijzen kick in.
grote verandering
In een jaar met pandemieën en protesten is niets sneller veranderd dan de tijdgeest. Heeft het project sterke privacybescherming centraal gesteld? Whoop. De pandemie heeft iedereen geïnteresseerd gemaakt in het traceren van contacten. Wil iemand zich concentreren op zakenreizen? Whoop. De hotelindustrie is ingestort. Grotere softwareprojecten die een jaar of langer kunnen duren, lopen het risico om te worden opgeschroefd door catastrofale gebeurtenissen. Wat in het begin een geweldig idee leek kan hopeloos verloren en afgesloten lijken als het tijd is om live te gaan.
technische verschuivingen
het zijn niet alleen veranderingen in de wereld als geheel. Getijdenveranderingen in de tech-gemeenschap kunnen hetzelfde effect hebben. NoSQL was ooit een geniaal idee dat ons zou bevrijden van relationele schema. Toen realiseerde iemand zich dat de bestanden opzwellen omdat elke plaat een lokaal schema bevatte. Een goed agile ontwikkelingsteam kan verschuiven wanneer technologische veranderingen de houding van het leiderschap en de klanten veranderen. Maar zelfs de meest wendbare teams kunnen niet omgaan met grote verschuivingen die alle lucht uit hun architectonische plannen zuigen. Het systeem werd gebouwd in de veronderstelling dat X was een geweldig idee en plotseling X is vuil. Soms is het het beste om het op te blazen en weer een ster te worden.
te veel toevoegingen
sommige softwareprojecten starten goed en zelfs succesvol. Dan voegt iemand een extra functie of drie, enten nieuwe code op de bestaande versie op een manier dat de code blijft lopen langs. Heldhaftige ontwikkelaars kunnen dit meerdere keren doen, vooral als de oorspronkelijke architect goed gepland heeft. Maar op een gegeven moment, de fundering afbrokkelt. Misschien kan de database de lading niet aan. Misschien zijn er te veel JOINs nodig om de verschillende vragen te voldoen. Goede software kan te dik worden, soms dankzij kleine verbeteringen die het over de rand duwde.
Moving goal posts
de initiële plannen vroegen om een database om de uitgaven van klanten bij te houden om te helpen met marketingplannen. Toen voegde een genie een functie toe die kunstmatige intelligentie gebruikt om uitgaven te correleren met de weersvoorspelling. Of iemand anders wilde dat de software automatisch bood op zoekmachineadvertenties. Het veranderen van de bestemming kan een project upend.
het is zeldzaam dat de veranderingen dingen op zichzelf verpesten. Maar nieuwe doelen kunnen zwakheden blootleggen en storingsmodi activeren. Misschien is het team nu te klein om het project succesvol te voltooien. Misschien zijn de technische fundamenten erg inefficiënt voor de nieuwe aanpak. Het is moeilijk voor iedereen om te anticiperen op de fretful combinatorics wanneer de beslissing wordt genomen om de doelen te veranderen.