Týmy

OKRka a KPIčka – 2 různé galaxie?

Marek Grynhoff

Produkt

V Heureka Group jsme se nedávno rozhodli, že OKR, která už nějaký čas využíváme v produktovo-vývojových týmech, zavedeme do všech týmů, ve všech oddělení, ve všech zemích. Šéf vývoje Lukáš Putna popsal, že jsme na to šli formou mezinárodního online OKR workshopu. Jedna z hlavních výzev byla, jak zavést OKR do týmů, které fungují diametrálně jinak než produkt a vývoj, například v týmu péče o zákazníky.

Když někomu vysvětlujete OKR poprvé, většinou říkáte, že je to o fokusu a měřitelných výsledcích. První reakce lidí bývá: „To známe, KPI nebo SMART cíle už používáme“‎. Když jsme to poprvé slyšeli od svých maďarských kolegů, vlastně nás to na chvíli znejistilo. Ptali jsme se sami sebe, zda má smysl zavádět OKR do týmů, které už teď měří svou práci přes KPI. Zjistili jsme, že pokud chceme zavést OKR do týmů mimo produkt a vývoj, tak naše zkušenosti nebudou stačit. Věděli jsme, že se toho musíme o OKR sami naučit víc.

BAU versus Improvement

Začali jsme tedy zkoumat, jak fungují různé týmy a co je náplní jejich práce. Některé týmy říkaly, že jsou primárně supportní, že dělají to, co přijde od zákazníků, klientů či z jiných týmů jako požadavky. Například v customer care prostě odpovídají na požadavky zákazníků. V BI dělají datové analýzy podle toho, kdo co ve firmě potřebuje zjistit a prozkoumat. Na druhé straně máme týmy, které se primárně starají o byznysové zlepšení. Tak například v produktu/vývoji nám jde o zlepšení našich produktů a služeb, v marketingu zrealizovat kampaň. Obojí má své jasné byznys cíle.

V tomto bodě jsme se zamysleli, zda nebudeme nějak uměle roubovat OKR na tyto dva zcela odlišné způsoby práce. Ale nakonec jsme došli k tomu, že ač by se to na první pohled nemuselo zdát patrné, náplň práce různých týmů se principiálně zas tak neliší.

Za prvé, všechny týmy řeší operativu. Na customer care odpovídají na požadavky zákazníků. V produktu a vývoji řeší dostupnost služeb, různé bugy, incidenty, problémy nebo požadavky ostatních týmů, často se tomu říká maintenance. V rámci naší OKR metodiky jsme to nazvali jako Business as Usual (BAU).

A za druhé, všichni se snaží o zlepšení toho, co dělají. Na customer care chtějí zvyšovat spokojenost zákazníků tím, jak jsou jejich požadavky řešeny. A chtějí to dělat efektivněji. V produktu a vývoji zase chceme zákazníkům poskytovat lepší produkty, chceme zlepšovat business metriky. Začali jsme tomu říkat Improvement.

No a pointa je, že všechny týmy řeší BAU i Improvement zároveň, protože oboje je pro chod firmy nezbytné. Jediné, co se liší, je podíl jedné či druhé složky na náplni práce daného týmu. Na customer care je to dejme tomu 80 % BAU, v produktu a vývoji je to 80 % Improvement. A v BI bude tento podíl někde mezi.

KPI versus OKR

Identifikace pojmů BAU a Improvement nám dost pomohla v dalším přemýšlení o tom, jak zavést OKR do všech týmů. Záhy se ukázalo, že už je to vlastně jednoduché. OKR jsou tu od toho, abychom řídili a vyhodnocovali Improvement. Ale taky potřebujeme mít u každého týmu vydefinované KPI, abychom věděli, jak se týmu daří v BAU. Proto OKR a KPI dohromady ukazují, jak si tým celkově stojí.

Uvědomili jsme si, že u týmů, které byly dosud orientovány na Improvement přes OKR, potřebujeme vydefinovat a začít pravidelně sledovat KPI, aby nezapomínaly na BAU. A u týmů, co jsou orientovány na BAU a mají své KPI, zase potřebujeme zavést OKR, aby vědomě pracovaly i na Improvementu.

Aby KPI a OKR fungovaly, je u každého týmu klíčové, aby vlastnil něco, co dává byznysově smysl. Týmu se nemůže často měnit náplň práce. Tým nemůže fungovat projektově (tedy nemůže pokaždé dělat na úplně něčem jiném, podle toho, kdo mu zadá jaký projekt). Musí se o něco trvale starat, rozvíjet to a odpovídat za to. A na to mít nastavené KPI, které pravidelně vyhodnocuje. A rozvíjet to tak, že si na kvartální bázi nastaví OKR pro Improvements, kterých chce dosáhnout.

