20 grunner til at programvareprosjekter mislykkes
hvert programvareprosjekt begynner med store drømmer og store visjoner. Et sted i et alternativt univers er det et prosjekt som oppfyller hver drøm, men altfor ofte snubler programvareprosjekter i vårt univers mot målstreken og noen ganger krysser den.
selvfølgelig er programvareprosjektfeil per definisjon ikke en binær ting. Du kan ende opp med kode som går bra, men ingen bruker. Eller du kan ende opp med kode som ikke engang kompilerer. Noen ganger kan du redde noe nyttig fra det flammende vraket, og noen ganger er det best å løpe bort før det eksploderer.
når ulmende rotet kjøler, obduksjoner begynne, som folk ønsker å vite hva som gikk galt. Her er de vanligste synderne.
For få teammedlemmer
Å prøve å gjøre for mye med for få programmerere Er et vanlig problem. Utviklere kan bare slipe ut så mye kode før de brenner ut. Jeg jobbet en gang på et lag der lederen trodde den riktige måten å presse mer arbeid fra smidige lag er å planlegge hver «sprint», så det begynte umiddelbart etter den forrige. Ingen gjennomtenkte pauser for å finne ut hva som fungerte og hva som ikke var. Sprint 42 endte onsdag på 1: 59pm og Sprint 43 begynte onsdag på 2: 00pm. Retrospektive analysemøter ble planlagt etter at neste sprint allerede startet. Noen smarte fyr foreslo at de ble omdøpt «maraton» og snart fant en annen jobb.
selvfølgelig er det vanskelig å vite hvor mange programmerere som er nok. Noen ganger kommer veisperringer og problemer i veien. Det kan ikke være lederens feil at jobben dobler i størrelse, men hvis du ikke har nok folk på jobben, er prosjektet sannsynligvis dømt.
For Mange teammedlemmer
hvis for få programmerere kan være dårlige, kan for mange potensielt være verre, da nettverkseffekter kan dømme et programvareprosjekt. Flere mennesker betyr mer koordinering, og det betyr flere møter, tar tid borte fra å skrive kode. Men hvis Du ikke holder nok møter, vil du snart oppdage At Team A ‘S API ikke grensesnitt Team B’ s microservices.
det ville være fint om vi bare kunne kaste penger på et problem ved å overstaffing et prosjekt, men du kan ikke.
For mye kommunikasjon
Skrive programvare er en ensom kunst. Mennesker kan jobbe sammen, men bare i begrensede anfall. Mange utviklere hater møter fordi de trenger å skifte sine mentale gir fra den dype nedsenkende logiske tanken til den mer åpne, sosiale modusen. Dette tar tid. Noen teamledere prøver å bekjempe feil ved å holde flere møter for å holde alle synkronisert. Det er en edel innsats, men du kan høre girene sliping. Teamet trenger å dele nok informasjon til å holde seg synkronisert, men mer sløser bare hjernesykluser.
Grunnleggende funksjonsendringer
i teorien liker utviklere å betrakte seg smidig. Det er derfor de omfavner ordet. Men noen ganger smidighet kan kaste alle ut av balanse. Alt avhenger av om skiftet krever grunnleggende endringer i det underliggende rammeverket. Det er lett å være smidig når du flytter en knapp rundt eller endrer en farge. Men når det innebærer å omarbeide databaseskjemaet eller rote rundt med sharding og replikering, er det ingen enkel måte å grasiøst svinge på.
Plukke feil teknologi for jobben
selv om du planlegger nøye og utarbeide riktig liste over funksjoner, kan ting mislykkes hvis du bruker feil teknologi. Databaser, for eksempel, er utformet for å være generelle og fleksible, men har arkitektoniske begrensninger. Skyv dem til å levere noe de ikke er laget for å gjøre, og de vil sakte til en virtuell stopp når de blir bedt om å skalere. Eller du kan starte Med En nosql database fordi de høres kult bare for å oppdage senere at du virkelig trenger SYRE-grade transaksjoner for å holde ting konsekvent og databasen ikke tilbyr dem. Oops.
Dårlig prioritering
Gode planleggere utarbeider en liste over funksjoner og prioriterer dem. Men noen ganger prioriteringer ikke på linje med virkeligheten av å implementere dem. I verste fall er de viktigste funksjonene de vanskeligste å skape.
Hva skal utviklerne gjøre? Hvis de konsentrerer seg om den viktigste funksjonen, vil de ikke gjøre noen fremgang og kan ende opp med å levere ingen av funksjonaliteten. Men hvis de begynner å slå av de enkle, kan de ende opp med noe som er verdiløst.
God planlegging krever mer enn en sjekkliste. Arkitektonisk visjon må ta hensyn til behovene og kostnadene ved å levere dem.
markedet vinduet lukkes
Noen ganger er det ikke programmererens feil. En av mine prosjekter var å slå en bestselgende referanse bok til en app. Boken solgte som hotcakes i årene før internett. Planen var å benytte seg av den etterspørselen og lage en interaktiv versjon som ville la folk sortere og søke gjennom dataene. Programmeringsteamet leverte programvare som inkluderte alt i boken, men var raskere, penere og mye lettere enn selve boken. Men ingen ville ha det lenger. Det var nok andre kilder, og ingen trengte en annen app som gjorde mye det samme som nyhetssider gjør overalt.
noen ganger virker en ide bra, men markedet har gått videre.
Dårlige arkitektoniske beslutninger
på ett prosjekt fikk jeg jobben med å endre ett nummer i en rad i databasen. Når brukeren var ferdig med å registrere, skulle jeg legge til brukerens id-nummer i den siste bestillingen. Høres enkelt, ikke sant? Men systemet ble bygget på en mikrotjenestearkitektur, og jeg kunne ikke løse dette ved å skrive en linje med kode som ville fortelle databasen Å OPPDATERE den kolonnen. Niks. Den arkitektoniske planen var å legge til et nytt mikroserviceanrop til den eksisterende stakken, og selv dette var vanskelig fordi mitt første mikroserviceanrop trengte å utløse et annet mikroserviceanrop og så videre.
til slutt fortalte den arkitektoniske whizen som skapte dette nettverket av mikrotjenester meg at det var veldig enkelt og skissert en serpentin sti gjennom fem lag av arkitekturen. Min jobb var å legge til fem NYE API-kall til fem forskjellige mikrotjenester, noe som også innebar å legge til fem sett med automatiserte tester for hvert lag. OG HVER API ble utviklet av et annet team gjennom årene, krever meg å forstå og etterligne fem forskjellige stiler av koding. Alt for å endre ett nummer.
Arkitektoniske beslutninger kan vare livet ut-spesielt hvis egoet ditt er grundig investert i dem, og du ikke kan endre dem. Prosjektledere må være klar til å legge merke til når den viktigste arkitektoniske planen ikke fungerer så store beslutninger kan gjøres.
Politiske konflikter
Å Skylde på politiske faktorer for en teknisk feil kan virke weaselly, men det er stadig mer sant. Etter hvert som prosjekter blir større og spenner over flere organisasjoner, bør det ikke være en overraskelse at fraksjoner vises og grupper jockey for kontroll, ressurser og til slutt makt.
Politiske fraksjoner er forskjellige fra reelle tekniske forskjeller. Det er ofte tekniske standarder eller kodebaser som gjør mye det samme på forskjellige måter. XML og JSON. Nå som jeg har skrevet det, kan jeg føle fansen av å rushing for å forklare hvorfor de ikke er de samme, og deres favorittvalg er den rette. Men når en del av et lag elsker ett valg og en annen holder den konkurrerende fraksjonen i høyeste grad, vil friksjonen rive dem fra hverandre.
dette har blitt enda mer vanlig ettersom arkitekter deler opp applikasjoner i flere, mindre tjenester og Api-Er. Ulike grupper vil ende opp med å kontrollere disse, og de vil ikke alltid komme sammen. Hvis Gruppe a liker JSON Og Gruppe B klamrer SEG TIL XML, vel, teamet ditt må enten implementere begge eller få en av dem til å endre seg. Alle tre er en smerte for alle lag som må jobbe med Både Gruppe A Og Gruppe B.
Spill på teknologi som ikke er klar for produksjon
Programmerere elsker de nyeste verktøyene og rammene. De ønsker å tro den nye tilnærmingen vil feie bort alle cruft som myrer ned forrige generasjon.
men ofte er neste generasjon ikke klar for produksjon. De nye funksjonene kan virke perfekte, men det er ofte hull som ikke er umiddelbart åpenbare. Noen ganger støtter koden bare noen få filtyper eller grensesnitt med bare noen få databaser. De andre kommer snart, de forsikrer deg, men prosjektet ditt må sendes denne måneden, og «snart» kan bety seks eller flere måneder før funksjonene du trenger er fullført.
Spill på teknologi som snart blir utdatert
i min erfaring er de gamle greiene vanligvis mer pålitelige og kamptestede, men det betyr ikke at gammel teknologi er perfekt. Funksjoner kan mangle som er avgjørende for programvareprosjektet når det går live. Verre, å satse på gammel teknologi kan føre til at du går glipp av fremtidige muligheter basert på endringer nedover linjen. Nye ideer, protokoller og filformater vises, og de kan gå uimplementert. Og hvis noen fra et konkurrerende lag insisterer på at du støtter en ny protokoll, vil den gamle teknologien skade.
Urealistiske tidsfrister
Tidsfrister er vanskelige. Mange prosjekter må gjøre det til markedet av en bestemt sesong eller hendelse. Men når tidsfrister først skrives ned, har utviklerne ikke begynt å oppdage veisperringer og hindringer i veien. Så hvis prosjektet glir og hendelsen går uten at programvaren blir lansert, blir hele prosjektet sett på som en feil, selv om koden bare skal løpe jevnt. Tidsfrister hjelper alle med å fokusere og trekke sammen, men de skaper også forventninger som kan være urealistiske.
Uforutsett konkurranse
en god produktsjef undersøker konkurransen før du dykker inn, men ingen kan forutsi hvilken konkurranse som kan vises ut av ingensteds. Hvis nye konkurrenter introduserer nye funksjoner som du må duplisere, vel, se avsnittene om funksjonsendringer og prioriterte feilmatcher ovenfor.
Rushing prosessen
Mange programvareprosjekter starter som visjonen til en person eller et lag som ønsker å fikse noe. De kommer opp med et uttrykk som «Snapchat For Y «eller» Uber For Y » og forventer at produktteamet skal være like responsivt som Snapchat eller Uber. Problemet er at å finne ut omfanget av prosjektet, skissere datastrømmene og forestille BRUKERGRENSESNITTET, er ofte ti ganger så mye arbeid som å skrive koden. Men imagineers vil gå fra ide til kode med en gang.
wireframes, databaseskjema og brukerhistorier er ikke bare hånd vinke, men en viktig del av jobben. Men de fleste vil tro at et programvareprosjekt bare skriver kode for å implementere en ide.
Falsk tro på kraften av programvare
Drømmere har ofte urealistiske tro på kraften av programvare for å forandre verden. Mange trodde at sosiale medier ville forene oss, men på en eller annen måte er det bare utsatte feillinjer som alltid var åpenbare. Programvareprosjekter ofte begynne med lysbilde dekk som lover å revolusjonere noen hjørne av verden. Når du skyver biter i en database, forvandler ikke noen, vel, folk blir sint, kjedelig, forvirret eller verre. De sier at programvaren er ødelagt fordi den ikke klarer å levere den magiske transformasjonen som alle forventet.
Mange programvareprosjekter kan kompilere, passere QA, sende og til og med få anstendig anmeldelser, men til slutt mislykkes i å oppnå noen av løftene på lysbildedekket fordi, vel, de forandringsløftene er umulige.
Onde underleverandører
vi elsker leverandørene som produserer bibliotekene og verktøyene som gjør at vi kan lage magi med bare noen få linjer med kode. Noen ganger får de vind av sin makt og bruker den til å ødelegge et prosjekt. Budsjettarket for versjon 1.0 var så bra at ledelsen ikke nølte med å godkjenne versjon 2.0. Deretter bestemmer leverandøren å presse oss ved å tredoble eller femdoble prisen.
denne effekten kan merkes selv når leverandørene ikke gjør det med vilje. Gratis nivåer kan gjøre et prosjekt ser veldig billig. Så når etterspørselen stiger og den andre versjonen utvider etterspørselen, sparker de reelle prisene inn.
Sea change
i et år med pandemier og protester, ingenting har endret seg raskere enn tidsånden. Gjorde prosjektet sterk personvernbeskyttelse en sentral funksjon? Ops. Pandemien har gjort alle interessert i kontaktsporing. Ønsker noen å fokusere på forretningsreiser? Ops. Hotellbransjen har kollapset. Større programvareprosjekter som kan ta et år eller lenger risiko å bli upended av katastrofale hendelser. Det som virket som en fantastisk ide i begynnelsen, kan virke håpløst tapt og frakoblet når det er på tide å gå live.
Tekniske skift
det er ikke bare endringer i verden som helhet. Tidevannsendringer i teknologisamfunnet kan ha samme effekt. NoSQL var en gang et geni ide som ville frigjøre oss fra relasjonsskjema. Så innså noen at filene oppblåste fordi hver post hadde et lokalt skjema. Et godt agile utviklingsteam kan skifte når teknologiske sjøendringer skifter holdningene til ledelsen og kundene. Men selv de mest smidige lagene kan ikke håndtere store skift som suger all luften ut av deres arkitektoniske planer. Systemet ble bygget forutsatt At X var en god ide og plutselig Er X smuss. Noen ganger er det best å blåse det opp og stjerne igjen.
For Mange tillegg
Noen programvareprosjekter starter godt og til og med sendes vellykket. Deretter legger noen til en ekstra funksjon eller tre, grafting ny kode på den eksisterende versjonen på en måte som koden fortsetter å halte sammen. Heroiske utviklere kan trekke dette av flere ganger, spesielt hvis den første arkitekten planla godt. Men på et tidspunkt smuldrer grunnlaget. Kanskje databasen ikke kan håndtere lasten. Kanskje det er for mange Sammenføyninger som trengs for å tilfredsstille de ulike spørsmålene. God programvare kan bli for fett, noen ganger takket være små forbedringer som presset den over kanten.
flytte målposter
de opprinnelige planene krevde en database for å spore kundeutgifter for å hjelpe med markedsføringsplaner. Deretter la noe geni til en funksjon som bruker kunstig intelligens for å korrelere utgifter med værmeldingen. Eller noen andre ønsket programvaren til automatisk bud for søkemotorannonser. Endre målet kan upend et prosjekt.
det er sjelden at endringene ødelegger ting alene. Men nye mål kan avsløre svakheter og utløse feilmoduser. Kanskje laget er nå for lite til å fullføre prosjektet vellykket. Kanskje de tekniske fundamentene er veldig ineffektive for den nye tilnærmingen. Det er vanskelig for alle å forutse fretful combinatorics når beslutningen er gjort for å endre målene.