Triády – seznamte se!

Potřebovali jste někdy rychle propojit velké množství lidí? Například na konferenci? Nebo jste potřebovali prohloubit vzájemné poznání se v týmu? To vás určitě bude zajímat následující samo-facilitační nástroj – Triády.

V roce 2016 jsme jsme organizovali setkání sítě lidí se společnými hodnotami, ale kteří se uvidí poprvé. Jak rychle překlenout takový ten podivný moment, když se potká množství neznámých lidí, ještě než se prolomí ledy? Po skvělém brainstomingu jsme dali dohromady koncept, který už jen stačilo doklepnout – Triády. Triáda je nástroj, který samofacilitačně udělá během 60 minut ze 3 cizích lidí známé, někdy dokonce i přátele.

Proč právě 3 lidé?

Protože trojice je velmi zvláštní uskupení. Dvojice je pro tvoření sítě malá a při seznamování nebo tvoření rychle vyčerpá svůj potenciál. Skupina o 4 a více lidech ztrácí intimitu a sdílení, zejména osobních věcí, jde jen po povrchu. Trojice je právě tak akorát. Je pořád dostatečně malá, aby byla pro sdílení bezpečná a současně skýtá zajímavou dynamiku. Když spolu dva mluví, třetí může pozorovat a přinést nezúčastněné vstupy, pozorování a rozdmýchat tak další diskuzi. I podle kmenového vůdcovství (Tribal leadership) je trojice základním stavebním kamenem silné kmenové kultury 4 – “MY”, kde lidem na sobě záleží a záleží jim na prosperitě celého kmene.

Jak takový nástroj vypadá?

Aby byl navíc škálovatelný a mohli jste jej použít například ve skupině 100 lidí?

Každý dostane tužku a svůj triádový papír, kde najde instrukce a volné políčka, kam si během rozhovoru píše poznámky, které použije později. Vysvětlení použití nástroje můžete vidět na následujícím videu:

PDF ke stažení zde.

Jak vidíte, nástroj sám provede trojici lidí seznamováním. Seznamování ale nemusí být vždy jediný cíl. Triády lze snadno přizpůsobit pro jakýkoliv jiný kontext. Namátkou se podívejme na několik dalších použití, která jsme poslední dobou realizovali na míru našim zákazníkům.

Modifikace: Rozbití ledů na konferenci

Na konferenci BusinessCon používáme tradičně triády hned ze startu na rozbití ledů mezi účastníky. Je to konference podnikatelů, proto jsme se v triádách namísto osobních hodnot zaměřili na to, jak si mohou podnikatelé navzájem pomoci, případně jaký nový business mohou společně nastartovat.

PDF ke stažení zde.

Modifikace: Příprava vstupů pro následný workshop

Před časem jsme facilitovali workshop pro cca 130 lídrů z CZ/SK Microsoftu a namísto hodnot (klasické triády), nebo vzájemné pomoci (BusinessCon triády), jsme se zaměřili na přípravu konkrétního tématu k řešení pro následný workshop.

PDF ke stažení zde.

Modifikace: Rychlý teaming v programu ReBeLeader

Od roku 2017 realizujeme společně s kolegy z RedButton leadershipový program ReBeLeader pro slovenskou Tatrabanku. Tam využíváme první den triády a další nástroje k rychlému teamingu, kdy během jednoho odpoledne vzniknou z neznámých lidí funkční týmy založené na vzájemném poznání a důvěře.

PDF ke stažení zde.

Běžte, šiřte, upravujte

Jak vidíte použití je téměř neomezené. A jak použijete nebo si upravíte triády vy? Nezapomeňte nám dát vědět na napiste.nam@rainfellows.cz.

Agile ve strojírenství

Agilita je dnes populární v mnoha průmyslových odvětvích. V IT, kde vznikla, je už de facto standardem. V mnoha bankách běží více či méně úspěšné Agilní transformace. Pojďme se však spolu podívat na příběh z Agilně netypického oboru strojírenství, konkrétně do společnosti REHAU.

Stručně o REHAU