Hlavní pointa je, že OKR jsou tady od toho, abychom se na některé KPI zaměřili a dostali jejich hodnoty na nový level. Názorný příklad je třeba konverzní poměr. Jako KPI ho sledujeme a nechceme, aby se zhoršoval. Pokud by ale ke zhoršování došlo, potřebujeme, aby na to někdo odpovědný reagoval – včas a se vším porozuměním situaci a nečekal na zadání. Na druhé straně se můžeme chtít cíleně zaměřit na zlepšení konverzního poměru. A to je případ, kdy je na řadě vytvořit OKR pro daný tým.

Najít a vybrat správné metriky je oříšek

Měli jsme velkou radost, když jsme si přišli na to, jak spolu souvisí OKR a KPI a že se vzájemně doplňují. Ale tím nebylo vyhráno. V průběhu workshopu se ukázalo, že je zcela klíčové pro KPI a OKR (pro Key Results) vybrat ty správné metriky. A hlavně se ukázalo, že není vůbec jednoduché vybrat takové, které reálně ukazují, že se daří to, co chceme. A vybrat metriku, která se dá snadno a průběžně vyhodnocovat.

V rámci našeho učícího se workshopu jsme se na metriky hodně zaměřili. Pro jeho účastníky jsme připravili materiál, jak je správně vybírat a stanovovat Key Results. Hodilo se, když si během workshopu všichni prakticky zkoušeli tvorbu OKR – ⁠ jak Objectives, tak navázaných Key Results pomocí měřitelných metrik. Nebylo to jednoduché a ne každému se to povedlo napoprvé ideálně. Ale všichni ke svým mnohdy prvním pokusům dostali zpětnou vazbu a zároveň měli možnost se inspirovat od ostatních. Rádi bychom naše doporučení, jak pracovat s metrikami, v budoucnu nasdíleli, ale je to na další celý článek, tak příště :)

Pusťme se do toho

Workshop skončil a my jsme se do toho pustili po hlavě a hlavně agilně. Všechny týmy si začaly definovat své OKR i KPI. Napoprvé to asi nebude vše dokonalé, ale poučíme se z našich chyb a v každé další kvartální iteraci se budeme zlepšovat. Tak to funguje se vším, co v Heurece děláme. A naše chyby a ponaučení z nich, to je vlastně téma na další článek :)

Moc si vážíme toho, že OKR mindset podporuje celé vedení skupiny Heureka Group. Vlastně si myslím, že pro zavedení OKR je naprosto klíčové, že ve vedení existuje vůle dát týmům odpovědnost. To znamená, že jim musíte dát také vlastnictví byznysových oblastí. Klíčová je zkrátka důvěra ve schopnosti a odborné znalosti týmů i lidí. Když si pak s lidmi pomocí OKR a KPI sladíte očekávání, odmění se vám tím, že udělají to nejlepší pro dosažení zlepšení a budou hlídat svůj byznys as usual.

Autor článku

V čele produktu stanul Marek v únoru 2018. Na starosti má produktovou strategii a vedení celého týmu. Marek je zastáncem agilních metodik. Proto v Heurece místo neflexibilních roadmap pomohl zavést řízení přes OKR. Místo velkých projektů prosazuje rozvoj produktů krok za krokem s průběžným ověřováním, zda úpravy, které se provádí, mají pro zákazníky smysl a užitek. Marek se produktu věnuje "odjakživa". Nejvíce zkušeností nabral při působení v LMC, které provozuje služby jako Jobs.cz nebo Prace.cz.

Podobné články

10 důvodů proč bejt vývojářem

10 důvodů proč bejt vývojářem

Každej sem tam prožijeme nějakou tu osobnostní krizičku. Sami sebe se ptáme: Co to dělám? A proč…

Kancelářský drážní rozhlas z buildserveru

Kancelářský drážní rozhlas z buildserveru

V libereckém kanclu máme build server pro naše mobilní aplikace (iOS a Android), který má na…

Generace Z: Nová naděje

Generace Z: Nová naděje

Lidé jsou různí. Spousta z nás už se pomalu dostává do toho věku, kdy začíná vyslovovat myšlenky o…

Zaber si svou židli!

<Nejsme asociálové/>

<Témata/>

Zajímá tě naše práce, technologie, tým nebo cokoliv jiného?
Napiš šéfovi vývoje Lukášovi Putnovi.

lukas.putna@heureka.cz