Jak se staví tým

Tenhle článek jsem chtěl napsat už několik let. Pořád jsem to odkládal s tím, že časem ještě získám víc zkušeností a tak to bude mít větší, komplexnější váhu. Že pořád na to bude jednou dost času. Ale tak to v životě nechodí... jednou přijde čas a uvědomíte si, že věci, která vás kdysi extrémně přitahovaly, vám najednou nic neříkají. A že pokud to neuděláte teď, tak už to neuděláte nikdy.

Přesně takovým obdobím teď procházím. Přičinil jsem se o zlom ve své kariéře a tak po 8 letech, kdy jsem dělal team leadera a souběžných 6 letech, kdy jsem se intenzivně věnoval technickému rekruitmentu, tyto dvě oblasti (dobrovolně) opouštím. A tak je tenhle článek jakýmsi rozloučením a předáním štafety.

Na začátku by měla být vize

Když dostanete možnost postavit nový tým, nebo třeba významně doplnit ten stávající, měli byste mít nějakou vizi, jak ten tým bude vypadat. Proč vize? Protože budování týmu nekončí přijímacím pohovorem. Nekončí ani po zkušební době, či úplném zapracování. Ono totiž nekončí nikdy - je to cesta, která je svým vlastním cílem. A proto potřebujete úběžník, ke kterému budete po celou dobu existence týmu směřovat.

Termín z perspektivy jsem si nevybral náhodou:

• Vize i úběžník jsou virtuální entity, kterých v realitě nejde dosáhnout.
• Vize i úběžník jsou "lehce pohyblivé cíle" - záleží na perspektivě, úhlu pohledu, času a pozorovateli.
• O skutečném vývoji/postupu vypovídá historie - to když se ohlédnete zpět a uvidíte, jakou cestu jste urazili.
• Existují nástroje, které vám ve složitem terénu pomůžou udržet směr.

Smutnou pravdou je, že většina teamleaderů a manažerů - pokud už si dali tu práci a takovou týmovou vizi si definovali - vám nebude schopna tuto vizi popsat. Samozřejmě, takový ty soft-skill/HR/people-management keci vám řekne každý. Ale to jsou jen newspeak keci.

Jestli mě Kanban něčemu naučil, tak "make policies explicit". Pro vizi to platí taky. Nemusíte ji s nikým sdílet. Ale sepište si to. Vyslovte to nahlas. Není to žádná magie, ale funguje to zázračně. Jinak budete po léta bloudit v pustinách. Vy i celý tým.

Přijímací pohovor

O (technických) přijímacích pohovorech jsem tady na blogu psal po léta. Ačkoliv to jsou, nijak překvapivě, ty nejčtenější články, jejich vliv byl minimální. Když jsem se po 5 letech vrátil na pracovní trh, byla to velmi tristní zkušenost.

Tak jako jsem v minulé sekci zdůrazňoval důležitost vize, pro pohovory platí to samé - nepokažte si to hned na začátku. Může vám v tom pomoci pár pravidel:

• Buďte konzistentní. Všichni lidi v týmu by měli projít stejným procesem. (Ale udělejte výjimku, když to dává smysl.)
• Udělejte technické kolo co nejbližší skutečné práci, kterou děláte. Tohle většině českých firem ještě nedošlo. Jste SW inženýři, dělejte věci racionálně a nedržte se bludných mýtů.
• Nedělejte síto příliš úzké a husté. Nemáte ani představu, jak je život rozmanitý. Pravda, čím budete starší, tím méně věcí vás bude překvapovat. Ale stejně vždycky přijde něco, co jste nečekali (pokud jste před tím nezavřeli oči). Výjimkou z tohoto pravidla je, pokud jste si ve vizi definovali, že chcete postavit tým ze samých klonů tzv. ideálního kandidáta (mmch. to chce většina pražských firem).
• Směřujte k vizi. Ptejte se: bude tenhle kandidát za 1/2 roku, za rok sedět do naší (týmové) vize?

 Neexistuje ideální pohovor. Pokud to s pohovorem myslíte vážně a neberete kohokoli z ulice, stojí za to se inspirovat u zkušených (článků je plný internet), něco seriózního si o tom přečíst a pracovat na tom a pohovor zlepšovat. Za sebe doporučuji třeba Esther Derby, Johanna Rothman, Gerald Weinberg, Andy Lester, či Michael Lopp (Rands in Repose).

Já jsem svůj způsob pohovorování vybrušoval pět let. Je to proces, který odpovídá mé vizi, takže pro někoho může být nevhodný. Některé věci jsou dokonce nepřenosné.

Pokud nevíte kde začít, zkuste 2-a-půl kolové schéma (obsah už si doplníte sami):

• Phone screen. Krátký a jednoduchý technický filtr - má smysl se vidět tváří v tvář a strávit spolu víc času? (Pro inspiraci, jak jsem to dělal já.)
• Technické kolo. Viz výše. A opět můžete nakouknout ke mně do kuchyně.
• Netechnické kolo. Podívejte se na kandidáta i jinak, než přes technologie - není to robot. Pokud si později nebudete sedět, bude to spíš kvůli osobním, netechnickým kvalitám. Ale i tady platí "nedělejte síto příliš husté".

Neúprosná pohovorová statistika

Postavit dobrý tým je těžká makačka. Je to plnohodnotný (IT) projekt. Věc, kterou si členové vašeho týmu nejspíš nikdy neuvědomí (a spousta dalších lidí okolo), je, kolik je za tím práce, dát dohromady 5 až 10 lidí.

Po léta si vedu pohovorovou statistiku. Tady je jeden konkrétní, řekl bych průměrný rok:

• Phone screen: celkově 46 pohovorů, z toho 33 postoupilo do dalšího kola (úspěšnost 72 %).
• Technické interview: celkově 29 pohovorů, z toho 20 postoupilo do dalšího kola (úspěšnost 69 %).
• Personální intervew: pro toto kolo nemám data (v grafu níže extrapoluji).
• Do týmu nastoupilo 6 lidí. Trvalo to rok.

 

Statistika pohovorů

Ke statistice pár poznámek:

• To že se lidi dostali na phone screen, znamená, že už byli minimálně profiltrovaný přes CV, buď interním HR, nebo agenturou. Tzn. že většinou už absolvovali headhunterský telefon. A samozřejmě prošli přes moje CV review.
• Reálně do dalšího kola nastoupí méně kandidátů, než kolik jich bylo úspěšných (z různých důvodů nepokračují dál).
• Interview byla během roku konzistentně rozvrstvena. Zhruba to znamená udělat za měsíc 4 phone screeny a 2-3 technická interview. A jednou za dva měsíce zapracovat nového člověka.
• Počítejte, že ze všech lidí, kteří vám projdou pohovory, vám do týmu nastoupí cca 10 % z nich. I míň.
• Povšimněte si poměrně vysoké úspěšnosti kandidátů v jednotlivých kolech. Domnívám se, že je to dáno tím, že jsem měl celý proces pod kontrolou a zůčastnil jsem se všech pohovorů (vyjma personálních interview). Pokud vám dělají interview různí lidé a nekonzistentně, bude neúspěšnost vyšší.

Zapracování

Fajn. Člověk vám nastoupil a dostal počítač a stravenky. Zpravidla bude nadšený a iniciativní. Neprošvihněte to! Samozřejmě, musí se naučit všechny ty procesy nástroje, projekty a produkty. Zaručeně tím ztráví celou zkušební dobu a velmi pravděpodobně celý úvodní semestr. Pokud je vaše doména složitá, může zapracování trvat i dva roky (true story).

Tohle období ubíhá tak nějak samo od sebe, samospádem. Možná to bude dost překotné. Ale nepodceňte to - je to první čas, kdy budete daného člověka opravdu poznávat. Jak pracuje, jak žije, jak se chová, jak na něj reagují ostatní (členové týmu)?

Je to jedinečné období, kdy můžete zasadit semínko kultury a pomáhat mu zakořenit a růst. Pomůžou vám v tom nástroje jako 1:1 a ochota naslouchat a řešit problémy.

Týmová kultura

Jakmile máte v týmu prvního člověka, je týmová kultura to nejdůležitější, o co byste měli jako team leadeři pečovat. Je otázka, jaká je konstelace a kolik na to budete mít reálně času. Ale pokud má tým zdravě funovat v následujících letech a překoná různé (personální, pracovní a další) krize, bude to díky živoucí kultuře. Pokud týmová kultura churaví, nebo dokonce umře (taky jsem to zažil), bude to jen o tom, jak přinést domů pytel peněz na kus žvance.

Každá kultura funguje na tom, že se lidé potkávají. Čím širší komunikační kanál, tím lepší (zdravější). Nejlépe osobně, když to nejde tak aspoň video, až pak telefon a úplně na konci instant messaging. Pokud si píšete už jen emailem, tak už vlastně nekomunikujete.

Mějte pravidelné týmové schůzky. Potkávejte se nad problémy, u jídla a (v rozumné míře) mimo práci.

Každá kultura, která se rozvíjí, má nějaké (samo)korektivní mechanizmy, historii a způsob zpracování zpětné vazby. V případě SW inženýrství máme skvělý a ozkoušený nástroj: týmové retrospektivy. Retrospektivy nemusí být jen o projektech a iteracích. Můžou mít zaměření i na tým a jeho kulturu.

