Způsoby spolupráce objednatele a dodavatele na softwarovém projektu

Na jedné straně máme objednatele, který má zájem o vytvoření informačního systému a na druhé straně dodavatele. Jaké jsou běžné způsoby spolupráce? Tyto modely se liší v míře fixace rozsahu, času a ceny, což ovlivňuje rizika, flexibilitu i zapojení obou stran. Volba závisí na definici požadavků, velikosti projektu a tolerance k riziku.

Fix Time, Fix Price (FTFP)

Tento způsob dodávky fixuje čas, cenu a rozsah projektu. Rizika nese dodavatel, odběratel má jistotu, že pokud nebude požadovat změny, musí být dodržen dohodnutý rozpočet. Nevýhodou tohoto způsobu spolupráce je nutnost určení přesného rozsahu projektu. Problémem může být také malá flexibilita, kdy změny znamenající navýšení rozsahu projektu vedou k výraznému navýšení ceny a času a mohou vyžadovat novou smlouvu a/nebo formální schválení. Dodavatel proto často navýší cenu rezervami na neočekávané komplikace, což může vést k nižší kvalitě nebo zjednodušenému řešení.

Time and Material (T&M)

Odběratel platí za skutečně odvedenou práci. Čas a rozsah projektu může být flexibilní. Tento způsob spolupráce lze využít pro agilní projekty, kde se postupně objevují a rozpracovávají požadavky. Rizikem je možnost překročení plánovaného rozpočtu. Odběratel musí aktivně monitorovat průběh, schvalovat sprinty a priorizovat úkoly, což zvyšuje jeho zapojení, ale vede k vyšší kvalitě finálního produktu.

Bodyshop

Dodavatel poskytuje svoje specialisty do týmu objednatele. Objednatel platí za jejich čas předem dohodnutou sazbu. Riziko dodavatele je minimální, odpovědnost je na straně objednatele. Výhodou je možnost rychle najmout další specialisty, pokud to projekt vyžaduje. 

Dedicated Team 

Dodavatel sestaví exkluzivní tým pracující dlouhodobě pouze pro odběratele, s plnou kontrolou nad procesy. Výhodou je hluboké porozumění doméně, stabilita a škálovatelnost.

Hybridní model

Kombinace předchozích způsobů spolupráce. Například dohodnuté klíčové milníky projektu s pevně daným termínem a platba za skutečně odvedenou práci. Tento přístup vyvažuje jistotu FTFP s flexibilitou T&M, ideální pro středně velké projekty s některými známými požadavky a prostorem pro iterace. Smlouvy často obsahují strop rozpočtu nebo bonusy za předčasné dokončení milníků, což podporuje důvěru mezi stranami.

User story, Use case, funkční požadavky, akceptační kritéria, ...

 Nedávno jsem dostal následující otázky:

• Není náhodou user story a use case to samé?
• Má smysl vymýšlet akceptační kritéria, když mám popsané funkční požadavky?
• A není vlastně user story a use case jen rozpracováním funkčního požadavku?

Pojďme si to projít. Funkční požadavek je například: Systém musí umožnit přihlášení uživatele. Specifikuje, co je požadováno. 

Use case pak popisuje, jak uživatel pracuje se systémem. Tj. v daném, případě by hlavní scénář byl:

• Uživatel otevře přihlašovací formulář.
• Uživatel zadá uživatelské jméno a heslo.
• Uživatel klikne na tlačítko „Přihlásit".
• Systém ověří údaje v databázi.
• Systém zobrazí úvodní stránku a přihlásí uživatele.

Alternativní scénáře mohou řešit situaci, kdy uživatel zadá chybné přihlašovací údaje a obnovu hesla.

User story je „Jako registrovaný uživatel se chci přihlásit pomocí jména a hesla, abych získal přístup k mým datům a funkcím systému.".

Akceptační kritéria:

• Úspěšné přihlášení: Po zadání platných údajů se uživatel dostane na úvodní stránku do 2 sekund bez chyb.​
• Neplatné údaje: Systém zobrazí chybovou zprávu „Neplatné jméno nebo heslo" a vrátí formulář, bez odhalení konkrétního údaje.​
• Bezpečnost: Po 3 neúspěšných pokusech se účet zamkne na 5 minut; zadání prázdných polí zobrazí varování.​

