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

  • 232323: Szóval managernek jó lenni, akkor dől a nagy lé, felelősség meg számonkérés sehol. Krém. (2019.10.31. 15:24) Kirúgják-e a menedzsert ha hibázik?
  • 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 fapados megoldás és fapados megoldás között nagy különbség van! (Nem mindegy, hol van benne szálka…)

Az egyik nap hozzám fordultak egy rég elfeledett szoftverrel kapcsolatban. A szoftver valami nagyon egyszerű nyilvántartóprogram web-es alapon, mögötte adatbázis. Klasszikus, pofonegyszerű felépítés. A felhasználó böngészővel megnyitja, böngészik az adatok között, újat felvisz illetve meglévőt módosít. Nincs css, nincs grafika, nincs háttérkép, nincs webform, nincs AJAX, semmi sincs csak egy teljesen béta igénytelen, funkcionális felület.

A fejlesztő annak idején 1 hét alatt dobta össze, plusz volt néhány utólagos igény.

Először meglepődtem, mert azt hittem, ezt a szoftvert már senki sem használja. Annak idején ideiglenesnek készült, meg hogy majd idővel átállunk valami komolyra. Aztán a dolog elmaradt, a felhasználók továbbra is használták a programot. Nem is kicsit: része lett a napi rutinnak (Run-The-Business-nek), állandóan belépnek, kb 15 fős a felhasználó bázis és valaki mindig online.

Most megint hozzá kellett nyúlni.

Először megijedtem, hogy nem fog menni, hiszen a kódot régen írták, a fejlesztő már rég nincs itt. Aztán kiderült, hogy a programban van törzsadat karbantartás is, és amit a felhasználók kérnek, az simán törzsadat hozzáadással megvalósítható. Kb 5 percig tartott.

Belegondoltam: hogyan lehet az, hogy van egy ennyire fapados, teljesen minimalista program, amivel nincs semmi baj, és nincsenek fejlesztési igények? Hogyan lehet az, hogy az évek alatt senki sem feszegette a program lecserélését és újraírását?

Mert ezzel szemben a drága pénzen, 6-12 hónap alatt megírt „professzionális” alkalmazásokra állandó a panasz, rengeteg a fejlesztési igény. És azokat nem lehet fejlesztői óra kifizetési nélkül „átállítani” semmire.

Talán azért van ez így, mert mást értünk „fapados” alatt.

Az informatikusok azt értik fapados alatt, ami műszakilag egyszerű programot kevés munkával összeütnek. A „műszakilag egyszerű” azt jelenti, hogy a programozónak egyszerű, vagy legalábbis kedve van hozzá. Például műszakilag egyszerű dolog képeket felrakni a menüre, vagy egy ketyegő órát implementálni a status bar-ban – a forrás kódja copy-paste módszerrel megszerezhető bárhonnan.

Ezzel szemben műszakilag nem egyszerű azokat az eseteket lefedni egy input mezőben, amit a felhasználó oda be akar ütni (véletlenül, figyelmetlenségből vagy rossz szándékkal).

A felhasználó szemében a fapados azt jelenti, hogy a program az üzleti folyamat fő lépéseit pofonegyszerűen lefedi. Be lehet ütni adatokat, elmenteni azokat, aztán egy táblázatból visszakeresni. Nincs szükség komplex kereső funkcióra, nincs szükség intelligens validálásra vagy begépelés közben felbukkanó kulcsszavakra. Csak egy egyszerű felületre, kevés mezővel, világos információkra, kevés nyomógombra. Ha ezeket tudja a rendszer, az összes többi már kezelhető a rendszeren kívül.

A rendszer nem kér több információt, mint amennyire feltétlenül szükség van, és nincs is benne több funkció, mint amennyi kell.

Amikor ez a program készült, a fejlesztő nagy gondot fordított az igények PONTOS megismerésére. Természetesen amikor elkészült a fejlesztés, a felhasználóknak további ötletei „támadtak” mit lehetne a programba tenni. Szerencsére sikerült kompromisszumot kötni: a felhasználók megértették, hogy nem kérhetnek akármennyit (hiszen a szoftver csak „átmenetileg” lesz), a másik oldalról viszont a fejlesztő belefektette a munkát, hogy az igényeknek megfeleljen – a legegyszerűbb, de leghatásosabb módon.

Ha úgy nézzük, a szoftver teljesen minimalista, viszont a minimális felhasználói igények teljesítésében maximalista. És mivel a legegyszerűbb, legvilágosabb módon ellátja a munkáját, ezért könnyű volt használni, megérteni és dolgozni vele. A felhasználók nem is kértek többet.

És hogy ne legyen probléma, az alkalmazás be lett tolva a standard alkalmazás támogatási folyamatba, rendszeresen mentés készült róla, és a rendszergazdák időnként ellenőrizték, hogy minden rendben megy-e.

Az évek alatt túlélt egy szerver konszolidációt – amikor át kellett telepíteni egy másik szerverre. Minden simán ment, a felhasználók számára észrevétlenül.

Feltehetőleg még néhány évig elketyeg az egyik félreeső szerveren anélkül, hogy bármilyen probléma legyen. És jó lenne, ha a többi esetben is így tudnánk fejleszteni, ennyire kevés erőfeszítéssel ennyire stabil rendszert kialakítva.

A felhasználók a legtöbb esetben megalkudnának egy minimalista felülettel, amennyiben az mindent tud, amire szükségük van. Nincs szükségük tanácsadóra, képekre, animációra

Avagy fapados megoldás és fapados megoldás között nagy különbség van! (Nem mindegy, hol van benne szálka…)

Avagy fapados megoldás és fapados megoldás között nagy különbség van! (Nem mindegy, hol van benne szálka…)

Az egyik nap hozzám fordultak egy rég elfeledett szoftverrel kapcsolatban. A szoftver valami nagyon egyszerű nyilvántartóprogram web-es alapon, mögötte adatbázis. Klasszikus, pofonegyszerű felépítés. A felhasználó böngészővel megnyitja, böngészik az adatok között, újat felvisz illetve meglévőt módosít. Nincs css, nincs grafika, nincs háttérkép, nincs webform, nincs AJAX, semmi sincs csak egy teljesen béta igénytelen, funkcionális felület.

A fejlesztő annak idején 1 hét alatt dobta össze, plusz volt néhány utólagos igény.

Először meglepődtem, mert azt hittem, ezt a szoftvert már senki sem használja. Annak idején ideiglenesnek készült, meg hogy majd idővel átállunk valami komolyra. Aztán a dolog elmaradt, a felhasználók továbbra is használták a programot. Nem is kicsit: része lett a napi rutinnak (Run-The-Business-nek), állandóan belépnek, kb 15 fős a felhasználó bázis és valaki mindig online.

Most megint hozzá kellett nyúlni.

Először megijedtem, hogy nem fog menni, hiszen a kódot régen írták, a fejlesztő már rég nincs itt. Aztán kiderült, hogy a programban van törzsadat karbantartás is, és amit a felhasználók kérnek, az simán törzsadat hozzáadással megvalósítható. Kb 5 percig tartott.

Belegondoltam: hogyan lehet az, hogy van egy ennyire fapados, teljesen minimalista program, amivel nincs semmi baj, és nincsenek fejlesztési igények? Hogyan lehet az, hogy az évek alatt senki sem feszegette a program lecserélését és újraírását?

Mert ezzel szemben a drága pénzen, 6-12 hónap alatt megírt „professzionális” alkalmazásokra állandó a panasz, rengeteg a fejlesztési igény. És azokat nem lehet fejlesztői óra kifizetési nélkül „átállítani” semmire.

Talán azért van ez így, mert mást értünk „fapados” alatt.

Az informatikusok azt értik fapados alatt, ami műszakilag egyszerű programot kevés munkával összeütnek. A „műszakilag egyszerű” azt jelenti, hogy a programozónak egyszerű, vagy legalábbis kedve van hozzá. Például műszakilag egyszerű dolog képeket felrakni a menüre, vagy egy ketyegő órát implementálni a status bar-ban – a forrás kódja copy-paste módszerrel megszerezhető bárhonnan.

Ezzel szemben műszakilag nem egyszerű azokat az eseteket lefedni egy input mezőben, amit a felhasználó oda be akar ütni (véletlenül, figyelmetlenségből vagy rossz szándékkal).

A felhasználó szemében a fapados azt jelenti, hogy a program az üzleti folyamat fő lépéseit pofonegyszerűen lefedi. Be lehet ütni adatokat, elmenteni azokat, aztán egy táblázatból visszakeresni. Nincs szükség komplex kereső funkcióra, nincs szükség intelligens validálásra vagy begépelés közben felbukkanó kulcsszavakra. Csak egy egyszerű felületre, kevés mezővel, világos információkra, kevés nyomógombra. Ha ezeket tudja a rendszer, az összes többi már kezelhető a rendszeren kívül.