Retrospektiva: team radar

Mít dobrou týmovou kulturu není nic zas až tak těžkého - chce to jen pár rutinních a pravidelných úkonů. Jako když pečujete o zahrádku. Když to zandedbáte, začne vám zvolna zarůstat plevelem. V určitý moment se může stát, že se vám zahrádka vylidní. Přeju, ať se to nestane.

Související články

• Jak dělám Java pohovor III: phone screen
• Jak dělám Java pohovor IV: Java workshop
• Smutná zpráva o stavu IT trhu
• Geek, který zapadne
• 1:1, nejdůležitější nástroj team leadera

1:1, nejdůležitější nástroj team leadera

Říká se tomu one-on-one. V psané podobě můžete narazit na zápis OoO, O-o-O, 1on1 a různé další. Já používám 1:1, ale kreativitě se meze nekladou.

Za ta léta, co dělám team leadera, jsem se setkal s širokou paletou lidí a jejich zkušeností s 1:1. Jsou tací, kteří 1:1 nikdy neměli a někdy o něm dokonce ani neslyšeli. Jsou lidi, pro které je to jenom takový "manažment folklór". A pak je menšina těch, kteří 1:1 očekávají a vyžadují.

Jak už jsem psal v minulém článku (Technical Leader, mytické stvoření), potřebuju uzavřít určité období a shrnout, co jsem se naučil. Tady je moje moudro:

"Hlavním nástrojem vývojáře je IDE. Hlavním nástrojem Technical Leadera je Issue Tracking System. A hlavním nástrojem Team Leadera je 1:1." ~ SoftWare Samuraj

Můj příběh

Když jsem před nějakými osmi lety začal zvolna aspirovat na roli team leadera (ano, bylo to ještě předtím, než jsem začal psát tenhle blog), šel jsem na to svou obvyklou cestou, která se dá shrnout do tří slov: internet, knihy, praxe.

Hodně mi pomohl Michael Lopp, píšící blog Rands in Repose. Jeho nejlepší články tehdy vyšly v inspirativní knížce Managing Humans, na kterou mě upozornil na svém blogu Lukáš Křečan (jak to ten chlap dělá, že je vždycky o pár kroků přede mnou?).

Já sám jsem do té doby nikdy žádné pravidelné 1:1 neměl, jen takové to klasické performance review. Proto mě šokovalo, že bych měl organizovat 1:1 na týdenní bázi - neuměl jsem si to představit.

V té době jsem v někdejší firmě převzal/zdědil Java kompetenci. V reálu to znamenalo, že všichni seniornější Javisti už z firmy odešli. Nebylo od koho se učit, tak jsem si roli definoval sám. Naplánoval jsem si s klukama semestrální 1:1 a protože byli rozeseti na projektech po celé Praze, chodil jsem tam za nima.

Dalším milníkem bylo angažmá, kde došlo k nepřátelskému převzetí projektu (lehce jsem se tématu dotknul v článku (Ne)funkční tým). Pořád ještě jako juniorní team leader jsem bojoval, jak to šlo, podle svých tehdejších schopností. Jedna z věcí, které jsem zkusil a která byla dobrým krokem, bylo zavedení 1:1. Scházeli jsme se jednou za 1/4 roku.

A pak přišel další projekt - dostal jsem v kulminaci nálož 16 lidí (naštěstí to rostlo postupně). Opět jsem sáhl po knize (článek Management za zavřenými dveřmi) a opět jsem zredukoval periodu - scházeli jsme se na 1:1 jednou za měsíc.

   

Ano, už to přijde. Pointa. Ale tentokrát bez knihy. Když jsem nastupoval do nové práce, měl jsem neobvyklý luxus - mohl jsem si postavit svůj vlastní tým, úplně od začátku. S tímhle novým týmem jsem začal dělat to, co se všude radí bez výjimky - týdenní 1:1. Dělám to tak už téměř pět let a můžu jen konstatovat, že 1:1 je ten nejdůležitější nástroj, který team leader má.

Vize, benefit, smysl

1:1 je nástroj. Je to nástroj používaný mezi dvěma entitatmi - mezi team leaderem a členem týmu, ev. mezi manažerem a reportujícím. Aspektů, které tento nástroj může přinést je mnoho, ale já bych vypíchnul čtyři, které považuji za nejhodnotnější.

• 1:1 je silný nástroj pro vytváření vztahu mezi team leaderem a členem týmu.
• 1:1 kritický nástroj pro budování důvěry.
• 1:1 je také nástroj na vytváření a ovlivňování týmové kultury.
• A 1:1 je prostor a čas, který team leader dedikuje svým lidem.

Nejkritičtějším elementem je budování důvěry - pokud ve vztahu chybí důvěra, je těch benefitů jenom polovina (a míň).

Pravidla

Každý si umí představit analogii s autem, které potřebuje pravidelný servis, aby dobře fungovalo. Pokud ho zanedbáte (nebo už se to nevyplatí), tak se to nějak promítne, nastřádá. O 1:1 to platí také. A možná i víc, protože lidi nejsou stroje. Tady je pár pravidel, která vám můžou pomoct udržet 1:1 v dobrém stavu.

Pravidelnost

Běháte? Chcete uměhnout maraton (5k, 10k, 1/2 maraton)? Je potřeba, abyste pravidelně trénovali. Učíte se cizí jazyk? Je potřeba, abyste ho pravidelně procvičovali. Učíte se nový programovací jazyk/framework/technologii? Je potřeba je pravidelně používat. Jinak to nemá moc smysl a přínos je malý.

S 1:1 je to stejný. Jak říkal soudruh Lenin: pravidelnost, pravidelnost, pravidelnost. Rytmus je benefitem i podpůrnou konstrukcí.

Nezrušitelnost

Nikdy 1:1 nerušte. Nastavte si to jako železné pravidlo - jestli jste team leader, 1:1 je důležitejší než jakýkoli projekt. Projekt skončí, lidi vám zůstanou.

Když říkám nikdy, jsem si vědom absolutnosti toho slova. Já sám se snažím pít vodu, když kážu víno. Snažím se tomu ideálu aspoň přiblížit. Osobně to mám nastavené tak, že 1:1 ruším jenom když jsem (a) nemocný, (b) na dovolený, (c) na služební cestě. Pokud se něco kritického vyskytne v práci, snažím se 1:1 místo zrušení aspoň přeplánovat.

Rušení 1:1 má ještě jeden důležitý aspekt, ke kterému se vrátím v sekci Doporučení.

Respekt a vychování

Ono to přímo vyplývá ze zmíněného axiomu, že 1:1 je nástroj na vytváření vztahu - chovejte se ke členům svého týmu s respektem. Kromě běžné sociální slušnosti, bych vypíchnul reakci na vyrušení.

Na 1:1 neberte nikomu telefon. Nekontrolujte zprávy. Zdvořile odražte osobní vyrušení. Pokud vaše žena nejede do porodnice, tak vás nic neomlouvá, že se nevěnujete na 100 % člověku, kterého máte před sebou.

Mě když volá žena během 1:1 schůzky... típnu jí telefon. A zavolám potom. Když mi během 1:1 volá šéf, nezvednu mu to. Když šéf během schůzky vpadne do místnosti, řeknu že mám 1:1 a zastavím se potom. Za prvý jsem v právu a za druhý, je to slušnost.

Naslouchejte

Lidé ve vedoucích rolích mají často nepříjemný zlozvyk: moc mluví. I já - jako introvert - tím dost trpím a musím si to neustále (už po léta) připomínat. Někdy se mi to i daří. Naslouchejte. Poslouchejte, co vám kolegové chtějí říct. Když už máte jejich důvěru, tak ji nezahoďte.

Technology free

Předpokládám, že tohle hodně lidí šmahem odmítne, ale stejně to řeknu. Na 1:1 choďte bez technologií. Poznámky si pište na papír. Psát si během 1:1 na počítači - s libovonými bohulibými úmysly - je nevychované a neosobní. Pamatujete? Respekt a budování vztahu.

Pokud opravdu potřebujete mít vaše poznámky archivované na počítači, je to jenom vaše pohodlnost, co snižuje kvalitu komunikace.

Samozřejmě, pokud potřebujete svému kolegovi něco na počítači ukázat, je to v pořádku. Pokud ale před ním frontálně sedíte s počítačem před sebou, je to chucpe.

Obsah

Lidé, kteří se setkávají s 1:1 poprvé, můžou váhat, co je obsahem. Samozřejmě, je to primárně pracovní záležitost. Ale je v pořádku probírat i osobní a rodiné záležitosti. Jak tedy obsah 1:1 definovat?

Ještě než se přesunu k lehce konkrétním bodům, zmíním dva stěžejní principy:

1. Nechte své kolegy spolu-vytvářet obsah 1:1. Ono i když se podíváte na ten zápis - 1:1 - mělo by to evokovat fifty-fifty, či win-win. Jsou věci, o kterých nemáte ani tušení, že by je vaši členové týmu chtěli řešit.
2. Přizpůsobte 1:1 každemu člověku. Lidé jsou různí - mají různé povahy, senioritu, externí a životní zkušenosti, sociální a rodinný status. Můžou pocházet z jiných kultur a světadílů. Respektujte to a reflektujte to.

Pracovní témata

