Jak to mawiał mój daw­ny pro­fe­sor filo­zo­fii: ​„gdy dwóch mówi to samo to już nie jest samo”. To co nazy­wa­my ​„zwin­nym podej­ściem” to coraz czę­ściej uzna­nie nie­sku­tecz­no­ści meto­dy pole­ga­ją­cej na ​„zbie­ra­niu wyma­gań” i obro­na przed ​„obie­ca­niem z góry tego co ma powstać”, bo nikt nie wie czym to coś będzie jak już powstanie…(o ile powsta­nie). Takie gło­sy poja­wia­ją się coraz czę­ściej, i to nie od wczoraj.…

Dzisiaj metody oparte na abstrakcji

Takie ​„pomy­sły” jak MDA (archi­tek­tu­ra bazu­ją­ca na mode­lo­wa­niu), MDE (inży­nie­ria bazu­ją­ca na mode­lo­wa­niu), nota­cje BPMN, UML, SysML, SoaML i podob­ne, sta­no­wią­ce sobą for­mę rysun­ku tech­nicz­ne­go na wyso­kim pozio­mie abs­trak­cji, to ścież­ka nie raz ratu­ją­ca pro­jek­ty infor­ma­tycz­ne. To meto­da pozwa­la­ją­ca radzić sobie z rosną­cą zło­żo­no­ścią inży­nie­rii jako cało­ści. Te narzę­dzia powsta­ją i są roz­wi­ja­ne od ponad 20 lat… Konstrukcji dzi­siej­sze­go tram­wa­ju czy zło­żo­ne­go opro­gra­mo­wa­nia, nie da sie już rze­tel­nie i pre­cy­zyj­nie opi­sać z pomo­cą ​„listy wyma­gań zebra­nych w trak­cie spo­tkań warsz­ta­to­wych” na roz­sąd­nej ilo­ści stron papie­ru. Ich podział na ​„funk­cjo­nal­ne i poza funk­cjo­nal­ne” nie wpro­wa­dza nicze­go nowe­go do takiej listy. Ta tech­ni­ka spe­cy­fi­ko­wa­nia (IEEExxx-1998^?1?) ma swo­je począt­ki ponad 30 lat temu!

W czym problem?

Niedawno uka­zał się kolej­ny cie­ka­wy arty­kuł na ten temat.

Requirements gathe­ring is one phra­se I have lear­ned not to use with sta­ke­hol­ders as I deli­ver pro­jects. It appe­ars to have struck fear, cyni­cism and/or anxie­ty in many of the user gro­ups I have to enga­ge at the most impor­tant sta­ge of the solu­tion ? the begin­ning. (Źródło: Business Analyst | Requirements Are Dead, Long Live the Solution²) 

Popularne sło­wo ​„eli­ci­ta­tion” to ​„uzy­ski­wa­nie, wydo­by­wa­nie”. Branża IT poszła w kie­run­ku uzna­nia, że zain­te­re­so­wa­ny (sta­ke­hol­der) ma rozu­mieć ​„wyma­ga­nia”. To jed­nak nie działa.

Elicitation And Other Animals The indu­stry then moved on with the ter­mi­no­lo­gy, to use the term ?eli­ci­ta­tion.? To add com­ple­xi­ty, the­re were sepa­ra­te defi­ni­tions of func­tio­nal requ­ire­ments, being dif­fe­rent to busi­ness requ­ire­ments, then get­ting tech­ni­cal and coming up with sys­tem requ­ire­ments. All of the types of requ­ire­ments have clo­uded the under­stan­ding by sta­ke­hol­ders, and then time is lost in the defi­ning the ter­mi­no­lo­gy befo­re any discus­sions have begun. A ple­tho­ra of whi­te papers and autho­red artic­le can descri­be the dif­fe­ren­ces and it?s abso­lu­te­ly cle­ar in some of tho­se eso­te­ric minds.. (Źródło: Business Analyst | Requirements Are Dead, Long Live the Solution²).

Nie wol­no zapo­mi­nać, że zama­wia­ją­cy nie jest inży­nie­rem. To co potra­fi powie­dzieć zama­wia­ją­cy i to co jest w sta­nie zro­zu­mieć to wyłącz­nie ​„wyma­ga­nia biz­ne­so­we” i nic ponad to. Poprzestanie w pro­jek­cie na takich ​„wyma­ga­niach” nie sta­no­wi żad­nych wyma­gań wobec inży­nier­skiej kon­struk­cji jaką ma wyko­nać deve­lo­per (czy­li inży­nier). Nie nale­ży tak­że zapo­mi­nać o tym, że każ­dy biz­ne­so­wy ​„udzia­ło­wiec” ma ​„swój inte­res” do reali­za­cji, wyma­ga­nia biz­ne­so­we to nic inne­go jak cele tych ludzi. I teraz klu­czo­we pyta­nie: kogo pytać o wyma­ga­nia np. dla opro­gra­mo­wa­nia wspo­ma­ga­ją­ce­go sprze­daż: pre­ze­sa tej fir­my czy jego sprze­daw­ców wal­czą­cych o pro­wi­zje mają­cych nadzie­ję, że ktoś zło­ży im pro­po­zy­cję lepiej płat­nej pra­cy? Sponsorem pro­jek­tów są zarzą­dy firm, ocze­ku­ją ter­mi­nów, nazw, opi­sów a nie nadziei…

Today?s pro­ject needs are for solu­tions measu­red in time-to-mar­ket, risk reduc­tion, take-up rates, or bet­ter still, what you defi­ned as measu­ra­ble at the begin­ning. (Źródło: Business Analyst | Requirements Are Dead, Long Live the Solution²) 

Powiązany arty­kuł zawie­ra inne cie­ka­we pytanie: 

Czego ocze­ku­je biz­nes: efek­tu czy produktu?

What Is The Difference Between Outcome And Output? Before I go much fur­ther, I sho­uld pro­ba­bly expla­in what I mean when I use the words out­co­me and out­put in a con­text rele­vant to busi­ness ana­ly­sts:
- Outcome is the chan­ge in the orga­ni­za­tion and chan­ges in the beha­vior of sta­ke­hol­ders as a result of a pro­ject.
- Output is any­thing that your team deli­vers as part of your pro­ject. This could inc­lu­de requ­ire­ments, docu­men­ta­tion, pro­ces­ses, softwa­re, tests and other things that tend to be measu­red in order to gau­ge how the pro­ject is going.
(Źródło: Business Analyst | Your Job Is Not to Elicit and Document Requirements³) 

i tu poja­wia się teza dla analityków:

Requirements Are (Not The Final) Output (wyma­ga­nia nie są osta­tecz­nym pro­duk­tem analityka)

To co nim jest? Popatrzmy na pro­ces tak zwa­nej ana­li­zy systemowej:

Gdzie jest faza ​„zbie­ra­nia wyma­gań” w rozu­mie­niu ​„eli­ci­ta­tion”? W zasa­dzie jest to dopie­ro począ­tek dro­gi czy­li sfor­mu­ło­wa­nie pro­ble­mu. Następnie ktoś powi­nien zba­dać śro­do­wi­sko pro­ble­mo­we czy­li prze­pro­wa­dzić bada­nie (ana­li­za biz­ne­so­wa orga­ni­za­cji) i opra­co­wać model (mapy pro­ce­sów biz­ne­so­wych, struk­tu­ry infor­ma­cyj­ne). Kolejny krok to inter­pre­ta­cja wyni­ków bada­nia. Co jest tą reko­men­da­cją? Jest nią reko­men­do­wa­ne roz­wią­za­nie pro­ble­mu, tym roz­wią­za­niem może być opro­gra­mo­wa­nie, zmia­ny orga­ni­za­cyj­ne a naj­czę­ściej jed­no i drugie.

Jednak nie jest roz­wią­za­niem stwier­dze­nie: ​„powin­ni­ście sobie kupić jakieś opro­gra­mo­wa­nie i popra­wić orga­ni­za­cję”. Rozwiązaniem (reko­men­da­cją) jest raczej: ​„to jest struk­tu­ra i logi­ka dzia­ła­nia opro­gra­mo­wa­nia, któ­re reko­men­du­ję a to są reko­men­do­wa­ne zmia­ny organizacyjne”. 

I to dopie­ro jest naj­wcze­śniej­szy moment na ​„wpusz­cze­nie” developera.

Nikogo w biz­ne­sie nie inte­re­su­je tak na praw­dę suchy spis pro­ble­mów (wyma­ga­nia zebra­ne na warsz­ta­tach wśród pra­cow­ni­ków), biz­nes jest zain­te­re­so­wa­ny czymś co moż­na nazwać, kupić i wdro­żyć w okre­ślo­nym cza­sie bo tyl­ko to pozwa­la na osza­co­wa­nie korzy­ści z takiej inwestycji.

Rynek zmie­nia się szyb­ko, więc nie ma sen­su szcze­gó­ło­we pro­jek­to­wa­nie cze­go­kol­wiek z uwa­gi na czas jaki zaj­mie takie pro­jek­to­wa­nie i ryzy­ko, że taki pro­jekt sta­nie się szyb­ko nie­ak­tu­al­ny. Nikt roz­sąd­ny nie nama­wia dzi­siaj do cze­goś o wdzięcz­nej nazwie ​„water­fall”. Co więc zro­bić? Dla dużych pro­jek­tów two­rzy­my archi­tek­tu­rę, opi­su­je­my mecha­ni­zmy dzia­ła­nia, poli­ty­kę roz­bu­do­wy i opis cyklu życia. Czyli to co pozwo­li roz­wi­jać roz­wią­za­nie meto­dą ite­ra­cyj­no-przy­ro­sto­wą, w razie potrze­by pozwo­li na prze­pro­jek­to­wa­nie, ale jako całość nadal będzie spój­ne, nie będzie wyma­ga­ło wymia­ny cało­ści gdy zmie­nią się warun­ki na rynku.

Można w tym miej­scu zary­zy­ko­wać tezę, że nie ma cze­goś takie­go jak ​„inży­nie­ria wyma­gań” bo czym ona jest i co jest jej pro­duk­tem? Uporządkowany spis życzeń? Mamy nato­miast na pew­no ​„inży­nie­rię sys­te­mów”.… sys­te­ma­mi są orga­ni­za­cje a tak­że narzę­dzia jakich uży­wa­ją np. oprogramowanie…