A rendszer nem kér több információt, mint amennyire feltétlenül szükség van, és nincs is benne több funkció, mint amennyi kell.

Amikor ez a program készült, a fejlesztő nagy gondot fordított az igények PONTOS megismerésére. Természetesen amikor elkészült a fejlesztés, a felhasználóknak további ötletei „támadtak” mit lehetne a programba tenni. Szerencsére sikerült kompromisszumot kötni: a felhasználók megértették, hogy nem kérhetnek akármennyit (hiszen a szoftver csak „átmenetileg” lesz), a másik oldalról viszont a fejlesztő belefektette a munkát, hogy az igényeknek megfeleljen – a legegyszerűbb, de leghatásosabb módon.

Ha úgy nézzük, a szoftver teljesen minimalista, viszont a minimális felhasználói igények teljesítésében maximalista. És mivel a legegyszerűbb, legvilágosabb módon ellátja a munkáját, ezért könnyű volt használni, megérteni és dolgozni vele. A felhasználók nem is kértek többet.

És hogy ne legyen probléma, az alkalmazás be lett tolva a standard alkalmazás támogatási folyamatba, rendszeresen mentés készült róla, és a rendszergazdák időnként ellenőrizték, hogy minden rendben megy-e.

Az évek alatt túlélt egy szerver konszolidációt – amikor át kellett telepíteni egy másik szerverre. Minden simán ment, a felhasználók számára észrevétlenül.

Feltehetőleg még néhány évig elketyeg az egyik félreeső szerveren anélkül, hogy bármilyen probléma legyen. És jó lenne, ha a többi esetben is így tudnánk fejleszteni, ennyire kevés erőfeszítéssel ennyire stabil rendszert kialakítva.

A felhasználók a legtöbb esetben megalkudnának egy minimalista felülettel, amennyiben az mindent tud, amire szükségük van. Nincs szükségük tanácsadóra, képekre, animációra

Avagy fapados megoldás és fapados megoldás között nagy különbség van! (Nem mindegy, hol van benne szálka…)

Az egyik nap hozzám fordultak egy rég elfeledett szoftverrel kapcsolatban. A szoftver valami nagyon egyszerű nyilvántartóprogram web-es alapon, mögötte adatbázis. Klasszikus, pofonegyszerű felépítés. A felhasználó böngészővel megnyitja, böngészik az adatok között, újat felvisz illetve meglévőt módosít. Nincs css, nincs grafika, nincs háttérkép, nincs webform, nincs AJAX, semmi sincs csak egy teljesen béta igénytelen, funkcionális felület.

A fejlesztő annak idején 1 hét alatt dobta össze, plusz volt néhány utólagos igény.

Először meglepődtem, mert azt hittem, ezt a szoftvert már senki sem használja. Annak idején ideiglenesnek készült, meg hogy majd idővel átállunk valami komolyra. Aztán a dolog elmaradt, a felhasználók továbbra is használták a programot. Nem is kicsit: része lett a napi rutinnak (Run-The-Business-nek), állandóan belépnek, kb 15 fős a felhasználó bázis és valaki mindig online.

Most megint hozzá kellett nyúlni.

Először megijedtem, hogy nem fog menni, hiszen a kódot régen írták, a fejlesztő már rég nincs itt. Aztán kiderült, hogy a programban van törzsadat karbantartás is, és amit a felhasználók kérnek, az simán törzsadat hozzáadással megvalósítható. Kb 5 percig tartott.

Belegondoltam: hogyan lehet az, hogy van egy ennyire fapados, teljesen minimalista program, amivel nincs semmi baj, és nincsenek fejlesztési igények? Hogyan lehet az, hogy az évek alatt senki sem feszegette a program lecserélését és újraírását?

Mert ezzel szemben a drága pénzen, 6-12 hónap alatt megírt „professzionális” alkalmazásokra állandó a panasz, rengeteg a fejlesztési igény. És azokat nem lehet fejlesztői óra kifizetési nélkül „átállítani” semmire.

Talán azért van ez így, mert mást értünk „fapados” alatt.

Az informatikusok azt értik fapados alatt, ami műszakilag egyszerű programot kevés munkával összeütnek. A „műszakilag egyszerű” azt jelenti, hogy a programozónak egyszerű, vagy legalábbis kedve van hozzá. Például műszakilag egyszerű dolog képeket felrakni a menüre, vagy egy ketyegő órát implementálni a status bar-ban – a forrás kódja copy-paste módszerrel megszerezhető bárhonnan.

Ezzel szemben műszakilag nem egyszerű azokat az eseteket lefedni egy input mezőben, amit a felhasználó oda be akar ütni (véletlenül, figyelmetlenségből vagy rossz szándékkal).

A felhasználó szemében a fapados azt jelenti, hogy a program az üzleti folyamat fő lépéseit pofonegyszerűen lefedi. Be lehet ütni adatokat, elmenteni azokat, aztán egy táblázatból visszakeresni. Nincs szükség komplex kereső funkcióra, nincs szükség intelligens validálásra vagy begépelés közben felbukkanó kulcsszavakra. Csak egy egyszerű felületre, kevés mezővel, világos információkra, kevés nyomógombra. Ha ezeket tudja a rendszer, az összes többi már kezelhető a rendszeren kívül.

A rendszer nem kér több információt, mint amennyire feltétlenül szükség van, és nincs is benne több funkció, mint amennyi kell.

Amikor ez a program készült, a fejlesztő nagy gondot fordított az igények PONTOS megismerésére. Természetesen amikor elkészült a fejlesztés, a felhasználóknak további ötletei „támadtak” mit lehetne a programba tenni. Szerencsére sikerült kompromisszumot kötni: a felhasználók megértették, hogy nem kérhetnek akármennyit (hiszen a szoftver csak „átmenetileg” lesz), a másik oldalról viszont a fejlesztő belefektette a munkát, hogy az igényeknek megfeleljen – a legegyszerűbb, de leghatásosabb módon.

Ha úgy nézzük, a szoftver teljesen minimalista, viszont a minimális felhasználói igények teljesítésében maximalista. És mivel a legegyszerűbb, legvilágosabb módon ellátja a munkáját, ezért könnyű volt használni, megérteni és dolgozni vele. A felhasználók nem is kértek többet.

És hogy ne legyen probléma, az alkalmazás be lett tolva a standard alkalmazás támogatási folyamatba, rendszeresen mentés készült róla, és a rendszergazdák időnként ellenőrizték, hogy minden rendben megy-e.

Az évek alatt túlélt egy szerver konszolidációt – amikor át kellett telepíteni egy másik szerverre. Minden simán ment, a felhasználók számára észrevétlenül.

Feltehetőleg még néhány évig elketyeg az egyik félreeső szerveren anélkül, hogy bármilyen probléma legyen. És jó lenne, ha a többi esetben is így tudnánk fejleszteni, ennyire kevés erőfeszítéssel ennyire stabil rendszert kialakítva.

A felhasználók a legtöbb esetben megalkudnának egy minimalista felülettel, amennyiben az mindent tud, amire szükségük van. Nincs szükségük tanácsadóra, képekre, animációra

Olvasói megjegyzésre válaszolva pár gondolat a beosztottakat érintő fontos kérdésekről.

A publikációs tervvel szakítva most egy olvasói megjegyzésre reagálnék.

Viktor írta:

ha esetleg írnál a célok kitűzéséről akár röviden is pár példával, azt megköszönném. Én eddig olyan célokat tűztem ki az adott célt addig tévesztőknek, mint hogy "a becslések pontosságának javítása", "adminisztráció pontosabbá tétele", x technológia megismerése, x alkalmazás fejlesztésében gyakorlat szerzése. Konkrét példával érdekelne, hogy egy programozónak, csoportvezetőnek milyen célokat szokás még kitűzni. Hasonlóan a karrier tervvel kapcsolatban is érdekelnének gyakorlati tapasztalatok, példák, hogy milyen jövőképet lehet felvázolni egy embernek ( főleg, hogy szeretném, hogy alapvetően legtöbbször azt szeretnénk, hogy az adott ember maradjon ott ahol van és csinálja a munkáját ugyanolyan jól, mint eddig ). Hogy lehet feloldani ezt az ellentmondást?

A felvetést nagyon jónak érzem, mert ezeken a szituációkon már én is keresztülmentem.

