W projektach IT – szczególnie realizowanych dla instytucji publicznych – słowo „odpowiedzialność” bywa zdradliwe. Wszyscy go używają, wszyscy kiwają głową, a potem okazuje się, że każda strona miała na myśli coś innego.

Dostawca zwykle rozumie odpowiedzialność jako: „dowieźć rozwiązanie”.
Klient (zwłaszcza publiczny) często rozumie ją jako: „móc to uzasadnić i obronić”.

Te dwa znaczenia nie są sprzeczne. One są równoległe. Problem zaczyna się wtedy, gdy projekt jest prowadzony tak, jakby istniała tylko jedna z tych perspektyw.

Analityk po stronie dostawcy jest zwykle skupiony na tym, żeby jak najdokładniej zebrać wymagania, nadać im strukturę i przełożyć je na język pracy zespołu wytwórczego. To oznacza codzienną współpracę z architektami, developerami i testerami: doprecyzowanie reguł biznesowych, rozbijanie tematów na mniejsze elementy, pilnowanie spójności oraz wychwytywanie luk zanim staną się kosztownymi błędami.

W tej perspektywie odpowiedzialność jest bardzo „projektowa”: dostarczyć rozwiązanie zgodnie z zakresem, budżetem i harmonogramem. Liczy się przewidywalność, jasność i możliwość planowania. Niejasne wymaganie nie jest „neutralne” – jest ryzykiem. Każda niedopowiedziana reguła, każdy nieopisany wyjątek i każda decyzja „do ustalenia później” ma tendencję do powrotu w najgorszym możliwym momencie: podczas testów, odbiorów albo tuż przed wdrożeniem.

Dlatego analityk dostawcy często instynktownie dąży do domykania tematów: „dopiszmy kryteria akceptacji”, „ustalmy wyjątki”, „potrzebuję decyzji, inaczej nie da się zaprojektować rozwiązania”. Z zewnątrz może to wyglądać jak „nacisk”, ale z jego perspektywy to zwykłe zarządzanie ryzykiem dowiezienia.

Tymczasem analityk po stronie klienta – szczególnie w instytucji publicznej – funkcjonuje w świecie, gdzie projekt IT jest tylko jednym z elementów większego systemu. Ograniczenia wynikają nie tylko z budżetu czy zasobów, ale też z regulacji prawa, oczekiwań interesariuszy, procedur, a także realnej perspektywy kontroli i rozliczalności.

W tym świecie „wymaganie” rzadko jest wyłącznie opisem funkcji systemu. To często również:

Dlatego klient publiczny ma naturalną ostrożność wobec skrótów myślowych i „ustaleń na słowo”. Czasem nie chodzi o brak zaufania do dostawcy, tylko o świadomość konsekwencji: jeśli coś zostanie odebrane bez właściwej podstawy, konsekwencje nie spadną na wykonawcę – spadną na instytucję, a często konkretnych ludzi w niej.

I tu pojawia się najważniejszy element „innej perspektywy odpowiedzialności”: klient publiczny często odpowiada nie tylko za efekt, ale też za ścieżkę dojścia do efektu.

Najbardziej kosztowne nieporozumienia biorą się nie z konfliktu, tylko z pozornej zgody.

Dostawca pokazuje działającą funkcję, interesariusze mówią „wygląda dobrze”, temat przechodzi dalej. Z perspektywy dostawcy to jest akceptacja robocza – sygnał, że można rozwijać kolejne elementy.

Z perspektywy klienta publicznego to często jeszcze nie jest akceptacja w sensie odpowiedzialności. Bo akceptacja może oznaczać formalne zatwierdzenie: decyzję, protokół, podpis, ślad w obiegu dokumentów. I dopóki tego śladu nie ma, temat bywa „niby uzgodniony, ale wciąż ryzykowny”.

W praktyce projekt może stanąć na etapie odbioru nie dlatego, że „ktoś zmienił zdanie”, tylko dlatego, że jedna strona uważała temat za zamknięty, a druga traktowała go jako wstępne uzgodnienie.

W rozmowach projektowych często padają zdania typu: „to po waszej stronie”, „to nie w naszym zakresie”, „to decyzja biznesu”. Czasem są prawdziwe kontraktowo. Ale jeśli używa się ich jako sposobu na zamknięcie tematu, projektowo działają jak bomba z opóźnionym zapłonem.

Bo odpowiedzialność w projektach IT to nie tylko pytanie „kto ma zrobić”, ale przede wszystkim „kto poniesie konsekwencje, jeśli nie domkniemy tematu teraz”.

To są inne konsekwencje, dlatego strony inaczej ważą ryzyka – i inaczej definiują „odpowiedzialność”.

Dojrzała współpraca nie polega na przerzuceniu odpowiedzialności, tylko na jej świadomym podziale.

W praktyce pomaga bardzo proste przesunięcie w myśleniu:

To brzmi poważnie, ale w praktyce sprowadza się do jednego: ustalenia, co w tym projekcie jest „roboczym ustaleniem”, a co jest „decyzją, za którą ktoś stanie”.

„Inna perspektywa odpowiedzialności” nie oznacza, że jedna strona jest „trudna”, a druga „nie rozumie realiów”. Oznacza, że każda strona chroni inny rodzaj ryzyka.

Dostawca chce dowieźć działające rozwiązanie. Klient publiczny chce dowieźć rozwiązanie, które da się odebrać i obronić.

Gdy te dwie perspektywy spotykają się świadomie – projekt przyspiesza. Gdy spotykają się przypadkiem – projekt prędzej czy później zatrzymuje się na rzeczach, których nie widać w backlogu, ale które są bardzo widoczne w kontroli.