Jak za 30 dní začlenit specializovaný vývojový tým

Úvod

Většina outsourcingových smluv selže již v prvním měsíci, nikoli v prvním roce. Inženýři jsou kvalifikovaní a sazba je přiměřená, ale tým stráví týdny bez přístupu k informacím, kontextu nebo jasných priorit. V době, kdy práce konečně začne, již klient ztratil důvěru v tento model.

Specializovaný vývojový tým může dosáhnout plné produktivity do 30 dnů, pokud se na to klient připraví. Dodavatel se postará o nábor a zaměstnávání, ale pouze klient dokáže vysvětlit produkt, kódovou základnu a obchodní cíle. Zaškolení je společný projekt a většinu předávání znalostí zajišťuje strana klienta.

Před prvním dnem: Co je třeba připravit

Týden před datem zahájení rozhoduje o tom, jak rychle se tým rozběhne. Inženýři, kteří čekají tři dny na přístup k repozitáři, ztrácejí elán a toto zpoždění udává tón celé spolupráci.

Příprava vyžaduje od klienta několik hodin práce. Většina z ní je administrativní a celý seznam může mít na starosti jedna osoba.

• Přístup a účty. Vytvořte účty pro repozitář kódu, nástroj pro sledování úkolů, cloudovou konzoli a komunikační kanály. Před datem zahájení otestujte každé přihlášení.
• Technická dokumentace. Shromážděte diagramy architektury, popisy API a návody k nastavení na jednom místě. Zastaralé dokumenty jsou přijatelné, pokud někdo označí, co se změnilo.
• Kontaktní osoba. Určete na straně klienta jednu osobu, která bude odpovídat na dotazy do jednoho pracovního dne. Touto osobou je obvykle technický vedoucí nebo produktový vlastník.
• Počáteční backlog. Připravte 10 až 15 úkolů s nízkou a střední složitostí. Tým potřebuje práci, která ho seznámí s kódovou základnou, aniž by ohrozila produkční prostředí.

1. týden: Přístup, kontext a první úkoly

První týden je věnován orientaci. Tým se seznamuje s tím, co produkt dělá, kdo ho používá a jak je kód uspořádán.

Výstup v tomto týdnu je záměrně malý. Cílem je funkční prostředí a první sloučená změna, nikoli vydání nové funkce.

1.–2. den: Nastavení prostředí

První den klient uspořádá úvodní hovor. Produktový vlastník vysvětlí obchodní model, hlavní skupiny uživatelů a aktuální priority. Technický vedoucí provede účastníky architekturou a procesem nasazení.

Po hovoru si inženýři nastaví lokální prostředí a spustí aplikaci. Většina problémů s nastavením se objeví právě zde, proto by měl být kontaktní pracovník na straně klienta k dispozici pro rychlé odpovědi.

Dny 3–5: První malé úkoly

Každý inženýr si vezme jeden nebo dva úkoly z počátečního backlogu. V této fázi se osvědčují opravy chyb, drobné změny uživatelského rozhraní a testování pokrytí. Inženýři pracují se skutečným kódem, ale riziko je nízké.

Každý úkol prochází kompletním cyklem revize kódu, testování a nasazení. Tým tak pozná, jak klient pracuje, a včas odhalí mezery v procesu.

2. týden: Procesy a rytmus komunikace

Ve druhém týdnu tým přechází od individuálních úkolů k týmovým rutinám. Klient a dodavatel se dohodnou na tom, jak se práce plánuje, projednává a vykazuje.

Distribuované týmy potřebují více struktury než týmy pracující na jednom místě. Časová pásma a kulturní rozdíly ztěžují neformální komunikaci, proto musí být rytmus jasně stanoven.

