Několik lidí mě požádalo o text mé přednášky na téma Design svobodné firmy, kterou jsem přednesl v úterý 24. dubna 2012 na Setkávání ke svobodě v pražském Hubu. Zde je její text. Popisuji v něm, čeho se podařilo dosáhnout ve firmě Netsafe Solutions a poskytuji své vlastní zamyšlení nad svobodnými principy.

Dobrý večer, moje jméno je Martin Pavlas. Někteří z vás mě a mojí práci znají ze stránek think-forth.com, kde píšu články zabývající se budováním zdravých pracovních prostředí.

Dnes večer bych vám chtěl vyprávět příběh o společnosti Netsafe Solutions. To jest o společnosti, ve které se mně a jejím zaměstnancům podařilo vytvořit prostředí, v němž se snoubí kvalitní a efektivní práce s principy svobodné a názorově otevřené společnosti.

Co je na Netsafe zajímavé, je fakt, že jsme se nepokoušeli primárně budovat svobodnou firmu. Naším cílem bylo zvládnout poměrně velký a komplikovaný softwarový projekt s relativně malým týmem zaměstnanců, navíc rozděleným do dvou různých lokalit. A to sice Prahy a holandského Amsterodamu.

Abych nastínil rozsah celého projektu, pouze zmíním, že se jedná o internetový platební portál s ročním obratem okolo 1.5 miliardy korun. Firma má licenci a dodržuje pracovní postupy Holandské Národní Banky a finální produkt a služba prochází pravidelnými audity společností Visa a MasterCard. Toto zmiňuji hlavně proto, že často slýchám názor, že svobodné principy nemohou být v takovém prostředí aplikovány.

Pokud kdokoliv přijme mýtus, že svobodu v práci lze mít jen v určitých typech firem a za určitých podmínek, sám si staví barikádu, která mu tím směrem brání jít.

Ještě dneska si živě vzpomínám na dobu, kdy jsem si krátce po založení Netsafe kreslil obrázky hierarchie společnosti a vymýšlel, kdo bude co dělat. Celý model nápadně připomínal aparát generálního ředitelství Českých drah, kde jsem dříve pracoval nebo církevní establishment s jedním Bohem nahoře a všemi těmi apoštoly, archanděly, biskupy a faráři pod ním.

Bohužel tento model si vylámal všechny zuby krátce poté, co jsme ze dne na den převzali projekt s milionem řádků zdrojového kódu softwarové aplikace a milionem defektů, který v každé minutě zpracovával několik platebních operací. Bylo jasné, že musíme přijmout velké množství nových zaměstnanců, a tím tento model posvětit, nebo začít pracovat odlišným způsobem.

Jako člověk, který se zabýval lodním designem, jsem se rozhodl přenést iterativní postup vytváření plánů lodě do oblasti vývoje software a na náš projekt.

V iterativním pojetí práce se pracuje na malých, časově omezených projektech s jasným cílem a výsledky práce se ihned integrují do celého systému. Hned poté, co je taková malá část dokončena a použita, dochází k reflexi toho, jaký má vliv na celek, co je další nejužitečnější krok, který by měl být proveden, jak vlastní práce probíhala z pohledu všech zúčastněných a co by šlo v další iteraci udělat lépe či jinak.

O něco později jsem zjistil, že pouze znovu vymýšlím kolo. V té době se už na mnoha místech používaly podobné, takzvané agilní techniky jako je scrum, kanban nebo ucelený systém nazývaný lean.

Všechny tyto frameworky sdílí několik zdravých principů. Hlavními z nich je sebe a samo organizace týmů a jednotlivých zaměstnanců, vysoká míra delegace zodpovědnosti, rozhodování a volnosti na zaměstnance, kteří danou práci dělají a tím pádem jí i nejvíce rozumí. Dále poskytují prostor na průběžné reflektování a úpravy způsobu práce právě těmito zaměstnanci, místo aby jim bylo ze shora říkáno, jak mají pracovat. Je až neuvěřitelné s jakým zápalem a energií jsou lidé ochotni řešit efektivitu své práce, je-li jim k tomu dán prostor a čas. Je neuvěřitelné, jak obrovský vliv to zpětně má na kvalitu jejich práce a zároveň pocity, které při tom zažívají.

Pokud věříte tomu, že lidé jsou motivováni k práci penězi, já bych oponoval tím, že daleko větší motivací je pro ně pocit vlivu na celý projekt, respektování jejich názorů a jich samých, poskytnutí jasného signálu, že jsou součástí většího, dobře fungujícího celku, který na ně klade – nebo ještě lépe – kde oni sami na sebe kladou zvládnutelné cíle. Každý zvládnutý cíl se pak stává malým vítězstvím a velkou odměnou, pro ně samé i pro vás jako zaměstnavatele. Samozřejmě je nutné zmínit, že toto bude fungovat za předpokladu, kdy budou adekvátně finančně zabezpečeni.

Abych byl trochu konkrétnější, popíšu vám v rychlosti průběh jedné iterace v Netsafe.

Na začátku jakékoliv práce je požadavek na úpravu aplikace nebo odstranění nějakého problému. Ten přichází buď od našich zákazníků nebo si ho sami vymyslíme. Takový požadavek by měl vždy být v souladu s dlouhodobější vizí našeho produktu. To, jestli tomu tak je, není řešeno pouze nějakým produktovým manažerem. Naopak, diskuse se může zúčastnit kdokoliv z firmy, koho to zajímá. Takových požadavků existuje vždy hned několik najednou, takže se zároveň řeší i pořadí v jakém se na nich bude pracovat. Primárně z pohledu užitečnosti a smysluplnosti požadavku. Často se při téhle plánovací diskuzi některé požadavky zahodí nebo se vytvoří nové.

Jelikož se diskuze zúčastňují lidé, kteří na tom budou později pracovat, mají obrovskou šanci pochopit důvody, proč má být děláno právě to, co leží na stole a mají možnost ovlivnit, zdali k tomu vůbec dojde. Dále jim to umožňuje vědět, na čem se bude pracovat v horizontu několika následujících týdnů.

Tyto plánovací diskuze se odehrávají průběžně, jednou nebo i vícekrát týdně. Požadavky jsou dále upřesňovány, mění se jejich pořadí podle aktuální situace, mohou být odstraňovány nebo přidány nové.

Jakmile je požadavek umístěn na pořadníku, je dále týmem průběžně upřesňován a postupně se vytvoří popis toho, jak bude aplikace vypadat a jak se bude chovat, až bude práce na požadavku dokončena. V této fázi nikdo nevymýšlí, jak bude nebo by měla být vlastní práce provedena. To je plně delegováno na tým, který bude na požadavku pracovat.

Kdykoliv má některý tým kapacitu pracovat na něčem novém, sám si vezme požadavek, který je na prvním místě v pořadí. Ještě jednou si všichni ověří, že plně chápou, co má být uděláno, a dohodnou se, jak dlouho na tom  budou pracovat. Poté společně vytvoří x kartiček popisujících úkony, které je potřeba provést k dokončení práce na požadavku. Od tohoto okamžiku je práce plně pod kontrolou týmu.

