20 ok, amiért a szoftverprojektek kudarcot vallanak
minden szoftverprojekt nagy álmokkal és nagy víziókkal kezdődik. Valahol egy alternatív univerzumban van egy projekt, amely minden álmot teljesít, de univerzumunkban túl gyakran a szoftverprojektek a célvonal felé botlanak, és néha átlépik azt.
természetesen definíció szerint a szoftverprojekt meghibásodása nem bináris dolog. Akkor a végén a kódot, hogy jól fut, de senki sem használja. Vagy a végén a kódot, hogy nem is fordít. Néha meg lehet menteni valami hasznosat a lángoló roncsokból, néha pedig a legjobb, ha elmenekül, mielőtt felrobban.
amikor a parázsló rendetlenség lehűl, megkezdődik a boncolás, mivel az emberek tudni akarják, mi történt rosszul. Itt vannak a leggyakoribb bűnösök.
túl kevés csapattag
gyakori probléma, hogy túl kevés programozóval próbálunk túl sokat tenni. A fejlesztők csak annyi kódot tudnak őrölni, mielőtt kiégnének. Egyszer dolgoztam egy csapatban, ahol a menedzser úgy gondolta, hogy az agilis csapatoktól több munka kiszorításának helyes módja az egyes “sprintek” ütemezése, így az közvetlenül az előző után kezdődött. Nincs átgondolt szünet, hogy kitaláljuk, mi működik, és mi nem. Sprint 42 véget ért szerdán 1:59pm és Sprint 43 kezdődött szerdán 2:00pm. A retrospektív elemzési találkozókat a következő sprint kezdete után ütemezték. Néhány okos srác azt javasolta, hogy nevezzék át őket “maratonoknak”, és hamarosan új munkát találtak.
természetesen nehéz tudni, hogy hány programozó elég. Néha útlezárások és problémák akadályozzák. Lehet, hogy nem a menedzser hibája, hogy a munka megduplázódik, de ha nincs elég ember a munkában, akkor a projekt valószínűleg ítélve van.
túl sok csapattag
ha túl kevés programozó lehet rossz, akkor a túl sok potenciálisan rosszabb is lehet, mivel a hálózati hatások elpusztíthatják a szoftverprojektet. A több ember több koordinációt jelent, ami több találkozót jelent, időt vesz igénybe a kódírástól. De ha nem tart elég értekezletet, hamarosan felfedezi, hogy az a csapat API-ja nem kapcsolódik a B csapat mikroszolgáltatásaihoz.
jó lenne, ha csak pénzt dobhatnánk egy problémára egy projekt túlmunkájával, de nem teheted.
túl sok kommunikáció
az írószoftver magányos művészet. Az emberek együtt dolgozhatnak, de csak korlátozott ütemben. Sok fejlesztő utálja a találkozókat, mert mentális sebességüket a mély, magával ragadó logikai gondolatról a nyitottabbra kell váltaniuk, társadalmi mód. Ez időbe telik. Néhány csapatvezető úgy próbál harcolni a kudarc ellen, hogy több találkozót tart, hogy mindenki szinkronban maradjon. Nemes erőfeszítés, de hallani lehet a fogaskerekek őrlését. A csapatnak elegendő információt kell megosztania ahhoz, hogy szinkronban maradjon, de többé csak pazarolja az agyi ciklusokat.
alapvető funkcióváltozások
elméletileg a fejlesztők agilisnak tartják magukat. Ezért fogadják el a szót. De néha az agilitás mindenkit ki tud dobni az egyensúlyból. Minden attól függ, hogy a váltás alapvető változásokat igényel-e az alapul szolgáló keretben. Könnyű agilisnak lenni, ha egy gombot mozgatunk vagy színt változtatunk. De amikor ez magában foglalja az adatbázis-séma átdolgozását vagy a sharding és a replikáció megkerülését, nincs egyszerű módja annak, hogy kecsesen elforduljon.
rossz technológia kiválasztása a feladatra
még akkor is, ha gondosan megtervezi és elkészíti a funkciók megfelelő listáját, a dolgok meghibásodhatnak, ha rossz technológiát használ. Az adatbázisokat úgy tervezték, hogy általánosak és rugalmasak legyenek, de vannak építészeti korlátaik. Nyomja meg őket, hogy szállítsanak valamit, amit nem terveztek, és lassítani fognak egy virtuális megállásra, amikor a skálát kérik. Vagy elindulhat egy NoSQL adatbázissal, mert csak hűvösnek tűnnek, hogy később felfedezzék, hogy valóban szükség van savas minőségű tranzakciókra, hogy a dolgok következetesek legyenek, és az adatbázis nem kínálja őket. Hoppá.
gyenge priorizálás
a jó tervezők összeállítják a funkciók listáját, és rangsorolják őket. De néha a prioritások nem egyeznek meg a megvalósítás valóságával. A legrosszabb esetekben a legfontosabb funkciókat a legnehezebb létrehozni.
mit kell tennie a fejlesztőknek? Ha a legfontosabb funkcióra koncentrálnak, akkor nem fognak előrelépni, és végül nem fogják biztosítani a funkciókat. De ha elkezdik kiütni a könnyebbeket, lehet, hogy valami értéktelen lesz.
a jó tervezéshez több kell, mint egy ellenőrzőlista. Az építészeti elképzeléseknek figyelembe kell venniük a megvalósítás igényeit és költségeit.
a piaci ablak bezárul
néha nem a programozó hibája. Az egyik projektem az volt, hogy egy bestseller referenciakönyvet alkalmazássá alakítsak. A könyvet úgy adták el, mint a sütit az internet előtti években. A terv az volt, hogy kihasználjuk ezt a keresletet, és elkészítünk egy interaktív verziót, amely lehetővé teszi az emberek számára az adatok rendezését és keresését. A programozó csapat olyan szoftvert szállított, amely mindent tartalmazott a könyvben, de gyorsabb, szebb és sokkal könnyebb volt, mint maga a könyv. De már senki sem akarta. Volt elég más forrás, és senkinek sem volt szüksége egy másik alkalmazásra, amely nagyjából ugyanazt tette, mint a híroldalak mindenhol.
néha egy ötlet nagyszerűnek tűnik, de a piac továbbment.
rossz építészeti döntések
egy projekten azt a feladatot kaptam, hogy egy sorban egy számot változtassak az adatbázisban. Amikor a felhasználó befejezte a regisztrációt, hozzá kellett adnom a felhasználó azonosító számát a legújabb megrendeléshez. Egyszerűen hangzik, igaz? De a rendszer egy mikroszolgáltatási architektúrára épült, és ezt nem tudtam megoldani egyetlen kódsor megírásával, amely megmondja az adatbázisnak, hogy frissítse az oszlopot. Nem. Az építészeti terv az volt, hogy egy új microservice hívás a meglévő verem, és még ez is nehéz volt, mert az első microservice hívás szükséges kiváltó újabb microservice hívást, és így tovább.
végül az építészeti zseni, aki létrehozta ezt a mikroszolgáltatási hálózatot, azt mondta nekem, hogy az egész nagyon egyszerű, és egy kígyószerű utat vázolt fel az építészet öt rétegén keresztül. Az volt a feladatom, hogy öt új API-hívást adjak hozzá öt különböző mikroszolgáltatáshoz, ami azt is jelentette, hogy minden réteghez öt automatizált tesztkészletet adtak hozzá. Minden API-t egy másik csapat fejlesztett ki az évek során, és öt különböző kódolási stílust kellett megértenem és utánoznom. Minden változtatni egy számot.
az építészeti döntések egy életen át tarthatnak — különösen, ha az egód alaposan befektet ezekbe, és nem tudod megváltoztatni őket. A projektmenedzsereknek készen kell állniuk arra, hogy észrevegyék, amikor a fő építészeti terv nem működik, így nagy döntéseket lehet hozni.
politikai konfliktusok
a politikai tényezők hibáztatása technikai hibáért tűnhet, de egyre inkább igaz. Ahogy a projektek egyre nagyobbak és több szervezetre kiterjednek, nem lehet meglepő, hogy frakciók jelennek meg és csoportok jockey az ellenőrzésért, az erőforrásokért és végső soron a hatalomért.
a politikai frakciók különböznek a valódi technikai különbségektől. Gyakran vannak olyan műszaki szabványok vagy kódbázisok, amelyek nagyjából ugyanazt teszik különböző módon. Vegyük az XML-t és a JSON-t. Most, hogy ezt beírtam, érzem, hogy a rajongók rohannak, hogy elmagyarázzák, miért nem azonosak, és a kedvenc választásuk a megfelelő. De amikor egy csapat egyik része szereti az egyik választást, a másik pedig a Versengő frakciót tartja a legnagyobb tiszteletben, jól, a súrlódás szét fogja tépni őket.
ez még gyakoribbá vált, mivel az építészek az alkalmazásokat több, kisebb szolgáltatásra és API-ra osztották fel. Különböző csoportok fogják irányítani ezeket, és nem mindig jönnek ki egymással. Ha az A csoport kedveli a JSON-t és a B csoport ragaszkodik az XML-hez, akkor a csapatnak vagy mindkettőt végre kell hajtania, vagy az egyiket meg kell változtatnia. Mindhárman fájdalmat okoznak minden olyan csapatnak, amelynek együtt kell működnie mind az A, mind a B csoporttal.
fogadás olyan technológiára, amely még nem áll készen a gyártásra
a programozók szeretik a legújabb eszközöket és keretrendszereket. Azt akarják hinni, hogy az új megközelítés el fogja söpörni az összes cirkuszt, amely az előző generációt lerázza.
de gyakran a következő generáció nem áll készen a gyártási felhasználásra. Az új funkciók tökéletesnek tűnhetnek, de gyakran vannak olyan hiányosságok, amelyek nem azonnal nyilvánvalóak. Néha a kód csak néhány fájltípust vagy interfészt támogat, csak néhány adatbázissal. A többiek hamarosan jönnek, biztosítják Önt, de a projektnek ebben a hónapban kell szállítania, és a “hamarosan” hat vagy több hónapot jelenthet, mielőtt a szükséges funkciók elkészülnek.
fogadások olyan technológiákra, amelyek hamarosan elavulnak
tapasztalatom szerint a régi dolgok általában megbízhatóbbak és harci teszteltek, de ez nem jelenti azt, hogy a régi technológia tökéletes. Hiányozhatnak olyan funkciók, amelyek létfontosságúak a szoftverprojekt számára, miután életbe lép. Rosszabb, ha a régi technológiára fogad, akkor kihagyhatja a jövőbeli lehetőségeket a változások alapján. Új ötletek, protokollok és fájlformátumok jelennek meg, amelyek megvalósíthatatlanok lehetnek. És ha valaki egy versengő csapatból ragaszkodik ahhoz, hogy támogasson valami új protokollt, akkor a régi technológia fájni fog.
irreális határidők
a határidők trükkösek. Sok projektnek egy adott szezonra vagy eseményre kell eljutnia a piacra. Mégis, amikor a határidőket először leírják, a fejlesztők még nem kezdték felfedezni az útjukban lévő akadályokat és akadályokat. Aztán, ha a projekt csúszik, és az esemény elmúlik anélkül, hogy a szoftver elindul, az egész projekt tekinthető hiba akkor is, ha a kód csak arról szól, hogy zökkenőmentesen. A határidők segítenek mindenkinek koncentrálni és összetartani, de olyan elvárásokat is teremtenek, amelyek irreálisak lehetnek.
előre nem látható verseny
egy jó termékmenedzser felméri a versenyt a merülés előtt, de senki sem tudja megjósolni, hogy milyen verseny jelenhet meg a semmiből. Ha az új versenytársak új funkciókat vezetnek be, amelyeket meg kell duplikálni, nos, lásd a funkcióváltozásokról és a prioritási eltérésekről szóló szakaszokat.
a folyamat rohanása
sok szoftverprojekt egy olyan személy vagy csapat jövőképeként indul, aki valamit meg akar javítani. Olyan kifejezéssel állnak elő, mint a “Snapchat for Y” vagy az “Uber for Y”, majd elvárják, hogy a termékcsapat ugyanolyan érzékeny legyen, mint a Snapchat vagy az Uber. A probléma az, hogy a projekt hatókörének kitalálása, az adatfolyamok felvázolása és a felhasználói felület elképzelése gyakran tízszer annyi munka, mint a kód írása. De a képzelők azonnal el akarnak menni az ötlettől a kódig.
a drótvázak, az adatbázis-séma és a felhasználói történetek nem csak kézzel integetnek, hanem a munka lényeges részét képezik. De a legtöbb ember azt akarja hinni, hogy egy szoftverprojekt csak kódot ír egy ötlet megvalósításához.
hamis hit a szoftver erejében
az álmodozók gyakran irreális hiedelmekkel rendelkeznek a szoftver hatalmában, hogy megváltoztassák a világot. Sokan azt képzelték, hogy a közösségi média egyesít minket, de valahogy csak kitett törésvonalak, amelyek mindig nyilvánvalóak voltak. A szoftverprojektek gyakran csúszdapaklikkal kezdődnek, amelyek azt ígérik, hogy forradalmasítják a világ néhány sarkát. Amikor az adatbázisba tolta a biteket, az senkit sem alakít át, nos, az emberek dühösek, unatkoznak, összezavarodnak vagy még rosszabbak. Azt mondják, hogy a szoftver elromlott, mert nem képes megvalósítani azt a varázslatos átalakulást, amelyet mindenki elvárt.
sok szoftverprojekt képes összeállítani, átadni a minőségbiztosítást, szállítani, sőt tisztességes véleményeket is kapni, de végül nem sikerül elérni a csúszda fedélzetén tett ígéreteket, mert Nos, ezek a világváltás ígéretei lehetetlenek.
gonosz alvállalkozók
szeretjük azokat a szállítókat, akik olyan könyvtárakat és eszközöket gyártanak, amelyek lehetővé teszik számunkra, hogy varázslatot hozzunk létre néhány sornyi kóddal. Időnként kiszagolják az erejüket, és arra használják, hogy elpusztítsanak egy projektet. Az 1.0 verzió költségvetési lapja olyan jó volt, hogy a vezetés nem habozott jóváhagyni a 2.0 verziót. Ezután az eladó úgy dönt, hogy megszorít minket az ár háromszorosával vagy ötszörösével.
ez a hatás akkor is érezhető, ha a gyártók nem szándékosan csinálják. Az ingyenes szintek nagyon olcsóvá tehetik a projektet. Aztán amikor a kereslet szárnyal, és a második változat kibővíti a keresletet, a valódi árak beindulnak.
Sea change
a járványok és tiltakozások egy éve alatt semmi sem változott gyorsabban, mint a korszellem. A projekt központi elemévé tette az erős adatvédelmi védelmet? Hoppá. A járvány mindenkit érdekelt az érintkezés nyomon követésében. Szeretne valaki az üzleti utazásra összpontosítani? Hoppá. A szállodaipar összeomlott. A nagyobb szoftverprojektek, amelyek egy évig vagy tovább is eltarthatnak, azt kockáztatják, hogy kataklizmikus események felborítják őket. Ami az elején csodálatos ötletnek tűnt, reménytelenül elveszettnek és megszakadtnak tűnhet, amikor ideje élni.
MŰSZAKI műszakok
ez nem csak a világ nagy változásairól szól. A technológiai közösség árapályváltozásainak ugyanolyan hatása lehet. A NoSQL egykor zseniális ötlet volt, amely felszabadít minket a relációs sémától. Aztán valaki rájött, hogy a fájlok felfújódnak, mert minden rekord helyi sémát tartalmazott. Egy jó agilis fejlesztőcsapat elmozdulhat, amikor a technológiai változások megváltoztatják a vezetés és az ügyfelek hozzáállását. De még a leg agilisabb csapatok sem tudnak megbirkózni a nagy műszakokkal, amelyek az összes levegőt kiszívják építészeti terveikből. A rendszert úgy építették fel, hogy X nagyszerű ötlet volt, és hirtelen X piszok. Néha az a legjobb, ha felrobbantjuk és újra csillagozunk.
túl sok kiegészítés
néhány szoftverprojekt jól indul, sőt sikeresen szállít. Aztán valaki hozzáad egy-három extra funkciót, új kódot oltva a meglévő verzióra oly módon, hogy a kód továbbra is sántikáljon. Hősi Fejlesztők húzza ezt le többször, különösen, ha a kezdeti építész tervezett jól. De egy bizonyos ponton az alapítvány összeomlik. Talán az adatbázis nem tudja kezelni a terhelést. Talán túl sok csatlakozás szükséges a különféle lekérdezések kielégítéséhez. A jó szoftver túl kövér lehet, néha annak a kis fejlesztésnek köszönhetően, amely a szélére tolta.
mozgó céloszlopok
a kezdeti tervek egy adatbázist kértek az ügyfelek kiadásainak nyomon követésére, hogy segítsenek a marketingtervekben. Aztán néhány zseni hozzáadott egy olyan funkciót, amely mesterséges intelligenciát használ a kiadások korrelálására az időjárás-előrejelzéssel. Vagy valaki más azt akarta, hogy a szoftver automatikusan ajánlatot tegyen keresőmotor-hirdetésekre. A cél megváltoztatása felülírhatja a projektet.
ritka, hogy a változások önmagukban tönkretegyék a dolgokat. De az új célok feltárhatják a gyengeségeket és meghibásodási módokat indíthatnak el. Talán a csapat most túl kicsi ahhoz, hogy sikeresen befejezze a projektet. Talán a technikai alapok vadul nem hatékonyak az új megközelítés szempontjából. Mindenkinek nehéz előre látni a nyugtalan kombinatorikát, amikor a célok megváltoztatásáról döntenek.