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:

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:

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.