Csak hogy mindenki értse: célkitűzés alatt azt értem, amikor év elején az egyes beosztottaknak az adott évre személyes célkitűzést (objective) adok, amelynek a teljesülését év végén megmérjük, és ebből adódik egy kiértékelés (appraisal). Az értékelés eredménye közvetlen hatással van a beosztott fizetésére, bónuszára és előmenetelére. Természetesen van egy féléves értékelés is (mid-term review), ahol visszajelzést lehet adni a beosztottnak arról, hogyan áll, és miben kell az év végéig javítania.

Ez egy teljesen bejáratot és szabványos dolog, minden multinál létezik, a részletektől eltekintve ugyanolyan formában.

A célok meghatározása a főnök feladata – és ez bizony nem könnyű. Ha túlságosan részletekbe menő, akkor lehet, hogy valami kimarad. Ha túlságosan általános, akkor sokmindent bele lehet magyarázni. Ha rosszak a célok, akkor rossz lesz a mérés és hibás a visszajelzés, ami károkat okoz: vagy azért, mert egy nem teljesítő kolléga fizetésemelést kap, vagy azért mert egy jól dolgozó kolléga motivációját romboljuk porig egy negatív értékeléssel.

A célok meghatározásának bejáratott módja a SMART módszer:

S – Specific: Egyszerű, jól meghatározott, közérthető, nem félreérthető, világos

M – Measurable: Könnyen mérhető, objektív

A – Attainable: Kapcsolódik a munkához és a beosztotthoz, a beosztottnak lehetősége van jó munkával kihatással lenni ará

R – Relevant: Reális elvárás, amit nem lehetetlen elérni

T - Time-bound: Azaz időben jól behatárolt, de úgy általában véve is behatárolt, hogy mit mérünk mettől meddig

A SMART azt feltételezi, hogy a menedzsernek van egy stratégiája, van egy világos munkafelosztás a csapaton belül, és az egyéni célokat majd a stratégia személyre lebontásával határozzuk meg.

Az IT stratégia készítéséről már írtam.

Év elején – amikor a célokat meg kell határozni – nagyjából a következő zajlik le:

1) Igyekszek minél hamarabb megismerni cégünk magas szintű, általános IT stratégiáját

2) Megvárom, hogy elkészüljön az éves üzleti stratégia

3) A magas szintű IT és az üzleti stratégia alapján meghatározom, hogy az én részlegemnek mi lesz a dolga az adott évben – ez a stratégia

4) A stratégiát lebontom nagyobb feladatokra és projektekre

5) Ezeket felosztom a csapatok és személyek között

6) A feladatok és projektek adják a személyes tervet az adott évre

A célkitűzések vegyesek szoktak lenni, van közte osztály-szintű, van közte általános, de van ami az egyes feladat végrehajtását jelenti, illetve akad ami „személyes kihívás”.

Példa általános célkitűzésre: a munkatárs projektjei követik a cég által előírt folyamatokat és módszertant, határidőre és adott költségkereten belül teljesülnek, a munkavégzés során a support folyamatoknak az esetek 95%-ban megfelel, az audit során 100%-os megfelelés

Példa egyes feladatok végrehajtására: az x meghatározott feladat év végéig lezárul, y projekt sikeres lezárása az év végéig, a helpdesk adott mérőszámai elérik vagy meghaladják az előző évet

Példa személyes kihívásokra: az év végére képes teljes értékűen ellátni egy vezető fejlesztő munkáját, az elfogadott training plan-nek megfelelően részvétel képzési programokban, x technológia megtanulása hogy segítség nélkül képes legyen megoldásokat szállítani, vagy csapatvezetőként feladata a csapattagok felügyelete és támogatása hogy képesek legyenek megoldásokat szállítani

A célokkal kapcsolatban tisztázzuk: az nem szerepel közte, hogy valaki elvégezze a munkáját – hiszen az elvárt és triviális. Egy JAVA programozónak nem adnék olyan célt, hogy JAVA programot kell írnia, és olyat sem, hogy jól. Viszont ha a kód minőség javítása fontos az adott évben, akkor mondhatnék neki olyat hogy a coding convention követése, amelynek mérése a bukott/sikeres code review-k aránya. Vagy valami hasonló.

Csoportvezetőnek, menedzsernek olyan célokat szokás adni, ami az egész csoport teljesítményét tükrözi, nem az egyénét. Ugyanis ő az egész csoportért felelős, nem határolódhat el a többiek teljesítésétől.

A célkitűzés és a karrier terv kéz a kézben jár. Amikor a stratégiát lebontjuk egyéni feladatokra, akkor ebben az egyéni karrier terv ad útmutatást. Ideális esetben mindenki olyan feladatokat (is) kap, ami illeszkedik a fejlődési tervébe. Például ha projekt és support feladatokat kell a csapaton belül szétosztani, akkor a projektet a projektmenedzser-anspiráns kollégák kapják, a csapatvezető-anspiránsok pedig a support jellegűt.

A célkitűzéssel együtt célszerű a karrier tervet is egyeztetni a munkatársakkal. Ez nagyjából a következő elemeket tartalmazza:

- A beosztott saját maga által kitűzött karrier cél vagy kihívás – lehet egész konkrét (pl menedzser szeretne lenni, át szeretne kerülni az értékesítői csapatba) vagy általános (JAVA programozással szeretne foglalkozni)

- Éves képzési terv – milyen területen, milyen ismereteket kellene fejleszteni, ide értve tanfolyamokat

- Némely cégek személyiségjegyeket is vizsgálnak, pl mennyire kreatív vagy mennyire jól kommunikál a munkatárs

A karrier terv teljesülését éppen úgy lehet mérni, mint a kitűzött célokat, és év végén közösen át lehet nézni, mi változott. Ilyenkor a főnök visszajelzése is megjelenik – tanácsok vagy ajánlás formájában.

A fentiek azt jelentik, hogy tanfolyamra és konferenciára nem „spontán” járnak a kollégák, hanem ezeket előre megbeszéljük, és terv szerint végrehajtjuk. Például az egyik munkatársam szeret projektekben dolgozni, számára a projektvezetői munka az „álom”, és képzési oldalon PMI minősítés a cél. Ezért megegyeztünk, hogy elmegy PMI tanfolyamra, amit a cég fizet számára.

Több oka is van, hogy a karrier tervet formalizálni kell. Az egyik az, hogy a munkatársak a legtöbb esetben elfelejtkeznek az önképzésről. A másik pedig az, hogy így a HR, illetve a felső vezetőség is tisztában lesz, kik dolgoznak a cégnél. Kinevezésnél és átszervezésnél kimondottan előnyös.

Milyen jövőképet lehet felvázolni?

Valóban ellentmondás, hogy egyik oldalon a cég azt akarja, hogy mindenki ugyanúgy lássa el ugyanazt a munkát, a másik oldalon pedig azt, hogy mindenki fejlődjön.

Két módon lehet feloldani az ellentmondást: Job rotation és előléptetési rendszer.

A job rotation azt jelenti, hogy adott időnként (mondjuk 3 évente) az embereket áthelyezik egy másik pozícióba. Természetesen olyanba, amit meg tud tanulni és el tud látni. Illetve az ő megüresedett helyére is rotálnak valakit. Így mindig van valami új, valami változatás. Mindig van lehetőség új dolgokat megtanulni, ami hosszú távon a munkatársak előnyére válik.

Az előléptetési rendszer azt biztosítja, hogy időről időre valaki feljebb lép, az ő helyére pedig szintén valaki feljebb lép. Biztosítani kell, hogy ez rendszeresen bekövetkezzen, ne váljanak a szervezeti struktúrák statikussá. Természetesen csak azt léptetik elő, aki az adott pozícióra a legalkalmasabb és az adott pillanatban készen áll rá (lásd karrier terv). Maga a tény, hogy LESZ lehetőség, mindenkit arra sarkal, hogy gyűjtse a piros pontokat és a jó minősítéseket.

Megjegyzés: a kiszervezett csapatom jól teljesített, ezért az ott lévő legjobb embert „előléptettem” – az eddigieknél komolyabb feladatokat kapott, és önként vállaltam, hogy érte egy fokkal többet fizetek. (Nyilván ez összességében csak pici különbség volt, neki viszont nagy)

Mondanom sem kell, mennyire megnövekedett a csapat motivációja. És utána mindenki nekem akart dolgozni.

Olvasói megjegyzésre válaszolva pár gondolat a beosztottakat érintő fontos kérdésekről.

A publikációs tervvel szakítva most egy olvasói megjegyzésre reagálnék.

Viktor írta:

ha esetleg írnál a célok kitűzéséről akár röviden is pár példával, azt megköszönném. Én eddig olyan célokat tűztem ki az adott célt addig tévesztőknek, mint hogy "a becslések pontosságának javítása", "adminisztráció pontosabbá tétele", x technológia megismerése, x alkalmazás fejlesztésében gyakorlat szerzése. Konkrét példával érdekelne, hogy egy programozónak, csoportvezetőnek milyen célokat szokás még kitűzni. Hasonlóan a karrier tervvel kapcsolatban is érdekelnének gyakorlati tapasztalatok, példák, hogy milyen jövőképet lehet felvázolni egy embernek ( főleg, hogy szeretném, hogy alapvetően legtöbbször azt szeretnénk, hogy az adott ember maradjon ott ahol van és csinálja a munkáját ugyanolyan jól, mint eddig ). Hogy lehet feloldani ezt az ellentmondást?

A felvetést nagyon jónak érzem, mert ezeken a szituációkon már én is keresztülmentem.

Csak hogy mindenki értse: célkitűzés alatt azt értem, amikor év elején az egyes beosztottaknak az adott évre személyes célkitűzést (objective) adok, amelynek a teljesülését év végén megmérjük, és ebből adódik egy kiértékelés (appraisal). Az értékelés eredménye közvetlen hatással van a beosztott fizetésére, bónuszára és előmenetelére. Természetesen van egy féléves értékelés is (mid-term review), ahol visszajelzést lehet adni a beosztottnak arról, hogyan áll, és miben kell az év végéig javítania.

Ez egy teljesen bejáratot és szabványos dolog, minden multinál létezik, a részletektől eltekintve ugyanolyan formában.

A célok meghatározása a főnök feladata – és ez bizony nem könnyű. Ha túlságosan részletekbe menő, akkor lehet, hogy valami kimarad. Ha túlságosan általános, akkor sokmindent bele lehet magyarázni. Ha rosszak a célok, akkor rossz lesz a mérés és hibás a visszajelzés, ami károkat okoz: vagy azért, mert egy nem teljesítő kolléga fizetésemelést kap, vagy azért mert egy jól dolgozó kolléga motivációját romboljuk porig egy negatív értékeléssel.

A célok meghatározásának bejáratott módja a SMART módszer:

S – Specific: Egyszerű, jól meghatározott, közérthető, nem félreérthető, világos

M – Measurable: Könnyen mérhető, objektív

A – Attainable: Kapcsolódik a munkához és a beosztotthoz, a beosztottnak lehetősége van jó munkával kihatással lenni ará

R – Relevant: Reális elvárás, amit nem lehetetlen elérni

T - Time-bound: Azaz időben jól behatárolt, de úgy általában véve is behatárolt, hogy mit mérünk mettől meddig

A SMART azt feltételezi, hogy a menedzsernek van egy stratégiája, van egy világos munkafelosztás a csapaton belül, és az egyéni célokat majd a stratégia személyre lebontásával határozzuk meg.

Az IT stratégia készítéséről már írtam.

Év elején – amikor a célokat meg kell határozni – nagyjából a következő zajlik le:

1) Igyekszek minél hamarabb megismerni cégünk magas szintű, általános IT stratégiáját

2) Megvárom, hogy elkészüljön az éves üzleti stratégia

3) A magas szintű IT és az üzleti stratégia alapján meghatározom, hogy az én részlegemnek mi lesz a dolga az adott évben – ez a stratégia

4) A stratégiát lebontom nagyobb feladatokra és projektekre

5) Ezeket felosztom a csapatok és személyek között

6) A feladatok és projektek adják a személyes tervet az adott évre

A célkitűzések vegyesek szoktak lenni, van közte osztály-szintű, van közte általános, de van ami az egyes feladat végrehajtását jelenti, illetve akad ami „személyes kihívás”.

Példa általános célkitűzésre: a munkatárs projektjei követik a cég által előírt folyamatokat és módszertant, határidőre és adott költségkereten belül teljesülnek, a munkavégzés során a support folyamatoknak az esetek 95%-ban megfelel, az audit során 100%-os megfelelés

Példa egyes feladatok végrehajtására: az x meghatározott feladat év végéig lezárul, y projekt sikeres lezárása az év végéig, a helpdesk adott mérőszámai elérik vagy meghaladják az előző évet

Példa személyes kihívásokra: az év végére képes teljes értékűen ellátni egy vezető fejlesztő munkáját, az elfogadott training plan-nek megfelelően részvétel képzési programokban, x technológia megtanulása hogy segítség nélkül képes legyen megoldásokat szállítani, vagy csapatvezetőként feladata a csapattagok felügyelete és támogatása hogy képesek legyenek megoldásokat szállítani

A célokkal kapcsolatban tisztázzuk: az nem szerepel közte, hogy valaki elvégezze a munkáját – hiszen az elvárt és triviális. Egy JAVA programozónak nem adnék olyan célt, hogy JAVA programot kell írnia, és olyat sem, hogy jól. Viszont ha a kód minőség javítása fontos az adott évben, akkor mondhatnék neki olyat hogy a coding convention követése, amelynek mérése a bukott/sikeres code review-k aránya. Vagy valami hasonló.

Csoportvezetőnek, menedzsernek olyan célokat szokás adni, ami az egész csoport teljesítményét tükrözi, nem az egyénét. Ugyanis ő az egész csoportért felelős, nem határolódhat el a többiek teljesítésétől.

A célkitűzés és a karrier terv kéz a kézben jár. Amikor a stratégiát lebontjuk egyéni feladatokra, akkor ebben az egyéni karrier terv ad útmutatást. Ideális esetben mindenki olyan feladatokat (is) kap, ami illeszkedik a fejlődési tervébe. Például ha projekt és support feladatokat kell a csapaton belül szétosztani, akkor a projektet a projektmenedzser-anspiráns kollégák kapják, a csapatvezető-anspiránsok pedig a support jellegűt.

A célkitűzéssel együtt célszerű a karrier tervet is egyeztetni a munkatársakkal. Ez nagyjából a következő elemeket tartalmazza:

- A beosztott saját maga által kitűzött karrier cél vagy kihívás – lehet egész konkrét (pl menedzser szeretne lenni, át szeretne kerülni az értékesítői csapatba) vagy általános (JAVA programozással szeretne foglalkozni)

- Éves képzési terv – milyen területen, milyen ismereteket kellene fejleszteni, ide értve tanfolyamokat

- Némely cégek személyiségjegyeket is vizsgálnak, pl mennyire kreatív vagy mennyire jól kommunikál a munkatárs

A karrier terv teljesülését éppen úgy lehet mérni, mint a kitűzött célokat, és év végén közösen át lehet nézni, mi változott. Ilyenkor a főnök visszajelzése is megjelenik – tanácsok vagy ajánlás formájában.

A fentiek azt jelentik, hogy tanfolyamra és konferenciára nem „spontán” járnak a kollégák, hanem ezeket előre megbeszéljük, és terv szerint végrehajtjuk. Például az egyik munkatársam szeret projektekben dolgozni, számára a projektvezetői munka az „álom”, és képzési oldalon PMI minősítés a cél. Ezért megegyeztünk, hogy elmegy PMI tanfolyamra, amit a cég fizet számára.

Több oka is van, hogy a karrier tervet formalizálni kell. Az egyik az, hogy a munkatársak a legtöbb esetben elfelejtkeznek az önképzésről. A másik pedig az, hogy így a HR, illetve a felső vezetőség is tisztában lesz, kik dolgoznak a cégnél. Kinevezésnél és átszervezésnél kimondottan előnyös.

Milyen jövőképet lehet felvázolni?

Valóban ellentmondás, hogy egyik oldalon a cég azt akarja, hogy mindenki ugyanúgy lássa el ugyanazt a munkát, a másik oldalon pedig azt, hogy mindenki fejlődjön.

Két módon lehet feloldani az ellentmondást: Job rotation és előléptetési rendszer.

A job rotation azt jelenti, hogy adott időnként (mondjuk 3 évente) az embereket áthelyezik egy másik pozícióba. Természetesen olyanba, amit meg tud tanulni és el tud látni. Illetve az ő megüresedett helyére is rotálnak valakit. Így mindig van valami új, valami változatás. Mindig van lehetőség új dolgokat megtanulni, ami hosszú távon a munkatársak előnyére válik.

Az előléptetési rendszer azt biztosítja, hogy időről időre valaki feljebb lép, az ő helyére pedig szintén valaki feljebb lép. Biztosítani kell, hogy ez rendszeresen bekövetkezzen, ne váljanak a szervezeti struktúrák statikussá. Természetesen csak azt léptetik elő, aki az adott pozícióra a legalkalmasabb és az adott pillanatban készen áll rá (lásd karrier terv). Maga a tény, hogy LESZ lehetőség, mindenkit arra sarkal, hogy gyűjtse a piros pontokat és a jó minősítéseket.

