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.

Konec nudným a neproduktivním poradám!

Znáte to, kolem stolu sedí několik spolupracovníků a reportují stav projektu vedoucímu. Každý by se měl zajímat o to, co kdo dělá, ale pravda je taková, že každý jen čeká, až přijde na řadu a řekne svou část. Jediný, kdo je na konci nějakým způsobem spokojený je vedoucí, který tak dostal alespoň nějaké informace o stavu projektu. Všichni ostatní setkání pokud ne přímo nenávidí, tak minimálně berou jako nutné zlo. Jde to celé dělat jinak?

Představme si situaci, kdy se na synchronizační meeting všichni účastníci těší, vnímají jej jako naprosto klíčovou součást práce, s nímž velmi rychle a efektivně společně vyřeší operativní problémy. A vedoucí má jistotu, že projekt běží nejlepší možným způsobem. Jak? Vyměňme reportování stavu projektu za vzájemné propojování a řešení situací v páru na základě operativní potřeby – stejným způsobem, jakým dělají byznys podnikatelé a živnostníci ve 21. století.

Jak to probíhá?

Předně pozornost a potřeba se přesouvá z “kde jsme byli minulý týden/měsíc” na “co potřebujeme pro co nejrychlejší posun vpřed”. Za druhé řešíme projekt jako autonomní tým a vedoucí se z dozorčího stává strážcem společných hodnot, hranic autonomie členů týmu a aktivním podporovatelem dění na projektu.

Agenda meetingu

  1. meeting procedureKaždý účastník pronese předem připravený 1-2 minutový proslov:
    1. Kdo jsem a co dělám (možno zkrátit či vynechat, pokud už se všichni znají)
    2. Co se nám od posledního meetingu podařilo a s čím mohu pomoci ostatním
    3. S čím bych aktuálně potřeboval pomoci
  2. Ostatní během proslovu naslouchají a snaží se co nejvíce aktivně pomoci, buď sami nebo prostřednictvím lidí ve svých týmech nebo své síti kontaktů. V takovém případě nic neříkají, jen si v okamžiku, kdy příležitost uvidí, zapíší poznámku na tzv. referenční ústřižek. Okamžitě proto, že člověk si obvykle už po chvíli nepamatuje, co kdo říkal 🙂 Referenční ústřižek účastníci vyplňují i v případě, chtějí-li přijmout nabídnutou pomoc nebo třeba jen slyšet k tématu více.
  3. Jakmile proběhne celé kolo a všichni nasdílejí, co mají ke sdílení, vymění si účastníci navzájem referenční ústřižky. Tato vizualizace je důležitá pro zvědomění jednotlivých spojení. Nabízený ústřižek účastníci obvykle vnímají jako dárek, jako formu závazku, která dále přispívá k tomu, že se propojení později opravdu uskuteční.
  4. Po výměně lístečků si členové ihned otevřou své kalendáře a naplánují si schůzky, kde si navzájem pomohou, či nasdílejí, co je třeba. Okamžité plánování schůzky opět zvyšuje šanci, že se následná společná akce uskuteční.
  5. Vedoucí v průběhu všechny nabádá, ať se propojí. Sám aktivně nabízí pomoc a svou síť kontaktů.

Vedoucí i všichni účastníci tak dostanou vhled do výsledků práce a toho, co se aktuálně řeší v celém týmu a navíc si všichni operativně pomáhají.

Co k tomu potřebujeme?

1. Orientace na budoucnost
Projekt má jasně definovaný záměr/cíl (celkový i nejbližší milník), a to včetně akceptačních kritérií. Každý z účastníků projektu zná odpověď na otázku “Jaký je dobrý výsledek projektu?” (cíle) a “Jak poznáme, že už tam jsme?” (akceptační kritéria, klíčové ukazatele). Schválně se zeptejte náhodně vybraného člena projektu, zda dokáže na tyto otázky bez zaváhání odpovědět. Pokud ne, víte, co máte dělat 🙂

2, Autonomní tým
Členové týmu (případně tým týmů) obvykle pracují samostatně. Potenciál se však skrývá právě mezi jednotkami, v jejich spolupráci: 1+1=11. Pokud každý rozumí cílům a akceptačním kritériím, pak nejlepším způsobem, jak vytvořit opravdu spolupracující tým je jednotlivé členy navzájem párovat při řešení (netriviálních) úkolů potřebných k dosažení tohoto cíle. Jde o takzvané budování triád (více v našem článku Agilní kultura a leadership, který popisuje Tribal Leadership). Úloha je při práci v páru rychleji dokončena, je menší pravděpodobnost chyby, lidé se od sebe navzájem učí a jsou tak zastupitelní a budují mezi sebou trvalé kooperativní vztahy. Časem tak získáte z pasivních jednotlivců spolupracující autonomní tým. S trochou štěstí můžete pozorovat, jak jednotlivé týmy, které spolu dříve nepromluvily, v kuchyňce u kávy proaktivně řeší spolupráci na projektu.

3, Vedoucí = lídr
Vedoucí je klíčovou částí systému. Z původního dozorčího se stává propojovatel a podpůrná síla. Jeho hlavním úkolem je maximálně podpořit párování členů týmu a zajistit, že všichni znají odpovědi na výše uvedené otázky. Lídr sám proaktivně odstraňuje z cesty vše, s čím si tým sám neporadí a pravidelně s týmem “vyměňuje olej”prostřednictvím tzv. týmové retrospektivy – setkání, na němž tým probere, co mu ve způsobu práce funguje a mělo by se stát standardem a co by mělo být zlepšeno. Vždy právě jeden návrh se pak co nejrychleji realizuje. Vybíráme jeden návrh, protože ze zkušenosti víme, že čím více jich rozpracujeme, tím menší je pravděpodobnost, že se některý dokončí.

network meeting

Pozitivní vedlejší účinky

Vybudované vztahy a zvyk práce v páru (skupině) se týmům mnohonásobně vrací v okamžiku něčeho neočekávaného, což v praxi nastává téměř každý den. Tím, že jsou spolu jednotlivci zvyklí spolupracovat a navzájem si důvěřují, je také větší šance, že případné problémy spolu vyřeší namísto toho, aby si vymezili hranice a vzájemně se obviňovali.

Víme, že každý projekt je unikátní, sdílejte s námi váš příběh – napiste.nam@rainfellows.cz.

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