Co tvoří produktivní prostředí?

Nedávno jsem se zamýšlel, co v mém případě činilo rozdíl mezi tím, kdy mě bavilo co jsem dělal a tím, kdy jsem pouze docházel do "práce". Co dělá člověka kreativním a co naopak pasivním. Uvědomil jsem si, že je v mém nejlepším zájmu přičinit se o to, aby v práci vzniklo kreativní prostředí, protože jenom tak budu mít pocit, že práce, kterou dělám má smysl. K tomu, aby bylo možné tento stav ovlivňovat, je však nutné rozlišit faktory, které na něj působí a na jejich základě zjistit, zda s těmito faktory dokážeme ze své pozice hnout, nebo nikoliv.

Absence kreativního prostředí, je pro mne byla pádným důvodem, proč jít tam, kde toto prostředí bude nebo, kde bude potenciál k tomu, aby vzniknout mohlo. Kreativní prostředí je něco, co žene lidi dopředu. Je to synergie mnoha faktorů, která celek činí něčím, co je víc než pouhý součet částí.

Zásadní vliv na kreativní prostředí mají podle mého názoru:

Lidé

Po čase jsem dospěl k názoru, že na lidech nejsou nejcennější znalosti nebo inteligence. Jsou to jiné lidské vlastnosti, které přispívají k fungování týmu a činí člověka hodnotným a prospěšným. Odpovědnost, ochota pomoci, zájem o obor a férový přístup. Cením si toho, když si můžu i u piva popovídat o Javě, technologiích a zkušenostech, aniž by někdo namítal, že se bavíme o práci. Jsem rád, když se můžu zeptat na radu a dostane se mi odpovědi, nasměrování a nebo odkazu na příklady - a to i v případě, že máme všichni plné ruce práce. Je pro mě velkým přínosem, když lidé v týmu sami přemýšlejí, jak věci zlepšit, tak abychom zbytečně nezabíjeli čas něčím, čím nemusíme. Jsem rád, když se můžu se šéfem bavit jako rovný s rovným, a on svých pravomocí používá jen výjimečně a to způsobem, který se jeví racionální (a že takových šéfů není zase tak moc). Vážím si lidí, kteří berou svoji práci vážně a nečiní hranice mezi svojí a cizí prací, pokud je to v zájmu projektu. V tyto lidi vkládám svoji důvěru a naopak se snažím jejich důvěru nezklamat.

Lidé jsou nutný základ, bez kterého to nejde. Zkušení lidé jsou sice výhodou, ale všichni jsme nějak začínali a sám vím, že zkušenost lidí nehraje ve vytváření kreativního prostředí tu zásadní roli. Někdy to může být i naopak - byl jsem svědkem případů, kdy jeden zkušený vývojář na sebe strhnul veškeré rozhodování a odpovědnost a v podstatě komunikaci v týmu zničil. Nedostatek nebo nevyrovnané znalosti a zkušenosti v týmu, lze řešit např. párovým programováním. Osobní kvality člověka, se však naučit nedají.

Lidé jsou jedna z nejdůležitějších věcí vůbec. Je to zároveň ale i jedna z věcí, kterou můžete ovlivnit nejméně.

Komunikace a spolupráce

Základem je bezbariérová komunikace - pro nikoho nesmí být problém jít za kolegou a vyřešit, co je zapotřebí. Tým musí společně fungovat - pokud funguje na různých místech republiky, měl by se pravidelně jednou za čas sejít a mít možnost vyřešit věci, které jsou jim všem společné (kromě toho, že se budou znát i jinak než přes nicky ve Skypu nebo Jabberu).

Čím přímější komunikace, tím rychlejší výměna zkušeností a řešení problémů. To co vyřeší deset minut společné diskuse u tabule s fixkou, těžko nahradí půldenní mailová komunikace. Důležitost komunikace však neplatí jen v rámci týmu, ale i celého oddělení (pokud spolu týmy nekomunikují, jejich zkušenosti, vylepšení a knihovny často zůstávají pouze uvnitř týmu a pro společnost nemají takový užitek).

Agilní metodiky jsou si tohoto vědomy. Staví na společné odpovědnosti a rozhodování (Scrum - plánování a odhady na začátku sprintu) pravidelném osobní setkávání (Scrum - denní skrumáž).

Likvidace překážek

Aby mohl být člověk / tým kreativní, musí čas trávit na kreativních věcech. Pokud svůj čas tráví obtížně navrženým testováním, složitým buildováním svých projektů, řešením kompetencí nebo nedej Bože plněním byrokratických nařízení a pravidel - těžko se od něj dá čekat kreativita a zápal pro práci.

Lidé reagují na překážky a obtíže různě. Pokud jsou nuceni k vykonávání nepříjemné a obtěžující práce, snaží se jí buď odbývat nebo jí odsunovat co nejdále, v naději, že ji třeba nakonec z "objektivních" příčin nebudou muset dělat. Podobný efekt s sebou nesou i činnosti, které nemají žádný viditelný přínos. K čemu je psaní javadocu, který se na sdíleném serveru zaktualizuje jen tehdy, když má někdo náladu? Proč se namáhat s psaním knihovny, se kterou se člověk nemůže efektivně podělit s ostatními?