• Denní standupy. Uspořádejte krátkou telekonferenci v čase, který se překrývá v obou časových pásmech. Patnáct minut stačí na projednání stavu a překážek.
• Plánování sprintů. Plánujte práci v jedno- nebo dvoutýdenních sprintech. Prioritu stanoví produktový vlastník na straně klienta a tým odhadne náročnost.
• Pravidla pro revizi kódu. Dohodněte se, kdo co reviduje a v jakém časovém horizontu. Zpoždění revize o více než jeden den zpomaluje celý tým.
• Písemné aktualizace. Požádejte o krátké týdenní shrnutí ve sdíleném kanálu. Zainteresovaným stranám to poskytne přehled bez nutnosti dalších schůzek.
• Postup eskalace. Definujte, kdo na které straně řeší překážky. Account manager dodavatele řeší problémy týmu a kontaktní osoba na straně klienta řeší otázky týkající se produktu.

3.–4. týden: Odpovědnost a měření

Poslední dva týdny prověří, zda zapracování proběhlo úspěšně. Tým přebírá skutečnou odpovědnost a obě strany vyhodnocují výsledky podle jasných kritérií.

Tato fáze také ukáže, kde je třeba proces ještě upravit. Drobné problémy se snáze řeší 25. den než 90. den.

Předání skutečné funkce

Ve třetím týdnu přiřaďte týmu jednu kompletní funkci z produktové roadmapy. Měla by vyžadovat rozhodnutí ohledně návrhu, práci napříč několika částmi kódové základny a nasazení do produkčního prostředí.

Technický vedoucí klienta zkontroluje technický přístup před zahájením vývoje. Poté má tým práci na starosti od odhadu nákladů až po nasazení. Přísný dohled v této fázi by byl v rozporu s jejím smyslem.

Metriky, které je třeba sledovat 30. den

Na konci měsíce uspořádejte s dodavatelem hodnotící hovor. Porovnejte výsledky s očekáváními stanovenými v prvním týdnu a pokud možno použijte číselné údaje.

• Tempo dodávek. Porovnejte plánované a dokončené story pointy za poslední dva sprinty. Stabilní tempo je důležitější než vysoké.
• Kvalita kódu. Zkontrolujte podíl pull requestů, které projdou revizí v prvním nebo druhém kole. Časté přepracovávání signalizuje mezery v kontextu.
• Objem dotazů. Sledujte, jak často inženýři žádají klienta o pomoc. Tento počet by měl každý týden klesat.
• Zpětná vazba od zainteresovaných stran. Požádejte produktového vlastníka a technického vedoucího o krátké zhodnocení. Jejich pohled často odhalí problémy, které metriky přehlédnou.

Časté chyby při zapracování

Většina zpoždění při zapracování má několik stejných příčin. Firmy je opakují, protože každá z nich se zpočátku jeví jako nevýznamná.

• Opožděný přístup. Účty, které dorazí až třetí den, stojí tým tři dny práce. Schvalování zabezpečení často trvá déle, než se očekává, proto s ním začněte včas.
• Chybějící kontext produktu. Inženýři, kteří nerozumí uživatelům, činí technicky správná, ale zbytečná rozhodnutí. Jedna hodina vysvětlování produktu ušetří týdny přepracovávání.
• Příliš mnoho kontaktních osob. Když dává pokyny pět lidí, dochází ke konfliktům priorit. Jeden rozhodující činitel udržuje jasný směr.
• Považování týmu za externí. Oddělené komunikační kanály a omezené schůzky vytvářejí dvoustupňovou strukturu. Týmy, které se zapojí do rutin klienta, se integrují rychleji.

Závěrečné úvahy

Třicet dní stačí k tomu, aby specializovaný tým dosáhl plné produktivity. Výsledek závisí méně na dodavateli a více na tom, jak dobře klient připraví přístup, kontext a jasné priority.

Považujte zapracování za projekt s odpovědnými osobami, termíny a závěrečným hodnocením. Strukturovaný první měsíc buduje důvěru, kterou dlouhodobá spolupráce vyžaduje.