ITÉlet

Egy kis humor konferenciajáróknak

Mi a különbség egy fejlesztői konferencia és egy menedzser konferencia között?

Egy kis humor konferenciajáróknak

Mi a különbség egy fejlesztői konferencia és egy menedzser konferencia között?

Mit takar ez a kifejezés, mire használjuk és miért elterjedt?

Vajon mit takarhat a „Command and control” kifejezés? Ha a wikipédián rákeresünk, akkor egy katonai szakkifejezéshez jutunk: az elöljáró tiszt irányítását és felügyeletét jelenti, amelynek segítésével a hozzá rendelt erők végrehajtanak egy küldetést. Irányítás és felügyelet. A tiszt parancsokat ad, a katonák végrehajtják.

Aki számítógéppel játszik, annak a kifejezésről a Command and Conquer című nagy sikerű játék ugrik be. Nem véletlenül, hiszen a C&C egy katonai stratégiai játék, és mint ilyen nagyon is köze lehet a katonai alapelvekhez.

A kifejezés azonban nem csak katonai körökben használatos, hanem üzleti körökben is. Lásd Command and control (management) szócikket a Wikipedián. A Command and control nem más, mint a direktív vezetői stílus.

A vezető a rá ruházott hatalom segítségével a beosztottait különböző feladatok végrehajtására utasítja, az utasítások végrehajtását ellenőrzi. Így képes a csapat közösen egy nagyobb célt elérni. A cél eléréséhez a vezető kulcsfontosságú, hiszen ő hoz döntéseket és ő határozza meg a részfeladatokat. A beosztottak csak végrehajtanak, pusztán eszközök a vezető kezében.

A kommunikáció egyirányú, felülről lefelé. Csak a vezető rendelkezik elégséges információval, az információ nem megosztott.

A Command and control (CC2) a vezetés minden szintjén alkalmazható, ebből a szempontból univerzális.

Biztos vagyok benne, hogy már mindenki dolgozott ilyen környezetben, tehát semmi újat nem mondtam.

Helyes-e a Command and control alkalmazása? Az biztos, hogy egy működő és bevált módszerről beszélünk.

A másik oldalról viszont nem vagyok benne biztos, hogy a legjobb. Már a wikis cikkben is említik, hogy manapság sokan elavultnak tekintik. A direktív vezetői stílus csak egy a 4 fő vezető stílus közül (direktív-supportív-coaching-delegating) a szituációs vezetés elmélet szerint. (Amit már említettem e blogon: Management styles)

A szituációs, avagy helyzetfüggő vezetés sokkal jobb a command and control-nál, hiszen a külső tényezőket is figyelembe veszi (például egyéni kompetenciák, csapat kohézió, motiváció, szervezeti kultúra), ezekhez alkalmazkodva választja ki a megfelelő vezetési stílust.

Az általános vélekedés (és szerény véleményem) szerint a motivált és kompetens csapat jobban teljesít, mint egy csapat intelligens majom. A direktív vezetés pontosan intelligens majmokká redukálja a csapatot. Ha növelni akarjuk a belső hatékonyságot, akkor a csapatot fokozatosan fejleszteni kell mind kompetencia, mind motiváció terén, hogy aztán szép lassan elengedjük a kezüket, és utasítások (command and control) helyett hagyjuk őket dolgozni (empowerment).

Természetesen ez sok tényezőtől függ – előfordulhat, hogy az adott helyzetben a direktív vezető hatékonyabb.

Ha ez igaz, akkor miért elterjedt a command and control, miért van sok direktív vezető? Miért kevésbé elterjedt és megértett a coaching vagy az empowerment?

Ennek rengeteg oka van, a teljesség igénye nélkül íme néhány:

A direktív vezetést hozzuk magunkkal. Otthon a szüleinknek volt hatalma felettünk, akik utasítottak. Az iskolában a tanáraink voltak a „feljebbvalóink”, akkor utasítottak erre vagy arra (pl. „csináld meg a házi feladatot”). Belénk nevelték ezt az alá-fölérendeltségi viszonyt, az utasítás végrehajtását, és azt, hogy nem szükséges a dolgok hátterével tisztában lenni. Amikor valaki minden előzetes tapasztalat nélkül menedzser lesz, akkor a hozott reflexekhez nyúl: automatikusan elkezd parancsokat osztogatni és elvárja azok végrehajtását a beosztottaktól. Egyszerűen nincs másik hozott modell.

A Command and control népszerűségének másik okát a katonaságban látják. Régen volt a kötelező sorkatonaság, ott az ember szembesült ezzel a vezetői stílussal, ha akart ha nem. Aztán amikor kinevezik vezetőnek, akkor reflexszerűen a korábban látott példát alkalmazza – függetlenül attól, hogy az jó vagy rossz.

A harmadik oka az egyszerűség. Nagyon egyszerű azt mondani a beosztottnak, hogy csináld meg ezt a feladatot, aztán pedig amikor jön a határidő, akkor rákérdezni az eredményre. Ezt a rutint könnyű felvenni, könnyű alkalmazni. Nincs szükség hosszú és drága képzésre. A dolog csak úgy jön magától.

Az egyszerűség mellett a command and control a vezetőtől nem igényel komoly munkavégzést. Nincs szükség információ megosztásra, nincs szükség motivációra, minimálisra lehet csökkenteni a szervezési feladatokat. Tervezni, feladatokat kiosztani és ellenőrizni azt kell.

További ok, hogy a többi vezetői stílust tanulni kell(ene). A mai modern, rohanó világunkban a vezetőknek nincs (vagy kevés) az ideje tanfolyamra menni, könyveket olvasni vagy másik sikeres vezetőtől tanulni. A legtöbb esetben „learn on the job” van. Információk hiányában a vezető legfeljebb csak sejtheti, hogy vezetni másképp is lehetne, de nem tudja hogyan és nem lesz előtte példa.

A command and control előnye, hogy jól működik B ligás beosztottakkal. A produktivitás kulcsa a vezető és az ő utasításai, nem pedig a beosztottak kreativitása. Vagyis nincs szükség kreatív, tapasztalt beosztottakra. Bárkit fel lehet venni és a dolog működni fog.

Magyar sajátosság, hogy hazánkban ennek a vezetői stílusnak van hagyománya. Ezt láttuk, ezt tanultuk, ezt fogjuk csinálni. Az utánunk jövők is ezt fogják eltanulni tőlünk, ezt fogják csinálni ha oda kerülnek, és majd ezt tanítják az utánuk jövőknek. A kör bezárult.

Hogyan csinálhatja valaki jól a command and control-t? A legkritikusabb tényező a keménység, azaz képes-e a vezető utasításokat osztogatni és utána bevasalni azok végrehajtását, vagy nem. Aki józan észre, belátásra vagy jóindulatra apellál, az keressen másik szakmát.

A command and control fontos eleme, hogy az utasításokat nem végrehajtó beosztottakat/katonákat megbüntetik. A keménység tehát belső keménységet is jelent: képesnek kell lennünk büntetni, adott esetben szívfájdalom nélkül kirúgni a nem-teljesítő beosztottat.

Megjegyzem, hogy a keménység, a határozott fellépés, a „my way or no way” hozzáállás az, ami az állásinterjún elsődleges szűrőfeltétel lesz.

A keménységen felül szükség van jó adminisztrációs készségre. Képesek legyünk tervet készíteni, a terv mentén haladni és azt folyamatosan ellenőrizni. Excel és MS Project a fő eszközök (vagy ezekkel ekvivalens szoftverek, a politikai korrektség kedvéért). Aki nem tud az íróasztal mögül Excel táblán szöszmötölve embereket tologatni, az szintén keressen másik szakmát.

Mit tegyen az a vezető, aki szeretne kitörni a command and control világából?

Képezze saját magát. A tanácsadók és az oktató cégek nagyon is jól ismerik a vezetői stílusokat és a többi módszert. Rengeteg tanfolyam elérhető. Egyszerűen csak el kell menni és megtanulni. Rá kell szánni az időt és a pénzt, 1000-szer megéri.

