IT projektmenedzsment | írta: Duncan Haughey | read time minutes
kezdjük néhány aggasztó statisztikával. A szoftverprojektek mindössze 29% – a volt sikeres, 52% – uk kifogásolta (költségtúllépések, költségvetési túllépések vagy tartalmi hiányosságok), 19% – uk pedig kudarcot vallott, a Standish Group 2015-ös jelentése szerint. Míg ezek az eredmények először néhány évvel ezelőtt jelentek meg, az eredmények ma sem kevésbé igazak.
ezenkívül az ügyfél által értékesnek ítélt projektek aránya 59%, Az Ügyfél által kielégítőnek ítélt projektek aránya pedig 56%.
a nem kielégítő projekteredmények olyan informatikai iparági normává váltak, ahol az ügyfél nem volt elégedett az eredménnyel. Szóval mit tehetünk ellene?
jó kiindulópont a szoftverprojektek kudarcának néhány kritikus okának kezelése.
1.ok: nincs elég idő
gyakran előfordul, hogy a határidő a projekt megkezdése előtt eldől, és nem tárgyalható. Ez a határidő hanyatt-homlok rohanást eredményez az induláshoz a feltételezés alapján, minél hamarabb elkezdi a kódolást, annál hamarabb befejezi a projektet.
a kódolás elindításának rohanása szinte mindig rossz megközelítés. Elengedhetetlen, hogy időt töltsön a jó formatervezés megteremtésére. A jó tervezés hiánya folyamatos változásokhoz vezet a fejlesztési szakaszban. Amikor ez megtörténik, Az idő és a költségvetés gyorsan elfogy.
megoldás:
- ne legyen kísértés, hogy egyenesen ugorjon be és kezdje el a kódolást.
- rendeljen elegendő időt egy jó terv elkészítéséhez, és a projekt többi része sokkal jobban fog futni.
ez a megközelítés javítja a hírnevét, ha olyan terméket szállít, amely megfelel az ügyfelek elvárásainak, és az első alkalommal megfelelően működik.
2.Ok: elégtelen költségvetés
sok projekt rendelkezik a legalacsonyabb árral, a legsikeresebb beszállítói politikával vagy irreálisan alacsony költségvetéssel, amely nem a projekt követelményein alapul. Amikor ez megtörténik, minden lelassul. Az erőforrások lassan érkeznek, vagy soha nem érkeznek meg; a sarkok levágódnak, a minőség pedig szenved.
megoldás:
- legyen reális a költségvetéssel kapcsolatban, és alapozza meg a teljes követelményekre.
- kerülje a szállító kiválasztását kizárólag a legalacsonyabb ár alapján.
- menjen olyan szállítóhoz vagy csapathoz, akinek bizonyított tapasztalata van a költségvetésen belüli teljesítésről.
- használjon egy beszállítói kiválasztási ellenőrzőlistát, például az alábbiakat, hogy megtalálja a projekthez megfelelő szállítót.
3. Ok: Gyenge kommunikáció
van egy mondás, “Soha ne feltételezz semmit”, ami különösen igaz a szoftverprojektekre. A jó kommunikáció az ügyféllel, a felhasználókkal és a fejlesztőcsapattal elengedhetetlen a projekt sikeréhez. Tegyen fel magának három kérdést:
- a csapatban mindenki megért téged?
- tudják, mit vársz tőlük, vagy feltételezted, hogy tudják?
- jól kommunikálnak egymással, a felhasználókkal és más osztályokkal?
megoldás:
- Keressen bármilyen kommunikációs bontást most. Ezek zavart és komplikációkat okozhatnak a projekt későbbi szakaszában.
- soha ne feltételezzük, hogy mindenki megérti mindazt, ami a projekten történik.
- szánjon időt arra, hogy olyan környezetet teremtsen, ahol a kommunikáció hozzáférhető, nyitott és gyakori.
4.ok: soha nem vizsgálja felül a projekt előrehaladását
a projekt előrehaladtával a dolgok megváltoznak, ami jelentősen befolyásolja a projektet. Fontos, hogy folyamatosan vizsgáljuk a projekt előrehaladását a kihívások korai leküzdése érdekében, és figyelmeztessük az érdekelt feleket a lehetséges késedelmekre és az eredmények változására.
megoldás:
- mindig állítson be mérföldköveket a csapat és az érdekeltek előrehaladásának áttekintéséhez a projekt során. Állítsa be, ha szükséges, hogy a pályán maradjon.
- maradj közel a csapatodhoz, hogy megértsd, mi történik és milyen kihívásokkal néznek szembe.
5.ok: nem megfelelő tesztelés
amikor a szállítandó nyomás be van kapcsolva, a tesztelés gyakran szenved. A tesztelés a fejlesztési ciklus végéig marad, minimális erőfeszítéssel a tesztelésre. Általában az eredmény egy hibákkal teli termék és egy boldogtalan ügyfél.
megoldás:
- végezzen tesztelést a fejlesztési életciklus során, tesztelve az egyes modulokat vagy komponenseket a fejlesztés során.
- az integrációs tesztelést csak a fejlesztési életciklus végéig hagyja, ami kevesebb stresszt és jobb terméket eredményez.
6.ok: tesztelés termelési környezetben
meglepő, hogy hány szervezet teszteli a termékeket termelési környezetében. A termelési környezet használata magas kockázatú stratégia, amely biztonsági megsértésekhez és tesztelés nélküli véletlen kibocsátáshoz vezethet, megzavarva a termelési rendszereket.
megoldás:
- minőségbiztosítási folyamat kidolgozása és új szoftvertermékek kiadása.
- a gyártási környezettől elkülönített környezetet biztosít a teszteléshez és a hibajavításhoz.
7.ok: a minőségbiztosítás hiánya
gyakran sietünk a szoftver szállításához, a minőségbiztosítás szenved. A dokumentáció hiányos a kódváltozásokhoz, a tervezés hibákat tartalmaz, a megvalósítások pedig befejezetlenek lehetnek. Ezek mind átdolgozáshoz, elvesztegetett időhöz és végül boldogtalan ügyfelekhez vezetnek.
megoldás:
- szánjon időt a minőségellenőrzésre és a szoftver dokumentálására a kiadás előtt.
- áttekintés Michael L Young 6. cikk sikertényezők a projekt minőségének kezelésében
8. ok: Nem felel meg az ipari szabványoknak
az ipari szabványoknak való megfelelés a szoftverprojektekben előnyösnek bizonyulhat a jó hozzáférhetőség, hordozhatóság, használhatóság, robusztusság biztosításával, valamint a jelenlegi és jövőbeli problémák csökkentésével. Az olyan szervezetek, mint a World Wide Web Consortium (W3C) és a Nemzetközi Szabványügyi Szervezet (ISO) olyan nyílt szabványokat dolgoztak ki, amelyeket nehéz megkérdőjelezni.
megoldás:
- szánjon időt arra, hogy szabványos megközelítést vezessen be projektjeihez.
- keresse meg, mi működik jól, és folytassa.
- változtasson meg mindent, ami nem működik.
- rendszeresen ellenőrizze és frissítse szabványait.
legközelebb, amikor szoftverfejlesztési projektet irányít, tekintse át ezt a listát, és emlékeztesse magát arra, hogy mi szükséges a siker biztosításához. Meg fog lepődni; ez különbséget tesz.
ajánlott olvasmány: Jorge Dominguez A KÁOSZJELENTÉS furcsa esete 2009.