Pracovním tématem číslo jedna jsou problémy. Technologické problémy, projektové problémy, problémy ve vztazích v práci. To je to, co vaše lidi nejvíc trápí. Externí záležitosti vyřešit nemůžete, ale můžete aspoň svého kolegu vyslechnout a nabídnout empatii.

Interní problémy jsou dvojího druhu - ty, které daný člověk může vyřešit sám. Možná mu k tomu chybí odvaha, možná neví jak, možná jen potřebuje cítit vaši podporu. A pak interní problémy, které on vyřešit nemůže, ale můžete je vyřešit vy... protože jste (jeho) team leader. Tohle výživné téma by vydalo nejméně na článek - klíčové slovo: coaching.

Tématem číslo dva jsou úšpěchy. I drobné. Co se vašemu kolegovi povedlo? V čem se zlepšil? Co se naučil? Není u toho potřeba používat vyprázdněné superlativy, méně je více. Ale nemělo by to zapadnout.

Téma číslo tři: rozvoj. Co dělá váš kolega navíc, nad rámec "daily job"? Čte knihy? Zajímavý článek na internetu? Osobní projekt? Samozřejmě sem spadají i školení a podobné věci, i když ty se neplánují každý týden.

Téma číslo čtyři (záměrně není v TOP 3): něco jako "mikro-status". Záleží na kontextu. Pokud kolegu potkáváte na denním standupu, asi to nebude tak podstatný, možná i zbytečný. Pokud dělá na jiném projektu, hodí se vědět, jak vypadá aktuální projektový/technologický "snaphot". Bacha na micro-management!

Osobní témata

Asi je jasný, co se tím míní. Rozsah a hloubka se budou lišit od kvality vztrahu a míry důvěry. Já si běžně se členy týmu povídám o sportu, dovolený, rodině, koníčkách apod. Jde hlavně o to, co jste ochotni prozradit vy. (Jenom to nepřežeňte.)

"The most important action that a leader must take to encourage the building of trust on a team is to demonstrate vulnerability first." ~ Patrick Lencioni

Doporučení

Na závěr ještě pár doporučení, která rozvíjejí témata, která už zazněla.

Pokud vše dobře půjde, budete mít 1:1 s daným člověkem léta. Jak váš vzájemný vztah, tak vaše 1:1 by se mělo vyvíjet. Neupadněte do rutiny. Adaptujte (se). Změňte vaše individualizované 1:1 tak, aby to stále byl oboustranně prospěšný nástroj.

Jak už jsem naťuknul - neřešte problémy vašich lidí za každou cenu. Buďte umírnění a nechte je vyřešit maximum problémů, které zvládnou sami. Podpořte je, když selžou. Bez chyb není učení.

Vyhraďte si na 1:1 poznámky dedikovaný sešit. Budete mít historii na jednom místě.

A zlaté doporučení. Pokud vaši lidé odcházejí (z firmy) - stává se to - nerušte jim 1:1, ale pokračujte s nimi až do konce. Ukážete jim, že vám na nich i tak pořád záleží. V opačném případě budou mít pocit, že jste je hodili přes palubu.

Mind Map

Související články

• Manažerem humorně a kousavě
• (Ne)funkční tým
• Management za zavřenými dveřmi

Technical Leader, mytické stvoření

tl;dr Pokud vás téma zajímá, ale nechce se vám číst dlouhý článek, skočte na sekci Model. Nic jiného číst nepotřebujete ;-)

Into the woods

Jak už jsem letos párkrát zmiňoval, procházím určitým přelomovým obdobím, jehož vedlejším, či hlavním(?) důsledkem je, že opouštím vyšlapané cesty. Prostě jsem si koupil bare-foot boty a sešel z dlážděných cest na trávu a lesní pěšiny.

Není to ale žádné pálení mostů. Jsem za tu cestu, kterou jsem urazil, vděčný a hodně jsem se na ní naučil. A abych mohl tenhle úsek putování uzavřít, rád bych se podělil ještě o několik témat, která do budoucna opouštím. Můj náhled, co to je technical leader, je jedním z nich.

Obiter dictum

Jako formální i neformální technical leader jsem pracoval řadu posledních let - v různém prostředí, pro různé zaměstnavatele, s různými týmy. Také jsem o této doméně hodně četl. Byla to role, která mne neskutečně bavila a ve které jsem se chtěl kontinuálně zlepšovat. Snad se mi to i dařilo.

Zároveň jsem viděl, jak lidé v mém blízkém a občas i (velmi) vzdáleném okolí tápou. Co by mělo být obsahem té role? Jak se mám naučit potřebné věci?

A občas jsem také viděl, jak měli lidé ambici stát se formálním technical leaderem, aniž by tušili co to obnáší a hrnuli se do toho s pouhými romantickými představami a vidinou nově deklarovaného statusu a finančních benefitů.

Kromě toho, že jsem sám v této roli pracoval, jsem i pár technical leaderů vychoval. No, vychoval - řekněme, že jsem jim nestál v cestě (ale to už je jiný příběh).

Takže i když vím, že "tam venku" existují lepší technical leadeři, než jsem já, cítím se trochu povolaný sdílet pár informací a osobních názorů. Už proto, že o tom nikdo moc nepíše. (A pár jednorožců už jsem viděl.)

Model

K roli technical leadera můžete mířit z jakékoli jiné technické role. Pro potřebu tohoto článku budeme vycházet z pozice vývojáře, ale můžete si za něj dosadit "obecného" (či specifického) SW Engineera.

Výchozím bodem by měl být vývojář, který je "rozumně" seniorní. Co znamená ono rozumně, nechám na vašem zdravém rozumnu ;-) Povýšení juniorního člověka na technical leadera nedává moc smysl.

K tomu, aby se člověk stal technical leaderem, musí mít, kromě svého ústředního skillu, ještě nějaký přesah. Co jsem za ty roky vypozoroval, je to většinou přesah do jedné ze tří oblastí: architektura, project management a team leading. A podobně jako u technical leadingu, mohou být tyto oblasti formální i neformální.

tl;dr Pokud jste rychločtenáři, můžete nyní přeskočit na sekci Gotický svorník (model re-visited). Pak už je to opravdu všechno :-P

Developer

Jedním z méně častých, i když také možných typů technical leadedra, je vývojář, který sice nemá přesah do výše naznačených oblastí, ale který má velmi hluboké znalosti své technické domény. Je to ten tzv. guru (trošku devalvované slovo, což?). Ale nejenom to - je také problem-solver a mentor. Umí vyřešit nejen své technické problémy, ale i svých kolegů a zároveň jim dát do "své" technologie potřebný vhled.

Uvádím tenhle typ jen pro úplnost. Většinou je zde někdy tenká, někdy hodně široká a rozmazaná hranice mezi velmi seniorním člověkem a "opravdovým" technical leaderem. Osobně jsem takových moc nepotkal. Ale je to validní cesta, pokud se necítíte povoláni k ostatním typům přesahů.

Architekt

Přesah do architektury je s přibývající senioritou běžný. Jako seniorní vývojář chcete vystrčit hlavu z písku své technické domény a podívat se, co se děje u souseda na dvoře. Časem si možná uvědomíte že mezi vaším (vývojářským) a sousedovým dvorem (architektura) není žádný plot. Jsou to dvě plochy téhož tělesa.

Jako technical leader s přesahem do architektury je vhodné umět navrhnout architekturu a zároveň ji zvládnout kompletně naimplementovat. Nikdy byste neměli z pusy vypustit ohavnou větičku, že něco je "implementační detail". To nechte ivory-tower architektům.

Je vhodné vidět daný software v celosti jeho life-cyclu. Nemít klapky na očích a nesoustředit se jen na aktuální (a nejzajímavější) vývojovou fázi. Jak například vypadají vaše logy? Budou sloužit jen pár měsíců vývojářům, nebo budou supportu/operations pomáhat roky na produkci?

Ovšem, není to jen o vás - je potřeba umět vysvětlit vaše návrhy svým méně seniorním kolegům a také jim pomoci s úseky, které jsou nad jejich síly (technicky, designově, myšlenkově).

Projekt Manager

Často se setkávám s tím, že vývojáři vlastně neví, za co je platí. Že dostávají peníze za to, že (efektivně) vyřeší nějaký business problém. To je věc, kterou si velmi dobře uvědomuje project manager - zná finanční rozměr projektu a měl by mít plán, jak to zvládnout.

Jako technical leader s přesahem do project managementu je vhodné umět sestavit implementační plán (v libovolné vyhovující formě). Naplánovat iteraci. Prioritizovat. Zvážit smysluplnost investovaného úsilí. Seřadit a spravovat časové slouslednosti - aby si vývojáři s tunelovým viděním nestěžovali, že je "něco" blokuje.

A také umět předvídat, odhalovat a mitigovat rizika. Umět řešit a případně eskalovat problémy: chybějící lidi, externí závislosti, nečekané události. Navrhnout a řídit vývojovou metodologii a umět ji podle kontextu modifikovat a přizpůsobit.

Team Leader

Team leader a technical leader jsou často překrývající se, nebo zaměňované pojmy. Temínem team leader zde myslím toho, kdo pracuje s lidmi, vede tým a má za něj zodpovědnost.

