Suurimad väljakutsed kohandatud tarkvara arendamisel

Tehnoloogiatööstuses leiate korduvalt, et koguni 50-70% of *tüüpi tarkvaraarendusprojektid lõppeb ebaõnnestumine. See iidne probleem on paljude jaoks õudusunenägu. CTOs ja tehnikajuhid. Teisest küljest tähendab eelhoiatus seda, et saate ennast ja oma meeskond ja minimeerida ebaõnnestumise riski. See on väljakutse, mida iga arendusmeeskond peab lahendama, toode disainerid ja teie - kui juht - peaksid kohtuma.*

Ma ei kahtle, et kohandatud tarkvara projektid on nõudlikud ja edu saavutamiseks tuleb hoolitseda ka kõige väiksemate detailide eest. Ausalt öeldes, kui ma olen vaadanud sellekohast statistikat, olen ma hämmastunud probleemi ulatuse üle. Mina isiklikult mõistsin, kui lugesin lugusid ettevõtetest, kelle koostöö tehnikapartneritega lõppes ebaõnnestumisega või nende meeskond kaotas projekt märkimisväärse eelarve- või tähtaja ületamise tõttu.

Ma hakkasin imestama, miks see nii on. Mul on mitu aastat kogemusi kohandatud tarkvara arendusprojektid, nii et mind huvitas see teema eriti. Otsustasin, et oma kogemustele tuginedes tuvastan kõik suurimad ohud, mis on seotud *tüüpi tarkvaraarendus, mida ma nüüd teiega jagan.*

Minu isiklik nimekiri suurimatest väljakutsetest kohandatud tarkvara arendamisel

1. Keelebarjäär. See on üks levinumaid probleeme, kui inimesed otsivad tehnikapartnerit. Kuid ma ei kahtle, et seda tegurit saab hõlpsasti lahendada. Nimelt tuleb lihtsalt valida tarkvaraarenduse partner kes suudab tagada probleemivaba suhtluse. Sujuv inglise keele oskus on kohustuslik. See on rahvusvaheline keel ja ilma selleta ei saa korralikult suhelda. Kujutage ette olukorda, et soovite rääkida arendajaga mingist probleemist või veast. Kui selgub, et ainus inimene, kes oskab inglise keelt, on projektijuht, kes ei ole tehniline inimene, siis on probleem. Te peate teadma, et arendajatega suhtlemine - et olla tõhus - peab olema väga täpne, mis eeldab inglise keele oskust. Pidage meeles seda lihtsat reeglit.

2. Kehv kommunikatsioon. Suhtlusaspektid on mõnevõrra seotud keelebarjääriga. Lisaks keelele peate olema veendunud, et teie igapäevane koostöö on hästi korraldatud. Minu arvates jäetakse see aspekt sageli tähelepanuta. Arendusmeeskonna pädevus võib olla nende töö oluline osa, kuid sama kehtib ka suhtlemise kohta kliendiga. Pealegi - ja ma tean seda omast kogemusest -, kui vastastikune suhtlusprotsess on korralikult korraldatud, siis kulgeb kogu projekt palju tõhusamalt ja te väldite tarbetuid probleeme, näiteks viivitusi.

3. Tähtaegade rikkumine. See on väga tavaline olukord, mida olete võib-olla ise kogenud. Tarkvaraarendusprojektide ajakava on väga raske hinnata. Sageli on esialgsed eeldused täiesti valed. Tähtaegadest mitte kinnipidamist võivad mõjutada paljud tegurid, sealhulgas need, mida ma käesolevas artiklis kirjeldan. Ma arvan, et siin mängib suurt rolli õige projektijuhtimise meetod. Soovitused? Kindlasti Scrum.

4. Ebapiisavad teadmised. Tarkvaraarendusprojektid nõuavad tavaliselt laialdasi teadmisi tehnoloogiast. See on suur väljakutse, kui arvestada, et tehnoloogia areneb pidevalt ja arendajad peavad olema kõigi uudistega kursis. Selles osas on oluline, et teie enda meeskond oleks tehnoloogiauudiste osas kursis. See ei ole nii iseenesestmõistetav, kui see võib tunduda, eriti kui tarkvaraarendusprojekt viiakse ellu majasisene väikese arendajate rühma poolt. Võib tekkida olukord, kus teie meeskonna pädevus osutub lihtsalt ebapiisavaks, mis võib kiiresti viia probleemide tekkimiseni ja selle tagajärjel projekti ebaõnnestumiseni.

