Domů

Principy Kanbanu

Kanban stojí na pěti klíčových principech:

  • vizualizace workflow,
  • omezení WIP,
  • řízení toku (flow),
  • explicitním nastavení pravidel,
  • společném zlepšování.

Kanban Principles Explained

6 vyjednávacích taktik

Vyjednávání

Většinu vyjednávacích taktik používají lidí intuitivně. Taktika je jednoduchý manévr, tah nebo protitah. Níže je přehled šesti nejběžnějších, se kterými se můžete setkat. V praxi nejde ani tak o to jednotlivé taktiky použít, jako spíše být schopni je identifikovat a neutralizovat.

Největší chybou při vyjdednávání je myslet si, že druhá strana musí prohrát, aby vy jste mohli vyhrát. Když ani jedna strana nemůže vyhrát, z teorie her víme, že musíme změnit pravidla hry. V nové hře mohou vyhrát obě strany.

Deadline

„Pokud to nebude do pátku, nemohu ručit za termín dodání.“

Tlak termínu může obě strany donutit jednat. Termíny mohou být skutečné nebo umělé. Externí termíny jsou vynucené třetí stranou, interní jsou stanovené vaší organizací.

Obrana: Osoba nastavující termín počítá s tím, že je v lidské povaze věřit, že termíny jsou skutečné. Pokud se chcese pokusit zneutralizovat termín, otestujte ho. Položte několik otázek a zjistěte, jak skutečný a pevný termín je. V případě skutečného termínu se zeptejte, odkud termín pochází, je-li možné jeho prodloužení a jaké jsou důsledky nedodržení termínu.

Tímto způsobem můžete napadnout například umělé termíny projektového managementu :)

Omezená autorita

„Bude to muset schválit můj šéf.“

Vyjednávající zdůrazní svoji omezenou autoritu a zpomalí vyjednávání. Výhodou je získání více času na rozhodování, případně i snížení tlaku protistrany.

Obrana: Je nutné zjistit, kdo dělá rozhodnutí, a setkat se přímo s tímto člověkem. Vždy když je to možné, začněte vyjednávat s tím, kdo má pravomoc dělat rozhodnutí.

Je to jedna z možných taktik při vyjednávání o zvýšení platu. Můj vedoucí mi jednou sedm měsíců sliboval projednání mého platu se svým nadřízeným. Až teprve vytvoření tzv. věrohodné hrozby („Odcházím z firmy.“) donutilo protistranu jednat.

Alternativou omezené autority je „chybějící osoba“. V případě „chybějící osoby“ nemůžete udělat závazné rozhodnutí bez tohoto člověka: „Nemůžu s vámi diskutovat termín dodávky, protože náš projektový manager je po zbytek týdne mimo firmu.“

Morálka

„Nabídněte nám férovou cenu. Nemůžete očekávat, že zaplatíme tolik při vašich problémech s cloud-dovým úložištěm.“

Odvolání se na morálku má připomenout, že cíl vyjednávání je vzájemná spokojenost. Tato taktika apeluje na váš smysl pro „fair play“ a zahrnuje mnoho prohlášení, jejichž účelem je dostat vás na druhou stranu.

Obrana: Připomenutí podmínek a vysvětlení, že tyto podmínky jsou v nejlepším zájmu obou stran. Zjistěte, jaká je skrytá motivace druhé strany a čeho se druhá strana doopravky obává.

Hodný a zlý

Hodný a zlý. Všichni jsme tuto situaci mnohokrát viděli v televizi. Jeden člen vyjednávacího týmu zastává extrémně radikální pozici, klade nadměrné požadavky a odmítá rozumné ústupky. Neochota slevit vás může zastrašit, vyvést z rovnováhy a snížit vaše očekávání. Najednou přijde do hry „hodný“ vyjednavač se smířlivými, mírně lichotivými poznámkami, a nabídne rozumnější nabídku. I když druhá nabídka je relativně lepší, stále nemusí být dost dobrá v absolutním smyslu. Člověk má přirozené nutkání s druhou nabídkou souhlasit.

