Od wielu lat lat, produktem mojej pracy są dokumenty opisujące w obiektywny sposób działanie organizacji, zawierające rekomendacje zmian do poprawy sytuacji, także wymagania na systemy informacyjne. Po opracowaniu rozwiązania i pomocy w wyborze jego dostawcy, prowadzę nadzór autorski nad realizacją opracowanego rozwiązania. [1] Po latach pracy nasuwa mi się dość ciekawy wniosek z obserwacji: Zamawiający działają na swoją szkodę!

Typowy projekt związany z wdrażaniem nowych rozwiązań to realne potrzeby Zamawiającego. Członkowie zespołu Zamawiającego mają nad sobą terminy  i “nieuchronność” kary za niepowodzenie. W efekcie Dostawca szybko staje się “Panem projektu”, bo to on dostarcza rozwiązanie, zna się, a bywa że szantażuje. Przewaga merytoryczna Dostawcy nad Zamawiającym jest tak wielka, że ten ostatni w zasadzie nie jest w stanie panować nad projektem. Powoli rynek to dostrzega i dlatego od kilku lat niemalże każda moja umowa na projektowanie zawiera także nadzór autorski (to forma kontroli efektów pracy dostawcy).

Nadal bardzo często Dostawca tworzy jednak pewną atmosferę: “to my realizujemy Wasz projekt i wszystko – Wy także – od nas zależy, nadzór autorski psuje Wam harmonogram bo my musimy te dokumenty czytać i tworzyć”.  Dwa razy w ostatnich pięciu lat zdarzyło mi się, że faktycznie Zamawiający zrezygnował z nadzoru autorskiego, bo członkowie zespołu zaczęli “trzymać stronę Dostawcy”, mimo informacji o szkodliwości zmian wprowadzanych przez z Dostawcę. Oba projekty skończyły się niestety klęską (mam kontakt z praktycznie każdym byłym klientem).

Projekt wdrożeniowy bez nadzoru merytorycznego, to bardzo często równia pochyła: od podpisania umowy na wdrożenie z dostawcą jest już tylko coraz gorzej, bo Dostawca upraszcza logikę systemu, pomija trudne do realizacji wymagania, stale organizuje spotkania, na których legitymizuje te zmiany w prosty sposób sposób: “to co macie w dokumentacji wymagań jest złe (nie da się, nikt tak nie robi itp.), nasz system realizuje to inaczej, zróbmy to prościej i szybciej a też będzie dobrze”. Zamawiający z reguły nie ma po swojej stronie żadnych kompetencji by ocenić skutki takich “propozycji” i na spotkaniach godzi się na to, podpisując kolejne notatki projektowe z takich “warsztatów”, małymi kroczkami funkcjonalność dostarczanego produktu oddala się od faktycznych potrzeb i wymagań. Projekt kończy się tak, że Zamawiający “dostał dokładnie to co chciał a nie to co jest mu potrzebne”. Statystyki projektów IT są bezlitosne: ok. 2/3 projektów to nadal projekty nieudane. [2]

Tam gdzie mój projekt był kolejnym podejściem, po poprzednim nieudanym, wyżej opisana sytuacja była praktycznie zawsze przyczyną wcześniejszej porażki. Paradoksalnie jest to – porażka – wręcz standardowa sytuacja, gdy Zamawiający najpierw wybiera Dostawcę a potem zleca mu analizę wymagań i kierowanie projektem.

Zjawisko to zawsze kojarzy mi się ze znanym w psychologii efektem nazywanym Syndrom Sztokholmski. Jest to sytuacja, w której ofiara, wbrew zdrowemu rozsądkowi, zaczyna sympatyzować ze swoim oprawcą.

[Syndrom Sztokholmski] …ofiara porwania czy zakładnik traci krytycyzm wobec swojej sytuacji, zaczyna wierzyć, ze jej oprawca działa w słusznym celu, i darzyć go sympatią. Jak twierdzi amerykańska psycholog, dr Natalie de Fabrique, zajmująca się badaniem tego syndromu, syndrom sztokholmski pojawia się u ofiar nieświadomie, to instynktowny, psychologiczny mechanizm obronny, dzięki któremu łatwiej jest im odnaleźć sens tego, co się dzieje, i uniknąć załamania nerwowego. [3]

W wielu projektach wdrożeniowych mamy podobną sytuację: pracownicy zamawiającego, zamiast działać na rzecz siebie czy swojego pracodawcy,  zaczynają trzymać stronę Dostawcy, który żali się, że ma problem z terminami i przerzuca winę za to na swojego klienta. Po pewnym czasie dochodzi do tego, że zespół Zamawiającego tak się “zżył z pracownikami Dostawcy”, że zaczyna ich bronić przed własnymi przełożonymi. Są Dostawcy, którzy celowo stwarzają takie sytuacje (np. organizując wyjazdowe szkolenia i warsztaty z noclegami), ale nie raz dzieje się “samoistnie”. Popatrzmy na poniższą listę, czy nie przypomina Wam to czegoś?

