O wyma­ga­niach napi­sa­no wie­le, ich kolek­cjo­no­wa­niu jesz­cze wię­cej, doku­men­tów wyma­gań pew­nie są gru­be tysią­ce w set­kach języ­ków. Czy coś moż­na do tego jesz­cze dodać? Tak, kolej­ny przy­kład jak to robić. Po co? Bo pro­jek­tów z zakre­su opro­gra­mo­wa­nia, nie­miesz­czą­cych się w budże­cie i ter­mi­nach, pro­jek­tów cza­sa­mi wręcz szko­dli­wych, jest tak dużo (podob­no ponad 80% to wła­snie takie), że war­to szu­kać przy­czyn… ale nie będę tu wyłusz­czał jakiejś nud­nej meto­dy­ki czy nor­my. Pokażę pewien przy­kład, któ­ry moim zda­niem jest antyw­zor­cem ana­li­zy i spe­cy­fi­ko­wa­nia wymagań.

W wielu dyskusjach o wymaganiach, pojawia się stwierdzenie: klient tak chciał.

Opracowanie spe­cy­fi­ka­cji czę­sto wygląda(ło) tak: klient opi­sał co by chciał (z regu­ły nie­ste­ty spon­sor pro­jek­tu odsy­ła ana­li­ty­ka do sze­re­go­wych pra­cow­ni­kow i ich kie­row­ni­ków). Analityk spi­su­je to co usły­szał. Niektórzy prze­ra­bia­ją takie user sto­ry na struk­tu­ral­ny tekst, bywa że zgod­ny z jaki­miś nor­ma­mi narzu­ca­ją­cy­mi spis tre­ści (i jakieś oczy­wi­sto­ści, np. że powi­nien być spój­ny i kom­plet­ny co by to nie mia­ło znaczyć).

Kolejny etap to poin­for­mo­wa­nie klien­ta o tym, że pew­ne jego wyma­ga­nia są trud­ne lub kosz­tow­ne do reali­za­cji, docho­dzi do jakichś nego­cja­cji i powsta­je doku­ment final­ny w posta­ci spe­cy­fi­ka­cji wyma­gań. Następnie bie­rze to do ręki pro­gra­mi­sta, sta­ra się zro­zu­mieć co i do cze­go będzie słu­ży­ło. Jeśli jego ana­li­tyk, użył np. tak zwa­nych przy­pad­ków uży­cia, będzie trosz­kę łatwiej. Wielu z nas to zna. W czym problem?

Podam przy­kład świe­ży. W pew­nym piśmie z bran­ży IT uka­zał się taki oto opis. Jest to opis pro­duk­tu, któ­ry powstał, jest obec­nie kupo­wa­ny w odpo­wie­dzi na wyma­ga­nia, któ­re ktoś kie­dyś posta­wił i nadal sta­wia bo pro­dukt jest naby­wa­ny (z tego co mi wiadomo).

Wiele klu­czo­wych infor­ma­cji przed­się­bior­stwa znaj­du­je się wyłącz­nie w wia­do­mo­ściach elek­tro­nicz­nych. Zwykle jeste­śmy świa­do­mi jak waż­ne dla biz­ne­su jest nie­za­wod­ne funk­cjo­no­wa­nie pocz­ty elek­tro­nicz­nej i trud­no zna­leźć jest fir­mę, w któ­rej nie były­by wyko­ny­wa­ne kopie zapa­so­we ser­we­ra pocz­to­we­go. Nie wszy­scy jed­nak zda­ją sobie spra­wę, że oprócz bac­ku­pów, bar­dzo istot­na jest archi­wi­za­cja poczty.

Jej pod­sta­wo­wym celem jest zapew­nie­nie moż­li­wo­ści łatwe­go wyszu­ki­wa­nia wia­do­mo­ści, nie­za­leż­nie od tego, czy pocho­dzą sprzed kil­ku tygo­dni, czy lat, a mogą być potrzeb­ne np. jako dowód w spra­wie sądo­wej (war­to zapa­mię­tać ter­min ediscovery). […]