Kolik projektů je bez čárky dokumentace nebo testů, u kolika projektů se první instalace na testovací prostředí provádí až na úplném konci, kolik kódu se zpatlalo jen proto, že to bylo v tu chvíli jednodušší?! Ve výsledku jedny bariéry staví jen bariéry další. Kdykoliv člověk narazí na to, že něco dělá nerad nebo s obtížemi, je to chvíle k zamyšlení, jak dané věci změnit. A přitom někdy stačí udělat jen malý krok k tomu, aby se bariéry odstranily nebo zmenšily.

Build projektu a instalace na testovací prostředí (tím nemyslím lokální vývojové prostředí) by měla být podle mého názoru záležitost několika málo minut, při které by člověk neměl být nucen nějak intenzivně přemýšlet. Commit do SCM by měl být záležitostí podmíněného reflexu a pozornost vývojáře by měla být rozptylována jen ve výjmečných případech (konflikty, neprojde kompilace / testy na CI). Dokumentace pokud se má vytvářet musí být dostupná ostatním téměř online - s každým buildem automaticky i přegenerovaný javadoc / jar se zdrojáky. Vývojáři by neměli být nuceni myslet na to, co musejí udělat, aby se dostali k aktuální dokumentaci - ta by prostě měla být vždy k dispozici v jejich IDE bez nutnosti extra práce.

Úpravě cizího kódu by nemělo bránit nic většího než zajištění zpětné kompatibility a projití automatických testů. Code revision by neměla blokovat napsání kódu v cizí knihovně, pokud jej potřebujeme pro využití ve své aplikaci - revizi stačí dělat před releasem. Vlastnictví kódu má negativní vliv na rozvoj sdílených knihoven - je častokrát jednodušší vytvářet věci jen pro svůj projekt, než podstoupit martyrium injektování daného kódu do cizí knihovny. Problém se potom řeší mnohokrát znovu a znovu, místo toho aby se vypilovala společná knihovna - velké množství času tak vyhazujeme oknem.

Při vytváření nové knihovny by se měl člověk věnovat pouze tomu, jaké jsou důvody k jejímu oddělení od ostatního kódu, jaká je její znovuvyužitelnost, jaké budou její kompetence a účel. Nikdy by člověk při tomto uvažování neměl být brzděn představou náročnosti vytváření adresářové struktury, zapojení do buildovacího procesu, vytvoření infrastruktury pro testy, zavedení do SCM, vytvoření podpory v CI atd. Tyto záležitosti by neměly být tak náročné, aby v uvažování o nové knihovně hrály roli.

Pokud vezmu za příklad opět onu zmiňovanou Scrum metodiku - v ní existuje speciální role zvaná Scrum master. Jedním z jejích hlavních účelů - ne-li důvod hlavní je, postarat se o identifikování a odstraňování překážek, která brání týmu v jejich práci. To jen podtrhuje jak důležitou roli můžou ve fungování týmů představovat podobné překážky.

Prostředky a nástroje

Tým by měl být tým vybaven odpovídajícími nástroji a prostředky. Většina vývojářů jsou navíc hračičkové, kteří si rádi hrají s hi-tech technologiemi a hi-tech hardwarem. Rádi se pochlubí ostatním na jakých strojích pracují a jsou taky ti první, kteří začnou mrmlat pod vousy, že ta jejich šunka je furt zamrzlá. Dobré vybavení něco stojí, ale na náladu v týmu má podle mého názoru značný vliv.

V oblasti SW je vývoj poměrně unikátní - většinu potřeb bohatě pokryje open-source řešení, které management společnosti nestojí ani korunu. V opodstatněném případě, by se však vedení nemělo rozpakovat nad tím, vybavit své vývojáře nástroji, které jim umožní trávit svůj čas efektivně. Z vlastní zkušenosti musím říct, že to vůbec není věc samozřejmá - spíše naopak. O to víc si teď vážím toho, že mohu pracovat na legální kopii IntelliJ Idey a používat ty nástroje, které jsou pro rutinní / podpůrné činnosti nejefektivnější. Nemusím trávit mnoho času obcházením nedokonalostí nástrojů, které používám ke své práci.

Možná jsem mluvil dosud jen o SW, ale hardware je v podstatě stejným "nástrojem" jako vývojové prostředí. Kolik firem má politiku pravidelného obnovování HW (tím nemyslím s iterací 1x za 5 let ;-) )? Ve které firmě dostanete jednou za čas na stůl nový notebook, aniž byste o něj krvavě poslední rok bojovali? Když řeknu polovina, možná ještě dost přeháním. Všechno toto však výrazně přispívá k maximálnímu FLOW, které ústí v kreativitu a efektivitu.

Ocenění a uplatnění

