Pět otázek před výběrem modelu
Nejdříve určete, jak dobře rozumíte problému a výsledku. Je zadání stabilní, nebo se jeho podoba ukáže až po rozhovorech s uživateli? Druhá otázka se týká schopnosti klienta rozhodovat průběžně. Třetí je technické riziko: kolik neznámých se skrývá v datech, integracích a stávajícím kódu? Čtvrtá je provozní odpovědnost po předání. Pátá je rozpočtový rámec a důsledky překročení termínu. Bez těchto odpovědí se název kontraktu stává zkratkou, která zakrývá skutečné závazky.
Model spolupráce má učinit riziko viditelným. Pevná cena není záruka pevného výsledku, pokud se mění předpoklady. Průběžně placená práce není automaticky nekontrolovatelná, pokud má rozpočtový limit, měřitelné etapy a pravidelné rozhodnutí pokračovat. Klient a dodavatel by měli umět vysvětlit, které rozhodnutí patří komu a co se stane při nové informaci.
Pevný rozsah a pevná cena
Pevně vymezený projekt dává smysl, když lze popsat výstup, vstupy, akceptaci a změnové řízení. Hodí se například pro oddělený integrační krok se známým API nebo konkrétní úpravu stabilního produktu. Dohoda musí obsahovat chování při chybách, hranice podpory, přístup k prostředí a součinnost klienta. Pokud tyto části chybí, nízká nabídnutá cena může pouze odložit nevyřešené otázky do pozdějšího sporu.
Rizikem je předstíraná jistota. Pokud neznáme kvalitu dat či chování externího systému, je rozumné nejprve objednat průzkum nebo experiment a teprve potom cenu implementace. Změny se posuzují podle dopadu na rozsah, termín a provoz. Užitečný pevný kontrakt umožňuje říci i to, co není součástí dodávky, aniž by tím skrýval klíčový předpoklad.
Time and materials s kontrolou výsledku
Průběžný model se hodí pro práci, která se učí za pochodu: nový produkt, modernizaci s nejasnými závislostmi nebo integraci, jejíž partner teprve upřesňuje rozhraní. Platba za čas sama o sobě neříká, zda vzniká hodnota. Proto stanovte krátké cíle, průběžný přehled nákladů a konkrétní ukázky dokončeného chování. Rozhodnutí o dalším období se pak opírá o důkaz, ne o počet odpracovaných hodin.
Otevřený rozsah vyžaduje aktivní účast vlastníka produktu. Musí určovat priority a přijímat kompromisy, zatímco technický tým musí upozornit na dluh, nejistotu a případné zbytečné zadání. Bez této součinnosti se model rychle změní v drahou frontu požadavků. Rozpočtový strop a právo spolupráci ukončit po jasně definovaném předání chrání kontrolu klienta.
Dedikovaný tým a doplnění interní kapacity
Dedikovaný tým přebírá dlouhodobý kontext produktu a odpovědnost za dohodnutý tok práce. Vlastník produktu na straně klienta dál určuje obchodní priority. Složení týmu se může měnit podle etapy, ale změna nesmí přerušit znalost systému. Cílem je schopnost bezpečně vydávat další změny, řešit incidenty a předávat rozhodnutí. Předem je třeba určit dostupnost, způsob revizí, vlastnictví přístupů a plán předání.
Staff augmentation znamená doplnění jednotlivé schopnosti do již fungujícího interního týmu. Odpovědnost za architekturu, prioritu a koordinaci zůstává převážně klientovi. Když interní vedení nebo proces chybí, samotný přidaný vývojář problém obvykle nevyřeší. Rozdíl mezi oběma modely je právě v řízení a odpovědnosti, nikoli jen v počtu externistů.
Konzultace a spravovaná služba
Konzultace je vhodná, pokud potřebujete rozhodnutí, audit omezeného rozsahu nebo návrh ověřovacího experimentu. Výstup má být použitelný: doporučení s předpoklady, variantami, riziky a dalším krokem. Konzultace bez přístupu ke správným lidem a datům může vytvořit jen obecný dokument. Vymezte proto konkrétní otázku a důkazy, které jsou pro odpověď dostupné. Implementace může, ale nemusí navazovat u stejného partnera.
Spravovaná služba se týká opakované odpovědnosti za provoz, údržbu či konkrétní schopnost. Potřebuje měřitelné hranice dostupnosti, bezpečnostní role, reakci na incident, podporované časy, výluky a způsob ukončení. Slovo „managed“ bez takové dohody nic negarantuje. U každého provozního závazku je důležité vědět, kdo vlastní infrastrukturu a data a kdo platí externí služby.
Přechod mezi modely
Model nemusí platit navždy. Krátká diagnostika může přejít do pevně vymezeného prototypu; ověřený produkt zase do průběžného týmu. Naopak stabilní část systému lze předat do provozní služby s jasným rozsahem. Přechod je vhodný, když se změní míra nejistoty nebo vlastní schopnosti klienta. Před každým krokem je třeba znovu vymezit výsledek, rozpočet, přístupy a odpovědnost za rozpracovanou práci.
Dodavatel má umět vysvětlit, proč určitý model doporučuje a jaké má nevýhody. Klient by měl vidět rozhodnutí v jednoduchém zápisu: předpoklady, vyloučené alternativy, kritéria další kontroly a způsob ukončení. Tak se vyhne situaci, kdy spolupráce pokračuje jen ze zvyku. Smluvní text musí odpovídat skutečnému fungování týmu; konkrétní právní podobu je třeba posoudit s příslušným odborníkem.
Jak připravit srovnatelné zadání
Pošlete cíl, omezení, známé systémy, požadovanou součinnost, rozhodovací termín a největší nejasnosti. Uveďte, co musí být doloženo při převzetí: například fungující tok, zdokumentované rozhraní, obnovená záloha nebo uživatelsky ověřený prototyp. Pokud porovnáváte nabídky, chtějte od všech stejný popis předpokladů a výluk. Cena bez nich není srovnatelná. Zeptejte se také, kdo bude po dokončení vlastnit kód, účty a provozní dokumentaci.
Dobrý první krok může být malý. Zvolte riziko, které by mohlo zvrátit celý plán, a dohodněte způsob jeho ověření. Teprve potom má smysl určovat dlouhodobý tým či pevný rozpočet. Tento postup neodkládá dodávku; vytváří podklad pro rozhodnutí, které jinak stojí na domněnkách.