Služby

Školení

Školení mí klienti používají, když chtějí do firmy zavést změnu a chtějí si být jistí, že všichni zaměstnanci chapou změnu do hloubky. Jedná se například o agilní transformace nebo o použítí agilních technických praktik jako Test Driven Development.

Poradenství

Poradenství při vývoji software může mít různou formu a cíl – například řízení vývoje pro velké množství vývojových týmů, zlepšování kvality vyvíjeného software. Poradenství je vždy individuální a při něm firmám přináším zkušenosti, které jsem za dvacet let praxe nasbíral ve velkých firmách.

Příklady spolupráce

Příklad 1 – Matěj

Zavolal mi Matěj, vedoucí vývoje v menší firmě (40 zaměstnanců), že by potřeboval poradit. V jejich firmě při vývoji vzniká velké množství chyb, které najdou až zákazníci. Sedli jsme si spolu a několik hodin jsem mu dělal Sparring Partnera. Matěj občas k našim debatám přizval další klíčové lidi z firmy. Spolu jsme přišli na to, že příčinou špatné kvality jsou nedostatečné schopnosti vývojářů u nich ve firmě. Doporučil jsem mu školení na Test-Driven Development

Jednodenní školení proběhlo o pár dnů později a ještě několik týdnů jsem jednou za čas docházel do firmy a pomáhal vývojářům použít techniky naučené při školení na jejich vlastním kódu, který zdaleka nebyl tak jednoduchý jako příklady použité při školení. Akce byla nicméně úspěšná a chybovost výrazně klesla. Navíc si teď všichni programátoři svoji práci víc užívají, protože mají pocit větší kontroly nad tím, co dělají.

Příklad 2 – Jirka

Napsal mi Jirka, kterého znám z bývalého zaměstnání a který teď pracuje ve větší firmě (250 zaměstnanců), že by potřebovali pomoct s problémy při vydávání software. Vlastní vydání jim trvá několik týdnů, vyžaduje to heroické úsilí od všech zúčastněných a vždycky přitom nadělají spoustu nového technického dluhu, který je potom zpomaluje.

Strávil jsem ve firmě dva dny a můj audit obsahoval dvě doporučení:

  • krátkodobá akce – zásadně vylepšit automatizaci testů a zrychlit sestavování a testování software tak, aby každý vývojář měl rychlou zpětnou vazbu pro každou svoji změnu
  • dlouhodobá iniciativa – problémy s vydáváním software pramení z toho, že se produkt vyvíjí v mnoha komponentních týmech. Každý tým dělá svoji část a integruje ji do produktu až se zpožděním. Na mnohé problémy se tudíž přijde pozdě a o to víc úsilí stojí je opravit. Bylo by vhodné uspořádat vývojové oddělení tak, aby si týmy byly více vědomé své zodpovědnosti za celý produkt.

S oběma akcemi můžu dál pomoci. Jirka si vybral jenom krátkodobou akci – změna organizační struktury celého oddělení mu připadala mimo jeho kompetenci. Spolu jsme potom několik týdnů vylepšovali jejich build pipeline a pak jsme se rozešli.

Za půl roku mi zavolal Václav, Jirkův šéf, CTO celé firmy. Mluvil prý s Jirkou a s dalšími klíčovými lidmi ve firmě a shodli se na tom, že by potřebovali přeorganizovat vývoj ve více týmech tak, aby byl efektivnější. Rychle jsme se dohodli, protože už jsem znal kontext a v dalších týdnech jsem nastoupil ke konzultacím.