Szakkönyvből rengeteg van, az interneten gyakorlatilag végtelen mennyiségű információ, útmutató és cikk található.

A legjobb persze az, ha találunk egy olyan főnököt, aki más módszerekkel dolgozik, és akkor tőle el lehet lesni a fortélyokat (mint kisinas a céhmestertől).

A cégeket általában az eredmény érdekli, nem pedig az, ahogyan az eredményig eljutottunk. Természetesen a cégkultúra befolyásolhatja ezt pozitív vagy negatív irányban. Mindenképpen célszerű olyan cégnél dolgozni, ahol a parancsuralmon túl is létezik élet, ahol az eredményességet objektíven mérik és elismerik.

Mit takar ez a kifejezés, mire használjuk és miért elterjedt?

Vajon mit takarhat a „Command and control” kifejezés? Ha a wikipédián rákeresünk, akkor egy katonai szakkifejezéshez jutunk: az elöljáró tiszt irányítását és felügyeletét jelenti, amelynek segítésével a hozzá rendelt erők végrehajtanak egy küldetést. Irányítás és felügyelet. A tiszt parancsokat ad, a katonák végrehajtják.

Aki számítógéppel játszik, annak a kifejezésről a Command and Conquer című nagy sikerű játék ugrik be. Nem véletlenül, hiszen a C&C egy katonai stratégiai játék, és mint ilyen nagyon is köze lehet a katonai alapelvekhez.

A kifejezés azonban nem csak katonai körökben használatos, hanem üzleti körökben is. Lásd Command and control (management) szócikket a Wikipedián. A Command and control nem más, mint a direktív vezetői stílus.

A vezető a rá ruházott hatalom segítségével a beosztottait különböző feladatok végrehajtására utasítja, az utasítások végrehajtását ellenőrzi. Így képes a csapat közösen egy nagyobb célt elérni. A cél eléréséhez a vezető kulcsfontosságú, hiszen ő hoz döntéseket és ő határozza meg a részfeladatokat. A beosztottak csak végrehajtanak, pusztán eszközök a vezető kezében.

A kommunikáció egyirányú, felülről lefelé. Csak a vezető rendelkezik elégséges információval, az információ nem megosztott.

A Command and control (CC2) a vezetés minden szintjén alkalmazható, ebből a szempontból univerzális.

Biztos vagyok benne, hogy már mindenki dolgozott ilyen környezetben, tehát semmi újat nem mondtam.

Helyes-e a Command and control alkalmazása? Az biztos, hogy egy működő és bevált módszerről beszélünk.

A másik oldalról viszont nem vagyok benne biztos, hogy a legjobb. Már a wikis cikkben is említik, hogy manapság sokan elavultnak tekintik. A direktív vezetői stílus csak egy a 4 fő vezető stílus közül (direktív-supportív-coaching-delegating) a szituációs vezetés elmélet szerint. (Amit már említettem e blogon: Management styles)

A szituációs, avagy helyzetfüggő vezetés sokkal jobb a command and control-nál, hiszen a külső tényezőket is figyelembe veszi (például egyéni kompetenciák, csapat kohézió, motiváció, szervezeti kultúra), ezekhez alkalmazkodva választja ki a megfelelő vezetési stílust.

Az általános vélekedés (és szerény véleményem) szerint a motivált és kompetens csapat jobban teljesít, mint egy csapat intelligens majom. A direktív vezetés pontosan intelligens majmokká redukálja a csapatot. Ha növelni akarjuk a belső hatékonyságot, akkor a csapatot fokozatosan fejleszteni kell mind kompetencia, mind motiváció terén, hogy aztán szép lassan elengedjük a kezüket, és utasítások (command and control) helyett hagyjuk őket dolgozni (empowerment).

Természetesen ez sok tényezőtől függ – előfordulhat, hogy az adott helyzetben a direktív vezető hatékonyabb.

Ha ez igaz, akkor miért elterjedt a command and control, miért van sok direktív vezető? Miért kevésbé elterjedt és megértett a coaching vagy az empowerment?

Ennek rengeteg oka van, a teljesség igénye nélkül íme néhány:

A direktív vezetést hozzuk magunkkal. Otthon a szüleinknek volt hatalma felettünk, akik utasítottak. Az iskolában a tanáraink voltak a „feljebbvalóink”, akkor utasítottak erre vagy arra (pl. „csináld meg a házi feladatot”). Belénk nevelték ezt az alá-fölérendeltségi viszonyt, az utasítás végrehajtását, és azt, hogy nem szükséges a dolgok hátterével tisztában lenni. Amikor valaki minden előzetes tapasztalat nélkül menedzser lesz, akkor a hozott reflexekhez nyúl: automatikusan elkezd parancsokat osztogatni és elvárja azok végrehajtását a beosztottaktól. Egyszerűen nincs másik hozott modell.

A Command and control népszerűségének másik okát a katonaságban látják. Régen volt a kötelező sorkatonaság, ott az ember szembesült ezzel a vezetői stílussal, ha akart ha nem. Aztán amikor kinevezik vezetőnek, akkor reflexszerűen a korábban látott példát alkalmazza – függetlenül attól, hogy az jó vagy rossz.

A harmadik oka az egyszerűség. Nagyon egyszerű azt mondani a beosztottnak, hogy csináld meg ezt a feladatot, aztán pedig amikor jön a határidő, akkor rákérdezni az eredményre. Ezt a rutint könnyű felvenni, könnyű alkalmazni. Nincs szükség hosszú és drága képzésre. A dolog csak úgy jön magától.

Az egyszerűség mellett a command and control a vezetőtől nem igényel komoly munkavégzést. Nincs szükség információ megosztásra, nincs szükség motivációra, minimálisra lehet csökkenteni a szervezési feladatokat. Tervezni, feladatokat kiosztani és ellenőrizni azt kell.

További ok, hogy a többi vezetői stílust tanulni kell(ene). A mai modern, rohanó világunkban a vezetőknek nincs (vagy kevés) az ideje tanfolyamra menni, könyveket olvasni vagy másik sikeres vezetőtől tanulni. A legtöbb esetben „learn on the job” van. Információk hiányában a vezető legfeljebb csak sejtheti, hogy vezetni másképp is lehetne, de nem tudja hogyan és nem lesz előtte példa.

A command and control előnye, hogy jól működik B ligás beosztottakkal. A produktivitás kulcsa a vezető és az ő utasításai, nem pedig a beosztottak kreativitása. Vagyis nincs szükség kreatív, tapasztalt beosztottakra. Bárkit fel lehet venni és a dolog működni fog.

Magyar sajátosság, hogy hazánkban ennek a vezetői stílusnak van hagyománya. Ezt láttuk, ezt tanultuk, ezt fogjuk csinálni. Az utánunk jövők is ezt fogják eltanulni tőlünk, ezt fogják csinálni ha oda kerülnek, és majd ezt tanítják az utánuk jövőknek. A kör bezárult.

Hogyan csinálhatja valaki jól a command and control-t? A legkritikusabb tényező a keménység, azaz képes-e a vezető utasításokat osztogatni és utána bevasalni azok végrehajtását, vagy nem. Aki józan észre, belátásra vagy jóindulatra apellál, az keressen másik szakmát.

A command and control fontos eleme, hogy az utasításokat nem végrehajtó beosztottakat/katonákat megbüntetik. A keménység tehát belső keménységet is jelent: képesnek kell lennünk büntetni, adott esetben szívfájdalom nélkül kirúgni a nem-teljesítő beosztottat.

Megjegyzem, hogy a keménység, a határozott fellépés, a „my way or no way” hozzáállás az, ami az állásinterjún elsődleges szűrőfeltétel lesz.

A keménységen felül szükség van jó adminisztrációs készségre. Képesek legyünk tervet készíteni, a terv mentén haladni és azt folyamatosan ellenőrizni. Excel és MS Project a fő eszközök (vagy ezekkel ekvivalens szoftverek, a politikai korrektség kedvéért). Aki nem tud az íróasztal mögül Excel táblán szöszmötölve embereket tologatni, az szintén keressen másik szakmát.

