Tag: JAD

Praca grupowa czyli Syndrom Sztokholmski w projekcie

1 komentarz

Od wie­lu lat lat, pro­duk­tem mojej pra­cy są doku­men­ty opi­su­ją­ce w obiek­tyw­ny spo­sób dzia­ła­nie orga­ni­za­cji, zawie­ra­ją­ce reko­men­da­cje zmian do popra­wy sytu­acji, tak­że wyma­ga­nia na sys­te­my infor­ma­cyj­ne. Po opra­co­wa­niu roz­wią­za­nia i pomo­cy w wybo­rze jego dostaw­cy, pro­wa­dzę nad­zór autor­ski nad reali­za­cją opra­co­wa­ne­go roz­wią­za­nia. [1] Po latach pra­cy nasu­wa mi się dość cie­ka­wy wnio­sek z obser­wa­cji: Zamawiający dzia­ła­ją na swo­ją szkodę!

Typowy pro­jekt zwią­za­ny z wdra­ża­niem nowych roz­wią­zań to real­ne potrze­by Zamawiającego. Członkowie zespo­łu Zamawiającego mają nad sobą ter­mi­ny i ​„nie­uchron­ność” kary za nie­po­wo­dze­nie. W efek­cie Dostawca szyb­ko sta­je się ​„Panem pro­jek­tu”, bo to on dostar­cza roz­wią­za­nie, zna się, a bywa że szan­ta­żu­je. Przewaga mery­to­rycz­na Dostawcy nad Zamawiającym jest tak wiel­ka, że ten ostat­ni w zasa­dzie nie jest w sta­nie pano­wać nad pro­jek­tem. Powoli rynek to dostrze­ga i dla­te­go od kil­ku lat nie­mal­że każ­da moja umo­wa na pro­jek­to­wa­nie zawie­ra tak­że nad­zór autor­ski (to for­ma kon­tro­li efek­tów pra­cy dostawcy).

Nadal bar­dzo czę­sto Dostawca two­rzy jed­nak pew­ną atmos­fe­rę: ​„to my reali­zu­je­my Wasz pro­jekt i wszyst­ko – Wy tak­że – od nas zale­ży, nad­zór autor­ski psu­je Wam har­mo­no­gram bo my musi­my te doku­men­ty czy­tać i two­rzyć”. Dwa razy w ostat­nich pię­ciu lat zda­rzy­ło mi się, że fak­tycz­nie Zamawiający zre­zy­gno­wał z nad­zo­ru autor­skie­go, bo człon­ko­wie zespo­łu zaczę­li ​„trzy­mać stro­nę Dostawcy”, mimo infor­ma­cji o szko­dli­wo­ści zmian wpro­wa­dza­nych przez z Dostawcę. Oba pro­jek­ty skoń­czy­ły się nie­ste­ty klę­ską (mam kon­takt z prak­tycz­nie każ­dym byłym klientem).

Projekt wdro­że­nio­wy bez nad­zo­ru mery­to­rycz­ne­go, to bar­dzo czę­sto rów­nia pochy­ła: od pod­pi­sa­nia umo­wy na wdro­że­nie z dostaw­cą jest już tyl­ko coraz gorzej, bo Dostawca uprasz­cza logi­kę sys­te­mu, pomi­ja trud­ne do reali­za­cji wyma­ga­nia, sta­le orga­ni­zu­je spo­tka­nia, na któ­rych legi­ty­mi­zu­je te zmia­ny w pro­sty spo­sób spo­sób: ​„to co macie w doku­men­ta­cji wyma­gań jest złe (nie da się, nikt tak nie robi itp.), nasz sys­tem reali­zu­je to ina­czej, zrób­my to pro­ściej i szyb­ciej a też będzie dobrze”. Zamawiający z regu­ły nie ma po swo­jej stro­nie żad­nych kom­pe­ten­cji by oce­nić skut­ki takich ​„pro­po­zy­cji” i na spo­tka­niach godzi się na to, pod­pi­su­jąc kolej­ne notat­ki pro­jek­to­we z takich ​„warsz­ta­tów”, mały­mi krocz­ka­mi funk­cjo­nal­ność dostar­cza­ne­go pro­duk­tu odda­la się od fak­tycz­nych potrzeb i wyma­gań. Projekt koń­czy się tak, że Zamawiający ​„dostał dokład­nie to co chciał a nie to co jest mu potrzeb­ne”. Statystyki pro­jek­tów IT są bez­li­to­sne: ok. 2/3 pro­jek­tów to nadal pro­jek­ty nie­uda­ne. [2]