5. Ebakoherentne nägemus. Kujutage ette olukorda, kus te alustate koostööd tehnikapartneriga - näiteks tarkvaramaja ja rääkige oma vajadustest. Kirjeldate üksikasjalikult toodet, mida soovite luua. Alguses näib kõik sujuvat. Aja jooksul selgub aga, et teie nägemus erineb täielikult teie partneri omast. Selle tulemusena tekib probleem, sest arendajate ja tootedisainerite meeskonna töö ei vasta teie ootustele.
   Ma arvan, et see on üsna tavaline probleem. Mõnikord on raske ühendada kliendi nägemust arendajate poolt kasutatavate "kõvade" lahendustega. Sellises olukorras on kindlasti abiks tehnilise meeskonna kogemus ja pehmed oskused. Oluline on, et teie tehniline partner vastaks teie ootustele, kuid kliendina peate olema teadlik, et tarkvarafirma pakutud konkreetne lahendus võib tegelikult osutuda tõhusamaks. Pidage seda meeles.

6. Muudatused projekti käigus. IT-projektide puhul on kõige tavalisemateks ohtudeks ulatuse hiilimine (omaniku poolt) ja kulla istutamine (PM, Scrum Master või arendajad). Kontrollimata muudatused projektis, uute funktsionaalsuste lisamine või muudatuste sisseviimine kuuluvad kahtlemata nii projektide tõhusust kui ka kiirust mõjutavate ohtude alla. Õige lähenemine juhtimisele on tagada, et esimene põhietapp on 100% täpne, sest see mõjutab projekti hilisemat edu.

7. Ebapiisavad vahendid projekti arendamine. Rahastamine on sisuliselt üks olulisemaid tegureid teie projekti edukuse seisukohalt. See on ilmselge. Tahaksin siiski juhtida teie tähelepanu veidi teistsugusele aspektile. Oluline on, et teil oleks tagatud eelarve pikemas perspektiivis, mitte ainult alguses eeldatav arendusperiood. Miks? Põhjus on lihtne. Väga sageli on nii, et arendusaeg pikeneb kuni 20-30% võrra. Seda peate arvestama, et teie projekt oleks rahaliselt kindlustatud. Nii vähendate riski, et teie projekt on veel arendusfaasis, kui eelarvevajadused hakkavad ilmnema. See on otseselt seotud valesti hinnatud projekti kestusega.

8. Määratlemata ohud ja nõrkused. Enne projekti alustamist teate ilmselt, et kogu protsess ei pruugi olla lihtne. Tõenäoliselt nõustute minuga, et iga projekt on väljakutse. Seega arvan, et enne alustamist peaksite analüüsima võimalikke ohte ja nõrkusi, mis võivad lõpptulemust mõjutada. Oluline on selliseid ohte juba algusest peale korralikult hallata.

Kokkuvõte

Ma ei tahaks soovitada, milline eespool loetletud ohtudest on kõige levinum. Ma arvan, et selleks ei ole reeglit - kõik sõltub projekti spetsiifikast. Kui aga seisate silmitsi oma projekti eduka elluviimise väljakutsega, pidage meeles seda, mida ma siin kirjutasin. Arvan, et minu kirjeldatud probleemide arvestamine võib olla teile suunanäitajaks, mis näitab, mida ei tohi teha ja kuidas ohuga toime tulla. Seda kõike selleks, et mitte sattuda jõhkra statistika ohvriks, vaid viia projekt edukalt lõpule.

Ja seda soovin ma teile. Kui teil on küsimusi seoses kohandatud tarkvara arendaminepalun võtke minuga ühendust. Vastan hea meelega kõigile neile.

Loe edasi:

Miks tasub omada äriarenduse eest vastutavat kasvumeeskonda? Codesti juhtumiuuring

Kuidas leida oma tootele sobiv turg?