Lekce 3 - Firemní kultura a benefity

V minulé lekci, Požadavky na juniory a vzdělávání, jsme se zaměřili na požadavky kladené na juniory a na roli vzdělávání.

Jindřich Máca se věnuje programování profesionálně zhruba 20 let. Vystudoval fakultu informačních technologií na ČVUT a primárně se zaměřuje na webový vývoj. Léta byl redaktorem a lektorem kurzů v ITnetwork.cz a nyní se ve volném čase věnuje také mentoringu. Téma přednášky, kterou pro nás připravil, je porovnání toho, jak probíhá agenturní vývoj v české a zahraniční firmě, resp. jak to chodí na českém a zahraničním trhu. V této části se zaměříme na firemní kulturu a benefity.

Máš pocit větší seberealizace, když jsi ve větší a světové firmě?

Řekl bych, že ano, a to díky velikostí a zaměření firmy. V té menší jsem musel skákat mezi několika projekty najednou a řešili jsme různé věci, protože nebylo tolik vývojářů. Takže jsem byl hodně vytížený. Tady mám svůj projekt a pracuju relativně na pohodu. Myslím si také, že i díky některým experimentálním projektům je moje seberealizace větší.

Mám zde i větší pocit, že se každý může zapojit a přidat i svůj názor na to, jak by měl projekt vypadat a co by mohl obsahovat. Firma se také zaměřuje na trh, který je více otevřený a inovativní.

Jaké jsou ve velké firmě benefity?

STRV má opravdu pěkné kanceláře. Není si na co stěžovat. Máme vlastní fitko, soukromý bar s pivem a kofolou na čepu, máme fotbálky, kulečníky, ping-pongy, jezdíme tam na koloběžkách. Tohle si člověk nejvíc užívá, když tam nastoupí. Postupně to pozlátko opadne. Je to příjemné, ale až tak důležité to není.

Máš vůbec čas ty benefity využívat?

Samozřejmě, že mnoho času na to není. Na koloběžce jezdím, protože člověk stále pospíchá na nějaký meeting. Párkrát do týdne si ten fotbálek zahrajeme. Potřebuješ k tomu ještě další hráče, tak se musíme zorganizovat. Buď po obědě nebo večer a k tomu si natočíme něco na baru. Fitko je super v tom, že ho člověk využije především po nebo před prací.

Ceremonies jsou pak různé. V české firmě jsme měli každodenní stand-upy, ale tady to tak často není. Není potřeba je dělat tak často. Někdo také dělá retrospektivu po každém sprintu, někdo řekne, že uděláme retrospektivu jednou za měsíc, nebo po dvou až třech sprintech. Nebo ji uděláme ad hoc, když je to potřeba.

Máme většinou agilní metodiky - někde v systému máš úkoly a zadání a sám si plánuješ menší úkoly a co chceš dělat dál. Vše ostatní nemá s danými metodami už moc společného, protože není zase až tak důležité ty metodiky dodržovat do puntíku.

Třeba na malé appce, kterou jsme dělali dva měsíce, jsme neměli žádný stand-up nebo naceňování. Měli jsme týdenní sprinty – tady je pět featur, které se mají tento týden udělat a jedeme dál.

Naopak s kolegou z Brazílie jsme si dali synchronizace, protože jsme v jiných časových pásmech. Zkrátka jsme potřebovali mít způsob, jak si předávat kontinuálně práci. Takže jsme si sami nastavili své synchronizace a nebylo třeba dělat stand-upy s úplně celým týmem. Ten projekt jsme dokončili dřív, než se předpokládalo. Dokonce jsme udělali i věci navíc a klient z nás byl nadšený.

Jak probíhá proces delivery?

Záleží projekt od projektu. V rámci sprintů mají někteří release per sprint – dodělají se nějaké featury a pak následuje release. Některé týmy razí spíš continuous delivery – rovnou se vydá cokoliv se udělá a schválí, kontinuálně. Hodně záleží, jak se nastaví procesy a jak se nastaví očekávání daného klienta.

Někteří čekají, že když jsi slíbil, že uděláš těchto pět featur, tak je uděláš. Řeknete si pak s klientem, jestli se mu to líbí nebo ne, jestli ten progres vydáme nebo nevydáme. Někdy si klient bude diktovat požadavky a podle toho, jak je budeme plnit, tak je bude vydávat. Tam musí být nastavený roll-back. Pokud by změnil názor a řekl, že se mu to najednou nelíbí, na kliknutí se vrátíme do předchozí verze. Sporná část se předělá a vydá znovu.

Jak probíhá testování, když máš dva měsíce na vývoj?

Záleží na tom, jestli máš vůbec testery a jak si s nimi nastavíš proces. Také záleží, jak moc je chceš zainteresovat do celého projektu. A samozřejmě je důležité, co ten tester bude testovat.