Megjegyzés: a kiszervezett csapatom jól teljesített, ezért az ott lévő legjobb embert „előléptettem” – az eddigieknél komolyabb feladatokat kapott, és önként vállaltam, hogy érte egy fokkal többet fizetek. (Nyilván ez összességében csak pici különbség volt, neki viszont nagy)

Mondanom sem kell, mennyire megnövekedett a csapat motivációja. És utána mindenki nekem akart dolgozni.

Olvasói megjegyzésre válaszolva pár gondolat a beosztottakat érintő fontos kérdésekről.

A publikációs tervvel szakítva most egy olvasói megjegyzésre reagálnék.

Viktor írta:

ha esetleg írnál a célok kitűzéséről akár röviden is pár példával, azt megköszönném. Én eddig olyan célokat tűztem ki az adott célt addig tévesztőknek, mint hogy "a becslések pontosságának javítása", "adminisztráció pontosabbá tétele", x technológia megismerése, x alkalmazás fejlesztésében gyakorlat szerzése. Konkrét példával érdekelne, hogy egy programozónak, csoportvezetőnek milyen célokat szokás még kitűzni. Hasonlóan a karrier tervvel kapcsolatban is érdekelnének gyakorlati tapasztalatok, példák, hogy milyen jövőképet lehet felvázolni egy embernek ( főleg, hogy szeretném, hogy alapvetően legtöbbször azt szeretnénk, hogy az adott ember maradjon ott ahol van és csinálja a munkáját ugyanolyan jól, mint eddig ). Hogy lehet feloldani ezt az ellentmondást?

A felvetést nagyon jónak érzem, mert ezeken a szituációkon már én is keresztülmentem.

Csak hogy mindenki értse: célkitűzés alatt azt értem, amikor év elején az egyes beosztottaknak az adott évre személyes célkitűzést (objective) adok, amelynek a teljesülését év végén megmérjük, és ebből adódik egy kiértékelés (appraisal). Az értékelés eredménye közvetlen hatással van a beosztott fizetésére, bónuszára és előmenetelére. Természetesen van egy féléves értékelés is (mid-term review), ahol visszajelzést lehet adni a beosztottnak arról, hogyan áll, és miben kell az év végéig javítania.

Ez egy teljesen bejáratot és szabványos dolog, minden multinál létezik, a részletektől eltekintve ugyanolyan formában.

A célok meghatározása a főnök feladata – és ez bizony nem könnyű. Ha túlságosan részletekbe menő, akkor lehet, hogy valami kimarad. Ha túlságosan általános, akkor sokmindent bele lehet magyarázni. Ha rosszak a célok, akkor rossz lesz a mérés és hibás a visszajelzés, ami károkat okoz: vagy azért, mert egy nem teljesítő kolléga fizetésemelést kap, vagy azért mert egy jól dolgozó kolléga motivációját romboljuk porig egy negatív értékeléssel.

A célok meghatározásának bejáratott módja a SMART módszer:

S – Specific: Egyszerű, jól meghatározott, közérthető, nem félreérthető, világos

M – Measurable: Könnyen mérhető, objektív

A – Attainable: Kapcsolódik a munkához és a beosztotthoz, a beosztottnak lehetősége van jó munkával kihatással lenni ará

R – Relevant: Reális elvárás, amit nem lehetetlen elérni

T - Time-bound: Azaz időben jól behatárolt, de úgy általában véve is behatárolt, hogy mit mérünk mettől meddig

A SMART azt feltételezi, hogy a menedzsernek van egy stratégiája, van egy világos munkafelosztás a csapaton belül, és az egyéni célokat majd a stratégia személyre lebontásával határozzuk meg.

Az IT stratégia készítéséről már írtam.

Év elején – amikor a célokat meg kell határozni – nagyjából a következő zajlik le:

1) Igyekszek minél hamarabb megismerni cégünk magas szintű, általános IT stratégiáját

2) Megvárom, hogy elkészüljön az éves üzleti stratégia

3) A magas szintű IT és az üzleti stratégia alapján meghatározom, hogy az én részlegemnek mi lesz a dolga az adott évben – ez a stratégia

4) A stratégiát lebontom nagyobb feladatokra és projektekre

5) Ezeket felosztom a csapatok és személyek között

6) A feladatok és projektek adják a személyes tervet az adott évre

A célkitűzések vegyesek szoktak lenni, van közte osztály-szintű, van közte általános, de van ami az egyes feladat végrehajtását jelenti, illetve akad ami „személyes kihívás”.

Példa általános célkitűzésre: a munkatárs projektjei követik a cég által előírt folyamatokat és módszertant, határidőre és adott költségkereten belül teljesülnek, a munkavégzés során a support folyamatoknak az esetek 95%-ban megfelel, az audit során 100%-os megfelelés

Példa egyes feladatok végrehajtására: az x meghatározott feladat év végéig lezárul, y projekt sikeres lezárása az év végéig, a helpdesk adott mérőszámai elérik vagy meghaladják az előző évet

Példa személyes kihívásokra: az év végére képes teljes értékűen ellátni egy vezető fejlesztő munkáját, az elfogadott training plan-nek megfelelően részvétel képzési programokban, x technológia megtanulása hogy segítség nélkül képes legyen megoldásokat szállítani, vagy csapatvezetőként feladata a csapattagok felügyelete és támogatása hogy képesek legyenek megoldásokat szállítani

A célokkal kapcsolatban tisztázzuk: az nem szerepel közte, hogy valaki elvégezze a munkáját – hiszen az elvárt és triviális. Egy JAVA programozónak nem adnék olyan célt, hogy JAVA programot kell írnia, és olyat sem, hogy jól. Viszont ha a kód minőség javítása fontos az adott évben, akkor mondhatnék neki olyat hogy a coding convention követése, amelynek mérése a bukott/sikeres code review-k aránya. Vagy valami hasonló.

Csoportvezetőnek, menedzsernek olyan célokat szokás adni, ami az egész csoport teljesítményét tükrözi, nem az egyénét. Ugyanis ő az egész csoportért felelős, nem határolódhat el a többiek teljesítésétől.

A célkitűzés és a karrier terv kéz a kézben jár. Amikor a stratégiát lebontjuk egyéni feladatokra, akkor ebben az egyéni karrier terv ad útmutatást. Ideális esetben mindenki olyan feladatokat (is) kap, ami illeszkedik a fejlődési tervébe. Például ha projekt és support feladatokat kell a csapaton belül szétosztani, akkor a projektet a projektmenedzser-anspiráns kollégák kapják, a csapatvezető-anspiránsok pedig a support jellegűt.

A célkitűzéssel együtt célszerű a karrier tervet is egyeztetni a munkatársakkal. Ez nagyjából a következő elemeket tartalmazza:

- A beosztott saját maga által kitűzött karrier cél vagy kihívás – lehet egész konkrét (pl menedzser szeretne lenni, át szeretne kerülni az értékesítői csapatba) vagy általános (JAVA programozással szeretne foglalkozni)

- Éves képzési terv – milyen területen, milyen ismereteket kellene fejleszteni, ide értve tanfolyamokat

- Némely cégek személyiségjegyeket is vizsgálnak, pl mennyire kreatív vagy mennyire jól kommunikál a munkatárs

A karrier terv teljesülését éppen úgy lehet mérni, mint a kitűzött célokat, és év végén közösen át lehet nézni, mi változott. Ilyenkor a főnök visszajelzése is megjelenik – tanácsok vagy ajánlás formájában.

A fentiek azt jelentik, hogy tanfolyamra és konferenciára nem „spontán” járnak a kollégák, hanem ezeket előre megbeszéljük, és terv szerint végrehajtjuk. Például az egyik munkatársam szeret projektekben dolgozni, számára a projektvezetői munka az „álom”, és képzési oldalon PMI minősítés a cél. Ezért megegyeztünk, hogy elmegy PMI tanfolyamra, amit a cég fizet számára.

Több oka is van, hogy a karrier tervet formalizálni kell. Az egyik az, hogy a munkatársak a legtöbb esetben elfelejtkeznek az önképzésről. A másik pedig az, hogy így a HR, illetve a felső vezetőség is tisztában lesz, kik dolgoznak a cégnél. Kinevezésnél és átszervezésnél kimondottan előnyös.

Milyen jövőképet lehet felvázolni?