Členové týmu pak pracují na úkonech popsaných na kartičkách. Sami si určují v jakém pořadí a jakým způsobem. Minimálně jednou denně se schází na krátkých 15-ti minutových poradách, kde si sdělí, jak jim práce jde – takzvaných kolečkách. Zároveň si pomocí jednoduché metody zvedání palců vyjadřují, zda práci na požadavku stihnou dokončit v naplánovaném čase.

Kdykoliv kdokoliv z týmu má pocit, že to nejde stihnout nebo potřebuje mluvit s ostatními, může celý tým zastavit a svolat další kolečko. Kdokoliv také může vyjádřit jakýkoliv pocit na takzvaném frustration boardu. Cokoliv, co se mu nelíbí nebo naopak.

Celý pracovní systém dále garantuje, že tým má každých čtrnáct dní jedno odpoledne vyhrazené na takzvanou retrospektivu. Na té se řeší vstupy z frustration boardu nebo jakékoliv jiné téma ohledně způsobu práce. Výstupem retrospektivy je vždy alespoň malá úprava způsobu práce nebo pracovního prostředí. Buď je posíleno něco, co fungovalo dobře nebo se zkusí dělat jinak něco, co tak dobré nebylo.

Každý zaměstnanec má zároveň možnost udělat pro ostatní přednášku na jakékoliv téma. Účast na přednáškách je opět dobrovolná. Firma dává k dispozici až jednu hodinu denně, čtyřikrát v týdnu. Přednášky jsou hojně využívány a většinou jsou dost kvalitní.

Původně jsme tento čas věnovali společnému čtení a diskutování odborné literatury. Přednášky se ale ukázaly být efektivnější a zábavnější.

Mohl bych pokračovat dál ve výčtu toho, co v Netsafe děláme, ale to bych přesáhl časový limit přednášky… ještě bych se rád zamyslel nad něčím obecnějším….

Pokud se vám takové pracovní prostředí podaří alespoň z části vytvořit, dříve či později dojde k něčemu, co vás může překvapit nebo možná i zaskočit, protože na to nebudete připraveni. Ze zaměstnanců se vám stanou lidé. Lidé, kteří se scházejí na jednou místě kvůli společnému cíli. Lidé, kteří na toto místo začnou přinášet svá přání, problémy, své silné i slabé stránky. To se samozřejmě děje na každém pracovišti, ve svobodně fungující firmě to ale nejde tak jednoduše ignorovat nebo potírat.

Jedním z hlavních témat a možná tím nejhlavnějším se proto stane mezilidská komunikace v tom nejširším slova smyslu. Techniky, jak technicky zvládnout práci, už budete umět. Budete se ale muset mnohem více věnovat tomu, jak spolu jednat, mluvit, neskrývat své názory, přiznat chybu, nemanipulovat ostatní, být schopni dojít k závěrům a rozhodnutím jako skupina lidí. Komunikace je natolik zásadní věc, že z mého pohledu ji není možné nechat pouze na zaměstnancích s tím, že oni si to nějak dají dohromady. Jakákoliv skupina zaměstnanců by měl mít k dispozici interního kouče, který proces učení se komunikovat zastřešuje.

Interní kouč je moderátorem retrospektiv, každodenních koleček. Téměř neustále poslouchá svůj tým a kdykoliv se  zaměstnanci zaseknou, dostanou do sporu nebo izolovaně řeší něco důležitého, pokusí se zajistit, aby proběhla úspěšná a hlavně užitečná komunikace. Nejen, že tak pomůže vyřešit konkrétní problém, navíc ukazuje ostatním, jak problém řešit příště a tím posiluje sebeorganizaci celého týmu. Jinými slovy, příště to tým vyřeší sám nebo se do takové situace vůbec nedostane. Jelikož pestrost lidí a jejich povah na pracovišti je obrovská, není interní kouč nějaký přechodný post. Naopak, je to důležitý člověk, který se stará, aby tento proces neustále pokračoval a byl držen mezi rozumnými mantinely.

Dosud jsem mluvil o komunikaci a vlastně ovšem jakoby z ptačí perspektivy. Z pohledu zaměstnavatele, který kouká na vše ze shora, a kterého se to možná moc netýká. To by bylo špatné. Ono by to vlastně asi ani moc nefungovalo. Chcete-li budovat svobodnou firmu, musíte začít u sebe nebo už to v sobě musíte mít.  Musíte žít s týmem svých zaměstnanců a svým způsobem musíte být jedním z nich.

Vidím to tak, že zaměstnavatel je vlastně pouze další zaměstnanec, který má jen jiné povinnosti. Někdo ve firmě programuje, jiný vytírá chodbu, další dává dohromady vizi produktu a tak dále.

Pokud budete chtít svobodu v práci prvoplánově využít ve svůj prospěch na úkor druhých, nebude to fungovat. Kdyby to náhodou fungovalo, nevytvořili jste svobodnou firmu, ale svobodného zaměstnavatele.

Já sám mám na toto téma velice zvláštní zážitek. Před nějakou dobou mě známý upozornil, že jsem vytvořil super efektivní manufakturu. Myslel, že mi tím skládá poklonu, mě tím však zásadně vyděsil. V ten okamžik jsem si uvědomil, že tímhle způsobem pracování jsem skutečně schopen vymáčknout z lidí obrovský výkon, a že bych mohl jít ještě dál. Jenže to by byl pro mě skok od svobody ke zneužívání. Přirozenou reakcí na jeho prohlášení byla diskuze na toto téma se všemi zaměstnanci. Z diskuze vyšel systém volných pátků – takzvaných project days, kdy si lidé mohou pracovat na vlastních projektech a bylo poskytnuto více času na vzdělávání a interní přednášky.

Osobně to nazývám koncept trvale udržitelného tempa. Pokud má něco dobře fungovat, a pokud to něco má být schopno občas podat vysoký výkon, musí to většinu času jet na optimální otáčky.

U auta nám to je jasné, u provozování firmy už to občas pokulhává. Často máme pocit, že jde o to, jet pořád na plný výkon. Je důležité si uvědomit, že toto je jen další mýtus. Mýtus natolik silně zakořeněný v nás všech, že se stal společenskou realitou. Chodíme do práce podávat výkon.

Naprostá většina z nás tráví v zaměstnání osm a více hodin denně, pět a více dní v týdnu. Pokud se tam budeme chovat jako na výkon orientované stroje, pokud nás to tam nebude bavit, pokud tam nebudeme mít lidi, které máme rádi, mrháme obrovskou částí svého života…

Díky za pozornost.