Společnost Rehau byla založena v Německu a od roku 1948 působí v oblasti nábytku, průmyslu, stavebnictví a automobilového průmyslu. Nyní jsme globální společností s více než 20 000 zaměstnanci. Naše první spolupráce v automobilovém odvětví byla se společností VW Beetle, která je dodnes naším velkým zákazníkem. Krom toho jsme také dodavateli hlavních prémiových značek jako je Porsche, Audi, BMW nebo Daimler, přičemž dodáváme převážně venkovní díly s nátěrem na polymerní bázi. Dodáváme také nárazníky a další venkovní díly za pomocí logistických procesů Just In Time (JIT) a Just In Sequence (JIS) z 16 různých továren v Jihoafrické republice (RSA) napříč celou Evropou a USA. V České republice máme své vývojové středisko pro automobilový průmysl v Čestlicích a dále tři výrobní závody v Moravské Třebové, Jevíčku a Mladé Boleslavi.

Počátek agilní transformace

Skupina REHAU začala s Agilní transformací v roce 2018, aby se stala flexibilnější, rychlejší a získala větší důvěru mezi zákazníky a jednotlivými týmy REHAU. Lukáš Kalal (vedoucí Engineering Design & Services CZ/IN v Praze – Čestlicích) se zúčastnil Agilního školení v USA a to v něm probudilo touhu začlenit některé Agilní principy do každodenní práce v našem závodě. Po tomto inspirativním školení jsme hledali partnera, který by nás mohl provést problematikou agility. Dostali jsme jasné doporučení, že firma RainFellows by měla být naší první volbou.

První krok

Jakákoliv organizační změna vyžaduje, aby lidé změnili své návyky – ty vytvářejí skutečné procesy společnosti. Zní to jednoduše, ale ve skutečnosti musíte čelit mnoha různým vrstvám odporu. Přestože jsme si většinou dobře vědomi různých problémů, máme tendenci vymýšlet si nespočet důvodů, proč se musíme držet našich starých dobrých zvyků a způsobů práce. A že všechno ostatní může být pro cíl změny nebezpečné. Je to naše vnitřní přesvědčení, které vytváří silný strach ze změn, a tím silný odpor, který se promítá do naší řeči například následovně:

  • „Nové věci nevydrží a mohou být nebezpečné!“
  • „Tohle u nás nikdy nebude fungovat, protože naše práce je specifická! (Nejsme IT, jsme velká společnost, naši zákazníci jsou zkostnatělí, máme distribuované týmy atd.)“ 
  • „To jsme zkusili již v minulosti a nefungovalo to… Pojmenujte jednu společnost, kde Agile funguje!“

Takové reakce slyšíme často.

Něco změnit stojí energii a přináší menší stabilitu. Lidé se neznámých věcí a změn bojí. Často však zapomínáme, že náš úspěch je založen na naší schopnosti přizpůsobit se.

Změnit jakékoliv návyky či procesy vyžaduje nejprve uvědomit si jejich negativní dopad a postupně lidi nechat, aby změnili svá základní přesvědčení. To v důsledku minimalizuje úroveň strachu a odporu.

Abychom vytvořili vhodné prostředí pro takovéto uvažování a získali agilní zkušenosti z první ruky, uspořádali jsme celodenní workshop. Zahrnoval půldenní (!) simulování tradičního projektu a vznik Agile. Protože to byla jen „simulace“ a sami účastníci dokonce do jisté míry vymýšleli agilní způsoby práce (od té chvíle se stali jejich vlastníky!), všichni se nakonec cítili uvolněnější a otevřenější změnám. Samotný workshop umožnil účastníkům uvědomit si současné návyky (tzn. procesy), jejich negativní dopad, potřebu změny a nechal je bezpečně změnit svá základní přesvědčení (např. „je to nová věc a je to nebezpečné“). Jakmile jsme tohoto dosáhli, mohla nastat skutečná změna v naší organizaci.

Výhody úvodního workshopu:

  • Účastníci získali praktické agilní zkušenosti v bezpečném prostředí, které jim umožnilo poučit se ze svých chyb;
  • Odpovědi na důležité otázky od důvěryhodných odborníků a znalosti, jak jiné společnosti implementovaly Agile;
  • Postoj odporu se změnil z „nebude fungovat“ na „zkusme to“;
  • Vlastnictví změny se přesunulo na lidi;
  • Energie a vzrušení pro změnu.

Kaizen workshop 

Poté, co jsme týmu umožnili zpracovat zkušenosti z prvního workshopu, nastal čas na další. Cíle druhého workshopu byly: 

  1. Zmapovat stávající procesy;
  2. Identifikovat hlavní problémy a úzká místa;
  3. Najít lepší možné způsoby práce;
  4. Vytvořit si implementační plán.