Tam gdzie mój pro­jekt był kolej­nym podej­ściem, po poprzed­nim nie­uda­nym, wyżej opi­sa­na sytu­acja była prak­tycz­nie zawsze przy­czy­ną wcze­śniej­szej poraż­ki. Paradoksalnie jest to – poraż­ka – wręcz stan­dar­do­wa sytu­acja, gdy Zamawiający naj­pierw wybie­ra Dostawcę a potem zle­ca mu ana­li­zę wyma­gań i kie­ro­wa­nie projektem.

Zjawisko to zawsze koja­rzy mi się ze zna­nym w psy­cho­lo­gii efek­tem nazy­wa­nym Syndrom Sztokholmski. Jest to sytu­acja, w któ­rej ofia­ra, wbrew zdro­we­mu roz­sąd­ko­wi, zaczy­na sym­pa­ty­zo­wać ze swo­im oprawcą.

[Syndrom Sztokholmski] …ofia­ra porwa­nia czy zakład­nik tra­ci kry­ty­cyzm wobec swo­jej sytu­acji, zaczy­na wie­rzyć, ze jej opraw­ca dzia­ła w słusz­nym celu, i darzyć go sym­pa­tią. Jak twier­dzi ame­ry­kań­ska psy­cho­log, dr Natalie de Fabrique, zaj­mu­ją­ca się bada­niem tego syn­dro­mu, syn­drom sztok­holm­ski poja­wia się u ofiar nie­świa­do­mie, to instynk­tow­ny, psy­cho­lo­gicz­ny mecha­nizm obron­ny, dzię­ki któ­re­mu łatwiej jest im odna­leźć sens tego, co się dzie­je, i unik­nąć zała­ma­nia ner­wo­we­go. [3]

W wie­lu pro­jek­tach wdro­że­nio­wych mamy podob­ną sytu­ację: pra­cow­ni­cy zama­wia­ją­ce­go, zamiast dzia­łać na rzecz sie­bie czy swo­je­go pra­co­daw­cy, zaczy­na­ją trzy­mać stro­nę Dostawcy, któ­ry żali się, że ma pro­blem z ter­mi­na­mi i prze­rzu­ca winę za to na swo­je­go klien­ta. Po pew­nym cza­sie docho­dzi do tego, że zespół Zamawiającego tak się ​„zżył z pra­cow­ni­ka­mi Dostawcy”, że zaczy­na ich bro­nić przed wła­sny­mi prze­ło­żo­ny­mi. Są Dostawcy, któ­rzy celo­wo stwa­rza­ją takie sytu­acje (np. orga­ni­zu­jąc wyjaz­do­we szko­le­nia i warsz­ta­ty z noc­le­ga­mi), ale nie raz dzie­je się ​„samo­ist­nie”. Popatrzmy na poniż­szą listę, czy nie przy­po­mi­na Wam to czegoś?

Objawy i symp­to­my syn­dro­mu sztok­holm­skie­go to:
– pozy­tyw­ne uczu­cia ofia­ry wobec sprawcy;
– zro­zu­mie­nie przez ofia­rę moty­wów i zacho­wań spraw­cy i podzie­la­nie jego poglądów;
– pozy­tyw­ne uczu­cia spraw­cy wzglę­dem ofiary;
– pomoc­ne zacho­wa­nia ofia­ry wobec sprawcy;
– nega­tyw­ne uczu­cia ofia­ry wobec rodzi­ny, przy­ja­ciół, auto­ry­te­tów pró­bu­ją­cych ją ratować;
– nie­zdol­ność zaan­ga­żo­wa­nia się w zacho­wa­nia, któ­re mogły­by dopro­wa­dzić do jej uwol­nie­nia od sprawcy.
Syndrom sztok­holm­ski nie doty­czy wszyst­kich osób dotknię­tych tra­gicz­ny­mi zda­rze­nia­mi. By zaist­niał, muszą wystą­pić okre­ślo­ne warun­ki. Ofiara:
– spo­strze­ga, że jej prze­ży­cie zale­ży od dobrej woli sprawcy;
– nie widzi moż­li­wo­ści ucieczki;
– dostrze­ga drob­ne uprzej­mo­ści ze stro­ny sprawcy;
– jest izo­lo­wa­na od per­spek­tyw odmien­nych od per­spek­ty­wy sprawcy.
[4]

Popatrzmy zatem na pro­jekt wdro­że­nio­wy, w którym:

  1. Zespól Zamawiającego wie­rzy, że ​„być albo nie być” fir­my, zale­ży od powo­dze­nia projektu,
  2. Zespół Zamawiającego nie widzi alter­na­ty­wy dla tego wdrożenia,
  3. Zespół Zamawiającego widzi, że Dostawca od cza­su do cza­su idzie mu na rękę (reali­zo­wa­nie drob­nych zachcia­nek Zamawiającego w zakre­sie projektu),
  4. Zespół Zamawiającego jest izo­lo­wa­ny od innych per­spek­tyw i spoj­rze­nia na reali­zo­wa­ny pro­jekt (sil­ne dąże­nie Dostawcy do wyeli­mi­no­wa­nia zewnętrz­ne­go nad­zo­ru mery­to­rycz­ne­go, audy­tów, nad­zo­ru autorskiego).