Těsně před začátkem pražského Coderetreatu jsem se ptal několika přítomných programátorů na jejich zkušenosti s párovým programováním. K mému překvapení byly minimální, v následné diskusi většinou zazněl názor, že v reálné práci “u nás ve firmě” tato technika použít nejde. Pak následoval vlastní Coderetreat, během něhož se muselo povinně pracovat v páru. Myslím, že řada přítomných radikálně změnila názor na praktickou použitelnost a efektivitu této techniky. Rád bych se tě, Mariane, jako velkého zastánce párového programování, zeptal na pár otázek, které mohou zajímat všechny vývojáře a team leadery, kteří si pohrávají s myšlenkou párové programování použít.

Martin: Jak bys několika slovy popsal, co vlastně párové programování je?

Marian: Párové programování je jedna ze základních technik XP (Extrémního Programování), při které sedí u jednoho počítače dva programátoři a pracují na jednom úkolu společně. Tomu, kdo programuje, se říká řidič a druhý má roli navigátora. Úkolem navigátora je přemýšlet o problému z většího odstupu, než je schopen samotný řidič. Ten naopak řeší konkrétní implementaci jednotlivých částí.

Martin: Jaké jsou podle tebe největší výhody práce v páru?

Marian: Jednou z výhod je již zmíněný odstup navigátora. Dost často se stane, že se v průběhu řešení komplikovaného problému řidič ztratí, případně zasekne. Někdy jde o malé záseky jako chybějící středník, obrácená podmínka, prohození parametrů. Myslím, že většina z nás programátorů zažila situaci, kdy jsme dlouho hypnotizovali nefunkční kus kódu, který jsme právě napsali. Rychlým řešením pro mě obvykle bylo požádání o pomoc kolegu. Již samotný akt vysvětlení (komunikace) problému někomu jinému mě často přivedl na cestu k řešení. Někdy zas stačil společný pohled do zdrojového kódu a chyba byla objevena v průběhu několika vteřin.

Právě rychlá a kvalitní zpětná vazba je během programování důležitá věc. Při párování stačí, když řidič řekne, co plánuje řešit nebo napíše kus kódu a navigátor mu může poskytnout jeho názor okamžitě. Největší výhodou to je v situacích, kde zná řidič několik potencionálních řešení nebo naopak nezná žádné, které by plně vyhovovalo.

Martin: Nemůžu si pomoct, to co popisuješ je z mého pohledu jen další aplikací Ashbyho zákona Law of Requisite Variety – řidič má vedle sebe kontrolní systém – navigátora… Na co by si měli dát programátoři při párovém programování pozor, hlavně v úplných začátcích?

Marian: Základem párování je již zmiňovaná komunikace. (více na téma komunikace ve článku Proč si nerozumíme). Pokud chce člověk s někým programovat v páru, musí s ním umět komunikovat. Zejména v začátcích bych doporučil párování jen s lidmi, se kterými si rozumím a jsem na stejné vlně. Jako u každé týmové aktivity je důležité mít schopnost akceptovat pohled, případně řešení toho druhého, minimálně v takové míře, že jsem ochoten zkusit jinou cestu.

Pozor by si měl dávat hlavně navigátor. Jeho role není být pouhým přísedícím, který kouká na to, jak ten druhý programuje. O tom, na čem se pracuje, by měl mít stejný nebo lepší přehled než řidič. Jeho úlohou je koukat dopředu a přemýšlet o práci v rámci většího celku, systémově. Ideální je když si navigátor udržuje seznam kroků, které jsou potřeba k dokončení úkolu. Řidič se pak může 100% soustředit na implementaci. Pokud se navigátor ztratí, případně neví, co dělá řidič, měl by to s ním okamžitě konzultovat. Jinak se z něj stává již zmíněný pouhý přísedící.

Martin: Hodně lidí si myslí, že párové programování sice přináší výhody jako je přenos zkušeností, zlepšení komunikace, ale považují ho za méně efektivní způsob práce. Jednoduše řečeno dva vývojáři dělají práci, kterou by mohl udělat jeden. Co si o tom myslíš ty?

Marian: Záleží, co si člověk představuje pod efektivitou práce při vývoji SW. Omezení párového programováni je to, že v jeden okamžik může psát na klávesnici jen jeden člověk. Programování ale není jen o psaní. Pokud by tomu tak bylo, pak bychom každý den vytvářeli tisíce řádek nového kódu.

Z mé zkušenosti větší část aktivity programátora tvoří pochopení zadání úkolu, zjišťování kde a jakým způsobem provést danou změnu a zároveň reagování na nově zjištěné skutečnosti, které získá pohledem do stávajícího kódu. Programování je vlastně řešení větších nebo menších záseků a to jde v páru mnohem lépe. Jejich výraznou eliminací pak pár získává prostor (a zároveň i sílu) dělat svou práci kvalitněji.

Důsledkem párového programování je i větší koncentrace na samotnou práci. Odpadá jakákoliv aktivita (email, FB, Twitter), která nesouvisí s úkolem, protože je jasné, že by byla pro toho druhého ztrátou času. Při intenzivním párování na to člověk vlastně ani nepomyslí.

Martin: Je nutné dělat code review na zdrojový kód napsaný párem?

Marian: V první řadě záleží na složení páru. Dva junioři určitě uvítají pohled seniora. Dále se může stát, že pár mění část softwarového systému, kterou zná lépe někdo jiný z týmu. V takovém případě dává smysl požádat konkrétního člověka o finální review. V neposlední řadě stojí za to, udělat review i v případě, když pár vytvoří základy nové funkcionality, na které bude stavět zbytek týmu. Pak dává smysl, aby se na to podívali všichni ještě před integrací do hlavní vývojové větve.

U běžných úkolů, ale dodatečné review potřeba není, protože přináší jen malou přidanou hodnotu, pár může integrovat svou práci okamžitě po jejím dokončení.

Martin: V Netsafe Solutions, kde pracuješ, se páruje docela intenzivně. Udělali jste nějaká speciální opatření nebo změny, aby se vám v páru pracovalo lépe?

Marian: Dlouhou dobu nám vyhovovalo párování u běžných pracovních stanic, v poslední době ale zkoušíme experimentovat a proto jsme zřídili dedikované párovací stanice. Ty poskytují dostatek prostoru pro dvě klávesnice, dvě myši, velký monitor a psací potřeby. U běžných stanic měl klávesnici a myš jen řidič a to komplikovalo navigátorovi život v situacích, kdy bylo jednodušší vyjádřit myšlenku pomocí kódu než slovně. Tento nový setup nám dále umožňuje využití pokročilých technik jako je třeba Ping-Pong TDD.

Martin: Jsou situace, kdy bys párování nedoporučil nebo zakázal?

Marian: Pokud se najdou dva lidi, kteří chtějí párovat, tak podle mě nedává smysl něco zakazovat nebo nedoporučovat. Samozřejmě jsou i přímočaré úkoly, u kterých musí programátoři sami zvážit, jestli jim to dává smysl. Každý z nás má hlavu a nohy, takže pokud v půlce úkolu zjistí, že to smysl nedává, je na místě párování ukončit.