Zúčastnil se celý tým a každý mohl říct svůj názor. Tím se vytvořil pocit vlastnictví společného nového způsobu práce. Bylo opravdu skvělé vidět tu energii a vzrušení a jak všichni přispívají. Vzhledem k povaze naší práce (Engineering) jsme se rozhodli použít techniku ​​Kanban namísto dnes tak populárního Scrumu. Díky celodenní týmové práci jsme přišli s návrhem, jak bude vypadat nový proces – Kanban Board s lístečky na něm.

Proč Kanban:

  • Přesné specifikace požadavků od našich klientů;
  • Čtrnáctidenní sprinty by znamenaly pouze umělé milníky, bez přidané hodnoty;
  • Potřeba vizualizace celého procesu;
  • Malá změna od současného způsobu práce.

Jako poslední krok jsme se dohodli na implementačním plánu:

  • Připravena fyzická tabule a prezentace týmu (dva týdny po workshopu) – sběr zpětné vazby, potvrzení konečné změny;
  • První použití pilotu (po jednom týdnu);
  • Retrospektiva a vylepšení (po jednom měsíci používání);
  • Retrospektiva a vylepšení s RainFellows (po 6 měsících).

Implementace Kanban, denní stand-up a retrospektivy

Nejprve jsme vytvořili prostředí, které nezastaví nadšení lidí tím, že nebude fungovat nebo tím, že bude chybět vybavení. Rychle jsme koupili magnetické tabule a pomocí pásky jsme definovali dohodnuté rozvržení procesu. Tabule byla vybavena lepicími lístečky různých barev a magnety. Nejdůležitější bylo začít co nejdříve po workshopu. Věděli jsme, že první návrh tabule není optimální, ale všichni si byli vědomi, že se bude vyvíjet a my ji budeme optimalizovat za běhu.

Byli jsme rádi, že jsme udělali pilotní tým pro změnu. Pilotní tým měl ukázat cestu ostatním týmům. Někteří to zpočátku nepřijali a považovali to za ztrátu času, ale čas ukázal opak.

Nyní každý sdílí stejnou úroveň informací a získává úplný přehled o všech projektech. Rychlost rozhodování přesvědčila i ty skeptické. A teď dokonce pomáháme ostatním oddělením založit jejich vlastní Kanban Board.

Výhody, které pozorujeme:

  • Po několika měsících jsme provedli průzkum. Výsledek nás všechny překvapil – bylo to velmi pozitivní! 
  • „Přehled“ byl jmenován každým jako hlavní přínos. Stejná úroveň informací, dokonce i pracovní zátěž sdílená všemi v týmu; 
  • “Snadnější spolupráce” a “svoboda výběru úkolu” byly další běžné odpovědi týmu; 
  • Z vnějšího hlediska týmový duch zvyšuje transparentnost a úroveň sdílení informací mezi lidmi; 
  • Kromě toho tým přirozeně fungoval v samoorganizačním režimu bez jakýchkoli zvláštních kroků.

Implementace nástroje Jira 

Měli jsme dobrý důvod přestěhovat se z fyzických tabulí do Jira. Museli jsme zlepšit spolupráci s naší kanceláří v Detroitu a naší novou kanceláří v Indii. Koordinace kapacity na vzdálených místech bez sdílené platformy stojí spoustu komunikace.

Stejně jako u fyzické tabule jsme vytvořili prostředí, které fungovalo bez přerušení od začátku. Prostudovali jsme Jira a otestovali si základní funkčnost, jako jsou filtry a různá uspořádání karet s úkoly pro lepší organizaci práce.

Indický tým jsme našli jako optimální pilot pro Jira. Šlo o zcela nový malý tým, který si právě nastavoval způsoby práce. Proč jim tedy hned neukázat nový proces? Přijali to jako součást standardních procesů, ne jako změnu. V Indii jsme jim poskytli týdenní osobní podporu a nechali tým otestovat Jira. Po tomto úspěšném testu jsme uspořádali úvodní setkání v Praze. Abychom zachovali možnost osobních schůzek, rozhodli jsme se použít projektor vedle fyzické tabule a použít jej jako paralelní vizuální podporu našich denních schůzek. Na druhém setkání jsme odhalili, že se každý díval na projektor místo fyzické tabule s kanbanem, takže od té doby používáme už pouze Jira.

Práce z domova 