Obrana: Dávejte si pozor na svoje původní požadavky. I když nabídka hodného vyjednavače může znít fantasticky v porovnání se zlým vyjednavačem, stále to nemusí být nabídka dost dobrá pro vaši stranu. Zjistěte, jestli nabízené podmínky souhlasí s vašimi požadavky.

Příklad: Některé zahraniční společnosti využívají této taktiky při diskuzi o platu. Nejde o to, že by nemohli svým zaměstnancům platit více, ale chtějí, aby zaměstnanci měli pocit, že si při vyjednávání sáhli na dno a byli maximálně spokojeni: „Podařilo se mi domluvit nástupní plat 50 000Kč. Je to skvělé. To mému kolegovi Frantovi, tomu se něco takového určitě povést nemohlo…“

Každý to tak dělá

„Nikdo na našem oddělení nemá takový plat, jaký chcete.“

Malé děti jsou mistři této taktiky: „Mami, každý ve třídě má nový mobil.“ Tato taktika se vyskytuje často také v obchodě. Cílem je přidat na věrohodnosti svému tvrzení a oslabit protistranu.

Obrana: Použijte ověřená data (standardní marže, průmyslové standardy, inflace, …) a stanovte si férové podmínky dohody. Dále si zjistěte, co konkurence nabízí a jaké mají vztahy s ostatními klienty. „Kdo jsou všichni?“

Asociace

„Tento projekt mi připomíná jednu zakázku pro XYZ s.r.o.“

Nejúspěšnější obhodníci používají tuto taktiku na začátku hovoru, aby přidaly svým slovům věrohodnosti a zlepšili svoji vyjednávací pozici. Taktika, někdy nazývaná „name-dropping“, spočívá v asociaci s různými jmény firem, lidí, produktů, atd. Asociace může být velmi efektivní, pokud je pravdivá, ale také velmi manipulativní, pokud je nepravdivá.

Obrana: zeptejte se druhé strany na to, co dělaly pro jiné firmy nebo lidi, které v rozhovoru zmiňují. Na jakých podmínkách se dohodli. Jak velká byla jejich objednávka? Zjistěte co nejvíce detailů o tom, co druhá strana se zmiňovanými subjekty dělala v minulosti.

Škálovaný Kanban

Jak můžeme škálovat Kanban? Odpověď je překvapivě jednoduchá: Aplikováním Kanbanu ve větším měřítku. Jakmile máme zavedený kanban pro alespoň jednu službu, existují tři dimenze, do nichž může náš kanban růst.

Škálování do šířky

Škálovat do šířky znamená zachytit delší část životního cyklu úkolů. V ideálním případě je zachycen celý životní cyklus. Odkud úkoly přicházejí? Co se děje po jejich dokončení? Následuje test zákazníkem? Širší cyklus umožňuje odhalit nové možnosti optimalizace a zvyšování efektivity.

Příklad: Původní board zachycující pouze vývoj produktu je rozšířen o “backlog nápadů” a práci s těmito nápady ještě před tím, než se dostanou do produkce.

Škálování do výšky

Škálování do výšky předpokládá hierarchii úkolů, které dohromady tvoří produkt nebo službu. Například strategické plánování na nejvyšší úrovni lze rozpadnout na jasně definované user stories, jenž mají být doručeny zákazníkovi. Tyto high-level features lze dále rozložit na drobnější user stories, na kterých bude konkrétní tým pracovat.

