ITélet - 1
- Lehet-e projektet vezetni kívülről?
- A modern szoftverfejlesztés Mithras kultusza
- Operations Management
- Projekt sikertényező: a kudarc mint kockázat
- Projektvezetés vs piramisépítés
- A kapitány prezentációja
Lehet-e projektet vezetni kívülről?
- a megrendelő oldalon nincs projektvezető, az ezzel kapcsolatos feladatokat a beszállító látja el.
- ez a modell nagyon alkalmas a kkv szektorban, különösen a közepes méretű cégeknél, ahol már kiszervezik a feladatokat, de még nincs túlzott szabályozottság.
- Mennyire hatékony ez a modell? Úgy gondolom, hogy amennyiben a projekt csakis is kizárólag a beszállítón múlik, úgy a modell működni fog. Ilyen például, amikor egy szoftverfejlesztési projektben a beszállító fejleszt, minőséget biztosít és üzemeltet egy személyben.
- ügyfél oldali feladatok minimálisak legyenek, tehát az igények megfogalmazásán és a validáláson túl más né nagyon legyen.
- né legyen semmilyen más kommunikációs csatornája a megrendelőn kívül.
- a nagyvállalat bürokratikus működéséből adódó problémákat a beszállítói PM egyszerűen visszasöpri az ügyfél oldalára (ez a TE problémád), az igen nagy bukáshoz fog vezetni. Összességében azt tanácsolnám, hogy beszállító oldali projektvezetésre csak kivételes esetben, alapos átgondolás után bízzunk projektet. Nagyvállalatnál, nagy projektnél semmiképpen.
- A legjobb modell természetesen az, amikor a beszállítói PM mellett van egy ügyfél oldali PM (aki lehet speciel külsős is).
A modern szoftverfejlesztés Mithras kultusza
Különösen felfigyeltem arra, hogy Mithras kultuszra is hivatkozik, ami imádnivaló, hiszen nem mindenki ismeri a régi vallásokat. )
- Milyen okai vannak, hogy ma még nem fejleszt mindenki agilisan?
- a bukott pilot-?ok.
- nem minden agilis projekt sikeres.
- a csapat tényleg követte-?e az adott módszertant? Sok esetben kiderül, hogy nem.
- a triviális megoldás: tanácsadókat kell hívni, akik majd helyes mederbe telik a fejlesztést, és ügyelnek a helyes alkalmazásra.
- nem lehet minden projekt, minden fejlesztő, minden menedzser mellé tanácsadót rakni. Ha a módszerek nem alkalmazhatóak intenzív tanácsadó beavatkozás nélkül, akkor ott komoly baj van.
- A tanácsadói beavatkozás azért és érdekes, mert megkérdőjelezi a tanfolyamok és minősítések létjogosultságát.
- új „vallás”, az agilis fejlesztés, amihez igazából tanácsadó kell, nem terjedt el eléggé, nincsenek elég jó case study-?k, nem 100%-osan sikeres, cserébe viszont bomlasztó hatású. Miért döntene úgy egy felsővezető, hogy ezt választja? Erre 1000 érvet tudnának mondani a szakértők, 100 case study-?val alátámasztva és megcáfolva a kritikát. A baj az, hogy ezek a cáfolatok, ezek a cikkek mind sales céllal születtek. Egy
- hit kérdése, hogy elhiszem, ez működik-?e vagy sem. Ha pedig hit kérdése, és a vallás (az agilis fejlesztés) ködbe burkolja a gyakorlatot, a megvalósítást, akkor el fog veszni. Legalábbis a Mithras kultusz így járt.
- Sales és hittérítés helyett tényekre és gyakorlatra koncentrálni.
- valódi case study-kra van szükség.
Operations Management
- Operations Management feladata a szolgáltatások – jelen esetben informatikai szolgáltatások – biztosítása, a folyamatos szolgáltatás fenntartása.
- Project Management célja változások menedzselése,
- Operations Management nem akarja megváltoztatni a folyamatokat és a szoftvereket, csupán fenntartani zavartalan működéseket.
- kéz a kézben megy, egymás nélkül nem léteznek.
- Számos cég úgy építi fel a szervezeti ábrát (nem csak IT-?n belül!) hogy szétválasztja az Operations és a Project ágat. A csapat egyik fele csak projekteken dolgozik, a másik fele pedig csak támogat. A két szervezeti ág között értelemszerűen sok az együttműködés. A gazdasági válság miatti lapos IT kiadásokra az jellemző, hogy az üzemeltetés-?jellegű költségek megmaradtak és felülmúlják a lecsökkentett projekt-?jellegű kiadásokat. Már mindenféle szoftver létezik, ezért egyre kevesebb a nagyívű beruházás. Helyette a meglévő szoftverek üzemeltetése és továbbfejlesztése hangsúlyos. Az ügyfelek nem akarnak 4 évente szoftvert cserélni – ha egyszer ki lett fejlesztve, akkor 10–20 évig is használnák (vagy még azon túl is). Eljutottunk oda, hogy az Operations is képes követni az üzleti változásokat. Tehát az üzleti projekt nem feltétlenül igényli, hogy informatikai oldalon is felálljon egy projekt szervezet.
Projekt sikertényező: a kudarc mint kockázat
- Egy tanács arra nézve, hogyan legyen a projektünk sikeres.
- A sikeres projektvezetőről az elején látszott, hogy tudja a dörgést és meg fog birkózni mindenféle kihívással. Ez arról derül ki, ahogyan a projektvezető hozzányúl a projekthez. A sikeres projektvezetők hasonló módon nyúltak hozzá a projekthez.
- Hogyan viselkednek a projektvezetők?
- Van a „magabiztos” típus. Kemény, rámenős. Ha őt választják ki, a projekt garantáltan sikeres lesz. oda fog vezetni, hogy „szállítunk BÁRMI ÁRON” és a „határidő KŐBE VÉSETT”. Ebből következik, ha valami rosszul megy, akkor inkább eltusolás és maszatolás, mintsem valódi megoldás születik. És ebből következik, hogy a projekt el fog csúszni. Végeredményben ez a típus nem sikeres.
- a magabiztos ellenkezője: a „káoszhívő”. Azt mondja, hogy a projekt úgyis el fog csúszni, a munka úgyis lehetetlen. Tehát nem érdekli a terv (úgyis felborul) és a megoldás sem (úgyis meg fognak változni az igények menet közben). Terv helyett homályos határidők vannak, elmaszatolt felelősséggel. sosem lesz átfogó kép és tartható ütemterv. Tipikusan a menedzsmenthez nem értő szakemberek vezetnek így projektet, és nem ők szoktak befutni egy állásinterjú során.
- „szerencsevadász” PM. Képzett, tehát legjobb gyakorlatokat követ. Igyekszik a terv szerint haladni, és ha valami váratlan történik, akkor kezd vele valamit. a szerencsevadász meggyőző sikerességet tud felmutatni. Azonban nem tökéletes. A váratlan eseményekre csak utólag reagál.
- a „profi” PM. A projekt megvalósítható, de nem lesz egyszerű és dolgozni kell – p értéke 0 és 1 között van. Az a különbség a szerencsevadászhoz képest, hogy a profi elébe megy az eseményeknek, azaz proaktívan felderíti azokat és semlegesíti. folyamatosan dolgozik a p érték csökkentésén. a profi dolgozik rövid távon a legtöbbet. Hosszú távon pedig az, akinek a projektje bukik (éjszakázások és a hétvégézések). a projekt egyik sikerfaktora az, hogy sikerül-?e az események elébe menni, és így ügyelni arra, a projekt né térjen le a tervezett útról. A kudarc lehetőségét kezeljük projekt kockázatként, elkerülésére dolgozzunk ki tervet és napi szinten ellenőrizzük annak végrehajtását.
Projektvezetés vs piramisépítés
Összességében tehát a piramis-?építő írnok főbb feladati hasonlítanak ahhoz, amit manapság egy projektmenedzser csinál napi szintén. Ilyen értelemben nagy is meglepő, hogy az elmúlt 5000 évben a lényeg (célok, erőforrások és ütemterv kezelése) nem változott. a napi szintű munkában sok hasonlóság lehet, de a modern projektvezető mégiscsak modern. Az eltérést nem a munka lényegi része jelenti, a célok és a koncepciók nem változtak, de az eszközök óriási különbséget jelentenek.
A kapitány prezentációja
- Mit tud a kapitány a hajójáról? Mindent, részletekig menően. Ugyanis az apróságok nagyon sokat számítanak a gyakorlatban.
- A kapitány nem megy be olyan kikötőbe, amelyikről nincs részletes leírása, és amiről nincs aktuális, napra kész vízmélység jelentése.
- Mit csinál a kapitány egy ilyen nagy hajón, ahol ennyi ember dolgozik és mindent számítógép vezérel? Tulajdonképpen nem sok dolga van. Csak annyi, hogy az 1200 beosztottja jól érezze magát és legyen mit csinálniuk. És egy fontos gondolat: a kapitány ráér, hogy előadást tartson.
- Ha sok a munkája, ha nagyon elfoglalt, akkor ott valami nagy baj van.
ITélet - kivonatok
- A túl sok irányváltástól lelassul a hajó
- A CV-t kozmetikázni kell // ITélet
- Előléptetés és kirúgás, mint motivációs eszköz - ITélet
- ITélet - 1
- A megfigyelés megváltoztatja a megfigyeltet - ITélet
- Miért nem fog soha eltűnni az email? - ITElet
- Mi hiányzik a frissen felvett informatikusokból?
- A túlóráról - ITÉlet
- Projektmenedzsment és az agilis szoftverfejlesztés - ITélet
- Hogyan lehet egy vállalat világszínvonalú rövid idő alatt? - ITÉlet
- Hogyan kell egy új menedzsert beilleszteni? - ITÉlet
Oct 21, 2011
comments powered by Disqus