Strona poświęcona mojej pracy naukowej i usługom jakie świadczę polskim podmiotom. Zapraszam tych którzy szukają wiedzy i tych którzy szukają wsparcia w swoich projektach informatyzacji.
Analizy Biznesowe i Systemowe Przedsiębiorstw - Projektowanie Systemów Informatycznych
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:
Zespól Zamawiającego wierzy, że „być albo nie być” firmy, zależy od powodzenia projektu,
Zespół Zamawiającego nie widzi alternatywy dla tego wdrożenia,
Zespół Zamawiającego widzi, że Dostawca od czasu do czasu idzie mu na rękę (realizowanie drobnych zachcianek Zamawiającego w zakresie projektu),
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.[…]
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ę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).
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę 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.
Strona używa plików cookie, aby zapewnić Ci wygodę przeglądania poprzez zapamiętywanie Twoich preferencji i powtarzających się wizyt. Klikając "Akceptuj wszystko", wyrażasz zgodę na użycie WSZYSTKICH plików cookie. Jednakże, możesz odwiedzić "Ustawienia plików cookie", aby zapewnić kontrolowaną zgodę.
Ta strona korzysta z plików cookie, aby poprawić wygodę podczas podczas przeglądania witryny. Pliko cookie, które są sklasyfikowane jako niezbędne, są przechowywane w przeglądarce, ponieważ są niezbędne do działania podstawowych funkcji witryny. Używamy również plików cookie stron trzecich, które pomagają nam analizować i zrozumieć, w jaki sposób korzystasz z tej witryny. Te pliki cookie będą przechowywane w przeglądarce tylko za Twoją zgodą. Możesz również zrezygnować z tych plików cookie. Ale rezygnacja z niektórych z tych plików cookie może mieć wpływ na wygodę przeglądania.
Niezbędne pliki cookie są absolutnie niezbędne do prawidłowego funkcjonowania witryny. Ta kategoria obejmuje tylko pliki cookie, które zapewniają podstawowe funkcje i zabezpieczenia strony. Te pliki cookie nie przechowują żadnych danych osobowych.
Wszelkie pliki cookie, które mogą nie być szczególnie potrzebne do działania witryny i są wykorzystywane w szczególności do gromadzenia danych osobowych użytkowników za pośrednictwem analiz, reklam i innych treści osadzonych, są określane jako niepotrzebne pliki cookie. Wymagane jest uzyskanie zgody użytkownika przed uruchomieniem tych plików cookie w witrynie.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Cookie
Duration
Description
__atuvc
1 year 1 month
AddThis sets this cookie to ensure that the updated count is seen when one shares a page and returns to it, before the share count cache is updated.
__atuvs
30 minutes
AddThis sets this cookie to ensure that the updated count is seen when one shares a page and returns to it, before the share count cache is updated.
bcookie
2 years
LinkedIn sets this cookie from LinkedIn share buttons and ad tags to recognize browser ID.
bscookie
2 years
LinkedIn sets this cookie to store performed actions on the website.
language
session
This cookie is used to store the language preference of the user.
lidc
1 day
LinkedIn sets the lidc cookie to facilitate data center selection.
na_id
1 year 24 days
The na_id is set by AddThis to enable sharing of links on social media platforms like Facebook and Twitter.
ouid
1 year 24 days
Associated with the AddThis widget, this cookie helps users to share content across various networking and sharing forums.
vc
1 year 24 days
The vc cookie is set by addthis.com on sites that allow sharing on social media.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Cookie
Duration
Description
at-rand
never
AddThis sets this cookie to track page visits, sources of traffic and share counts.
browser_id
5 years
This cookie is used for identifying the visitor browser on re-visit to the website.
CONSENT
2 years
YouTube sets this cookie via embedded youtube-videos and registers anonymous statistical data.
uid
1 year 24 days
This is a Google UserID cookie that tracks users across various website segments.
uvc
1 year 1 month
Set by addthis.com to determine the usage of addthis.com service.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Cookie
Duration
Description
di2
1 year 24 days
AddThis sets this cookie on sites that allow sharing on social media. It is used to track user behaviour anonymously, to create usage trends that will improve relevance to their services and advertising.
loc
1 year 1 month
AddThis sets this geolocation cookie to help understand the location of users who share the information.
um
1 year 24 days
Set by AddThis for registering the user's sharing of content through social media.
VISITOR_INFO1_LIVE
5 months 27 days
A cookie set by YouTube to measure bandwidth that determines whether the user gets the new or old player interface.
YSC
session
YSC cookie is set by Youtube and is used to track the views of embedded videos on Youtube pages.
yt-remote-connected-devices
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt-remote-device-id
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt.innertube::nextId
never
This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.
yt.innertube::requests
never
This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.
Ciekawy artykuł na podobny temat:
https://www.focus.pl/artykul/9‑klamstw-na-temat-rozwoju-osobistego