Kanban používá stále stejné principy a funguje v jakémkoliv měřítku - ať jde o úkoly trvající hodiny nebo měsíce. Obvykle se můžeme setkat se čtyřmi úrovněmi Kanbanu:

  1. Osobní Kanban. Osobní Kanban může využívat jednotlivec nebo velmi malý tým k efektivnějšímu organizování práce.
  2. Týmový Kanban. Práce týmu je chápána jako služba. Aplikování praktik Kanbanu vytváří předvídatelný tok hodnoty k zákazníkovi.
  3. Produktový Kanban. Položky v produktovém Kanbanu by měly být menší než typický projekt, ale dostatečně velké, aby mohly být rozpoznány a ohodnoceny zákazníkem.
  4. Portfolio Kanban. Portfolio management není varianta produktového Kanbanu s většími projekty, ale úplně nová disciplína zabývající se řizením finančního portfolia. Risk v projektech je vyvažován prací s časovými horizonty, návratností investice, hledáním alternativ v produktu vzhledem k pravděpodobným změnám na trhu a diferenciací portfolia.

Škálování do hloubky

Dodání služby jedním týmem může být blokováno potřebou specializované podpory jiného týmu s odlišnou specializací. (Např. potřebujeme zjistit, že technologie, kterou se chystáme implementovat, již není patentovaná.) Škálování do hloubky propojuje týmy a znázorňuje závislosti mezi úkoly. Zásadním předpokladem je, že všechny týmu již v nějaké podobě Kanban praktikují.

Zkreslení výběrem

Zkreslení výběrem je matematický fenomén, který chtě nechtě každý den zažíváme v praxi. Zkreslení výběrem znamená, že naše pozorování, ze kterých tvoříme širší závěry, nejsou pro danou situaci reprezentativní. Informace, které se k nám dostanou, mohou být záměrně zkresleny nebo si je jen vybíráme dle určitého klíče a tedy si je zkreslujeme sami. O co se konkrétně jedná?

Kupujeme rajčata

Zkreslení výběrem bych nejnározněj vysvětlil na příkladu kupování rajčat. Představte si, že se zastavíte v obchodě, prohlédnete si jedno, dvě, tři rajčata, a pokud se vám líbí, vezmete si kilo. Gratuluji, právě jste provedli něco, čemu se říká statistical inference. Z vlastností malého vzorku rajčat jste odvodili kvalitu všech rajčat u obchodníka. Obchodník vám z nich náhodně vybere kilo. Všechno funguje dobře jen do té doby, dokud je výběr rajčat čistě náhodný.

Vybral-li vám rajčata obchodník, mohlo se stát, že vám záměrmě ukázal tři nejlepší kusy. Mylně se pak může zdát, že všechna rajčata jsou krásná. A to je právě zkreslení výběrem.

Zkreslené informace tým lídra

Není-li k nějaké manažerské roli ze strany podřízenýc naprostá důvěra, je téměř jisté, že se k této roli dostanou jen určité, filtrované, informace. Ve chvílích, kdy se na první pohled může zdát, že tým exceluje, mohou lidé ve skutečnosti zažívat své nejhlubší krize.

Vývojáři nemusí říkat všechno, protože:

  • se bojí, že budou potrestání;
  • nechtějí být sami pověřeni nápravou situace;
  • nevěří, že k nápravě (ze strany třetích osob) dojde;
  • mají strach o své prémie;
  • nechtějí vedení naštvat.

Cesta informací ke střednímu managementu musí naopak projít přes nižší management. Vzniká tzv. kognitivní bublina, ve které management žije.

Objevování bugů při testování

Analogií výběru bugů z backlogy je navrtávání ropných polí v Texasu. V následujícím grafu ukazuje osa x počet pokusných vrtů a osa y normované množství objevené ropy.

Ropná pole [citace: Root, Drew: The pattern of petroleum discovery rates]

Z grafu je vidět, že několik málo vrtů vedlo k objevení většiny známé ropy. Lineární aproximace “uděláme dvojnásobek vrtů, abychom objevili dvojnásobek ropy” rychle přestala fungovat. D. H. Root a L. J. Drew vysvětlují, že velká ložiska jsou objevena první, protože je nejsnadnější je objevit.

