Analiza to super sprawa, o tym wie każdy, kto miał z nią styczność i kręcą go takie rzeczy. “Wyciąganie” z ludzi czegoś, czego nie wiedzą że powinni powiedzieć, analizy tony dokumentów, pisanie wielostronicowych opracowań zdobytej wiedzy i spędzanie wielu godzin nad idealnym ułożeniem strzałeczek w diagramie (bo przecież kształt, wielkość i ułożenie strzałki jest najważniejsze dla zrozumienia modelu, prawda?! 😉 ).

Ale są też chwile, gdy każdy z nas zapędził się za bardzo, zakręcił w analizach, uwierzył użytkownikowi, przegapił jakiś dokument, nie dopytał, zlekceważył “czerwone światełko” w głowie itd. I następuje….. fuck’up. 

Zapraszam na fuck’up confession!

“niepodjęte netto”

Dawno dawno temu ;), otrzymałam jedno z pierwszych samodzielnych zadań – miałam dokonać specyfikacji założeń do modułu związanego z wypłatą świadczeń określonej grupie odbiorców.

Zadanie to było na prawdę spore, nie była to pojedyncza funkcjonalność czy modyfikacja czegoś, co już działa, tylko przygotowanie założeń do stworzenia całego nowego modułu. Zaczynaliśmy (to znaczy ja z zespołem developerów) z tak zwaną carte blanche – proces ten nie był obsługiwany wcześniej systemowo, więc szykowaliśmy założenia od podstaw.

W czasie przeprowadzenia analizy miałam bezpośredni kontakt  z  interesariuszami i z użytkownikami końcowymi: z użytkownikami, którzy mieli wprowadzać dane do systemu; z tymi, dla których dane były najważniejsze (czyli odbiorcy świadczeń) oraz z grupami użytkowników, które korzystały z tych danych – czyli rozliczenia, księgowość, finanse itd. Zespół developerski był także zaangażowany w cały proces i na bieżąco robiliśmy burze mózgów, dyskutowaliśmy nad pozyskanymi informacjami tak, by powstający produkt był jak najlepszy i zgodny z wymaganiami.

Wszystko szło całkiem sprawnie: analiza przebiegała pomyślnie, proces biznesowy “as is” i “to be” powstawał, użytkownicy byli (“w miarę”) zaangażowani (chociaż nie należeli do najłatwiejszych rozmówców;) ). Korzystałam z wielu opisywanych w literaturze tak zwanych technik zbierania wymagań (nawet nie zdając sobie sprawy z ich fachowych nazw, bo zawsze byłam bardziej praktykiem niż teoretykiem) – warsztaty, spotkania robocze, obserwacja w terenie i analiza dokumentów. Zarządzenia, procedury, instrukcje były źródłem ogromnej wiedzy dotyczącej założeń obsługi tego procesu. Jednak dla mnie zawsze największą wartość mają dokumenty, które są produktem procesu (wyznaję niepisaną zasadę “Powiedz mi co chcesz wygenerować, ja będę wiedzieć co musimy ustalić, byś mógł to zrobić“).

Jednym z produktów procesu miał być zestaw dokumentów księgowych umożliwiających sprawne zaksięgowanie wypłat świadczeń i ich rozliczenie “do zera”. “Rozliczenie do zera” oznaczało w dużym skrócie: “suma przyznanych=wypłacone-nieodebrane”. Analizując dokumenty księgowe, mówiące o świadczeniach nieodebranych, zobaczyłam pozycję “niepodjęte netto“. W całym raporcie (wyglądającym jak jakieś “tysiąc pińcet” różnych komórek z przeróżnymi kwotami), była to jedna z komórek w podsumowaniu kolumny. Zgodnie z moją zasadą “kto pyta nie blondzi” (proszę nie oburzajcie się za określenie, ja sama jestem naturalną blondynką;) ), poszłam do księgowości do przemiłej starszej pani, która od lat siedziała w tym temacie, i zapytałam co to jest “niepodjęte netto”. To pani uprzejmie i wyjaśniła (wskazując przyniesiony przeze mnie wydruk), że “Na tym raporcie, to jest ta wartość w trzecim wierszu od dołu, druga kolumna od prawej”.

Starałam się oczywiście dalej pytać: skąd ta kwota się bierze, co dalej się z tym dzieje, czy ta wartość jest do czegoś potrzebna itd. Uprzejma Pani powiedziała, że ona “tą kwotę wpisuje potem tam do innego programu i księguje i tyle. I że przecież ta kwota wynika z niewypłaconych świadczeń. Dowidzenia.” Nie myślcie że odpuściłam tak łatwo 🙂 Wracałam do niej kilka razy, ale Pani była nieugięta i na pytanie co to jest “niepodjęte netto” po prostu wskazywała to pole palcem i mówiła “no przecież to to!”. Byłam nawet u jej szefowej (księgowy Szef Wszystkich Szefów) z tym pytaniem, ale byłam przekierowywana do Uprzejmej Pani, bo to ona zajmuje się tymi świadczeniami i tylko ona wie co tam jest potrzebne:) Pytałam swojego szefa, dyskutowaliśmy w zespole. I wiecie co? Odpuściliśmy. Postanowiliśmy ogarnąć utworzenie raportu z nieszczęsną wartością kryjącą się w określeniu “niepodjęte netto” tak jak to zrozumieliśmy z lakonicznych wypowiedzi Uprzejmej Pani i Księgowego Szefa Wszystkich Szefów i ruszyliśmy do przygotowywania systemu i generowanych z niego raportów. Na usprawiedliwienie dodam, że mieliśmy świadomość braków w specyfikacji, ale postanowiliśmy przygotować coś w stylu “produkcyjnego prototypu”, czyli wypuścić na produkcję pierwszą wersję modułu i poczekać na reakcje biznesu. Zadanie i tak musieliśmy zrobić, więc była to na tamtą chwilę jedyna droga działania.

