Különbségek a klasszikus és az agilis projektmenedzsment között (1. rész) - a projektek egyszerűvé váltak
Klasszikus vagy agilis - a projektmenedzsment két módszere, amelyek nem különbözhetnek egymástól: Persze, minden projektmenedzser sikeresnek akarja vezetni a projektjét, de a két megközelítés alapötletei és eljárása teljesen ellentétesnek tűnik. Ezt nem utolsósorban heves viták fejezik ki arról, hogy melyik módszer a "jobb". De vajon van-e „jobb” ez a takaró? Aligha valószínű! Köztudott, hogy az eszközök csak akkor működnek, ha a célnak megfelelően vannak kiválasztva. Az "Agile, classic & Co: Melyik projektmenedzsment módszertan alkalmas?" Cikkben többet megtudhat a módszertan helyes megválasztásáról.
Tehát hogyan választhatja ki az egyik vagy másik megközelítést? Először is tudnia kell, mi mindenbe keveredik az egyes módszerekkel. Ez konkrétan azt jelenti: Mit jelent az elkötelezettség a projektje szempontjából, és miben különbözik a két megközelítés. Az Ön számára megkönnyítése érdekében a következő cikk az első egy 4 cikkből álló sorozatban, amelyben elmagyarázzuk a különbségeket klasszikus és agilis alulra kerülni.
A sorozat elején három nagyon alapvető különbséggel indulunk:
Veszély: A kifejezések mögött klasszikus és agilis Nagyon sok különböző folyamatmodell, keret és megvalósítás van elrejtve. A gyakorlatban van néhány vegyes megközelítés, a legváltozatosabb jellemzőkkel. Egy klasszikusan szervezett projekt agilis alprojekteket tartalmazhat. Még akkor is, ha egy projekt hivatalosan 100% -osan követi az egyik vagy másik tanítást, és a keretrendszer rögzítve van, az ügyes projektvezető gyakran talál gyakorlati megoldást az ebből adódó problémák kezelésére. Ebben a sorozatban nem megyünk ilyen vegyes formákra és megoldásokra, hanem szándékosan vesszük figyelembe a "klasszikus" és az "agilis" szélsőséges formáit a jobb megértés érdekében.
Késői visszajelzés a korai visszajelzéssel szemben
Az ügyfél szempontjából a klasszikus és az agilis eljárások közötti különbségek akkor válnak különösen világossá, amikor A visszajelzés ideje és gyakorisága figyelembe kell venni: Mikor tud az ügyfél (vevő, végfelhasználó, ...) visszajelzést adni a projekt eredményéről/termékéről?
Klasszikus projektmenedzsment:
Az eredményt gyakran csak a projekt végén mutatják be az ügyfélnek. Ez lehet például a projektben kifejlesztett termék. Annak érdekében, hogy ez ne essen rosszul, és ez a termék valóban megfeleljen a vásárló elvárásainak, a projekt elején nagy gondot kell fordítani a követelmények meghatározására. Általában egy követelményspecifikáció készül, amely a projekt végén képezi az alapját az ügyfél elfogadásának. Tehát a visszajelzések csak a legvégén érkeznek.
Példák:
- Egyedi készítésű szivattyú szennyvíztisztító telephez, egyértelmű műszaki követelményekkel és specifikációkkal
- Marketingesemény megvalósítása új okostelefon bemutatására
- A hatóság alkalmazottainak képzése az "új adatvédelmi szabályok" témájában
Veszély: A klasszikus projektmenedzsmentben természetesen lehetőség van arra is, hogy az ügyfél visszajelzést adjon a projekt végrehajtása során. Példák kérem?
- A fent bemutatott fejlesztési projektben az ügyféllel folytatott konzultációt a tervezési szakasz befejezése után lehet megtartani.
- A dolgozók képzésének példáján a kidolgozott képzési koncepció bemutatható a hatóság vezetőségének jóváhagyásra.
A klasszikus projektmenedzsmentben az ilyen visszacsatolási pontokat elsősorban arra használják, hogy ellenőrizzék, a projekt még mindig jó úton halad-e annak érdekében, hogy megakadályozzák a rosszabb dolgok bekövetkezését. Ha egy ilyen ponton szükség van a tanfolyam korrekciójára, ez általában jelentős átütemezési erőfeszítéseket jelent - a projekt gyakran drága és késik.
Agilis projektmenedzsment:
Az ügyfél rendszeres ciklusokban kap alfunkciókat vagy terméknövekedéseket az értékeléshez - kifejezetten visszajelzésre és kritikára van szükség. Ez csak akkor működik, ha a projekt eredményét fel lehet bontani egymás után generálható, majd megvizsgálható/értékelhető növekményekre. Az első példa a szoftver fejlesztése - az a terület, ahol az agilis ötlet ered.
Az ábra bemutatja az eljárást a Scrum keretrendszer példájával az agilis projektmenedzsmentben:
Változó követelményekkel rendelkező, nem biztonságos környezetben az előny nyilvánvaló: A teljes termék hosszú időn át történő fejlesztése helyett mindenki részt vesz rendszeres betekintésben a projekt előrehaladásába. A követelmények módosíthatók, és meghatározhatók a következő lépések. Ily módon a későbbi kiterjedt kiigazítások automatikusan megszűnnek. A klasszikus projektmenedzsmenttel szemben nem áll fenn annak kockázata, hogy a követelmények változása észrevétlen marad, vagy a legrosszabb esetben a termék megkerülhető a piacon.
Példák:
- Weboldal fejlesztése online boltral és számos egyéb részletes funkcióval
- Vezérlő szoftver fejlesztése új motortervezéshez
- Egy családi ház tervezése építészeti iroda által
Meghatározott folyamatok az innovációval szemben
A tizenharmadik előregyártott ház építése „a csapszegtől függetlenül” az összes konfigurációs lehetőség ellenére óriási mértékben eltér az innovatív alkalmazás fejlesztésétől - és ezért az eljárás is jelentősen eltér:
Klasszikus projektmenedzsment:
A klasszikusan tervezett és megvalósított projektek különösen alkalmasak olyan projektekre, amelyek meghatározott folyamatokat követnek, amelyek során jól érthető részletes megoldásokat/komponenseket alkalmaznak, és amelyekből kiszámítható eredmény születhet. A bevált és meghatározott lépések előre meghatározott eredményhez vezetnek.
Példák:
- Egyetlen családi ház építése "le a csapról"
- A vállalati kiszolgáló tájának frissítése
Agilis projektmenedzsment:
Az agilis projektmenedzsmentet gyakran használják dinamikus környezetekben: a termékfejlesztésben, a kutatásban és a szoftverfejlesztésben. Gyakran nem lehet egyértelműen megjósolni, hogy az eredmény részletesen hogyan fog kinézni, és mely megközelítések hozzák a legjobb megoldást - az elején egyszerűen senki sem tudja. Egy adott tervnek vagy folyamatnak kevés értelme van, elvégre valami újat kell létrehozni. Ha úttörő újításokat kívánnak létrehozni, nincs szabványos recept, amelyet közvetlenül lehetne alkalmazni.
Példák:
- A laptop kijelző optimalizálása új, még nem teljesen ismert technológiával
- Egy innovatív alkalmazás fejlesztése a fogyáshoz
Szekvenciális fejlesztés vs. iteratív fejlődés
Előre meghatározott, egymást követő lépésekben a cél felé - vagy rövid ciklusokban? A projektmenedzsment módszertanai itt jelentősen eltérnek. Ez a pont szorosan kapcsolódik a visszacsatolási gyakorisághoz (lásd fent):
Klasszikus projektmenedzsment:
A hagyományosan megvalósított projektekben a meghatározott fázisokat az elején egymás után dolgozzák fel. Amikor egy fázis vagy egy feladatblokk elkészült, a következő kezdődik. Elvileg a fázisok is átfedhetnek, de legalább egy alprojekten belül soha nem kerülnek feldolgozásra körülbelül párhuzamosan, hanem lényegében egymás után.
Ez a megközelítés azon a feltételezésen alapul, hogy minden információ rendelkezésre áll a projekt elején. Ezeket követelményekbe és tervekbe csomagolják, majd megkezdődik a megvalósítás.
Példa: Csak akkor kezdődik a programozás, ha a weboldal megtervezése teljesen befejeződött.
Agilis projektmenedzsment:
Az agilis projektmenedzsmentben az elején nem mindent határozunk meg részletesen. Az alapötlet: az emberek nem láthatják előre az összes részletet, sőt az ügyfelek sem tudják pontosan, mit akarnak, és milyen lehetőségek állnak rendelkezésre az elején. Emiatt kis egységeket valósítanak meg, ezeket ellenőrzik és szükség esetén fejlesztik.
Ismétlődő:
Az iteratív megközelítés azon a feltételezésen alapul, hogy sok mindent gyakran helytelenül vagy nem ideálisan oldanak meg az első lépésben, mielőtt a hibákat a következő lépésben kijavítanák. Nyersen fogalmazva: Az első dobás a szemetesre szól, de tanulhatunk belőle és építhetünk rá. Vagy másképpen: Az első dobás javaslat az ügyfél számára. A többszöri próbálkozást tehát nem hibának tekintik, hanem eleve az eljárás részeként tervezik meg.
példa: Ahelyett, hogy egy új weboldal részletes tervezetét minden részletében benyújtanák, durva vázlatok készülnek, korábbi verziók készülnek, és ezeket fokozatosan finomítják az ügyféllel egyeztetve.
Járulékos:
Az inkrementális megközelítéssel a nagy darabokat részfeladatokra bontják, és ezek egymás után teljesülnek. A háttér: Ha egy kis alkatrész épül, akkor ismeretek szerezhetők és alkalmazhatók más funkciókra is.
Példa: Ahelyett, hogy egy új vállalat jelenlétének összes aloldalát megtervezné, eredetileg csak a kezdőlap jön létre.
Következtetés
Minden alkalmazáshoz a megfelelő eszköz kiválasztása a trükk! Ebben a cikkben megismerhette az első három különbséget a klasszikus és az agilis projektmenedzsment között. Kíváncsi többet megtudni? A 2. részben folytatódik!