Valóban ellentmondás, hogy egyik oldalon a cég azt akarja, hogy mindenki ugyanúgy lássa el ugyanazt a munkát, a másik oldalon pedig azt, hogy mindenki fejlődjön.

Két módon lehet feloldani az ellentmondást: Job rotation és előléptetési rendszer.

A job rotation azt jelenti, hogy adott időnként (mondjuk 3 évente) az embereket áthelyezik egy másik pozícióba. Természetesen olyanba, amit meg tud tanulni és el tud látni. Illetve az ő megüresedett helyére is rotálnak valakit. Így mindig van valami új, valami változatás. Mindig van lehetőség új dolgokat megtanulni, ami hosszú távon a munkatársak előnyére válik.

Az előléptetési rendszer azt biztosítja, hogy időről időre valaki feljebb lép, az ő helyére pedig szintén valaki feljebb lép. Biztosítani kell, hogy ez rendszeresen bekövetkezzen, ne váljanak a szervezeti struktúrák statikussá. Természetesen csak azt léptetik elő, aki az adott pozícióra a legalkalmasabb és az adott pillanatban készen áll rá (lásd karrier terv). Maga a tény, hogy LESZ lehetőség, mindenkit arra sarkal, hogy gyűjtse a piros pontokat és a jó minősítéseket.

Megjegyzés: a kiszervezett csapatom jól teljesített, ezért az ott lévő legjobb embert „előléptettem” – az eddigieknél komolyabb feladatokat kapott, és önként vállaltam, hogy érte egy fokkal többet fizetek. (Nyilván ez összességében csak pici különbség volt, neki viszont nagy)

Mondanom sem kell, mennyire megnövekedett a csapat motivációja. És utána mindenki nekem akart dolgozni.

Olvasói megjegyzésre válaszolva pár gondolat a beosztottakat érintő fontos kérdésekről.

Hogyan lehet a cégnél tartani a kiemelkedően teljesíti beosztottakat?

Hesz Roland küldött linket egy cikkre 5 ways to keep your rockstar employees happy? címmel. A témafelvetés nagyon szép, azonban a tanácsokkal nem értek egyet – lényegi dolgok hiányoznak. Ezért megpróbálom összeszedni azokat a dolgokat, amik tényleg fontosak.

Kezdjük rögtön a legelején: ki szupersztár a csapatban? Mert ez ugyanannyira homályos definíció, mint a „tehetség”. Márpedig a „tehetség” egy gumidefiníció, gyakorlatilag mindenki és senki. Ilyen értelemben véve téves a téma, hiszen nem a szupersztárokat kell motiválni, hanem minden beosztottunkat.

Ha a csapatból egyes beosztottak szupersztárok, az egyben azt is jelenti, hogy a többiek nem azok. A csapatban egyenlőtlenségek vannak, ebből hosszú távon konfliktus lesz, csökken a csapat kohézió és a teljesítmény.

Két megoldást látok, amivel ez kiegyensúlyozható:

- A nélkülözhetetlen embereket ki kell rúgni

- Minden alkalmazottból szupersztárt kell faragni

Miért nehéz a szupersztárok menedzselése?

Mert ők az átlagnál jobban teljesítenek, az átlagnál jobban értenek szakterületükhöz, ezért szükség esetén könnyen találnak munkát máshol. Vagyis bármikor leléphetnek. Ezzel szemben a tehetségtelen és alulképzett munkatárs kevéssé fog váltani, hiszen megbecsüli a munkahelyét.

A szupersztárokat motiválni KELL, mert különben elveszítik érdeklődésüket és máshova mennek dolgozni. Ráadásul pozitívan kell őket motiválni, mert negatív motiváció hatására lelépnek. Tehát csakis egy út létezik a szupersztárok megtartására: a pozitív motiváció. (És itt feldobnám az empowerment kifejezést is)

Mik azok a tényezők, amikkel egy szupersztár (vagy egy átlagos munkatárs) hosszú távpn a cégnél tartható? Felsorolok párat, aztán jön a kifejtés

- Pénz

- Főnök

- Kihívások

- Megbecsülés

- Jó csapat

- Extra juttatások

- Fejlődési lehetőség

Az amatőrök azt gondolják, hogy a munkatársakat a cégnél tartani csak pénzkérdés. Valóban fontos dolog, mert ha piaci érték alatti fizetésért kifacsarjuk a beosztottakat, akkor könnyen elveszíthetjük őket. De ugyanakkor a magas fizetés nem garancia arra, hogy maradnak. Sőt előfordulhat, hogy a szupersztár inkább marad alacsonyabb fizetésért a helyén, ha ott jól érzi magát, hiába is kap jó ajánlatot egy fejvadásztól.

A főnök az, aki miatt az emberek a cégnél maradnak, de a főnök az, aki miatt otthagyják azt. Sokat lehet rajta vitázni, de a jó főnök képes – legalábbis egy darabig – a cég egyéb hátrányait kompenzálni és a tehetségeket megtartani. Ugyanakkor bármilyen jó is a cég, egy idióta főnök képes a legjóindulatúbb embert is elüldözni. A sztárok nem dolgoznak idiótáknak, ahogyan Cservenyák Tamás írja.

Bárki bármit is mond, de egy szupersztárhoz kihívások illenek. Egy unatkozó szuperhős előbb-utóbb feladja, és elmegy kevesebbért egy rosszabb céghez. A kihívásokkal teli munka segít a munkatársnak fejlődni, ugyanakkor lehetőséget nyújt önmegvalósításra és saját korlátaik egyre kijjebb tolásában.

A megbecsülés, a pozitív visszajelzés iránti igény alapvető emberi szükségletek. Még a szupersztár is vágyik egy kis köszönömre. Ellenben ha mindenki csak a hibákat nézi és gyakori a kritika, akkor onnan mindenki menekülni fog.

A jó csapat, a közösség az, ami miatt az emberek nap mint nap bejárnak a munkahelyükre. A pénz is fontos, de a közösség fontosabb. Talán mondanom sem kell, hogy egy rossz közösség, egy kirekesztő csapat nagyon rövid idő alatt képes elkergetni a jól teljesítő szupersztárokat.

Az extra juttatások alatt igazából nem a pénzt értem, hanem apró ajándékokat és szívességeket. Hallottam már olyan programozóról, aki csak azért ment el másik céghez dolgozni pont ugyanannyi fizetésért, mert ott minden nap délben ingyen pizza volt, míg a korábbi munkahelyén csak pénteken. Mentálisan sokat jelent, ha a cég apró dolgokat tesz a beosztottakért. Nem a szívességek és ajándékok értékén van a hangsúly, hanem az érzésen. Mert adott helyzetben ezek az apróságok jelentik a különbségek két munkahely között.

Szóval ezek azok a fő tényezők, amikkel a munkatársakat a cégnél, a csapatban lehet tartani. De pontosan mit is kell egy menedzsernek, vezetőnek napi szinten tennie, hogy ezek érvényesüljenek, és a szupersztár tényleg a cégnél maradjon?

A személyes kapcsolat értéke felbecsülhetetlen. A főnök-beosztott viszonyt ki kell építeni és gondozni. Igen, ki kell építeni, az nem csak úgy „megtörténik” magától és nem jó, ha a beosztottak alkalmazkodó képességére hagyatkozunk. Amikor egy beosztottal beszélgetek, akkor nem csak a munka kerül szóba, hanem a beosztott hogyléte, a család, mi van a feleséggel/gyerekekkel, csinált-e valami érdekeset a hétvégén, milyen filmet látott a moziban vagy hova megy nyaralni. (Indiai beosztottakkal például a Bolywood-i filmekről beszélgetünk vagy a Diwali-ról.)

A lényeg az, hogy meglegyen ez a személyes kapocs, ne csak névtelen droidok passzolgassák egymásnak az emaileket körbe-körbe munkaidő alatt. Individuals and interactions over processes and tools, ahogyan az agilisták mondják. A személyes kapcsolat erősíti a közösséghez tartozást és a főnökkel való viszonyt.

A pozitív vezetői attitűd nagyon fontos, ezt rögtön két részre is bontanám. Az empowerment azt jelenti, hogy a szupersztár lehetőséget kap feladatai kapcsán dönteni, azaz önállóan és szabadon tevékenykedni. Ha a sasokat szabadon engedjük, akkor magasan és hosszan fognak repülni. A szabadság megbecsülést jelent, de lehetőséget ad, hogy a munkatárs megkeresse a neki megfelelő kihívásokat, illetve fejlődési lehetőségeket.

