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 spraw­cy;
- 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 ofia­ry;
- pomoc­ne zacho­wa­nia ofia­ry wobec spraw­cy;
- nega­tyw­ne uczu­cia ofia­ry wobec rodzi­ny, przy­ja­ciół, auto­ry­te­tów pró­bu­ją­cych ją rato­wać;
- 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 spraw­cy.
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 spraw­cy;
- nie widzi moż­li­wo­ści uciecz­ki;
- dostrze­ga drob­ne uprzej­mo­ści ze stro­ny spraw­cy;
- jest izo­lo­wa­na od per­spek­tyw odmien­nych od per­spek­ty­wy spraw­cy.
[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).

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

Po latach

Niedawno [2023] poja­wi­ła sie na YT cie­ka­wa pre­zen­ta­cja, pole­cam, jest i o SCRUM i agi­le na tablicy:

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:

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Ten post ma jeden komentarz

Dodaj komentarz

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