Wymagania umarły. Rozwiązaniem jest cykl życia produktu

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 Solution2

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 Solution2).

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 Solution2

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 Requirements3

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

________________________________
  1. 1.
    Żeliński J. IEEE1998 Czy pro­du­ku­je dobre wyma­ga­nia. IT​-Consulting​.pl. https://it-consulting.pl//2008/09/27/ieee830-1998-%e2%80%93-czy-produkuje-dobre-wymagania/. Published March 9, 2017. Accessed December 24, 2018.
  2. 2.
  3. 3.

Inne artykuły na podobny temat

Komentarze

  1. Michał Stachura 13 stycznia 2017 at 14:41

    Chcesz powie­dzieć, że bli­żej Ci do mode­lu reali­za­cji pro­jek­tów opi­sa­nych mniej szcze­gó­ło­wo ale z moż­li­wo­ścią reali­za­cji przy­ro­sto­wej niż kla­sycz­nych metod pro­jek­to­wa­nia roz­po­czę­tych stu­dium wyko­nal­no­ści pro­jek­tu z apte­kar­ską dokładnością?

    • Jaroslaw Zelinski 13 stycznia 2017 at 15:15

      Ja nigdy nie byłem apte­ka­rzem, w inży­nie­rii jestem zwo­len­ni­kiem podzia­łu prac na ana­li­zę i pro­jek­to­wa­nie i realizację/implementację. Jeżeli umó­wi­my się, że nie mówi­my o małych pro­jek­ci­kach” to w dużych pro­jek­tach jesteś ska­za­ny na etap pro­jek­to­wa­nia szkie­le­tu (archi­tek­tu­ra) i poli­ty­ki jego roz­bu­do­wy oraz etap reali­za­cji, rzu­ca­nie sie na deta­le imple­men­ta­cyj­ne na eta­pie pro­jek­to­wa­nia to w obec­nym tem­pie zmian na ryn­ku strzał w sto­pę.… Od ogó­łu do szcze­gó­łu.… to mantra 😀 

      Studium wyko­nal­no­ści pro­jek­tu to w zasa­dzie pierw­sze wnio­ski z ana­li­zy biz­ne­so­wej: jak już będzie wia­do­mo jakie roz­wią­za­nie (w tym alter­na­tyw­ne) jest reko­men­do­wa­ne, ma sens oce­na ren­tow­no­ści i tech­no­lo­gicz­nej wykonalności.

      Moje naj­więk­sze doku­men­ty (nafa­sze­ro­wa­nie sche­ma­ta­mi blo­ko­wy­mi) mają ok 200 stron… stan­dar­do­wo poni­żej 100…

  2. Adam Arczewski 17 stycznia 2017 at 13:45

    Witam Panie Jarku
    Chętnie zapo­znam się z Pana publi­ka­cją Analiza Biznesowa.

  3. Marek Bisztyga 17 stycznia 2017 at 15:54

    Cześć.
    1. Opinie, iż czas pozy­ski­wa­nia wyma­gań minął są lek­ko prze­sa­dzo­ne. Może to nie idea trą­ci naf­ta­li­ną, a meto­dy. Zgoda, co do tezy, że lista wyma­gań” do reali­za­cji jest już pas­se. Analiza biz­ne­so­wo-sys­te­mo­wa sta­ła się inte­gral­ną czę­ścią zja­wi­ska o znacz­nie szer­szym zasię­gu – zarzą­dza­nia zmia­ną, ze wszyst­ki­mi tego kon­se­kwen­cja­mi, rów­nież w obsza­rze meto­do­lo­gii, tech­nik i narzędzi.
    2. Nawet jeśli zgo­dzi­my się, że naj­wa­zniej­sze dla biz­ne­su jest roz­wią­za­nie, to zawsze trze­ba wie­dzieć, jakie­go pro­ble­mu jest to roz­wią­za­nie. Często bowiem mamy już goto­we lekar­stwo (pod poję­ciem lekar­stwa rozu­miem to, co aktu­al­nie umie zespół IT, a szu­ka­my na gwałt cho­ro­by, któ­ra do nie­go pasu­je. Problem tkwi w sposobie/umiejętności iden­ty­fi­ka­cji pro­ble­mów oraz uczci­wo­ści w ich stawianiu.
    Pozdrawiam,
    Marek

    • Jaroslaw Zelinski 18 stycznia 2017 at 08:25

      Dla porząd­ku zwró­cę uwa­gę, że mowa o zło­żo­nych roz­wią­za­niach, bo pro­ble­mem jest rosną­ca zło­żo­ność pro­duk­tów (i np. tele­wi­zo­rów i oprogramowania).
      1. Artykuł źró­dło­wy i mój, wska­zu­je na for­mę. Wymaganiem nie będą set­ki” cech zewnętrz­nych, a to do cze­go pro­dukt ma być uży­ty i jak ma być skon­stru­owa­ny, kon­struk­cja – archi­tek­tu­ra – powin­na uwzględ­niać podat­ność na zmia­ny w cyklu życia produktu.
      2. To praw­da i to kwe­stia tego, że bez mode­lu orga­ni­za­cji sta­no­wią­ce­go kon­tekst pro­jek­tu, sta­wia­nie komu­kol­wiek i cze­mu­kol­wiek wyma­gań w zasa­dzie nie ma więk­sze­go sensu.

  4. Marek Bisztyga 18 stycznia 2017 at 09:57

    Obawiam się, że tym razem nie roz­wi­nie­my się, tyl­ko wymie­ni­my poglą­dy (w myśl mak­sy­my umiesz­czo­nej poni­żej tego okienka).
    Architektura – to jest wła­śnie to, co zastę­pu­je set­ki” cech zewnetrz­nych pęł­nią­cych role wyma­gań, a dokład­niej, zmia­ny archi­tek­tu­ry biz­ne­so­wej, kon­se­kwen­cją któ­rych są / powin­ny być zmia­ny archi­tek­tu­ry sys­te­mu IT, rozu­mia­ne­go bądź jako pro­dukt” , bądź jako infra­struk­tu­ra”. Wymaganiami stric­te są decy­zje pro­jek­to­we wyni­ka­ją­ce ze związ­ków przy­czy­no­wo-skut­ko­wych pomię­dzy zda­rze­nia­mi w biz­ne­sie a cecha­mi i spo­so­ba­mi uży­wa­nia sys­te­mów, któ­re to związ­ki są chy­ba naj­waż­niej­szym i naj­cen­niej­szym efek­tem budo­wy i ana­li­zy architektury.

    • Jaroslaw Zelinski 18 stycznia 2017 at 12:27

      Ano, klien­tom powta­rzam, że przy­cho­dzi taki moment gdy nale­ży zre­zy­gno­wać z zama­wia scho­dów na pię­tro opi­su­jąc je w deta­lach, nale­ży zamó­wić scho­dy pisząc, że słu­żą nam na co dzień w dro­dze do sypial­ni i toa­le­ty, a cza­sa­mi do tego by wnieść nowe łóż­ko o wymia­rach nie mniej­szych niż… ten dru­gi spo­sób jest znacz­nie mniej ryzy­kow­ny biz­ne­so­wo”…

  5. Jaroslaw Zelinski 1 grudnia 2017 at 09:15

Dodaj komentarz

Twój adres email nie zostanie opublikowany

Komentuj i zadawaj pytania autorowi.

Identyfikator *
E-mail *
Witryna internetowa

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.