Naštěstí jsme začali pracovat s Jira před dobou nucené práce z domova. Ve skutečnosti to bylo jen dva týdny před pandemií. Takže to byla spíše adaptace na situaci. Naše setkání jsou nyní delší, místo 5 minut to trvá 30 minut. Hlavně proto, že musíme kompenzovat izolaci a lidé rádi mluví i o jiných věcech, než jen o problémech nebo kapacitách.

Výhody Jira:

  • Možnost přidat informace přímo na pracovní kartu. Mít vše na jednom místě a dosažitelné pro všechny členy týmu;
  • Nedokážeme si představit, jak by se současná situace řešila s něčím jiným než s touto platformou a sdílenými informacemi;
  • Digitální Kanban Board otevírá možnost statistik a ukazuje oblasti, kde se můžeme zlepšit.

Plány do budoucna

Stále jsme na začátku a je toho ještě hodně co dělat. Musíme studovat Jira ještě hlouběji a také požádat tým o zpětnou vazbu.

Kromě toho bychom chtěli zahájit takovouto Jira-spolupráci i s našimi kolegy v Německu a tímto způsobem spolupráce pomoci ostatním útvarům v celé společnosti. Později by bylo skvělé, kdybychom bez e-mailů použili Jira pro sdílení všech informací o projektech, takže úplné informace by byly vedeny již pouze v Jira-úkolech. Když se podíváme do budoucna, rádi bychom např. sledovali hodiny a kontrolovali rozpočet podle reportů z Jira nebo realizovali projekty s našimi zákazníky v Jira.

Závěr

Agile byl původně vynalezen v oblasti IT pro úspěšné řízení projektů ve vysoce turbulentním prostředí. Mnoho nápadů však vzniklo ve vývoji produktů Toyota, v dílnách slavného českého podnikatele Tomáše Bati a mnoha dalších. V současné době naše globální ekonomika vstupuje do nebývalé situace. Můžeme očekávat, že v důsledku toho dojde k neočekávaným událostem a změnám. Agile je tedy logickým nástrojem k úspěšné plavbě vysokými vlnami neznáma.

V REHAU jsme zažili to, že se týmy během transformace změnily: jsou „svěžejší“, aktivní, samosprávné a rychleji reagují.

Spoluautoři

Lukáš Kálal, Head of Engineering Design & Services CZ/IN, REHAU

Jakub Gurecký, Internal Agile Coach, REHAU

Retrospektiva s dětmi

Děláte doma retrospektivu s dětmi? Je to skvělé, ale připravte se na variantu, že Vám řeknou svůj názor. A to není vždy jednoduché slyšet. Budete překvapeni, s čím Vaše děti přijdou.

Z naší kuchyně

U nás jsme začali otázkou: “Co nám přinesla Korona dobrého? Co nového bychom si chtěli ponechat i nadále?” Samozřejmě děti reagují spontánně:

“Nemusím vstávat do školy!”

“Táta je s námi pořád doma a necestuje pryč!”

“Chceme každý den maminčinu domácí pizzu!”

“Hokej s tátou!”

Mimo jiné touto otázkou děti vedeme k postoji, že okolnosti nejsou negativní nebo pozitivní, ale záleží, jak na ně reagujeme. A v tom máme svobodu a kontrolu.

Když jsme rozebrali např. vstávání do školy, děti nám odhalily svoje pocity: “Připadáme si jako mravenci – že vás musíme poslouchat! Vy můžete všechno, my musíme vstávat a chodit do školy a pořád uklízet!”

Po vyjasnění, že jsme si to nevymysleli my (ano, překvapilo je to) a že je naše odpovědnost (překvápko podruhé), aby děti byly ve škole, přišla reakce: “Tak po nás aspoň nekřičte – dělej! Dělej!”

Pokračovali jsme rozebíráním pocitu „My nemůžeme dělat nic co chceme, jen vás poslouchat.“ Požádali jsme děti, aby popsaly, co se za ten den stalo, co dělaly: „Hráli jsme na tabletu, pak v pokojíčku, dělali jsme s tebou blbinky, jo a byli jsme na výpravě v lese!“

Pak jsme děti požádali, aby z toho vybrali věci, které dělali ze své vůle neboli co je bavilo. Po chvíli zaváhání vyprsknou: „No všechno! Aha, díky!“