Při testování softwarového produktu se můžeme setkat se stejnou křivkou jako na obrázku výše. Na ose x je doba testování, na ose y počet objevených bugů. Během prvního dne je objeveno nejvýce chyb a množství nově objevených chyb další dny klesá. Stejným způsobem, jakým bychom odhadovali množství neobjevené ropy, můžeme analogicky v některých případech odhadnout množství bugů, které zatím unikly objevení v testech a budou nalezeny až u zákazníka.

Závěr

Podobných příkladů zkreslení výběrem bychom mohli nalézt bezpočet. V praxi je důležité o možném zkreslení vědět. Na zkreslení výběrem můžeme provést korekci nebo data interpretovat jiným způsobem.

Stále stejné pohovory

Jednou z věcí, které jsem se naučil ve své krátké kariéře agilního kouče, je nedělat změnu tam, kde není vítána. Jednou z takových změn byl můj pokus o zlepšení přijímacích pohovorů. Bylo to v době, kdy jsme akutně sháněli nového člena našeho Scrum týmu. Představy ideálního vývojáře byly přibližně takovéto: dobrá znalost programovacího jazyka, komunikativní, týmový hráč, zkušenosti z jiných firem nebo vlastní projekty, schopný vyznat se ve vícevláknové aplikaci.

Mysleli jsme si, že něco takového by mohla splňovat většina kandidátů. A nesplňovala. Po pěti neúspěšných pohovorech jsem začal přemýšlet nad tím, co děláme špatně. Vodí k nám agentury nevhodné uchazeče? Většina lidí totiž přišla na pohovor právě přes agentury. Šestý člověk, jenž se ucházel o práci v naší firmě, byl poněkud zvláštní.

Byl to Ind, který nám narovinu ukázal svoje pracovní zkušenosti týkající se téměř výhradně fixování bugů. Byl to člověk, který nikdy nic velkého nenapsal, zato dobře věděl, jak analyzovat legacy kód. Oběma, mě a mému šéfovi, nám zamotal hlavy.

Nejprve jsme ho (alespoň pro sebe) zamítli. Později, při rozhovoru s Product Ownerem, jsem si uvědomil, že fixování bugů je přesně to, co děláme. Při pohovorech hledáme nějaký - z našeho pohledu - ideální typ vývojáře, který se ale vůbec nemusí hodit pro práci, jaká se u nás reálně dělá. A nechceme si to připustit. Otázky, které na pohovorech můj šéf kladl, se za posledních pět let nezměnily. Mí kolegové a já jsme byli všichni přijati dle úplně stejných otázek.

Bylo na čase se zamyslet nad tím, jak vlastně děláme pohovory. Klademe správné otázky? Pomáhají nám tyto otázky zjistit to, co chceme zjistit? Nebo je to jenom taková naše formalita? Nejsme předujatí? Umožňujeme různorodost lidí v týmu? Chtěl jsem si promluvit se šéfem.

V případech, kdy si nejsem jist výsledkem, otevírám téma velmi ze široka. Proč se nám nedaří hledat vhodné uchazeče? Sledujeme otázkami to, to chceme zjistit? Můžeme pohovory nějak vylepšit? Dostalo se mi rázného zamítnutí. Pohovory děláme dobře. Není co zlepšovat, protože už je to dobré. Otázky jsou odzkoušené a fungují.

Můj nadřízený měl zkrácený úvazek a svoji práci nikdy nedelegoval. Takže ano, chápu, že se mu toto téma nechtělo řešit. A já jako kouč nedělám změny tam, kde nejsou vítány.

Jak to dělám já

Je to přibližně týden, kdy byla spuštěna stránka Hany Farkaš jaktodelamja.cz. Jde o skvělou věc - konečně máme všechna videa z Jak to dělám já pohromadě.

Jak to dělám já je komunitní akce pro Scrum Mastery, kteří tak mají možnost nahlédnout do zákulisí práce jiných Scrum Masterů, aniž by opustili svoji firmu. Protože každý Scrum Master přikládá důležitost jiným dovednostem a prezentuje svoji práci z odlišné perspektivy, jsou prezentace velmi pestré.

