Neokrádejte své klienty aneb jak také dělat (nejen) web

2. prosince 2002

•

Nedávno jste se na Intervalu v článku „Jak dělat web“ mohli dočíst o vcelku logických a používaných zásadách řízení (nejen) IT projektů. Představa takto bravurně řízeného projektu je mnohdy jen vzdáleným ideálem. Zákazník často přes sebelepší analýzu neví, co chce, a kromě toho se popisovaná metodika neslučuje s „pozorováním programátorů v divočině“. Co s tím?

Expozice

Začněme se strohými fakty. Co brání úspěšnému dokončení IT projektu? Odpověď takřka tautologická zní: Jsou to rizika. Pokud toto stručné tvrzení rozvedeme hlouběji, jistě nás napadnou i konkrétní příklady. Jsou to například:

zpoždění harmonogramu
přemíra chyb ve výsledném produktu
nepochopení zadání
časté průběžné změny zadání
zbytečně komplikovaný produkt
fluktuace pracovníků
… a další

Za účelem minimalizace rizik vznikají různé metodologie projektového řízení. S esencí velké části z nich jste se mohli seznámit ve zmiňovaném článku Jak dělat web. Projdeme-li však „klasickou metodu“ realistickým okem šťourala, i na těchto typických rizicích zjistíme, že ideální průběh má od reality mnohdy daleko.

Krize

(To, že v našem článku předchází krize kolizi, můžeme brát jako důkaz, že opravdu není možné na vývoj software slepě aplikovat tradiční postupy.)

Zpoždění harmonogramu

Upřesněný harmonogram prací vzniká v průběhu analýzy. Obvykle vychází z detailní analýzy požadavků a zkušeností projektových týmů s obdobnými projekty. Zákazník se samozřejmě bez závazného harmonogramu neobejde. Na druhou stranu je pochopitelné, že se zde při sebezkušenějším týmu skrývají četná potenciální úskalí, která na povrch vyplynou až v realizační fázi. Těmto úskalím se dodavatel snaží předejít započtením notných rezerv a maximální striktností požadavků specifikovaných v analýze.

Tento postup však mnohdy vede doslova k „boji o rizika“ – zákazník se snaží z dodavatele vyždímat maximum, ten naopak může podlehnout pokušení zneužít nezkušenosti zástupců klienta a schovat do analýzy rizika na straně zákazníka takovým způsobem, že valnou část předávací fáze tvoří dohadování argumentované dodavatelem slovy „ale to přece v analýze nebylo“.

Přemíra chyb

Proti chybám se bráníme testováním, to je známá věc. Pokud postupujeme stylem „analýza -> architektura -> implementace -> testování -> předání“, přirozeně nás napadnou zvídavé otázky související s předchozím problémem: Bude na testy dost času? Nehrozí, že testy budeme muset z nedostatku času oželet? Nevynoří se během testování problémy nečekané obtížnosti?

Nepochopení zadání

Proč se vlastně dělá nějaká analýza, a nezačneme rovnou architekturou systému a programováním? Je to proto, že zákazník a dodavatel mluví různými jazyky. Zákazník vidí své obchodní potřeby, má přibližnou představu o svých požadavcích, leč mnohdy (a nezazlívejme mu to) vůbec nerozumí implementační náročnosti „samozřejmých detailů“. Přesně opačná situace může nastat u dodavatele – na technologickou stránku věci jsou „mistři, jako tygři na skákání“, jejich představy o významu jednotlivých „drobností“ pro zákazníka jsou však silně ovlivněny čistě technickým náhledem. Tento rozpor drsně ilustruje Scott Adams v dilbertovských stripech z konce letošního září, v nichž nebohá Alice umírá na nevyléčitelnou otravu uživatelským rozhraním, navrženým programátory.

Proto se dodavatel se zákazníkem snaží nalézt jazyk společný v dokumentu zvaném „analýza požadavků“. Tento dokument musí splňovat základní vlastnosti:

musí být dostatečně přesný a racionálně strukturovaný, aby se z něj technicky orientovaní pracovníci dodavatele nezbláznili
musí být dostatečně srozumitelný, aby zákazník věděl, jak vlastně dodavatel vnímá jeho potřeby
musí používat dostatečně jasné a přímočaré formulace, aby se minimalizovalo riziko nedorozumění

Pro správné pochopení zadání je dodržení všech tří podmínek klíčové. Samozřejmě se nabízí otázka: „co znamená ‚dostatečně‘?“. To prokáže budoucnost. Tak s chutí do práce.

Hmm… a neexistuje nějaký lepší způsob, jak nalézt společný jazyk, než je přepečlivá analýza?

Časté průběžné změny zadání

Zde je v tradiční metodice projektového řízení dodavatel ve výhodě, alespoň za předpokladu vytvoření analýzy natolik srozumitelné, kdy je zákazník schopen uznat, že opravdu žádá změnu a nikoli samozřejmou a předpokládanou vlastnost. Project manager suše oznámí, že se jedná o změnu, že zpracování tohoto požadavku zabere tolik a tolik účtovaného analytického času, pak se zákazník dozví, na kolik dalšího účtovaného času změna přijde, a mezitím vesele a nelítostně cválá harmonogram.

Což je pro nás jako dodavatele v zásadě fajn, ale ruku na srdce, není vám v tuto chvíli nebohého zákazníka trochu líto?

Zbytečně komplikovaný produkt

Obecnost, obecnost, obecnost. Proč psát jednoúčelový kód, když problém lze krásně převést do abstraktní roviny a vytvořit sofistikovanou univerzální a znovupoužitelnou komponentu? Stejně víme, že zákazník si navymýšlí spoustu novinek, co když tímto geniálním zobecněním vyřeším X potenciálních požadavků? A vůbec, co by tomu řekl můj učitel programování, který nad přímočarými řešeními ohrnoval nos a vedl nás k většímu nadhledu a obecnějším řešením?

Na pohled logické otázky, ale ruku na srdce, ta obecnější komponenta nás (potažmo klienta) bude stát čas, při zobecňování mnohdy stejně začneme řešením jednoúčelovým, a kdo ví, jestli se zadání nepozmění natolik, že celá naše veleobecnost přijde vniveč?

Hle, dilema.

Fluktuace pracovníků

Není možné navážet se do tradičního vývoje. Lidé přicházejí a odcházejí, někoho přejede tramvaj, někdo se rozhodne konečně dodělat školu a někdo prostě začne být projektem neodvolatelně „unaven“. Takový je život – a tomuto problému žádnou zázračnou metodikou nepředejdeme. Čemu však předejít můžeme, jsou negativní vlivy této fluktuace – a jistě se shodneme na tom, že o ty nám jde především.

Typicky zde klademe důraz na důkladnou dokumentaci zdrojového kódu a dodržování společné štábní kultury, zejména testování vlastních kusů kódu a jednotný coding style. Napadat tyto zdravé zásady by bylo bláznovstvím, ale i zde se nabízí šťouravá otázka – když už ne obligátní „a nešlo by to nějak jinak a lépe“, tak alespoň „nešlo by zde dělat něco víc?“.

Ty z vás, kteří mým šťouravým řečnickým otázkám dosud nadšeně přitakávali, musím nyní trochu zklamat. Článek je dlouhý až až, je tedy čas udělat si pauzu, využít diskusi pod článkem k tomu, nakolik se shodujeme s hodnocením rizik a názorech na jejich možnou prevenci. Rozuzlení nastane v druhém dílu, který již bude notně konstruktivnější a v němž se dozvíme, co je to avizované extrémní programování vlastně zač. Zatím se budu těšit na vaše názory.