K testování máme Quality Assurance (QA) – celé oddělení na zajištění kvality daného softwaru. Je to dost často kolaborace a nastavení nějakého očekávání. My třeba máme navrženy na back-end integrační testy na všechny end-pointy. V rámci automatizace máme pokryto všechno testy a většinou není potřeba používat nějakého Postmana nebo něco na testování API. To se děje kontinuálně.

Dost často se QA soustředí na front-endovou část aplikace. Ne vždy se odchytí vše – například vizuální bugy. Záleží na tom, zda máš nastavený staging environment. Pokud ten projekt nemá nastaven continuous delivery, ale staging environment, míří kandidát připravený na uvedení na trh do stagingu. Tam se řekne, že aktuálně má tyto featury, které se budou vydávat. Předá se to QA a ti si poradí s testováním. QA mohou mít také nastavenou částečnou automatizaci třeba pomocí Cypressu. Projedou si základní flow - regresi, smoke testy, jestli je ten kandidát připravený, zareportují bugy a podobně. Během toho my pracujeme na úplně jiných doplňcích, takže se tomu musí přizpůsobit branching strategie v Gitu. Člověk musí vždy přemýšlet nad tím, jak si projekt nastaví a vykomunikuje.

Ze začátku je vývoj intenzivnější a ke konci projektu se spíše klade větší důraz k nápravě bugů. To souvisí i s flow - občas přijde nějaký bug report. Na back-end toho ovšem mnoho nechodí, díky těm automatickým testům to funguje. Samozřejmě člověk občas zapomene na nějaké edge case a tak. Hodně bugů se týká spíše vizuální stránky nebo něco není podle zadání. Tyto problémy se týkají většinou front-endu.

Jak projekt dostane zelenou od QA, měl by se prezentovat klientovi, jestli něco nechce změnit. Někdy také klient kouká na projekt průběžně a hlásí už během projektu, co by chtěl jinak. Když je staging v pořádku a všichni jsou spokojení, následuje produkce. Někdy se QA testuje ještě v produkci, hlavně smoke testy na flow.

U nás jsou QA oddělení lidé, kteří mají technické znalosti. Stejně tak i designeři. Když na to přijde, umí naši QA otestovat API a napsat si automatizovaný test. Nehledí se u nich tolik na kvalitu kódu, ale na jeho účel.

Jaká máte vlastně další oddělení?

Máme velké sekce technické i netechnické. Technická sekce je obrovská, takže je rozdělená na menší oddělení. Patří sem back-end, front-end, Android, iOS, Data Science, QA, Design a IT Support. Netechnická se skládá z HR, Sales, Marketing, Finance, Project management. Zkušenější projekťáci ale mají i slušnou technickou znalost.

QA je sice separátní oddělení, které je zodpovědné za kvalitu, ale i tak jsou součástí týmu. Podílejí se na všech fázích vývoje. Dobří QA zastřešují tasky, které se plánují – odchytí třeba i to, že zadání testu nedává smysl, nebo že nekoreluje s ničím v daném projektu. Já na back-endu třeba napíšu test a přemýšlím, kterými vstupy bych kód rozbil a napíšu někomu z QA o radu. On mi pomůže a já jemu ušetřím práci. Je to opak přehazování horkého bramboru mezi odděleními. Zkrátka spolu kooperujeme jako součást jednoho týmu.

Každé oddělení má své lidi. Ti nad sebou mají jednoho či více leaderů. Leadeři se koordinují mezi sebou, třeba i na nových projektech. Zároveň pak nad nimi jsou lidé na C-level (CEO, CFO, CPO atd.), kteří se koordinují mezi sebou a s lídry. Pak jsou majitelé, ale ti do toho moc nemluví. Celá ta struktura je relativně plochá.

Český trh je docela start-upový, liší se od amerického?

Tady v Česku dostanou start-upy mnohem snáze investici a pak sami nevědí, co s ní správně dělat. Amerika je mnohem více kompetitivní. Získat tam investici není vůbec jednoduché a není ani jednoduché, jak naložit s těmi penězi. Česká start-upová scéna zažila svůj boom a teď se to začíná uklidňovat. Všichni se učí z prodělaných chyb a pokračují už správným směrem. V Americe to už takto funguje delší dobu. Lidé v americkém start-upu už ví, co od produktu chtějí. Sami si jdou za NVP a mají přesně spočítaný budget a cíle. V českých start-upech takových přímočarý přístup chybí, alespoň taková je moje zkušenost. Chtějí to mít dokonalé a bojí se, aby jim to někdo neukradl. A pak to často nedopadne nijak. Úspěšné české start-upy jely naopak tím americkým stylem – pojďme to co nejdřív dostat mezi lidi.

V příští lekci, Praxe ve firmě a práce na zakázkách, se zaměříme na firemní praxi a způsob práce na zakázkách.