Jako technical leader s přesahem do team leadingu je vhodné... vést lidi. Komunikovat se svým týmem. Řešit jeho problémy a objevovat příležitosti. Mít individuální přístup k jeho členům - každý z nich je originál. Vystupovat jako facilitátor.

A nejpodstatnější věc - mít vizi a udržovat týmovou kulturu. Působit preventivně proti bad apples. Vytvořit dobře promazaný stroj, který vyhraje softwarové play-off.

Budu k vám upřímný. Tenhle přesah je ze všech nejtěžší a nejvíc adeptů na něm ztroskotá. Jde o to, se nepoložit a pokračovat. Zkusit to znova, až to půjde. Ono to půjde.

Gotický svorník (model re-visited)

V předšlých sekcích jsme naznačili možné přesahy, které může technical leader mít, kromě svého core-skillu. Někdy má přesah jen do jedné z těchto oblastí, někdy do dvou. Nejcennější ale je, pokud má přesah do všech tří domén a působí tak jako svorník klenby, která z těchto pilířů vyrůstá.

V reálním světě měnících se potřeb a požadavků, se ty přesahy budou organicky měnit a přelévat, někdy i během krátké doby (jednoho projektu). I když ale daný skill není zrovna potřeba, pořád obohacuje všechny zbývající aspekty.

Technical... Leader

Většina adeptů na technical leadera se soustředí na to první slovo v názvu role. Ale to druhé slovo - leader - tam není náhodně. Osobně bych řekl, že tenhle aspekt je v celkovém přínosu a smyslu ten důležitější. Protože technical leader, který není leader je jenom seniorní vývojář.

Důvod, proč je tato druhá složka opomíjená, je celkem prostý - techničtí lidé z ní mají obavy. Jak se stanu leaderem? Všichni uvidí, že to neumím! A tak se soustředí na to, co už dobře znají... technologie. Komfortní bublina. A možná tak trochu čekají, že ty věci kolem leadershipu, tak nějak přijdou samy. Snesou se z modrého nebe jako vavřínový věnec nesený holubicemi...

Ale něco vám řeknu: vy už jste se jako seniorn vývojáři narodili? Že ne? Že to trvalo léta praxe a učení se? Jasně, jasně. Prozradím vám tajemství: nic jako "natural born leader" neexistuje! Vede k němu úplně ta samá cesta, jakou jste už sami ušli. Zadejte si do Googlu heslo natural born leader a budete vědět, na čem ještě potřebujete pracovat. Většinou je to práce na celý život. Ale někdy se začít musí.

Jediná cesta?

Samozřejmě, že role technical leadera má mnoho podob. Kdybychom chtěli pokračovat v naznačeném modelu, mohli bychom přidat jako další oblast přesahu například business analýzu. Nebo QA. Nebo... Anebo modelovat/definovat tuhle měňavou roli úplně jinak.

Podstatné je dát vaší roli technical leadera to, co váš kontext potřebuje. Cesty páně jsou nevyzpytatelné a matka příroda je flexibilní a přizpůsobivá. Nechť vás síla na vaší cestě technical leadera provází.

Doporučená literatura

Pokud jste dočetli až sem, tak jste možná opravdoví čtenáři. A ti čtou opravdové knihy. O technical leadingu už pár titulů napsáno bylo. Jestli můžu doporučit jeden z nich, je to kniha Becoming a Technical Leader od Geralda Weinberga (@JerryWeinberg), která je jako truhlice narvaná drahokamy. Některé nedoceníte hned. Jak říká Jerry:

"Becoming a technical leader is not something that happens to you, but something that you do."

Související články

• Programátor -> Vývojář -> Software Engineer

Související externí články

• Technický lídr (Banter bloguje)
• Mýtus nekódujícího architekta (Dagblog, TL tématu se dotýká jen okrajově)

Jak dělám Java pohovor IV: Java workshop

Zcela bezkonkurenčně nejčtenějším zápisem na mém blogu je opus magnum Jak dělám Java pohovor. Jeho čtenost je řádově vyšší, než u zbytku veškerých textů. Ten článek už je skoro pět let starý a neodpovídá (mojí) realitě.

Věci, které za to stojí, se snažím vylepšovat, takže je v důsledku dělám jinak. A pokud máte to štěstí, že si můžete vybírat lidi k sobě do týmu, tak by vám na tom mělo záležet. Hodně. A tak si ty poslední tři, čtyři roky říkám, že bych měl svůj zápis zaktualizovat. Jak tedy dělám pohovor dnes?

Agenda Java interview

Agenda pohovoru zůstala hodně podobná:

1. Představím se já.
2. Prostor pro otázky kandidáta a/nebo představení společnosti, business domény, našeho oddělení a projektů.
3. Diskuze nad kandidátovým projektem.
4. Review kandidátova kódu.
5. Java workshop

Drobnou změnou je bod číslo 3, diskuze nad kandidátovým projektem. Velkou a stěžejní změnou je pak titulní Java workshop.

Diskuze nad kandidátovým projektem

Dříve jsem v tomto bodě probíral kandidátovo CV, ale postupně se to vyvinulo v diskuzi nad konkrétní zkušeností. Přijde mi to zajímavější a přínosnější, než diskuze nad "suchou historií".

(Mimochodem, kandidáti mají neuvěřitelně zažitou historizaci svojí praxe. I když jim opakovaně explicitně zdůrazníte, že nechcete slyšet chronologicky odříkanou pracovní zkušenost, většinou vás naprosto ignorují a spustí naučený kolovrátek. Hanba vám HR a head-hunteři!)

V dnešní době se tedy ptám na projektovou zkušenost ve stylu:

"Mohl byste mi popsat Váš poslední, nebo poslední úspěšný projekt? Zajímají mě hlavně technické aspekty - mohl byste mi popsat a ideálně namalovat architekturu, či design vašeho vybraného projektu? Dále by mě zajímalo, jak byl projekt řízen, jaké role se na něm podílely a jaká byla Vaše role? Co třeba nějaké disciplíny SW inženýrství? Release management? Source code management? Issue tracking?"

Většinou se mi podaří kandidáta (přátelsky) přimět k namalování nějakého schématu na whiteboard. To má dva aspekty. Jednak se nad vizualizovanou architekturou/designem dobře diskutuje. A jednak poznáte, jak je na tom kandidát ohledně schopnosti vysvětlit technické věci, znalost modelování, uvědomění si "big picture", kontextu daného projektu a spoustu dalších věcí.

Ilustrační příklad whiteborard architektury

Java workshop

Když jsem pozměněnou podobu interview vymýšlel, chtěl jsem něco, co bude co nejblíž způsobu, jakým bych chtěl, abysme v týmu pracovali. Tedy: komunikovali spolu a uměli diskutovat nad kódem a designem. A samozřejmě... psali kód, ideálně s unit testy.

Začínám tím, že si s kandidátem sedneme vedle sebe a předložím mu - podle vybraného příkladu - následující obrázek (pro nadcházející odstavce, považujme za dané zadání návrhový vzor Observer):

Class diagram návrhového vzoru Observer

Zeptám se kandidáta, jestli zná UML a daný návrhový vzor. Pokud ano, tak ať jedno, druhé, či oboje vysvětlí. Pokud ne, řeknu nevadí a obojí vysvětlím já. Tahle část trvá krátce, většinou tak do pěti minut a jejím hlavním smyslem je porozumět zadání. A teď přijde to hlavní.

Otevřu notebook a... ukážu kandidátovi "skeleton" projektu natažený v IDE. Vypadá to nějak takhle:

Skeleton Java projektu v IDE

Jak je vidět na obrázku, i na UML diagramu výše, v projektu jsou dvě rozhraní a dvě implementační třídy. Ty konkrétní třídy "implementují" metody z interfaců, ale jsou prázdné. Čili, jde to zkompilovat, ale nic to nedělá.

Rozhraní a jeho prázdná implementace

Malá vsuvka, pokud vás to napadlo - v tom IDE to mám připravený v Eclipse a v IntelliJ IDEA. Dřív jsem to měl připravený i pro NetBeans, ale pak jsem to přestal udržovat - za ty čtyři roky mi na pohovor nepřišel nikdo, kdo by chtěl v NetBeansech dělat.

Zpátky k projektu. Kromě produkčního kódu jsou tam připravený - opět prázdný - třídy pro testy. Pokud by vás zajímalo, jak přesně ten startovní projekt v IDE vypadá, podívejte se na můj repositář na Bitbucketu: https://bitbucket.org/sw-samuraj/hiring/overview

Vysvětlím kandidátovi strukturu projektu a řeknu něco jako:

"Takže, tady máme prázdný projekt (pro návrhový vzor Observer) a zkusíme si ho naimplementovat. Pokud znáte, nebo jste dělal nějakou reálnou implementaci tohoto vzoru, můžete zkusit udělat ji. Anebo můžeme zkusit naimplementovat ten vzor jako takový, dejme tomu ukázkový příklad.

Záleží jen na Vás s čím začnete, jestli s implementací, nebo s testy a já jsem tady proto, abych Vám pomohl v případě problému. A v průběhu toho, jak budete psát, se Vás budu ptát na některé aspekty Vašeho kódu.

V projektu můžete cokoliv změnit, je zde jen jedno pravidlo - nesmíte nijak upravovat interfacy."