Mit tegyen az a vezető, aki szeretne kitörni a command and control világából?

Képezze saját magát. A tanácsadók és az oktató cégek nagyon is jól ismerik a vezetői stílusokat és a többi módszert. Rengeteg tanfolyam elérhető. Egyszerűen csak el kell menni és megtanulni. Rá kell szánni az időt és a pénzt, 1000-szer megéri.

Szakkönyvből rengeteg van, az interneten gyakorlatilag végtelen mennyiségű információ, útmutató és cikk található.

A legjobb persze az, ha találunk egy olyan főnököt, aki más módszerekkel dolgozik, és akkor tőle el lehet lesni a fortélyokat (mint kisinas a céhmestertől).

A cégeket általában az eredmény érdekli, nem pedig az, ahogyan az eredményig eljutottunk. Természetesen a cégkultúra befolyásolhatja ezt pozitív vagy negatív irányban. Mindenképpen célszerű olyan cégnél dolgozni, ahol a parancsuralmon túl is létezik élet, ahol az eredményességet objektíven mérik és elismerik.

Mit takar ez a kifejezés, mire használjuk és miért elterjedt?

Vajon mit takarhat a „Command and control” kifejezés? Ha a wikipédián rákeresünk, akkor egy katonai szakkifejezéshez jutunk: az elöljáró tiszt irányítását és felügyeletét jelenti, amelynek segítésével a hozzá rendelt erők végrehajtanak egy küldetést. Irányítás és felügyelet. A tiszt parancsokat ad, a katonák végrehajtják.

Aki számítógéppel játszik, annak a kifejezésről a Command and Conquer című nagy sikerű játék ugrik be. Nem véletlenül, hiszen a C&C egy katonai stratégiai játék, és mint ilyen nagyon is köze lehet a katonai alapelvekhez.

A kifejezés azonban nem csak katonai körökben használatos, hanem üzleti körökben is. Lásd Command and control (management) szócikket a Wikipedián. A Command and control nem más, mint a direktív vezetői stílus.

A vezető a rá ruházott hatalom segítségével a beosztottait különböző feladatok végrehajtására utasítja, az utasítások végrehajtását ellenőrzi. Így képes a csapat közösen egy nagyobb célt elérni. A cél eléréséhez a vezető kulcsfontosságú, hiszen ő hoz döntéseket és ő határozza meg a részfeladatokat. A beosztottak csak végrehajtanak, pusztán eszközök a vezető kezében.

A kommunikáció egyirányú, felülről lefelé. Csak a vezető rendelkezik elégséges információval, az információ nem megosztott.

A Command and control (CC2) a vezetés minden szintjén alkalmazható, ebből a szempontból univerzális.

Biztos vagyok benne, hogy már mindenki dolgozott ilyen környezetben, tehát semmi újat nem mondtam.

Helyes-e a Command and control alkalmazása? Az biztos, hogy egy működő és bevált módszerről beszélünk.

A másik oldalról viszont nem vagyok benne biztos, hogy a legjobb. Már a wikis cikkben is említik, hogy manapság sokan elavultnak tekintik. A direktív vezetői stílus csak egy a 4 fő vezető stílus közül (direktív-supportív-coaching-delegating) a szituációs vezetés elmélet szerint. (Amit már említettem e blogon: Management styles)

A szituációs, avagy helyzetfüggő vezetés sokkal jobb a command and control-nál, hiszen a külső tényezőket is figyelembe veszi (például egyéni kompetenciák, csapat kohézió, motiváció, szervezeti kultúra), ezekhez alkalmazkodva választja ki a megfelelő vezetési stílust.

Az általános vélekedés (és szerény véleményem) szerint a motivált és kompetens csapat jobban teljesít, mint egy csapat intelligens majom. A direktív vezetés pontosan intelligens majmokká redukálja a csapatot. Ha növelni akarjuk a belső hatékonyságot, akkor a csapatot fokozatosan fejleszteni kell mind kompetencia, mind motiváció terén, hogy aztán szép lassan elengedjük a kezüket, és utasítások (command and control) helyett hagyjuk őket dolgozni (empowerment).

Természetesen ez sok tényezőtől függ – előfordulhat, hogy az adott helyzetben a direktív vezető hatékonyabb.

Ha ez igaz, akkor miért elterjedt a command and control, miért van sok direktív vezető? Miért kevésbé elterjedt és megértett a coaching vagy az empowerment?

Ennek rengeteg oka van, a teljesség igénye nélkül íme néhány:

A direktív vezetést hozzuk magunkkal. Otthon a szüleinknek volt hatalma felettünk, akik utasítottak. Az iskolában a tanáraink voltak a „feljebbvalóink”, akkor utasítottak erre vagy arra (pl. „csináld meg a házi feladatot”). Belénk nevelték ezt az alá-fölérendeltségi viszonyt, az utasítás végrehajtását, és azt, hogy nem szükséges a dolgok hátterével tisztában lenni. Amikor valaki minden előzetes tapasztalat nélkül menedzser lesz, akkor a hozott reflexekhez nyúl: automatikusan elkezd parancsokat osztogatni és elvárja azok végrehajtását a beosztottaktól. Egyszerűen nincs másik hozott modell.

A Command and control népszerűségének másik okát a katonaságban látják. Régen volt a kötelező sorkatonaság, ott az ember szembesült ezzel a vezetői stílussal, ha akart ha nem. Aztán amikor kinevezik vezetőnek, akkor reflexszerűen a korábban látott példát alkalmazza – függetlenül attól, hogy az jó vagy rossz.

A harmadik oka az egyszerűség. Nagyon egyszerű azt mondani a beosztottnak, hogy csináld meg ezt a feladatot, aztán pedig amikor jön a határidő, akkor rákérdezni az eredményre. Ezt a rutint könnyű felvenni, könnyű alkalmazni. Nincs szükség hosszú és drága képzésre. A dolog csak úgy jön magától.

Az egyszerűség mellett a command and control a vezetőtől nem igényel komoly munkavégzést. Nincs szükség információ megosztásra, nincs szükség motivációra, minimálisra lehet csökkenteni a szervezési feladatokat. Tervezni, feladatokat kiosztani és ellenőrizni azt kell.

További ok, hogy a többi vezetői stílust tanulni kell(ene). A mai modern, rohanó világunkban a vezetőknek nincs (vagy kevés) az ideje tanfolyamra menni, könyveket olvasni vagy másik sikeres vezetőtől tanulni. A legtöbb esetben „learn on the job” van. Információk hiányában a vezető legfeljebb csak sejtheti, hogy vezetni másképp is lehetne, de nem tudja hogyan és nem lesz előtte példa.

A command and control előnye, hogy jól működik B ligás beosztottakkal. A produktivitás kulcsa a vezető és az ő utasításai, nem pedig a beosztottak kreativitása. Vagyis nincs szükség kreatív, tapasztalt beosztottakra. Bárkit fel lehet venni és a dolog működni fog.

Magyar sajátosság, hogy hazánkban ennek a vezetői stílusnak van hagyománya. Ezt láttuk, ezt tanultuk, ezt fogjuk csinálni. Az utánunk jövők is ezt fogják eltanulni tőlünk, ezt fogják csinálni ha oda kerülnek, és majd ezt tanítják az utánuk jövőknek. A kör bezárult.

Hogyan csinálhatja valaki jól a command and control-t? A legkritikusabb tényező a keménység, azaz képes-e a vezető utasításokat osztogatni és utána bevasalni azok végrehajtását, vagy nem. Aki józan észre, belátásra vagy jóindulatra apellál, az keressen másik szakmát.

A command and control fontos eleme, hogy az utasításokat nem végrehajtó beosztottakat/katonákat megbüntetik. A keménység tehát belső keménységet is jelent: képesnek kell lennünk büntetni, adott esetben szívfájdalom nélkül kirúgni a nem-teljesítő beosztottat.

Megjegyzem, hogy a keménység, a határozott fellépés, a „my way or no way” hozzáállás az, ami az állásinterjún elsődleges szűrőfeltétel lesz.

A keménységen felül szükség van jó adminisztrációs készségre. Képesek legyünk tervet készíteni, a terv mentén haladni és azt folyamatosan ellenőrizni. Excel és MS Project a fő eszközök (vagy ezekkel ekvivalens szoftverek, a politikai korrektség kedvéért). Aki nem tud az íróasztal mögül Excel táblán szöszmötölve embereket tologatni, az szintén keressen másik szakmát.

Mit tegyen az a vezető, aki szeretne kitörni a command and control világából?

Képezze saját magát. A tanácsadók és az oktató cégek nagyon is jól ismerik a vezetői stílusokat és a többi módszert. Rengeteg tanfolyam elérhető. Egyszerűen csak el kell menni és megtanulni. Rá kell szánni az időt és a pénzt, 1000-szer megéri.

Szakkönyvből rengeteg van, az interneten gyakorlatilag végtelen mennyiségű információ, útmutató és cikk található.

A legjobb persze az, ha találunk egy olyan főnököt, aki más módszerekkel dolgozik, és akkor tőle el lehet lesni a fortélyokat (mint kisinas a céhmestertől).

A cégeket általában az eredmény érdekli, nem pedig az, ahogyan az eredményig eljutottunk. Természetesen a cégkultúra befolyásolhatja ezt pozitív vagy negatív irányban. Mindenképpen célszerű olyan cégnél dolgozni, ahol a parancsuralmon túl is létezik élet, ahol az eredményességet objektíven mérik és elismerik.

Mit takar ez a kifejezés, mire használjuk és miért elterjedt?

Vajon mit takarhat a „Command and control” kifejezés? Ha a wikipédián rákeresünk, akkor egy katonai szakkifejezéshez jutunk: az elöljáró tiszt irányítását és felügyeletét jelenti, amelynek segítésével a hozzá rendelt erők végrehajtanak egy küldetést. Irányítás és felügyelet. A tiszt parancsokat ad, a katonák végrehajtják.

Aki számítógéppel játszik, annak a kifejezésről a Command and Conquer című nagy sikerű játék ugrik be. Nem véletlenül, hiszen a C&C egy katonai stratégiai játék, és mint ilyen nagyon is köze lehet a katonai alapelvekhez.

A kifejezés azonban nem csak katonai körökben használatos, hanem üzleti körökben is. Lásd Command and control (management) szócikket a Wikipedián. A Command and control nem más, mint a direktív vezetői stílus.

A vezető a rá ruházott hatalom segítségével a beosztottait különböző feladatok végrehajtására utasítja, az utasítások végrehajtását ellenőrzi. Így képes a csapat közösen egy nagyobb célt elérni. A cél eléréséhez a vezető kulcsfontosságú, hiszen ő hoz döntéseket és ő határozza meg a részfeladatokat. A beosztottak csak végrehajtanak, pusztán eszközök a vezető kezében.

A kommunikáció egyirányú, felülről lefelé. Csak a vezető rendelkezik elégséges információval, az információ nem megosztott.

A Command and control (CC2) a vezetés minden szintjén alkalmazható, ebből a szempontból univerzális.

Biztos vagyok benne, hogy már mindenki dolgozott ilyen környezetben, tehát semmi újat nem mondtam.

Helyes-e a Command and control alkalmazása? Az biztos, hogy egy működő és bevált módszerről beszélünk.

A másik oldalról viszont nem vagyok benne biztos, hogy a legjobb. Már a wikis cikkben is említik, hogy manapság sokan elavultnak tekintik. A direktív vezetői stílus csak egy a 4 fő vezető stílus közül (direktív-supportív-coaching-delegating) a szituációs vezetés elmélet szerint. (Amit már említettem e blogon: Management styles)

A szituációs, avagy helyzetfüggő vezetés sokkal jobb a command and control-nál, hiszen a külső tényezőket is figyelembe veszi (például egyéni kompetenciák, csapat kohézió, motiváció, szervezeti kultúra), ezekhez alkalmazkodva választja ki a megfelelő vezetési stílust.

Az általános vélekedés (és szerény véleményem) szerint a motivált és kompetens csapat jobban teljesít, mint egy csapat intelligens majom. A direktív vezetés pontosan intelligens majmokká redukálja a csapatot. Ha növelni akarjuk a belső hatékonyságot, akkor a csapatot fokozatosan fejleszteni kell mind kompetencia, mind motiváció terén, hogy aztán szép lassan elengedjük a kezüket, és utasítások (command and control) helyett hagyjuk őket dolgozni (empowerment).

Természetesen ez sok tényezőtől függ – előfordulhat, hogy az adott helyzetben a direktív vezető hatékonyabb.

Ha ez igaz, akkor miért elterjedt a command and control, miért van sok direktív vezető? Miért kevésbé elterjedt és megértett a coaching vagy az empowerment?

Ennek rengeteg oka van, a teljesség igénye nélkül íme néhány:

A direktív vezetést hozzuk magunkkal. Otthon a szüleinknek volt hatalma felettünk, akik utasítottak. Az iskolában a tanáraink voltak a „feljebbvalóink”, akkor utasítottak erre vagy arra (pl. „csináld meg a házi feladatot”). Belénk nevelték ezt az alá-fölérendeltségi viszonyt, az utasítás végrehajtását, és azt, hogy nem szükséges a dolgok hátterével tisztában lenni. Amikor valaki minden előzetes tapasztalat nélkül menedzser lesz, akkor a hozott reflexekhez nyúl: automatikusan elkezd parancsokat osztogatni és elvárja azok végrehajtását a beosztottaktól. Egyszerűen nincs másik hozott modell.

A Command and control népszerűségének másik okát a katonaságban látják. Régen volt a kötelező sorkatonaság, ott az ember szembesült ezzel a vezetői stílussal, ha akart ha nem. Aztán amikor kinevezik vezetőnek, akkor reflexszerűen a korábban látott példát alkalmazza – függetlenül attól, hogy az jó vagy rossz.

A harmadik oka az egyszerűség. Nagyon egyszerű azt mondani a beosztottnak, hogy csináld meg ezt a feladatot, aztán pedig amikor jön a határidő, akkor rákérdezni az eredményre. Ezt a rutint könnyű felvenni, könnyű alkalmazni. Nincs szükség hosszú és drága képzésre. A dolog csak úgy jön magától.

Az egyszerűség mellett a command and control a vezetőtől nem igényel komoly munkavégzést. Nincs szükség információ megosztásra, nincs szükség motivációra, minimálisra lehet csökkenteni a szervezési feladatokat. Tervezni, feladatokat kiosztani és ellenőrizni azt kell.

További ok, hogy a többi vezetői stílust tanulni kell(ene). A mai modern, rohanó világunkban a vezetőknek nincs (vagy kevés) az ideje tanfolyamra menni, könyveket olvasni vagy másik sikeres vezetőtől tanulni. A legtöbb esetben „learn on the job” van. Információk hiányában a vezető legfeljebb csak sejtheti, hogy vezetni másképp is lehetne, de nem tudja hogyan és nem lesz előtte példa.

A command and control előnye, hogy jól működik B ligás beosztottakkal. A produktivitás kulcsa a vezető és az ő utasításai, nem pedig a beosztottak kreativitása. Vagyis nincs szükség kreatív, tapasztalt beosztottakra. Bárkit fel lehet venni és a dolog működni fog.

Magyar sajátosság, hogy hazánkban ennek a vezetői stílusnak van hagyománya. Ezt láttuk, ezt tanultuk, ezt fogjuk csinálni. Az utánunk jövők is ezt fogják eltanulni tőlünk, ezt fogják csinálni ha oda kerülnek, és majd ezt tanítják az utánuk jövőknek. A kör bezárult.

Hogyan csinálhatja valaki jól a command and control-t? A legkritikusabb tényező a keménység, azaz képes-e a vezető utasításokat osztogatni és utána bevasalni azok végrehajtását, vagy nem. Aki józan észre, belátásra vagy jóindulatra apellál, az keressen másik szakmát.

A command and control fontos eleme, hogy az utasításokat nem végrehajtó beosztottakat/katonákat megbüntetik. A keménység tehát belső keménységet is jelent: képesnek kell lennünk büntetni, adott esetben szívfájdalom nélkül kirúgni a nem-teljesítő beosztottat.

Megjegyzem, hogy a keménység, a határozott fellépés, a „my way or no way” hozzáállás az, ami az állásinterjún elsődleges szűrőfeltétel lesz.

A keménységen felül szükség van jó adminisztrációs készségre. Képesek legyünk tervet készíteni, a terv mentén haladni és azt folyamatosan ellenőrizni. Excel és MS Project a fő eszközök (vagy ezekkel ekvivalens szoftverek, a politikai korrektség kedvéért). Aki nem tud az íróasztal mögül Excel táblán szöszmötölve embereket tologatni, az szintén keressen másik szakmát.

Mit tegyen az a vezető, aki szeretne kitörni a command and control világából?

Képezze saját magát. A tanácsadók és az oktató cégek nagyon is jól ismerik a vezetői stílusokat és a többi módszert. Rengeteg tanfolyam elérhető. Egyszerűen csak el kell menni és megtanulni. Rá kell szánni az időt és a pénzt, 1000-szer megéri.

Szakkönyvből rengeteg van, az interneten gyakorlatilag végtelen mennyiségű információ, útmutató és cikk található.

A legjobb persze az, ha találunk egy olyan főnököt, aki más módszerekkel dolgozik, és akkor tőle el lehet lesni a fortélyokat (mint kisinas a céhmestertől).

A cégeket általában az eredmény érdekli, nem pedig az, ahogyan az eredményig eljutottunk. Természetesen a cégkultúra befolyásolhatja ezt pozitív vagy negatív irányban. Mindenképpen célszerű olyan cégnél dolgozni, ahol a parancsuralmon túl is létezik élet, ahol az eredményességet objektíven mérik és elismerik.

Érdemes-e az alkalmazás-támogatást elválasztani a szoftver fejlesztéstől?

Amikor programozásról beszélünk, akkor mindig elfelejtjük tisztázni, pontosan milyen céllal is tesszük azt. Ugyanis a programozás kétféle lehet:

1) Fejlesztés, azaz új funkciók vagy új alkalmazás készítése

2) Alkalmazás támogatás, azaz a meglévő funkciók hibáinak kijavítása

A kétféle munka teljesen különböző hozzáállást és módszereket igényel. Az első inkább kreatív, hosszú időtartami, fix határidővel. A második esetben a munka inkább sziszifuszi, alaposságot és kitartást igényel, általában sok apró feladatról van szó, amiket nem határidőre hanem minél hamarabb kell megcsinálni.

A kétféle feladat kezelésére 3 modell terjedt el:

a) Ugyanaz a csapat és ugyanazok a fejlesztők végzik el mind a fejlesztési, mind a támogatási feladatokat

b) Szétválasztják a fejlesztést a támogatástól, tehát külön fejlesztő írja a kódot és külön fejlesztő javítja a hibákat

c) Az első kettő keveréke, amikor ugyanaz a csapat végzi a fejlesztést és a támogatást, de a csapaton belül a fejlesztők tipikusan egyik vagy tipikusan másik feladatot végzik

Most nézzük meg részleteiben, mit is jelentenek ezek a modellek.

a) Ugyanaz a csapat csinál mindent

Ez a legtipikusabb felállás, különösen kisvállalkozásoknál. A tudás a fejlesztők fejében koncentrálódik, akik a létező összes feladatot ellátják, legyen az új igény vagy hibajavítás.

Az erőforrások az igények függvényében mozgathatók a feladatok között. Emiatt a munka változatos és hatékony. A programozók rálátnak arra, ki mit csinál, ezért ki tudják használni a közösség erejét illetve a szinergiákat. A változtatások egy kézben (vagy legalábbis közös kézben) vannak.

Óriási előnye a modellnek, hogy a csapat motivált a minőségi, hosszú távú megoldásokra – ugyanis a gyenge megoldások utána „takarítást” ugyanazoknak az embereknek kell végeznie.

A modell hátránya, hogy a fejlesztési projektek teljesítése a véletlenszerűen felmerülő hibaelhárítás miatt bizonytalan. Magyarul: megegyezünk, hogy mikorra lesz kész a fejlesztés, de ha felbukkan egy súlyos hiba a rendszeren, akkor értelemszerűen azzal kell foglalkozni, és a határidő elúszik.

A fejlesztők egy idő után frusztráltak lesznek, hogy az „értékteremtő” fejlesztést rendszeresen megszakítja az „unalmas” támogatási munka. Ha az alkalmazás elég nagy, akkor garantált lesz a sok „megszakítás”, amivel egy idő utána kezdeni kell valamit.

b) A fejlesztés és a támogatás szétválasztása

Nagy cégeknél, ahol sok támogatási feladat van (a nagy méretek miatt), gyakran szétválasztják a fejlesztést a támogatástól, nagyjából az alábbi előnyök miatt:

- A támogatási feladatatok sok esetben unalmas pepecselő munkát jelentenek, amit egy kezdő fejlesztő is el tud látni.

- Tehermentesítik a „guru” szintű fejlesztőket, hogy ők a projektekkel tudjanak foglalkozni.

- Az olcsóbb fejlesztők bevetése a támogatási feladatokra alacsonyabb költséget jelent. (Vagy nézzük másképp: a drága fejlesztők nem égetik az idejüket rutin feladatokkal)

- Az alkalmazás támogatás folyamat alapú (lásd ITIL), jól megszervezhető és mérhető, függetlenül az adott alkalmazástól vagy technológiától. A szinergiák kiaknázhatóak a támogató csapatok összevonásával.

A költséghatékonyság és a triviális előnyök mellett azonban a modellnek hátrányai is vannak:

- Senki nem lesz motivált abban, hogy hosszú távú megoldásokat készítsen. A fejlesztők nem érdekeltek benne, hiszen más takarít fel utánuk, miközben a „takarítók” a minél gyorsabb munkavégzésre lesznek rászorítva a minőségi megoldások helyett. Összességében, az alacsonyabb árat a rosszabb minőséggel fogjuk „kifizetni”.

- Nehéz fenntartani a motivációt az alkalmazás támogatóknál.

- A műszaki döntéseket a fejlesztők (a projekt csapat) hozza, miközben nincs rálátásuk arra, mit fognak jelenteni azok a döntések a napi munkára.

- A valóságban a fejlesztők is fognak alkalmazás támogatást végezni. Mivel a fejlesztők kezében van az alkalmazás tervezés, ezért szükségszerűen lesznek hibák, amiket a támogatók nem tudnak kijavítani. (Valójában csak az 1. és 2. szintű támogatást végzi másik csapat, a 3. szintű megmaradt)

Összességében tehát a költséghatékonyság látszólagos – kevesebbért elvégzik a munkát a támogatók, de az elvégzett munka is kevesebb lesz. A minőség romlik, ami hosszú távon plusz munkát és költséget fog okozni.

b2) A fejlesztés és a támogatás szétválasztása - kiszervezéssel

Modell szempontjából nem külön eset, de megemlítem azt a helyzetet, amikor az alkalmazás támogatást teljes egészében a cégen kívülre szervezik – mint nem „core” tevékenység.

A legjobb gyakorlat az ilyen kiszervezésre az, hogy az IT szolgáltatót hibajegyek alapján fizetik, valamilyen incentive rendszerben, ami egyszerre rugalmas (annyi munkát kell elvégezni, amennyire szükség van, amennyi ticket generálódik) és olcsó (az egy ticket-re fizetett árat jelentősen a saját költségek alá lehet vinni). Az IT szolgáltató alkalmazás támogatásra specializálódott, nagy tételben tudja a ticket-eket kezelni, az erőforrásokat igény szerint átcsoportosítani, tehát hatékonyabb tud lenni, mint a belső helpdesk.

