Obtížné rozhovory

Nedávno jsem dočetl knihu, která je, jak se říká, otvírák na oči. Jmenuje se Difficult Conversations. V jednoduchosti je o tom, co se děje, když se lidi baví o něčem ne právě příjemném. Takové ty situace, kdy se šéfa snažíte přesvědčit, že si zasloužíte přidat, sdělit přítelkyni, že chrápe nebo vysvětlit sousedovi, proč potřebujete vrtat do panelu v neděli v šest ráno.

Je to knížka ohromě užitečná pro každého, kdo přijde do kontaktu s lidmi. Mě opravdu otevřela oči. Teď, když vidím lidi diskutovat, tak si uvědomuji, co se tam děje, proč se hádají a co měli udělat lépe. Na sebe to bohužel zatím aplikovat neumím.

Asi nedokážu vytáhnout to podstatné, tak tu jen vypíšu to, co jsem si z toho odnesl já.

Obtížné rozhovory téměř nikdy nejsou o tom zjistit fakta. Jsou o konfliktech ve vnímání, interpretacích a hodnotách. … Nejsou o tom co je pravda, ale o tom co je důležité.

… obtížné konverzace ne jen že se dotýkají pocitů. Jsou ve svém jádru o pocitech. Pocity nejsou jenom nějakým vedlejším produktem obtížného rozhovoru, jsou jeho nedělitelnou součástí. … Občas jsou pocity to jediné důležité.

Cože, takže když se hádám, tak nezáleží na tom jestli mám pravdu? No jo, asi opravdu ne. Je jedno, jestli přítelkyně chrápe, důležité je co cítí ona a co já. Je jedno, jestli si zasloužím přidat, jde o to co cítí můj šéf.

Předpokládáme, že známe záměry ostatních, i když tomu tak není. … Pravda je, že záměry jsou neviditelné. Jenom je vyvozujeme z chování ostatních. Jinými slovy, si je vymýšlíme. … Záměry jsou důležité a pokud je odhadnete špatně, tak to ohrožuje váš vztah.

To se mi děje běžně. Když někomu ublížím já, tak je to z nedopatření. Když někdo ublíží mě, tak je to sobecký hnusný zmetek. Když přijdu pozdě, tak je to proto, že mi ujel autobus, když mě nechá čekat někdo jiný, tak je nespolehlivý.

Když někoho obviníme z nekalých záměrů, tak se začne bránit. Z jeho pohledu se brání proti křivému nařčení. Z našeho pohledu je jenom defenzivní. My máme pravdu, on jen není dost silný si to přiznat. … Obě strany si myslí, že jsou oběť a že se musí bránit.

Sakra, to jako znamená, že bych neměl lidem říkat, že jsou nespolehliví, protože přišli pozdě. Že se jakou začnou bránit a nikam se nedostaneme?

Proč je to vždycky ten druhý, kdo je naivní, sobecký, iracionální nebo manipulativní?

To by mě taky zajímalo.

Hmm, už mě to tu nebaví opisovat. Koukám, že jsem si podtrhl velkou část té knížky. Tak to zkusím jinak. Co jsem si zapamatoval ohledně toho, jak by měl člověk správně jít do obtížných rozhovorů.

Rozmyslet si, co vlastně chci. Chci se jen pohádat, někomu to vytmavit nebo najít řešení? Pokud chci najít řešení, tak nejdřív musím zjistit pohled toho druhého. Když mu budu do hlavy cpát co jsem vymyslel, tak mě nebude poslouchat. Je to divné ale je to tak. Musím si prostě poslechnout, jaký je jeho pohled na věc. Když já nebudu poslouchat jeho, nebude poslouchat on mě.

Pokud v tom problému mám nějaké pocity, tak si je musím umět uvědomit. Musím vědět, proč mě to štve, proč se cítím ublíženě nebo jak se vlastně cítím. Musím to taky umět sdělit. Nemá smysl mlátit dveřma, ironicky se ušklíbat nebo zvedat oči v sloup. Možná mi to uleví, ale situaci to jen zhorší.

Musím pečlivě oddělovat fakta od svých názorů nebo pocitů. Takže nemá smysl říkat: „Jsi sobec.“ Místo toho musím říci: „Nechala jsi mě čekat dvě hodiny na mraze ve vánici u otevřené žumpy. Jsem zmrzlý a cítím se, že ti na mě nezáleží.“. Vypadá to, že oba výroky jsou stejné, ale nejsou. První je můj soud a vyvolá jen obranu a protiútok. U druhého je větší šance na konstruktivní rozhovor. Tady pozor na zobecňování. Pokud bych začal s „Zase jsi mě nechala čekat“ tak si jen koleduju o protiútok.

Užitečné je taky začít tím, co vlastně chci. Když jdu někomu dát rozkaz, tak mu musím říci, že mu dávám rozkaz. Když jdu něco diskutovat, tak musím říci, že jdu diskutovat. Vyhnu se tak problému s tím, že někomu dávám rozkaz, ale on to pochopí, že s ním chci diskutovat. Mě pak naštve, že mi odporuje, on bude překvapený proč jsem naštvaný a bude to k ničemu.

To je asi všechno. Takže pokud přicházíte do kontaktu s lidmi a není vám jasné, proč se všichni kromě vás chovají iracionálně, tak vám tuto knihu vřele doporučuji. Je sice trochu dlouhá, ale stojí to za to.

Korporátní hry – Cargo kult

Popis hry

Cargo kult je týmová hra, v které hráči imitují aspekty určitého postupu či metodiky aniž by přejali její podstatu. V oblasti softwarového inženýrství toto chování poprvé popsal Steve McConnel v článku Cargo Cult Software Engineering (IEEE Software, 2000). Náš kolektiv autorů tuto hru pozoroval v různých variantách. Např. RUP bez iterací, Kanban bez omezení rozdělané práce, Scrum bez dedikovaného týmu, DevOps bez spolupráce mezi OPS a vývojáři nebo Extrémní programování bez automatických testů. Oblíbené jsou rovněž „agilní“ metodiky bez retrospektivy či vyhledávání zpětné vazby.

Pojmenování

Jméno je převzato z označení náboženských hnutí v Melanesii po druhé světové válce. Místní obyvatelstvo se snažilo opakováním rituálů bílých návštěvníků získat hodnotné zboží – cargo. Patrně nejznámějším příkladem je budování atrap letišť, letadel a napodobování rituálů pozemního personálu. Domorodci je odpozorovali během přítomnosti americké armády, od které získali mnoho užitečných věcí. (zdroj Wikipedia)

Účel hry

Názory expertů na účel hry se liší. Příčinou rozporů je nemožnost objektivnímu výzkumu. Hráči sami netuší, že se účastní této hry a na přímé dotazy reagují podrážděně. Pokud jsou si své účasti ve hře vědomi, často netuší proč se v jejich společnosti hraje. Jelikož se ale jedná o velmi populární hru, předložíme několik nejuznávanějších názorů.

Nepochopení

Nejsimpličtějším výkladem je prosté nepochopení. Korporátní management převezme postup, nicméně nepochopí jeho podstatu. Tento výklad je nepravděpodobný, protože všechny moderní metodiky jsou velmi snadno pochopitelné.

Popírání

Z reakcí respondentů někteří experti usuzují, že si někteří hráči svoji účast ve hře neuvědomují nebo popírají, že by hru hráli. Jsou přesvědčeni, že u nich nejde o imitaci, ale že opravdu aplikují metodiku správně. V tomto ohledu se příliš neliší od Melanéských domorodců. O příčinách takového popírání reality můžeme jenom spekulovat. Pravděpodobně jde o podvědomý strach z neúspěchu, který je v korporátním prostředí obzvláště silný. Tuto hypotézu by potvrzovalo i často pozorované vyhýbání se retrospekci. Při případném zkoumání neúspěchů by se muselo zjistit, že je metodika využívána nesprávně. Hráči podobný výsledek podvědomě tuší a vyhýbají se jakékoliv činnosti, která by na tento fakt upozornila.

Setrvačnost

Korporace vykazují velikou setrvačnost. Jakýkoliv pokus o změnu jejich směru vyžaduje velké množství energie. Často není potřebná energie dostupná a pokus o změnu skončí v polovině nebo na začátku. Tato hypotéza by vysvětlovala, proč se v některých společnostech skončí už u přejmenování schůzí a vykazovacího systému aniž by se změnilo cokoliv jiného.

Možné protiútoky a obrana proti nim

Vzhledem k tomu, že jde o týmovou hru, které se často účastní celá oddělení nebo i korporace, protiútoky proti této hře nebývají časté. Pokud se přeci jen objeví, mají obvykle dvě základní podoby.

Rebélie