A je to. Kandidát začne psát, já se dívám, občas se na něco zeptám. Když se nám to zadrhne, jemně kandidáta navnadím, nebo popostrčím. Občas něco do kódu napíšu i já sám.

Každý kandidát je naprosto jiný. Někdo to celé vystřihne za půl hodiny i s pěknými unit testy. Někdo za stejnou dobu stačí vyrobit jednu metodu, která přidává prvky do kolekce. V průměru strávím touhle částí zhruba 40-50 minut.

A je to. Interview krátce zakončím a rozejdeme se.

Jak workshop vyhodnotit?

V momentě, kdy workshop skončí, už mám většinou jasno, jestli chci mít kandidáta v týmu, nebo ne. Někdy jsem na pochybách a je lepší se na to vyspat, nebo prodiskutovat s někým nezúčastněným.

Jinak vás asi zklamu - neprozradím vám žádné tajemství, jak z té cca hodiny programování udělat výsledek. Pro mne to byla dlouhá cesta, během které jsem mířil k jakémusi ideálu. Proto nepotřebuju nějaký checklist, abych věděl, jestli tam - s kandidátem - jsme, nebo ne.

Pokud vám minulý odstavec nedává smysl, nebo mu nerozumíte a přesto byste chtěli vědět, jak worshop vyhodnotit, zkuste se inspirovat těmihle aspekty:

• Jak kandidát komunikuje? Během vysvětlování zadání a během programování.
• Jak efektivně pracuje v IDE? (Na oblíbené IDE se ptám ještě před pohovorem, takže by to neměl být stresující faktor, že programuju v něčem nezvyklém.)
• Jak hezky/čitelně/čistě/efektivně píše kód?
• Jak designuje/strukturuje metody, třídy, testy?
• Jak píše testy? Jestli vůbec. A kdy? Předtím, potom, zároveň?
• Zajímají vás nějaké seniornější aspekty? Klidně se můžete ponořit do věcí, jako je specifická implementace některého Java API, nebo třeba do Reflection API (fakt, vyplyne to úplně přirozeně).
• Chcete si ověřit znalost konkrétní verze Javy? 6, 7, 8? Žádný problém, jde to.
• Jak kandidát komunikačně a znalostně reagoval na navržené alternativy?

Určitě vás napadne něco dalšího.

Co už nedělám

S odkazem na původní článek, bych vypíchnul věci, od kterých jsem upustil. V první řadě, už se nevrtám v CV. Ani před pohovorem, ani během. Životopis si většinou jen rychle proběhnu před phone screenem, jestli mě tam něco nezaujme - třeba jestli má kandidát zkušenost s (business) analýzou, architekturou, team leadingem apod. Prostě nějaký přesah za vývojařinu.

A potom, už nedávám hlavolam. I když tahle část bývala celkem zábavná, tak jsem ji odstranil - když jsem před těmi čtyřmi lety nově definoval, jak bych chtěl pohovor pojmout, zaměřil jsem se na to, aby to bylo co nejbližší denní realitě. A tam prostě vývojáři mechanické hlavolamy neřeší. (Čest výjimkám.)

Jak dál?

Pohovor tímto způsobem dělám poslední čtyři roky a musím přiznat, že po té době je to pro mne už příliš velká rutina. Chce to změnu. Zatím čekám na inspiraci. Je možné, že tenhle článek čtete v přelomovém období - takže jestli se někdy potkáme spolu na pohovoru, dost možná, že bude vypadat jinak.

No dobře, Java. Ale co .Net?

Z minulých dvou let mám zajímavou zkušenost. Poprvé v životě mě potkalo štěstí, že jsem se stal mentorem. Jako tím opravdovým, kdy se vztah mentor-mentee "samovolně", organicky vytvoří. Pikantní na tom je, že můj mentee není Javista... je to .Neťák!

No. Kromě jiného jsme spolu řešili také .Net pohovory. Z dnešního pohledu to vlastně nebylo nic těžkého - vzali jsme můj Java pohovor, vytvořili .Net workshop a bylo to.

Podstatné je, že to výborně fungovalo a dnes tak máme úspěšný nový .Net tým. Zkušenosti zkrátka občas přijdou ze strany, odkub byste to nečekali.

Předešlé díly

• Jak dělám Java pohovor
• Jak dělám Java pohovor II: proč nedávám testy?
• Jak dělám Java pohovor III: phone screen

Související články

• Jak se nabírají Javisti na Filipínách
• Jak dělají Java pohovor jinde
• Měl by mít vývojář portfolio?
• Kontrakt místo pohovoru, je to reálné?
• Geek, který zapadne

Jak dělám Java pohovor III: phone screen

Technickému recruitingu se věnuji už nějaké čtyři roky. Je to činnost, která mě hodně baví a tak jako u jiných aspektů své práce, jsem si vypěstoval určitý postup. Zároveň se snažím věci pořád zlepšovat a korigovat, jak studiem, tak praxí.

Phone Screen

Jedna z věcí, ke kterým jsem došel a považuji ji za nutnost, je phone screen. Jediný případ, kdy ho nedělám, je buď že mám s daným člověkem přímou pracovní zkušenost, anebo jsme se předtím už osobně setkali - to se stává, pokud třeba někdo zareaguje na můj inzerát.

Poslední dobou si hodně čtu o agilním přístupu (i po těch letech se člověk pořád má co učit) a věc, která se mi stále vrací a furt si ji musím připomínat - každý mítink musí mít smysl. Fajn, jaký je tedy pro mne smysl phone screenu? Podívejme se, co stojí v soukromém samurajském slovníku:

Phone Screen: Je to první, krátký a efektivní kontakt s potencionálním kolegou, který zodpoví jedinou otázku - má smysl se osobně vidět a pokračovat ve vzájemném získávání informací?

Proč používám termín phone screen a ne třeba "telefonní pohovor"? Inu, to proto, že je to krátké a přesně to vystihuje svůj účel. Uznejte - "telefonní filtrování" zní blbě samo o sobě a poslat kandidátovi pozvánku s takovým předmětem by asi nebylo zrovna vstřícné. 

Struktura

Můj phone screen má vždy stejný začátek. Zavolám, představím se jménem a firmou a řeknu: "Tento phone screen by měl trvat 30 minut a projdeme si následující kroky:

1. představím se já,
2. představí se kandidát z hlediska technologií,
3. technické otázky,
4. kandidátovy otázky."

Pak si cca 30 minut povídáme, během té doby bedlivě sleduji čas, a po půl hodině rozhovor ukončím.

Pokud se podívám blíže na jednotlivé body:

Představím se já, tedy, znovu zopakuji svoje jméno, řeknu svoji formální pozici a krátce vysvětlím obsah své práce. Myslím si, že je to fér vůči kandidátovi - dát mu nějaký kontext, aby věděl, s kým asi tak mluví.

Představí se kandidát z hlediska technologií. Jediná informace, kterou o kandidátovi v tento moment mám, je zpravidla pouze jeho CV. Což je dost slabá a nevěrohodná informace. Požádám proto kandidáta, aby se mi představil z hlediska technologií. Zdůrazním, že mě nezajímá klasické "odříkávání" životopisu, stejně tak, jaký byl business význam projektů, nebo aplikací, na kterých se podílel. Co mě zajímá, je jeho současný technologicko-seniorní "snapshot".

Myslím, že je to celkem logické - nenajímám odborníka na nějakou business doménu, ani business analytika, ale vývojáře. Takže mě zajímají technologie, frameworky, architektura atd. Bohužel, lidé dost často tuto otázku ignorují a spustí naučený kolovrátek. Pokud se tak stane (pořád sleduju ten čas), vrátím je zpátky k původní otázce.

Technické otázky. Jedním z cílů předchozí části je zjistit kandidátovy silné technologické stránky. Říkám o sobě (ohledně pohovorů), že jsem hodný, ale spravedlivý. Takže se ho ptám na věci, o kterých říká, že je dobře zná. Samozřejmě, musím ty věci dobře znát i já. Ale vzhledem ke svému stáří a senioritě ;-) vždycky najdeme slušný průnik. Někdy se i kandidáta přímo zeptám: "Jaké jsou momentálně dvě Vaše nejsilnější technologie?".

No a pak začneme na povrchu, u triviálních a základních věcí a jdeme hloub a hloub, až se někde naše znalosti zastaví - narazíme na lokální minumum. Pokud se to stane, nebo se téma vyčerpá, nebo pokud přes veškerou snahu zůstaneme stále na hladině, přejdu k dalšímu (silnému) tématu.

Pro představu jak může tahle část vypadat, dejme tomu, kandidát říká, že dobře zná JPA, či Hibernate. Můžeme začít třeba otázkou "Na jakém principu tahle technologie funguje?", nebo "Jaký je vztah mezi JPA a Hibernate?".

Pak se podíváme na mapování pomocí metadat. Můžou to být otázky typu "Které dvě anotace/XML elementy jsou nezbytně nutné, aby framework mohl používat (POJO) třídu jako entitu?", či "Které anotace při mapování běžně používáte?". Podstatné je, že nevyžaduji přesné názvy, ale jestli kandidát rozumí o čem mluví a principům, na kterých to funguje.

