Rozdiely medzi klasickým a agilným riadením projektu (časť 1) - projekty sú jednoduché
Klasické alebo agilné - dve metodiky projektového riadenia, ktoré sa nemôžu líšiť: Iste, každý projektový manažér chce viesť svoj projekt k úspechu, ale základné myšlienky a postup oboch prístupov sa zdajú úplne opačné. Toto sa vyjadruje v neposlednom rade v búrlivých debatách o tom, ktorá metóda je „lepšia“. Ale je táto deka „lepšia“? Ťažko pravdepodobné! Je dobre známe, že nástroje fungujú, iba ak sú na tento účel vybrané vhodným spôsobom. V článku „Agile, classic & Co: Kedy je vhodná metodika riadenia projektu?“ Viac informácií o správnom výbere metodiky sa dozviete.
Ako si teda zvoliť jeden alebo druhý prístup? Najskôr musíte vedieť, do čoho idete pri každej metóde. Konkrétne to znamená: Čo znamená záväzok pre váš projekt a v čom sa tieto dva prístupy líšia. Aby sme vám to uľahčili, nasledujúci článok je prvým zo série 4 článkov, v ktorých vysvetľujeme rozdiely medzi nimi klasický a agilný dostať dnu.
Na začiatku série začíname tromi veľmi zásadnými rozdielmi:
Nebezpečenstvo: Za podmienkami klasický a agilný Skrýva sa veľa rôznych procesných modelov, rámcov a implementácií. V praxi existuje niekoľko zmiešaných prístupov s najrôznejšími charakteristikami. Klasicky organizovaný projekt môže obsahovať svižné čiastkové projekty. Aj keď projekt oficiálne sleduje jedno alebo druhé učenie na 100% a rámec je pevne stanovený, dôvtipný manažér projektu často nájde pragmatické riešenie, ako sa s výslednými problémami vyrovnať. V tejto sérii nejdeme do tak zmiešaných foriem a riešení, ale aby sme lepšie porozumeli, zámerne zvažujeme extrémne formy „klasickej“ a „agilnej“.
Neskorá spätná väzba vs. skorá spätná väzba
Z pohľadu klienta sú rozdiely medzi klasickými a agilnými postupmi zvlášť zreteľné, keď Čas a frekvencia spätnej väzby treba brať do úvahy: Kedy môže alebo musí (alebo môže) klient (zákazník, koncový používateľ, ...) poskytnúť spätnú väzbu k výsledku/produktu projektu?
Klasické riadenie projektu:
Výsledok sa zákazníkovi často prezentuje až na konci projektu. Môže to byť napríklad produkt vyvinutý v rámci projektu. Aby sa to nepokazilo a tento produkt skutočne spĺňal očakávania zákazníka, je potrebné pri definovaní požiadaviek na začiatku projektu venovať veľkú pozornosť. Zvyčajne sa vytvorí špecifikácia požiadavky, ktorá je základom pre prijatie zákazníkom na konci projektu. Spätná väzba teda prichádza až na samom konci.
Príklady:
- Zákazkové čerpadlo pre čističku odpadových vôd s jasnými technickými požiadavkami a špecifikáciami
- Realizácia marketingovej udalosti pre predstavenie nového smartfónu
- Školenie zamestnancov orgánu v oblasti „nových pravidiel ochrany údajov“
Nebezpečenstvo: V klasickom projektovom manažmente je samozrejme možnosť dať klientovi možnosť poskytnúť spätnú väzbu počas realizácie projektu. Príklady prosím?
- Vo vyššie uvedenom vývojovom projekte sa mohli konzultácie s klientom uskutočniť po skončení fázy návrhu.
- Na príklade školenia zamestnancov by sa mohla vyvinutá koncepcia školenia predložiť vedeniu orgánu na schválenie.
V klasickom projektovom manažmente sa takéto body spätnej väzby primárne používajú na kontrolu, či je projekt stále na dobrej ceste, aby sa predišlo zhoršeniu situácie. Ak je v takom okamihu potrebná korekcia kurzu, zvyčajne to vyžaduje značné úsilie v oblasti preplánovania - projekt je často drahý a oneskorený.
Agilné riadenie projektu:
Zákazník dostáva v pravidelných cykloch čiastočné funkcie alebo prírastky produktu na posúdenie - je výslovne požadovaná spätná väzba a kritika. Funguje to iba vtedy, ak je možné výsledok projektu dobre rozdeliť na prírastky, ktoré je možné generovať jeden po druhom a potom ich preskúmať/posúdiť. Ukázkovým príkladom je vývoj softvéru - oblasti, z ktorej pochádza svižná myšlienka.
Obrázok ukazuje postup na príklade rámca Scrum v agilnom riadení projektu:
V nebezpečných prostrediach s meniacimi sa požiadavkami je výhoda zrejmá: Namiesto dlhodobého vývoja kompletného produktu dostávajú všetci zúčastnení pravidelný prehľad o priebehu projektu. Je možné upraviť požiadavky a definovať ďalšie kroky. Týmto spôsobom sa automaticky vylúčia rozsiahle následné úpravy. Na rozdiel od klasického projektového riadenia neexistuje riziko, že zmeny požiadaviek zostanú nezistené alebo v najhoršom prípade dôjde k obídeniu produktu na trhu.
Príklady:
- Vývoj webových stránok s online obchodom a mnohými ďalšími podrobnými funkciami
- Vývoj riadiaceho softvéru pre nový dizajn motora
- Projektovanie rodinného domu architektonickou kanceláriou
Definované procesy vs. inovácie
Stavba trinásteho panelového domu „off the peg“ sa napriek všetkým možnostiam konfigurácie enormne líši od vývoja inovatívnej aplikácie - a preto sa bude výrazne líšiť aj postup:
Klasické riadenie projektu:
Klasicky plánované a realizované projekty sú obzvlášť vhodné pre projekty, ktoré sledujú definované procesy, v ktorých sa používajú dobre pochopené podrobné riešenia/komponenty a z ktorých by mal vyplynúť predvídateľný výsledok. Osvedčené a definované kroky vedú k vopred určenému výsledku.
Príklady:
- Stavba rodinného domu „na kolíku“
- Aktualizácia serverového prostredia v spoločnosti
Agilné riadenie projektu:
Agilné riadenie projektov sa často používa v dynamických prostrediach: pri vývoji produktov, výskume a vývoji softvéru. Často nie je možné jasne predpovedať, ako bude výsledok vyzerať podrobne a ktoré prístupy prinesú najlepšie riešenie - na začiatku to jednoducho nikto nevie. Daný plán alebo proces nemá veľký zmysel, koniec koncov by malo vzniknúť niečo nové. Ak majú vzniknúť priekopnícke inovácie, neexistuje žiadny štandardný recept, ktorý by sa dal priamo aplikovať.
Príklady:
- Optimalizácia displeja notebooku pomocou novej technológie, ktorá ešte nie je úplne pochopená
- Vývoj inovatívnej aplikácie na chudnutie
Postupný vývoj vs. iteračný vývoj
Vo vopred stanovených, postupných krokoch k cieľu - alebo v krátkych cykloch? Metodiky projektového riadenia sa tu značne líšia. Tento bod úzko súvisí s frekvenciou spätnej väzby (pozri vyššie):
Klasické riadenie projektu:
V tradične realizovaných projektoch sa definované fázy na začiatku spracovávajú jedna po druhej. Po dokončení fázy alebo bloku úloh sa začne ďalšia. Fázy sa v zásade môžu aj prekrývať, ale minimálne v rámci podprojektu sa nikdy nespracovávajú približne paralelne, ale v podstate jedna po druhej.
Tento prístup je založený na predpoklade, že všetky informácie sú k dispozícii na začiatku projektu. Tieto sú zabalené do požiadaviek a návrhov a potom sa začína s implementáciou.
Príklad: Programovanie sa začne až po úplnom dokončení dizajnu webových stránok.
Agilné riadenie projektu:
V agilnom riadení projektu nie je na začiatku všetko podrobne definované. Základná myšlienka: ľudia nemôžu vopred vidieť všetky podrobnosti a ani klienti nevedia presne, čo chcú a aké možnosti sú na začiatku k dispozícii. Z tohto dôvodu sú implementované malé jednotky, ktoré sú skontrolované a v prípade potreby vylepšené.
Iteratívne:
Iteračný prístup je založený na predpoklade, že v prvom kroku je veľa vecí často nesprávne alebo nie ideálne vyriešených skôr, ako sa chyby opravia v ďalšom kroku. Povedané na rovinu: Prvý žreb je za kôš, ale môžeme sa z neho poučiť a na ňom stavať. Alebo inak: Prvý hod je návrhom pre klienta. Viaceré pokusy sa preto nepovažujú za chyby, ale skôr sa plánujú ako súčasť postupu od samého začiatku.
príklad: Namiesto priameho predloženia podrobného konceptu novej webovej stránky so všetkými jej podrobnosťami sa vytvárajú hrubé náčrty, vytvárajú sa predchádzajúce verzie a tieto sa postupne dolaďujú po konzultácii so zákazníkom.
Prírastkové:
Postupným prístupom sa veľké časti rozdelia na čiastkové úlohy a tieto sa postupne dokončujú. Pozadie: Ak sa vytvorí malá časť, je možné získať vedomosti a aplikovať ich na ďalšie funkcie.
Príklad: Namiesto navrhovania všetkých podstránok novej spoločnosti sa najskôr vytvorí iba úvodná stránka.
Záver
Výber správneho nástroja pre každú aplikáciu je často trik! V tomto článku ste spoznali prvé tri rozdiely medzi klasickým a agilným riadením projektu. Zaujíma vás, či sa chcete dozvedieť viac? Pokračuje sa v časti 2!