Martin: Ze své zkušenosti vidím, že jedním z největších problémů při vývoji software je obrovská míra nedorozumění v komunikaci mezi vývojáři a dalšími členy týmů. Pomáhá párování tento problém řešit?

Marian: Práce programátora je z tohoto ohledu opravdu náročná. Na jedné straně musí správně interpretovat zadání – na straně druhé musí transformovat to, co pochopil do kódu, kterému musí rozumět počítač a zároveň i zbytek týmu.

Ne vždy se jedno nebo druhé povede správně a párové programování určitě pomáhá v tom, že vyžaduje neustálou komunikaci mezi řidičem a navigátorem. Co člověk – to jiný výklad zadaného úkolu. V situacích, kdy se řidič s navigátorem neshodnou na pochopení zadání je potřeba kontaktovat zadavatele nebo ostatní členy týmu.

Pokud programátor pracuje sám, může se snadno stát, že si zadání vysvětlí po svém, a v dobré víře dodá něco úplně jiného, než očekával ten, kdo úkol zadal.

Martin: Stalo se ti při párování něco, co tě vyloženě překvapilo, ať už pozitivně nebo negativně?

Marian: Před dvěma, třemi léty jsem si tu techniku neuměl v praxi vůbec představit. Nejvíc mě proto překvapilo jak lehké je začít a to, že to funguje. Teď jsou dny, kdy nepáruji spíš výjimkou.

Martin: Co tebe osobně k té technice přivedlo a proč tě tak zaujala?

Marian: Vlastně za to může můj kolega, kterému se při code review asi desetkrát vrátil kód, na kterém pracoval. Nakonec rezignoval a požádal o pomoc. Já jsem se přihlásil a společně jsme ten úkol dotáhli do úspěšného konce. Radost z dobře odvedené společné práce nejspíš zapříčinila to, že jsme párové programování začali provozovat častěji a zhruba po roce jsme do toho zatáhli i další členy týmu.

Martin: Kdybys měl od zítřka přísný zákaz párování, jak by ses cítil?

Marian: Takový zákaz mi přijde stejně absurdní jako zakázat pomáhání jinému členovi týmu. Neumím si takovou situaci představit. Asi bych měl pocit, že pracuji na hodně podivném místě.

Martin: Porušil bys ten zákaz?

Marian: Spíš bych řešil, jak ten zákaz zrušit nebo bych uvažoval o změně zaměstnavatele.

Jsme lidé a proto si často potřebujeme předávat informace. Řečeno jinými slovy, potřebujeme někomu nějakou informaci sdělit nebo ji naopak zachytit a pochopit. Dejme tomu tento text. Jestli vaše první reakce je: “to je přeci jednoduché”, prosím, čtěte dál. Celá věc je mnohem komplikovanější než se může na první pohled zdát…

Minulý pátek jsem byl na Svobodomyslném Workshopu, který pořádal Petr Skondrojanis z LMC. Vraceli jsem se tam k tématům diskutovaným na Setkávání ke svobodě, ale ať jsme šli jakýmkoliv směrem, zavedlo nás to k firemním kontextům a ke komunikaci. Petr sepsal zápisky ze setkání a zároveň se v nich hodně zabýval právě kontexty. Já bych se dnes chtěl zamyslet naopak nad komunikací. Můj minulý článek Frustration Board sklidil poměrně pozitivní ohlas, věřte ale, že bez lidí, kteří budou umět a budou ochotni rozumně a aktivně komunikovat, jeho přínos bude minimálně diskutabilní.

Psát o komunikaci je obtížné, začnu proto tedy u obecných poznatků z oblasti komunikačních teorií a postupně přejdu k praktické aplikaci v pracovním prostředí.

Paralely ke hrám

Existují různé způsoby, jak můžeme na komunikaci mezi lidmi nahlížet. Popíši zde tři pohledy, které k tomu používají paralely k různým hrám.

Komunikace jako bowling… Tato paralela chápe toho, kdo chce sdělit nějakou zprávu, jako hráče bowlingu, který vrhá kouli. Sdělovaná zpráva je tou koulí. Koule je vržena na dráhu (komunikační kanál) s cílem zasáhnout co největší počet pasivních kuželek (příjemce zprávy). V tomto jednosměrném pojetí komunikace je předpokládáno, že sdělující (hráč) je schopen vytvořit jednoznačnou zprávu (kouli) pro daný účel sdělení tak, aby byl opakovaně a kýmkoliv pochopen její význam (koule zasáhla kuželky). Paralela k bowlingu je asi nejběžnější způsob chápání komunikace a vychází z obecného pocitu, že slova mají jasně určený význam. Osobně si myslím, že tento přístup je poněkud nešťastný a přináší spoustu zásadních nedorozumění. Největší slabina této paralely tkví v tom, že příjemce zprávy je chápán pouze jako pasivní prvek.

Komunikace jako ping-pong… Chápat komunikaci jako ping-pong je o něco lepší analogie než bowling. Už jen proto, že to není hra s pouze jedním aktivním hráčem. Podávající (sdělující) odehrává míček (zprávu) s určitým záměrem, o kterém přijímající v ten okamžik ještě neví. Přijímající reaguje až pozorování příchozí zprávy a je-li tato zpráva nějak pochopena, snaží se vracet svou odpověď zpět přes síť. Role podávajícího a přijímajícího se neustále střídá. Stejně jako verbální a neverbální komunikace, míčky mohou být přímé nebo s falešnou rotací… Bohužel, ani tato paralela není dokonalá. Při komunikaci hráči v jeden okamžik nehrají jen s jedním míčkem jako v ping-pongu, ale s mnoha míčky najednou. Další rozdíl představuje fakt, že při komunikaci by měli hráči hrát spolu a ne proti sobě. Měli by se snažit odehrát míček tak, aby ho protihráč mohl, co možná nejlépe přijmout.

Komunikace jako hra Aktivity… Pro účely pochopení dalšího textu je toto asi nejlepší paralela. Hráči se při této hře snaží odhadnout, co se jim předvádějící snaží sdělit. Sdělující sleduje reakce ostatních a koriguje svůj projev tak, aby jeho spoluhráči co nejrychleji a nejlépe uhádli předváděnou aktivitu. Vzniká zde komunikační transakce mezi všemi zúčastněnými. Sdělující i přijímající hráči se podílí na komunikaci stejně aktivně a společně se snaží o co možná nejvyšší míru vzájemného porozumění.

Co člověk to jiný vesmír

Před tím než začnu psát o tom, proč si nerozumíme a co s tím případně dělat, jak sliboval nadpis článku, musím napsat pár slov o vnímání, interpretování a vytváření obrazu reality v naší mysli.