A jdeme hlouběji - jaké mohou být vztahy mezi entitami, jaké jsou strategie pro získávání dat a která z nich je defaultní pro daný typ vztahu? Jak se řeší složené klíče? Na téhle úrovni složitosti často opustíme mapování entit a podíváme se na jiná zajímavá témata - přece jenom, děláme phone screen a času je málo.

Můžeme si popovídat třeba o EntityManageru, nebo o Session. Pokud nám to spolu klape, můžeme se dostat až k transakcím, nebo co to je PersistenceContext a PersistenceUnit. Někdy dokonce dojde i na lifecycle entit :-)

Ať už se dostaneme kamkoliv, je podstané, jak jsme si o tom popovídali. Už jsem zmiňoval, nejde mi o žádné odříkávání slovníkových dat a in-memory znalostí. Jde mi o porozumnění a rozsah, které by mělo odpovídat dané úrovni seniority. Jednotlivé otázky, jak úvodní, tak usměrňující vybírám intuitivně, nemám žádný mustr, podle kterého jedu.

Když se čas nachýlí, je prostor pro kandidátovy otázky. Kandidát mi věnoval cca 25 minut svého času a tak je fér mu otevřeně zodpovědět, co by ho zajímalo. Možná si říkáte, že 5 minut na otázky není moc, ale většinou to bohatě stačí - moje zkušenost je taková, že nadpoloviční většina lidí nemá žádné otázky, nebo tak jednu dvě. Pokud je někdo zvědavější a má otázek víc, i já mu (rád) věnuji víc času.

Zakončení

Jakmile jsou otázky za náma, zbývá říct už jen dvě věci - co bude následovat a rozloučení. Co následuje po rozhovoru? Za pomocí svých poznámek (viz dále) sepíšu jednoduché hodnocení s pozitivním, nebo negativním výsledkem, který se kandidát vzápětí dozví. Pozitivní skóre se rovná pozvání na osobní pohovor.

Jak si píšu poznámky

Když jsem s phone screeny začínal, psával jsem si poznámky přímo do vytištěného CV. Není to dobrý způsob - každé CV je jinak formátované, velikost bílých ploch na psaní je proměnlivá, je to neuspořádané atd. Jedinou výhodou je, že CV a poznámky jsou pohromadě.

Časem jsem ale zakomponoval lepší metodu - přímo během pohovoru si kreslím mind mapu. Stejnou metodu pak používám i u osobního pohovoru (Je to konzistentní a dobře se v tom hledá). Výhodou mind mapy je, že si daleko lépe připomenete, o čem jste si povídali. A taky to lépe vypadá. Navíc, mind mapa se mnou zůstane - zpracovaná CV vyhazuji, ale mind mapy si schovávám a archivuji.

Související články

• Jak dělám Java pohovor
• Jak dělám Java pohovor II: proč nedávám testy?
• Jak se nabírají Javisti na Filipínách
• Jak dělají Java pohovor jinde
• Měl by mít vývojář portfolio?
• Kontrakt místo pohovoru, je to reálné?
• Geek, který zapadne

Kanban, zprávy z fronty II

Máme za sebou, s týmem, další, úspěšnou implementaci Kanbanu. Projekt pomalu končí, je čas se ohlédnout. Jak to vypadalo, co fungovalo, co je potřeba zlepšit?

O projektu

Vzhledem k tomu, že z bezpečnostního hlediska se jedná o citlivé téma, nebudu psát nic o architektuře a technologiích. Což ale nevadí, protože z pohledu Kanbanu je obsah a typ projektu nepodstatný. Ale ať nám to povídání nevisí ve vzduchu, nastíním business case.

Výsledkem projektu je/bude webová aplikace, s jejíž pomocí si zájemci mohou online zažádat o různé typy víz a povolení (pracovní, k pobytu apod.) a také je eventuálně online zaplatit. Aplikace, jako taková, je velmi hloupoučká, veškerá business logika a workflow zpracování žádosti se děje na backendu, který už není součástí naší dodávky.

Team

Šlo o malý projekt, takže i malý tým - 2 vývojáři, 1-2 testeři/integrátoři, 1 technical leader, 1 project leader. Celkově (a konstantně během celého projektu) nějakých pět lidí. Pouze dva členové týmu měli předešlou zkušenost s agilním vývojem, s Kanbanem pak pouze jeden. Tým byl technicky seniorní, žádný junior.

Vizualize

Základním přikázáním Kanbanu je vizualizuj! Všechno, co jde (a dává smysl), vše, co dá lepší viditelnost projektu.

Kanban Board

První věc, která se (obvykle) vyzualizuje, je projektové/procesní workflow. Použili jsme jak fyzický, tak elektronický board. Ten elektronický byl založen na issue tracking (ITS) nástroji Redmine.

Bohužel, Redmine je, jako ITS, dosti nezralý/problematický a pro Kanban nemá žádný použitelný plugin. Problém jsme vyřešili "oklikou přes ruku" (= workaround) pomocí pluginu Wiki Lists, který dává přijatelný výsledek. Elektronický board byl primárním zdrojem informací a stavu.

Elektronický Kanban board (Redmine a Wiki Lists plugin)

Fyzický board byl druhotný zdroj informací. Používali jsme ho jako přirozené místo setkávání týmu (stand-upy). Další výhodou byla jeho neustálá přítomnost v open spacu. Takže všichni viděli :-)

Každý člen týmu byl zodpovědný za synchronizaci svých tasků mezi ITS a fyzickým boardem.

Fyzický Kanban board (stav na koneci projektu)

Co stojí za zmínku na fyzickém boardu: je zde název projektu a číslo aktuálního releasu, grafy statistik (viz dále), bankovky přivezené ze služební cesty. Předpokládám, že stavy workflow jsou samo-vysvětlující. Assignment jsem řešili pomocí labelů (Vit, Lub, Seb atd.).

Design kartiček

Na kartičkách, které na fyzickém boardu představují jednotlivé tasky, může být spousta informací. Na rozdíl od elektronické verze, kde bývá spousta atributů, má kartička jen omezený prostor. Proto je potřeba zvážit, jaké informace na ni dát, aby byla zároveň informačně dostačující a přitom srozumitelná. Velmi podrobně se tomuto tématu věnuje (výborná) kniha Kanban in Action.

My jsme začali a skončili u jednoduchého designu:

• ID z ITS ve formátu #nnn (levý horní roh).
• Zjednodušený název/summary tasku (uprostřed).
• Zkratka komponentu/feature/user story (zeleně, pravý horní roh).
• Délka setrvání ve stavu In Progress (červené tečky dole, tečka = den).
• Indikátor kritické priority (červený vykřičník, nahoře uprostřed).
• Indikátor blokace (červené B, pravý dolní roh).

Design kartiček

Class of Service

Když jsme projekt začínali, měli jsme všechny kartičky žluté. Postupně jsme pak zavedli classes of service. U tohoto konceptu je podstatné, že každá třída má přiřazenou specifickou politiku, jak s ní zacházet. Má třeba jiné workflow, jinou prioritu atd.

My jsme prvně odlišili tasky a bugy jiným workflow a bugy jsme na boardu odlišili růžovými lístečky (červené nebyly ;-)  Protože jsme měli zero bug policy, měl každý bug vždy vyšší prioritu než task.

Později jsme zavedli ještě jednu třídu pro tasky - má neintuitivní název intangible (termín přejímám z knihy Kanban in Action). Do téhle třídy spadají tasky, které nemají přímou, hmatatelnou business hodnotu, nicméně je potřeba je udělat. Jsou to věci jako různé konfigurace, interní dokumentace, refactoring apod. Tato třída měla (s výjimkou přípravy releasu) prioritu nižší, než task.

Třídy služeb (Classes of Service): žlutý - task, růžový - bug, zelený - intangible

Limit WIP

Moje zkušenost je zatím taková, že limitování WIP (Work In Process), je pro účastníky tou nejproblematičtější položkou Kanbanu - lidi vždycky nadávají, když jsou alokovaný na víc než jeden projekt, ale budou do krve hájit svůj "multi-taskinig". Myslím, že tady nás čeká ještě dlouhá cesta pomalé a trpělivé implantace principu stop starting, start finishing.

Malou podporu Kanbanu v Redminu už jsem zmiňoval. Limit WIP v něm nejde nastavit, tak jsme si ho definovali "jenom" jako politiku - každý by měl pracovat v daný čas jenom na jednom tasku. Fungovalo to jen z půlky dobře, vývojáři obvykle toto "omezení" dodržovali, testeři obvykle ne. Celkově bych ale řekl, že pokud je WIP nastavený jenom politikou, může to i přesto dobře fungovat. Chce to jen trpělivě lidi vzdělávat, jít příkladem a s klidem to vyžadovat. Poučení pro mne - být důslednější.

S WIP jde velmi často ruku v ruce otázka, co s blokovanými tasky? Není na to jednoduchá odpověď, částečně se to dá řešit flow, nebo politikou. Ale asi nejlepší je mít poučený tým - jak jsem kdesi četl (možná že Agile Samurai?) "zkušený agilní vývojář nikdy nezačne task, který není schopný dokončit". Čili prvně si task "před-nalyzovat" a odstanit rezistence a pak se teprve do něj pustit. Ne vždycky to jde, ale autonomní a uvědomnělý přístup členů týmu (opak skočím do toho pohlavě, neboli jdu rovnou bušit) mi dost často chybí.

Manage Flow

