20 důvodů, proč softwarové projekty selhávají
každý softwarový projekt začíná velkými sny a velkými vizemi. Někde v alternativním vesmíru existuje projekt, který splňuje každý sen, ale až příliš často softwarové projekty v našem vesmíru narazí na cílovou čáru a někdy ji překročí.
samozřejmě, ze své podstaty, selhání softwarového projektu není binární věc. Můžete skončit s kódem, který běží dobře, ale nikdo nepoužívá. Nebo můžete skončit s kódem, který nebude ani kompilovat. Někdy můžete zachránit něco užitečného z hořícího trosek a někdy je nejlepší utéct, než exploduje.
když doutnající nepořádek vychladne, začnou pitvy, protože lidé chtějí vědět, co se pokazilo. Zde jsou nejčastější viníci.
příliš málo členů týmu
snaha udělat příliš mnoho s příliš malým počtem programátorů je běžným problémem. Vývojáři mohou jen brousit tolik kódu, než vyhoří. Jednou jsem pracoval v týmu, kde si manažer myslel, že správným způsobem, jak vytlačit více práce z agilních týmů, je naplánovat každý „sprint“, takže to začalo bezprostředně po předchozím. Žádné promyšlené pauzy, abychom zjistili, co funguje a co ne. Sprint 42 skončil ve středu v 1: 59 a Sprint 43 začal ve středu ve 2: 00. Retrospektivní analýzy byly naplánovány po dalším sprintu, který již začal. Nějaký chytrý chlap navrhl, aby byli přejmenováni na „maratony“ a brzy našli jinou práci.
samozřejmě je těžké vědět, kolik programátorů stačí. Někdy překážejí zátarasy a problémy. Nemusí to být chyba manažera, že se práce zdvojnásobí, ale pokud nemáte dostatek lidí v práci, váš projekt je pravděpodobně odsouzen k zániku.
příliš mnoho členů týmu
pokud příliš málo programátorů může být špatné, příliš mnoho by mohlo být potenciálně horší, protože síťové efekty mohou zničit softwarový projekt. Více lidí znamená větší koordinaci a to znamená více schůzek, přičemž čas od psaní kódu. Ale pokud nemáte dostatek schůzek, brzy zjistíte, že API týmu a nespojuje mikroslužby týmu B.
bylo by hezké, kdybychom mohli jen házet peníze na problém přetížením projektu, ale nemůžete.
příliš mnoho komunikace
psaní softwaru je osamělé umění. Lidé mohou spolupracovat, ale pouze v omezených záchvatech. Mnoho vývojářů nenávidí setkání, protože potřebují posunout své mentální zařízení z hlubokého pohlcujícího logického myšlení do otevřenějšího sociálního režimu. Chce to čas. Někteří vedoucí týmu se snaží bojovat proti selhání tím, že pořádají více schůzek, aby byli všichni synchronizováni. Je to ušlechtilé úsilí, ale můžete slyšet broušení ozubených kol. Tým musí sdílet dostatek informací, aby zůstal synchronizován, ale už jen plýtvá mozkovými cykly.
základní změny funkcí
teoreticky se vývojáři rádi považují za agilní. Proto to slovo přijali. Ale někdy agility může Všechny vyvést z rovnováhy. Vše záleží na tom, zda posun vyžaduje zásadní změny základního rámce. Je snadné být agilní při pohybu tlačítka nebo při změně barvy. Ale když to zahrnuje přepracování databázového schématu nebo škubání kolem shardingu a replikace, neexistuje snadný způsob, jak elegantně otáčet.
výběr nesprávné technologie pro práci
i když pečlivě plánujete a sestavíte správný seznam funkcí, může dojít k selhání, pokud použijete nesprávnou technologii. Databáze, například, jsou navrženy tak, aby byly obecné a flexibilní, ale mají architektonická omezení. Tlačit je dodat něco, co nejsou určeny k tomu, a oni zpomalí na virtuální zastavení, když žádal, aby měřítko. Nebo můžete začít s databází NoSQL, protože zní skvěle, až později zjistíte, že opravdu potřebujete transakce na úrovni kyselin, abyste udrželi věci konzistentní a databáze je nenabízí. Jejda.
špatná prioritizace
dobří plánovači sestaví seznam funkcí a upřednostňují je. Ale někdy se priority neshodují s realitou jejich implementace. V nejhorších případech jsou nejdůležitější funkce nejtěžší.
co mají vaši vývojáři dělat? Pokud se soustředí na nejdůležitější funkci, nedosáhnou žádného pokroku a mohou nakonec poskytnout žádnou z funkcí. Ale pokud začnou klepat na ty Snadné, mohou skončit s něčím, co je bezcenné.
dobré plánování vyžaduje více než kontrolní seznam. Architektonická vize musí brát v úvahu potřeby a náklady na jejich realizaci.
okno trhu se zavře
někdy to není chyba programátora. Jedním z mých projektů bylo proměnit nejprodávanější příručku v aplikaci. Kniha se prodávala jako hotcakes v letech před internetem. V plánu bylo využít tuto poptávku a vytvořit interaktivní verzi, která by lidem umožnila třídit a prohledávat data. Programovací tým dodal software, který obsahoval vše v knize, ale byl rychlejší, hezčí a mnohem lehčí než samotná kniha. Ale už to nikdo nechtěl. Bylo dost jiných zdrojů a nikdo nepotřeboval další aplikaci, která dělala totéž jako zpravodajské weby všude.
někdy se nápad zdá skvělý, ale trh se posunul dál.
špatná architektonická rozhodnutí
u jednoho projektu jsem dostal za úkol změnit jedno číslo v jednom řádku v databázi. Když uživatel dokončil registraci, měl jsem přidat identifikační číslo uživatele k poslední objednávce. Zní to jednoduše, že? Ale systém byl postaven na architektuře microservices a nemohl jsem to vyřešit napsáním jednoho řádku kódu, který by řekl databázi, aby aktualizovala tento sloupec. Ne. Architektonickým plánem bylo přidat nové volání mikroslužeb do stávajícího zásobníku a dokonce to bylo těžké, protože moje první volání mikroslužeb potřebovalo spustit další volání mikroslužeb atd.
nakonec mi architektonický whiz, který vytvořil tuto síť mikroservisů, řekl, že je to všechno velmi jednoduché a nastínil hadovitou cestu pěti vrstvami architektury. Mým úkolem bylo přidat pět nových volání API do pěti různých mikroservisů, což také znamenalo přidání pěti sad automatizovaných testů pro každou vrstvu. A každé API bylo v průběhu let vyvinuto jiným týmem, vyžadující, abych pochopil a napodobil pět různých stylů kódování. Vše pro změnu jednoho čísla.
architektonická rozhodnutí mohou trvat celý život-zvláště pokud je do nich důkladně investováno vaše ego a nemůžete je změnit. Projektoví manažeři musí být připraveni si všimnout, kdy hlavní architektonický plán nefunguje, takže lze učinit velká rozhodnutí.
politické konflikty
obviňovat politické faktory z technického selhání se může zdát slabé, ale je to stále více pravdivé. Jak se projekty zvětšují a pokrývají více organizací, nemělo by být překvapením, že se objevují frakce a skupiny žokej pro kontrolu, zdroje a nakonec moc.
politické frakce se liší od skutečných technických rozdílů. Často existují technické normy nebo kódové základny, které dělají totéž různými způsoby. Vezměte XML a JSON. Teď, když jsem to napsal, cítím, jak fanoušci buď spěchají, aby vysvětlili, proč nejsou stejní a jejich oblíbená volba je správná. Ale když jedna část týmu miluje jednu volbu a druhá drží konkurenční frakci v nejvyšším ohledu, studna, tření je roztrhne.
to se stalo ještě běžnějším, protože architekti rozdělili aplikace na více menších služeb a API. Různé skupiny je nakonec ovládají a ne vždy spolu vycházejí. Pokud skupina a má ráda JSON a skupina B lpí na XML, dobře, váš tým bude muset implementovat oba nebo si jeden z nich změnit. Všechny tři jsou bolest pro každý tým, který musí pracovat jak se skupinou A, tak se skupinou B.
sázení na technologii, která není připravena k výrobě
programátoři milují nejnovější nástroje a rámce. Chtějí věřit, že nový přístup smete všechny cruft, že bažiny se předchozí generace.
ale nová generace často není připravena k výrobnímu použití. Nové funkce se mohou zdát dokonalé, ale často existují mezery, které nejsou okamžitě zřejmé. Někdy kód podporuje pouze několik typů souborů nebo rozhraní pouze s několika databázemi. Ostatní se blíží, ujišťují vás, ale váš projekt musí být dodán Tento měsíc a „brzy“ by mohlo znamenat šest nebo více měsíců před dokončením potřebných funkcí.
sázení na technologii, která bude brzy zastaralá
podle mých zkušeností jsou staré věci obvykle spolehlivější a testovány v bitvě, ale to neznamená, že stará technologie je dokonalá. Funkce mohou chybět, které jsou životně důležité pro váš softwarový projekt, jakmile bude spuštěn. Horší je, že sázení na staré technologie může způsobit, že přijdete o budoucí příležitosti na základě změn v řadě. Objevují se nové nápady, protokoly a formáty souborů a mohou být nerealizovány. A pokud někdo z konkurenčního týmu trvá na tom, že podporujete nějaký nový protokol, stará technologie bude bolet.
nereálné termíny
termíny jsou složité. Mnoho projektů se musí dostat na trh podle konkrétní sezóny nebo události. Přesto, když jsou termíny poprvé zapsány, vaši vývojáři nezačali objevovat zátarasy a překážky, které jim stojí v cestě. Pak, pokud projekt sklouzne a událost projde bez spuštění softwaru, celý projekt je považován za selhání, i když kód právě běží hladce. Termíny pomáhají každému soustředit se a táhnout za jeden provaz, ale také vytvářejí očekávání, která mohou být nereálná.
Nepředvídaná soutěž
dobrý produktový manažer zkoumá konkurenci před potápěním, ale nikdo nemůže předpovědět, jaká konkurence se může objevit z ničeho. Pokud noví konkurenti představí nové funkce, které musíte duplikovat, studna, viz části o změnách funkcí a nesouladu priorit, výše.
spěchání procesu
mnoho softwarových projektů začíná jako vize osoby nebo týmu, který chce něco opravit. Přicházejí s frází jako „Snapchat pro Y „nebo“ Uber pro Y “ a pak očekávají, že produktový tým bude stejně citlivý jako Snapchat nebo Uber. Problém je v tom, že zjistit rozsah projektu, načrtnout datové toky a představit si uživatelské rozhraní je často desetkrát tolik práce než psaní kódu. Ale imagineers chtějí jít od nápadu ke kódu hned.
drátové modely, schéma databáze a uživatelské příběhy nejsou jen mávání rukou, ale nezbytnou součástí práce. Ale většina lidí chce věřit, že softwarový projekt je jen psaní kódu realizovat nápad.
falešná víra v sílu softwaru
snílci mají často nerealistické přesvědčení o síle softwaru změnit svět. Mnozí si představovali, že nás sociální média spojí, ale nějak jsou to jen odhalené zlomové linie, které byly vždy zřejmé. Softwarové projekty často začínají skluzavkami, které slibují revoluci v některých koutech světa. Když strkání bitů do databáze nikoho nezmění, dobře, lidé se zlobí, nudí, zmatení nebo horší. Říká se, že software je rozbitý, protože nedokáže poskytnout magickou transformaci, kterou všichni očekávali.
mnoho softwarových projektů může sestavit, projít QA, loď a dokonce získat slušné recenze, ale nakonec nedosáhne žádného ze slibů na kluzné palubě, protože tyto sliby změny světa jsou nemožné.
zlí subdodavatelé
milujeme dodavatele, kteří vyrábějí knihovny a nástroje, které nám umožňují vytvářet kouzlo pomocí několika řádků kódu. Občas, dostanou vítr své síly a použijí ji ke zničení projektu. Rozpočtový List Pro verzi 1.0 byl tak dobrý, že vedení neváhalo schválit verzi 2.0. Pak se prodejce rozhodne nás zmáčknout ztrojnásobením nebo pětinásobením ceny.
tento efekt lze pociťovat, i když to prodejci nedělají záměrně. Volné úrovně mohou Projekt vypadat velmi levně. Když pak poptávka stoupne a druhá verze poptávku rozšíří, skutečné ceny se nastartují.
Změna moře
za rok s pandemiemi a protesty se nic nezměnilo rychleji než zeitgeist. Udělal projekt silnou ochranu soukromí ústředním prvkem? Jejda. Pandemie přiměla všechny, aby se zajímali o trasování kontaktů. Chtěl se někdo zaměřit na služební cesty? Jejda. Hotelový průmysl se zhroutil. Větší softwarové projekty, které mohou trvat rok nebo déle, riskují, že budou zničeny kataklyzmatickými událostmi. To, co se na začátku zdálo jako skvělý nápad, se může zdát beznadějně ztracené a odpojené, když je čas jít žít.
technické posuny
nejsou to jen změny ve světě jako celku. Přílivové změny v technologické komunitě mohou mít stejný účinek. NoSQL byl kdysi geniální nápad, který by nás osvobodil od relačního schématu. Pak si někdo uvědomil, že soubory se nafouknou, protože každý záznam nesl místní schéma. Dobrý agilní vývojový tým se může posunout, když technologické změny moře posunou postoje vedení a zákazníků. Ale ani ty agilní týmy se nedokážou vypořádat s velkými posuny, které vysávají veškerý vzduch z jejich architektonických plánů. Systém byl postaven za předpokladu, že X byl skvělý nápad a najednou X je špína. Někdy je nejlepší to vyhodit do vzduchu a znovu hrát.
příliš mnoho dodatků
některé softwarové projekty začínají dobře a dokonce úspěšně dodávají. Pak někdo přidá další funkci nebo tři, roubování nového kódu na stávající verzi tak, aby kód nadále kulhal. Hrdinští vývojáři to mohou několikrát vytáhnout, zvláště pokud původní Architekt plánoval dobře. Ale v určitém okamžiku se nadace rozpadá. Možná databáze nezvládne zátěž. Možná existuje příliš mnoho spojení potřebných k uspokojení různých dotazů. Dobrý software může být příliš tlustý, někdy díky malým vylepšením, která ho tlačila přes okraj.
přesouvání cílů
původní plány vyžadovaly databázi, která sleduje výdaje zákazníků, aby pomohla s marketingovými plány. Pak nějaký génius přidal funkci, která používá umělou inteligenci ke korelaci výdajů s předpovědí počasí. Nebo někdo jiný chtěl, aby software automaticky nabízel reklamy ve vyhledávačích. Změna cíle může Projekt vylepšit.
je vzácné, že změny zničí věci samy o sobě. Nové cíle však mohou odhalit slabiny a spustit režimy selhání. Možná je tým nyní příliš malý na to, aby projekt úspěšně dokončil. Možná jsou technické základy pro nový přístup divoce neefektivní. Je těžké pro každého předvídat strašlivou kombinatoriku, když je rozhodnuto o změně cílů.