Ez az elmélet.

A gyakorlatban ezzel két óriási probléma van:

- Ha a fejlesztőket azért fizetik, hogy hibát javítsanak, akkor ott sok hiba lesz

- A támogatás kiszervezésével óriásira növekszik a távolság a belső architect (aki műszaki döntéseket hoz és aki átlátja az architektúrát) illetve a hibajavító support között. Eredmény: olyan megoldások fognak születni, amik megborítják a szoftver egységét, további hibákat generálva.

c) Keverék megoldás: azonos csapat, de külön személyek

Az első két megoldás ötvözete, amikor is szétválasztjuk a funkciókat, de a fejlesztői illetve támogatói munkát végző informatikusok ugyanazon helyen ugyanazon csapat tagjaként dolgoznak. Ennek számtalan előnye van:

- Nem lesz információs szakadék az architekt és a support között

- A support látja az átfogó képet, értesül a műszaki döntésekről

- Ugyanakkor a feladatokat külön emberek végzik, megvalósul a guruk tehermentesítése

- Hatékonyan tud összedolgozni az „A” ligás és a „B” ligás fejlesztő – mindenki a saját területén a saját speciális feladataival foglalkozik

- Karrier lehetőség – átjárhatóság lesz a két feladatkör között, ami erős motivációs tényező

- Erőforrások mozgatása szükség szerint

Szerintem a „c” megoldás a legjobb, de az aktuális iparági ajánlás a „b”. Ami a kiszervezés miatt „b2” lesz.

Érdemes-e az alkalmazás-támogatást elválasztani a szoftver fejlesztéstől?

Amikor programozásról beszélünk, akkor mindig elfelejtjük tisztázni, pontosan milyen céllal is tesszük azt. Ugyanis a programozás kétféle lehet:

1) Fejlesztés, azaz új funkciók vagy új alkalmazás készítése

2) Alkalmazás támogatás, azaz a meglévő funkciók hibáinak kijavítása

A kétféle munka teljesen különböző hozzáállást és módszereket igényel. Az első inkább kreatív, hosszú időtartami, fix határidővel. A második esetben a munka inkább sziszifuszi, alaposságot és kitartást igényel, általában sok apró feladatról van szó, amiket nem határidőre hanem minél hamarabb kell megcsinálni.

A kétféle feladat kezelésére 3 modell terjedt el:

a) Ugyanaz a csapat és ugyanazok a fejlesztők végzik el mind a fejlesztési, mind a támogatási feladatokat

b) Szétválasztják a fejlesztést a támogatástól, tehát külön fejlesztő írja a kódot és külön fejlesztő javítja a hibákat

c) Az első kettő keveréke, amikor ugyanaz a csapat végzi a fejlesztést és a támogatást, de a csapaton belül a fejlesztők tipikusan egyik vagy tipikusan másik feladatot végzik

Most nézzük meg részleteiben, mit is jelentenek ezek a modellek.

a) Ugyanaz a csapat csinál mindent

Ez a legtipikusabb felállás, különösen kisvállalkozásoknál. A tudás a fejlesztők fejében koncentrálódik, akik a létező összes feladatot ellátják, legyen az új igény vagy hibajavítás.

Az erőforrások az igények függvényében mozgathatók a feladatok között. Emiatt a munka változatos és hatékony. A programozók rálátnak arra, ki mit csinál, ezért ki tudják használni a közösség erejét illetve a szinergiákat. A változtatások egy kézben (vagy legalábbis közös kézben) vannak.

Óriási előnye a modellnek, hogy a csapat motivált a minőségi, hosszú távú megoldásokra – ugyanis a gyenge megoldások utána „takarítást” ugyanazoknak az embereknek kell végeznie.

A modell hátránya, hogy a fejlesztési projektek teljesítése a véletlenszerűen felmerülő hibaelhárítás miatt bizonytalan. Magyarul: megegyezünk, hogy mikorra lesz kész a fejlesztés, de ha felbukkan egy súlyos hiba a rendszeren, akkor értelemszerűen azzal kell foglalkozni, és a határidő elúszik.

A fejlesztők egy idő után frusztráltak lesznek, hogy az „értékteremtő” fejlesztést rendszeresen megszakítja az „unalmas” támogatási munka. Ha az alkalmazás elég nagy, akkor garantált lesz a sok „megszakítás”, amivel egy idő utána kezdeni kell valamit.

b) A fejlesztés és a támogatás szétválasztása

Nagy cégeknél, ahol sok támogatási feladat van (a nagy méretek miatt), gyakran szétválasztják a fejlesztést a támogatástól, nagyjából az alábbi előnyök miatt:

- A támogatási feladatatok sok esetben unalmas pepecselő munkát jelentenek, amit egy kezdő fejlesztő is el tud látni.

- Tehermentesítik a „guru” szintű fejlesztőket, hogy ők a projektekkel tudjanak foglalkozni.

- Az olcsóbb fejlesztők bevetése a támogatási feladatokra alacsonyabb költséget jelent. (Vagy nézzük másképp: a drága fejlesztők nem égetik az idejüket rutin feladatokkal)

- Az alkalmazás támogatás folyamat alapú (lásd ITIL), jól megszervezhető és mérhető, függetlenül az adott alkalmazástól vagy technológiától. A szinergiák kiaknázhatóak a támogató csapatok összevonásával.

A költséghatékonyság és a triviális előnyök mellett azonban a modellnek hátrányai is vannak:

- Senki nem lesz motivált abban, hogy hosszú távú megoldásokat készítsen. A fejlesztők nem érdekeltek benne, hiszen más takarít fel utánuk, miközben a „takarítók” a minél gyorsabb munkavégzésre lesznek rászorítva a minőségi megoldások helyett. Összességében, az alacsonyabb árat a rosszabb minőséggel fogjuk „kifizetni”.

- Nehéz fenntartani a motivációt az alkalmazás támogatóknál.

- A műszaki döntéseket a fejlesztők (a projekt csapat) hozza, miközben nincs rálátásuk arra, mit fognak jelenteni azok a döntések a napi munkára.

- A valóságban a fejlesztők is fognak alkalmazás támogatást végezni. Mivel a fejlesztők kezében van az alkalmazás tervezés, ezért szükségszerűen lesznek hibák, amiket a támogatók nem tudnak kijavítani. (Valójában csak az 1. és 2. szintű támogatást végzi másik csapat, a 3. szintű megmaradt)

Összességében tehát a költséghatékonyság látszólagos – kevesebbért elvégzik a munkát a támogatók, de az elvégzett munka is kevesebb lesz. A minőség romlik, ami hosszú távon plusz munkát és költséget fog okozni.

b2) A fejlesztés és a támogatás szétválasztása - kiszervezéssel

Modell szempontjából nem külön eset, de megemlítem azt a helyzetet, amikor az alkalmazás támogatást teljes egészében a cégen kívülre szervezik – mint nem „core” tevékenység.

A legjobb gyakorlat az ilyen kiszervezésre az, hogy az IT szolgáltatót hibajegyek alapján fizetik, valamilyen incentive rendszerben, ami egyszerre rugalmas (annyi munkát kell elvégezni, amennyire szükség van, amennyi ticket generálódik) és olcsó (az egy ticket-re fizetett árat jelentősen a saját költségek alá lehet vinni). Az IT szolgáltató alkalmazás támogatásra specializálódott, nagy tételben tudja a ticket-eket kezelni, az erőforrásokat igény szerint átcsoportosítani, tehát hatékonyabb tud lenni, mint a belső helpdesk.

Ez az elmélet.

A gyakorlatban ezzel két óriási probléma van:

- Ha a fejlesztőket azért fizetik, hogy hibát javítsanak, akkor ott sok hiba lesz

- A támogatás kiszervezésével óriásira növekszik a távolság a belső architect (aki műszaki döntéseket hoz és aki átlátja az architektúrát) illetve a hibajavító support között. Eredmény: olyan megoldások fognak születni, amik megborítják a szoftver egységét, további hibákat generálva.

