Derrick és Harry Projektmenedzsment Blogja

Amit tudni akartál a projektvezetésről, de nem merted megkérdezni

Facebook Tumblr Tweet Pinterest Tetszik
0
2012. február 27. - TanacsLajos
Új szolgáltatással szeretnénk bővíteni blogunkat, mellyel reményeink szerint nagy örömet okozunk majd projektmenedzsment iránt érdeklődő kedves olvasóinknak. Szeretnénk, ha a napi munkátok során minél gyakorlatiasabb tanácsokkal láthatnánk el benneteket, ha válaszokat adhatnánk azokra a kérdésekre, témákra, amik régóta motoszkálnak bennetek, ha fórumot nyújthatnánk nektek, ahol őszintén és konstruktívan megtárgyalhatjuk azokat a problémákat, amelyekkel nap mint nap szembesültök munkátok során.
 
Bármilyen kérdést, témát feldobhattok, például:
- Baj-e, ha azt látom, hogy a programozóim index.hu-t olvasnak munkaidőben?
- Mikor engedjem el szabadságra az embereimet?
- Honnan tudom, hogy a fejlesztők megvezetnek-e a becslésekkel, vagy nem?
- Hülyeség-e a SOA architektúra, vagy tényleg van értelme?
- Hogyan kell felépíteni a tesztelést agilis projektben?
- Írjatok a projektportfolio menedzsmentről!
 
A kérésünk csupán annyi, hogy ha konkrét projekthelyzetet tártok elénk, mindig a szereplők és egyéb üzleti információk megnevezése nélkül tegyétek!
Várjuk hát a témákat, felvetéseket, akár kommentként ide, akár emailben a derrickesharry@gmail.com-ra!

 

14 komment

Ajánlott bejegyzések:

A bejegyzés trackback címe:

https://derrickesharry.blog.hu/api/trackback/id/tr884218287

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

groteszk 2012.04.21. 21:04:37

Tulképpen mikor mondanátok sikeresnek egy projektet? Az optimum, persze megvan: megrendelő elégedett, szállító - kivitelező (aki, persze, lehet belső is) elégedett, mindenki happy.

De egyébként?
Válasz erre 

Oberinspektor Derrick 2012.04.22. 20:18:30

@groteszk: Jó kérdés. Az a minimum, hogy a projekt eredménye használatba kerüljön és a gyakorlatban használható legyen. Hogy kicsit csúszott, hogy a Szállítónak pénzügyileg bukó, hogy a Megrendelő oldali projektvezető gyomorfekélyt kapott, előfordul. Ha meg egyik sem következett be, ultrasiker :)
Válasz erre 

attilakristo3d · http://www.missingcloud.com 2012.09.10. 02:25:55

Nem biztos, hogy ez a kérdésem túl project management-közeli lenne. De majd eldöntitek :) Szóval.. annyira sokat írtok a blogotokon a becslésekről, hogy felvetődött ez a kérdésem: Magyarországon mennyire elfogadott az, hogy becslés megy ki az ügyfélnek, fix összeget tartalmazó árajánlat helyett?

Tapasztalatom szerint a becslések becslésként való megtartása és nem mindenáron fix-árajánlatokká konvertálása egyszerűbb és kifizetődőbb, ráadásul jobban meg is közelíti a valóságot: soktényezős dolog a fejlesztés, az ügyfél is részese az igények miatt, röviden: nem-fix tényezőkből nem lehet fix dolgot gyúrni. Ti hogy látjátok?

És a project manager tehet valamit a becslésekért, hogy kiváltsák az árajánlatot (és ennek a jelenségnek az elterjedéséért), vagy ő mossa kezeit, merthogy "ez inkább a céges vezetés/pénzügy, stb döntése és kompetenciája"?
Válasz erre 

TanacsLajos 2012.09.13. 07:14:00

A rövid válasz a kérdésedre az, hogy nem elfogadott, vagy legalábbis alig. A becslés alapú (azaz nem kötelező érvényű vállalás) nem ad biztonságot a megrendelőnek, hiszen nyitva hagyja a projekt költségeinek felső határát.
Egy nagyvállalati környezetben rengeteg jóváhagyón megy keresztül egy projekt, mire elindul. Sajnos a bizalom hiánya miatt senki nem szokott jóváhagyni olyat, hogy "kb. ezt kb. ennyiből ki fogjuk hozni".
Ez persze alapvetően rossz megközelítés, teljesen igazad van, hiszen a szoftvereknek jellegükből adódóan nem lehet pontosan megmondani, mennyibe fognak kerülni. Többek között erre nyújtanak alternatív választ az agilis módszertanok például.
A projektvezető azért igenis tehet valamit azért, hogy elérje azt az állapotot, amit írsz: ha sikerül jó és bizalmi viszonyt kiépítenie az ügyféllel, akkor elérheti, hogy a fix áras vállalásból adódó (egyébként hamis) biztonságérzet nélkül is bele mernek vágni egyes munkákba. Persze, van ennek pénzügyi vonatkozása is, de általánosságban a projektvezetőnek feladata a projektet pénzügyileg is sikeressé tenni, így abszolút hozzá is tartozik ez a terület.
Válasz erre 

