Produktivita vývojářů – 9 nejhorších škodičů

1. Vyrušení a schůze/online hovory

Neustálé pípání notifikací z komunikačních kanálů a e-maily patří mezi klasické rušiče. Dostat se zpět do tvořivé zóny vývojářské mysli a pokračovat tam, kde jste byli před pauzou, může trvat i 30 minut. A čím více vyrušení je, tím je větší frustrace, práce je méně kvalitní a vzniká více chyb.
Řešení: Pokud si nemůžete notifikace na několik hodin vypnout, nastavte si oznámení pouze z kanálů, které se vás bezprostředně týkají.

Rozdíl mezi vyrušením a schůzkou je ten, že je plánována. Dopad je ale stejný, možná horší, protože vývojář ví, že se nemůže naplno do práce ponořit. Jedna schůzka například okolo jedenácté hodiny zajistí, že se během dopoledne žádný velký úkol nedokončí.

Řešení: Krátké schůzky hned na začátku pracovního dne nebo těsně před obědem.

2. Neurčitost

TA nejen zdržuje ale umí znechutit tak, že vývojář uvažuje o odchodu. To, že něco nefunguje, není zadání! Bug report by měl obsahovat dostatek informací, aby vývojář věděl, jak na věci pracovat. Jinak ztrácí čas zjišťováním a přemýšlením.

3. Racčí management

Určitě jste o něm už slyšeli. Jedná se o managery, kteří nejsou až tak do projektu zapojeni, ale i přesto jednou za čas přiletí a vše “podělají”. Bez dostatečného množství informací vše okamžitě zkritizují: To vypadá strašně. Opravte to.” Pro vývojáře je tento typ chování velice demotivující a pracovní drive se může snížit i na několik následujících dní.

Řešení: K projektu by se měli vyjadřovat lidé, kteří si o něm zjistí dostatečné množství informací

4. Zásluhy

Stává se to celkem často. Zásluhy za práci vývojáře si přivlastní jiný vývojář nebo manažer. To vytváří napětí, které na dlouho zlikviduje vývojářskou produktivitu.

5. Pracovní prostředí

Produktivitu práce ovlivňuje velmi mnoho faktorů. Například zvuky, které mohou zaměstnance na jiných pozicích rušit, programátoři milují – určité množství bílého šumu (hlasitá klimatizace, zvuky projíždějících aut a náklaďáků…) jim pomáhá lépe se soustředit.

6. Více nástrojů a hardware

Vývojáři používají denně pro programování, odesílání a slučování kódu desítky nástrojů. Čím více se dá automatizovat, tím lépe. Pokud ale programátor používá “historické” nástroje, ovlivní to jeho produktivitu. S tím souvisí i kvalita a výkonnost vybavení, a také například možnost druhého monitoru. To znamená, že investice se vyplatí. Čím lepší nástroje, tím vyšší produktivita.

7. Dokumentace říká jak, ale neříká proč

Komentování kódu je bežná praxe, která pomáhá při pozdějších úpravách a problémech, zvlášť když je musí řešit jiný vývojář než ten, který kód psal původně. Častou chybou ale bývá, že je komentářů málo, nebo je v nich pouze popsáno, co kód dělá, málokterý ale vysvětluje proč.
r = n / 2; // Nastav r na n děleno 2
// opakuj dokud r — (n/r) je větší nebo rovno t, přičemž ( abs( r — (n/r) ) > t ) { r = 0.5 * ( r + (n/r) ); // Nastav r na půlku z r + (n/r)
}
Pokud byste řešili chybu a narazili na tento kód, nevěděli byste, kde začít.

8. Nesmyslné termíny

S nesmyslně napjatými termíny bojuje v současnosti každý, o to více vývojáři. Manažeři se snaží snižovat původní odhady a výsledný odhad považovat za závazný termín. Ten berou platný a sdílejí ho s vyšším managementem. Není divu, že mají programátoři pocit, že lhůty jsou nepřiměřené, vzniká napětí, ve kterém se těžko soustředí.

Řešení: Stanovujte realistické termíny společně s vývojářem

9. Rozplizlost rozsahu

Rozplizlost rozsahu (někdy také rozplizlost zaměření, požadavků, funkcí a někdy syndrom zahrnutí úplně všeho) v řízení projektů se týká neřízených změn v rozsahu projektu. K tomu může dojít, pokud není rozsah projektu správně definován, zdokumentován nebo řízen.

Rozplizlost rozsahu mění relativně jednoduché požadavky na strašně složitá a časově náročná monstra! A většinou se to děje během vývoje! Příklad jednoduché funkce:
Verze 1 (před implementací): funkce je “Zobraz mapu místa”
Verze 2 (když je verze 1 už skoro hotová): funkce se mění na “Zobraz 3D mapu místa”
Verze 3 (když je verze 2 už skoro hotová): funkce se mění na “Zobraz 3D mapu místa, kterou může uživatel prolétnout”

Pokud chcete lepší produktivitu od svého vývojáře, mluvte s ním. Zeptejte se, s čím se nejvíce potýká a co ho od práce zdržuje. Drtivá většina problémů se dá řešit. I když se dnešní technologie velice liší od té před 30 lety, poučení je stále stejné. Když hodnotíte produktivitu týmu, nemůžete ignorovat lidský faktor. Projděte své procesy, prostředí a pracovní návyky se svým týmem a nechte je, ať vás navedou k nejvyšší produktivitě a zároveň i k jejich spokojenosti.

null