Realita existuje v našich myslích. Co člověk, to jiná instance reality, neboť každý z nás si ji během svého života vytváří. Tato realita je postavená na informacích, které se k nám dostávají a na tom jakým způsobem my tyto informace integrujeme do naší vlastní, již existující, představy reality. Realita je tak systémem navzájem propojených symbolů popisujících vnější svět i nás sama sebe. Tyto symboly vytváříme sami pro sebe a jejich význam je velice specifický pouze pro nás samotné. Jiný člověk může podobný symbol prožívat velice odlišným způsobem. Slovo otec v sobě určitě nese obraz rodiče mužského pohlaví, pro někoho s tím navíc přicházejí pocity pohody a blízkosti, pro jiného pocity strachu…

Na jazyku, kterým komunikujeme je specifické právě to, že slova jsou pouze sekvence zvuků. Slova sama o sobě nemají žádnou přímou spojitost s tím, co popisují (až na vyjímky, které replikují určité zvuky… “prásk”, atd). Význam k těmto slovům – zvukům si každý z nás přiřadil sám. Právě proto význam jednoho slova může být pro různé lidi velmi odlišný.

Vznik nedorozumění

Pojďme si popsat možný proces, který se odehrává při komunikaci. Když chceme někomu něco sdělit, zaměříme svou pozornost na část naší reality, které má být sdělena druhé osobě. Kdyby bylo možné tento obraz bezchybně přenést přímo do představy reality druhé osoby, byla by spousta věcí v našich životech o dost jednodušší. To ale bohužel nejde. Musíme k tomu tedy použít nástroj, kterým svoje sdělení popíšeme a zároveň nám umožní informaci fyzicky přenést od sdělujícího k příjemci. Tím nástrojem je již zmíněný jazyk. V okamžiku, kdy tento nástroj začneme používat, začíná docházet ke zmatení – konfůzi.

Ten, kdo předává své sdělení ho formuluje už ve své mysli právě pomocí jazyka a na základě všech svých kontextů (souborů symbolů tvořící jeho obraz reality). Tento vnitřní rozhovor sama se sebou už začíná limitovat možnost vyjádřit přesně to, co bychom chtěli. V následující fázi pak začneme sdělení formulovat pomocí slov, která budou skutečně vycházet z našich úst a budou cestovat k druhé osobě. Sdělení se bude dále měnit, protože budeme omezeni svou znalostí jazyka, etiketou a dalšími redukujícími elementy. K přidávání konfůzních prvků bude docházet i čistou mechanikou mluvení, například špatnou výslovností, vadami řeči. Poté zvuk našich slov cestuje vnějším prostředím k uším toho, kdo nás poslouchá. Nemusím asi říkat, že i v této fázi se zpráva může ještě více zdeformovat, například okolním hlukem.

V okamžiku, kdy zvukové vlny rozhýbou bubínky posluchače, začíná proces zpětného dekódování zprávy. Není to ale přesně ta zpráva, kterou vysílající původně chtěl vyslat, jsou to jen zvuky hlásek a neverbální symboly, které se podařilo přijímajícímu zachytit. Při zpětném dekódování zprávy dochází k dalším změnám významu. Na straně příjemce hlavně kvůli konstruování významu sdělení na základě jeho vlastních kontextů. Tyto kontexty jsou vždy jiné než kontexty toho, kdo zprávu sděluje. K úplnému porozumění by bylo potřeba omezit všechny redukce a šumy k nimž při komunikaci dochází a příjemce by musel znát všechny kontexty vysílajícího. Toto však není možné a z tohoto důvodu je dobré jakoukoliv komunikaci chápat jako větší či menší nedorozumění. K úplnému pochopení druhého nemůže v principu dojít.

Dosud jsem psal převážně o přímé komunikaci. Nemusím asi zmiňovat, že při jakémkoliv jiném způsobu komunikace, například telefon, email nebo chat, se celá situace ještě dále zhoršuje. Smutným paradoxem je fakt, že lidé vytvořili internet, medium založené na bezchybné nebo samoopravující se komunikaci technických přístrojů, který z části slouží k šíření konfůze mezi lidmi.

Praktické využití?

Jako nadřízení a kolegové si buďte vědomi toho, že vaši podřízení a kolegové mohou vaše slova, emaily, dokumenty chápat jinak než jste zamýšleli. Pokuste se zvýšit míru přímé osobní komunikace. Při přímé komunikaci se mnohem lépe zúčastněným interaguje a snáze eliminují míru nedorozumění. Dobrou pomůckou je ověřování, to jest požádat druhého, aby nám řekl svými slovy, to co jsme se mu právě snažili sdělit.

V pracovní praxi často lidé dělají chyby nebo chybná rozhodnutí ne proto, že byli hloupí nebo líní, ale jednoduše protože dělají něco jiného než po nich někdo jiný chtěl. Pracují na vlastní interpretaci toho, co zaslechli.

Synchronizační schůzky

Interní koučové a mentoři by měli vést lidi k tomu, aby místo bezradného bloudění v problémech o samotě dali přednost komunikaci o problému s kolegy v prvním možném okamžiku, kdy cítí, že potřebují pomoc. Pro některé lidi je toto obtížné. Zde výborně pomáhají rituály denních koleček (daily standups, cocktail parties, daily meetings), tedy informálních setkání všech členů týmu za účelem sdílení informací. Typickou náplní kolečka je výměna informací o tom, co každý ze členů týmu udělal od posledního kolečka, čemu se bude věnovat do příštího kolečka a jestli ho něco brzdí v jeho – její práci. Kolečko by mělo být časově limitováno. Tým o šesti zaměstnancích si dokáže sdělit vše důležité během méně než 15 minut.

V poslední době jsem začal na kolečka chodit v roli pozorovatele (pilota) nebo tam pozorovatele posílám. Jeho úkolem je naslouchat a číst mezi řádky. Někteří lidé umí určité věci sdělit, jiní to neumí, například mluvit o tom, že si s něčím neví rady. Úkolem pozorovatele je jim s tím pomoci. Věta “pracuji na tom už druhý den, jde to pomalu, ale snažím se”, může být chápána členy týmů jako čistý popis aktivity a nemusí ji věnovat větší pozornost. Pozorovatel však může nahlas říci: “a je to pouze zdlouhavá práce nebo bys s tím chtěl od někoho pomoci?”. Samozřejmě, cílem této aktivity je předání pozorovatelových schopností všem členům týmu.

Information handovers

Minimalizujte počet kol předávání určité informace (information handover). A to mezi patry hierarchicky organizované společnosti, mezi různými odděleními, mezi jednotlivými zaměstnanci ve formě postupně padajících kostiček domina. Při každém předání totiž dochází k posunům významu skrze kontexty sdělujícího i přijímajícího. Meeting skupiny lidí, kde jsou zastoupeni všichni, kdo by se měli nebo mohou k diskutovanému tématu vyjádřit zásadní mírou zvyšuje šanci, že si celá skupina vytvoří společný obraz toho, o čem se jedná. A pokud i přitom dojde k posunu významu diskutované záležitosti, jsou tomu všichni přítomni.

