Sú ľudia, ktorí keď potrebujú vyvinúť softvérový systém, obchádzajú dodávateľov a snažia sa získať „presnú cenu za projekt“. Potom zhromažďujú ponuky rôznych dodávateľov, vyberú si tú najlepšiu (obyčajne tú s najnižšou cenou), objednajú projekt a potom sa stiahnu na zmluvne dohodnutú dobu a očakávajú, že na konci dostanú fungujúci systém.
U nás takto nepracujeme. Nerobíme ponuky s pevnou cenou, aj keď potom často čelím otázkam prečo. Preto Vám vysvetlím, prečo si myslím, že ponuky s pevnou cenou sú zlé a prečo sa naši zákazníci bez nich zaobídu. Vychádzam zo svojho e-mailu potenciálnemu zákazníkovi, ktorému sa mi nepodarilo dovolať a vysvetliť mu všetko cez telefón.
Za prvé – nikdy nedostanete „presnú cenu“! Vývoj softvéru, osobitne vytvorenie nového systému podľa individuálnych požiadaviek zákazníka je kreatívny a invenčný proces. Nedá sa presne povedať, ako dlho bude trvať vývoj funkcie A. Dá sa však urobiť predpoklad, tj. odhadnúť to. Ale nič viac – len odhad. Osobitne ak uvážim množstvo informácií, ktoré sú na začiatku projektu o každej funkcii k dispozícii.
Každý softvérový vývojár vie, že nedokáže na začiatku presne predpovedať, ako dlho mu zaberie vývoj každej funkcie, takže sa pokúsi urobiť odhad. Na tom nie je nič zlé. Problém však nastáva v okamihu, keď sa tento odhad začne prezentovať ako skutočná realita. A to je presne to, čo sa stáva pri typickom priebehu vytvárania ponuky. Pretože každá spoločnosť vie, že pri zostavovaní ponuky nastáva riziko v odhade, snaží sa zaistiť sa proti tomuto riziku nadhodnotením odhadu. Pri vývoji softvéru sa bežne uvažuje s 25% bezpečnostnou prirážkou k odhadu, čo iba ukazuje, aký je samotný odhad nepresný. V každom prípade to, čo zákazník dostáva ako ponuku je odhad navýšený o nejakú prirážku. Vývojár sa potom bude cítiť spokojný, že nepríde o peniaze v prípade, že sa vývoj nebude uberať presne podľa očakávaní.
A teraz si predstavme, že Vám niekto povie že realizácia projektu bude stáť 25.000 USD. My však vieme, že skutočnosť bude odlišná. Na konci projekt bude stáť 24.998 USD alebo 25.231 USD. V skutočnosti je oveľa pravdepodobnejšie, že bude stáť buď 20.000 USD alebo 30.000 USD. V prvom prípade budete ukrátení o 5.000 USD v peniazoch alebo funkcionalite, ktorá by sa mohla vyvinúť. V druhom prípade utrpí kvalita. A dá sa ľahko dokázať, že ak sa dostane projekt nad rozpočet a zmluva je na pevnú cenu, každá normálne uvažujúca spoločnosť urobí všetko preto, aby minimalizovala svoje straty. To v praxi znamená ukončiť projekt čo najrýchlejšie. Proste ho vystreliť zo dverí, čím skôr tým lepšie. V prípade softvéru to tiež znamená vyvinúť mizerný, nezdokumentovaný kód, problémy riešiť radšej rýchlym „ohákovaním“ než elegantným riešením, a obmedziť testovanie na absolútne minimum. A aby sa ďalej znížila cena, nahradiť seniorných vývojárov za menej skúsených, pracovať cez čas – jednoducho využiť všetky prostriedky. Ak nebola pevná len cena ale aj termín dodania, a firme hrozí penále z omeškania, potom má ešte ďalšiu motiváciu na zníženie kvality len aby sa čo najviac obmedzili straty.
Toto vysvetľuje, prečo tak veľa IT projektov (nezáleží na tom, či sa jedná o vývoj alebo nasadenie štandardného systému) nakoniec nedopadne alebo aspoň skončí nespokojnosťou klienta.
Na ponukách s pevnou cenou je aj ďalšia vec, ktorá je zlá pre zákazníkov. Samotný tendrový proces už zo svojej podstaty vyžaduje, aby mal projekt pevný rozsah. To znamená, že klient musí stanoviť vopred konečný zoznam funkcionality, ktorú by mohol požadovať od vývojového tímu predtým, než sa začne samotný vývoj. Preto veľa ľudí začína proces spísaním dlhého zoznamu všetkého, čo ich len k zamýšľanému systému napadne.
Takýto zoznam nie je zlá vec, niekedy je jeho zostavenie ajcelkom prospešné. To, čo je zlé je jeho fixácia – tj. jeho vytesanie do kameňa zmluvy. A prečo? Po prvé, ak začínate písať tendrový dokument s vedomím, že ak na čokoľvek zabudnem, potom to už nikdy nedostanem, dopadne to obyčajne tak, že sa na zoznam dostane veľa nepotrebných vecí. Ale súčasne sa zabudne na veľa vecí, ktoré potrebné sú, pretože sa na ne príliš nemyslelo. A nemyslelo sa na ne preto, pretože tieto požiadavky Vás napadnú až v okamihu, keď začnete systém používať. Aj keď iba v jeho prvej verzii.
Inými slovami, napísať dokument s pevným rozsahom funkčnosti a potom ho zafixovať ako súčasť zmluvy znamená nevýhodný obchod - vymeniť veľa užitočných, ale doteraz neznámych požiadaviek za veľa vychytávok alebo funkcií, ktoré potom síce nikto nebude používať ale ktoré vznikli v procese vymýšľania riešenia v snahe na nič nezabudnúť.
Ak to zhrniem: myslím si, že dlhodobé plánovanie je vec prospešná, ale nepredávame ilúziu toho, že plán je niečo viac než tomu v skutočnosti je. My zaručujeme kvalitu a dátumy dodania príslušnej verzie (to pre každú iteráciu, obyčajne 2 týždne), a potom vopred zafixujeme cenu každej iterácie. Nefixujeme však rozsah projektu a nefixujeme ani celkovú cenu za projekt. Ak dostanete vynikajúcu myšlienku, ale dva mesiace po zahájení projektu – v poriadku, zapracujeme ju. Ak sa vo štvrtom mesiaci rozhodnete, že to, čo sa vyvinulo doteraz už stačí – v poriadku, môžete ukončiť práce kedykoľvek. Dávame Vám slobodu, ktorú Vám tradičný vývoj nad pevne definovaným projektom dať nemôže. A sme úplne úprimní a otvorený v tom, čo Vám ponúkame: ponúkame naše služby, v balíčkoch s dohodnutou cenou. Vyvinieme čo najviac v prvotriednej kvalite za objem peňazí, ktorý ste ochotní zaplatiť za projekt.
A ešte jedna vec: s agilným tímom sa Vám nikdy nestane, že dostanete balík kódu, ktorý sa nedá na nič použiť a to jediné, čo Vám potom ostáva je pokúsiť sa nájsť niekoho, kto by ho dokončil. A prečo? Pretože na konci každej iterácie dostávate novú, kompletnú verziu produktu, ktorá je 100% otestovaná a 100% funkčná. Neobsahuje všetky funkcie (po pravde, prvá verzia po prvej iterácii pravdepodobne nebude príliš nabitá funkciami), ale tie, ktoré boli dokončené sú naozaj hotové – a plne funkčné. To znamená že úplne od počiatku dostávate fungujúci softvérový systém, ktorý sa každé 2 týždne aktualizuje novými funkciami. Nikdy sa nestanete rukojemníkom vývojového tímu: stávate sa vlastníkom kódu a dostávate niečo, čo je funkčné. To najlepšie je, že len Vy sa rozhodujete ktorá funkčnosť je najdôležitejšia „teraz“ a mala byť dodaná v nasledujúcej iterácii.
Andy Brandt
Entrepreneur & Manager
Code Sprinters
Andy píše svoj blog na www.andybrandt.net
Preložil: Michal Vallo
U nás takto nepracujeme. Nerobíme ponuky s pevnou cenou, aj keď potom často čelím otázkam prečo. Preto Vám vysvetlím, prečo si myslím, že ponuky s pevnou cenou sú zlé a prečo sa naši zákazníci bez nich zaobídu. Vychádzam zo svojho e-mailu potenciálnemu zákazníkovi, ktorému sa mi nepodarilo dovolať a vysvetliť mu všetko cez telefón.
Za prvé – nikdy nedostanete „presnú cenu“! Vývoj softvéru, osobitne vytvorenie nového systému podľa individuálnych požiadaviek zákazníka je kreatívny a invenčný proces. Nedá sa presne povedať, ako dlho bude trvať vývoj funkcie A. Dá sa však urobiť predpoklad, tj. odhadnúť to. Ale nič viac – len odhad. Osobitne ak uvážim množstvo informácií, ktoré sú na začiatku projektu o každej funkcii k dispozícii.
Každý softvérový vývojár vie, že nedokáže na začiatku presne predpovedať, ako dlho mu zaberie vývoj každej funkcie, takže sa pokúsi urobiť odhad. Na tom nie je nič zlé. Problém však nastáva v okamihu, keď sa tento odhad začne prezentovať ako skutočná realita. A to je presne to, čo sa stáva pri typickom priebehu vytvárania ponuky. Pretože každá spoločnosť vie, že pri zostavovaní ponuky nastáva riziko v odhade, snaží sa zaistiť sa proti tomuto riziku nadhodnotením odhadu. Pri vývoji softvéru sa bežne uvažuje s 25% bezpečnostnou prirážkou k odhadu, čo iba ukazuje, aký je samotný odhad nepresný. V každom prípade to, čo zákazník dostáva ako ponuku je odhad navýšený o nejakú prirážku. Vývojár sa potom bude cítiť spokojný, že nepríde o peniaze v prípade, že sa vývoj nebude uberať presne podľa očakávaní.
A teraz si predstavme, že Vám niekto povie že realizácia projektu bude stáť 25.000 USD. My však vieme, že skutočnosť bude odlišná. Na konci projekt bude stáť 24.998 USD alebo 25.231 USD. V skutočnosti je oveľa pravdepodobnejšie, že bude stáť buď 20.000 USD alebo 30.000 USD. V prvom prípade budete ukrátení o 5.000 USD v peniazoch alebo funkcionalite, ktorá by sa mohla vyvinúť. V druhom prípade utrpí kvalita. A dá sa ľahko dokázať, že ak sa dostane projekt nad rozpočet a zmluva je na pevnú cenu, každá normálne uvažujúca spoločnosť urobí všetko preto, aby minimalizovala svoje straty. To v praxi znamená ukončiť projekt čo najrýchlejšie. Proste ho vystreliť zo dverí, čím skôr tým lepšie. V prípade softvéru to tiež znamená vyvinúť mizerný, nezdokumentovaný kód, problémy riešiť radšej rýchlym „ohákovaním“ než elegantným riešením, a obmedziť testovanie na absolútne minimum. A aby sa ďalej znížila cena, nahradiť seniorných vývojárov za menej skúsených, pracovať cez čas – jednoducho využiť všetky prostriedky. Ak nebola pevná len cena ale aj termín dodania, a firme hrozí penále z omeškania, potom má ešte ďalšiu motiváciu na zníženie kvality len aby sa čo najviac obmedzili straty.
Toto vysvetľuje, prečo tak veľa IT projektov (nezáleží na tom, či sa jedná o vývoj alebo nasadenie štandardného systému) nakoniec nedopadne alebo aspoň skončí nespokojnosťou klienta.
Na ponukách s pevnou cenou je aj ďalšia vec, ktorá je zlá pre zákazníkov. Samotný tendrový proces už zo svojej podstaty vyžaduje, aby mal projekt pevný rozsah. To znamená, že klient musí stanoviť vopred konečný zoznam funkcionality, ktorú by mohol požadovať od vývojového tímu predtým, než sa začne samotný vývoj. Preto veľa ľudí začína proces spísaním dlhého zoznamu všetkého, čo ich len k zamýšľanému systému napadne.
Takýto zoznam nie je zlá vec, niekedy je jeho zostavenie ajcelkom prospešné. To, čo je zlé je jeho fixácia – tj. jeho vytesanie do kameňa zmluvy. A prečo? Po prvé, ak začínate písať tendrový dokument s vedomím, že ak na čokoľvek zabudnem, potom to už nikdy nedostanem, dopadne to obyčajne tak, že sa na zoznam dostane veľa nepotrebných vecí. Ale súčasne sa zabudne na veľa vecí, ktoré potrebné sú, pretože sa na ne príliš nemyslelo. A nemyslelo sa na ne preto, pretože tieto požiadavky Vás napadnú až v okamihu, keď začnete systém používať. Aj keď iba v jeho prvej verzii.
Inými slovami, napísať dokument s pevným rozsahom funkčnosti a potom ho zafixovať ako súčasť zmluvy znamená nevýhodný obchod - vymeniť veľa užitočných, ale doteraz neznámych požiadaviek za veľa vychytávok alebo funkcií, ktoré potom síce nikto nebude používať ale ktoré vznikli v procese vymýšľania riešenia v snahe na nič nezabudnúť.
Ak to zhrniem: myslím si, že dlhodobé plánovanie je vec prospešná, ale nepredávame ilúziu toho, že plán je niečo viac než tomu v skutočnosti je. My zaručujeme kvalitu a dátumy dodania príslušnej verzie (to pre každú iteráciu, obyčajne 2 týždne), a potom vopred zafixujeme cenu každej iterácie. Nefixujeme však rozsah projektu a nefixujeme ani celkovú cenu za projekt. Ak dostanete vynikajúcu myšlienku, ale dva mesiace po zahájení projektu – v poriadku, zapracujeme ju. Ak sa vo štvrtom mesiaci rozhodnete, že to, čo sa vyvinulo doteraz už stačí – v poriadku, môžete ukončiť práce kedykoľvek. Dávame Vám slobodu, ktorú Vám tradičný vývoj nad pevne definovaným projektom dať nemôže. A sme úplne úprimní a otvorený v tom, čo Vám ponúkame: ponúkame naše služby, v balíčkoch s dohodnutou cenou. Vyvinieme čo najviac v prvotriednej kvalite za objem peňazí, ktorý ste ochotní zaplatiť za projekt.
A ešte jedna vec: s agilným tímom sa Vám nikdy nestane, že dostanete balík kódu, ktorý sa nedá na nič použiť a to jediné, čo Vám potom ostáva je pokúsiť sa nájsť niekoho, kto by ho dokončil. A prečo? Pretože na konci každej iterácie dostávate novú, kompletnú verziu produktu, ktorá je 100% otestovaná a 100% funkčná. Neobsahuje všetky funkcie (po pravde, prvá verzia po prvej iterácii pravdepodobne nebude príliš nabitá funkciami), ale tie, ktoré boli dokončené sú naozaj hotové – a plne funkčné. To znamená že úplne od počiatku dostávate fungujúci softvérový systém, ktorý sa každé 2 týždne aktualizuje novými funkciami. Nikdy sa nestanete rukojemníkom vývojového tímu: stávate sa vlastníkom kódu a dostávate niečo, čo je funkčné. To najlepšie je, že len Vy sa rozhodujete ktorá funkčnosť je najdôležitejšia „teraz“ a mala byť dodaná v nasledujúcej iterácii.
Andy Brandt
Entrepreneur & Manager
Code Sprinters
Andy píše svoj blog na www.andybrandt.net
Preložil: Michal Vallo
Žádné komentáře:
Okomentovat