Najprostszą for­mą archi­wi­za­cji może być kopio­wa­nie przy­cho­dzą­cej i wycho­dzą­cej pocz­ty z ser­we­ra, nie­co bar­dziej zaawan­so­wa­na pozwo­li na usta­le­nie kry­te­riów i zacho­wy­wa­nie tyl­ko tych wia­do­mo­ści, któ­re je speł­nia­ją. Lepsze roz­wią­za­nia umoż­li­wią prze­no­sze­nie zgod­nie z poli­ty­ką archi­wi­za­cji listów elek­tro­nicz­nych wraz z załącz­ni­ka­mi, pozo­sta­wia­jąc w skrzyn­kach użyt­kow­ni­ków skró­ty (ang. stub) zawie­ra­ją­ce pod­sta­wo­we dane (np. nadaw­ca, adre­sat, temat, roz­miar). Ich otwar­cie spo­wo­du­je przy­wró­ce­nie z archi­wum i zapre­zen­to­wa­nie ory­gi­nal­nej wia­do­mo­ści, a z punk­tu widze­nia użyt­kow­ni­ka nie będzie wie­le się róż­nić od zwy­kłe­go otwie­ra­nia wia­do­mo­ści. Systemy archi­wi­zu­ją­ce pocz­tę wypo­sa­ża­ne są w por­tal, za pomo­cą któ­re­go użyt­kow­ni­cy mogą samo­dziel­nie wyszu­ki­wać i wydo­by­wać zacho­wa­ne wia­do­mo­ści ze swo­ich skrzy­nek oraz (jeśli otrzy­ma­ją takie upraw­nie­nia) innych użyt­kow­ni­ków. (żr. Archiwizacja pocz­ty – luk­sus czy koniecz­ność? – idg​.pl Wiadomości).

Nie trze­ba być geniu­szem by się domy­ślić, że ktoś ocze­ku­je wła­śnie tego co powy­żej bo ma pro­ble­my z tymi doku­men­ta­mi. Powyższy tekst mógł by być takim user sto­ry posia­da­cza pro­gra­mu pocz­to­we­go (w licz­bie pra­cow­ni­ków dzie­sią­tek i setek w fir­mie), któ­re­mu coś kie­dyś zgi­nę­ło lub nie mógł zna­leźć. Artykuł w dal­szej czę­ści zawie­ra opis pro­duk­tu pew­ne­go domi­nu­ją­ce­go na ryn­ku IT dostaw­cy roz­wią­zań, któ­ry jest odpo­wie­dzią na ten pro­blem. (No i mamy w IDG kla­sycz­ny [[pro­duct pla­ce­ment]] a nie­za­leż­nym piśmie bran­żo­wym – zain­te­re­so­wa­nych o jaki pro­dukt cho­dzi odsy­łam do lek­tu­ry źró­dła cytatu).

Tak więc jak zapy­ta­my pra­cow­ni­ka co by chciał, to się dowie­my że … i tu opis jak powy­żej: Klient Nasz Pan. Czego ja się cze­piam? Zauważyłem już jakiś czas temu, że ilość skła­do­wa­nych śmie­ci pra­wie zawsze dokład­nie odpo­wia­da obję­to­ści posia­da­ne­go śmiet­ni­ka. Co mam na mysli?

Inny ana­li­tyk 😉 spoj­rzał by na takie wyma­ga­nia (o ile dał by się namó­wić na ich spi­sy­wa­nie w takiej posta­ci) i zapy­tał by mana­ge­ra: w czym pro­blem? Zapewne usły­szał by, że pra­cow­ni­kom giną cza­sa­mi bar­dzo waż­ne infor­ma­cje, któ­re mie­li w poczcie.