Psycholodzy co do jed­ne­go są zgod­ni: czło­wiek nie jest w sta­nie bro­nić się przed swo­imi emo­cja­mi, dla­te­go czę­sto jedy­nym spo­so­bem obro­ny przed mani­pu­la­cją jest uni­ka­nie kon­tak­tu z mani­pu­lan­tem. Nie ma tu zna­cze­nia czy to mani­pu­la­cja celo­wa czy nieuświadomiona.

Lekarstwo na sytu­acje, takie jak wyżej opi­sa­na, jest tyl­ko jed­no: zre­zy­gno­wać z warsz­ta­tów gru­po­wych z Dostawcą! Jak to komuś mówię to ma miej­sce prze­ra­że­nie i pada­ją sło­wa ​„Ale prze­cież pra­ca gru­po­wa jest naj­efek­tyw­niej­sza! Tak uczy­li na szko­le­niu i mówi­li na kon­fe­ren­cjach”. W lite­ra­tu­rze nie raz spo­ty­ka­łem się z podej­ściem odra­dza­ją­cym warsz­ta­ty gru­po­we i burze mózgów z uwa­gi a ich duże kosz­ty i nie­efek­tyw­ność. Nie jest jed­nak takich opi­nii zbyt wie­le, bo mit efek­tyw­no­ści pra­cy gru­po­wej jest wiecz­nie żywy (mimo tego, że bada­nia nauko­we poka­zu­ją, że pra­ca gru­po­wa jest mniej efek­tyw­na niż pra­ca samodzielna).

Praca gru­po­wa, mity i fak­ty.

Jednak od cza­su do cza­su spo­ty­kam się książ­ka­mi czy wpi­sa­mi na blo­gach, że odej­ście od idei JAD (ang. Joint Application Development) wydat­nie popra­wi­ło jakość pro­jek­tów (sam IBM pro­po­nu­je w to miej­sce cał­ko­wi­te zastą­pie­nie warsz­ta­tów ana­li­zą doku­men­tów źró­dło­wych a potem pisem­ne for­mu­ło­wa­nie uwag i zarzą­dza­nie zakre­sem pro­jek­tu z uży­ciem ści­słej pro­ce­du­ry, co para­dok­sal­nie trwa kró­cej, jest tań­sze i daje znacz­nie lep­sze efekty).

Co cie­ka­we, idea taka poja­wi­ła się w np. tak zwa­nej zwin­nej meto­dzie zarzą­dza­nia pro­jek­tem SCRUM, w posta­ci roli Product Ownera (PO) jako oso­by prak­tycz­nie cał­ko­wi­cie sepa­ru­ją­cej zespół zama­wia­ją­ce­go od zespo­łu Dostawcy (busi­ness vs. developers):

There are seve­ral aspects abo­ut this role which I think are cri­ti­cal to under­stand: Product owners brid­ge the com­mu­ni­ca­tion betwe­en the team and the­ir sta­ke­hol­ders. As Figure 1 shows, in prac­ti­ce the­re pro­ves to be two cri­ti­cal aspects to this role: first as a sta­ke­hol­der pro­xy within the deve­lop­ment team and second as a pro­ject team repre­sen­ta­ti­ve to the ove­rall sta­ke­hol­der com­mu­ni­ty as a whole.[…]

The role of Product Owner (Scott Ambler, Agile Modeling)

Źródło: The Product Owner Role: A Stakeholder Proxy for Agile Teams

Ciekawe jest to, że więk­szość zna­nych mi zespo­łów dekla­ru­ją­cych pra­cę zgod­ną ze SCRUM, to zespo­ły deve­lo­per­skie, któ­re prak­tycz­nie cał­ko­wi­cie rezy­gnu­ją z praw­dzi­wej roli PO. Jak? Po pro­stu wyzna­cza­ją na PO jed­ne­go z pośród człon­ków zespo­łu deve­lo­per­skie­go, co jest pogwał­ce­niem zasad SCRUM. Skutek jest taki, że oso­ba, któ­rej pod­sta­wo­wą rolą jest zarzą­dza­nie funk­cjo­nal­no­ścią pro­duk­tu i sepa­ro­wa­nie Developera od Zamawiającego, pra­cu­je na rzecz deve­lo­pe­ra i godzi się na każ­dą zmia­nę korzyst­ną dla swo­je­go zespo­łu. Niestety w pro­jek­tach pro­gra­mi­stycz­nych jest to nie­mal­że regu­ła. W pro­jek­tach budow­la­nych (set­ki lat doświad­czeń) dla odmia­ny jest to praw­nie zaka­za­ne: nie wol­no łączyć roli nad­zo­ru autor­skie­go (archi­tekt i pro­jek­tant) ani z rolą wyko­naw­cy ani z rolą inwestora.