Má smysl učit se C++ v roce 2018?

Má smysl učit se C++ i v roce 2018? Jednou větou: “Ano, pokud jsou systémy psané v C++ to, co vás zajímá.” Více větami: viz zbytek článku.

Jazyk C++ vytvořil Bjarne Stroustrup v 80. letech v Bellových laboratorých. Od té doby vzniklo několik standardů: C++98, C++03, C++11, C++14, C++17. Nejvýznamnější změny jazyka přináší C++11 a vývoj v posledních letech ukazuje, že jazyk C++ je stále živým jazykem. Standard C++14 opravuje a přidává věci, které se do C++11 nevešly. Verze C++17 se zaměřuje na zlepšení čitelnosti kódu.

Odpověď na otázku, zda zvolit C++ jako svůj další jazyk, závisí na tom, zda chcete vyvíjet systémy, pro které je C++ vhodný. Každý jazyk se totiž hodí na něco jiného. Cesta C++ byla více matematická, než u jiných jazyků. C++ umožňuje zvolit z několika programovacích přístupů (objektově orientované programování, metaprogramování, data abstrakce, hierarchie tříd). C++ vám umožní vybrat si z mnoha cest, přičemž optimální variantou bývá kombinace všech přístupů. Něco takového ve většině jazyků není možné.

Na druhou stranu je nutné říci, že v jazyce až donedávna chyběly základní funkce pro interakci se souborovým systémem (např. vytvořit složku) a psaní grafických aplikací vyžaduje externí framework, jehož studium vám pravděpodobně zabere více času než studium samotného jazyka. C++ se v minulosti více zaměřilo na abstraktní možnosti jazyka a zvětšování standardní knihovny nebylo prioritou.

Předností jazyka C++ je jeho rychlost a blízkost k hardware. Osobně jsem C++ využil v práci při psaní software k vojenským radarům, stolním telefonům, nativním Windows aplikacím (to jsou ty aplikace, které vypadají lépe než Java aplikace). Vývoj programů pro věděcké výpočty většinou probíhal přepisem kódu z Pythonu / Matlabu, odkud byly algoritmy převedeny kvůli rychlosti a přenositelnosti do C++ (není nutné řešit, jakou verzy Python má zákazník nainstalovanou). Často se setkáte s informací, že v C++ se píší operační systémy. V praxi ovšem musíte být velký geek, aby jste se dostali ke kódu Linuxového jádra. Dokonce i Red Hat vás spíše zaměstná na vývoji virtualizačního rozhraní než na fixování Linuxu.

Jazyk C++ tu je s námi už dlouho a ještě dlouho bude. Je to taková stálice. Protože většina společností má spousty starého kódu, práce na vývoji nového software se hledá obtížně, ale je tu. Jděte do C++, pokud by se vám líbilo dělat na věcech zmíněných výše, nebo alespoň pokud chcete mít praktickou zkušenost s jazykem blízkým k hardware.

P.S. Rozhodnete-li se učit jazyk C++, pozor na jeden častý mýtus: “Při učení C++ se hodí nejprve znát jazyk C.” Ne! To není pravda! Přes podobnost syntaxe je C jiný programovací jazyk. “C-čkové myšlení” se při přechodu do C++ jen těžko odnaučuje. Za důkaz by mi posloužily miliony řádků starého C++ legacy kódu, který psali lidé zvyklí na C.

Je Extrémní programování extrémní?

Na přednášce o Extrémním programování v Kentico mi byl položen zajímavý dotaz: “Je Extrémní programování stále extrémní?” Tazatel poukazoval na to, že dobré praktiky doporučované Extrémním programováním jsou dnes již tak běžné, že za nimi vlastně není nic neobvyklého. Proč se Extrémnímu programování (XP) neříká jednoduše jen Programování?

Jak XP získalo své jméno

