Prečo sa požiadavky v IT projekte stále menia a ako ich dostať pod kontrolu

Prečo sa požiadavky v IT projekte stále menia?

Požiadavky sa menia predovšetkým preto, že na začiatku projektu nepozná celý problém nikto z účastníkov. Biznis sa medzitým vyvíja, používatelia zistia svoje skutočné potreby až pri prvej ukážke a technické prekážky sa objavia počas vývoja. Podľa PMI zažije rozširovanie rozsahu (scope creep) približne 52 % projektov.

Príčiny zoradené podľa toho, ako často sa s nimi stretávame v praxi:

1. Nejasné alebo neúplné zadanie. Zadanie opisuje riešenie („chceme modul na objednávky“), nie problém, ktorý má vyriešiť. Detaily potom pribúdajú počas celého projektu.
2. Nezmapovaný proces klienta. Softvér sa navrhuje podľa predstavy o fungovaní firmy, nie podľa skutočného stavu. Výnimky, schvaľovanie a ručné obchádzky sa ukážu až pri testovaní.
3. Používatelia vidia produkt prvýkrát neskoro. Bez prototypu len ťažko posúdia, čo im vyhovuje. Prvá ukážka preto takmer vždy prinesie vlnu úprav.
4. Príliš veľa hlasov a žiadne rozhodovanie. Obchod, účtovníctvo aj vedenie posielajú požiadavky priamo vývojárom a nikto ich nezoraďuje podľa priority.
5. „Stratené v preklade“. Klient používa jazyk biznisu, vývojári jazyk systému. Nedorozumenia z analýzy sa prejavia až na hotovej funkcii.
6. Zmena ľudí. Nový manažér alebo produktový vlastník prináša novú víziu a iné priority.
7. Vonkajšie vplyvy. Legislatíva (GDPR, daňové zmeny, e-fakturácia), krok konkurencie alebo nová technológia, ktorá dáva počas dlhého projektu väčší zmysel.
8. Skryté technické obmedzenia. Napojenie na starý systém alebo API tretej strany sa správa inak, než sa predpokladalo.

Prvé štyri príčiny vznikajú vo vnútri projektu a dajú sa výrazne obmedziť. Posledné štyri sú prirodzené, a preto je potrebný proces, nie zákaz zmien.

Ako zistiť, čo presne spôsobuje zmeny vo vašom projekte?

Príčinu zistíte najrýchlejšie podľa toho, kedy a od koho zmeny prichádzajú. Vyberte posledných 10 až 20 zmenových požiadaviek a pri každej zaznamenajte, kto ju zadal, v ktorej fáze prišla a či pridáva novú potrebu, alebo opravuje nepochopenie. Opakujúci sa vzor ukáže príčinu presnejšie než akýkoľvek dojem.

Čo pozorujete	Pravdepodobná príčina	Kam smerovať nápravu
Zmeny prídu hneď po každom demo stretnutí	Používatelia nevideli produkt dosť skoro	Prototypy a kratšie iterácie
„To sme mysleli inak“ pri hotovej funkcii	Chýbajúce akceptačné kritériá, jazyková bariéra	Konkrétne príklady a kritériá ku každej požiadavke
Požiadavky si navzájom odporujú	Chýba jeden rozhodujúci vlastník	Určiť produktového vlastníka
Objavujú sa výnimky a „špeciálne prípady“	Proces nebol zmapovaný	Analýza procesov
Zmeny prichádzajú v nárazoch po porade vedenia	Nejasná stratégia alebo ciele	Merateľné ciele projektu
Vývojári hlásia „toto sa nedá, ako sme plánovali“	Skryté technické obmedzenia	Technická analýza integrácií vopred

Platí aj jednoduché pravidlo: ak viac ako tretina zmien opravuje nepochopenie a nepridáva novú hodnotu, problém nespočíva v meniacom sa prostredí, ale v zadaní. Zadanie, ktoré tomu predchádza, rozoberáme v článku čo má obsahovať technické zadanie projektu.

Čo môžete urobiť hneď, aby zmeny prestali rozbíjať projekt?

