Ať už jste junior, zkušený vývojář nebo projektový manažer, následující potíže pravděpodobně znáte. Toto téma je však relevantní nejen pro dodavatele, ale i pro jejich klienty. Jaké nejčastější fuck-py každý z nás někdy pozná? Co vývojáře budí ze snů? A jak se tomu vyhnout? V tomto článku se zaměříme na tři zásadní problémy a ukážeme vám, jak se s nimi dokážeme úspěšně vyrovnat.

Čas jsou peníze, chyby jsou často čára přes rozpočet. Neefektivní vývoj může být velice nákladný, jelikož ovlivňuje architekturu systému, spokojenost zaměstnanců i zákazníků. Důvodů je jistě mnohem více, ale my se zaměříme na podle nás 3 nejzásadnější. Ke každému rovněž uvádíme, jak jednotlivé problémy řešíme my, a tak možná bude mít i váš příští fuck-up šťastný konec. Tento přístup je vhodný pro náš tým, ale každému může sednout něco jiného a přístup je třeba přizpůsobit potřebám vašeho týmu.

Hurá akce

Volba, do jakých projektů a jakým způsobem se pustit, bohužel často nespočívá v dostatečných průzkumech, analýzách a plánování, ale často v ovlivňovacích schopnostech vedení. Důvody se často opakují – například nedostatek prostředků a kapacit pro důkladné strategické plánování, jelikož se tým už dávno potápí v operativě. Tento problém se vyskytuje zejména tehdy, kdy má tým více přiležitostí než si může naložit na bedra.

Výsledkem může být například cílení na odvětví, kterému vedení nerozumí, nebo mnoho nesourodých projektů a technologií, které tým skrz fluktuaci nezvládá spravovat. Dopady jsou zřejmější, než příčiny tohoto průšvihu – snižuje se kvalita dodávky, jelikož na vedení je vyvíjen tlak skrz finance i termíny. Vedení svoji nespokojenost snadno přenáší na celý tým.

Jak to ovlivňuje například programátora? Vývojář obvykle nechce nic psát dvakrát nebo kód někomu opakovaně vysvětlovat, má psát generický, škálovatelný a čitelný kód. Když má nedostatek zkušeností nebo je na něj vyvíjen tlak, může inklinovat např. ke kopírování celých bloků kódu (funkce, komponenty, služby, externí balíčky) v rámci jedné aplikace, jelikož neví jak psát obecně a efektivně. To vede k tzv. “špagetové” architektuře, která je kapacitně velmi náročná na správu a rozšíření.

„Neřízené rozhodování, jakou cestou se vydat, není problémem jen u vývoje software, ale pokud vedení projektu neřídí ani svůj vlastní život, těžko se může správně rozhodovat na kariérní úrovni.“

Jak k tomu přistupujeme my?

Namísto technokratického přístupu dáváme vývoji směr a tvoříme strategii. Do projektu se pustíme jen za předpokladu, že je v souladu s naším posláním a plánem. Pokud po řádném průzkumu získá projekt dostatečnou prioritu, tak se do něj s radostí pouštíme.

Over-engineering

V kontextu vývoje software znamená, že aplikujete příliš mnoho přístupů či technických řešení, která jsou překotná a nepotřebná pro danou situaci. Výsledek je možná sofistikovaný, na druhé straně ale také složitý, zdlouhavý a přitom jednodušší řešení by bylo naprosto dostatečné pro daný úkol. Tento přístup může vést k nárůstu nákladů, ke zpožděním v dodávkách i složitosté údržbě v budoucnu. Jedná se o problém zejména u méně ostřílených kolegů. Jaký to má dopad na jednotlivé pozice v týmu?

• Programátor – Chce mít čistý kód, používat moderní technologie a ideálně veškerou operativu mimo tvůrčí řešení automatizovat (např. nasazování, verzování, testování a dokumentování). Rád se učí a zkoumá nové přístupy a technologie. To vše vede k tomu, že je hluboce ponořen do specifického problému. Což je správně, jelikož přijít na geniální řešení, to chce čas a out-of-the box myšlení. Snadno ale skončíte u toho, že se nedokážete na problém podívat z vyšší perspektivy.
• Grafik – Rád dá volný průchod svému uměleckému talentu, a to ideálně na bílém plátně bez technického či finančního omezení, a tudíž má před sebou tolik možností, že začne over-engineerovat a překročí plánovaný rozpočt. Pokud naopak pracuje dle zajetých šablon, zapomene na kouzlo inovativních a jednodušších řešení. To může vést k tomu, že aplikuje složité přístupy, které vedou ke zvýšení časové náročnosti úkolu.
• Tester – Nahlíží na aplikaci a její funkce či potencionální chyby ze všech různých pohledů. Problém je, když testuje scénáře, které v praxi nemohou nikdy nastat (např. nesprávná data nad dobrě validovaným systémem) nebo otestují kompletní testovací knihu v nesprávný čas skrz obavy z dopadu nějaké chyby.
• Projektový manažer – Osoby zodpovědné za projekt mají rádi kontrolu a přehled. Proto sledují řadu ukazatelů nad dodávkou. Může se však stát, že při sledování několika desítek ukazatelů je v krizové situaci projektu přehlcen informacemi natolik, že neví, který ukazatel s problémy řešit nejdříve. Špatná rozhodnutí následně mohou vést k mikromanagementu či plánování na několik let dopředu.

Jak to řešíme my?

Především přistupujeme k celému vývoji konzistentně, a to od průzkumu až po testování. Nastavili jsme procesy pro zásadní obchodní i technická rozhodnutí. Nevymýšlíme vymyšlené a využíváme existující osvědčená a moderní řešení. Máme jednu transparentní a snadno pochopitelnou architekturu, která nám šetří čas. Používáme ucelený celek souvisejících technologií, který nerozšiřujeme o další substituční alternativy. Při složitějších problémech se vždy poradí členové týmu k volbě za správným řešením.