Ten Inny ana­li­tyk pochy­lił by się na tym i zapy­tał by, czym są te waż­ne infor­ma­cje. Najczęściej są to jakieś usta­le­nia, ofer­ty, tre­ści umów itp. Jeden sce­na­riusz roz­wią­za­nia tego pro­ble­mu już zna­my (powy­żej). A jaki drugi?

Należy ogra­ni­czyć pojem­ność skrzy­nek pocz­to­wych do ok. 100Mb (tak 100Mb! w tym kosz i spam). W efek­cie pra­cow­ni­cy zosta­ną zmu­sze­ni do selek­cji tego co otrzy­mu­ją i jest im potrzeb­ne. 100MB to i tak dużo jak na bie­żą­cą komu­ni­ka­cję. Przy tak małej ilo­ści miej­sca każ­dy, nawet śred­nio roz­sąd­ny pra­cow­nik, zacznie kopio­wać na swo­im (lub sie­cio­wym dys­ku, kwe­stia archi­tek­tu­ry sie­ci w danej fir­mie) wszyst­ko co ma jaką­kol­wiek war­tość, a prak­ty­ka poka­zu­je, że sta­no­wi to może 10% tre­ści kore­spon­den­cji. Uzgadnianie tre­ści doku­men­tów czę­sto wyma­ga kil­ku, kil­ku­na­stu listów. Biorąc pod uwa­gę, że w zasa­dzie każ­dy uży­wa opcji cyto­wa­nia, rośnie tasie­miec powie­la­nych cyto­wań w kolej­nych listach. Czy ma sens prze­cho­wa­nie tego wszyst­kie­go? Raczej nie.

Tak więc, sko­ro w fir­mie i tak robi­my kopie zapa­so­we dys­ków sie­cio­wych i zaso­bów pra­cow­ni­ków a dys­ki są coraz tań­sze po co two­rzyć dru­gi i bar­dzo kosz­tow­ny ser­wer pli­ków z sys­te­mu pocz­to­we­go? Po co uży­wać ser­we­ra pocz­to­we­go do zarzą­dza­nia doku­men­ta­mi sko­ro i tak jest to tyl­ko cześć waż­nych rze­czy a pozo­sta­łe i tak są na dys­kach sie­cio­wych jako pli­ki i nie unik­nie­my sys­te­mu zabez­pie­cze­nia tych zaso­bów tak­że? Skoro współ­dzie­le­nie pli­ków na dys­kach sie­cio­wych jest pro­ste i w zasa­dzie bez kosz­to­we to po co dopła­cać do ser­we­ra pocz­to­we­go za opcje por­ta­lo­we­go dostę­pu do swo­ich i cudzych maili, za moż­li­wość zarzą­dza­nia pra­wa­mi do cudzych maili by kole­ga, kole­żan­ka lub szef mogli skom­ple­to­wać histo­rię kore­spon­den­cji z klien­tem? Dlaczego trzy­mać waż­ne pli­ki w ser­we­rze pocz­to­wym sko­ro odzy­ski­wa­nie ich stam­tąd jest znacz­nie trud­niej­sze niż z kata­lo­gów na dys­kach? Takich pytań moż­na zadać jesz­cze wie­le. Czy życze­nie pra­cow­ni­ka (któ­ry ma pra­wo nie wie­dzieć, że są inne meto­dy lub ukry­je je bo wyma­ga­ły by zmian) jest wystar­cza­ją­cym powodem?

Tak więc Inna ana­li­za wyma­gań, wyko­na­na przez Innego ana­li­ty­ka wyglą­da­ła by tak:

1. ziden­ty­fi­ko­wa­no by i opi­sa­no pro­blem biz­ne­so­wy (orga­ni­za­cyj­ny, zarząd­czy itp.)
2. zbu­do­wa­no by jakiś model orga­ni­za­cji pozwa­la­ją­cy na odtwo­rze­nie pro­ble­mu i zro­zu­mie­nie miej­sca i przy­czyn jego powsta­wa­nia, zba­da­no by róż­ne warianty
3. ziden­ty­fi­ko­wa­no by i spre­cy­zo­wa­no przy­czy­ny ist­nie­nia problemu,
4. opi­sa­no by moż­li­we warian­ty roz­wią­za­nia pro­ble­mu w posta­ci dwóch lub wię­cej kon­cep­cji rozwiązania
5. oce­nio­no by poten­cjal­ne szko­dy obec­ne­go sta­nu i osza­co­wa­no próg ren­tow­no­ści zaku­pu cze­goś nowego

Na tym eta­pie dosta­je­my opis pro­ble­mu, ziden­ty­fi­ko­wa­ną jego przy­czy­nę i wska­za­nia z ryzy­ka­mi, jak pro­blem roz­wią­zać. Możliwe, że roz­wią­za­nie orga­ni­za­cyj­ne by spra­wę roz­wią­za­ło (dra­stycz­ne ogra­ni­cze­nie pojem­no­ści skrzy­nek zamiast ich powięk­sza­nie). Może innym roz­wią­za­niem był­by jakiś [[sys­tem zarzą­dza­nia tre­ścią]] (może [[sys­tem zarzą­dza­nia doku­men­ta­mi]])? Z taki­mi infor­ma­cja­mi mana­ger może popro­sić kil­ku dostaw­ców roz­wią­zań o ofer­ty na pro­dukt i/lub usłu­gę roz­wią­za­nia problemu.

Nasz Inny ana­li­tyk, jeże­li ma wie­dzę i doświad­cze­nie w roli pro­jek­tan­ta, może przy­go­to­wać jako kon­ty­nu­acje takie­go pro­jek­tu od razu kon­cep­cję roz­wią­za­nia. Ma to te duża zale­tę, że uni­ka­my ryzy­ka, że dostaw­ca opra­cu­je taką kon­cep­cje pod sie­bie. Koncepcja roz­wią­za­nia to nie wska­za­nie pro­duk­tu a okre­śle­nie co powi­nien robić i jakie są tu ogra­ni­cze­nia. Nadal bez decy­do­wa­nia o szcze­gó­łach (pisze­my co a nie jak ma zostać zre­ali­zo­wa­ne, jed­nak nie zapo­mi­na­my o ogra­ni­cze­niach któ­re nale­ży tak­że w takich wyma­ga­niach umie­ścić – zwa­ne czę­sto wyma­ga­nia­mi poza­func­kjo­nal­ny­mi) orga­ni­zu­je­my kon­kurs ofert (prze­targ) i świa­do­mie wybie­ra­my opty­mal­ne rozwiązanie.

Nasz lokal­ny inży­nier, może na to po pierw­sze nie mieć cza­su, po dru­gie to nie są kom­pe­ten­cje inży­nier­skie! Jaka tech­no­lo­gia zosta­nie wybra­na? Przy popraw­nie okre­ślo­nych wyma­ga­niach i ogra­ni­cze­niach: będzie kom­pa­ty­bil­na z naszy­mi zaso­ba­mi, będzie kosz­to­wo opty­mal­na, będzie speł­nia­ła swo­ją rolę bo w koń­cu mamy tak­że ogra­ni­cze­nia (tu nasz inży­nier się nie­wąt­pli­wie popi­sze i słusznie).

Jeżeli więc Wiele klu­czo­wych infor­ma­cji przed­się­bior­stwa znaj­du­je się wyłącz­nie w wia­do­mo­ściach elek­tro­nicz­nych to ja życzę powo­dze­nia tej fir­mie – suge­ru­je szyb­ko to zmie­nić. Po dru­gie klient dobre­go ana­li­ty­ka to nie jego Pan a Pacjent. Mamy dwa sce­na­riu­sze, mana­ger ma wybór. Czy ja mam rację? Nie wiem. Moją rolą eks­per­ta jest zba­dać pro­blem, opi­sać skut­ki i warian­ty roz­wią­za­nia. Decyduje mana­ger (klient analityka).