Najrýchlejší efekt prinesú tri kroky: jeden vstup pre všetky požiadavky, jeden človek, ktorý o nich rozhoduje, a písomne uvedený dopad na čas a cenu pri každej zmene. Nový nástroj ani iný dodávateľ nie sú potrebné. Nastavenie zvyčajne zaberie pár dní a chaos v projekte citeľne utlmí.

Rýchle opatrenia

1. Zaveďte zoznam zmien (change log). Každá požiadavka má dátum, autora, dôvod a stav. Postačí tabuľka, Jira alebo Trello. Žiadne zadania na chodbe ani v súkromných správach vývojárom.
2. Určte produktového vlastníka. Jedna osoba na strane firmy zbiera podnety zo všetkých oddelení a rozhoduje o poradí.
3. Ku každej zmene priraďte dopad: koľko hodín, aký posun termínu, čo sa kvôli nej odsúva. Keď je cena zmeny viditeľná, veľa požiadaviek typu „bolo by fajn“ zanikne samo.
4. Prioritizujte jednoduchou metódou. Použite MoSCoW (must, should, could, won't) alebo ICE skóre (vplyv, istota, jednoduchosť na škále 1 až 10). Do aktuálnej iterácie patria len položky „must“.
5. Píšte akceptačné kritériá. Namiesto „rýchly export“ uveďte „export 5 000 objednávok do CSV do 10 sekúnd“. Odlíšte ich od definície dokončenia, ktorá rieši technickú kvalitu.
6. Dohodnite toleranciu. Vopred stanovte, aká odchýlka rozpočtu alebo termínu (napríklad 10 alebo 20 %) ešte nevyžaduje eskaláciu vedeniu.

Ak zmeny už teraz posúvajú rozpočet, odporúčame článok, prečo sa softvérový projekt predraží a ako to zachytiť včas.

Kedy treba nestabilné požiadavky riešiť systematicky s vývojovým partnerom?

Systematické riešenie je potrebné vtedy, keď rýchle opatrenia nestačia: zmeny prichádzajú aj po zavedení zoznamu zmien a dotýkajú sa jadra procesu, prípadne projekt prepája viac oddelení alebo systémov. Riešením je discovery fáza, analýza procesov a iteratívny vývoj s architektúrou, ktorá zmenu unesie.

Nejde o akademickú otázku. Podľa PMI nesplní ciele 47 % neúspešných projektov práve pre nepresné riadenie požiadaviek.

Ako k tomu pristupujeme v BeCode

• Discovery pred kódom. V discovery fáze projektu spolu s vami zmapujeme ciele, používateľov, výnimky a integrácie. Väčšina „neskorých“ zmien sa tak objaví na papieri, kde je ich oprava najlacnejšia.
• Softvér postavený okolo reálneho procesu. Nepreberáme predstavu o procese, ale skutočný tok práce vo firme vrátane ručných obchádzok. Preto CRM alebo interný systém na mieru len zriedka prekvapí výnimkou, ktorú nikto nespomenul.
• Prototyp a MVP namiesto veľkého odovzdania. Používatelia pracujú s prvou verziou po týždňoch, nie po mesiacoch. Spätná väzba prichádza, kým je zmena ešte malá.
• Iterácie s jasnou prioritou. Každé kolo má dohodnutý rozsah. Nové požiadavky zaraďujeme do zoznamu úloh (backlogu) a do ďalšieho kola, nie doprostred rozpracovanej práce.
• Architektúra, ktorá rastie s vami. Vďaka modulárnemu návrhu sa nová legislatíva, napojenie ďalšieho systému či AI automatizácia pridajú bez prestavby celého riešenia. Viac v článku o škálovateľnej softvérovej architektúre.

Ak Váš projekt už beží a zmeny ho zahlcujú, vieme ho prevziať aj v strede vývoja. Začíname krátkou analýzou rozpracovaného stavu a prioritizáciou zoznamu úloh.

Ako predísť tomu, aby sa požiadavky menili nekontrolovane?

Prevencia stojí na štyroch pilieroch: problém je pochopený skôr, než sa začne programovať, rozhoduje jedna osoba, používatelia vidia produkt čo najskôr a pre zmeny platí dohodnutý proces. Zmeny tým nezmiznú, ale prestanú prekvapovať a začnú výsledok zlepšovať namiesto toho, aby ho narúšali.

Kontrolný zoznam pred štartom a počas projektu

• Ciele projektu sú merateľné (SMART) a vedenie ich odsúhlasilo.
• Procesy sú zmapované vrátane výnimiek, pozri analýzu firemných procesov pred digitalizáciou.
• Je určený jeden produktový vlastník s rozhodovacou právomocou.
• Každá požiadavka má akceptačné kritériá a konkrétny príklad.
• Prvý klikateľný prototyp je naplánovaný do niekoľkých týždňov od štartu.
• Integrácie a legacy systémy sú technicky overené ešte pred odhadom.
• V rozpočte je rezerva na zmeny a dohodnutá tolerancia odchýlok.
• Zmenový proces (zápis, odhad dopadu, schválenie) je dohodnutý v zmluve.
• Pravidelne prebieha ukážka (demo) a retrospektíva, napríklad každé 2 týždne.
• Roadmapa sa reviduje podľa dát z používania, nie podľa najhlasnejšieho hlasu.

Pri dlhodobých produktoch odporúčame aj dobre vedenú roadmapu digitálneho produktu. Nové nápady v nej získajú svoje miesto v čase a netlačia na aktuálny šprint.

Ak sa v Vašom projekte opakujú tie isté zmeny a príčina nie je jasná, dá sa objasniť skôr, než vznikne ďalší riadok kódu. V BeCode začíname úvodnou analýzou cieľov, procesov a integrácií, z ktorej vznikne zadanie, na ktoré sa dá spoľahnúť.

Časté otázky

Je zmena požiadaviek v IT projekte znakom zlyhania?

Nie. Zmena požiadaviek patrí k vývoju softvéru, pretože projekt postupne odhaľuje detaily a biznis sa medzitým vyvíja. Zlyhaním je až neriadená zmena: bez zápisu, odhadu dopadu a rozhodnutia o priorite. Dobre riadené zmeny často vedú k lepšiemu produktu, než aký opisovalo pôvodné zadanie.

Aký je rozdiel medzi agilným a waterfall prístupom k zmenám požiadaviek?

Waterfall sa snaží zadanie na začiatku zafixovať a každú zmenu rieši formálnym zmenovým konaním, ktoré býva drahé. Agilný prístup, napríklad Scrum, so zmenami počíta: pracuje v krátkych iteráciách a nové požiadavky zaraďuje do backlogu podľa priority. Pri softvéri na mieru s nejasným zadaním je agilný model zvyčajne výhodnejší.

Ako komunikovať zmeny s dodávateľom, aby neohrozili rozpočet a termíny?

Každú zmenu zasielajte jedným kanálom a cez jednu zodpovednú osobu. Od dodávateľa si pred schválením vyžiadajte písomný odhad dopadu na hodiny a termín. Vopred dohodnite toleranciu odchýlok a pravidelné ukážky, na ktorých sa zmeny prioritizujú. Rozpočet tak rastie len vedome, nie nenápadne.

Čo je scope creep a ako súvisí so zmenou požiadaviek?

Scope creep je postupné, často nenápadné rozširovanie rozsahu projektu bez zodpovedajúcej úpravy rozpočtu a termínov. Vzniká, keď sa zmeny požiadaviek prijímajú bez posúdenia dopadu. Zmena požiadaviek je prirodzený jav, scope creep je jej neriadená podoba. Predchádza mu zoznam zmien a jasná prioritizácia.

Kto zaplatí za zmenu požiadaviek počas vývoja?

Závisí to od zmluvného modelu. Pri pevnej cene sa zmeny mimo dohodnutého rozsahu zvyčajne naceňujú samostatne, pri modeli čas a materiál sa premietnu do odpracovaných hodín. Rozhoduje aj to, či ide o novú požiadavku, alebo o opravu nepochopeného zadania. Preto sa oplatí dohodnúť zmenový proces v zmluve vopred.

Ako často sa môžu meniť požiadavky v Scrume?

V backlogu sa požiadavky môžu meniť kedykoľvek, rozsah rozbehnutého šprintu, typicky 1 až 4 týždne, však zostáva nemenný. Nové podnety produktový vlastník prioritizuje a zaradí do niektorého z ďalších šprintov. Tím tak zostáva flexibilný a zároveň môže sústredene dokončiť rozpracovanú prácu.