Na koniec pole­cam cie­ka­wy arty­kuł na podob­ny temat:

Polacy kupu­ją miesz­ka­nia bez usług i zie­le­ni. Wybierają szczel­nie ogro­dzo­ne beto­no­we pusty­nie bez przed­szko­li, pla­ców zabaw i komu­ni­ka­cji. A obok roz­wią­zań praw­nych to wła­śnie decy­zje kon­su­men­tów ukształ­tu­ją nam prze­strzeń na kolej­ne dzie­się­cio­le­cia. (żr. Ufamy dewe­lo­pe­rom bar­dziej niż leka­rzom. Przypomina to syn­drom sztok­holm­ski).

Bibliografia

[1]
J. Żeliński, ?Moja rola w pro­jek­tach,? IT-Consulting. [Online]. Available: https://it-consulting.pl//metoda-prowadzenia-analiz-i-standardy/
[3]
?Syndrom Sztokholmski,? Newsweek. [Online]. Available: 
[4]
?Syndrom Sztokholmski,? Niebieska linia. [Online]. Available: 

A na grzyba nam Pan Analityk?

8 komentarzy

Przecież ana­li­zę zro­bi­my sami, a jak nie – to zro­bi to dostaw­ca. Tak czę­sto roz­po­czy­na się tak zwa­na ​„Droga do klę­ski”. Jednym z typo­wych listów ini­cju­ją­cych współ­pra­ce z wie­lo­ma moimi klien­ta­mi był ten:

Planujemy wdro­że­nie nowe­go opro­gra­mo­wa­nia, chce­my tym razem unik­nąć pre­sji ze stro­ny dostaw­cy opro­gra­mo­wa­nia. Poprzednim razem dostaw­ca opro­gra­mo­wa­nia uprasz­czał sobie pra­cę, już na eta­pie ana­li­zy, któ­rą wyko­ny­wał sam. Analiza wyma­gań pole­ga­ła na wywia­dach i warsz­ta­tach gru­po­wych, skoń­czy­ła się zwy­kłym opi­sem, tabel­ka­mi i kil­ko­ma nie­czy­tel­ny­mi sche­ma­ta­mi. Podczas ana­li­zy i wdro­że­nia sta­le wma­wia­no nam, że ​„tego nie moż­na”, ​„to nale­ży upro­ścić” albo ​„tak się nie robi” my zaś nie potra­fi­li­śmy tego oce­nić. Wiele naszych potrzeb odkry­wa­li­śmy dopie­ro pod­czas insta­la­cji kolej­nych pro­to­ty­pów, zaś dostaw­ca uni­kał wpro­wa­dza­nia zmian i obie­ca­nych dosto­so­wań. Dostaliśmy w efek­cie nie­przy­dat­ne i nie­zgod­ne z biz­ne­so­wy­mi potrze­ba­mi opro­gra­mo­wa­nie. Czy może nam Pan tym razem pomóc?

Czy to pro­pa­gan­da? Niestety nie. W czym pro­blem? A mia­no­wi­cie w meto­dzie pro­wa­dze­nia ana­li­zy i potem tre­ści spe­cy­fi­ka­cji wyma­gań. Łatwo powie­dzieć: zebrać wymagania.

Powszechnie uwa­ża się, że ana­li­za wyma­gań na opro­gra­mo­wa­nie to pro­sty, ale pra­co­chłon­ny pro­ces pro­wa­dze­nia wywia­dów i skrzęt­ne­go zapi­sy­wa­nia tego, cze­go ocze­ku­je przy­szły użyt­kow­nik. Nic bar­dziej błęd­ne­go – jest to naj­gor­szy sposób.

Wśród wie­lu tego typu metod są te naj­prost­sze i naj­bar­dziej ryzy­kow­ne a mia­no­wi­cie: wywia­dy, ankie­ty, [[sesje JAD]]. Sama ich isto­ta zakła­da, że klient wie co chce, nale­ży to tyl­ko z nie­go wycią­gnąć i upo­rząd­ko­wać. Być może cza­sa­mi tak jest, ale z regu­ły koń­czy się to kla­sycz­nym stwier­dze­niem klien­ta na koniec projektu:

Tak, dostar­czy­li nam Państwo dokład­nie to co chcie­li­śmy ale zupeł­nie nie to, cze­go potrzebujemy.