Lepší osobně než elektronicky

Přesto, že se na nás ze všech stran valí dokonalé project management, issue tracking a collaboration nástroje, preferujte přímou osobní komunikaci kdykoliv je to možné. Naučte se vstávat od svých pracovních stolů a choďte za svými kolegy a ptejte se jich. Jděte v této aktivitě ostatním příkladem. Dejte jasný signál zaměstnancům, že i oni mohou svolat krátké porady, kdykoliv cítí, že je to potřeba. Pokud skutečně z nějakého důvodu musíte používat elektronické nástroje, používejte je spíš k tomu, aby zrcadlili diskuze a jejich závěry, které probíhají ve vašem pracovním prostoru. Nenechte je stát se jediným místem, kde se lidé dozvídají, na čem mají pracovat a kde se tomu snaží porozumět.

Mezinárodní prostředí

Ve společnosti, kde pracují lidé z různých kulturních prostředí a kde se komunikuje různými jazyky, je zapotřebí v komunikaci ještě více opatrnosti. Různá kulturní prostředí přichází s odlišnými kontexty v oblasti etiky, chápání dobrého-špatného, s odlišnou představou, jak probíha pracovní den a spoustou dalších rozdílů. Problémy, které z toho mohou vzniknout, jsou často zcela zásadní. Stejně tak používání cizího jazyka většinou redukuje možnosti sdělujícího formulovat zprávu podle svých představ a stejně tak je přijímající limitován při konstruování významu, toho co slyší.

Zbořte zdi. A to jak ty fyzické, tak ty virtuální. Firma konec konců není nějaká zhmotněná struktura, je to společenství lidí a lidé z velké části existují právě skrze vzájemnou komunikaci a interakci. Co potřebujete, je zaměstnance naučit nebát se mluvit a ptát se. Běžte jim příkladem…

Závěrem bych chtěl podotknout, že tento článek nemá ambice jít dále než nastínit hrubé rysy problematiky mezilidské komunikace a jejího dopadu pracovní proces. Tento text a můj vlastní pohled na komunikaci vychází z interpretativních škol komunikačních teorií.

V článku o svobodné firmě jsem přislíbil, že se pokusím rozepsat na téma technik, které mohou vylepšit komunikaci mezi lidmi, kreativitu a obecně přístup k práci. Frustration board je nástroj, který jsem vytvořil společně s kolegy ze společnosti Netsafe Solutions a jeho hlavním smyslem je dát zaměstnancům jasný signál, že i oni mohou řídit dění ve firmě.

Na lednovém Setkávání ke svobodě jsem byl překvapen tím, kolik lidí chápe svobodu-zodpovědnost jako něco, co zaměstnanec buď má nebo nemá. V následných diskuzích pak často zazníval názor, že primárně jde o to, takové (svobodné) lidi hledat a průběžně se těch nezodpovědných zbavovat. S tímto názorem nesouhlasím. Jsem přesvědčen, že každý člověk přichází na tento svět se schopností a touhou žít svobodně. Tím pádem je možné tuto schopnost dále rozvíjet. Pokud byla během života poškozena výchovou v rodině, vzděláváním ve škole, přístupem k práci v předchozích zaměstnáních, je možné ji rekonstruovat. Frustration board je jednoduchý nástroj, který může tomuto procesu pomoci.

Frustration board je místo, kam může kdokoliv z firmy vyvěsit kartu s textem popisujícím cokoliv, co se danému člověku nelíbí. Vyvěšení kartičky by neměla být první reakce na setkání se s něčím nepříjemným. Naopak frustration board popisuji jako místo, kam problém umístím až poté, co jsem vyčerpal všechny další možnosti. To jest, zkusil jsem problém komunikovat a řešit s kolegy, konzultoval jsem ho s mentorem – people leaderem, a tak dále. Jinýmy slovy, když s něčím nemůžu skutečně nic v daný okamžik udělat, tak to mohu vždy dát na Frustration board. Už samotný akt popsání problému a umístění na tabuli má svůj význam, tím to ale nekončí.

Frustration board nebude nikdy plně fungovat, pokud se s kartami, které na něm jsou, nebude nic dít. Zaměstnanci musí mít důvěru, že každá karta bude mít šanci být reflektována. Naopak, pokud tam karty budou pouze přibývat, stane se frustration board samotný jen další frustrací. Proces, který zaručuje reflektovaní karet nazýváme retrospektivou. Retrospektiva se koná každé dva týdny a datum následující retrospektivy je vždy všem zaměstnancům znám.

Při retrospektivě se sejde celý tým, celá firma. Meeting vede facilitátor, který má za úkol dbát na to, aby byla dodržována určitá pravidla (fáze restrospektivy, délka nepřesáhla dvě hodiny, rozumná komunikace  účastníků). Po krátkém úvodu jsou vyzváni zaměstnanci, co umístnili karty na frustration board, aby je představili ostatním. Případně, aby zodpověděli rychlé, upřesňující, zjišťovácí dotazy. Facilitátor hlídá, že dochází skutečně pouze k představování problémů a nedochází k diskuzím ohledně jejich řešení či popírání jejich platnosti. Během představování karet mohou zaměstnanci napsat a představit nové problémy, na které si právě vzpomněli nebo se inspirovali tím, co právě slyšeli.

Všechny představené karty se vyvěsí na tabuli. Často se tam sejdou karty popisující stejnou věc nebo karty, které spolu úzce souvisí.  Tyto karty se tým se společně s facilitátorem pokusí identifikovat a dát je k sobě tak, že tvoří skupinu karet popisující jeden problém. Pro další práci má taková skupina karet stejný význam jako samostatná karta.

Následně se hlasuje, kterým kartám nebo skupinám karet by se měla věnovat pozornost v druhé části retrospektivy, to znamená, které karty jsou chápány jako nejdůležitější. Většinou používáme metodu dot-votingu. Každý účastník má k dispozici dva magnety a muže je umístnit na kartu nebo karty, které právě on považuje za důležité. Dvě karty, které ziskají nejvíce hlasů postupují. Ostatní karty se rychlým způsobem projdou a buď se ke každé z nich udělá malé TODO a někdo si ji vezme na starost nebo se vyhodnotí jako nedůležitá či jednorázová událost a zahodí se. Případně se karta může vratit zpět na frustration board, to by se ale mělo stávat pouze zřídka. Po lednovém Setkávání ke svobodě určitě zkusím na dalších retrospektivách použít metodu Open Space k výběru karet, kterým se budou zaměstanci věnovat. Určitě dává větší možnost, řešit věci, které konkrétní zaměstnance nejvíce zajímají.