Nejčastěji na cargo kult útočí malé skupinky pracovníků, kteří se snaží přejmout i podstatu imitované metodiky. Doufají, že se tím zvýší jejich efektivita a tím přesvědčí i zbytek hráčů přestat imitovat.

Obrana proti rebélii je jednoduchá. Většina moderních metodik vyžaduje určité podmínky. Například soustředění se na jeden projekt a tím pádem málo časté přepínání mezi úkoly. V takovém případě stačí tyto podmínky narušit. Například jednotlivým rebelům přidělit několik rolí nebo paralelně probíhajících úkolů, čím zaručíme jejich neúspěch.

Osvícený management

Z nepodložených zdrojů jsme zaslechli i o případech, kdy se o nápravu pokusil management. Jak již bylo uvedeno v části setrvačnost, je takový tlak z hora rozprostřen do velké plochy a tím pádem vyžaduje neuvěřitelné množství energie. Je snadné poukázat na vynaložené prostředky a takovou snahu včas zmařit.

Nebezpečné závislosti

Stala se nám takový nemilý, nepěkná věc. Do kódu se nám dostaly závislosti na knihovnách, které mají buď nestabilní nebo zastaralé API.

První je Apache HttpClient ve verzi 3. Prostě takhle jednoho dne přijdeme do práce a zjistíme, že máme v kódu spoustu závislostí na třídách jako je HttpMethod. Máme je samozřejmě pěkně izolované v jedné vrstvě aplikace, ale i tak je to na neuvěřitelném množství míst. Nevím jestli jste si všimli, ale je to opravdu HttpClient ve verzi 3. Dnes, v době, kdy je nová verze 4 už asi pět let na světě!

Druhá podobná věc se nám přihodila s Akkou. Do relativně důležitého API se nám dostala scala.concurrent.Future. A ano, opět čtete správně, není to Javovská java.util.concurrent.Future, je to cosi ze Scaly. Proč jsme něco takového dopustili? Asi z mladické nerozvážnosti. Prostě nám tenkrát nedošlo, že děláme blbost. Nemám nic proti Scale nebo Acce. Jde jen o to, že komunita kolem obou mírně řečeno kašle na zpětnou kompatibilitu. Takže jedeme na obstarožní verzi Akky, protože zkrátka nemáme dost času a odvahy na aktualizaci. Nejen že mají v nových verzích jiné API, ono se to celé i dost jinak chová.

Proč to tu vlastně píšu? Chci si pro příště vtlouci do hlavy toto:

Do důležitých API podezřelé třídy nepatří!

Otázka je, co jsou podezřelé třídy a jak se bez nich obejít? Podezřelá třída obvykle pochází z neustálené knihovny. Z takové, v které se často mění API nebo chování zpětně nekompatibilním způsobem. Je samozřejmě těžké předvídat budoucnost na základě minulosti, ale většinou to člověk pozná z release notes, uživatelského fóra nebo dokumentace. V obou našich případech to bylo evidentní. To, že už existuje nová, úplně jiná verze HttpClienta jsme věděli. To, že autoři Scaly ještě nepochopili, k čemu je dobrá zpětná kompatibilita, také není žádné tajemství.

Takže jak správně postupovat? Příště bych se nejdřív podíval, jestli neexistuje ekvivalent buď přímo v Javě nebo v nějaké prověřené knihovně jako je Spring. V našem případě jsme mohli použít abstrakci ze Springu. Ta by nás od API HttpClienta odizolovala. Mohli bychom se přepínat mezi implementacemi HTTP knihovny podle libosti. Stejně tak v případě Akky jsme mohli použít standardní Javovskou Future alespoň na úrovni API. Tím bychom si umožnili mnohem snazší update nebo dokonce změnu implementace.

No jo, ale co když neexistuje neexistuje žádná důvěryhodná abstrakce? Pak se musím se rozhodnout. Buď budu autorům knihovny věřit, že budou dodržovat zpětnou kompatibilitu. Také si musím být docela jist, že danou knihovnu nikdy nebudu chtít vyměnit za jinou. Nebo mi nezbyde nic jiného, a budu muset nedůvěryhodné třídy obalit do nějaké své abstrakce. A to tak, aby mi ta závislost nikudy neprosakovala. Vím, že je to na první pohled zbytečná práce. Vyhnete se ale tomu, co dříve nebo později čeká nás – bolestivému a zbytečnému přepisu hromady kódu.