Vzduch se pročistil. Nebyla to autorita rodiče, která řekla „Jste nevděční smradi, nic neděláte!“ Ale v tu chvíli sami pochopili sílu svých emocí, které ale vychází z přesvědčení „musím jen poslouchat“ nikoliv z reality. Minimálně po zbytek daného dne jsou děti jako vyměněné.

Jak postupujeme

  1. Necháme děti napsat nebo nakreslit (aby je to více bavilo) na lísteček, co se jim za poslední dobu líbilo a chtěli by zachovat i dále nebo zažívat více. Po chvíli si nasdílíme (ano, pamatují si, co ty obrázky znamenají 😉
  2. Za co chci někomu z rodiny poděkovat? Opět – lísteček a kolečko sdílení.
  3. Co se mi nelíbí a chci jinak? Opět – lísteček a diskuze, co s tím můžeme společně udělat.  

Závěrem

Jako rodiče máme pocit, že jsou daná pravidla samozřejmost a že jsme to už dětem přece vysvětlovali. Nebo jim to ani nemusíme vysvětlovat, prostě svět takový je. V takovém případě je ale možné, že si naše dítě buduje postoj malé oběti. 

Našim cílem je vychovat děti s postojem, že záleží hlavně na jejich přístupu a ten ovlivní vždy. 

Jak se vzdělává (agilní) kouč?

Nedávno jsem dostal dva zajímavé dotazy:

  1. Jak se jako kouč vzděláváš ty?
  2. Jak může naše firma získat desítky zkušených koučů, když u nás má s Agilitou málokdo praktickou zkušenost?

Když jsme v roce 2006/2007 pomalu rozjížděli tým koučů Tietu, ze kterého následně vyrostlo RainFellows, velmi rychle jsme pochopili, že zkušenosti a expertíza Agile jsou jedna věc, ale schopnost tyto zkušenosti předat je úplně jinou disciplínou. Jak co nejrychleji tuto “kompetenční díru” vyplnit? Akcelerovali jsme naše učení Agilním způsobem: pravidelnými retrospektivami, koučováním v páru a učením se jeden od druhého (peer learning) v týmu.

Následovala fáze dvě: potřebovali jsme předat znalosti mimo náš tým. Vytvořili jsme tedy komunitu napříč firmou a zeměmi. Celý koncept byl ještě poměrně nestrukturovaný a volný. Tyto zkušenosti byly ale základem pro následující posun: když jsme odešli z Tieta a založili RainFellows s.r.o., první kroky vedly do podnikatelského klubu BforB. Tady jsme pochopili význam (a bez té vlastní zkušenosti by to nešlo) efektivní struktury klubových/komunitních setkání. Následoval náš projekt BusinessCon, kterým jsme společně s ostatními tento koncept posunuli na novou úroveň. Zaměřili jsme se na učení jeden od druhého (peer learning) nad praktickými případovkami, případně Case Clinic v případě inovativních řešení.

Takto ověřenou strukturu jsme promítli do setkávání (Guildy neboli cechu) Agilních koučů. Jak vypadá takové první setkání?

Kick off
0,5hPředstavení
1hKompetenční mapa – klíčové kompetence Kouče (dává dohromady sama skupina), převedení na gamifikační prvky (úrovně, achievementy, příklad: zde) –   sdílení zkušeností při plnění výzev z kompentenční mapy.
1hBurza potřeb – co potřebuji s ohledem na mou roli a kompetenční mapu? Co naopak můžu nabídnout jako mou “silnou dovednost”? Kouči si nabízí pomoc mezi sebou.
1hHodnoty a naše společné manifesto – jakými dohodami se řídí naše skupina?
0,5hPrioritizace Backlogu témat (přednášek) + volba Core týmu

Jak vypadá taková burza potřeb můžete vidět například v programu RBeConnected, ve kterém jsme jako průvodci. Smyslem je přenášet odpovědnost a aktivitu přímo na členy, nenechávat to na lídrovi nebo externím lektorovi. Burza potřeb spolu s prvkem gamifikace hezky vizualizuje cestu kouče, což je opět jeden z principů Agility aplikovaný přímo na rozvoj kouče.

Všechna další setkávání se pravidelně odehrávají podle společného schématu:

Komunita (Guilda neboli cech)
1hÚvod + vybraná přednáška
1,5hPřípadová studie/Case Clinic
1hVizualizace splněných questů, achievementů a nová Burza potřeb
0,5hPrioritizace Backlogu témat a dohodnutí následných akcí a schůzek

Případová studie, příp. Case Clinic je dopředu připravená na základě poptávky někoho z členů komunity. Např. “V mém týmu úplně nefungují Retrospektivy. Kdo mi s tím chce pomoct?” Dva další členové (typicky senior + junior) připraví na příští setkání spolu se zadavatelem podklady (jak vypadá tým, jak se dosud vedou retrospektivy, jaký je problém, atd.). Během setkání se pak všichni vyjadřují k danému problému: co je v té souvislosti napadá, s čím mají dobrou zkušenost, co naopak nedoporučují, atd. Dochází tak ke společnému sdílení a někdy i inovacím za pomoci kolektivní inteligence všech zúčastněných. Každý si odnáší něco pro sebe, pochopitelně nejvíce pak ten, který přišel se zadáním. Budují se vztahy mezi kouči, kteří si následně pomáhají i nad rámec setkání.

Takto řešený způsob vzdělávání je aplikací Agilních principů: kultura MY, pravidelné reflexe, učení se od sebe navzájem, maximální zaměření na hodnotu, atd. Včetně principu Učící se organizace (Learning organisation), která se dá škálovat napříč celou společností – nemusí to být jen komunita koučů! Setkávání Tribe leaderů, Chapterů a Guild má stejnou strukturu.

Tak se vzdělávám já. Popravdě, knihy příliš nečtu, nejsem čtenářský typ. Ale baví mě učit se od druhých. To je můj osobní růst.

Fixní kontrakt a vývoj? Recept na selhání

Někdy se stane, že projekt selže. A to navzdory všemu možnému, co pro jeho úspěch uděláme. Třeba i aplikování toho nejlepšího z osvědčených postupů. Ať už jste dodavatel nebo zákazník, takzvané fixní (fixed price) kontrakty nejspíše udělají z vašeho vysněného projektu noční můru.

Zdroj napětí

Zákazník potřebuje fungující a kvalitní produkt nebo službu. Dodavatel chce takový vyvinout. Ale ve většině případů se to nepovede. A je v podstatě jedno o jaké odvětví se jedná.

Tvoříte pro klienta novou marketingovou strategii? Vyvíjíte nové senzory pro měření stavu počasí? Nebo software? Zbystřete – váš projekt má statisticky velmi malou šanci na úspěch.

Samozřejmě existuje mnoho faktorů, které přispívají k tomuto selhání, ale jednou z hlavních příčin bývá kontrakt – formální spojení mezi zákazníkem a dodavatelem. S kontraktem vše začíná a také obvykle končí, protože v případě problémů je to právě kontrakt, co nakonec rozhoduje. Podívejme se, jaká rizika typické fixní kontrakty přinášejí a jak se jim vyhnout.

Většina vývojových (R&D) projektů selže

Podívejme se v detailu na vývoj software, protože tam všechny nevýhody a rizika dobře vynikají. Pravděpodobnost úspěchu softwarového projektu (SwP) je asi jen 37% [Standish Group – Chaos report 2010, 2012, 2014, 2017]. To je docela alarmující, navíc se to s léty nijak nelepší. Znamená to, že by lidé v IT byli hloupí nebo neschopní? Ne, problémem je, že pro budování software používáme nevhodné modely spolupráce a postupy. Většina zákazníků totiž přistupuje k vývoji software na zakázku stejně jako k nákupu produktů (automobily, telefony, počítače, domy). Ale pravdou je, že tyto dva případy nejsou stejné. Podívejme se proč.

SWD CZ

Jak vidíte na obrázku výše, šance na opakovatelnost úspěchu a opětovné využití znalostí v případě návrhu unikátního software na zakázku je mnohem nižší, než v případě výroby např. automobilu.

Použití stejného přístupu bychom mohli přirovnat k realizaci programu Apollo (člověk na Měsíci), plného nezbytného výzkumu a vývoje nových technologií, pomocí tzv. vodopádového modelu – popsat do detailu cíl, navrhnout najednou celé řešení, postavit napoprvé funkční raketu s příslušenstvím a v předem daném datu odpálit posádku k měsíci. Jsem přesvědčen, že by se jednalo o jednu velikou katastrofu. Byla to až 11. mise Apollo, která nakonec přistála na měsíci. A představte si kolik miliónu cyklů pokus-omyl bylo třeba provést se všemi prototypy a podsystémy před tím, než bylo vůbec možné uspět.

Úspěch v těchto kreativních/inovativních oborech, kam SwP nepochybně patří, vyžaduje četné krátké cykly učení. Jen tak je možné vytvořit něco tak složitého, jako je software naplňující neurčité potřeby zákazníka. Problémem je, že k takovým projektům přistupujeme s domněnkou, že jsou předvídatelné. Snažíme se vše zafixovat do kontraktu v okamžiku, kdy vlastně o celém projektu a problému, který řeší, víme nejméně. Kdy ještě neznáme kritické informace, které vyplynou až v průběhu realizace.

Dům snů

house of dreamsPokud jste někdy stáli na straně zákazníka, určitě víte, jak těžké je formulovat požadavky. Kde začít? Jak celý problém uchopit? Často se stává, že ty nejdůležitější požadavky dokonce chybí.

Když se zeptáme lidí na našich workshopech: “Představte si svůj dům snů… všechno je možné… jaký by byl?”. Obvykle dostaneme odpověď jako že bude mít bazén, velikou televizi, obří obývák, sám se bude uklízet atd. Ale nikdo obvykle neřekne že bude mít okna, dveře, zdi a střechu. Proč? Protože to je “jasné”, že každý dům je má. Každý architekt by to měl vědět, ne? A teď si představte zákazníka odmítajícího převzít software, protože je jasné, že každý bankovní systém řeší i pravidelné posílání měsíčních výpisů z účtu, které samozřejmě ani nebylo součástí požadavků. Analytik to přeci měl vědět…

Mary měla malé jehňátko

mary had a little lambA to není všechno. I kdybychom byli schopni všechny požadavky popsat, stále bude obtížné je přesně pochopit. Znáte říkanku “Mary měla malé jehňátko”? (Mary had a little lamb) Pokud ji vytrhneme z kontextu – stejně jako to děláme s požadavky – co ta věta znamená? Jak jí rozumíte?

  • Starala se Mary o svého mazlíčka jehňátko?

  • Nebo snědla malé jehně?

  • Nebo snědla malou porci velkého jehněte?

  • Porodila jehně?

  • Měla s ním sex?

  • Napálila nějakého naivu, aniž by za to nesla následky? (z hantýrky burzovních makléřů)

Jak vidíte, jediná věta v požadavcích může být interpretována mnoha různými způsoby. Dokonce takovými, které by nikdo ani nehádal – třeba ten s tím naivou. A teď si představte tisíce vět ve specifikaci požadavků, z nichž každá podléhá tomuto takzvanému Mary had a little lamb syndromu. Vidí čtenář požadavků budoucí software stejně jako ten, kdo tuto specifikaci píše?

Proč tedy uzavíráme fixní kontrakty?

Takže pokud…

  • se potřebujeme adaptovat na měnící se požadavky po celou dobu projektu
  • nedokážeme předem definovat všechny detailní požadavky
  • nedokážeme jim jednoznačně rozumět
  • a tím pádem ani odhadnout jejich pracnost

…proč tedy stále tyto fixní kontrakty používáme a snažíme se vše odhadnout a zafixovat předem? Obsah projektu, čas doručení a cenu? Předpokládám, že tomu tak je, protože lidé podpisující tyto kontrakty si neuvědomují specifika vývojových R&D projektů nebo prostě neví o žádné rozumnější alternativě. Ale takový omezující kontrakt má pak velmi negativní důsledky.

cage bars lock closed fixed contract birdPředstavte si sami sebe jako dodavatele svázaného takovýmto kontraktem, který penalizuje jakékoliv porušení některého z rohů pomyslného trojúhelníku požadavky, datum doručení a cena. Představte si, že se objeví nějaká komplikace, což se velmi pravděpodobně stane. Zvolíte risk a doručíte to, co zákazník opravdu potřebuje, anebo budete hrát bezpečně a doručíte to, co je doslovně napsáno v kontraktu? Mnohdy zákazník ani nechce nebo nemůže zmíněné komplkace řešit. Co uděláte? Většina lidí volí “bezpečnou” variantu a doručí to, co je kontraktováno. A pak je to tady – prohra na obou stranách. Zákazník nedostane to, co pro svůj byznys skutečně potřebuje a dodavatel je za to obviňován. Přepracování produktu a oprava chyb pak násobí cenu celého řešení.

Nedokážeme předvídat budoucnost (nevíme, co nevíme) a v ní a v realizačních detailech jsou ukryta ta nejhorší překvapení. Jako například změny potřeb zákazníka, technické problémy, neplatné předpoklady, legislativní změny… Nejvíce překvapení zažijeme, když jsou odhady pracnosti a kontrakt vynuceny velmi brzy, kdy nemáme příliš mnoho informací. Ze zkušenosti také víme, že tato omezení vyplývající z kontraktu vytvářejí bariéru mezi zákazníkem a dodavatelem, která jim pak brání v aplikování praktiky, která by mohla celou situaci zlepšit – tzv. trvalého zlepšování (continuous improvement). Bariéry prodlužují nebo znemožňují nezbytné cykly učení.

Agile/Lean kontrakt

air freedom options mountains sky free people man person

Co bychom tedy měli udělat? Jednoduše řečeno – nedávat do kontraktu detailní popis výsledného produktu, ale raději se v něm zaměřit na to, jak mají dodavatel a zákazník spolupracovat, aby dosáhli společně nejlepšího možného výsledku. Zdá se to být kacířská myšlenka, protože selský rozum říká: “Pokud jsme tentokrát nedostali, co jsme chtěli, musíme být příště mnohem více striktnější a definovat vše ještě detailněji”. To ale, jak jsme si řekli dříve, neřeší příčinu a situaci v konečném důsledku ještě zhorší.

Co by tedy mělo být napsáno v takovém kontraktu? Určitě popis postupu/procesu, jakým způsobem dodavatel společně se zákazníkem vytvoří nejlepší možný výsledek. Vložíme tam osvědčené postupy a praktiky, které empiricky fungují. Co to znamená? Krátce řečeno, kontrakt by měl obsahovat následující:

Postup/proces tvorby výsledného produktu/služby založený na učících se cyklech (iteracích) a jednotlivé fáze projektu

  • Příprava projektu – vize, byznys cíle, hlavní akceptační kritéria, vysokoúrovňové testy, které musí projít, aby řešení pomáhalo byznysu
  • Tvorba řešení – iterace a jejich akceptace
  • Doručení řešení – termíny a finální akceptace

Odpovědnosti dodavatele

  • Spolupracovat se zákazníkem na tvorbě požadavků, pomoci mu definovat je z pohledu uživatele, ne systému.
  • Před každou iterací se zavázat k tvorbě jejího obsahu a mít připravený funkční výsledek pro následnou demonstraci hodnoty na jejím konci.

Odpovědnosti zákazníka, kdy musí být přítomen nebo k dispozici a na jak dlouho

  • Pomoci připravit detaily k požadavkům před začátkem iterace
  • Být k dispozici k otázkám vývojářů během iterace
  • Účastnit se dema, být na něm schopen akceptovat/odmítnout předváděnou a dohodnutou hodnotu

Učící se cykly

  • Kdy a jak proběhnou společné retrospektivy, aby se předcházelo problémům a spolupráce se neustále zlepšovala
  • V případě, že iterace selže, nebo zákazník není spokojen s výstupem, je automaticky provedena zvláštní společná retrospektiva a jsou přijata opatření, aby se situace neopakovala

Důsledky porušení dohodnutého způsobu spolupráce

  • Zákazník se nedostaví na demo? Všechna funkcionalita je automaticky akceptována, každá další změna je řešena jako nový požadavek.
  • Objevily se chyby? Musí být opraveny dodavatelem v následující iteraci.

Obchodní model

  • Na základě čeho se počítá cena? (rezervovaná kapacita, cena za iteraci, za požadavek, za jeden StoryPoint, …)
  • Bonusy a pokuty

Jak je vidět, takový typ kontraktu je vždy unikátní, protože odráží konkrétní možnosti a omezení obou partnerů. Takže jeden vzor kontraktu určitě nebude sedět na všechny projekty. Ale jsou zde části, které se obvykle dají znovu použít. Tak jako tak, práce věnována takovému kontraktu se později mnohonásobně vrátí.

Nám se povedlo dostat několik takovýchto kontraktů do praxe s různými zákazníky naších klientů. A podle výsledků a zpětné vazby tento přístup opravdu funguje! Výsledky jsme již několikrát prezentovali na mezinárodních konferencích (Leanest 2012, 2013 konference ve Stockholmu a v Praze).

Pokud byste chtěli vědět více, ozvěte se nám. Rádi nasdílíme vše, co jsme se za posledních 10 let v této oblasti naučili.

Sledujte nás na