Přívlastek extrémní získalo XP ze svého principu: “Pokud je něco užitečné, děláme to pořád.” Prakticky: Komunikace se zákazníkem je užitečná, proto bude zákazník na pracovišti a budeme s ním komunikovat neustále. Je refaktoring přínosný? Potom budeme refaktorovat po každém novém kousku kódu (praktika je doplněna testováním a párovým programováním, takže je neustálý refaktoring opravdu efektivní).

Je pravda, že v 90. letech, v době obrovských projektů s gigantickými rozpočty a ještě většími technickými dluhy, mohla být myšlenka “neustále refaktorovat” viděna jako extrémní. Je tomu tak ale i dnes?

Praktiky XP dnes

XP učí dobré vývojářské praktiky a jejich použití se společnost od společnosti liší. Pracujete-li skutečně agilně, hlídáte-li si technický dluh, zákazník je pro vás spolupracující partner, vývojáři jsou experti na slovo vzatí, pak vás zřejmě XP nic nového nenaučí. Buď tak, nebo jen žijete v agilní iluzi.

Většina firem, co znám, bohužel takto nefunguje. Zákazník tlačí na dodávku a tým se dostává do smrtelného cyklu “programuj, programuj, programuj”. Bouchá se kód, technický dluh se bude řešit potom. Párové programování by nás jenom zdrželo a průběžnou integraci se pokusíme zavést po dalším release. Nejdřív musíme fakturovat! Pak ten zbytek. Takže ano, pro většinu firem je dle mého názoru Extrémní programování extrémní i dnes.

Ultimátní blog

V březnu tento blog oslavil první rok. Když se dívám zpětně, nejdůležitější bylo vytrvat. V minulosti jsem blogů začínal nespočet.

Hlavní problém při blogování pro programátora je vydržet nekódovat, ale psát. V průběhu několika posledních let jsem zkoušel různé blogovací platformy (Kirby, Ghost), ale žádná mi plně nevyhovovala. Upravoval jsem design, javascript a nakonec si dokonce zkusil napsat vlastní CMS, což byla pro vývojáře jasná volba cesta do pekel. Nakonec mě nejvíce zaujal Jekyll hostovaný přímo na GitHub.com. Nedávno jsem zjistil, že pro neprogramátory a odpůrce Gitu existuje služba Forestry, která dělá commity za vás. Váš web na GitHubu může být od webu s plnohodnotným CMS k nerozeznání (až na to, že veškerou historii máte verzovanou).

Se vzhledem webu se stále nemohu smířit. Možná je dobrý. Možná stále vidím nějaká zlepšení. Ale snažím se psát, neprogramovat.

Jeff Atwood (Coding Horror), autor jednoho z nejnavštěvovanějších developerských blogů, popsal jediný krok, který je nutný k dosažení ultimátního blogového úspěchu. V tomto mu plně věřím - stačí jen jedna věc. Vydržet.

Po roce blogování bych se chtěl posunout dál. Psát častěji než každých 14 dní (fajn, kadenci Coding Horror 6 článků do týdne nezvládám). Psaní mě již nebolí, je to dokonce fajn relax a témat mám spousty. Jo, chtělo to rok. První rok je těžký.

Typy agilních koučů

Co kouč musí umět

Spojení “Agilní kouč” velmi zpopularizovala Lyssa Adkins ve své knize Coaching Agile Teams (rok 2010). Lyssa je velmi konkrétní v tom, co by měl Agilní kouč umět:

  • výborná znalost Agilních praktik,
  • profesionální koučování,
  • mentoring,
  • umět školit,
  • ovládat umění facilitace.

Kromě těchto základních dovedností má Agilní kouč obvykle jednu specializaci:

  • technické mistrovství,
  • obchodní mistrovství,
  • mistrovství v transformaci organizací.

PCA výcvik Obrázek: Agile Coaching Competency Framework

Typy agilních koučů

Technické mistrovství

