Musíte rychle reagovat na změny na trhu? Inovujete? Adaptujete novinky? K tomu všemu jistě řešíte i interní vzdělávání, tedy přenos know-how uvnitř firmy. Stává se vám, že neustále dokola "znovuobjevujete kolo"? To stojí jak čas, tak peníze. Pojďte se podívat na jednu z metod podpory přenosu a zachování know-how ve firmě, na systém "gild".
Gilda, popřípadě, v našich končinách spíše cech, je profesní uskupení, kde jedním z jeho cílů je vzdělávání členů. Představme si tedy například gildu kovářů, kteří každý mají svou kovárnu, ale společně dohlížejí na standardy kování, školí učedníky tak, aby bylo komu za čas předat kovárny atd. Nyní, prosím, pomiňme ostatní charakteristiky cechů zvláště v zemích Českých, kde jejich působení často vedlo k technologickému zaostání a potlačování konkurence. Pro naše účely tedy použijeme jen to pozitivní :-)
Nedávno jsme psali o tom, že "mistrovství" a pocit dobře odvedené práce, je jedním z klíčových faktorů pro motivaci a angažovanost zaměstnanců. Je tedy více než vhodné jej podpořit a hlavně správně komunikovat. Lidé, bez ohledu na vzdělání, věk, nebo profesi, si rádi hrají a tak můžeme firemní interní vzdělávání obohatit o prvky gamifikace a učinit jej tak atraktivnější. Využít lze třeba mechanismů známých z RPG her, kde herní postava při plnění úkolů sbírá "zkušenostní body" a postupuje nahoru po žebříčku "úrovní", s čímž se obvykle pojí zpřístupnění dalších lepších schopností atd.
Co tím řešíme?
- nedostatečné sdílení znalostí mezi teamy a odděleními ve firmě
- nízkou míru motivace zaměstnanců k sebevzdělávání a ke vzdělávání vzájemnému
- "znovuobjevování kola" v různých týmech, což vede k časové i finanční ztrátě, neefektivitě a frustraci lidí
- nízkou angažovanost zaměstnanců v práci
Čeho tím dosáhneme?
- lepší komunikace a přenosu know-how mezi zaměstnanci z různých teamů či oddělení ve firmě, což povede ke kontinuálnímu zvyšování znalostí a prohlubování talentů
- vyšší motivace ke vzdělávání v rámci firmy a napříč teamy
- lepší soudržnosti teamů vedoucí k jejich vyšší efektivitě
- vyšší míry angažovanosti zaměstnanců firmy a jejich sounáležitosti s firmou
- rychlejšího onboardingu / zaškolování nováčků
- schopnosti mnohem rychleji reagovat na technologický vývoj a adoptovat nové technologie
Jak na to?
- chceme motivovat intrinsně (tj. nefinanční motivátory)
- chceme využít gamifikaci k podpoře "mistrovství" jako jednoho ze základních prvků motivace
- chceme použít RPG prvky při gamifikaci
- chceme motivovat odměnou za žádoucí vzorce chování (pomoc ostatním v teamu, dodržování best practices, ...)
- chceme také poskytnout zaměstnancům určitou autonomii a možnost samoorganizace, což opět vede k jejich vyšší angažovanosti
Koncept gild
Pojďme si nyní na reálném (byť zjednodušeném) případu ukázat, jak by taková gilda mohla vypadat. Mějme softwarovou firmu, která má čtyři skupiny zaměstnanců dle jejich dovedností: produktové manažery, backend vývojáře, frontend vývojáře a grafiky / UX designéry. Firma je rozsáhlá; teamů, které obsahují kolegy z různých skupin je mnoho a nemají moc příležitostí se potkávat, protože lidé z různých teamů spolu nepracují.
Gildy, jakožto profesní sdružení, tedy reflektují skupiny zaměstnanců a máme zde tak gildu projekťáků, gildu backendistů, gildu frontendistů a gildu grafiků.
Zkušenosti a levely
Zapojením gamifikačních prvků využijeme toho, že lidé jsou hraví a rádi se zlepšují. Můžeme jim tedy nabídnout přehledný systém, který je bude odměňovat za jejich pracovní činnosti. Tato odměna bude primárně ve formě "XP", zkušenostních bodů, které se dále mohou proměňovat v postup po "levelech" a znázorňovat tak stále vyšší míru odbornosti a mistrovství v dané gildě. Za zvláštní příležitosti mohou být udělovány "odznaky", které pak symbolizují určitou specifickou zásluhu, tedy někdo třeba nemusí mít extra vysoký level, ale může být třeba nejlepší opravář chyb v programu.
Některé činnosti, které chceme odměňovat, budou pravděpodobně společné pro různé gildy, většina jich však bude specifických, protože musí reflektovat přirozené charakteristiky práce členů každé gildy.
Návrh několika kritérií, za které lidé sbírají XP (zkušenostní body), může vypadat třeba následovně:
|
Kritérium
|
Proč?
|
Metrika
|
Možnost "odznaku"
|
Pozn.
|
|---|---|---|---|---|
| SPOLEČNÉ | ||||
| Přednáška na "technologické hodince" | Protože chceme podporovat přenos know-how | 1p = 1000XP | "technologická hodinka" je minikonference, kde kolegové přednáší kolegům | |
| Pochvala od kolegy ("žeton") | Protože chceme podporovat kolegialitu | 1pch = 500XP | "žeton" - odměna v "peer-to-peer" systému odměňování. Např. zaměstnanci si mohou každý týden věnovat žeton za to, že si vzájemně pomohli vyřešit nějaký problém atd. | |
| Pochvala od nadřízeného | Protože každý je rád chválen | 1pchN = ?XP | ||
| Zlepšení se mezi TOP3 odpovídače na dotazy na intranetu | Protože chceme podporovat pomáhání si navzájem | 1z = 2000XP | "Guru" | Aplikuje se pouze v momentě kdy někdo "skočí do top3". Pokud tam je, tak se znovu nezapočítává. Jen pokud by "vypadl" a pak se tam vrátil, tak opět ano. |
| Uzavřený task | 1t = 10XP | "Task killer" | XP dostane assignee i reporter (pokud jde o stejnou osobu, jen jednou) | |
| VÝVOJÁŘI (backendisté i frontendisté) | ||||
| Commity | Protože spíše chceme commitovat často a menší kusy | 1c = 1XP | "Ztělesněné odhodlání" | |
| Uzavřená code reviews | Protože chceme aby si kolegové navzájem revidovali kód | 1cr = 5XP | "Revizor" | |
| Odstraněná chyba | Protože nechcem mít tech. dluh a chybový produkt | 1bug = 10XP | "Biolit" | |
| GRAFICI | ||||
| Finalizovaný návrh aplikace | 1FN = 1000XP | Schválený návrh celé aplikace | ||
| Hotová komponenta | 1k = 100XP | Komponenta vč. dokumentace | ||
| PROJEKŤÁCI | ||||
| Projektový kickoff | Protože chceme podporovat komunikaci | 1PK = 250XP | Je třeba kolegům sdělovat smysl práce, jakou přidanou hodnotu pro klienta projekt má atd. | |
| Projektové postmortem | --//-- | 1PM = 250XP | Je třeba se poučit z chyb (jak je příště nedělat) i úspěchů (jak je příště zopakovat). Též je vhodné informovat kolegy o tom, jak je klient s projektem spokojen, zda naplnil očekávání atd. | |
Lze zároveň postupovat ve více "povoláních"? Ano, proč ne. Podpoří se tak ještě více přenos know-how mezi profesemi.Kritéria každopádně musí být ušita daným gildám na míru tak, aby podporovala požadované činnosti a vzorce chování. Při jejich tvorbě je třeba se zamýšlet nad dopady, proto například nechceme odměňovat vývojáře za počet napsaných řádků kódu, což by nevedlo k vyššímu výkonu, ale k zbytečnému a neefektivnímu kódu a tím i nižší kvalitě a udržovatelnosti aplikace. Stejně tak například u pracovníků helpdesku nechceme odměňovat počet odbavených klientů, což by se velmi pravděpodobně projevilo negativně na kvalitě "odbavení", respektive na poklesu spokojenosti uživatelů s helpdeskem.
Máme tedy kritéria, za která zaměstnanci dostávají XP a mohou tak postupovat na vyšší levely, což může vypadat například pro vývojáře následovně:
| Level | XP | Δ XP |
|---|---|---|
| 0 | 0 | 0 |
| 1 | 3000 | 3000 |
| 2 | 7000 | 3500 |
| 3 | 10 500 | 3500 |
| 4 | 14 500 | 4000 |
| 5 | 18 500 | 4000 |
| 6 | 22 500 | 4000 |
| 7 | 26 500 | 4000 |
| 8 | 30 500 | 4000 |
| 9 | 35 500 | 5000 |
| 10 | 40 500 | 5000 |
| 11 | 45 500 | 5000 |
| 12 | 50 500 | 5000 |
| atd. |
Úvaha nad počtem XP nutných k přechodu na vyšší úroveň byla takováto:
Vývojáři (frontend, backend, ...)
Průměrný vývojář zvládne asi toto:
- uzavře za den 2 tasky a 3 bugy
- udělá za den 20 comitů
- udělá za den 20 code reviews
- udělá každé 3 měsíce 1 přednášku na technologické hodince (firemním vzájemném školení)
- každé 2 měsíce dostane pochvalu od kolegy (např. v rámci peer-2-peer bonus systému)
Měsíc má 20 prac. dní (zanedbáváme dovolené a nemoci). Tj. za měsíc je možno nasbírat:
- 20XP + 30XP = 50XP za den
- 20c = 20XP/den
- 20cr = 100XP/den
- tj celkem 170XP za den, tj. 3400XP za měsíc
- tj. celkem 40 800XP / rok + 4x 1000Xp za přednášky + 6x 500XP za pochvaly od kolegy => 47 800XP za rok
Další nápady a principy:
- levelovat by mělo být možno v relativně rozumném čase (měsíčně?) aby se udržela motivace
- levelování by mohlo být progresivně náročnější (tj. postoupit z levelu 1 na dva je snazší, než z 11 na 12), akcentujeme tím i to, že chceme větší zapojení v činnostech za více XP (přednášky atd.)
Udělení odznaku a postup na vyšší level
Tyto události je třeba správně komunikovat a "oslavit je". Není nutné pořádat celofiremní teambuilding kvůli tomu, že vývojář XY postoupil o level a dostal odznak "hlavní vychytávač chyb", ale je určitě dobré jej, v rámci gildy a teamu, kde daný člověk působí, pochválit, případně symbolicky odměnit. Zde máme na mysli spíše třeba čokoládu, poukázku na kurz vaření, voucher na masáž atd., než finanční odměnu. Rozhodně nechceme aby se přirozená touha po zlepšování se a uznání proměnila na honbu za finančním bonusem k výplatě. Často je veřejná pochvala od kolegy lepší, než pár drobných... Pozor ale - ve firmě by již měla panovat jistá kultura a nálada, jinak hrozí, že se z chválení a celého systému gild stane fraška.
Odznaky (a případně i levely) by měly mít nějaké fyzické vyjádření. Opravdový odznáček, malý pohár, nebo zkrátka něco, co si odměněný ponechá a bude mu to připomínat jeho úspěch. A bude to i informace pro ostatní kolegy, která funguje jako "vnadidlo" pro vyšší zapojení.
Meetingy gild
K tomu, aby mohly gildy fungovat, se jejich členové musí setkávat. Zabere to tedy nějaký čas. Ten je ale vykoupen klady uvedenými výše (rychlejší onboarding, zlepšování znalostí týmů, schopnost rychlejší reakce na vývoj technologií,...). Gildovní meetingy by si měly členové gildy organizovat sami a to ať už ad-hoc, nebo třeba pověřením nejzkušenějšího člena. Setkání by také měla mít předem známou agendu a měla by být řízena, aby neztratila efektivitu (informační a řešitelská část, moderace diskusí atd.). Dobrou praktikou je nedělat setkání povinná, ale nabízet taková témata, na která budou ostatní členové chtít přijít (a mohou též kdykoli odejít). Někdy též může gilda hospodařit s nějakým rozpočtem, o jehož využití se na jednáních gildy hlasuje. V každém případě je též vhodná naprostá transparence třeba v tom, že členové gildy ví, kolik stojí například to, že se 10 lidí sejde na hodinu a "nepracuje" (byť samozřejmě "učení se" je produktivní čas)...
Samospráva gild
Gilda může hospodařit s nějakým rozpočtem (část success fee z projektů, pokud tuto praktiku firma podporuje, nebo třeba dobrovolné příspěvky členů atd.). Pak je velmi vhodné zajistit diskusi a demokratickou volbu při využívání těchto zdrojů. Gilda si tak třeba odhlasuje, že člen XY vyjede na drahé školení s tím, že až se vrátí, předá znalosti ostatním členům.
Pokud se gilda rozhodne, že chce mít čelního představitele, tj. "guildmastera", který by pak ovšem měl mít jasně dané odpovědnosti a ručení, je praktické demokraticky jej zvolit na určité omezené období. Pro tyto účely se dá využít třeba jednoduchá tabulka "Job Score Card" (na konkrétním příkladu níže). Nad stejnou tabulkou se pak guildmaster pravidelně setkává se svými kolegy a řeší jejich osobní cíle (vzdělávací, např. naučit se technologii XY, pracovní, např. zlepšit dodržování dev. patterns atd.) na další období. Je tedy jakýmsi liniovým manažerem.
| JSC: Backend guildmaster | Jméno Příjmení | ||
|---|---|---|---|
|
Poslání / účel: Guildmaster backendu je člověk, který zná dobře backend a zároveň ví, kde je potřeba co zlepšit. Sleduje trendy a technologie. Je ale též dobrým duchem gildy Backendu (dále jen BE), je "go-to" osoba v případě, že si někdo neví s něčím rady, stará se o rozvoj znalostí svých kolegů, stará se o to, aby měl BE team vždy to, co právě potřebuje. |
|||
| Klíčové dovednosti / kompetence (úroveň aktuální/požadovaná): | Ručí za: | Odpovídá za: | Hodnoty: |
|
|
|
|
|
MoS (úroveň aktuální/požadovaná):
|
Kvartální osobní cíle (OKRs)
|
||
Časová náročnost vs přínos gild
Jistě vás napadne, zda budou mít zaměstnanci vůbec čas pracovat, budou-li se mít zabývat záležitostmi kolem chodu gildy. Je třeba si uvědomit, že čas strávený cíleným vzděláváním, se bezpochyby projeví i "v businessu", a to např. snížením chybovosti produktu, zrychlením "time to market" atd. Každopádně efektivita a přínos gild, jsou veličiny velmi závislé na úzkém provázání s cíly businessu, vizí a strategií firmy a vzájemné spolupráci, tedy bez toho, aby gilda reagovala na potřeby firmy ("chceme proniknout na trh XY a tudíž je třeba portovat naše produkty na platformu ABCD, což je třeba naučit naše teamy...", nebo např. "máme rychlou a silnou konkurenci, potřebujeme zkrátit "time to market" a tak chceme zavést DevOps praktiky,... ).
Samotná administrace a evidence "zkušeností" pro postup po levelech se dá relativně snadno částečně automatizovat (dokonce již i existují jednoduché pluginy přinášející gamifikační prvky třeba do systému JIRA) a zcela jistě rozložit mezi členy gildy samotné.
Značným přínosem bude jistě i vyšší míra angažovanosti zaměstnanců vycházející jak z atraktivity přítomných gamifikačních prvků, tak z míry autonomie (samosprávy, možnosti o sobě rozhodovat) gildy. I samo prohlubování znalostí a učení se (i učení někoho jiného) je významným prvkem motivace.
Jak začít?
Začít se dá v malém a jednoduše. Nesnažte se hned "zabít všechny mouchy jednou ranou". Zkuste vytvořit malou gildu, zapojte členy do tvorby pravidel, rozdělte odpovědnosti. Důležité je, aby vznik gildy nebyl samoúčelnou akcí, ale opravdu se tím řešily reálné problémy firmy. Proto je třeba i s vyšší kadencí komunikovat dosažená přínosy a zlepšení.
Budete-li mít zájem, s gildami, respektive s přenosem know-how, nebo třeba s onboardingem / adaptačním procesem vašich zaměstnanců rádi pomůžeme. napište nám na gildy@cerebra.cz.
Petr Holodňák
+420 721 660 957 
