Zaangażowanie obu stron — dlaczego projekt IT to nie usługa kurierska
Zamawiasz kuriera — kurier przyjeżdża, zostawia paczkę, odjeżdża. Zero interakcji, zero pytań, zero odpowiedzialności za to co jest w środku. Projekt IT działa zupełnie inaczej. I ci którzy tego nie rozumieją, na końcu są zaskoczeni wynikiem.
Wzór który wiele wyjaśnia
W zarządzaniu kompetencjami funkcjonuje prosty wzór:
Postawa jest mnożnikiem — nie składnikiem
Postawa nie sumuje się z wiedzą — ona ją skaluje. Możesz mieć świetny stack, sprawdzone pipeline'y ETL i doświadczenie w dziesiątkach migracji. Jeśli po drugiej stronie ktoś nie odpisuje na pytania, odkłada UAT i nie przychodzi na demo — projekt dostarczysz, ale nie taki jaki mógłby być. Działa to w obie strony.
Ten wzór dotyczy obu stron: wykonawcy i klienta. W projektach danych jakość końcowego wyniku zależy tyle od kodu i architektury co od tego czy klient wie czego chce, jest dostępny i podejmuje decyzje na czas.
Co to znaczy w praktyce projektu danych
Wykonawca wnosi:
Metodyki ETL, znajomość narzędzi BI, doświadczenie z podobnymi projektami, wiedza o typowych problemach z jakością danych.
Klient wnosi:
Znajomość własnych procesów biznesowych, historia systemu, wiedzę o wyjątkach i zasadach które nigdzie nie są zapisane — tylko w głowach ludzi.
Wykonawca wnosi:
Budowa pipeline'ów ETL, modelowanie danych, tworzenie dashboardów, diagnozowanie problemów z jakością danych w czasie rzeczywistym.
Klient wnosi:
Umiejętność weryfikacji wyników (UAT), komunikowanie wymagań, szybkie podejmowanie decyzji o priorytetach, dostęp do właściwych osób w organizacji.
Wykonawca wnosi:
Proaktywne sygnalizowanie problemów zanim staną się kryzysem, transparentność w komunikacji, regularny kontakt bez czekania aż klient zapyta o status.
Klient wnosi:
Dostępność do rozmów, szybkie odpowiedzi na pytania, gotowość do uczestnictwa w demo i weryfikacji wyników, decyzyjność zamiast odkładania na "po kwartale".
Dwa scenariusze — jeden projekt
Ten sam zakres, ten sam zespół, ten sam budżet. Różnica: postawa obu stron.
Niska postawa obu stron
Warsztat wymagań odwołany dwa razy. Odbywa się w okrojonym składzie — bez osoby która zna system od środka. Wymagania są szkicowe.
Pytania czekają na odpowiedź 3–5 dni. Każde opóźnienie blokuje kolejny etap. Sprint który miał trwać tydzień trwa trzy.
Demo — nikt nie przychodzi albo ktoś jest nieprzygotowany. Feedback: "wygląda ok, zobaczymy po uruchomieniu". UAT bez weryfikacji to nie UAT.
Go-live. Użytkownicy końcowi widzą system po raz pierwszy i mają listę uwag. Część wynika z wymagań nigdy nieprecyzyjnie zdefiniowanych.
Klient niezadowolony. Wykonawca tłumaczy że "robił zgodnie z ustaleniami". Obie strony mają rację — i obie przegrały.
Wysoka postawa obu stron
Warsztat odbywa się raz, z osobą która zna dane od środka. Wymagania są konkretne — wiadomo co wchodzi w zakres, a co nie.
Pytania wracają tego samego dnia. Projekt idzie rytmem — nie stoi w kolejce na decyzję. Sprinty kończą się zgodnie z planem.
Na demo przychodzi ktoś kto rozumie dane. Feedback jest konkretny: "to pole mapuj inaczej, tutaj brakuje filtra". Problemy wychodzą wcześnie — nie na produkcji.
Go-live bez niespodzianek. Użytkownicy widzieli system w trakcie projektu. Wiedzą czego się spodziewać — bo współtworzyli wymagania.
Projekt zamknięty w terminie. Obie strony wiedzą co dostarczyły. Klient wróci z kolejnym projektem.
To nie jest wina złego wykonawcy ani złego klienta. To wynik braku zrozumienia że projekt IT to wspólna praca — nie usługa gdzie jeden podmiot dostarcza a drugi odbiera.
Postawa to nie deklaracja — to konkretne zachowania
Nie prosimy klientów o codzienną obecność. Projekt nie powinien być kolejnym obowiązkiem zarządczym. Chodzi o coś konkretnego i proporcjonalnego.
Czego oczekujemy od klienta
- ✓1–2 godziny na warsztat wymagań na starcie
- ✓Odpowiedź na pytania w ciągu 24 godzin (nie tygodnia)
- ✓Uczestnictwo w demo po każdym sprincie (30–45 min co 2 tygodnie)
- ✓Dostęp do osoby która zna dane od środka — nie tylko do managera projektu
- ✓Decyzje o priorytetach podejmowane na bieżąco, nie po miesiącu
Co gwarantujemy po naszej stronie
- ✓Regularne demo wyników — nie "dostarczymy na końcu"
- ✓Proaktywna komunikacja problemów — nie czekamy aż klient zapyta
- ✓Jasne raportowanie statusu bez korporacyjnego żargonu
- ✓Sygnalizowanie ryzyk zanim staną się problemem
- ✓Pytamy o kontekst biznesowy — nie budujemy w próżni
Dlatego używamy tych narzędzi
Metodyki które stosujemy nie są biurokratycznym rytuałem — każda z nich jest bezpośrednią odpowiedzią na ryzyko braku zaangażowania.
MoSCoW — bo "wszystko jest ważne" to brak decyzji
Wymusza od klienta wspólne ustalenie priorytetów na starcie. Bez tego każda zmiana w trakcie projektu jest "pilna" i każde opóźnienie jest "nieoczekiwane".
SMART — bo "dane mają być poprawne" to nie wymaganie
Precyzyjne wymagania wymagają czasu obu stron na starcie. Oszczędzają go wielokrotnie w trakcie i eliminują spory przy odbiorze.
Scrum — bo "zobaczymy na końcu" to za późno
Sprinty i regularne demo budują właściwą postawę obu stron w stałym rytmie — i pozwalają korygować kurs zanim błąd urośnie do rozmiarów problemu.
Trójkąt projektowy — bo jakość to wypadkowa decyzji obu stron
Czas, koszt i zakres to zmienne które klient współkształtuje każdą decyzją w trakcie projektu. Jakość — ta czwarta zmienna — jest wynikiem wszystkich poprzednich.
Najlepsze projekty które zrealizowaliśmy miały jedno wspólne: klient był obecny i decyzyjny — nie zarządzał projektem za nas, ale nie znikał też na miesiąc. Ta równowaga jest trudna do opisania w kontrakcie. Ale kiedy ją widać — czuć ją w każdym sprincie.
FAQ
Co konkretnie oznacza właściwa postawa w projekcie IT? ▾
Czy postawa jest ważniejsza od wiedzy i umiejętności? ▾
Jak wygląda właściwa postawa po stronie QandA? ▾
Powiązane artykuły
Brzmi jak podejście które Ci odpowiada?
Zacznijmy od rozmowy — bez zobowiązań, za to z konkretnymi pytaniami o Twój projekt.
Umów rozmowę