Dlaczego tak się dzie­je, choć wie­lu (ana­li­ty­ków) tak bar­dzo się sta­ra? Jak ana­li­za może wyglą­dać napi­sa­łem tu już nie raz. Ale po co tyle zacho­du? Dlaczego upie­ram się przy tych śmiesz­nych for­ma­li­zmach, sko­ro moż­na po ludz­ku zapi­sać co powie­dział user a potem zamie­nić to na wypunk­to­wa­ne listy lub wier­sze ład­nej tabe­li? Najlepiej jesz­cze gdy liczą sobie naj­mniej kil­ka­set pozy­cji. Jednak tak pra­cu­je ana­li­tyk dyk­ta­fon.

Dobra spe­cy­fi­ka­cja wyma­gań na opro­gra­mo­wa­nie, to wynik ana­li­zy i mode­lo­wa­nia orga­ni­za­cji, kom­pro­mis pomię­dzy moż­li­wo­ścia­mi tech­no­lo­gii a cela­mi biz­ne­so­wy­mi wdro­że­nia. Nie ma tu zna­cze­nia czy będzie to goto­wy sys­tem ERP, czy dedy­ko­wa­ne roz­wią­za­nie. Ale po kolei.

Czym gro­zi ana­li­tyk dyktafon?

Tu pozwo­lę sobie sko­rzy­stać z zawar­to­ści krót­kie­go arty­ku­łu kole­gi pro­wa­dzą­ce­go blog O wyma­ga­niach. Poniżej kil­ka sta­ty­styk oraz mój komen­tarz co do ich przy­czyn. a że pro­blem jest poważ­ny wystar­czy wie­dzeć, że:

Błędy w wyma­ga­niach to jed­na trze­cia wszyst­kich defek­tów w pro­jek­tach. [Dean Leffingwell, Don Widrig – ​„Managing Software Requirements” (1999)]

Produktem ana­li­zy wyma­gań są wyma­ga­nia, jak już wspo­mnia­łem, moż­na je zbie­rać meto­da­mi ​„reje­stra­cyj­ny­mi” (odpy­ty­wa­nie klien­tów) oraz ​„badaw­czy­mi”. Te dru­gie to kolej­no: ana­li­za i model orga­ni­za­cji klien­ta, iden­ty­fi­ka­cja celów biz­ne­so­wych i czyn­ni­ków wpły­wa­ją­cych na ich osią­gnię­cie, pro­jekt roz­wią­za­nia: co ma zostać dostar­czo­ne, opis pro­jek­tu czy­li spe­cy­fi­ka­cja pro­duk­tu. Wywiady są łatwe a peł­na ana­li­za trud­na. Nie trud­no się więc domy­ślić, któ­rych się robi naj­wię­cej. I mamy głów­ną przy­czy­nę, to właśnie:

Procesy zwią­za­ne ze zbie­ra­niem wyma­gań są źró­dłem więk­szo­ści poważ­nych pro­ble­mów z jako­ścią. [Gerald Weinberg – ​„Quality Software Management” (1997)]

Jakość spe­cy­fi­ka­cji wyma­gań to mię­dzy inny­mi jej kom­plet­ność, spój­ność itp. Jak doku­ment wyma­gań jest niskiej jako­ści to typo­wym obja­wem jest tak zwa­ne odkry­wa­nie wyma­gań w trak­cie trwa­nia pro­jek­tu, czy­li zmia­ny zakre­su pro­jek­tu, a:

Zmiany zakre­su są jed­nym z naj­częst­szych źró­deł dodat­ko­wych kosz­tów w pro­jek­tach i czę­sto pro­wa­dzą do porzu­ce­nia pro­jek­tu. [Capers Jones – ​„Assessment and Control of Software Risks” (1994)]

Co jesz­cze? Skąd te roz­dę­te budże­ty, prze­ter­mi­no­wa­ne pro­jek­ty typu ​„czas i mate­riał”? Bo:

Naprawa błę­dów zwią­za­nych z wyma­ga­nia­mi pochła­nia 70 – 80% kosz­tów ponow­nej pra­cy w pro­jek­tach IT. A cał­ko­wi­te kosz­ty ponow­nej pra­cy zja­da­ją nawet do 50% kosz­tów pro­jek­tu. [Dean Leffingwell – ​„Calculating and Return on Investment from More Effective Requirements Management” (1997)]

Kolejny etap, to kosz­ty utrzymania:

Szukanie i napra­wia­nie błę­dów wyma­gań po wdro­że­niu sys­te­mu jest 100 razy kosz­tow­niej­sze niż szu­ka­nie i napra­wia­nie tych samych błę­dów pod­czas zbie­ra­nia wyma­gań. [Barry Boehm, Victor R. Basili – ​„Software Defect Reduction Top 10 List” (2001)]

I tyle o złych wymaganiach.

Analityk zamiast dyktafonu

