Zpětná vazba z technické komunity

Owned by Tomáš Znamenáček
Last updated: 27. May 2021
4 min read

Témata

Přehlcení a pocit závazku

  • Nadměrný počet kanálů, zpráv, pojmů a rolí

  • Velký počet dobře myšlených rituálů (Strom vděčnosti, retrospektivy, snídaně & obědy, …), které můžou na někoho působit uměle, zvlášť zpočátku zapojení

  • Zapojení v Česko.Digital působí jako velký závazek, dobrovolníci se bojí, jestli jsou mu schopni dostát

  • „Začal jsem být rád, že stíhám sledovat projektový kanál“

  • „Pocit, že mi niečo uchádza a nemá zmysel sa toľko snažiť, aj tak nestihnem všetko monitorovať“

  • „Vnímám nedostatek kapacit z mé strany – tempo projektu (a možná i Česko.Digital) už není tolik kompatibilní s prací po večerech a o víkendu“

Jdu kolem vs. dlouhodobé zapojení

  • Na GitHubu nejsou prakticky žádné issues, většina věcí je v Trellu a vyžaduje kontext, komunikaci, onboarding

  • „Byznysová“ očekávání termínů nás táhnou pryč od režimu „jdu kolem a něco drobného si naprogramuju” k pevnějším závazkům, stálejšímu zapojení dobrovolníků na projektu

  • Režim „najděte si task na GitHubu a zapojte se bez závazků“ nám fungoval na webu, ale velmi pomalu

  • Shrnuto: Režim „jdu kolem a něco si naprogramuju“ má minimální bariéru, ale taky minimální rychlost. Stabilnější zapojení vyžaduje větší motivaci – shodu v technologiích, silné souznění s tématem projektu, větší počet dobrovolníků s podobnou kompetencí (vzájemně se zastoupíme) a podobně.

  • K tomuhle systému viz též náš starší rozhovor s COO Code 4 Romania ⤵︎

Náš průměrný programátor je seniorní vývojář něco po třicítce, obvykle s rodinou, v práci už se moc k programování nedostane, je team leader nebo projektový manažer. A děsí se všech těch drobností, které je potřeba udělat, aby se projekt posunul dopředu – rozdělování práce, dokumentace, testování, a tak dále.

Původně jsme se snažili napodobit tradiční IT firmu, měli jsme koordinátory projektů a k nim tým se všemi běžnými profesemi, UX designérem, někým přes komunikaci, textařem, tech leadem a podobně. Zkoušeli jsme to jeden celý rok a nefungovalo to, především protože nikdo nechtěl dělat rutinní práce. Uvědomili jsme si, že musíme co nejvíc věcí automatizovat, což se podařilo, ale problém to nevyřešilo. Nakonec nám došlo, že potřebujeme větší základní tým. Takže teď máme v základním technickém týmu 8 lidí, z toho jeden je náš CTO. A těch osm lidí se stará o veškerou infrastrukturu (všechno kolem GitHubu, repozitáře, …), o návrh architektury řešení, organizaci práce. Takže jako programátorovi už vám stačí přijít k projektu, nabrat si úkoly a podle času se do nich pustit.

To má tři základní výhody. Za prvé už se nám veškeré informace o jednom projektu neschází v jedné hlavě – místo toho ví o všech projektech všechno osm lidí, takže už není problém poskytnout potřebnou podporu dobrovolníkům. Za druhé výrazně investujeme do dokumentace projektů, takže kdo chce informace, najde je. A za třetí se nám podařilo minimalizovat čas, který je potřeba pro nastavení pracovního prostředí, takže se každý může co nejrychleji pustit do práce.

Dál bylo potřeba vyřešit rytmus vývoje. Při práci s dobrovolníky nikdy nevíte, co se stane – narodí se dítě, umře kočka, zkrátka se v životě dějí věci, které dobrovolníkům znemožní prioritizovat práci pro nás. My ale zároveň nemůžeme zastavit celý tým. Takže každý měsíc uspořádáme ve čtyřech rumunských městech hackday, pracovní den, na kterém se 12 hodin programuje. Není to hackaton, hackatony my neděláme. Je to prostě den, kdy můžete přijít někam s notebookem a programovat s ostatními. A za jeden takový den se obyčejně udělá tolik práce, co za měsíc běžného vzdáleného provozu. Díky tomu si udržujeme stabilní rytmus. Všichni vidí, že se pokročilo dopředu, a technický tým nemůže uváznout ve fázi code reviews. Ten měsíc prostě musí být hotovo. Je to taková vražedná spirála, kterou záměrně roztáčíme, abychom lidi přiměli k práci :–)

Iterativní vývoj vs. vodopád

  • „Namísto rychlého spuštění minimální verze a další práce v iteracích jsme se snažili vše ladit a plánovat do nejmenšího detailu”

  • „Do budoucna bych se vyvaroval waterfallu, nebál bych se cesty postupných vylepšení (změna fontu → barev → patičky, …)“

Míla shrnuje & navrhuje

Revize onboardingu

Jak se dobrovolník cítí, když přichází zvenčí?

  • Postupovat na dobrovolníky pomalu

  • Pozvat je jen do kanálů, kde opravdu být mají/chtějí, ideálně jen jeden

  • Co nejméně používat hromadné notifikace

Tasky k rozebrání

Zamyslet se nad tím, jak strukturujeme úkoly a jestli jsme schopni tento proces unifikovat napříč projekty.

  • Mít připravené malé, jasně popsané úkoly jako issues na GitHubu a počítat s tím, že bude trvat delší dobu, než se vyřeší

  • Pokud Trello, tak mít jasně oddělené, co jsou úkoly pro vývojáře

  • Marketplace těchto menších úkolů, možná i nezávisle na projektu: „Chtěl bych si zaprogramovat, kde můžu pomoct?“ Já vlastně nevím. Musím procházet kanály a hledat kontext. Jak můžeme podobné úkoly nabízet – Slack bot? Trello? GitHub organizace?

Jdu kolem vs. dlouhodobé zapojení

Co vlastně budujeme? Je komunita set rolí na projektech, které naplňují konkrétní lidé, nebo je to velká skupina lidí, která plní dílčí úkoly a občas z ní někdo přeskočí do něčeho dlouhodobého? („Lidi na roli vs. lidi na úkol“)

Zdroje

Zpětná vazba k webu

Zpětná vazba k zapojování technických lidí