SygnITy Expert
Każdy, kto choć raz uczestniczył w projekcie IT, zna ten moment. Spotkanie projektowe, pełna sala, a na ekranie prosty szkic. Klient z błyskiem w oku mówi: „My tylko chcemy, żeby na mapce było widać, gdzie są nasze rury. Ma być prosto.” I w tym momencie zaczyna się opowieść. Bo już kilka spotkań później okazuje się, że mapa ma nie tylko pokazywać rury, ale powinna też:
- liczyć zużycie wody
- automatycznie generować faktury
- integrować się z TERYT
- wysyłać e-dokumenty przez ePUAP
- a przy okazji powiadamiać SMS-em kierownika brygady, że ekspres w pokoju socjalnym przygotował kawę
Wymagania rządzą się własną biologią, rodzą się w chaosie, dojrzewają w nieoczekiwanym kierunku i rzadko przypominają pierwotny organizm. Analityk balansuje między „to ma być proste” a „to ma robić wszystko”.
Spotkanie otwierające. Na ekranie wyświetla się mapa.
„Tu hydranty, tu zasuwy, tu studzienki. I żeby można było kliknąć i zobaczyć dane.”
Wszyscy kiwają głowami. Przecież to oczywiste, prawda?
Z pozoru wszystko jasne. Aż padają kolejne dopowiedzenia:
„I żeby było widać, które obiekty są w eksploatacji.”
„I żebyśmy mieli raport, ile hydrantów jest w przeglądzie.”
„I żeby działało zdalnie, ale offline też.”
Każde „i żeby” w głowie Klienta „to tylko jeden przycisk więcej” a dla zespołu dodatkowe 40rbh.
Następnie analityk musi zadać pytanie: „A kto dokładnie ma z tego korzystać i w jakim celu?”
Odpowiedź na nie, odsłania fundamentalną prawdę o tym, że różne działy w tej samej firmie patrzą na to samo narzędzie przez zupełnie inne pryzmaty:
- Dział techniczny potrzebuje mapy roboczej do codziennych napraw i konserwacji.
- Dział inwestycji widzi w tym narzędzie do planowania remontów i rozwoju sieci.
- Dział administracji oczekuje dostępu do dokumentacji technicznej i historii obiektów.
- Zarząd chce przejrzystych raportów i wskaźników efektywności.
Moment, w którym każdy z działów widzi w mapie coś innego to nie jest problem, który trzeba ukryć. To jest kluczowe odkrycie. Lepiej dyskutować o tym teraz niż spierać się o to na produkcji.
I tak wymaganie „chcemy prostą mapę z rurami” przestaje być wymaganiem, a staje się projekcyjnym testem Rorschacha, gdzie każdy widzi w nim to, co chce zobaczyć.
Dla wykonawcy systemu prawdziwym wyzwaniem staje się nie utworzenie mapy, ale zaprojektowanie narzędzia, które rozwiąże rzeczywiste problemy wszystkich interesariuszy.
Po pierwszych warsztatach klient, który na początku z nieśmiałością mówił „chcielibyśmy, aby na naszej mapce oprócz rur, było coś jeszcze”, nagle odkrywa potencjał technologiczny. To właśnie w tej fazie dochodzi do fundamentalnej zmiany sposobu myślenia: z użytkownika pasywnego staje się wizjonerem cyfrowej transformacji.
Proces przypomina ekspansję potrzeb, im więcej możliwości system oferuje, tym więcej oczekiwań budzi. Z perspektywy teorii zarządzania produktem jest to naturalna faza dojrzewania wymagań, w której abstrakcyjne pomysły zaczynają krystalizować się w konkretne funkcje, ale jednocześnie rozgałęziają się w niespodziewanych kierunkach. To już nie „chcielibyśmy”, tylko „system POWINIEN”:- „System powinien automatycznie rozpoznawać lokalizację”.
- „System powinien inteligentnie generować raport”.
- „System powinien natychmiast wysyłać go do kierowników działów”.
Dla analityka biznesowego i menadżera projektu to bardzo ważny moment, ponieważ zbyt wczesne ograniczenie wizji klienta zabija innowację, ale zbyt swobodny rozwój wymagań może sparaliżować projekt. Sztuka polega na tym, by być przewodnikiem, który pomaga klientowi odkryć, czego naprawdę potrzebuje, bez gubienia się w chaosie możliwości.
Pojawia się kolejne fundamentalne pytanie, które niczym grawitacja sprowadza wizje z powrotem na ziemię: „A co będzie, jeśli…”- użytkownik nie dokończy procesu?
- dane będą niepełne?
- synchronizacja opóźni się o 30 sekund?
- zabraknie połączenia w momencie zapisu?
- dwóch użytkowników edytuje ten sam rekord?
Każde „a co, jeśli” to kolejny moduł obsługi błędów, kolejna warstwa zabezpieczeń, kolejna rozbudowa. Te pytania to nie przejaw pesymizmu to inżynieria ryzyka. W praktyce właśnie takie scenariusze ujawniają się dopiero po wdrożeniu, gdy użytkownicy napotykają sytuacje, o których nikt na etapie projektowania nie pomyślał.
A klient? Klient zaczyna dostrzegać możliwości poza pierwotną wyobraźnią:
- „Skoro system wie, gdzie są rury, to niech sugeruje optymalną trasę dla ekipy…”
- „A jak sugeruje trasę, to niech rezerwuje potrzebne części z magazynu…”
- „A jak rezerwuje części, to niech automatycznie wystawia zamówienie do dostawcy…”
- „A jak wystawia zamówienie, to niech śledzi status dostawy i powiadamia brygadzistę.”
Po tygodniach pracy gotowa jest pierwsza wersja systemu. Pełen entuzjazm. Interfejs działa. Dane są. Mapa się renderuje. Wszystko zgodnie ze specyfikacją. Prezentacja. Klient patrzy na ekran. Cisza… A potem pada: „Hmm… to wygląda zupełnie inaczej niż myślałem.”
To kluczowy moment w psychologii projektów IT. Dopóki system istnieje tylko w wyobraźni i dokumentacji, każdy widzi go inaczej. Ale gdy prototyp materializuje się na ekranie, złudzenie pęka. Wszyscy patrzą na ten sam system i okazuje się, że nie wygląda to do końca tak, jak każdy oczekiwał. Ktoś zauważa: „Mapa ładuje się 0,3 sekundy za długo.” A mapa ładuje się w 0,9 sekundy, a jest to doskonały wynik przy tej ilości danych. Ale percepcja to nie matematyka.Zaczyna się lawina szczegółów, o których nikt nie wspomniał przez 12 tygodni warsztatów:
- „Czy nie mogłaby działać szybciej?”
- „Może dodać jeszcze jeden kolor?”
- „Koniecznie tryb ciemny!”
- „To po co ten przycisk „Zapisz”? Myśleliśmy, że to będzie automatycznie.”
- „A da się to jakoś… bardziej wow?”. Niestety definicja „wow” pozostaje tajemnicą.
Testy to nie tylko szukanie błędów, ale i moment, gdy abstrakcyjny „system” staje się konkretnym „tym przyciskiem, który muszę kliknąć, żeby zrobić swoją robotę”.
Wypływają na powierzchnię nieuświadomione założenia:
- Że użytkownik będzie miał mysz (a nie touchpad w laptopie)
- Że będzie wiedział, co to „warstwa wektorowa” (nie będzie)
- Że przeczyta instrukcję (nie przeczyta)
Gdy projektujemy system w teorii, wyobraźnia podsuwa nam optymistyczny scenariusz: spokojny i opanowany użytkownik, który dysponuje kompletnymi danymi, posiada stabilne łącze internetowe oraz wszystko działa mu za pierwszym razem. Ale rzeczywistość bywa zgoła inna: użytkownik jest zestresowany, posiada niepełne dane, połączenie internetowe się zrywa, telefon mu dzwoni, gdzieś z boku szef nalega, a system właśnie pokazał komunikat „Nieznany błąd o kodzie: 0x80070005″.
System z prostego narzędzia przekształca się w platformę zarządzania światem. Klient redefiniuje „chcemy prosto” na „chcemy nowocześnie, w chmurze, w aplikacji mobilnej”. Bo zobaczenie działającego prototypu uruchamia nowy tryb myślenia. Dopiero teraz klient naprawdę odkrywa, czego chce.
Rzeczywistość pokazuje, że ponad połowa problemów wykrytych podczas testów nigdy nie pojawiła się w dyskusjach o wymaganiach. A wiele wymagań zmienia się po pokazaniu pierwszego działającego prototypu. W głowach zespołu rodzi się pytanie: „Czy my jeszcze robimy ten sam projekt?” Spoiler: nie… Już dawno nie.Miesiące analiz, warsztatów, testów, poprawek, testów i kolejnych poprawek. Wreszcie czas na wdrożenie produkcyjne. Klient loguje się. System działa. Raporty się generują. Mapa renderuje się w 0,5 sekundy. Użytkownicy klikają przyciski. Dane się zapisują. Cisza, ale to ta dobra cisza. Nic nie „wybuchło”, nikt nie dzwoni z krytycznym błędem, serwery nie płoną.
PM płacze z radości. Testerzy otwierają szampana, ale bezalkoholowego, bo to środa.Programiści rezerwują urlopy.
Analityk archiwizuje 136 plików o nazwie „wymagania_FINAL_v2_1_poprawione_OSTATECZNE_final3.docx”.
I właśnie wtedy dzwoni Klient:
„Kiedy możemy zacząć prace nad wersją 2.0?” Bo, teraz gdy system działa, klient widzi kolejne możliwości.
System w produkcji to nie dziecko, które się wychowało i w końcu nadchodzi czas na jego wyprowadzkę. To dziecko, które zostaje w domu, wymaga kolejnych pokoi, nowych zabawek, i co chwilę mówi „tato, mamo chcę …”.
Tak, tylko nie od razu. Proces analizy wymagań to jak wspólne układanie puzzli bez obrazka na pudełku. Najważniejsze elementy pojawiają się dopiero w trakcie pracy, a kluczowe potrzeby ujawniają się przy pierwszym kontakcie z realnym systemem.
Najlepsze systemy rodzą się z rozmów, testów, krytycznych pytań i odrobiny dystansu a nie tylko z dokumentów, natomiast prawdziwy sukces projektu IT to nie wierne odtworzenie specyfikacji, lecz stworzenie rozwiązania, które naprawdę odpowiada na codzienne wyzwania użytkowników. I wtedy, gdy klient powie Ci: “Tak, właśnie o to mi chodziło” wiesz, że zrobiliście razem coś wartościowego.