V předchozích článcích jsem psal o tom, proč je hodinová sazba v roce 2026 mrtvá a proč vám dodavatel IT systému neřekne pravdu. Oba texty se dotýkaly stejného problému: špatně nastavené motivace vedou k špatným výsledkům.
Dnes chci jít hlouběji. Ne do teorie, ale do praxe - jak vypadá firma, která odměňuje čas místo výsledků. A co s tím jde dělat.
Anatomie rozpadajícího se týmu
V každé firmě, kde jsem pracoval nebo konzultoval, jsem viděl stejný vzorec. Dva typy lidí, stejná hodinová sazba.
Tahouni
Jsou efektivní. Řeší problémy rychle. Berou na sebe další práci, protože jim to jde. Za rok jsou zahlcení, za dva vyhořelí. Odměna? Stejná jako u kolegů, kteří dělají polovinu.
Přežívači
Naučili se systém. Úkol, který jde udělat za hodinu, roztáhnou na čtyři. Vypadají zaneprázdněně. Nikdo nekontroluje, jestli ta zaneprázdněnost přináší hodnotu. Odměna? Stejná jako u tahounů - a navíc bez stresu.
Hodinová sazba tenhle vzorec nejen umožňuje, ale přímo podporuje. Čím déle na úkolu pracuji, tím více hodin odpracuji s menší námahou. Čím efektivnější jsem, tím víc práce dostanu za stejné peníze.
Jediná motivace, kterou systém nabízí? Zvyšování hodinové mzdy. Ale to problém neřeší - jen zvyšuje náklady na stejný pattern.
Proč KPIs situaci nezachránily
Firmy problém vidí. Reakce je logická: zavedeme metriky. Budeme měřit výkon. KPIs. Problém? Většina KPIs měří aktivitu, ne hodnotu.
Plošné cíle pro všechny
Stejný target pro každého člověka v týmu. Prodejci honí počet callů. Developeři lines of code. Support počet uzavřených ticketů. Výsledek: kvantita zabíjí kvalitu. Všichni gamují systém. Skutečný byznys trpí.
Zkuste si to představit konkrétně:
IT support s cílem „X ticketů měsíčně" nutí lidi rychle odbývat zákazníky místo řešit problémy do hloubky. Pomalý kolega, který se každému věnuje hodinu, vypadá jako hvězda. Rychlý expert, který vyřeší problém za pět minut, je „málo produktivní".
Sales s cílem „100 callů týdně" vede ke spamování leadů. Žádné budování vztahů. Revenue stagnuje, ale dashboard září.
Vývoj s cílem na počet deployů vede k fragmentaci - místo jednoho promyšleného releasu deset malých, které nikdo nepotřeboval.
Meziroční navyšování
Každý rok +10-20 % na stejné metrice. Bez ohledu na trh nebo realitu. První rok to funguje - je kam růst. Druhý rok je to těžší. Třetí rok lidé buď začnou podvádět, nebo odejdou.
Goodhart's Law v praxi: „Když se metrika stane cílem, přestane být užitečnou metrikou."
Ne všechny KPIs jsou špatné
Abych byl férový: existují firmy, které metriky používají dobře. Rozdíl je v tom, co měří.
- Activity-based KPIs(počet callů, ticketů, hodin) měří činnost. Snadno se gamují, protože aktivita ≠ hodnota.
- Outcome-based KPIs(customer retention, NPS, revenue per employee) měří výsledek. Hůře se gamují, protože jsou navázané na reálný byznys.
Problém je, že většina firem sahá po activity-based metrikách, protože se snáze měří a reportují. „Tým uzavřel 500 ticketů" zní konkrétněji než „zákazníci jsou spokojenější". Jenže to první číslo nic neříká o tom, jestli firma roste.
Outcome-based KPIs fungují - ale vyžadují delší časový horizont, komplexnější měření a ochotu přiznat, že ne všechno se dá vyjádřit jedním číslem v dashboardu.
Sankce za nesplnění
Co se stane, když někdo nesplní KPI? Snížení bonusu. Horší hodnocení. Tlak. Výsledek? Lidé optimalizují na splnění čísla, ne na vytvoření hodnoty. A ti nejlepší - kteří by nesplnění viděli jako systémový problém, ne osobní selhání - odcházejí jinam.
Křížové KPIs: Komplikovanější, ne lepší
Reakce na gamování je obvykle další vrstva metrik. Měříme efektivitu i kvalitu. Tickety se vrací na přepracování? Přidáme metriku na first-time resolution. Teoreticky to dává smysl. Prakticky to vytváří další problémy:
- Komplexita: Místo jednoho čísla sledujete pět. Nikdo neví, co je vlastně priorita.
- Vymahatelnost: V IT segmentu je často nemožné objektivně posoudit kvalitu. Co je „správně vyřešený" ticket? Záleží na kontextu.
- Čísla v dashboardu: Metriky existují, ale nikdo podle nich reálně nejedná. Jsou to jen čísla, která jednou měsíčně někdo otevře.
A hlavně: stále měříte aktivitu, ne hodnotu. Jen složitějším způsobem.
Motivace, která zmizela
Nejhorší efekt špatně nastavených metrik není v číslech. Je v lidech. Pracovní nasazení se mění v honění targetů. Kreativita ustupuje snaze „splnit". Před vyhodnocením dochází k umělému navyšování - všichni vědí, že poslední týden v měsíci jsou čísla nafouklá. A co intrinsická motivace? Chuť dělat práci dobře, protože to dává smysl? Zmizí. Protože systém ji nepotřebuje. Systém chce čísla.
Jak jsem to vyřešil: Poměrové odměňování
V Procederu pracujeme s kontraktory. Model hodinové sazby jsem od začátku odmítl - z důvodů popsaných výše. Místo toho jsem navrhl něco jiného: Developer dostává poměrovou částku ze zakázky.
Jak to funguje
- Zakázka má hodnotu X korun.
- Z této hodnoty se odečte marže firmy.
- Zbytek se rozdělí mezi lidi, kteří se na zakázce podíleli, podle jejich zapojení.
Je v podstatě jedno, jestli developer práci odvede za den nebo za deset. Samozřejmě existuje časový rámec - kapacitní plánování, termíny, projektové milníky. Ale odměna není navázaná na počet hodin.
Proč to funguje
- Odměňujeme efektivitu: Šikovný developer, který úkol vyřeší rychle, si vydělá víc za jednotku času. Má motivaci být efektivní.
- Zakázka se nemůže stát ztrátovou: Náklady na práci jsou procento z hodnoty zakázky, ne fixní částka podle hodin.
- Developer má zájem identifikovat vícepráce: Pokud se zadání rozšiřuje, není motivace to tiše strpět. Naopak - čím jasněji definovaný scope, tím lépe pro všechny.
- Přirozeně se projeví kvalita: Pomalý nebo nekvalitní developer si vydělá méně. Nemá smysl pokračovat ve spolupráci, když výsledky neodpovídají.
- Odpovědnost za chyby: Pokud se po dodání objeví prokazatelné bugy, developer je opravuje na své náklady. Není to trest - je to logický důsledek toho, že přebírá odpovědnost za svou práci. Bugovost je adresná. Víme, kdo co dělal, a ten člověk za to ručí.
Kapacitní plánování
„Ale jak víš, že to developer zvládne včas?"
Kapacitní plánování funguje na úrovni projektu, ne jednotlivce. Developer dostane scope, deadline a podíl. Jak si práci rozloží, je na něm. Pokud má problém stihnout termín, komunikuje to - protože má motivaci, aby zakázka proběhla čistě.
Když věci nejdou podle plánu
„A co když developer onemocní? Klient změní scope? Technologie selže?"
Férová otázka. V hodinovém modelu je odpověď jednoduchá: platíš za čas, ať se děje cokoliv. V poměrovém modelu musíte mít pravidla:
Nemoc / výpadek developera: Zakázku přebírá někdo jiný, podíl se přerozdělí podle reálného zapojení. Developer, který odpadl, dostane poměr za to, co stihl.
Změna scope klientem: Vícepráce = nová kalkulace. Původní scope má svůj podíl, rozšíření má svůj. Developer není rukojmím klientových změn.
Technické problémy mimo kontrolu developera: API třetí strany přestane fungovat, klient dodá špatná data. Tohle je riziko firmy, ne developera. Řešíme to individuálně, ale princip je jasný: developer nenese riziko za věci, které nemohl ovlivnit.
Klíčové je, že pravidla existují předem. Ne „uvidíme, až se to stane". Transparentnost funguje jen tehdy, když všichni vědí, na čem jsou.
Aplikovatelnost
Model jsem navrhl pro kontraktory, ale princip je aplikovatelný i pro kmenové zaměstnance. Místo fixního platu + bonusu za KPIs:
- Základní plat (nižší než obvykle)
- Poměrová složka z hodnoty dodaných projektů
Tím se posouvá vztah mezi zaměstnavatelem a zaměstnancem. Není to „platím ti za čas" ale „podílíme se na výsledku".
Proč to funguje: Alignment zájmů
Největší přínos poměrového modelu není v samotném procentu ze zakázky. Je v tom, že všichni táhnou stejným směrem.
Developer chce, aby zakázka proběhla čistě - protože na tom závisí jeho výdělek. Chce identifikovat vícepráce - protože tím chrání svůj scope. Chce odvést kvalitní práci - protože bugy opravuje na své náklady. Chce komunikovat problémy včas - protože pozdní eskalace ho stojí čas i peníze.
V hodinovém modelu jsou zájmy v konfliktu. Firma chce rychle a levně. Developer chce hodně hodin. Výsledek je přetahovaná, kde nikdo nevyhrává.
V poměrovém modelu chceme všichni totéž: úspěšně dokončenou zakázku. To není ideologie - je to matematika.
Není to pro každého
Poměrové odměňování není univerzální řešení. Vyžaduje:
- Od firmy: Jasně definované zakázky s pevnou cenou. Transparentní kalkulace, kde lidé vidí, jak se jejich odměna počítá. Důvěru v lidi - kontrolujete výstupy, ne hodiny.
- Od lidí: Ochotu nést odpovědnost za výsledek. Proaktivní komunikaci problémů. A hlavně - ochotu nést riziko, že pomalá práce = menší výdělek.
Pro rutinní pozice se stabilním outputem může být klasický plat jednodušší. Ale pro expertní práci - vývoj, konzultace, automatizaci - je hodinová sazba absurdní. Trestá talent a odměňuje pomalost.
Závěr
Hodinová sazba a plošné KPIs mají společný problém: měří aktivitu místo hodnoty. Výsledkem jsou firmy, kde tahouni vyhoří, přežívači prosperují a nikdo neví, proč se nic nehýbe, když všechna čísla vypadají dobře. Řešení není další vrstva metrik. Je to fundamentální změna: odměňovat výsledky, ne čas.