Jeżeli wyma­ga­nia spe­cy­fi­ku­je się meto­dą pro­stej obser­wa­cji (odsłu­chu) otrzy­mu­je­my opis fak­tów a nie ich przy­czyn. Rzecz a tym, że fak­ty nic nie mówią o ich przy­czy­nach. Kolejny cytat:

Wyobraźmy sobie kogoś, kto chce napi­sać pro­gram symu­lu­ją­cy grę w sno­oke­ra. Problem ten może zostać opi­sa­ny przy­pad­ka­mi uży­cia opi­su­ją­cy­mi powierz­chow­nie cechę: ​„Gracz ude­rza bia­ła kulę, któ­ra prze­miesz­cza się z pew­ną pręd­ko­ścią, ta po okre­ślo­nym cza­sie ude­rza czer­wo­ną kulę pod okre­ślo­nym kątem, ude­rzo­na czer­wo­na kula prze­miesz­cza się na pew­na odle­głość w pew­nym kie­run­ku.” Możesz sfil­mo­wać set­ki tysię­cy takich ude­rzeń, zare­je­stro­wać para­me­try każ­de­go ude­rze­nia i jego skut­ki. Jednak tą meto­dą i tak nie stwo­rzysz nawet dość dobrej symu­la­cji. Aby napi­sać na praw­dę dobrą grę, powi­nie­neś raczej zro­zu­mieć pra­wa rzą­dzą­ce ruchem kul, ich zależ­ność od siły i kie­run­ku ude­rze­nia, kie­run­ku itp. Zrozumienie tych praw pozwo­li Ci znacz­nie łatwiej napi­sać dobre opro­gra­mo­wa­nie. (źr. Analysis Patterns. Reusable Object Models, Martin Fowler, Addison-Wesley, 1997).

Inny przy­kład, z nie­co innej dzie­dzi­ny ale dosko­na­le odda­ją­cy efek­ty pole­ga­nia na obser­wa­cji. Przez wie­le lat uzna­wa­no, że Ziemia to cen­trum wszech­świa­ta. Ludzie obser­wo­wa­li Niebo z Ziemi. To co widzą, po pro­tu reje­stro­wa­li ufa­jąc, że sama obser­wa­cja da wła­ści­wy wynik. W efek­cie uzy­ski­wa­li takie oto tra­jek­to­rie pla­net i gwiazd:

geocentryczny

Nie dawa­ły się opi­sać żad­nym pro­stym rów­na­niem, a te rów­na­nia któ­re powsta­wa­ły były nie tyl­ko przy­bli­że­nia­mi ale tak­że bar­dzo zło­żo­ny­mi zależ­no­ścia­mi dla każ­de­go cia­ła nie­bie­skie­go z osob­na. Powyższy rysu­nek to namiast­ka tego przy­no­szą z sobą ana­li­ty­cy obserwatorzy.

Prawdę odkrył i udo­ku­men­to­wał Kopernik, czło­wiek któ­ry nie szu­kał pokla­sku ani u zwy­kłych ludzi patrzą­cych z wia­rą w nie­bo, ani u tych, w któ­rych inte­re­sie było, by Ci ludzie wie­rzy­li, że Ziemia to sta­no­wi cen­trum ich świa­ta. Odkryta praw­da w efek­cie wszyst­kim dobrze słu­ży ? mimo począt­ko­we­go opo­ru, a wyglą­da ona tak:

heliocentryczny

System helio­cen­trycz­ny jest pro­sty, zro­zu­mia­ły dla każ­de­go, łatwy do opi­sa­nia (mimo to wie­lu ludziom nadal trud­no się pogo­dzić z tym, że nie są pęp­kiem świa­ta a jedy­nie jego czę­ścią i to nie cen­tral­ną). Poszczególne komór­ki orga­ni­za­cyj­ne w fir­mach i orga­ni­za­cjach, owe fir­my na ryn­ku, są jak poszcze­gól­ne cia­ła nie­bie­skie we wszech­świe­cie, pra­cow­ni­cy tych orga­ni­za­cji jak róż­ni obser­wa­to­rzy tego same­go Nieba. Każdy ma swo­je oso­bi­ste spoj­rze­nie na swo­ją część ale nikt z nich nie widzi cało­ści «z góry”. Każdy ma swój, geo­cen­trycz­ny widok. Typowe wywia­dy to zle­pek takich opisów.

Praktyka poka­zu­je, że sys­te­my (fir­my, orga­ni­za­cje) obser­wo­wa­ne z ich wnę­trza wyda­ją się bar­dzo skom­pli­ko­wa­ne i tak też są opi­sy­wa­ne przez więk­szość ludzi (patrz wyżej dia­gram sys­te­mu geo­cen­trycz­ne­go). W rze­czy­wi­sto­ści więk­szość sys­te­mów jest znacz­nie prost­sza, jed­nak odkry­cie tego wyma­ga głę­bo­kie­go spoj­rze­nia z zewnątrz.