Kanban má rád autonomní lidi. Já taky. Kanban je pull system - když dám něco do TODO, vyhovuje mi, když to nemusím nikomu přiřazovat, ale libovolný člen týmu si to (podle svých schopností) vezme na starost. Jako team leaderovi mi to šetří obrovské množství času.

Jeden člen týmu měl s tímhle přístupem silný problém, bylo to pro něj příliš volné, "bez pravidel". Opět platí: vysvětlovat, vzdělávat. Plus, Kanban holt není pro každého, někdy si lidé a proces nesednou.

Workflow tasku na tomhle projektu je jedna z věcí, které se nám, myslím, dost povedly. Jedním z podstatných rysů flow byla silná podpora formalizovaného code review (můžete se těšit, až o tom Banter napíše článek).

Za zmínku stojí stav merge. Původně to byl jenom pseudo-stav (neměl svůj obraz v ITS). Ale vzhledem k asynchronní povaze našeho code-review procesu a občasné distribuovanosti týmu (home office, služební cesty), se vyplatilo z něj udělat svébytný stav.

Workflow tasku

Na počátku projektu jsme měli také samostatný stav pro blokované tasky. Ale pak jsme ho zrušili a nahradili blokujícím atributem přímo na issue. Důvod je prostý. Toto byl už druhý projekt, kde jsem měl v rámci Kanbanu stav blocked a vždycky to dopadlo stejně - tento stav se stal odkladištěm (až smetištěm) pro blokované tasky a nikdo (ani já) se moc nesnažil s tím něco dělat, odblokovat je. Řekl bych, že blocked atribute v tomhle funguje lépe a navíc není svázaný jen s jedním stavem - věci můžou být blokované ve vývoji, testování, integraci atd.

Další věc, kterou jsme v rámci flow zavedli byla fronta pro tasky čekající na otestování. Projekt byl z hlediska testerů podhodnocený, takže tasky se nám tam hromadily zcela přirozeně. V Kanbanu je to pěkně vidět - když se vám někde začnou štosovat lístečky, máte (možná) problém. Z hlediska teorie jde o úzké hrdlo a obvykle stojí za to ho trochu rozšířit, nebo odstranit.

My jsme to řešili dvěma způsoby: jednak jsme se zaměřili na automatizaci (Selenium testy), což pomohlo pouze částečně (testy fungovaly spíše regresně, než že by testovaly nově vyvinuté tasky) a jednak jsme úspěšně zalobovali za alokaci dalšího testera.

Statistiky

Se správou flow souvisí také jeho měření. Statistiky jsme používali, ale až takový přínost to pro nás nemělo. Z několika důvodů:

• Se sbíráním statistik jsme začali pozdě. To bylo dané hlavně téměř nulovou podporou a využitelností reportingu v Redminu. Polovinu údajů pro statistiky bylo potřeba získávat ručně. I při malém týmu to bylo dost pracné.
• Změny v našem flow byly celkem drobné. Ve spojení s předešlým bodem, je otázka, jak moc by se změny projevily a jak by to bylo průkazné.

Takže to byla spíš taková zajímavost a zkušenost pro příští projekt. Metriky, které jsme sbírali, byly throughput (propustnost, velocita) a lead time (trvání dokončení tasku).

Týdenní velocita

Statistiky jsme dělali jak pro "obecné" issue, tj. task bez ohledu na jeho typ a velikost, tak pro tasky odhadnuté pomocí triček (T-shirts). Ze statistiky tak např. vyplývá, že průměrná velocita týmu za týden byla 6 tasků, a průměrné dokončení tasku odhadnutého jako S trvalo 2,5 dne. (Dokončení je myšleno tak, jak ho chápe Kanban, takže vyvinuto, zreviewováno, otestováno, deployováno.)

Lead Time podle relativní velikosti tasků

Explicit Policies

Explicitní politiky jsou důležité. Je pak nad čím diskutovat a není to hospodská tlachačka o něčem "co všichni ví" a "takhle se to vždycky dělá". Obecně, nemělo by jich být moc, měly by být jednoduché a měly by být snadno přístupné. Naše politiky jsme měli na projektové wiki a zahrnovaly:

• Stand-up: jaký je jeho smysl a jaké má pravidla.
• WIP = 1: každý dělá v daný čas pouze na jediném tasku.
• Zero Bug Policy: každý reportovaný bug je automaticky kritický a musí být opraven, než se začne pracovat na novém tasku.
• Pravda je v ITS: primární zdrojem stavu projektu je trackovací systém. Každý je zodpovědný za aktuálnost a synchronizaci svých tasků.

Co mi chybělo a ocenil bych, je Definition of Done. Tak příště.

Implement Feedback, Improve Collaborativelly

Na rovinu, tyhle dvě věci nám moc nešly. Sice jsme měli retrospektivy, ale nevzpomínám si, že by to nějak ovlivnilo věci kolem Kanbanu, flow apod. Na jednu stranu to trochu chápu - tým byl Kanbanem nepolíbený, a autonomním se člověk nestane přes noc. Vysvětlovat, vzdělávat, působit. Chce to čas.

Pravidelné týmové aktivity

Následující praktiky nejsou součástí Kanbanu. Ale velice dobře se s ním pojí.

Stand-up

Denní stand-up, agilní to klasika. Pro popis bude nejjednodušší, když ocituju naši politiku:

The main purpose of the stand-up is that the team get the current context of the project.

The stand-up should be:

• short - max. 10 minutes,
• focused - see the main purpose above,
• with participation of the all team members,
• in front of the Kanban board.

The stand-up shouln't be used for:

• discussions which don't involve all the team,
• solving the technical problems.

If such situation happens (discussion, problem),

• it should be rather solved after stand-up,
• ideally in the phone box rather than in open-space,
• only with people who are interested/involved in the problem.

The typical stand-up participation is:

1. What did I do yesterday?
2. What will I do today?
3. What is blocking me.

U stand-upů se mi opět potvrdilo, to co u jiných agilních praktik - lidi, kteří s tím nemají zkušenost, můžou prvně "frfňat". Ale jen do té doby, než "to začnou dělat". Pak přijde něco jako prozření. Problém s akceptací jsme měli u jednoho člena týmu, ale potom, co jsme si to vysvětlili a deklarovali výše uvedenou politiku, už to bylo v pořádku.

Že to dobře fungovalo, můžu ilustrovat faktem, že tým nepotřeboval týdenní statusy (byly by zbytečné), protože stav všichni pobrali během stand-upů.

Retrospektivy

Retrospektivy jsme začali dělat cca v půlce projektu. Pro mne to bylo premiérové téma, proto jsem nechal retrospektivy řídit zkušenějšího kolegu a sám jsem se ponořil do studia. Hodně mi v tom pomohla kniha Agile Retrospectives.

Retrospektivy jsou pro mne ještě příliš čerstvé téma, takže je zatím nebudu hodnotit. Ale pocitově, intuitivně z nich mám dobrý pocit a chci je použít na dalším projektu.

Prioritizace

Prioritizovat je potřeba snad na každém projektu. Někdy víc, někdy méně formálně. V Kanbanu to může být stěžejní záležitost. U nás jsme se domluvili, že prioritizaci budou dělat technical a project leader. Naplánovali jsme to týdně na páteční ráno, aby bylo od pondělí jasno, co si lidi můžou brát.

Moc to nefungovalo, sešli jsme se jen párkrát. Přesto to nějak jelo bez větších zádrhelů, možná tomu napomohla automatická prioritizace vyplývající z classes of service (viz výše). U většího projektu by to asi byl dost problém. Prostě další oblast pro zlepšení.

Odhady

Na projektu jsme zavedli relativní odhady tasků pomocí triček (T-shirt estimations). Používali jsme velikosti S, M, L a XL. Pokud něco mělo velikost XL, bylo potřeba to dále rozbít na menší části. Pro odhadování samotné jsme používali planning poker s odpovídajícími hodnotami karet.

Odhady jsme dělali jednou týdně, většinou to zabralo hodinu. Členové týmu si stěžovali, že to jde pomalu (odhadne se toho málo), na druhou stranu oceňovali diskuzi, která nad tasky vznikla a umožnila tak lépe pochopit daný problém.

Odhady jsme začali dělat přibližně ve stejné době jako retrospektivy, takže neměly tak velký přínos, jak by mohly, kdybysme s nimi začali už na začátku projektu. Pozitivně vnímám, že je dělal celý tým. Naučili jsme se, jak používat trička a na dalším projektu budeme pokračovat.

Zhodnocení

Toto je druhý projekt, kde jsem aplikoval Kanban a potvrdilo se mi, že je to životaschopný a přínosný nástroj. Jako u všeho, co je tvořeno "měkkými" pravidly, hodně záleží na poučenosti lidí v týmu. Jednou z hlavních zkušeností je pro mne: vysvětlování není nikdy dost - tady se budu muset ještě hodně zlepšit. Ale doufám, že už jsem své kolegy naočkoval a příště to bude zase o něco snadnější.

Myslím, že učednická léta už mám v Kanbanu za sebou. Teď je potřeba zaměřit se na pokročilejší témata a zlepšit a dotáhnout do konce věci, jako jsou metriky, třídy služeb, plánování a odhady, používání modelů ad.

