HTML

ITÉlet

Egy multinacionális cégnél dolgozó informatikai manager szakmai blogja. Észrevételek, tapasztalatok szoftver fejlesztésről, vezetésről, managementről és hatékonyságról itthoni és külföldi példákon keresztül. Az informatikáról másképp...

Utolsó kommentek

  • sagabona: szia... elég régen született ez a bejegyzés, én csak most akadtam rá véletlenül. Érdekes dolgokat írsz, részben egyetértek az általad gondoltakkal, azonban pár dologban messze más a véleményem - ez ... (2018.10.19. 11:14) Gondolatfoszlányok a pályaválasztásról
  • Simon Géza: "A következő forradalmi áttörés, nagy dobás, ami megint tőzsdei felfutáshoz vezet, az nem valamilyen informatikai dolog lesz, hanem egészen más." Ha a generic AI nem informatikai, akkor igazad van.... (2018.02.19. 07:01) Az IT jövője
  • pggp: @AnyTink: Köszi, de én csak egy blog olvasó vagyok, aki jól tudja használni a keresőt ;-) (2017.10.17. 07:19) Milyen volt hazaköltözni?
  • AnyTink: @pggp: :) Gratulálok a család bővüléséhez és a sikeres 'hazatelepedéshez'. Mi most gondolkodunk a hazaköltözésen és jó olvasni mások élményéről! Köszönöm az írásod :) (2017.10.16. 18:49) Milyen volt hazaköltözni?
  • pggp: Tulajdonképpen igen, alakult valami: akocsis.com "2017 április, Dália eloször Szentesen" ;-) (2017.06.06. 21:51) Milyen volt hazaköltözni?
  • Utolsó 20

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)

Címkék: döntés menedzsment

A bejegyzés trackback címe:

https://akocsis.blog.hu/api/trackback/id/tr95211255

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.

attilak 2009.10.11. 17:59:52

Amennyiben termekkel kapcsolatos a fejlesztes, ott bejon a termekciklus-hossz tenyezo is. Olyan iparagakban ahol a termekeletciklus rovid - Toyota autoitol elteroen - nincs ido hosszu tervezesre. Gondolj peldaul telefonokra, laptopokra amit evente vesz az ember. A jovo, a joleti tarsadalom es a verseny erosodese minden iparagban a termekciklusido rovidulesehez vezet, ami pedig ugy altalaban a P-t roviditi.

Ismeretlen_102125 2009.10.12. 12:15:34

@attilak: Sokan gondolkodnak úgy, ahogy leirtad, alapjaiban és részleteiben igaz, de a végkövetkeztetés hibás. A piac valóban változik, és reagálni kell rá, egyre gyorsabban és gyorsabban. Vagyis csökkentjük a ciklusidőt. Viszont ha a ciklusidő csökkentése a célunk, akkor előbb-utóbb eljutunk oda, hogy minden változtatásunk taktikai lesz, és szem elől veszitjük stratégiai célokkal. Ami pedig nagyon nem jó - éppen ezt mondta a cikk amire legutóbb hivatkoztál. Már dolgoztam együtt olyan emberrel, aki a ciklusidő csökkentésében látta az informatika Szent Grálját, és láttam olyan projektet ahol ezt a filozófiát követték. Nagyon jól is ment egy darabig, sokkal jobban mint más projektek, aztán egy idő után összeomlott.

Ismeretlen_131970 2009.10.21. 16:35:16

Akocsis! Igazad van. Ha csak azzal törődnénk, hogy csökkentsük a cilkusidőt, akkor egy idő után már nem lenne idő folyamatosan a stratégiai célokat követni. A végtelenségig nem lehet csökkenteni a ciklusidőt, mert minél kevesebb az idő, annál több a munka egy ciklusban. És minél több a munka, annál több a hibalehetőség, ami ugye, ha becsúszik, akkor pluszköltség. És be is fog csúszni, ha eléggé felpörög a dolog. És ugyanott vagyunk, ahol a part szakad...Csak a piacot kell követni. Arra koncentrálni, hogy felgyorsítsuk a ciklusokat, felesleges. A piacok így is egyre gyorsabban változnak.

attilak 2009.10.23. 20:39:13

Parhuzamositas segithet a P csokkenteseben (egy bizonyos pontig persze). A piackoveto (reaktiv) magatartas hagyomanyosan versenyhatranyhoz vezet...