Rzemieślnicy pro­du­ku­ją­cy ?przed Kopernikiem? skom­pli­ko­wa­ne i kosz­tow­ne przy­rzą­dy do okre­śla­nia poło­że­nia pla­net i gwiazd z wia­do­mych powo­dów nie byli zain­te­re­so­wa­ni uprasz­cza­niem tego mode­lu i swo­ich skom­pli­ko­wa­nych przy­rzą­dów. Dlatego zapew­ne nie raz jesz­cze usły­szę, że dobra ana­li­za to set­ki stron, tysią­ce wyma­gań, mie­sią­ce pracy.

Jednak dobra ana­li­za to tyl­ko: dzie­siąt­ki stron i wyma­gań, tygo­dnie pra­cy ale zaawan­so­wa­ne meto­dy takie jak for­mal­na ana­li­za sys­te­mo­wa opar­ta na mode­lach i ich testowaniu.

Warto jed­nak zazna­czyć, że tak jak pro­jek­ty dedy­ko­wa­ne mają sens od ok. 75 tys. zł. (wyli­cze­nie w jed­nym zw wcze­śniej­szych arty­ku­łów) tak zaprzę­ga­nie takich metod ana­li­zy ma sens nawet jeże­li war­tość pro­jek­tu (war­tość ryzy­ka) prze­kra­cza już 10 tys. czy­li nie tak wie­le.… (koszt tego typu ana­liz to ok. 20% budże­tu projektu).

Na zakon­cze­nie cytat:

Niestety naj­częst­szy­mi przy­czy­na­mi [pro­ble­mów i dużych kosz­tów w pro­jek­tach] są źle prze­pro­wa­dzo­na ana­li­za przed­wdro­że­nio­wa i nie­ste­ty zbyt małe doświad­cze­nie part­ne­ra wdro­że­nio­we­go. Zwłaszcza przy dużych pro­jek­tach, gdzie spe­cy­fi­ka przed­się­bior­stwa wyma­ga oddziel­nych roz­wią­zań uzu­peł­nia­ją­cych i dużej wie­dzy pro­gra­mi­stycz­nej, poja­wia­ją się pro­ble­my. (źr. Wdrożenie ERP ? koszt czy zysk? – ERP ‑view​.pl.)

analiza systemowa oraz modelowanie jako jej główne narzędzie.

Analiza Systemowa – analiza biznesowa i projektowanie systemów

10 komentarzy

W stycz­niu tego (2011) roku napi­sa­łem: Mamy więc ana­li­zę biz­ne­so­wą i spe­cy­fi­ko­wa­nie wyma­gań poprzez opra­co­wa­nie wery­fi­ko­wal­nych mode­li a nie tyl­ko listę potrzeb, któ­rej nie­ste­ty nie da się zwe­ry­fi­ko­wać co do kom­plet­no­ści i spój­no­ści bo nie ma narzę­dzia spraw­dza­ją­ce­go. Co jest takim narzę­dziem? Ano mode­le i to, że powsta­ły (jeże­li powsta­ły) przy pomo­cy sfor­ma­li­zo­wa­nej nota­cji. (źr. Analiza przed­wdro­że­nio­wa ? czym jest | Jarosław Żeliński – rynek IT, ana­li­za biz­ne­so­wa i pro­jek­to­wa­nie sys­te­mów).

Przyszła pora na opi­sa­nie samej ana­li­zy. Skoro więc ana­li­za bazu­je na mode­lach, naj­czę­ściej dia­gra­mach, poku­si­łem się na, tym razem na nie­for­mal­ny dia­gram obra­zu­ją­cy ana­li­zę sys­te­mo­wą w kon­tek­ście inży­nie­rii oprogramowania.

Mamy dwa ele­men­ty tej ana­li­zy: ana­li­zę sys­te­mo­wą jako pro­ces głów­ny oraz mode­le jako narzę­dzia testo­wa­nia hipo­tez. W przy­pad­ku pro­jek­to­wa­nia celem jest pro­jekt rozwiązania.

Standardowym narzę­dziem sto­so­wa­nym przez więk­szość ana­li­ty­ków wyma­gań do prze­ka­za­nia wyma­gań na opro­gra­mo­wa­nie jest ich spe­cy­fi­ka­cja. Problem w tym, że pierw­szym testem tej spe­cy­fi­ka­cji jest tak na praw­dę dopie­ro ich implementacja.

