Dohodli jste se na rozsahu, podepsali smlouvu a vývojový tým začal pracovat. V tuhle chvíli si mnoho majitelů firem klade otázku, na kterou nečekali: co vlastně mám teď dělat?
Někteří klienti zcela zmizí — plně se spoléhají na tým, aby se za týdny znovu ozvali a zjistili, že projekt se ubírá jiným směrem. Jiní dělají přesný opak: posílají každodenní zprávy, zpochybňují každé designové rozhodnutí a přidávají nové požadavky uprostřed sprintu. Ani jeden přístup nefunguje.
Existuje střední cesta — a vyplatí se ji znát ještě před zahájením vývoje, ne až po prvním tření.
Proč záleží na vašem zapojení víc, než si myslíte
Vývojářské firmy jsou odborníci na tvorbu softwaru. Nejsou odborníci na vaše podnikání. A právě v té mezeře se utápí většina projektů.
Vývojáři mohou napsat dokonale funkční kód a přitom vytvořit něco, co neřeší ten správný problém — pokud nikdo s obchodní znalostí aktivně nesměruje rozhodnutí. Tím člověkem jste vy. Tuto odpovědnost si přerozdělit nemůžete, protože odborná znalost domény je u vás.
To neznamená, že musíte být technický člověk. Znamená to, že musíte být dostupným, informovaným a rozhodným obchodním partnerem po celou dobu projektu.
Rozhodnutí, která může udělat jen vy
Některá rozhodnutí vypadají technicky, ale jde v jádru o otázky vašeho podnikání. Tady je potřeba vaše přispění, nikoli úsudek vývojáře.
Priorita. Když je potřeba upravit rozsah — protože něco trvalo déle, než se čekalo, nebo se objevil nový požadavek — musí někdo rozhodnout, co je nejdůležitější. To je obchodní rozhodnutí, ne technické. Pokud váš vývojový tým žádá o vedení ohledně priorit a nedostává ho, projekt buď stagnuje, nebo pokračuje na základě předpokladů, se kterými nemusíte souhlasit.
Firemní logika. Jak funguje vaše cenotvorba? Jaké jsou výjimky z vašich standardních postupů? Kdy je zákazník označen pro ruční kontrolu? Tato pravidla žijí ve vašem podniku — často jen v hlavách lidí, nikoli v žádném dokumentu. Vývojové týmy je potřebují mít explicitně popsaná, a jediný způsob, jak je vytáhnout na povrch, je zapojit lidi, kteří je znají.
Akceptace. Když vám tým ukáže dokončenou funkci, jste jediný, kdo může říct, zda skutečně dělá to, co potřebujete. Technická správnost je odpovědností týmu. Obchodní správnost je vaše. To nejsou totéž.
Tolerance k riziku. V každém projektu přicházejí kompromisy — mezi rychlostí a robustností, mezi funkcemi a náklady, mezi ideální architekturou a funkčním produktem. Váš tým může představit možnosti, ale rozhodnutí náleží vám.
Jak zůstat zapojeni, aniž byste zpomalovali práci
Efektivní zapojení klienta je otázkou načasování a struktury, nikoli objemu. Klient, který rychle reaguje a je konkrétní, způsobuje daleko méně zdržení než ten, kdo se zcela odtáhne.
Přijďte na sprint review. Pokud váš tým pracuje ve sprintech (obvykle dvoutýdenní cykly), pravidelně se prezentuje hotová práce. Choďte na tato setkání. Je to nejrychlejší způsob, jak odhalit nedorozumění brzy — kdy je oprava levná — místo pozdě, kdy to tak levné není.
Odpovídejte na otázky rychle. Vývojové týmy blokují nezodpovězené otázky. Rozhodnutí, které k vám cestuje týden, může způsobit týden ztráty. Většina otázek není těžká — jen potřebují někoho s autoritou, kdo dá jasnou odpověď. Rychlá a nedokonalá odpověď je téměř vždy lepší než pomalá a dokonalá.
Určete jediný kontaktní bod. Pokud má na projektu názory více lidí ve vaší organizaci — což je normální a zdravé — dohodněte se předem, kdo má pravomoc dávat závazné pokyny. Protichůdné instrukce od různých stakeholderů jsou výrazným zdrojem prodlev a oprav.
Rozlišujte zpětnou vazbu od instrukcí. Při hodnocení hotové práce je rozdíl mezi „všiml jsem si problému s tímhle" (zpětná vazba) a „prosím změňte to, aby dělalo X" (instrukce). Obě jsou legitimní, ale měly by být jasně komunikovány, aby na ně tým mohl adekvátně reagovat.
Co klidně nechejte na týmu
Součástí maximálního využití vývojářského partnerství je důvěřovat týmu v tom, co je skutečně v jejich doméně.
Technologické volby. Jaký framework, databáze nebo infrastruktura je pro váš systém nejvhodnější, je technická otázka. Váš tým by měl na žádost vysvětlit rationale, ale tyto detailní volby nepotřebujete schvalovat. Zasahování do technologických rozhodnutí na základě toho, co jste slyšeli odjinud, je běžný způsob, jak zavést problémy, které jste neplánovali.
Dělení a sekvencování úkolů. Pořadí, v jakém se funkce vyvíjejí, a jak je práce rozdělena mezi vývojáře, je otázka projektového řízení a inženýrství. Tým ví, co na čem závisí a co se co nejefektivněji nastavuje na to, co je již hotovo.
Kvalita kódu a testování. Způsob, jakým je kód interně strukturován, jak se testuje a jaké standardy dodržuje, je odpovědností týmu. Měli byste očekávat dobré postupy — a tým zodpovídat, pokud se projeví systémové problémy s kvalitou — ale procházet kód řádek po řádku není užitečnou klientskou aktivitou.
Designové detaily v rámci dohodnutých směrnic. Pokud jste poskytli brand guide nebo designové směřování, tým může rozhodovat v tomto rámci bez vašeho schválení každé drobné volby. Přeschvalování designu vytváří úzká hrdla, aniž by zlepšovalo výsledky.
Nejčastější zdržení na straně klienta
Existuje několik opakujících se vzorců, které projekt ze strany klienta zpomalují. Znát je předem je nejlepší způsob, jak se jim vyhnout.
Nedostupnost v kritických rozhodovacích momentech. Některá rozhodnutí skutečně vyžadují schůzku nebo podrobný rozhovor, ne jen rychlou odpověď. Pokud je klient v těchto momentech těžko dostupný, práce buď stojí, nebo pokračuje na základě předpokladů. Oba výsledky jsou nákladné.
Přidávání rozsahu během vývoje. Při vývoji přicházejí nápady — to je přirozené. Chybou je brát je jako okamžité přidání do aktuálního buildu namísto přidání do budoucí fáze. Každá změna rozsahu uprostřed buildu narušuje plánování týmu a obvykle stojí více než stejná změna v příští fázi.
Zpožděné akceptační testování. Dokončené funkce je potřeba přezkoumat a akceptovat (nebo označit pro opravu) včas. Pokud akceptační testování zaostává o týdny, tým mohl postavit další práci na něčem, co nebylo schváleno — což vytváří kaskádové opravy.
Měnění zadání po podpisu. Děje se to častěji, než by mělo. Podepsané požadavky se přehodnocují, schválené designy se redesignují, potvrzená rozhodnutí se ruší. Každý zvrat má svou cenu. Pokud si ohledně požadavku skutečně nejste jistí, vyplatí se nejistotu vyřešit v discovery fázi, ne uprostřed vývoje.
Jak vypadá dobrá spolupráce v praxi
Klienti, kteří nakonec dosáhnou nejlepších výsledků, nejsou ti, kdo rozumějí softwaru — jsou to ti, kdo rozumějí svému podnikání a jsou ochotni se po celou dobu projektu pravidelně zapojovat.
Přijdou na review, dávají konkrétní zpětnou vazbu, rozhodují v rozumném čase a důvěřují týmu v technických volbách, přičemž sami zůstávají blízko obchodním výsledkům. Řeknou týmu včas, když se něco změnilo, místo aby doufali, že na tom nezáleží.
Vztah mezi majitelem firmy a vývojovým týmem funguje jako každý dobrý pracovní vztah: potřebuje jasnou komunikaci, vzájemnou úctu k doménám každého a dostatečnou strukturu, aby vše zůstalo na správné cestě.
Když tyto prvky jsou na místě, projekty mají tendenci jít dobře. Když nejsou, i technicky vynikající týmy mají potíže dodat to, co firma skutečně potřebuje.
Správné nastavení vztahu stojí za vynaloženou energii. Investice, kterou vložíte do pochopení své role — a do toho, abyste ji skutečně plnili — se mnohonásobně vrátí v podobě projektu, který dopadne přesně tak, jak jste potřebovali.