c) Keverék megoldás: azonos csapat, de külön személyek

Az első két megoldás ötvözete, amikor is szétválasztjuk a funkciókat, de a fejlesztői illetve támogatói munkát végző informatikusok ugyanazon helyen ugyanazon csapat tagjaként dolgoznak. Ennek számtalan előnye van:

- Nem lesz információs szakadék az architekt és a support között

- A support látja az átfogó képet, értesül a műszaki döntésekről

- Ugyanakkor a feladatokat külön emberek végzik, megvalósul a guruk tehermentesítése

- Hatékonyan tud összedolgozni az „A” ligás és a „B” ligás fejlesztő – mindenki a saját területén a saját speciális feladataival foglalkozik

- Karrier lehetőség – átjárhatóság lesz a két feladatkör között, ami erős motivációs tényező

- Erőforrások mozgatása szükség szerint

Szerintem a „c” megoldás a legjobb, de az aktuális iparági ajánlás a „b”. Ami a kiszervezés miatt „b2” lesz.

Érdemes-e az alkalmazás-támogatást elválasztani a szoftver fejlesztéstől?

Amikor programozásról beszélünk, akkor mindig elfelejtjük tisztázni, pontosan milyen céllal is tesszük azt. Ugyanis a programozás kétféle lehet:

1) Fejlesztés, azaz új funkciók vagy új alkalmazás készítése

2) Alkalmazás támogatás, azaz a meglévő funkciók hibáinak kijavítása

A kétféle munka teljesen különböző hozzáállást és módszereket igényel. Az első inkább kreatív, hosszú időtartami, fix határidővel. A második esetben a munka inkább sziszifuszi, alaposságot és kitartást igényel, általában sok apró feladatról van szó, amiket nem határidőre hanem minél hamarabb kell megcsinálni.

A kétféle feladat kezelésére 3 modell terjedt el:

a) Ugyanaz a csapat és ugyanazok a fejlesztők végzik el mind a fejlesztési, mind a támogatási feladatokat

b) Szétválasztják a fejlesztést a támogatástól, tehát külön fejlesztő írja a kódot és külön fejlesztő javítja a hibákat

c) Az első kettő keveréke, amikor ugyanaz a csapat végzi a fejlesztést és a támogatást, de a csapaton belül a fejlesztők tipikusan egyik vagy tipikusan másik feladatot végzik

Most nézzük meg részleteiben, mit is jelentenek ezek a modellek.

a) Ugyanaz a csapat csinál mindent

Ez a legtipikusabb felállás, különösen kisvállalkozásoknál. A tudás a fejlesztők fejében koncentrálódik, akik a létező összes feladatot ellátják, legyen az új igény vagy hibajavítás.

Az erőforrások az igények függvényében mozgathatók a feladatok között. Emiatt a munka változatos és hatékony. A programozók rálátnak arra, ki mit csinál, ezért ki tudják használni a közösség erejét illetve a szinergiákat. A változtatások egy kézben (vagy legalábbis közös kézben) vannak.

Óriási előnye a modellnek, hogy a csapat motivált a minőségi, hosszú távú megoldásokra – ugyanis a gyenge megoldások utána „takarítást” ugyanazoknak az embereknek kell végeznie.

A modell hátránya, hogy a fejlesztési projektek teljesítése a véletlenszerűen felmerülő hibaelhárítás miatt bizonytalan. Magyarul: megegyezünk, hogy mikorra lesz kész a fejlesztés, de ha felbukkan egy súlyos hiba a rendszeren, akkor értelemszerűen azzal kell foglalkozni, és a határidő elúszik.

A fejlesztők egy idő után frusztráltak lesznek, hogy az „értékteremtő” fejlesztést rendszeresen megszakítja az „unalmas” támogatási munka. Ha az alkalmazás elég nagy, akkor garantált lesz a sok „megszakítás”, amivel egy idő utána kezdeni kell valamit.

b) A fejlesztés és a támogatás szétválasztása

Nagy cégeknél, ahol sok támogatási feladat van (a nagy méretek miatt), gyakran szétválasztják a fejlesztést a támogatástól, nagyjából az alábbi előnyök miatt:

- A támogatási feladatatok sok esetben unalmas pepecselő munkát jelentenek, amit egy kezdő fejlesztő is el tud látni.

- Tehermentesítik a „guru” szintű fejlesztőket, hogy ők a projektekkel tudjanak foglalkozni.

- Az olcsóbb fejlesztők bevetése a támogatási feladatokra alacsonyabb költséget jelent. (Vagy nézzük másképp: a drága fejlesztők nem égetik az idejüket rutin feladatokkal)

- Az alkalmazás támogatás folyamat alapú (lásd ITIL), jól megszervezhető és mérhető, függetlenül az adott alkalmazástól vagy technológiától. A szinergiák kiaknázhatóak a támogató csapatok összevonásával.

A költséghatékonyság és a triviális előnyök mellett azonban a modellnek hátrányai is vannak:

- Senki nem lesz motivált abban, hogy hosszú távú megoldásokat készítsen. A fejlesztők nem érdekeltek benne, hiszen más takarít fel utánuk, miközben a „takarítók” a minél gyorsabb munkavégzésre lesznek rászorítva a minőségi megoldások helyett. Összességében, az alacsonyabb árat a rosszabb minőséggel fogjuk „kifizetni”.

- Nehéz fenntartani a motivációt az alkalmazás támogatóknál.

- A műszaki döntéseket a fejlesztők (a projekt csapat) hozza, miközben nincs rálátásuk arra, mit fognak jelenteni azok a döntések a napi munkára.

- A valóságban a fejlesztők is fognak alkalmazás támogatást végezni. Mivel a fejlesztők kezében van az alkalmazás tervezés, ezért szükségszerűen lesznek hibák, amiket a támogatók nem tudnak kijavítani. (Valójában csak az 1. és 2. szintű támogatást végzi másik csapat, a 3. szintű megmaradt)

Összességében tehát a költséghatékonyság látszólagos – kevesebbért elvégzik a munkát a támogatók, de az elvégzett munka is kevesebb lesz. A minőség romlik, ami hosszú távon plusz munkát és költséget fog okozni.

b2) A fejlesztés és a támogatás szétválasztása - kiszervezéssel

Modell szempontjából nem külön eset, de megemlítem azt a helyzetet, amikor az alkalmazás támogatást teljes egészében a cégen kívülre szervezik – mint nem „core” tevékenység.

A legjobb gyakorlat az ilyen kiszervezésre az, hogy az IT szolgáltatót hibajegyek alapján fizetik, valamilyen incentive rendszerben, ami egyszerre rugalmas (annyi munkát kell elvégezni, amennyire szükség van, amennyi ticket generálódik) és olcsó (az egy ticket-re fizetett árat jelentősen a saját költségek alá lehet vinni). Az IT szolgáltató alkalmazás támogatásra specializálódott, nagy tételben tudja a ticket-eket kezelni, az erőforrásokat igény szerint átcsoportosítani, tehát hatékonyabb tud lenni, mint a belső helpdesk.

Ez az elmélet.

A gyakorlatban ezzel két óriási probléma van:

- Ha a fejlesztőket azért fizetik, hogy hibát javítsanak, akkor ott sok hiba lesz

- A támogatás kiszervezésével óriásira növekszik a távolság a belső architect (aki műszaki döntéseket hoz és aki átlátja az architektúrát) illetve a hibajavító support között. Eredmény: olyan megoldások fognak születni, amik megborítják a szoftver egységét, további hibákat generálva.

c) Keverék megoldás: azonos csapat, de külön személyek

Az első két megoldás ötvözete, amikor is szétválasztjuk a funkciókat, de a fejlesztői illetve támogatói munkát végző informatikusok ugyanazon helyen ugyanazon csapat tagjaként dolgoznak. Ennek számtalan előnye van:

- Nem lesz információs szakadék az architekt és a support között

- A support látja az átfogó képet, értesül a műszaki döntésekről

- Ugyanakkor a feladatokat külön emberek végzik, megvalósul a guruk tehermentesítése

