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

Bullshit elemzés és közkeletű mítoszok Holden cikke alapján.

Bullshit elemzés és közkeletű mítoszok Holden cikke alapján.

Holden cikkében összeszedett néhány nagyon frappáns vállalati bullshit-et. Mindegyik gyöngyszem, de igazából az utolsó fogott meg:

„a folyamatokat legjobban a bennük dolgozók ismerik”


Mivel a vállalatokat a tudomány mai állása szerint felülről lefelé vezetik, ezért a folyamatokat elsősorban a vezetőknek és menedzsereknek kell ismernie. Ha nem ismernék a folyamataikat, akkor nem is tudnák vezetni a vállalatot.

Ezzel szemben ha egy beosztott nem ismeri a folyamatot amiben dolgozik, nos az elő szokott fordulni és alapvetően nem baj. Hiszen ha valamit nem tud, akkor kérdez a főnökétől. A baj akkor van, ha a főnöke nem ismeri a folyamatot és nem tud válaszolni a kérdésre.

Most nézzünk konkrét példákat!

Tegyük fel hogy van egy fejlesztő, aki nem ismeri a cégnél hatályos fejlesztési folyamatot. Programot írni tud, ha valaki megkeresi egy hibával akkor azt kijavítja, de egyébként nem követi a folyamatot és/vagy sokszor eltér tőle. Ilyen fejlesztőből szerintem nagyon is sok van, sőt általánosságban mondható, hogy sok jó szakembert a szakmai munka érdekli, és nem a folyamat.

Ugyanígy gyakori jelenség, hogy az ügyintézők csak azokat a folyamatokat ismerik, amiket minden nap csinálnak, és azokat egyáltalán nem, amik az egyedi esetekre vonatkoznak. Ilyen például hogy ha valaki egy mobil cég értékesítési pontján új előfizetést akar kötni, azt gyorsan elintézik. De ha a meglévő telefonszámát akarja áthordozni egy másik szolgáltatóhoz, akkor az nem fog elsőre sikerülni.

 

Miért is van ez? Mert a beosztottakat igazából nem érdeklik a folyamatok. Az ő napi munkájuk nagy részéhez nem kell ismerni a folyamatokat, legfeljebb csak azok egy kis részét. Boldog élet a droidé: azt csinálom amit mondanak, amit nem mondtak azt nem csinálom, ha pedig valami furcsa történik akkor leblokkolok és széttárom a kezem.

Ezzel szemben a vezető dolga az, hogy minden kérdésre tudjon válaszolni, minden kivételt le tudjon kezelni, és úgy általában átlássa a folyamatokat. Különben nem tudná a droidokat vezérelni és leállna a termelés.

 

Akkor pedig miért gondolhatja bárki is, hogy a folyamatokat legjobban a bennük dolgozók ismerik?

Ennek kettős oka van:

1) Mert a benne dolgozók azt hiszik, hogy mindent tudnak. És ennek ellenkezőjéről a tények sem fogják őket meggyőzni. Ha valami baj történik, akkor azért mindenki MÁS felelős: az ügyfél, a főnök, a világ, mindegy ki, csak az a lényeg hogy más a hibás.

2) Sajnos léteznek inkompetens vezetők, akik nem ismerik a folyamatokat, sőt még saját szerepükkel sincsenek tisztában. Mivel inkompetensek, ezért a feladatot és a felelősséget (folyamatok ismerete) teljes egészében a beosztottaik nyakába varrják. Akik „megszokik vagy megszökik” elv alapján kénytelenek az ő munkáját is elvégezni. Vagyis a „folyamatokat legjobban a benne dolgozók ismerik” magyarra fordítva: „nem értek hozzá, hagyjatok békén”.

 

Mint vezető, nekem az a dolgom, hogy a folyamatokat ismerjem, hogy legyenek folyamatok és hogy kövessük azokat. Ha én nem figyelek erre oda, akkor más nem fog. És ha nincsenek folyamataink, akkor káoszba fulladunk.

Címkék: folyamat vezető

A bejegyzés trackback címe:

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

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.

cgcglw 2012.04.20. 10:25:57

Ahogy a szervezetnek, úgy a folyamatoknak is van hierarchiája. A beosztottak kell, hogy ismerjék jól a mikro folyamatokat, a vezetők feladata pedig a makro folyamatok ismerete. Ha valamilyen változás hatására a ez a folyamat hierarchia átrendeződik, mikro folyamatok válnak makro folymattá, vagy egy mikro folyamat változása miatt borul a makrofolyamat, akkor praktikus szemlélet lehet „a folyamatokat legjobban a bennük dolgozók ismerik” állítás.

Tamás 2012.04.22. 11:08:49

Egyetértek @cgcglw -vel. Kicsit konkrétabb példát nézve: nem örülnék, ha egy projekt menedzser mondaná meg, hogy használjak-e Test-Driven-Developmentet; illetve hogy mennyi unit tesztet írjak. Annak se örülnék, ha megmondaná, hogy egy bugreport reprodukálható-e vagy sem. Ezeket nekem, a fejlesztőnek kell tudnom. Előfordul, hogy van róla véleménye a PM-nek. Ilyenkor szerencsésebb, ha a véleménye csak vélemény/javaslat marad - és nem lesz belőle utasítás. Másrészt, ha eszkalálnom kell egy adott bugot; vagy valamiért szükségem van még egy virtuális szerverre, vagy bármilyen más eszközre, akkor a PM-hez fordulok, mert ő tudja, mi ennek a módja: kitől kell kérni, hol kell feladni a ticketet, a rém bonyolult ticketing rendszer melyik mezője valójában mit jelent, etc.

Ismeretlen_102125 2012.04.22. 15:10:48

Engetelmetekkel ellentmondanék. A vezető feladata nem csak az, hogy a makro folyamatokat ismerje, hanem az is, hogy felelősséget vállaljon az alá tartozó területért - beleértve a mikro folyamatokat. Konkrét példa: lehet, hogy a PM nem ért a unit test-hez, de ő felelős azért, hogy a unit test-ek jók legyenek. Mert ha nem lennének jók, akkor a szoftver minősége esik, és emiatt megbukhat a projekt. Ezért a PM-nek ismernie kell, hogyan fejlesztenek és tesztelnek a beosztottai, és szükség esetén abba beleszóljon. (Hangsúlyozom: szükség esetén)

Tamas 2012.04.24. 11:37:22

@akocsis, szerintem jellemző, hogy a manager - hiába van mérnöki/fejlesztői múltja - nem ért annyira az adott technológiához, hogy ellenőrizni tudja a mérnökök munkáját. Azaz, code-quality ellenőrzését, ezzel együtt unit tesztek ellenőrzésést nem bíznám rá egy manager, mert nem ért hozzá. Nem is kell persze, máshoz kell értenie. Hogyan ellenőrizhető akkor a minőség? Szerintem sokkal jobb, ha 2-3 fejlesztő közös code-review-k alatt ántézi egymás kódját. Esetleg egy, a többinél tapasztaltabb mérnököt meg lehet kérni, hogy ellenőrizze az ellenőrizendőket, és szükség esetén ő szóljon bele. Persze itt már eltértünk a folyamatoktól, inkább code qualityról van szó. Abban nagyon igazad van, hogy _szükség_esetén_ szóljon bele a menedszer. Sőt, szerintem itt kezdődik a művészet: a menedzser mikor mennyire hagyja szabadjára a mérnökeit.