Avagy milyen hosszú a P a PDCA-ban?

PDCA, azaz Plan-Do-Check-Act

Minden manager ismeri.

A kérdés az, hogy milyen hosszú legyen a tervezés, és hogyan kell megfelelően dönteni?

Az első kérdés a döntéshozás szintje. Fontos megtalálni a döntéshez szükséges szinten a hierarchiában. A Project Manager dönt a projektjén belül, de nem dönt(het) olyan kérdésekben, amik a projekten kívül mást is érintenek.

A középvezetők tipikusan nem döntéshozók, „csak" végrehajtók, és felelősek az operatív munkáért. Ez persze sok esetben azt jelenti, hogy a napi ügyeket érintő kérdésekben döntenek.

Az igazi döntéshozói szint a felsővezetés, illetve a Project Sponsor. A döntést sok esetben nem kézzel hozzák, hanem mondjuk a stratégia kidolgozása vagy a célok kitűzése önmagában meghatározza azt az utat, amin mozogni lehet.

Fontos megtalálni azokat, akik egy döntés érint, és így bevonni a megfelelő embereket a döntéshozásba. Ez gyakran tovább tart, mint maga a döntés. Pedig fontos, hiszen a döntésnek akkora súlya lesz, mint akik meghozzák - ha egy kulcsfontosságú kolléga nem vett részt a döntéshozásban, akkor esetlen súlytalanná válik a döntés.

És milyen sokáig tartson a döntés, gyorsan vagy alaposan döntsünk?

Kétféle modell létezik:
1) Vastag P, hosszú és alapos döntés, amit vékony D, C és A követ. A döntésen sokat dolgozunk, ezért a későbbiekben kevés a munka.
2) A másik modell a vékony P, gyorsan elhatározzuk magunkat és nekiugrunk a munkának, ami vastagabb D, vastagabb C és vastagabb A lépéseket eredményez. Mivel a döntés nem volt alapos, sokmindent menet közben kell dolgozni, nagyon alaposan ellenőrizni kell az eredményt (hiszen hibás lehet), és feltehetőleg korrigálni is kell majd.

Nagy cégeknél megfigyelhető, hogy az 1-es metódust preferálják. Például a Toyota egy-egy új autómodell elkészítésénél nagyon hosszú tervezési/design fázist követően gyorsan vág bele a kivitelezésbe, és rekord idő alatt készül el. A hosszú tervezés eredménye rövidebb ciklusidő.

Bizony nagyon igaz, hogy ha elkapkodjuk a döntést, és csak úgy belecsapunk valamibe - például mert nincs elég idő végiggondolni a lehetőségeket - a végén problémáink lesznek, és a problémák megoldása sokkal több időt vesz igénybe, mint amibe az alapos elemzés került volna. Azaz paradox módon a gyors munka lassú kivitelezést szül.

Az informatikában - ahol nem mindig lehet csak úgy irányt váltani - ez hatványozottan igaz. Azt mondják, egy hibás döntést egy későbbi fázisban 10-szeres költséggel lehet csak kijavítani, még későbbi fázisban pedig a hiba ára 100-szoros.

Például sokkal egyszerűbb jól megtervezni egy szoftvert és jól megírni, mint utána hibákat javítani. Egy-egy hiba megtalálása és kijavítása óriási erőfeszítés: megfelelő tesztesetek elkészítése, a tesztelő ideje és munkája, a hiba követése és hibakövető rendszerben, egy fejlesztőnek újra át kell néznie a kódot, javítani, újratesztelni a javítást, aztán ott vannak a regressziós hibák.

Még rosszabb a helyzet, ha sokkal korábbi hibás döntés levét isszuk, például egy hibásan elemzett üzleti folyamat eredményeképpen a szoftver nem fogja tudni kiszolgálni az üzleti igényt. Ilyenkor alapjaiban kell újragondolni dolgokat: nem csak a kódban kell javítani mint egy hibánál, hanem architektúrálisan is bele kell piszkálni, megváltoztatva a működési folyamatot, az igényspecifikációt, a kézikönyvet.

Úgyhogy döntsünk jól és alaposan...

(Aki pedig a RAD vagy agilis fejlesztési modellel jön, nos annak is megvan a maga költsége időben, munkában, minőségben)