- Hatékonyan tud összedolgozni az „A” ligás és a „B” ligás fejlesztő – mindenki a saját területén a saját speciális feladataival foglalkozik

- Karrier lehetőség – átjárhatóság lesz a két feladatkör között, ami erős motivációs tényező

- Erőforrások mozgatása szükség szerint

Szerintem a „c” megoldás a legjobb, de az aktuális iparági ajánlás a „b”. Ami a kiszervezés miatt „b2” lesz.

Érdemes-e az alkalmazás-támogatást elválasztani a szoftver fejlesztéstől?

Amikor programozásról beszélünk, akkor mindig elfelejtjük tisztázni, pontosan milyen céllal is tesszük azt. Ugyanis a programozás kétféle lehet:

1) Fejlesztés, azaz új funkciók vagy új alkalmazás készítése

2) Alkalmazás támogatás, azaz a meglévő funkciók hibáinak kijavítása

A kétféle munka teljesen különböző hozzáállást és módszereket igényel. Az első inkább kreatív, hosszú időtartami, fix határidővel. A második esetben a munka inkább sziszifuszi, alaposságot és kitartást igényel, általában sok apró feladatról van szó, amiket nem határidőre hanem minél hamarabb kell megcsinálni.

A kétféle feladat kezelésére 3 modell terjedt el:

a) Ugyanaz a csapat és ugyanazok a fejlesztők végzik el mind a fejlesztési, mind a támogatási feladatokat

b) Szétválasztják a fejlesztést a támogatástól, tehát külön fejlesztő írja a kódot és külön fejlesztő javítja a hibákat

c) Az első kettő keveréke, amikor ugyanaz a csapat végzi a fejlesztést és a támogatást, de a csapaton belül a fejlesztők tipikusan egyik vagy tipikusan másik feladatot végzik

Most nézzük meg részleteiben, mit is jelentenek ezek a modellek.

a) Ugyanaz a csapat csinál mindent

Ez a legtipikusabb felállás, különösen kisvállalkozásoknál. A tudás a fejlesztők fejében koncentrálódik, akik a létező összes feladatot ellátják, legyen az új igény vagy hibajavítás.

Az erőforrások az igények függvényében mozgathatók a feladatok között. Emiatt a munka változatos és hatékony. A programozók rálátnak arra, ki mit csinál, ezért ki tudják használni a közösség erejét illetve a szinergiákat. A változtatások egy kézben (vagy legalábbis közös kézben) vannak.

Óriási előnye a modellnek, hogy a csapat motivált a minőségi, hosszú távú megoldásokra – ugyanis a gyenge megoldások utána „takarítást” ugyanazoknak az embereknek kell végeznie.

A modell hátránya, hogy a fejlesztési projektek teljesítése a véletlenszerűen felmerülő hibaelhárítás miatt bizonytalan. Magyarul: megegyezünk, hogy mikorra lesz kész a fejlesztés, de ha felbukkan egy súlyos hiba a rendszeren, akkor értelemszerűen azzal kell foglalkozni, és a határidő elúszik.

A fejlesztők egy idő után frusztráltak lesznek, hogy az „értékteremtő” fejlesztést rendszeresen megszakítja az „unalmas” támogatási munka. Ha az alkalmazás elég nagy, akkor garantált lesz a sok „megszakítás”, amivel egy idő utána kezdeni kell valamit.

b) A fejlesztés és a támogatás szétválasztása

Nagy cégeknél, ahol sok támogatási feladat van (a nagy méretek miatt), gyakran szétválasztják a fejlesztést a támogatástól, nagyjából az alábbi előnyök miatt:

- A támogatási feladatatok sok esetben unalmas pepecselő munkát jelentenek, amit egy kezdő fejlesztő is el tud látni.

- Tehermentesítik a „guru” szintű fejlesztőket, hogy ők a projektekkel tudjanak foglalkozni.

- Az olcsóbb fejlesztők bevetése a támogatási feladatokra alacsonyabb költséget jelent. (Vagy nézzük másképp: a drága fejlesztők nem égetik az idejüket rutin feladatokkal)

- Az alkalmazás támogatás folyamat alapú (lásd ITIL), jól megszervezhető és mérhető, függetlenül az adott alkalmazástól vagy technológiától. A szinergiák kiaknázhatóak a támogató csapatok összevonásával.

A költséghatékonyság és a triviális előnyök mellett azonban a modellnek hátrányai is vannak:

- Senki nem lesz motivált abban, hogy hosszú távú megoldásokat készítsen. A fejlesztők nem érdekeltek benne, hiszen más takarít fel utánuk, miközben a „takarítók” a minél gyorsabb munkavégzésre lesznek rászorítva a minőségi megoldások helyett. Összességében, az alacsonyabb árat a rosszabb minőséggel fogjuk „kifizetni”.

- Nehéz fenntartani a motivációt az alkalmazás támogatóknál.

- A műszaki döntéseket a fejlesztők (a projekt csapat) hozza, miközben nincs rálátásuk arra, mit fognak jelenteni azok a döntések a napi munkára.

- A valóságban a fejlesztők is fognak alkalmazás támogatást végezni. Mivel a fejlesztők kezében van az alkalmazás tervezés, ezért szükségszerűen lesznek hibák, amiket a támogatók nem tudnak kijavítani. (Valójában csak az 1. és 2. szintű támogatást végzi másik csapat, a 3. szintű megmaradt)

Összességében tehát a költséghatékonyság látszólagos – kevesebbért elvégzik a munkát a támogatók, de az elvégzett munka is kevesebb lesz. A minőség romlik, ami hosszú távon plusz munkát és költséget fog okozni.

b2) A fejlesztés és a támogatás szétválasztása - kiszervezéssel

Modell szempontjából nem külön eset, de megemlítem azt a helyzetet, amikor az alkalmazás támogatást teljes egészében a cégen kívülre szervezik – mint nem „core” tevékenység.

A legjobb gyakorlat az ilyen kiszervezésre az, hogy az IT szolgáltatót hibajegyek alapján fizetik, valamilyen incentive rendszerben, ami egyszerre rugalmas (annyi munkát kell elvégezni, amennyire szükség van, amennyi ticket generálódik) és olcsó (az egy ticket-re fizetett árat jelentősen a saját költségek alá lehet vinni). Az IT szolgáltató alkalmazás támogatásra specializálódott, nagy tételben tudja a ticket-eket kezelni, az erőforrásokat igény szerint átcsoportosítani, tehát hatékonyabb tud lenni, mint a belső helpdesk.

Ez az elmélet.

A gyakorlatban ezzel két óriási probléma van:

- Ha a fejlesztőket azért fizetik, hogy hibát javítsanak, akkor ott sok hiba lesz

- A támogatás kiszervezésével óriásira növekszik a távolság a belső architect (aki műszaki döntéseket hoz és aki átlátja az architektúrát) illetve a hibajavító support között. Eredmény: olyan megoldások fognak születni, amik megborítják a szoftver egységét, további hibákat generálva.

c) Keverék megoldás: azonos csapat, de külön személyek

Az első két megoldás ötvözete, amikor is szétválasztjuk a funkciókat, de a fejlesztői illetve támogatói munkát végző informatikusok ugyanazon helyen ugyanazon csapat tagjaként dolgoznak. Ennek számtalan előnye van:

- Nem lesz információs szakadék az architekt és a support között

- A support látja az átfogó képet, értesül a műszaki döntésekről

- Ugyanakkor a feladatokat külön emberek végzik, megvalósul a guruk tehermentesítése

- Hatékonyan tud összedolgozni az „A” ligás és a „B” ligás fejlesztő – mindenki a saját területén a saját speciális feladataival foglalkozik

- Karrier lehetőség – átjárhatóság lesz a két feladatkör között, ami erős motivációs tényező

- Erőforrások mozgatása szükség szerint

Szerintem a „c” megoldás a legjobb, de az aktuális iparági ajánlás a „b”. Ami a kiszervezés miatt „b2” lesz.