Shrňme si to:

• Funkční požadavek říká, co má systém dělat.
• Use case říká, jak uživatel interaguje se systémem.
• User story říká, proč to uživatel potřebuje.
• Akceptační kritéria definují, kdy je funkcionalita hotova.

Stabilita softwarových požadavků

Stabilita softwarových požadavků má zásadní vliv na celý projekt. Pokud jsou požadavky stabilní, jasně pochopené a sdílené všemi aktéry, vývoj probíhá předvídatelně, náklady se drží pod kontrolou a architektura se nemusí neustále ohýbat podle nově se objevujících nápadů.

Nestabilní požadavky mají vždy konkrétní kořenovou příčinu. Jednou z nejčastějších je nedostatečné pochopení toho, kdo je skutečný stakeholder. Mnoho týmů pracuje pouze s jednou skupinou uživatelů, která je nejvíce slyšet, a teprve během vývoje se ukáže, že existují i další skupiny, jejichž potřeby nebyly zachyceny.

Další častou příčinou je příliš rychlý start vývoje. Tlak na rychlé výsledky často vede k tomu, že týmy „skočí rovnou do kódu“, aniž by věnovaly dostatek prostoru analýze a validaci požadavků. Výsledek? Požadavky jsou formulovány vágně, mnohdy i vícevýznamově, a jakmile je implementace vystaví realitě, začne se ukazovat, že každý stakeholder si požadavek vyložil jinak.

Nestabilita také vzniká tehdy, když projekt nemá jasnou a sdílenou produktovou vizi. Pokud neexistuje dokument typu Vision & Scope, dochází k tomu, že každý stakeholder vnáší do projektu vlastní agendu a jednotlivé požadavky nejsou zasazené do širší strategie. Bez této kotvy je jakákoliv specifikace náchylná ke změnám.

Stabilizace požadavků není o vytvoření „betonové specifikace“, kterou už nikdy nelze změnit. Jde o to, aby jakákoliv změna byla předvídatelná, řízená a odůvodněná. V praxi se osvědčilo několik postupů.

Jedním z nejúčinnějších nástrojů je vytvoření kvalitní vize a rámce projektu. V okamžiku, kdy se všichni stakeholdery shodnou na tom, proč systém vzniká, jaké problémy řeší a jaké naopak neřeší, dramaticky klesá množství pozdějších změn. 

Dalším krokem je důsledná validace požadavků s uživateli. V mnoha organizacích stačí, že analytik napíše specifikaci a ta se formálně schválí. Praxe však ukazuje, že skutečné porozumění vzniká až při prototypování, modelování scénářů a aktivní diskuzi. 

Neméně důležité je zavedení baseline – tedy oficiální, verzované sady schválených požadavků. Jakmile je baseline stanovena, každá změna se posuzuje prostřednictvím řízení změn. To neznamená, že se změny zakazují, ale že se u každé změny vyhodnocuje dopad na architekturu, testy, plán a rozpočet. Teprve poté se rozhodne, zda změna skutečně stojí za cenu, kterou její přijetí přináší.

V agilních projektech je situace specifická. Agilní přístup nestaví na tom, že požadavky jsou stabilní dlouhodobě, ale naopak očekává jejich vývoj. Přesto však platí, že požadavky musí být stabilní minimálně v rámci sprintu. V praxi to znamená, že během sprintu nesmí docházet k zásadním reinterpretacím uživatelských příběhů. Pokud se to přesto děje, většinou se ukáže, že produktový owner neměl dostatečně připravený backlog, nebo že stakeholdery nebyli včas zapojeni do rozpracování požadavků.

Nestabilita požadavků nikdy nezmizí sama od sebe. Je potřeba ji aktivně řídit a čelit jejím příčinám. Pokud však tým přijme správné postupy a začne pracovat se stakeholdery profesionálně a strukturovaně, stabilita se stane přirozeným vedlejším efektem dobře řízeného vývojového procesu.