Živím sa už nejakú dobu vývojom softvéru. Tento odbor som aj vyštudoval. Vo firme, kde pracujem, vyvíjame softvér pre rôznych zákazníkov - od malých firiem, cez stredné firmy, až po giganty typu plynárenských spoločností, veľké banky, či štátne inštitúcie.
Za tú dobu už som si zvykol, že zákazníci (obzvlášť ich manažéri) majú "trošku" inú optiku, a čo je z ich pohľadu drobnosť, je často "pakárna" na pár dní programovania, a naopak. Na čo si však nemôžem stále zvyknúť, je neustále podceňovanie dôležitosti aspoň nejakého zadania a podrobnej analýzy. Často je zákazník ako tá povestná ženská - nevie čo vlastne chce, ale neprestane, kým to nedostane (a keď už to má, tak nevie, čo s tým).
Nedávno sme dostali vyzvanie do výberového konania na internetový obchod od jednej obchodnej firmy. Zadanie bolo prekvapivo dobre spracované, ale harmonogram bol totálne pomýlený. Na analýzu bol jeden mesiac (vrátane "drobností" ako vyriešenie platobnej brány "na všetky banky v ČR a SR poskytujúce možnosť platieb cez internet" a na úverové spoločnosti), na realizáciu potom mesiace štyri. Ani po niekoľkých upozorneniach na nereálnosť tohoto harmonogramu nebol zadávateľ ochotný pristúpiť na zmenu, takže sme sa nakoniec rozhodli z výberového konania odstúpiť.
Podobne je vo fáze analýzy často problém so spoluprácou zo strany pracovníkov zákazníka, ktorí si neuvedomujú jej dôležitosť (zriedkavou výnimkou sú v tomto smere napríklad ľudia z ČNB). Pritom pokiaľ sa analýza odflákne, a je jedno, či kvôli nekompetentnosti a/alebo nedôslednosti tvorcu alebo zákazníka, je nádej na úspešné dokončenie projektu minimálna. Úspešným dokončením projektu pritom nemyslím len to, že sa dodrží termín, vystaví faktúra, a zákazník ju včas zaplatí, ale predovšetkým následné používanie vytvoreného diela, a spokojnosť zákazníka.
Analýza pritom - aspoň podľa mojich skúseností1 - nemusí byť technicky detailná, ba dokonca často ani nie je vhodné, aby obsahovala detaily ako diagram tried, sekvenčné diagramy, vývojové diagramy a podobne2. Je však nutné, aby obsahovala podrobný popis chovania navrhovaného systému zo strany používateľa, a v prípade, že bude spolupracovať s inými systémami, tak i podrobný popis použitého aplikačného rozhrania. Takúto analýzu by si mal zákazník poriadne preštudovať, opripomienkovať, a nakoniec, keď už si povie "fajn, takto to chceme, takto to má byť", schváliť.
Proces tvorby takejto analýzy je pritom časovo náročný, a preto ma vždy prekvapujú zákazníci, ktorí síce očakávajú dlhú dobu trvania projektu (kľudne i pol roka či viac), ale na analýzu počítajú dva-tri týždne, v lepšom prípade mesiac. Podľa mojich skúseností však analýza tvorí tretinu až polovicu doby trvania projektu (od zahájenia po spustenie pilotnej prevádzky). Hlavným časovým nárokom je, že analytické práce (v tom rozsahu, ako ju popisujem v predchádzajúcom odstavci) sa na rozdiel od následných programátorských prác dosť problematicky paralelizujú.
Dobrá analýza však chráni obe strany. Softvérovú firmu pred neustálymi zmenami požiadaviek zákazníka a nekonečným nezaplateným vývojom (ešte som nezažil zákazníka, ktorý by bol ochotný pristúpiť na platenie za odpracované hodiny, všetci chcú pevnú cenu za projekt), naopak zákazníka pred nekvalitnou prácou dodávateľa. Obaja majú možnosť v prípade problémov vziať analýzu, a tomu druhému ju "obúchať o hlavu" - dodávateľ s tým, že za zmeny v rozpore s analýzou musí zákazník zaplatiť, zákazník s tým, že výsledný program sa nechová tak, ako je v analýze napísané, a je nutné tento rozpor odstrániť (samozrejme zadarmo a čo najrýchlejšie). Ba dokonca má zákazník s kvalitne napísanou analýzou možnosť "vykašľať" sa v prípade problémov na pôvodného dodávateľa, a vybrať si iného. Ten bude mať vývoj vďaka kvalitnej analýze značne uľahčený.
A preto - nepodceňujte dôležitosť analýzy, nech už ste na strane dodávateľa softvéru, alebo na strane zadávateľa a následne používateľa vytvoreného diela.
1 Tu musím skonštatovať, že naša firma sa sústredí na vývoj front-endových aplikácií hlavne pre firemné intranety, takže všetko čo ďalej píšem, je ovplyvnené týmto pohľadom.
2 Prílišná technickosť analýzy môže dokonca spôsobiť, že netechnicky orientovaní pracovníci zákazníka, zodpovední za jej schválenie, jej čítanie odfláknu, a z toho neskôr vzniknú zbytočné problémy.
