20 syytä, miksi ohjelmistoprojektit epäonnistuvat
jokainen ohjelmistoprojekti alkaa suurista unelmista ja suurista visioista. Jossain vaihtoehtoisessa universumissa on projekti, joka täyttää jokaisen unelman, mutta aivan liian usein ohjelmistoprojektit universumissamme kompastuvat kohti maaliviivaa ja joskus ylittävät sen.
ohjelmistoprojektin epäonnistuminen ei tietenkään määritelmän mukaan ole binäärinen asia. Voit päätyä koodi, joka toimii hyvin, mutta kukaan ei käytä. Tai voit päätyä koodi, joka ei edes koota. Joskus Liekehtivästä hylystä voi pelastaa jotain hyödyllistä ja joskus on parasta juosta karkuun ennen kuin se räjähtää.
kytevän sotkun jäähtyessä alkavat ruumiinavaukset, sillä ihmiset haluavat tietää, mikä meni pieleen. Tässä ovat yleisimmät syylliset.
liian harvat tiimiläiset
yrittävät tehdä liikaa liian vähillä ohjelmoijilla on yleinen ongelma. Kehittäjät voivat jauhaa vain tietyn määrän koodia ennen kuin ne palavat loppuun. Työskentelin kerran tiimissä, jossa managerin mielestä oikea tapa puristaa lisää töitä ketteriltä joukkueilta on ajoittaa jokainen ”sprintti” niin se alkoi heti edellisen jälkeen. Ei harkittuja taukoja selvittää, mikä toimi ja mikä ei. Sprint 42 päättyi keskiviikkona klo 1:59PM ja Sprint 43 alkoi keskiviikkona klo 14:00pm. Retrospektiiviset analyysitapaamiset oli sovittu jo alkaneen seuraavan sprintin jälkeen. Joku nokkela kaveri ehdotti, että ne nimettäisiin ”maratoneiksi” ja löysi pian uuden työpaikan.
on tietysti vaikea tietää, kuinka monta ohjelmoijaa riittää. Joskus tielle tulee tiesulkuja ja ongelmia. Se ei ehkä ole johtajan vika, että työ kaksinkertaistuu koko, mutta jos sinulla ei ole tarpeeksi ihmisiä työssä, projekti on todennäköisesti tuhoon tuomittu.
liian monta tiimin jäsentä
jos liian harvat ohjelmoijat voivat olla huonoja, liian moni voi mahdollisesti olla huonompikin, sillä verkkoefektit voivat tuhota ohjelmistoprojektin. Enemmän ihmisiä tarkoittaa enemmän koordinointia ja se tarkoittaa enemmän kokouksia, jolloin aikaa kuluu koodin kirjoittamiseen. Mutta jos et pidä tarpeeksi kokouksia, huomaat pian, että A-ryhmän API ei ole yhteydessä B-ryhmän mikropalveluihin.
olisi mukavaa, jos voisimme vain heittää rahaa ongelman piikkiin ylityöllistämällä projektin, mutta et voi.
liika viestintä
ohjelmistojen kirjoittaminen on yksinäistä taidetta. Ihmiset voivat työskennellä yhdessä, mutta vain rajoitetuissa jaksoissa. Monet kehittäjät vihaavat tapaamisia, koska heidän täytyy siirtää henkisiä vaihteitaan syvästä immersiivisestä loogisesta ajattelusta avoimempaan, sosiaaliseen tilaan. Tämä vie aikaa. Jotkut joukkueenjohtajat yrittävät taistella epäonnistumista vastaan pitämällä enemmän kokouksia, jotta kaikki pysyisivät synkronoituina. Se on jalo yritys, mutta voit kuulla vaihteiden hiertävän. Tiimin on jaettava tarpeeksi tietoa pysyäkseen synkronoituna, mutta kaikki muu vain tuhlaa aivosyklejä.
Fundamental feature changes
teoriassa kehittäjät pitävät itseään ketterinä. Siksi he omaksuvat sanan. Mutta joskus ketteryys voi horjuttaa kaikkien tasapainoa. Kaikki riippuu siitä, vaatiiko muutos perustavanlaatuisia muutoksia taustalla olevaan kehykseen. On helppo olla ketterä, kun liikuttaa nappia tai vaihtaa väriä. Mutta kun se liittyy muokata tietokannan skeema tai mucking noin sharding ja replikointi, ei ole helppo tapa sulavasti pivot.
väärän tekniikan valitseminen tehtävään
vaikka suunnittelisit huolellisesti ja laatisit oikean listan ominaisuuksista, asiat voivat epäonnistua, jos käytät väärää teknologiaa. Esimerkiksi tietokannat on suunniteltu yleisluonteisiksi ja joustaviksi, mutta niillä on arkkitehtonisia rajoitteita. Työnnä niitä toimittamaan jotain, mitä niitä ei ole suunniteltu tekemään, ja ne hidastuvat virtuaalisesti pysähtymään, kun niitä pyydetään skaalaamaan. Tai voit aloittaa NoSQL-tietokannasta, koska ne kuulostavat siisteiltä vain huomataksesi myöhemmin, että tarvitset todella HAPPOLUOKAN liiketoimia pitääksesi asiat johdonmukaisina ja tietokanta ei tarjoa niitä. Hups.
huono priorisointi
Hyvät suunnittelijat laativat listan ominaisuuksista ja priorisoivat ne. Mutta aina prioriteetit eivät ole linjassa niiden toteuttamisen todellisuuden kanssa. Pahimmissa tapauksissa tärkeimmät ominaisuudet ovat vaikeimpia luoda.
mitä kehittäjät tekevät? Jos ne keskittyvät tärkeimpään ominaisuuteen, ne eivät edisty ja saattavat päätyä toimittamaan mitään toiminnallisuutta. Mutta jos he alkavat tyrmätä helpot, he voivat päätyä johonkin arvottomaan.
hyvä suunnittelu vaatii muutakin kuin muistilistan. Arkkitehtoninen visio on otettava huomioon tarpeet ja kustannukset niiden toimittamisesta.
markkinaikkuna sulkeutuu
joskus se ei ole ohjelmoijan vika. Yksi projekteistani oli tehdä myydyimmästä hakuteoksesta sovellus. Kirja myi kuin kuumakalle ennen internetiä. Suunnitelmana oli hyödyntää tätä kysyntää ja tehdä interaktiivinen versio, joka antaisi ihmisten lajitella ja etsiä tietoja. Ohjelmointitiimi toimitti ohjelmiston, joka sisälsi kaiken kirjan, mutta oli nopeampi, kauniimpi ja paljon kevyempi kuin itse kirja. Mutta kukaan ei halunnut sitä enää. Muita lähteitä oli tarpeeksi, eikä kukaan tarvinnut toista sovellusta, joka teki paljon samaa kuin uutissivustot tekevät kaikkialla.
joskus idea tuntuu hienolta, mutta torilla on menty eteenpäin.
huonot arkkitehtuuripäätökset
yhden projektin kohdalla sain tehtäväkseni vaihtaa tietokannassa yhden numeron peräkkäin. Kun käyttäjä lopetti rekisteröitymisen, minun piti lisätä käyttäjän tunnusnumero uusimpaan tilaukseen. Kuulostaa yksinkertaiselta. Mutta järjestelmä oli rakennettu mikropalveluiden arkkitehtuurille, enkä voinut ratkaista tätä kirjoittamalla yhden rivin koodia, joka käskisi tietokannan päivittää kyseisen sarakkeen. Ei. Arkkitehtoninen suunnitelma oli lisätä Uusi microservice puhelu olemassa olevaan pinoon ja jopa tämä oli vaikeaa, koska minun ensimmäinen microservice puhelun piti laukaista toinen microservice puhelun ja niin edelleen.
lopulta tämän mikropalveluiden verkoston luonut arkkitehtuurinero kertoi minulle, että kaikki oli hyvin yksinkertaista ja hahmotteli serpentiinipolun arkkitehtuurin viiden kerroksen läpi. Tehtäväni oli lisätä viisi uutta API-puhelua viiteen eri microservices-palveluun, mikä tarkoitti myös viiden automatisoidun testisarjan lisäämistä jokaiselle kerrokselle. Ja jokainen API on kehittänyt eri tiimi vuosien varrella, edellyttää minua ymmärtämään ja jäljitellä viisi eri tyylejä koodaus. Kaikki yhden numeron vaihtamiseksi.
arkkitehtoniset päätökset voivat kestää eliniän — varsinkin jos ego on niihin perusteellisesti panostanut eikä niitä voi muuttaa. Projektipäälliköiden on oltava valmiina huomaamaan, kun pääarkkitehtuurisuunnitelma ei toimi, jotta voidaan tehdä isoja päätöksiä.
poliittiset konfliktit
poliittisten tekijöiden syyttäminen teknisestä viasta voi tuntua nihkeältä, mutta se on yhä enemmän totta. Koska projektit kasvavat isommiksi ja kattavat useita organisaatioita, ei pitäisi olla yllätys, että ryhmittymät näkyvät ja ryhmät jockey valvontaa, resursseja ja lopulta valtaa.
poliittiset ryhmittymät eroavat todellisista teknisistä eroista. On usein teknisiä standardeja tai koodipohjia, jotka tekevät paljon samaa asiaa eri tavoin. Ota XML ja JSON. Nyt kun olen kirjoittanut, että, voin tuntea fanit joko kiirehtivät selittää, miksi he eivät ole sama ja heidän suosikki valinta on oikea. Mutta kun yksi osa tiimistä rakastaa yhtä valintaa ja toinen pitää kilpailevaa ryhmää suuressa arvossa, kitka repii heidät kappaleiksi.
tämä on yleistynyt entisestään arkkitehtien jakaessa sovelluksia useisiin, pienempiin palveluihin ja sovellusliittymiin. Eri ryhmät päätyvät kontrolloimaan näitä, eivätkä ne aina tule toimeen keskenään. Jos ryhmä A tykkää JSON ja ryhmä B takertuu XML, hyvin, joukkue joko täytyy toteuttaa molemmat tai saada yksi niistä muuttaa. Kaikki kolme ovat tuskaa mille tahansa joukkueelle, joka joutuu työskentelemään sekä A-että B-ryhmän kanssa.
vedonlyönti tekniikasta, joka ei ole valmis tuotantoon
ohjelmoijat rakastavat uusimpia työkaluja ja kehyksiä. He haluavat uskoa, että uusi lähestymistapa pyyhkii pois kaiken sen julman, mikä kaataa edellisen sukupolven.
mutta usein seuraava sukupolvi ei ole valmis tuotantokäyttöön. Uudet ominaisuudet voivat tuntua täydellisiltä, mutta niissä on usein aukkoja, jotka eivät ole heti ilmeisiä. Joskus koodi tukee vain muutamaa tiedostotyyppiä tai rajapintoja, joissa on vain muutama tietokanta. Muut ovat tulossa pian, he vakuuttavat, mutta projekti on toimitettava tässä kuussa ja ”pian” voisi tarkoittaa kuusi tai enemmän kuukautta ennen ominaisuuksia tarvitset ovat valmiita.
vedonlyönti pian vanhentuvaan tekniikkaan
kokemukseni mukaan vanhat jutut ovat yleensä luotettavampia ja taistelutestattuja, mutta se ei tarkoita, että vanha teknologia olisi täydellistä. Ominaisuudet voivat puuttua, jotka ovat elintärkeitä ohjelmistoprojekti, kun se menee elää. Pahempaa, vedonlyönti vanha tech voi aiheuttaa voit menettää tulevaisuuden mahdollisuuksia perustuu muutoksiin linjan. Uusia ideoita, protokollia ja tiedostomuotoja ilmestyy, ja ne voivat jäädä toteuttamatta. Ja jos joku kilpailevasta tiimistä vaatii, että kannatat jotain uutta protokollaa, niin vanha tekniikka sattuu.
epärealistiset määräajat
määräajat ovat hankalia. Monien hankkeiden on ehdittävä markkinoille tiettyyn vuodenaikaan tai tapahtumaan mennessä. Silti kun määräajat on ensin kirjoitettu ylös, kehittäjät eivät ole alkaneet löytää tiesulkuja ja esteitä tiellään. Jos projekti sitten lipsahtaa ja tapahtuma menee ohi ilman ohjelmiston käynnistämistä, koko projekti nähdään epäonnistumisena, vaikka koodi olisi juuri sujumassa ongelmitta. Määräajat auttavat kaikkia keskittymään ja vetämään yhtä köyttä, mutta ne luovat myös odotuksia, jotka voivat olla epärealistisia.
ennakoimaton kilpailu
hyvä tuotepäällikkö kartoittaa kilpailun ennen sukellusta, mutta kukaan ei osaa ennustaa, mitä kilpailu saattaa ilmestyä tyhjästä. Jos uudet kilpailijat ottavat käyttöön uusia ominaisuuksia, jotka sinun täytyy kopioida, No, katso osiot ominaisuuksien muutoksista ja prioriteettieroista, yllä.
prosessin kiirehtiminen
monet ohjelmistoprojektit alkavat ihmisen tai tiimin visiona, joka haluaa korjata jotain. He keksivät lauseen, kuten ”Snapchat Y: lle” tai ”Uber y: lle”, ja odottavat sitten tuotetiimin olevan yhtä reagoiva kuin Snapchat tai Uber. Ongelmana on, että projektin laajuuden selvittäminen, tietovirtojen luonnostelu ja käyttöliittymän kuvitteleminen ovat usein kymmenen kertaa niin paljon työtä kuin koodin kirjoittaminen. Mutta mielikuvituksen tekijät haluavat siirtyä ideasta koodiin saman tien.
rautalangat, tietokantarakenne ja käyttäjätarinat eivät ole vain käden heiluttelua, vaan olennainen osa työtä. Mutta useimmat ihmiset haluavat uskoa, että ohjelmistoprojekti on vain koodin kirjoittamista idean toteuttamiseksi.
väärä usko ohjelmistojen voimaan
Unelmoijilla on usein epärealistisia uskomuksia ohjelmistojen voimasta muuttaa maailmaa. Moni kuvitteli, että sosiaalinen media yhdistäisi meidät, mutta jotenkin se on vain paljastuneita vikalinjoja, jotka ovat aina olleet ilmeisiä. Ohjelmistoprojektit alkavat usein slide-kansilla, jotka lupaavat mullistaa jonkin maailmankolkan. Kun bittien tunkeminen tietokantaan ei muuta ketään, ihmiset suuttuvat, kyllästyvät, hämmentyvät tai pahempaa. He sanovat, että ohjelmisto on rikki, koska se ei tuota maagista muutosta, jota kaikki odottivat.
monet ohjelmistoprojektit voivat laatia, läpäistä QA: n, lähettää ja jopa saada kunnollisia arvosteluja, mutta eivät lopulta saavuta mitään diakannen lupauksista, koska, no, nuo maailman muutosta koskevat lupaukset ovat mahdottomia.
pahat alihankkijat
rakastamme myyjiä, jotka tuottavat kirjastot ja työkalut, joiden avulla voimme luoda taikoja vain muutamalla koodirivillä. Joskus he saavat vihiä voimastaan ja käyttävät sitä projektin tuhoamiseen. Version 1.0 budjetti oli niin hyvä, että johto ei epäröinyt hyväksyä versiota 2.0. Sitten myyjä päättää puristaa meitä kolminkertaistamalla tai viisinkertaistamalla hinnan.
tämä vaikutus voi tuntua silloinkin, kun myyjät eivät tee sitä tahallaan. Ilmaiset tasot voivat saada projektin näyttämään erittäin halvalta. Sitten kun kysyntä kasvaa huimasti ja toinen versio laajentaa kysyntää, todelliset hinnat potkivat sisään.
meren muutos
pandemioiden ja protestien vuodessa mikään ei ole muuttunut nopeammin kuin zeitgeist. Nostiko projekti vahvan yksityisyyden suojan keskeiseksi piirteeksi? Hups. Pandemia on saanut kaikki kiinnostumaan kontaktien jäljittämisestä. Halusiko joku keskittyä työmatkailuun? Hups. Hotelliala on romahtanut. Isommat ohjelmistoprojektit, jotka voivat kestää vuoden tai kauemmin, ovat vaarassa joutua mullistavien tapahtumien varjoon. Alussa upealta tuntunut idea saattaa tuntua toivottoman eksyneeltä ja irralliselta, kun on aika lähteä livenä.
tekniset muutokset
kyse ei ole vain muutoksista koko maailmassa. Vuorovesimuutoksilla teknisessä yhteisössä voi olla sama vaikutus. NoSQL oli aikoinaan nerokas idea, joka vapauttaisi meidät relaatiosuunnitelmasta. Sitten joku tajusi, että tiedostot paisuivat, koska jokainen levy sisälsi paikallisen skeeman. Hyvä ketterä kehitystiimi voi muuttua, kun teknologiset merenmuutokset muuttavat johdon ja asiakkaiden asenteita. Mutta ketterimmätkään joukkueet eivät pärjää isoille muutoksille, jotka imevät kaiken ilman heidän arkkitehtisuunnitelmistaan. Järjestelmä rakennettiin olettaen, että X oli loistava idea ja yhtäkkiä X on likaa. Joskus on parasta räjäyttää se ja tähdittää uudelleen.
liian monta lisäystä
jotkut ohjelmistoprojektit käynnistyvät hyvin ja jopa lähtevät onnistuneesti. Sitten joku lisää ylimääräisen ominaisuuden tai kolme, oksastamalla uutta koodia olemassa olevaan versioon siten, että koodi jatkaa ontua pitkin. Sankarillinen kehittäjät voivat vetää tämän pois useita kertoja, varsinkin jos alkuperäinen arkkitehti suunniteltu hyvin. Jossain vaiheessa perusta kuitenkin murenee. Ehkä tietokanta ei kestä kuormaa. Ehkä on liian monta liittymistä tarvitaan tyydyttämään eri kyselyt. Hyvä ohjelmisto voi saada liian rasvaa, joskus ansiosta pieniä parannuksia, jotka työnsi sen reunan yli.
Moving goal posts
alkuperäisissä suunnitelmissa tarvittiin tietokanta, joka seuraisi asiakkaiden menoja markkinointisuunnitelmien helpottamiseksi. Sitten joku neropatti lisäsi ominaisuuden, joka korreloi tekoälyn avulla menoja sääennusteen kanssa. Tai joku muu halusi ohjelmiston tarjoavan automaattisesti hakukonemainoksia. Kohteen muuttaminen voi upend projekti.
on harvinaista, että muutokset pilaavat asioita itsestään. Uudet tavoitteet voivat kuitenkin paljastaa heikkouksia ja laukaista vikatiloja. Ehkä tiimi on nyt liian pieni saattaakseen projektin onnistuneesti päätökseen. Ehkä tekninen perusta on hurjan tehoton uudelle lähestymistavalle. Kaikkien on vaikea ennakoida fretful combinatorics, kun päätetään muuttaa tavoitteita.