Druhou fázi retrospektivy nebudu popisovat příliš detailně, neboť ta si zaslouží vlastní článek. Takže pouze v krátkosti: nejdříve dojde ke zmapování problému nebo situace popsané na kartě, například formou vytvoření skupinové mindmapy, root cause diagramu, použitím metody 5-Whys. Poté se hledají konkrétní proveditelná řešení problému. Retrospektiva by měla skončit s jasným plánem, co by mělo být uděláno nebo děláno jinak, aby se stejná karta na frustration  boardu už nemusela v budoucnu objevit. Plán by měl představovat takovou challenge, kterou je tým skutečně schopen splnit. Vytvoření nerealizovatelného plánu nepřinese nic víc, než zklamání, pasivitu a pesimismus při dalších retrospektivách. Pokud je problém a tím pádem i jeho řešení příliš velké, plán by se měl soustředit pouze na první reálně proveditelné kroky, ne řešení problému celého. Naopak, úspěšně splněná challenge přináší pocit dodělané práce a vylepšení celého systému. To je stav, který ještě více motivuje k další iteraci vylepšování pracovního prostředí.

Facilitátor by měl dbát na to, aby si tým byl vědom toho, jestli je challenge zvládnutelná. Nejlépe v horizontu následujících dvou týdnů, to jest do další retrospektivy. Není to ale on, kdo říká, co se dá nebo nedá zvládnout. Jeho úkolem je vést tým k tomu, by se nad splnitelností plánu skutečně zamyslel.

Dalším důležitým úkolem facilitátora je hlídat, že nevznikají karty a řešení, která reprezentují běžnou práci. Například: “musíme dopsat tuto část aplikace, protože jsme to zase nestihli”. Důraz by měl být naopak kladen na to, aby se lidé na retrospektivách naučili řešit prostředí, ve kterém pracují a způsob, jakým v tomto prostředí pracují a komunikují. Například u právě zmíněného přikladu je lepší ptát se: “Proč jsme zase nestihli dodělat práci včas?”

Musí být frustration board plný pouze problémů? Nemusí a neměl by. Tým, který se naučí tento nástroj používat, brzy pochopí, že je dobré vytvářet i karty, které naopak popisují pozitivní události nebo nápady na zlepšení práce. Stejně jako se dá analyzovat problém a hledat jeho řešení, se může tým společně zamyslet nad tím, proč něco funguje dobře a jak toho ještě lépe využít nebo zda-li stejný dobrý přístup nejde využít i jinde. Název frustration board je proto zavádějící. Ze zkušenosti mohu ale říci, že je chytlavý, a že vetšina týmů má ze začátku mnohem větší tendenci primárně řešit právě jen frustrace.

Co všechno nás tedy frustration board naučí?

Zaměstnanci se postupně naučí chápat význam zachytávání jak negativních tak i pozitivních situací a procesů. Dále se naučí sdílet a otevřeně komunikovat své pocity, které kolem těchto událostí mají s ostatními.

Tým jako celek se postupně začne učit řešit svoje problémy sám. To je zásadní, protože právě členové týmu jsou ti, kdo jsou schopni najít nejlepší řešení – to oni dané problematice nejvíc rozumí.

Kdokoliv, kdo firmu nebo tým vede zjistí, že zaměstnanci jsou schopni vidět věci, které on sám(a) nevidí nebo vidět ani nemůže. Uvidí také, že zaměstnanci jsou schopni tyto problémy rychle a kreativně řešit. Toto zjištění by mělo vést k tomu, že tým získává ještě více autonomie a dochází k faktickému přesouvání zodpovědnosti za chod týmu přímo na tým. Pracovníci v týmu mají dobrou motivaci tuto zodpovědnost přijímat, neboť chápou, že to je zodpovědnost za věci, které se týkají jich samotných. Vidí ale také jasný signál, že jejich potřeby jsou reflektovány, že firma jim vychází vstříc při řešení a zajišťování požadavků vycházejících z retrospektiv.

Auto-regulační a samo-organizující systém, který skrze toto může vzniknout, většinově překonává centralizováné řízení.

A ještě trocha teorie na závěr…

Kromě výše zmíněného je frustration board v kombinaci s retrospektivou elegatním řešením, které pomůže firmám pokoušejícím se zavádět alternativní modely řízení jako je model horizontalní zodpovědnosti, holgrafické organizace nebo svobodné firmy.

Na jakokoliv firmu nebo organizaci se můžete dívat jako na systém, který může nabývat mnoha stavů. Čím komplexnější taková firma bude, čím složitější problémy bude řešit nebo čím vyšší míra chaosu tam bude vládnout, tím více možných stavů (takového systému) bude existovat. William Ross Ashby, jeden ze zakladatelů moderní kybernetiky, definoval zákon Law of Requisite Variety. Tento zákon říká, že jakýkoliv systém bude stabilní pokud počet stavů kontrolních-řídících procesů systému je stejný nebo větší než počet všech možných stavů, které mohou v tomto systému vzniknout. Jednoduché a krásné pravidlo říkající, že řídit se dá mnoha způsoby a nemusí se nasledovat zavedené dogma.

Frustration board je místo, které pomáhá najít stavy, které jestě nemají svůj kontrolní proces a retrospektiva, se pak pokouší takový proces definovat a uvést do chodu. Ideálně chytřejším způsobem než jen delegováním na nadřízeného nebo někoho jiného.

Pokud máte jakékoliv dotazy, ptejte se pomocí komentářů, kontaktujte nás na emailové adrese uvedené v sekci O nás nebo si s námi přijďte popovídat na další Setkávání ke svobodě 28.2. 2012 v pražském Hubu.

• Co jsem se dnes naučil?
• Co mě dnes překvapilo?
• Co budu dělat v budoucnu jinak?

Akce zaměřená na procvičování základů návrhu a vývoje software, ohlášená na osmou hodinu ranní, mohla přilákat jen lidi, kteří jsou nadšení pro své řemeslo. Něco málo po osmé byli již všichni zabydlení v hezkých prostorách pražského Hubu. V 8:45 proběhlo  rychlé intro, kde jsme si řekli, že dnešek je dnem, kdy se můžeme pokusit psát perfektní kód tak, abychom pak v zaměstnání pod tlakem termínu zvládli odvést za stejný čas lepší práci. Dále bylo zmíněno to, že den bude rozdělen do šesti časově ohraničených bloků, práce bude probíhat formou párového programování a na konci každého z bloků bude nutné vymazat veškerý napsaný kód.

V 9:00 si každý rychle našel partnera pro první blok a tak jsme se mohli pustit do zkoumání problému, kterým byla Conway’s Game of Life. Jedná se o hru, která nemá hráče. Jediné, co může člověk ovlivnit je počáteční nastavení světa, který se skládá z nekonečné 2D mřížky obsahující buňky. Každá z buněk může být v jednom ze stavů – živá/mrtvá a její další osud se řídí několika jednoduchými pravidly:

• Pokud má živá buňka méně než dva živé sousedy, umírá v důsledku nedostatku obyvatel.
• Pokud má živá buňka dva nebo tři živé sousedy, zůstává naživu do dalšího kola.
• Pokud má živá buňka více než tři živé sousedy, umírá v důsledku přemnožení.
• Pokud má mrtvá buňka přesně tři živé sousedy, stává se v dalším kole buňkou živou.