Neefektivní procesy

Mohou brzdit vývoj softwaru, vést k zbytečným nákladům a zpožděním. Berme zde v úvahu úskalí v zavedeném systému, který má prostor ke zlepšení, nikoli organizaci bez základních procesů fungujících v úplné či částečné anarchii.

Prvním takovým procesem je nedostatečná analýza a plánování. Mnoho týmů se snaží rychle začít s vývojem softwaru bez řádného plánování a analýzy požadavků, což vede k nejasnostem, nedorozuměním a zbytečným opravám a úpravám v průběhu vývoje.

Druhým neefektivním procesem je špatná komunikace v týmu. Pokud členové týmu nekomunikují průběžně a účinně, může dojít k zbytečnému zpoždění vývoje softwaru, chybám a nedorozuměním. Zde je důležité mít jasnou komunikační strategii a plán.

Dalším problémem je nedostatečné testování a validace softwaru. Pokud není softwarový produkt řádně otestován a validován, mohou se objevit chyby a problémy velmi nákladné na opravu. Zde je nutné mít robustní testovací strategii a procesy, aby se minimalizovala rizika vzniku chyb.

Dalším neefektivním procesem je nedostatečné zapojení zákazníka nebo koncového uživatele do vývoje softwaru. Pokud není koncový uživatel zapojen do procesu vývoje, může to vést k výrobě softwaru, který nevyhovuje jeho potřebám a neodpovídá požadavkům trhu. Zásadní je zde především dostatečná míra transparentnosti s plány, rozpočtem, změnami i problémy.

A nakonec, jedním z největších problémů vývojových týmů je nedostatečné řízení projektů. Pokud projekt není řízen řádně, snadno dochází ke zbytečnému zpoždění a růstu nákladů. Výsledek nebývá dobrý pro spolupráci týmu ani produkt samotný.

• Tím, že mají projektoví manažeři obvykle na starost mnoho projektů, často nehledají a nezkouší nové způsoby vedení a měření výsledků. Pokud se dlouho držíte zavedených přístupů, možná nenaplňujete plný potenciál svého týmu.
• Při nedostatečném plánování a měření se programátorům dostává příležitosti nadhodnocovat časové odhady na splnění úkolu. Ti toho mohou zneužít až do takové míry, kdy jim vedení proplácí vysoké přesčasy, které neodpovídají odvedené práci.
• Pokud úkolům nenastavíte správnou prioritu dle požadavků zákazníka a severitu dle efektivního rozvoje architektury, může být projekt dokonce předčasně ukončen s oboustranou nespokojeností.
• Vedení by se rovněž mělo dostatečně zaměřit na růst týmu i jeho členů.

Jak k tomu přistupujeme my?

Základním pilířem našeho fungování je lean přístup. Naší výhodou je, že zakladatel Jakub si prošel po určitou dobou každou ze základních rolí procesu vývoje software, a tudíž je pro něj snadné se vžít do pozice jednotlivých kolegů. Každý má však svoji odbornost, a tudíž i jasně stanovenou odpovědnost. Vzájemně se tedy doplňujeme, radikálně a otevřeně komunikujeme, a tím se neustále posouváme. Jasně vymezenými přístupy a technologiemi máme pod palcem vzájemnou zastupitelnost. Počet schůzek průběžně omezujeme pouze na ty nejdůležitější.  Rovněž máme procesní OKR, KPI, měříme kvalitu a vývoj jak týmu, tak projektu. Pro vývoj používáme agile rapid prototyping a SCRUM.

Jak si to můžeme shrnout?

Volba příštího projektu nemusí být založena pouze na intuitivní a impulzivní úrovni. Průzkumy trhu, alternativních produktů a hodnocení rizik lze provést i na základní úrovni celkem rychle v porovnání s celou dodávkou. Plánování a měření projektu s kvalitním výsledkem nemusí být otázka času, ale spíše průzkumu a pochopení trhu či potřeb uživatelů. Kdo na začátku zaspí,  ve výsledku nestíhá a zbytečně vyvíjí tlak na celý tým. Nové projekty podložené kvalitním průzkumem a plánem, naopak můžete vítat bez obav z předčasného ukončení “hurá akce”.

Over-engineering se u každé role vývojového týmu projevuje trochu odlišně, ale princip jeho řešení je v zásadě podobný. V případě přemrštěně složitého řešení je tedy žádoucí jej přerámovat a najít jednodužší řešení, nebo jej iterovaně revidovat dokud se řešitel nedostane jednodužší úrovně komplexnosti a se nebo mu ideálně aktivně snažit předejít.

Pro procesní řízení je vhodné, aby si vedoucí pracovník danou pozici vyzkoušel. Toho lze dosáhnout například prostřednictvím řady IT akademií jako je CodeBiters nebo si s týmem mohou zavést program sdílení zkušeností pro lepší pochopení práce druhého. Na základě toho si lze stanovit měřitelné ukazatele výkonnosti a postupně efektivitu procesů optimalizovat. Nutné je stanovit takové procesy, které týmu budou pomáhat dosahovat lepších výsledků. Půlka týdne proseděná na poradách mezi dobré procesy určitě nepatří, i když řada firem se s tímto přístupem jen těžko loučí.

Dnes jsme si řekli o 3 velmi častých úskalí vývoje software. Vysvětlili jsme si jejich příčiny, dopady a možná řešení. Přejeme mnoho zdaru a ať vás vývoj software baví stejně jako nás.