Dalším důležitým motorem, který žene vývoj kupředu je ocenění kvalitní práce - nemluvím zde jen o penězích, na stejných vahách leží i respekt, autorita a důvěra. A také uplatnění artefaktů, které v procesu vývoje vznikly - tedy fakt, že knihovny / technologie / vylepšení / procesy, za kterými jednotliví vývojáři stojí, se ve společnosti prosadily a že se skutečně používají. Toto je samozřejmě již výrazně závislé na kvalitě vytvořených artefaktů a tedy na vývojářích samotných - nicméně i z hlediska vedení a atmosféry týmu musí být cítit, že dveře jsou reusovatelným věcem otevřeny a že je cesta tímto směrem preferována (např. tím, že je ochota věnovat na rozvoj větší prostředky než jen, co firma získá z implementace u jednoho zákazníka).

Zavěrečným bodem, který bych zde chtěl uvést je důležitost synergie mezi obchodem a vývojem (což je věc v mnoha firmách problematická). Ideální vazba by podle mého názoru měla být ta, že obchod primárně nabízí a prodává portfolio vytvořené vývojem, naopak vývojáři rozšiřují portfolio na základě potřeb obchodu. To předpokládá fungující komunikaci mezi odděleními.

Zdá se to možná jako logická věc, ale až příliš často jsem se setkal s tím, že obchod v honbě za zákazníkem generoval natolik různorodá zadání, že nebylo možné zhodnotit vývojem již vytvořené produkty. Ve výsledku se tím společnost připravuje o zisk, protože reusovaná řešení mají dva pozitivní efekty - zisk a snížené vývojové riziko.

Často narážíme na problémy odlišných motivací - obchodníci mají podíly z počtu a objemu uskutečněných obchodů. Vývojáři jsou motivováni dokončením projektu včas a v dostatečné kvalitě. Pokud tyto motivace nemají společnou linku, může to vést i k tomu, že si obě oddělení ve výsledku "škodí", což ve výsledku neprospívá nikomu.

Prototypy - možnost hraní si a zkoušení

Důležité v procesu vývoje je možnost věnovat se i prototypovým projektům. V mém pojetí je protopový ten projekt, kde je možnost vyzkoušet si novou technologii a kde nebudou mít případné nedokonalosti a chyby dané prvním použitím - popř. samotné ověření nevhodnosti celé technologie (postupu), výrazné dopady na výsledek projektu, tým nebo dokonce celou společnost. Někdy se prototypové projekty obtížně hledají (pokud nechceme vytvářet umělé "interní" projekty) a tento přístup asi není univerzální pro všechny, nicméně v našem případě, kdy funguje, má velmi pozitivní dopady.

Produktivní zatížení

Ač se to na první pohled nemusí zdát má na kreativní náladu v týmu zcela zásadní vliv, pravidelné zatěžování smysluplnou prací. Tedy, že jsou týmu předkládány projekty, tak aby mohl pracovat ve stálém tempu. Pokud existují období, kdy se nepracuje na žádném reálném projektu, začínají vývojáři zvažovat, zda toto nemůže být hrozbu pro jejich práci nebo pro ně samotné - začínají se zabývat něčím, čím by se zabývat neměli. Pokud chceme mít produktivní tým, musíme jejich produktivitu využívat - úkolově zaměření lidé potřebují vidět výsledky své práce, musí mít pocit, že jsou prospěšní a musí svou produktivitu "cítit". Pokud toto nemají jejich motivace a kreativita se začne vytrácet. Jistě znáte ten pocit, kdy vás první dny bez práce baví, máte ještě plno věcí, které jste chtěli dodělat, vyčistit si stůl i hlavu, vyzkoušet některé nové věci, na které nebyl dřív čas. Jenže to funguje jen po omezenou dobu, pak už nastoupí takový nepříjemný pocit ...

Podobný efekt i když, řekl bych, méně fatální je naopak přetěžování týmu. Tým je možné dočasně přetěžovat, pokud je toto přetěžování vyváženo např. odměnami nebo volnem. Tato varianta je na efektivnost / produktivitu v krátkodobém horizontu dokonce pozitivní. Při dlouhodobějším přetěžování se však efekty na kreativitě začnou podepisovat - řada věcí je odkládána na dobu, až na to bude čas, je přistupováno ke kompromisním řešením, která jsou rychle realizovatelná a v té době vyhovují, snižuje se kvalita výstupního produktu (a tudíž se zvyšuje riziko).

Závěrem

V článku jsem chtěl zachytit mé postřehy z mé dosavadní praxe ve vývoji. Jedná se na o můj subjektivní názor a retrospektivu z pozice, ve které se nacházím nyní. Pro mě samotného je přínosné, že jsem si mohl v průběhu psaní tohoto článku, vytříbit myšlenky a uvědomit si, co je z mého pohledu pozitivní a které hodnoty já sám musím prosazovat, pokud chci pracovat v kreativním a produktivním prostředí. Protože většinu toho v čem žijeme si vytváříme sami.