Cílem prvního bloku bylo seznámení se s mechanikou hry tak, abychom se mohli ve zbytku dne soustředit na procvičování různých programátorských postupů. Po 45 minutách ohlásil zvonek konec bloku a následovala první krátká retrospektiva, na které jsme si během nekolika málo minut řekli, co nás zaujalo nebo překvapilo. Spousta lidí zjistila, že třičtvrtě hodiny je příliš krátká doba na dokončeni řešení. Opět jsme proto zdůraznili, že dnešním cílem není problém vyřešit, ale že cílem je tréning základů návrhu a vývoje software.

     

Miroslav Bajtoš pak představil 4 pravidla jednoduchého návrhu, která jsou hlavním tématem všech Coderetreat-ů.

1. Prochází všechny testy.
2. Kód neobsahuje žádné duplicity.
3. Kód vyjadřuje záměr programátora (proměnné/metody jsou dobře pojmenované).
4. Kód neobsahuje žádné nadbytečné části.

Dopoledne jsme zvládli ještě další 2 bloky. Spousta lidí byla pořád v módu snahy o vyřešení problému a někteří ještě bojovali s pochopením Game of Life. Většina začínala s 2D polem, které obsahovalo boolean flagy případně instance třídy Buňka. V retrospektivách jsme se proto zaměřili právě na poukázaní problémů, které přináší tyto přístupy.

2D pole

• Problém se splněním podmínky zadání, které říká, že svět je nekonečný.
• Co když přijde požadavek na změnu topologie?

Buňka

• K čemu ji člověk potřebuje?
• Pokud má v sobě příznak živá/mrtvá, znamená to, že musíme mít všechny mrtvé? Máme pak stejný problém s nekonečnem jako při použití 2D pole?
• Kolik odpovědností má tato třída? Neporušuje SRP? Pozice, znalost topologie – sousedé, znalost pravidel přežití

Aleš Roubíček pak ještě zdůraznil, že pravidla čistého kódu platí i pro testy. Po krátké diskusi nasledoval výborný oběd spojen s dlouhou pauzou, během které jsme si stihli všichni odpočinout před tím, co na nás čekalo v následujících hodinách.

V týmu facilitátorů jsme se shodli, že odpoledne trochu přitvrdíme a přinutíme lidi vystoupit z jejich komfortní zóny, ve které jsou zvyklí programovat. Tématem prvního odpoledního bloku proto bylo psaní krátkých, dobře pojmenovaných tříd a metod.

• Maximum 5 řádek v jedné metodě.
• Maximum 3 metody v jedné třídě.

Mile mě překvapilo, že všichni výzvu přijali, o čem jsem se mohl přesvědčit i na mé pravidelné pochůzce, kdy jsem pozoroval, jak to lidem jde. Tam kde byli dopoledne metody o délce 20 a více řádek jsem teď viděl krátké metody, jejichž názvy lépe odůvodňovali jejich existenci a přehlednost kódu se tím výrazně zlepšila.

Při následovné retrospektivě se několik lidí přiznalo, že měli metodu o délce 6 řádek a to z důvodu vnořených for cyklů a podmínek. S úsměvem na tváři jsme jim proto zdělili výzvu pro další blok:

• Nepoužívat podmínky (IF, WHILE)
• Nepoužívat cyklus FOR

U některých lidí zavládlo zmatení následované sérií otázek jestli to myslíme vážně. S klidným výrazem na tváři jsme odpověděli, že ano a nadhodili jsme několik návrhů:

• Použití polymorfizmu.
• Funkcionální konstrukty map/filter.

Výzva byla nakonec přijata a po rychlém vyhledání nových partnerů mohl začít pátý blok, který se nakonec ukázal jako nejnáročnější z celého dne. Páry bojovali hlavně s odstraňováním podmínek. Použitím funkce filter se některým povedlo zabít 2 mouchy (podmínku i cyklus FOR) jednou ranou a výsledný kód vypadal výrazně lepe než ten, který se objevoval na obrazovkách dopoledne. Po 45 minutách přišlo vysvobození v podobě zvonění, nasledované retrospektivou, během níž jsme si opět popovídali o zajímavostech zjištěných v průběhu posledního bloku.

Na účastnících již byly znát náznaky únavy a tak jsme se s Mirem a Alešem shodli, že den zakončíme blokem, ve kterém může každý popustit uzdu své fantazie a zkusit cokoliv. Poskytli jsme několik nápadů pro inspiraci:

• Napište nejhorší kód jaký umíte.
• Mute – komunikace jen skrze kód.
• Find the Loophole – ten kdo píše produkční kód se ho snaží napsat evidentně nesprávně, ale zároveň tak, že splňuje všechny napsané testy.
• Pokud jste psali testy, teď to zkuste bez nich.
• Nepoužívat myš.

Páry se rychle domluvili na způsobu, kterým budou pracovat a mohlo se začít. Nejzajímavějším bylo pozorovat páry, které si zvolili “Mute” (někteří dokonce zároveň s “Find the Loophole”). Kombinace frustrace s radostí byla očividná. Několik párů si take vyzkoušelo práci bez použití myši a zjišťovali, co všechno umí jejich editor bez toho, aniž by sundali ruce z klávesnice.

I poslední blok byl nekompromisně ukončen zvonkem a my jsme se tak dostali k finální retrospektivě celého dne. Každý měl možnost zodpovědět 3 otázky:

• Co jsem se dnes naučil?
• Co mě dnes překvapilo?
• Co budu dělat v budoucnu jinak?

Zazněla spousta zajímavých odpovědí, ze kterých jsem vybral:

• Získal jsem motivaci.
• Budu trénovat, trénovat, trénovat.
• Hodně jsem se toho naučil.
• Čekal jsem, že lidi budou mít chladnější přístup, ale mýlil jsem se a atmosféra byla skvělá.
• Na první pohled absurdní omezení (nepoužívat IF) může vést k zajímavým pohledům na problém.
• V pondělí řeknu šéfovi, že v Praze již testují, že bychom taky měli začít.
• I JavaScript může vypadat dobře.
• Překvapilo mě, jak někteří zvládají svůj editor – zkusím se zdokonalit v tom svém.
• Poprvé jsem si vyzkoušel párové programování – byla to zábava.

Nezbývá než doufat, že účastníkům vydrží získaná energie a poznatky co nejdéle a že alespoň část z nich je využije pro další rozvoj svých schopností.

Jako facilitátoři jsme získali spoustu nových zkušeností a věřím, že je využijeme při organizaci dalších Coderetreat-ů, které na sebe nenechají dlouho čekat.

Za tým organizátorů bych moc rád poděkoval všem účastníkům za to, že si díky svému přístupu vytvořili super akci a zároveň i našim partnerům – firmám GMC a Think-Forth, které přispěli nemalou částkou na pokrytí našich potřeb.