Na de hogyan irányítsunk egy szabadon tevékenykedő, önálló döntést hozó beosztottat? Erre való a coaching: a szupersztárt támogatjuk a munka elvégzésében, nem szabjuk meg számára az utat (csak a célokat), de közben érdeklődünk a tervről és az aktuális helyzetről. Döntések és utasítások helyett kérdéseket teszünk fel, amiket a szupersztár megválaszol – nekünk és saját magának – így tereljük a megfelelő megoldás felé. Mivel szupersztárról van szó, feltehetőleg jól csinálja, tehát a kérdések szerepe csak az, hogy feltárjuk az esetleges kétséges pontokat (ha vannak).

Pozitív vezetői hozzáállás esetén jól át kell gondolni a büntetés és jutalmazás arányát, hogy mikor használjuk a carrot-ot és mikor a stick-et. Az emberek pozitív visszajelzésre vágynak, és amikor lehet akkor dicsérjük meg a beosztottakat. A dicséret legyen nyilvános, a csapat előtt történjen, esetenként járjon apró ajándékkal. Azonban negatív visszajelzésre is szükség van: amikor valaki elrontott vagy hibázott, arról azért beszéljünk – már csak azért is, hogy a hibákból tanulni lehessen és legközelebb ne forduljon elő. Kritizálni lehetőség szerint négyszemközt, privát. És ügyeljünk a megfelelő szóhasználatra. A „buta vagy, ezt is elszúrtad, nem hiszem el hogy ezt nem lehet jól csinálni!” jellegű kifakadás helyett sokkal célravezetőbb az „ezt legközelebb csináljuk másképp”. Nem megsérteni kell az embereket, hanem csak rámutatni a hibákra. A büntetés és jutalmazás helyes aránya fejleszti a csapat, az emberek közötti kapcsolatot, növeli az önbecsülést és a magabiztosságot.

Fontos a stabil háttér, a kiszámítható környezet. Az emberek nem szeretik változást, ragaszkodnak a már megszokott helyekhez, arcokhoz és folyamatokhoz. Azt sem szeretik, ha folyton problémák bukkannak fel, ha a munkafolyamatot váratlan események szakítják félbe. A bizonytalan környezet elijeszti az embereket. A vezető dolga, hogy a stabil hátteret megteremtse és megvédje a csapatot a külvilág hatásaitól. Ehhez azonban a vezetőnek dolgoznia kell, mert a világ már csak olyan, hogy mindig félbe akarja szakítani a munkát.

A jó főnök-beosztott viszonyhoz elengedhetetlen a szoros kommunikáció. Szükség van napi szintű kapcsolatra, hogy a főnöknek rálátása legyen a munkára és szükség esetén segíteni tudjon. Ugyanakkor a beosztottnak is szüksége van, hogy a munkához szükséges információkat megkapja. Ezen felül szükség van informális beszélgetésekre (család, nyaralás, foci, mozi, stb). Heti rendszerességgel legyen privát beszélgetés, ahol a beosztott visszajelzést adhat (mivel haladt jól, mivel volt sok gondja, mi a véleménye, mi bosszantja). Ezen felül szükség van személyes találkozókra – de mindenképpen maradjon meg a beosztott privát köre, hogy ne érezze a nyakán lihegni a főnököt.

Mindezeken felül szükség van éves és fél éves értékelésre, célok kitűzésére és azok mérésére. Ez is kommunikáció, és kiváló eszköz a szupersztár terelgetésének. A célok motivációt adnak, az értékelés pedig növeli a megbecsülést (a szupersztár jól teljesít, tehát az értékelés és visszajelzés nagyrészt pozitív lesz).

Továbbfűzve az éves értékelés gondolatát, szükséges hogy legyen egy hosszú távú stratégia, amelybe illeszkedik az egyén karrier terve. A szupersztár nem csak azért tölti a heteket, hónapokat és éveket a cégnél, hogy ugyanazt a munkát újra és újra ugyanúgy elvégezze, hanem valahova jutni akar, valamit elérni. Ilyen terv csakis akkor tud létezni, ha a vezetőnek van jövőképe, azaz stratégiája. Ezt a stratégiát el kell magyarázni és megosztani a beosztottakkal, hogy ők is tisztában legyenek vele.

A karrier terv a beosztott fejlődése szempontjából fontos, tehát mondjuk menedzser akar lenni és beosztottakat vezetni, vagy éppen ellenkezőleg, valamilyen technológiában akar elmélyülni vagy projektekben részt venni.

A hosszú távú jövőkép lehetőségeket jelent tanulásra, kihívásokra és önmegvalósításra. Hiánya bizonytalanságot szül, a szupersztár esetleg céltalannak érezheti a munkát és máshova megy, jobb perspektíva reményében.

Bizonyára lesznek a Kedves Olvasók között olyanok, akik kétségbe vonják a fentieket, vagy legalábbis kétlik, hogy létezik ilyen. Pedig létezik - én így dolgozok -, de biztos, hogy mindenhol léteznie kell. A menedzser ugyanis időről időre „kénytelen” olyanokat vezetni, akik szupersztárok, jól teljesítenek, feltehetőleg a menedzsernél idősebbek, sokkal tapasztaltabbak és okosabbak. És ha a menedzser ebben a helyzetben rosszul kezeli őket, akkor hosszú távon saját magával szúr ki. Éppen ezért a fentiek nem opcionálisak.

Hogyan lehet a cégnél tartani a kiemelkedően teljesíti beosztottakat?

Hesz Roland küldött linket egy cikkre 5 ways to keep your rockstar employees happy? címmel. A témafelvetés nagyon szép, azonban a tanácsokkal nem értek egyet – lényegi dolgok hiányoznak. Ezért megpróbálom összeszedni azokat a dolgokat, amik tényleg fontosak.

Kezdjük rögtön a legelején: ki szupersztár a csapatban? Mert ez ugyanannyira homályos definíció, mint a „tehetség”. Márpedig a „tehetség” egy gumidefiníció, gyakorlatilag mindenki és senki. Ilyen értelemben véve téves a téma, hiszen nem a szupersztárokat kell motiválni, hanem minden beosztottunkat.

Ha a csapatból egyes beosztottak szupersztárok, az egyben azt is jelenti, hogy a többiek nem azok. A csapatban egyenlőtlenségek vannak, ebből hosszú távon konfliktus lesz, csökken a csapat kohézió és a teljesítmény.

Két megoldást látok, amivel ez kiegyensúlyozható:

- A nélkülözhetetlen embereket ki kell rúgni

- Minden alkalmazottból szupersztárt kell faragni

Miért nehéz a szupersztárok menedzselése?

Mert ők az átlagnál jobban teljesítenek, az átlagnál jobban értenek szakterületükhöz, ezért szükség esetén könnyen találnak munkát máshol. Vagyis bármikor leléphetnek. Ezzel szemben a tehetségtelen és alulképzett munkatárs kevéssé fog váltani, hiszen megbecsüli a munkahelyét.

A szupersztárokat motiválni KELL, mert különben elveszítik érdeklődésüket és máshova mennek dolgozni. Ráadásul pozitívan kell őket motiválni, mert negatív motiváció hatására lelépnek. Tehát csakis egy út létezik a szupersztárok megtartására: a pozitív motiváció. (És itt feldobnám az empowerment kifejezést is)

Mik azok a tényezők, amikkel egy szupersztár (vagy egy átlagos munkatárs) hosszú távpn a cégnél tartható? Felsorolok párat, aztán jön a kifejtés

- Pénz

- Főnök

- Kihívások

- Megbecsülés

- Jó csapat

- Extra juttatások

- Fejlődési lehetőség

Az amatőrök azt gondolják, hogy a munkatársakat a cégnél tartani csak pénzkérdés. Valóban fontos dolog, mert ha piaci érték alatti fizetésért kifacsarjuk a beosztottakat, akkor könnyen elveszíthetjük őket. De ugyanakkor a magas fizetés nem garancia arra, hogy maradnak. Sőt előfordulhat, hogy a szupersztár inkább marad alacsonyabb fizetésért a helyén, ha ott jól érzi magát, hiába is kap jó ajánlatot egy fejvadásztól.

A főnök az, aki miatt az emberek a cégnél maradnak, de a főnök az, aki miatt otthagyják azt. Sokat lehet rajta vitázni, de a jó főnök képes – legalábbis egy darabig – a cég egyéb hátrányait kompenzálni és a tehetségeket megtartani. Ugyanakkor bármilyen jó is a cég, egy idióta főnök képes a legjóindulatúbb embert is elüldözni. A sztárok nem dolgoznak idiótáknak, ahogyan Cservenyák Tamás írja.