Minęło parę tygodni/miesięcy. System ruszył, wytworzyliśmy instrukcje, odbyły się szkolenia, pierwsze przyznawanie świadczeń przebiegło pomyślnie…. ale po pierwszej wypłacie świadczeń, realizowanej w nowym systemie, dostaliśmy telefon z księgowości – “gdzie jest niepodjęte netto”?

Rozpisywanie się nad dalszymi szczegółami nie jest istotne, ale skutkiem tego telefonu było (wreszcie!!) konkretne wyjaśnienie przez Księgowość SKĄD BIERZE SIĘ TA WARTOŚĆ i.. odkrycie (skutecznie ukrytego wcześniej) procesu, który ogólnie mówiąc, dotyczył zarządzania świadczeniami, które nie zostały odebrane w terminie. Procesu na tyle krytycznego, że de facto okazało się konieczne przebudowanie prawie całego tworzonego modułu. Zmiana kluczowych założeń, doprecyzowanie wymagań, zmiany w sposobie rozliczania i księgowania świadczeń. To był taki kamyczek, który uruchomił lawinę i skończyło się na drugiej wersji modułu, z kompletnie innymi założeniami rozliczeń, skorzystaniem z innych mechanizmów księgowania itd. Druga wersja tego modułu funkcjonuje po dziś dzień i była na bierząco rozwijana o nowe funkcjonalności. Podstawowe założenia z v2 przetrwały 🙂

Taka refleksja..

Traktuję tą sytuację jak fuck’up, gdyż efektem tej jednej jedynej źle wyspecyfikowanej wartości “niepodjęte netto” była konieczność zmiany podstawowych założeń modułu. Być może, gdybym wtedy nie odpuściła i odmówiła dalszego specyfikowania bez wyjaśnienia tej wartości, nie było by tej sytuacji i wdrażalibyśmy “produkcyjnego prototypu”. Być może już wtedy okazałoby się, że powinniśmy zaopiekować jeszcze jeden duży obszar związany z obsługą w czasie (tzn w kolejnych miesiącach) nieodebranych w terminie świadczeń. Być może gdybym więcej pytała, była bardziej dociekliwa (upierdliwie dociekliwa;) ), nie bała się przyznać, że mimo wielu ogólnych informacji ze strony biznesu – nadal nie otrzymałam precyzyjnego wyjaśnienia “co to jest i do czego służy”, w końcu pozyskałabym konkretną wiedzę.

Być może. Ale może nie, może produkcyjny prototyp był w tamtym czasie i w tym otoczeniu biznesowym niezbędny, by między innymi uświadomić Księgowości problemy z zaksięgowaniem świadczeń i skłonić do zmiany sposobu rozliczeń. I być może tylko dzięki temu mogliśmy jeszcze raz sprawdzić działanie poszczególnych obszarów, skonsultować je z odbiorcami, dokonać usprawnień i w efekcie wypuścić wersję działającą skutecznie po dziś dzień.

Ta sytuacja nauczyła mnie jeszcze jednej rzeczy. To mit, że użytkownicy nie wiedzą czego chcą, a my analitycy, na wzór rycerzy na białym koniu, przybywamy im na ratunek i “uświadamiamy nieuświadomione”. To oni są specjalistami w swojej dziedzinie, my nie znamy tak doskonale obszaru, w którym oni się poruszają codziennie. Szanujcie swoich rozmówców i jeśli swoją percepcją nie rozumiecie ich tłumaczeń, to starajcie się wczuć w ich potrzeby, jak najbliżej poznać zagadnienie by dotrzeć do sedna. Nie możemy pozwolić sobie na myślenie, że “wiemy lepiej” i “nie słuchajmy ich, sami to ogarniemy”. Zawsze starajmy się ich wysłuchać, wydobyć potrzebne informacje, poznać potrzeby, poznać dziedzinę, PYTAĆ! i nie zrażać się, jeśli użytkownik ma problem z wyjaśnieniem. Nie odpuszczajmy, wracajmy do niewyjaśnionego tematu, szukajmy innych rozmówców, szukajmy odpowiedzi aż sami nie poczujemy, że “ogarniamy”. Przecież Uprzejma Pani doskonale wiedziała skąd bierze i do czego potrzebuje wartości ‘niepodjęte netto”. Czyli ona wiedziała Czego Chce. Ona po prostu nie wiedziała jak to wyjaśnić.

Na koniec wam powiem, że case “niepodjęte netto” był jednym z najważniejszych wydarzeń, mającym wpływ na to jak teraz podchodzę do użytkowników, analizy i zbierania wymagań.

ps: przedstawiłam ten case dość powierzchownie i skupiłam się najbardziej na problemie nieprecyzyjnie wyspecyfikowanej wartości w raporcie, gdyż to wydawało mi się najistotniejsze. W prezentowanym przykładzie było jeszcze kilka zdarzeń, które spowodowały potrzebę wytworzenia drugiej wersji modułu.