- na začiatku so zákazníkom urobím vyčerpávajúci rozhovor kde sa snažím zistiť hlavné požiadavky systému
- potom zabijem veľa času spisovaním týchto požiadaviek a vytvorím detailný návrh riešenia spolu s odhadom ceny (ponuka pre zákazníka)
- po dohode so zákazníkom vyjasním veci ktoré mi pri spisovaní požiadaviek neboli jasné
- dohodu o vytvorení systému podpíšem spolu so zákazníkom, pričom sa odvolávam na fixný rozsah požiadaviek a fixnú výslednú cenu (akékoľvek zmeny požiadaviek sa riešia nad rámec dohody)
- rozídem sa so zákazníkom s tým, že si stanovíme termín prezentácie prvej verzie systému resp. nasledujúcej etapy alebo míľnika vo vývoji
- vyvíjam systém, so zákazníkom vôbec nekomunikujem alebo len veľmi málo, vždy sa odvolávam na detailne spísané požiadavky, robím systém "tak ako to zákazník chcel"
- systém počas dohodnutých míľnikov prezentujem zákazníkovi (ak sú vôbec nejaké priebežné míľniky dohodnuté v zmluve)
- nakoniec systém odovzdám, súlad s požiadavkami demonštrujem funkčnými testami ktoré sú súčasťou zmluvy zo začiatku projektu
Pri komunikácii so zákazníkom čelím v zásade aj týmto typom otázok:
- "Bolo by ťažké zmeniť tento gombík z červeného na modrý? Zistil som, že modré gombíky sa používateľom páčia omnoho viac." a typická odpoveď "V zmluve sa píše o červenom gombíku, tak sme si to predsa na začiatku dohodli. Zmena sa musí riešiť nad rámec dohody."
- "Čo sa stane keď nastane situácia XYZ? Ako je to v systéme ošetrené?" a typická odpoveď "V dohodnutých požiadavkach o situácii XYZ nie je ani zmienka, musí sa to riešiť nad rámec zmluvy ako dodatočná úprava systému."
Pozorný čitateľ asi cíti kam týmto smerujem. Klasická schéma "pozbieram požiadavky - podpíšem zmluvu - pracujem presne podľa požiadaviek - odovzdám systém" jednoducho nie je dobrá. Tento prístup má nasledujúce problémy:
- nikto na svete nedokáže na začiatku projektu detailne stanoviť všetky požiadavky, pretože požiadavky sa vždy vyvíjajú v čase v dôsledku rôznych faktorov (trh, potreby zákazníka, používatelia systému, prípadne iné okolnosti)
- biznis hodnota jednotlivých funkcií systému z pohľadu zákazníka sa vždy v čase mení, rovnako ako sa mení trh v ktorom zákazník pôsobí - napríklad po čase sa ukáže, že by bolo dobré implementovať funkciu A (zákazník sleduje nový trend na trhu a prispôsobí tomu systém), alebo funkcia B po nasadení prvej verzie systému nepriniesla očakávaný výsledok a tak ju nemá zmysel ďalej rozvíjať
- detailné spísanie požiadaviek na začiatku projektu vytvára dojem, že sme celú doménu zanalyzovali a máme ju plne pokrytú (ignorujeme zmenu ako nevyhnutný aspekt všetkého okolo nás, ignorujeme spätnú väzbu zákazníka v čase resp. jeho potrebu vyvinúť systém tak, aby v danom okamihu poskytoval maximálnu biznis hodnotu)
- detailné spísanie požiadaviek na začiatku projektu spôsobuje výrazné oneskorenie pred dodaním prvej prezentovateľnej verzie systému
- zmena požiadaviek sa vždy rieši nad rámec pôvodnej zmluvy - vo všeobecnosti sú pôvodné požiadavky zmluvne zabezpečené voči akejkoľvek zmene
Ako keby sme podľa tejto schémy vytvárali niečo čo si raz stanovíme, ohraničíme a zabezpečíme zmluvou. Potom sa ponoríme pod hladinu vyvíjať systém bez toho, aby sme sa niekedy aspoň trocha vynorili a opýtali sa zákazníka prirodzené otázky:
- Ide projekt dobrým smerom?
- Poskytuje systém v danom čase maximálnu biznis hodnotu pre zákazníka?
- Nepracujeme zbytočne na funkciách ktoré nemajú veľkú hodnotu vzhľadom na súčasný stav (trh, potreby zákazníka, iné okolnosti)?
- A predovšetkým - je tento systém naozaj ten, ktorý zákazník chcel (a chce)?
Aký zákazník má skutočne záujem na tom, aby sa aktívne NEpodieľal na vývoji systému ktorý v konečnom dôsledku prevezme a zaplatí on sám? Sú dve možnosti: zákazník alibista ktorý to má "v paži" a zákazník ktorý je hlúpy. Prvý prípad možno pozorovať vo verejnom IT sektore prepletenom korupciou a lobizmom tzv. "veľkých hráčov". S týmto bohužiaľ bežný obchodník nič neurobí, môže sa však do tohto kolotoča zapojiť sám ako subdodávateľ a zbierať omrvinky po "veľkých hráčoch" (týmto spôsobom funguje mnoho IT firiem). Druhý prípad nie je taký zlý, pretože šikovný obchodník dokáže zákazníka presvedčiť že jeho aktívnou účasťou sa biznis hodnota vyvíjaného systému maximalizuje a zákazník dostane presne to čo chce. Sú to v konečnom dôsledku peniaze zákazníka, z ktorých sa má vyvinúť systém vyhovujúci jeho požiadavkám.
Aký je teda vhodný spôsob realizácie projektu? No predovšetkým taký, ktorý sa orientuje na potreby zákazníka namiesto striktného držania sa pôvodného kontraktu. Jeden prístup používa user stories ako "príbehy" používania systému z pohľadu zákazníka. User stories zachytávajú požiadavky systému s väzbou na proces ktorým sú realizované:
- Karta
- Konverzácia
- Akceptácia
Karta: stručný popis požiadavky s použitím vzoru Rola-Cieľ-Motivácia, napríklad: "Ako správca objednávok, chcel by som mať možnosť zobraziť zoznam všetkých nevybavených objednávok, aby som ich mohol následne vybaviť". Motivácia je veľmi dôležitá, popisuje biznis hodnotu požiadavky ("prečo"). Cieľ zas popisuje požadovanú funkcionalitu systému ("čo"). Karta je vždy stručná, cieľom je vyhnúť sa predčasnej detailnej formulácii požiadavky a sústrediť sa hlavne na cieľ a motiváciu. Kartu možno vnímať ako prísľub budúcej konverzácie, poznámku do budúcna aby sme na požiadavku nezabudli.
Konverzácia: rozhovor medzi zákazníkom a ľuďmi zodpovednými za vývoj systému. Najlepší spôsob komunikácie medzi ľuďmi je bežná konverzácia a nie diagramy s farebnými krabičkami ako si mnohí analytici myslia (krabičky sú dobré na vizualizáciu myšlienok). Konverzáciu nemožno zmluvne ohraničiť a prezentované myšlienky sa nedajú vytesať do kameňa ako detailné požiadavky do zmluvy. Tým, že sa nesnažíme všetko detailne zdokumentovať, umožňujeme prirodzený vývoj nášho poznania problematiky a požiadaviek smerom k lepšiemu pochopeniu toho, čo od nás zákazník vlastne chce. Každá konverzácia speje k vzájomnému porozumeniu požiadaviek tak, aby výsledný systém reflektoval predstavu zákazníka. Konverzácie sú časté a vôbec nemusia byť zdĺhavé, vždy podľa potreby. Zákazník ma dobrý pocit, že vyvíjaný systém reflektuje jeho aktuálne biznis potreby. Vývojový tím má dobrý pocit, že pomáhajú zákazníkovi naplniť jeho biznis ciele. Konverzácia je o kooperácii a partnerstve.
Akceptácia: akceptačné testy za účasti zákazníka ktoré preukazujú správnosť implementácie každej požiadavky. Zákazník má vždy posledné slovo v rozhodovaní kedy je daná požiadavka "hotová".
Schému Karta-Konverzácia-Akceptácia možno aplikovať na každú požiadavku systému. Na začiatku projektu sa identifikujú najdôležitejšie požiadavky. Ako prvé sa vždy realizujú požiadavky s najvyššou biznis prioritou. Biznis prioritu určuje a v čase mení zákazník podľa aktuálnych okolností. Požiadavky môžu počas vývoja systému pribúdať alebo ubúdať na základe podnetov od zákazníka. Vývojový tím sa vždy sústredí na to, čo je v danom momente najpodstatnejšie. Tento prístup je v mnohom spoločný s agilnou filozofiou vývoja a princípov Agile Manifesto:
- ľudia a interakcie (bežná ľudská komunikácia) namiesto procesov a nástrojov
- fungujúci systém zodpovedajúci aktuálnym požiadavkám zákazníka namiesto systému ktorý len realizuje prvotné požiadavky
- partnerstvo a spolupráca namiesto formálneho držania sa zmluvy stanovenej na začiatku projektu
- reakcia na zmenu (konverzácia) umožňujúca sledovať aktuálne potreby zákazníka namiesto vytesania detailných požiadaviek do kameňa v zmluve na začiatku projektu a nasledovania tohto plánu bez ohľadu na okolnosti
Stanovenie detailných požiadaviek hneď na začiatku projektu a neúčasť zákazníka pri vývoji systému rozdeľuje zákazníka a vývojový tím na dve strany: každá sa snaží hájiť svoj záujem v duchu dojednanej zmluvy. Zákazník chce systém presne zodpovedajúci požiadavkám za danú cenu a vývojový tím chce čo najrýchlejšie (najlacnejšie, najefektívnejšie) vytvoriť systém spĺňajúci požiadavky. Stráca sa tu aspekt kvality s dôrazom na rozšíriteľnosť systému do budúcna - hlavným cieľom je predsa systém podľa požiadaviek. Systém podľa požiadaviek však nemusí znamenať aj fungujúci systém a už vôbec nemusí znamenať systém, ktorý reflektuje aktuálne potreby zákazníka. Kde je spolupráca, partnerstvo, vzájomný dialóg s cieľom vytvorenia toho správneho systému?
Softvér sám o sebe nemá vnútornú hodnotu. Softvér má hodnotu pre zákazníkov ak im pomôže v ich biznise. Vývoj softvéru je predovšetkým o porozumení potrebám zákazníkov a vývoji systémov ktoré čo najlepšie tieto potreby reflektujú. Iba tak môže vzniknúť pravé obchodné partnerstvo ktoré je zárukou dlhodobého úspechu pre obidve strany.
Súvisiace odkazy
Use Stories to Deliver Business Value
Agile software development