Už teď je jasné, že Kanban použiju na příštím projektu. Takže cca za rok si budete moci přečíst další díl tohoto článku. Nebo seriálu? ;-)

Mind Map

Související články

• Kanban, lehký úvod
• Kanban, zprávy z fronty
• Kanban z čistého nebe

Code review checklist

Nedávno jsem v práci prezentoval, jaké přínosné věci používáme na aktuálním projektu. Vyzkoušeli jsme si spoustu zajímavých nástrojů a praktik a v podstatě to byla taková laboratoř, kdy ty funkční záležitosti použijeme na dalším projektu. Mind mapa níže shrnuje přehled prezentovaných témat.

Jedním z nejcennějších realizovaných konceptů pro mne je, že se nám podařilo naimplementovat funkční a efektivní code review. (Doufám, že kolega Banter o tom brzy napíše článek.) A co čert nechtěl, po zmiňované prezentaci se nejvíc diskutovalo právě code review. Jedním z výstupů téhle diskuze je, že by bylo dobré mít nějaký code review checklist.

Já takový checklist nemám, protože ke code review přistupuju intuitivně (což ale neznamená, že nevím, co přesně chci, naopak). Nicméně pro potřeby diskuze jsem si sesumíroval, co by v takovém checklistu mohlo být.

Pozitivní věci na projektu (code review je fialový)

Co je to code review?

Ač se pojem code review používá v oblasti softwarového inženýrství dosti zhusta, má celkem nejednoznačný obsah. Pro někoho to je výsledek nástrojů jako je SonarQube, PMD, FindBugs ad. Tyto nástroje řeší tzv. statickou analýzu kódu a jsou výbornými pomocníky při udržování kvalitního kódu.

Ale code review, tak jak ho chápu já, začíná tam, kde tyto nástroje končí. Prostě tam, kde stroje selhávají, či nestačí, přichází ke slovu "stará dobrá ruční práce". Dalo by se to také nazvat jako asynchronní peer review.

Co je to code review checklist?

Checklist ((kontrolní) seznam bodů) slouží k tomu, abychom na něco nezapomněli. Třeba koupit chleba a mlíko cestou z práce. V případě code review jde o to, nezapomenout projít některý z aspektů, které chceme v rámci review kontrolovat.

Hlavní oblasti

Věci, které tak nějak intuitivně kontroluji při code review by se daly shrnout do těchto základní oblastí:

• Konvence
• Design
• Best-practices
• Závislosti
• Pokrytí testy

Konvence

Kdekoliv dochází k nějaké sociální interakci, jsou přítomny konvence. Buď již existují, nebo se začnou vytvářet. V dnešní době, kdy je vývoj software téměř vždy týmovou prací, je taková sociální (u některých programátorů a adminů spíše asociální) komunikace nevyhnutelná. Z hlediska code review, bych vypíchnul dva body, pro které je dobré konvence nastavit a dodržovat/kontrolovat:

• Formátování zdrojového kódu napomáhá jeho čitelnosti, pochopitelnosti, orientaci v něm atd. Tahle oblast se dá z větší části kontrolovat pomocí statické analýzy kódu (např. v Javě nástroj Checkstyle), ale některé věci zkrátka nejde nacpat do (automatických) pravidel. Domluvte se na nich, dodržujte je a váš reviewer vás bude mít rád ;-)
• Pojmenování. Věci by měly mít správná jména. Bude pak jasné, k čemu slouží, když se o nich budeme bavit, budeme více méně na stejné platformě a kdokoliv nový to lépe a rychleji vstřebá. Typicky, je dobré mít jmennou konvenci pro komponenty, balíčky, třídy, metody a proměnné. A cokoliv dalšího, co dává smysl a bude se vyskytovat ve více instancích.

Konvence jsou velmi rozsáhlé téma. A stejně jako u spousty dalších věcí, o kterých budu psát, dochází k jejich přesahu do jiných oblastí. Berme to rozřazení do základních kategorií jako velmi volné.

Design

Tohle je moje oblíbené téma, a tak zde budu mít nejvíc položek. Je to taky z toho důvodu, že kontrola designu je pro mne jedním z hlavních cílů code review. Kdybych si měl vybrat jenom jeden aspekt, který revidovat, byl by to jednoznačně design.

• Konceptuální diskuze. Důvod, proč často zamítnu reviewovaný kód je, že zavádí nějakou konceptuální změnu designu, která nebyla předem diskutovaná. Tohle má dvě složky. Jedna je subjektivní - mám určité designové preference a jelikož jsem většinou zodpovědný za architektonická rozhodnutí, tak je to moje právo a zodpovědnost. Druhá složka je týmová - pokud někdo "partizánsky" propašuje změnu, která bude ovlivňovat ostatní členy týmu, je to jasný důvod k zamítnutí. (Jen pro jistotu, partizánský zde má negativní konotace.) Obojí se dá jednoduše řešit zavedením designových review, kterých se účastní celý tým a kde se řeší design ještě před implementací.
• Testovatelnost. Nejsem TDD evangelista (v dnešní době?!), ale koncept a zkušenosti s unit testy mne jako vývojáře hluboce ovlivnily. Myslím si, že největší přínos a benefit unit testů je, že mají pozitivní vliv na design produkčního kódu. Kód, který je obtížně testovatelný, je prostě špatný.
• Konzistence. Systém/aplikace by měl být konzistentní napříč různými vrstvami, tj. odpovědnost jednotlivých vrstev/komponent, přístup ke zpracování výjimek, používané datové typy (třeba by pomohl kanonický datový model), přístup k logice (objektově, funkcionálně) atd.
• Znovupoužitelnost. Na úrovni knihoven, komponent, tříd, metod.
• SOLID. Systém/aplikace by měl respektovat dané/zvolené paradigma. V případě OOP by měl být "SOLIDní". Takže: Single responsibility, Open-close, Liskov substitution, Interface segregation, Dependency inversion. A objektový. Atd.
• Logování by mělo být smysluplné, odpovídající a se správnou severitou a formátováním. Občas mě zaráží, jak málo vývojáři přemýšlí u logování nad tím, že aplikace poběží většinu svého životního cyklu na produkci.
• Vyvarovat se: duplicity, komplexity, zanořené logiky (cykly, podmínky), věcí napevno napsaných v kódu (hardcoded). A smrtelně nebezpečné choroby DIY.

Zdroj: Dilbert.com

Best-practices

Best-practices asi není úplně nejlepší název pro tuto kategorii. A určitě není vyčerpávající a jistě mi leccos propadlo sítem.

• Kód by měl být čitelný a srozumitelný. Čitelný znamená, že po něm "oko dobře plyne", čemuž můžou napomoci konvence. A srozumitelný ve smyslu, že business logika by měla být jednoduše pochopitelná.
• Externalizace. Některé věci by v kódu neměly být vůbec: konfigurace, internacionalizace, to co patří do properties, řetězce literálů. Často je něco řešeno konstantama, místo použití enumů.
• Okomentovaný kód. Jestli je v kódu Javadoc se dá zkontrolovat statickou analýzou kódu. Jestli jsou ty komentáře aktuální, smysluplné a říkají to, co by měly, to už nám žádný nástroj neřekne. Pokud je kód čitelný a pochopitelný, mělo by v komentáři být popsaný hlavně výjimečné, či překvapující chování.
• Zakomentovaný kód. Jednoznačně vyhodit! Už nikdy se nepoužije a bude tam hnít roky.
• Neadresné TODO. Podobně jako zakomentovaný kód. Pokud mají vaši vývojáři potřebu si psát do kódu TODO, ať se tam aspoň podepíší. Stejně už se k tomu nejspíš nikdy nevrátí. Možná je to moje úchylka, ale nesnáším (měsíce, či roky staré) TODO v produkčním kódu.
• Komity do VCS by měly být malé, časté, smysluplné a měly by řešit pouze jedinou věc. A měly by mít rozumný komentář, ideálně nastavený konvencí. Když vidím komit/changeset, kde někdo opravil "půlku internetu", otevírá se mi imaginární kudla v kapse.

Závislosti

Ve zkratce, měli bychom si dát pozor, co nám kdo do aplikace/systému zatáhne. To se týká hlavně externích knihoven, ale také interní závislostí mezi jednotlivými vrstvami a komponentami.

Není to tak dávno, co jsem si tuhle říkal "proč je ta (Java EE) aplikace tak veliká?". Vypíšu si strom závislostí a ona je tam přibalená půlka Springu?!? Uf.

Pokrytí testy

Přiznám se, jednou jsem dělal na aplikaci, která měla 96% pokrytí testy. Ale jinak, nejsem žádný fanatik přes testy. Nicméně "rozumné" a "dostatečné" pokrytí testy by aplikace měla mít. Zejména business logiky. Naopak, není potřeba testovat platformu, či frameworky.

A kde je ten checklist?

Jak jsem psal v úvodu, tento článek je zamyšlením, co by v code review checklistu být mohlo. Možná, kdybych přemýšlel dost dlouho, tak bych dal dohromady i nějaký reálný checklist. Ale nechci. Mám rád, když jsou nastavená nějaká pravidla, ale musí umožňovat dostatek volnosti. Aby se dalo dýchat, aby nepotlačovaly invenci a motivaci. Diskuze je daleko důležitější, než mít nějaký papír na odškrtávání.

Mind map