attilakristo_ · www.missingcloud.com 2013.02.25. 02:12:25

Kicsit késve, de köszönöm a választ :)

Egyetértek vele.
Egyébként úgy látom, hogy azért hazánkban is elterjedőben van - szabadúszóknál legalábbis - az "óradíj+becslés"-alapú ügymenet, már amilyen területeken ez indokolt persze.
Válasz erre 

András777 2013.05.17. 14:22:12

Hello!

Akkor most pár hónap késéssel meg is kérdezném, hogy "Baj-e, ha azt látom, hogy a programozóim index.hu-t olvasnak munkaidőben?"

Illetve mennyit indexezhetnek, járhatnak le kávézni? Mit teszel, ha azt látod, hogy a programozóknak több indexezést néz el a vezető fejlesztő, mint te gondolnád?
Válasz erre 

TanacsLajos 2013.05.20. 20:39:54

@András777: Köszönjük a kérdést, messzire vezet a téma! Bizonyos szempontból mindegy, hogy mennyit indexeznek meg kávéznak az emberek. A lényeg az, hogy az adott héten végezzenek jó minőségben a rájuk bízott feladatokkal: ha ez megvan, mindegy, hogy 10 percet vagy egy órát kávéznak összességébe véve egy nap. Természetesen ennek van előfeltétele: legyenek rendesen leterhelve, azaz ne úgy becsüljenek, hogy minden feladatba belekalkulálnak még 50% barátnővel csetelést, lakásvásárlás intézést, vagy hétvégi buli szervezést.

Az sem mindegy, milyen időszakban van a projekt: vannak nyugodtabb időszakok, amikor kicsit több lazítás is belefér, meg vannak húzós időszakok, amikor nem. Amikor még nincs nagy őrület, vagy valamilyen külső függőség miatt úgyis csak vontatottan lehet haladni, akkor én haza szoktam korábban küldeni az embereket, pénteken csak délig vagyunk, és meg is szoktam nekik mondani, hogy most gyűjtjük az energiát a nehéz napokra.

A vezető fejlesztő általában a rábízott teljes csapat teljesítményéért felel, lehet, hogy egyszerűen a csapatszellemnek jót tesz, ha kicsit lazábban vannak fogva. Persze az is lehet, hogy a vezető fejlesztőd gyenge kezű, és képtelen fegyelmet tartani, azért indexezik mindenki. A kulcskérdés az, hogy jönnek-e az eredmények, vagy nem. Erre koncentrálj: de erről ne riportokon keresztül akarj meggyőződni, tartass bemutató mondjuk minden héten az elért haladásról.

Az indexezni hagyás kétélű fegyver. Megfelelő mennyiségben alkalmazni jó, mert egy kis szünet serkenti a programozó kreativitását, embernek érezheti magát, aki maga oszthatja be, hogyan jut el a feladat megoldásához. Ugyanakkor túl nagy lazaság mindenkire ártalmas: a napi fél óra először háromnegyed, aztán másfél lesz, ami egészen addig fajul, hogy egyes emberek 1-2 óra produktív munkánál képtelenek többet teljesíteni. El kell intézni a gyerek fogorvosát, megnézni a fészbukkot, lemenni kávézni Rozikával, aztán már itt az ebédidő, megnézni az étlapot, a holnapit is, másfél órás ebéd újabb kávéval, aztán tele hassal képtelenség bármit csinálni, egy óra internetezés, és már délután 2-3 körül járunk úgy, hogy semmi nem történt aznap. Ez sajnos nem ritka jelenség, és meggyőződésem, hogy a következetes és hatékony feladatkiosztás és számonkérés hiányából ered.

Szóval ha jönnek az eredmények, akkor nem baj, ha indexet olvasnak. Aki jól húz, azt bizalommal érdemes meghálálni, itt ez azt jelenti, hogy "Nem ugatok, ha indexet olvasol, mert bízom benned, tudom, hogy megoldod a feladatot". Ha nem jönnek az eredmények, akkor nincs lazítás, akkor sem, ha más miatt nem jönnek. Ha rosszul áll a projekt, akkor mindenki azon tornázzon, hogy megjavuljon, és ne máson!
Válasz erre 

raki 2013.06.25. 11:38:25

Azt szeretném megkérdezni, hogy szoktatok-e használni uncertainty diagramot illetve hogyan szoktátok a projekt határidejének bizonytalanságát kommunikálni, vannak-e erre jó és kevésbé jó módszerek?

Lehet-e ezt jól kommunikálni a döntéshozók felé? És akkor hogy kell, ha a szervezet kevésbé fogékony erre?

A diagramot a "Tom Demarco - Waltzing with Bears Managing Risks On Software Projects" könyvben olvastam.
Válasz erre 

raki 2013.06.25. 23:38:45

Itt például ennek a szimpatikus szemüveges embernek az oldalán még szuper excel template is van:

www.andrewj.com/thoughts/combining%20risks.asp
Válasz erre 