Technický kouč se nesmí bát ušpinit si ruce. Jeho doménou je architektura, design, kódování, testování, technické praktiky, software craftsmanship. To vše v kontextu agilního vývoje. Technický kouč je schopen vést tým vývojářů příkladem a důkladně argumentovat k použití best practices tak, aby tým pochopil, proč to dělá.

Některá spojení praktik jsou silnější než jiná a mohou dohromady tvořit velmi efektivní metodiku (příkladem je Extrémní programování). Technický kouč by měl být také expertem na metodiky vývoje software a umět jednotlivé praktiky zasadit do vhodného širšího rámce.

Obchodní mistrovství

Mistrovství v businesse zahrnuje schopnost použít správnou obchodní strategii a modely řízení tak, aby se z agilního přístupu stala konkurenční výhoda (viz např. Lean Start-Up).

Mistrovství v transformaci organizací

Transformačních koučů mám na LinkedIn nejvíce. Ti nejlepší jsou velmi velmi velmi drazí. Ti začínající snad ani opravdovými kouči nejsou. Mistrovství v transformaci organizací zahrnuje schopnost facilitovat, katalizovat a vést transformaci celé organizace. Tato oblast se táhne skrz change management, firemní kulturu, rozvoj organizace, systémové myšlení a společenské vědy.

Chcete specializované kouče

Jedním z mých velkých Aha! momentů bylo uvědomnění, že kouč by se měl specializovat. Žádný člověk nemůže ovládat technické znalosti, držet krok s obchodními trendy a zároveň umět přetransformovat celou organizaci odshora až dolů. Mně jsou technické znalosti nejbližší, proto se rozepíšu o nich.

Na sociálních sítích i některých blozích se až příliš často setkáte s názorem, že Agilní kouč by měl ovládat všechny oblasti agilního vývoje. Pokud jde o vývojářeské praktiky, obvykle se zmiňuje TDD a že stačí, pokud o takové praktice kouč ví a nasměruje tým správným směrem.

Myslím, že přesně takové články píší lidé bez hlubších technických znalostí. Kvalita software se nezlepší jen tím, že vývojáři začnou psát nějaké testy. Roy Osherove, autor knihy The Art of Unit Testing, přímo říká: Žádné unit testy jsou lepší než špatné unit testy. Donutíte-li dělat TDD tým, který to neumí, je to horší, než kdyby žádné testy nepsali. A vývojáři obvykle ani nevědí, že dělají něco špatně.

Podobně bych mohl pokračovat s dalšími agilními praktikami, jejichž povrchní pochopení produktu nepomůže. Proto se koučové specializují.

Role jsou kompromis, ne limity

Nedávno jsem se zúčastnil zajímavé diskuze na téma rolí v týmu. Kolega vysvětloval, že role (ať v týmu nebo ve firmě) jsou ve skutečnosti kompromis, proto nesmí limitovat to, co člověk může dělat nebo to, na co má pravomoce.

V dokonalé firmě je každý člověk dokonalý. Každý zaměstnanec je výborný vývojář, rozumí produktu, umí řídit projekt a zná záludnosti marketingu. Možná takových lidí na světě pár existuje, ale určitě jich není dostatek, aby mohla každá firma zaměstnávat jen dokonalé lidi.

Takže firmy dělají kompromisy. Najmou výborného vývojáře a řeknou mu, že bude především programovat. O marketing se postará někdo jiný, kdo rozumí dobře marketingu. Co když se ale najde někdo, kdo je na jednu stranu výborný vývojář, ale může být také přínosem pro produkt? Řeknete takovému člověku, že “tohle není jeho role”, nebo si jeho nápady poslechnete?

Asi před rokem jsem jednoho takévého člověka potkal v coworkingovém centru. Web designer Michal mi řekl svůj příběh, jak jedné malé fimě, pro kterou ještě nedávno pracoval, málem domluvil novou zakázku. Když si ho šéf pozval do kanceláře, čekal pochvalu. Naopak dostal pořádně vynadáno: “Domlouvání kontraktů není tvoje starost!” Michal firmu opustil a dál se živí jako freelancer.