Halálmenet (projektmenedzsment)
A halálmenet a projektmenedzsmentben egy projekt, amiről a munkatársak érzik, hogy bukni fog, vagy fenntarthatatlan mennyiségű túlmunkát követel. A vezetők azonban nem látják be ezt, és további erőfeszítést követelnek a dolgozóktól, hátha mégis sikerül.
Először a szoftverfejlesztésben ismerték fel és nevezték meg ezt a gyakorlatot. Más gazdasági ágak később vették át.
A halálmenet többnyire a túl optimista vagy irreális tervezés eredménye, ami érintheti az ütemezést és a teljesítendő feladatokat. Gyakran hiányos a dokumentáció vagy a munkatársak képzettsége és gyakorlottsága elégtelen. A projekt természetének ismerete demotivál, a résztvevők reménytelenül tekintenek egymásra, és igyekeznek túlélni. Ezt a feladatot megnehezíti a főnökség elvárása, hogy adják fel a szabadidejüket és a családjukkal töltött időt (munka utáni idő, hétvégék), hogy a projekten dolgozzanak; vagy pedig fektessenek be elég energiát, ami gyakran kiégést okoz. A projektnek nem látszik a vége, mivel a határidőket többször is kitolták.
A résztvevők helyzetét súlyosbítja, hogy úgy érzik, hogy máshogy menedzselve a projektet sikerre lehetne vinni, például megfelelő technológiával, több szakértelemmel, több résztvevővel. Különösen nyomasztó, ha a cégnél a megfelelő erőforrások rendelkezésre állnának, de a projekt nem kapja meg. A céges kultúra nyomása, illetve a gyors profitszerzés következménye tovább súlyosbítja a vezetőség inkompetenciáját. Néha szándékosan is kezdeményeznek halálmenetet, hogy eltereljék a figyelmet a vállalat többi problémájáról.
A halálmenetet Edward Yourdon bővebben kifejti ebben a könyvében: Death March: The Complete Software Developer's Guide to Surviving 'Mission Impossible' Projects (ISBN 0130146595), aminek második kiadása Death March (ISBN 013143635X). Yourdon egy ökölszabályt is megad a halálmenet felismerésére: Egy projekt, aminek paraméterei legalább 50%-kal meghaladják a normálisnak tekinthető mennyiséget.[1]
Egy halálmenetben a mérföldköveket nem érik el időben, vagy nincsenek is mérföldkövek kitűzve. A projektet nem menedzselik projekt módjára, káosz uralkodik, nincsenek kitűzött határidők vagy betarthatatlanok. Hiányoznak a pontos tervek, a fejlesztés addig zajlik, amíg egy-egy pontatlanul definiált funkció többé-kevésbé nem működik. A megjelenő köztes vagy tesztverziók gyenge minőségűek, és a minőség egyre romlik. Változáskezelés sincs, mivel a kritériumok nincsenek megfelelően definiálva. A tegnap új kihívásai a holnap hibái.
Jegyzetek szerkesztés
Források szerkesztés
- Frederick P. Brooks: Vom Mythos des Mann-Monats: Essays über Software-Engineering. Bonn: mitp. 2003. ISBN 3-8266-1355-4
- William J. Brown: Anti-patterns. Refactoring Software, Architecture and Projects in Crisis. New York: John Wiley & Sons. 1998. ISBN 0471197130
- Martin Fowler: Refactoring: Improving the Design of Existing Code. Reading/Massachusetts: Addison-Wesley. 1999. ISBN 0201485672
- Joshua Kerievsky: Refactoring to Patterns. Boston: Addison-Wesley. 2004. ISBN 0321213351
- Bruce A. Tate: Bitter Java. Greenwich/Connecticut: Manning. 2002. ISBN 193011043X
- Bruce A. Tate et al: Bitter EJB. Greenwich/Connecticut: Manning. 2003. ISBN 1930110952
- Gerald M. Weinberg: Psychologie des Programmierers. Bonn: mitp. 2004. ISBN 3-8266-1465-8
Fordítás szerkesztés
Ez a szócikk részben vagy egészben a Death march (project management) című angol Wikipédia-szócikk fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.
Ez a szócikk részben vagy egészben az Anti-Pattern című német Wikipédia-szócikk fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.