Bárki bármit is mond, de egy szupersztárhoz kihívások illenek. Egy unatkozó szuperhős előbb-utóbb feladja, és elmegy kevesebbért egy rosszabb céghez. A kihívásokkal teli munka segít a munkatársnak fejlődni, ugyanakkor lehetőséget nyújt önmegvalósításra és saját korlátaik egyre kijjebb tolásában.

A megbecsülés, a pozitív visszajelzés iránti igény alapvető emberi szükségletek. Még a szupersztár is vágyik egy kis köszönömre. Ellenben ha mindenki csak a hibákat nézi és gyakori a kritika, akkor onnan mindenki menekülni fog.

A jó csapat, a közösség az, ami miatt az emberek nap mint nap bejárnak a munkahelyükre. A pénz is fontos, de a közösség fontosabb. Talán mondanom sem kell, hogy egy rossz közösség, egy kirekesztő csapat nagyon rövid idő alatt képes elkergetni a jól teljesítő szupersztárokat.

Az extra juttatások alatt igazából nem a pénzt értem, hanem apró ajándékokat és szívességeket. Hallottam már olyan programozóról, aki csak azért ment el másik céghez dolgozni pont ugyanannyi fizetésért, mert ott minden nap délben ingyen pizza volt, míg a korábbi munkahelyén csak pénteken. Mentálisan sokat jelent, ha a cég apró dolgokat tesz a beosztottakért. Nem a szívességek és ajándékok értékén van a hangsúly, hanem az érzésen. Mert adott helyzetben ezek az apróságok jelentik a különbségek két munkahely között.

Szóval ezek azok a fő tényezők, amikkel a munkatársakat a cégnél, a csapatban lehet tartani. De pontosan mit is kell egy menedzsernek, vezetőnek napi szinten tennie, hogy ezek érvényesüljenek, és a szupersztár tényleg a cégnél maradjon?

A személyes kapcsolat értéke felbecsülhetetlen. A főnök-beosztott viszonyt ki kell építeni és gondozni. Igen, ki kell építeni, az nem csak úgy „megtörténik” magától és nem jó, ha a beosztottak alkalmazkodó képességére hagyatkozunk. Amikor egy beosztottal beszélgetek, akkor nem csak a munka kerül szóba, hanem a beosztott hogyléte, a család, mi van a feleséggel/gyerekekkel, csinált-e valami érdekeset a hétvégén, milyen filmet látott a moziban vagy hova megy nyaralni. (Indiai beosztottakkal például a Bolywood-i filmekről beszélgetünk vagy a Diwali-ról.)

A lényeg az, hogy meglegyen ez a személyes kapocs, ne csak névtelen droidok passzolgassák egymásnak az emaileket körbe-körbe munkaidő alatt. Individuals and interactions over processes and tools, ahogyan az agilisták mondják. A személyes kapcsolat erősíti a közösséghez tartozást és a főnökkel való viszonyt.

A pozitív vezetői attitűd nagyon fontos, ezt rögtön két részre is bontanám. Az empowerment azt jelenti, hogy a szupersztár lehetőséget kap feladatai kapcsán dönteni, azaz önállóan és szabadon tevékenykedni. Ha a sasokat szabadon engedjük, akkor magasan és hosszan fognak repülni. A szabadság megbecsülést jelent, de lehetőséget ad, hogy a munkatárs megkeresse a neki megfelelő kihívásokat, illetve fejlődési lehetőségeket.

Na de hogyan irányítsunk egy szabadon tevékenykedő, önálló döntést hozó beosztottat? Erre való a coaching: a szupersztárt támogatjuk a munka elvégzésében, nem szabjuk meg számára az utat (csak a célokat), de közben érdeklődünk a tervről és az aktuális helyzetről. Döntések és utasítások helyett kérdéseket teszünk fel, amiket a szupersztár megválaszol – nekünk és saját magának – így tereljük a megfelelő megoldás felé. Mivel szupersztárról van szó, feltehetőleg jól csinálja, tehát a kérdések szerepe csak az, hogy feltárjuk az esetleges kétséges pontokat (ha vannak).

Pozitív vezetői hozzáállás esetén jól át kell gondolni a büntetés és jutalmazás arányát, hogy mikor használjuk a carrot-ot és mikor a stick-et. Az emberek pozitív visszajelzésre vágynak, és amikor lehet akkor dicsérjük meg a beosztottakat. A dicséret legyen nyilvános, a csapat előtt történjen, esetenként járjon apró ajándékkal. Azonban negatív visszajelzésre is szükség van: amikor valaki elrontott vagy hibázott, arról azért beszéljünk – már csak azért is, hogy a hibákból tanulni lehessen és legközelebb ne forduljon elő. Kritizálni lehetőség szerint négyszemközt, privát. És ügyeljünk a megfelelő szóhasználatra. A „buta vagy, ezt is elszúrtad, nem hiszem el hogy ezt nem lehet jól csinálni!” jellegű kifakadás helyett sokkal célravezetőbb az „ezt legközelebb csináljuk másképp”. Nem megsérteni kell az embereket, hanem csak rámutatni a hibákra. A büntetés és jutalmazás helyes aránya fejleszti a csapat, az emberek közötti kapcsolatot, növeli az önbecsülést és a magabiztosságot.

Fontos a stabil háttér, a kiszámítható környezet. Az emberek nem szeretik változást, ragaszkodnak a már megszokott helyekhez, arcokhoz és folyamatokhoz. Azt sem szeretik, ha folyton problémák bukkannak fel, ha a munkafolyamatot váratlan események szakítják félbe. A bizonytalan környezet elijeszti az embereket. A vezető dolga, hogy a stabil hátteret megteremtse és megvédje a csapatot a külvilág hatásaitól. Ehhez azonban a vezetőnek dolgoznia kell, mert a világ már csak olyan, hogy mindig félbe akarja szakítani a munkát.

A jó főnök-beosztott viszonyhoz elengedhetetlen a szoros kommunikáció. Szükség van napi szintű kapcsolatra, hogy a főnöknek rálátása legyen a munkára és szükség esetén segíteni tudjon. Ugyanakkor a beosztottnak is szüksége van, hogy a munkához szükséges információkat megkapja. Ezen felül szükség van informális beszélgetésekre (család, nyaralás, foci, mozi, stb). Heti rendszerességgel legyen privát beszélgetés, ahol a beosztott visszajelzést adhat (mivel haladt jól, mivel volt sok gondja, mi a véleménye, mi bosszantja). Ezen felül szükség van személyes találkozókra – de mindenképpen maradjon meg a beosztott privát köre, hogy ne érezze a nyakán lihegni a főnököt.

Mindezeken felül szükség van éves és fél éves értékelésre, célok kitűzésére és azok mérésére. Ez is kommunikáció, és kiváló eszköz a szupersztár terelgetésének. A célok motivációt adnak, az értékelés pedig növeli a megbecsülést (a szupersztár jól teljesít, tehát az értékelés és visszajelzés nagyrészt pozitív lesz).

Továbbfűzve az éves értékelés gondolatát, szükséges hogy legyen egy hosszú távú stratégia, amelybe illeszkedik az egyén karrier terve. A szupersztár nem csak azért tölti a heteket, hónapokat és éveket a cégnél, hogy ugyanazt a munkát újra és újra ugyanúgy elvégezze, hanem valahova jutni akar, valamit elérni. Ilyen terv csakis akkor tud létezni, ha a vezetőnek van jövőképe, azaz stratégiája. Ezt a stratégiát el kell magyarázni és megosztani a beosztottakkal, hogy ők is tisztában legyenek vele.

A karrier terv a beosztott fejlődése szempontjából fontos, tehát mondjuk menedzser akar lenni és beosztottakat vezetni, vagy éppen ellenkezőleg, valamilyen technológiában akar elmélyülni vagy projektekben részt venni.

A hosszú távú jövőkép lehetőségeket jelent tanulásra, kihívásokra és önmegvalósításra. Hiánya bizonytalanságot szül, a szupersztár esetleg céltalannak érezheti a munkát és máshova megy, jobb perspektíva reményében.

Bizonyára lesznek a Kedves Olvasók között olyanok, akik kétségbe vonják a fentieket, vagy legalábbis kétlik, hogy létezik ilyen. Pedig létezik - én így dolgozok -, de biztos, hogy mindenhol léteznie kell. A menedzser ugyanis időről időre „kénytelen” olyanokat vezetni, akik szupersztárok, jól teljesítenek, feltehetőleg a menedzsernél idősebbek, sokkal tapasztaltabbak és okosabbak. És ha a menedzser ebben a helyzetben rosszul kezeli őket, akkor hosszú távon saját magával szúr ki. Éppen ezért a fentiek nem opcionálisak.

süti beállítások módosítása