TanacsLajos 2013.06.26. 14:26:12

@raki: Én is olvastam a könyvet, és szerintem a kockázatkezeléssel kapcsolatos alapfogalmak lefektetésére nagyon jó, illetve segíthet abban, hogy tudatosabban élje meg az ember a projekt kockázatainak felismerését, de személy szerint nem hiszek az ilyen diagramokban. A projekt határidejének bizonytalanságát nem szoktuk kommunikálni, mert az általában kiveri a biztosítékot a hallgatóságban. Sokkal inkább szoktuk azt mondani, hogy "A tervezett élesítési dátum 2015. március 23" még akkor is, ha az majdnem két évnyi távolságra van. És szinte biztosan nem aznap lesz az élesítés.
Ha valaki ért a szoftverprojektekhez, akkor tudja, hogy sokszor még két héttel az élesítés előtt sem lehet biztosan állítani, hogy aznap lesz élesítés. Ha valaki nem ért hozzá, akkor egy menedzsment prezentáció nem alkalmas arra, hogy elmagyarázzuk, hogy működik ez a szakma: jobb magabiztossággal egy fix, remélhetőleg vállalható dátumot sugározni. Ráadásul nagyon sokszor a dátum kívülről jön, a feladathoz ragasztva: vagy megcsinálod akkorra, vagy véged :) Itt nem üzenheted azt, hogy "hát, 45%-os valószínűséggel tudjuk majd tartani a határidőt", mert az az azonnali bukással egyenlő.
Saját használatra sem írok ilyen táblázatokat. Nem hiszek a projektek ilyen szempontú formalizálásában, szerintem ez túlzott leegyszerűsítése a helyzetnek, és félrevezet, mert elfed minden olyan tényezőt, ami nincs benne a táblázatban.
Válasz erre 

raki 2013.06.28. 09:59:31

Kockázatkezelési tervet szoktatok csinálni? Ha igen, ennek a formátuma, használata, haszna megegyezik a "könyvekben" szokásosan leírtakkal?

Ezt pl egy steering committee is rendszeresen látja?
Válasz erre 

raki 2013.06.28. 16:13:28

Még ehhez a kockázati százalék részhez. Akkor az a párbeszéd, ami a "Software Estimation Demystifying the Black Art" c könyvben van, olyan a valós életben nem történhet meg? És mondjuk az USA-ban vagy Németországban?

TECHNICAL LEAD: Our estimate for this project is that it will take 5 to 7 months. We're still pretty early in the Cone of Uncertainty, so we can tighten that up as we go.

EXECUTIVE: Five to 7 months is too wide a range. How about if we just use an estimate of 5 months?

TECHNICAL LEAD: We've found it really useful to distinguish between estimates and commitments. I can't change the estimate, because that's a result of a lot of computations. But I could possibly have my team commit to a delivery schedule of 5 months if we all agree that we want to take on that level of risk.

EXECUTIVE: That seems like semantics to me. What's the difference?

TECHNICAL LEAD: Our range of 5 to 7 months includes one standard deviation of variation on each side of our 50/50 estimate of 6 months. That means we have about an 84% chance that we'll deliver within 7 months. Our estimates suggest that we have only 16% chance of actually meeting a 5-month commitment.

EXECUTIVE: We need more than 50% confidence in the date we commit to, but 84% is more conservative than we need. What would the 75% confident date be?

TECHNICAL LEAD: According to the probabilities we estimated, that would be about 6.5 months.

EXECUTIVE: Let's commit to that then.

TECHNICAL LEAD: That sounds good.
Válasz erre 

raki 2013.06.28. 16:32:06

Még annyit ehhez, hogy nyilván van tapasztalatom abban, hogy mennyire lehet ilyen %-os dolgokat, illetve bizonytalanságokat kommunikálni. Arra vagyok kíváncsi, hogy nektek hátha van más tapasztalatotok vagy valaki másnak.

Mondjuk én inkább az IT cégekből néznék ki ilyet, pl egy bankból, ahol igazából az IT max másod- vagy sokadhegedűs, ott nem.
Válasz erre 

TanacsLajos 2013.06.30. 21:16:58

@raki: Persze, szerintem alapvetően a hallgatóságtól függ, hogy mennyire lehet őszintének lenni a határidőkkel és azok bekövetkezési valószínűségével kapcsolatban.
Amennyiben formálisan elvárják a kockázatkezelést, akkor a könyvekben olvashatóhoz hasonlót szoktam csinálni: kockázatok listája, bekövetkezési valószínűséggel, hatás súlyosságával, elkerülési tervvel, bekövetkezés esetén hatásenyhítési tervvel. Ha egy ilyet csinál az ember és még nagyjából frissen is tartja, attól általában mindenki eldobja az agyát azt gondolván, hogy te vagy a világ legnagyobb projektmenedzsere.
A gyakorlatban nekem ez nem sokat segített, amikor használtam: úgy éreztem, trivialitásokkal tömöm tele. Arra esetleg jó volt, hogy a projekt helyzetét kifelé megmutassam.
Válasz erre 
süti beállítások módosítása