Alternatywnym podej­ściem jest ana­li­za sys­te­mo­wa i mode­lo­wa­nie. Problem do roz­wią­za­nia to opra­co­wa­nie opro­gra­mo­wa­nia, któ­re zre­ali­zu­je cel zama­wia­ją­ce­go. Zamiast jed­nak, np. z pomo­cą wywia­dów, spi­sy­wać, nie pod­da­ją­ce się żad­nym testom, ocze­ki­wa­nia zama­wia­ją­ce­go, two­rzy­my dwa modele:

  1. naj­pierw model fir­my zama­wia­ją­ce­go by na nim prze­te­sto­wać zro­zu­mie­nie dzia­ła­nie samej fir­my i ewen­tu­al­nie ją nie­co ​„zop­ty­ma­li­zo­wać”,
  2. model przy­szłe­go opro­gra­mo­wa­nia, któ­re ma zaspo­ko­ić potrze­by zama­wia­ją­ce­go czy­li zre­ali­zo­waw­szy jego cel.

Celem jest opro­gra­mo­wa­nie a dostaw­cy opro­gra­mo­wa­nia naj­mniej ryzy­ku­ją gdy dosta­ną jego spe­cy­fi­ku­ję czy­li goto­wy pro­jekt. Tak wiec prze­te­sto­wa­ny model opro­gra­mo­wa­nia reali­zu­ją­cy cel zama­wia­ją­ce­go jako wynik ana­li­zy sys­te­mo­wej sta­no­wi nic inne­go jak opis pro­duk­tu, któ­ry ma powstać. Oczywiście nikt nie pro­jek­tu­je od zera opro­gra­mo­wa­nia biz­ne­so­we­go bo to nie­roz­sąd­ne, wyko­rzy­stu­je się tak zwa­ne szkie­le­ty opro­gra­mo­wa­nia. O szkie­le­tach już było tu: Frameworks Introduction ? czy­li jak się psu­je dobre ERP. A teraz zapra­szam do obej­rze­nia tego co tu napi­sa­łem po moje­mu czy­li na dia­gra­mie 🙂 (tak zwa­ne mapy myśli cza­sa­mi sie przydają :)).

Warto tu zwró­cić uwa­gę na jed­ną rzecz: ewen­tu­al­ne zmia­ny roz­wią­za­nia i korek­ty mode­lu (czy­li pro­jek­tu) odby­wa­ją się nadal na eta­pie ana­li­zy i pro­jek­to­wa­nia, a wiec o rząd albo dwa taniej, niż pod­czas imple­men­ta­cji. Jest to głów­na prze­wa­ga tej meto­dy nad ana­li­zą w posta­ci sesji JAD ([[JAD, ang. Joint Application Development]] – ozna­cza współ­two­rze­nie apli­ka­cji, któ­re cza­sa­mi postrze­gam jako świa­do­me anga­żo­wa­nie klien­ta w pro­ces pro­jek­to­wa­nia by potem uczy­nić go współ­win­nym nie­po­wo­dze­nia) i opra­co­wy­wa­nia struk­tu­ral­nych dokumentów.

analiza systemowa oraz modelowanie jako jej główne narzędzie.

Jeżeli zre­zy­gnu­je­my z mode­li pozo­sta­je nam ryzy­kow­na sesja warsz­ta­to­wa (nie­jed­na):

Przygotowując warsz­tat zbie­ra­nia wyma­gań musisz być pewien, że zapro­sisz na nie­go wła­ści­we oso­by. Pamiętaj wte­dy, że:

  • Twoi bez­po­śred­ni klien­ci (pre­ze­si, dyrek­to­rzy, wła­ści­cie­le firm) czę­sto nie zna­ją tak napraw­dę potrzeb i kon­tek­stu pra­cy przy­szłych użyt­kow­ni­ków koń­co­wych zama­wia­ne­go systemu.
  • Użytkownicy koń­co­wi nie zawsze zna­ją i rozu­mie­ją potrze­bę biz­ne­so­wą dla two­rze­nia nowe­go oprogramowania.
  • Klienci i użyt­kow­ni­cy koń­co­wi nie zna­ją tech­no­lo­gii tak dobrze jak Ty i Twoja fir­ma, więc nie będą w sta­nie zro­zu­mieć szcze­gó­łów roz­wią­zań tech­nicz­nych w two­rzo­nym systemie.
  • Ty i Twoja fir­ma może­cie nie rozu­mieć w peł­ni potrzeb klien­ta i pro­ble­mu, któ­ry two­rzo­ne opro­gra­mo­wa­nie ma rozwiązać.

Co z tym zro­bić? Pamiętaj, aby zadbać, żeby przed­sta­wi­cie­le wszyst­kich powyż­szych grup bra­li udział w warsz­ta­tach, wów­czas inte­res każ­dej ze stron będzie repre­zen­to­wa­ny. (źr. ser­wis O wymaganiach)