Objawy i symptomy syndromu sztokholmskiego to:
– pozytywne uczucia ofiary wobec sprawcy;
– zrozumienie przez ofiarę motywów i zachowań sprawcy i podzielanie jego poglądów;
– pozytywne uczucia sprawcy względem ofiary;
– pomocne zachowania ofiary wobec sprawcy;
– negatywne uczucia ofiary wobec rodziny, przyjaciół, autorytetów próbujących ją ratować;
– niezdolność zaangażowania się w zachowania, które mogłyby doprowadzić do jej uwolnienia od sprawcy.
Syndrom sztokholmski nie dotyczy wszystkich osób dotkniętych tragicznymi zdarzeniami. By zaistniał, muszą wystąpić określone warunki. Ofiara:
– spostrzega, że jej przeżycie zależy od dobrej woli sprawcy;
– nie widzi możliwości ucieczki;
– dostrzega drobne uprzejmości ze strony sprawcy;
– jest izolowana od perspektyw odmiennych od perspektywy sprawcy.
[4]

Popatrzmy zatem na projekt wdrożeniowy, w którym:

1. Zespól Zamawiającego wierzy, że “być albo nie być” firmy, zależy od powodzenia projektu,
2. Zespół Zamawiającego nie widzi alternatywy dla tego wdrożenia,
3. Zespół Zamawiającego widzi, że Dostawca od czasu do czasu idzie mu na rękę (realizowanie drobnych zachcianek Zamawiającego w zakresie projektu),
4. Zespół Zamawiającego jest izolowany od innych perspektyw i spojrzenia na realizowany projekt (silne dążenie Dostawcy do wyeliminowania zewnętrznego nadzoru merytorycznego, audytów, nadzoru autorskiego).

Psycholodzy co do jednego są zgodni: człowiek nie jest w stanie bronić się przed swoimi emocjami, dlatego często jedynym sposobem obrony przed manipulacją jest unikanie kontaktu z manipulantem. Nie ma tu znaczenia czy to manipulacja celowa czy nieuświadomiona.

Lekarstwo na sytuacje, takie jak wyżej opisana, jest tylko jedno: zrezygnować z warsztatów grupowych z Dostawcą! Jak to komuś mówię to ma miejsce przerażenie i padają słowa “Ale przecież praca grupowa jest najefektywniejsza! Tak uczyli na szkoleniu i mówili na konferencjach”. W literaturze nie raz spotykałem się z podejściem odradzającym warsztaty grupowe i burze mózgów z uwagi a ich duże koszty i nieefektywność. Nie jest jednak takich opinii zbyt wiele, bo mit efektywności pracy grupowej jest wiecznie żywy (mimo tego, że badania naukowe pokazują, że praca grupowa jest mniej efektywna niż praca samodzielna).

Jednak od czasu do czasu spotykam się książkami czy wpisami na blogach, że odejście od idei JAD (ang. Joint Application Development) wydatnie poprawiło jakość projektów (sam IBM proponuje w to miejsce całkowite zastąpienie warsztatów analizą dokumentów źródłowych a potem pisemne formułowanie uwag i zarządzanie zakresem projektu z użyciem ścisłej procedury, co paradoksalnie trwa krócej, jest tańsze i daje znacznie lepsze efekty).

Co ciekawe, idea taka pojawiła się w np. tak zwanej zwinnej metodzie zarządzania projektem SCRUM, w postaci roli Product Ownera (PO) jako osoby praktycznie całkowicie separującej zespół zamawiającego od zespołu Dostawcy (business vs. developers):

There are several aspects about this role which I think are critical to understand: Product owners bridge the communication between the team and their stakeholders. As Figure 1 shows, in practice there proves to be two critical aspects to this role: first as a stakeholder proxy within the development team and second as a project team representative to the overall stakeholder community as a whole.[…]

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

Ciekawe jest to, że większość znanych mi zespołów deklarujących pracę zgodną ze SCRUM, to zespoły developerskie, które praktycznie całkowicie rezygnują z prawdziwej roli PO. Jak?  Po prostu wyznaczają na PO jednego z pośród członków zespołu developerskiego, co jest pogwałceniem zasad SCRUM. Skutek jest taki, że osoba, której podstawową rolą jest zarządzanie funkcjonalnością produktu i separowanie Developera od Zamawiającego, pracuje na rzecz developera i godzi się na każdą zmianę korzystną dla swojego zespołu. Niestety w projektach programistycznych jest to niemalże reguła. W projektach budowlanych (setki lat doświadczeń) dla odmiany jest  to prawnie zakazane: nie wolno łączyć roli nadzoru autorskiego (architekt i projektant) ani z rolą wykonawcy ani z rolą inwestora.

Na koniec polecam ciekawy artykuł na podobny temat:

Polacy kupują mieszkania bez usług i zieleni. Wybierają szczelnie ogrodzone betonowe pustynie bez przedszkoli, placów zabaw i komunikacji. A obok rozwiązań prawnych to właśnie decyzje konsumentów ukształtują nam przestrzeń na kolejne dziesięciolecia. (żr. Ufamy deweloperom bardziej niż lekarzom. Przypomina to syndrom sztokholmski).

Po latach

Niedawno [2023] pojawiła sie na YT ciekawa prezentacja, polecam, jest i o SCRUM i agile na tablicy: