Więcej tego samego nic nie zmieni

W ostatnich czasach obserwuję jeszcze większe niż dotąd specjalizowanie się zawodów. Lekarze już nie są po prostu lekarzami, a są specjalistami od konkretnych organów. Już nie idzie się do stomatologa, tylko w zależności od problemu, idzie się do chirurga-stomatologa w celu usunięcia zęba, a do higienistki stomatologicznej, aby oczyścić uzębienie z kamienia. Lekarz internista, po wywiadzie, wysyła nas do specjalisty, który bada nas pod kątem jedynie jego specjalizacji, nie zastanawiając się zbytnio nad tym, co może być przyczyną dysfunkcji organu i leczy skutki a nie przyczyny, gdyż jest to poza dziedziną jego wiedzy.

## Specjalizacja a podejście holistyczne
W branży IT, szef projektu może się wywodzić z innej grupy zawodowej niż IT, a jego specjalizacja polega na prowadzeniu projektów i wymaga się wręcz od kierowników projektów certyfikatów potwierdzających ich specjalizację. Testerzy już nie są po prostu testerami, tylko są testerami typu "black-box", funkcjonalnymi, automatyzującymi, manualnymi, itd. Takich przykładów można mnożyć mnóstwo. Zapominamy jednak o bardzo ważnym spoiwie, bez którego nie da się pójść do przodu. Chciałoby się powiedzieć: lekarzu – człowiek to jeden organizm a nie luźno połączone ze sobą organy; specjalisto IT, twój produkt działa tylko gdy wszystkie jego elementy ze sobą funkcjonują harmonijnie.

Pomimo niezaprzeczalnej logiczności powyższych stwierdzeń, podejście holistyczne wydaje się być coraz bardziej marginalizowane. Specjalistów ceni się wyżej niż tych, którzy wiedzą, jak działa harmonijna całość, co staje się nową specjalizacją. Ślepa wiara w automatyzację oraz procesy wytwórcze, powoduje, iż ludzie coraz bardziej przypominają maszyny. Sprawdzam co mam przypisane w "backlogu", koduję, "merguję", odznaczam, iż zrobione i przełączam się na inny "task", na spotkaniu odpowiadam na pytania i tyle. Jak nie ma błędów to jest dobra jakość, jak są, to trzeba je poprawić. Pracuję zgodnie z ustalonym procesem, gdy nic nie mam w "backlogu" – znaczy wolne i tak dzień za dniem.

Prawdziwa jakość, tą którą doceni klient (rynek), rodzi się jednak gdzie indziej, ja to nazywam zaangażowaniem, pasją, motywacją poszczególnych ludzi pracujących w projekcie. W uproszczeniu, oznacza to, iż to samo zadanie mogę wykonać tak aby było zrobione lub wykonać wyjątkowo, tak abym był z niego dumny a klient zachwycony. Żeby jednak wiedzieć o tym co może pozytywnie zaskoczyć klienta, należy zmienić podejście do pracy. Bez poszerzenia horyzontu, bez choćby znajomości specyfiki klienta, istoty problemu który rozwiązujemy, środowiska, w którym nasze rozwiązanie będzie wdrożone, nie jesteśmy w pełni wykorzystać swoich talentów. Sam proces tego nie zmieni, gdyż jest to atrybut osoby pracującej nad zadaniem.

W środowisku IT, programista może wykonać tą samą zmianę na kilka sposobów. o ile się angażuje i rozumie docelowy model działania swojej aplikacji, to jedyne co może go zniechęcić do tego, żeby nie iść drogą na skróty, jest wewnętrzna motywacja. Stan wiedzy oraz stan emocjonalny przekładają się bezpośrednio na jakość kodu, a w konsekwencji na jakość dostarczanego produktu. Pomijanie tego faktu przez kadrę zarządzającą wprawia mnie w zdumienie, szczególnie iż z branżą IT mamy do czynienia już ponad trzy dekady. w tej chwili jako remedium na te problemy pojawiają się różnego rodzaju udogodnienia dla pracowników. Często mają oni do dyspozycji pokoje gier, miejsca wypoczynku, inspirujące biura, wszystko po to, aby było im przyjemniej. To miło i bardzo to popieram! Jednak to co jest najważniejsze, wciąż pozostaje niezmienione. Wciąż poszukuje się rozwiązań w narzędziach, frameworkach, procesach, a nie tam, gdzie jest to najistotniejsze, czyli zgrana grupa, dobrze się komunikująca, pracująca z zaangażowaniem w projektach, grupa, której się chce. Menedżerowie i liderzy nie tworzą aktywnie ekosystemu promującego zmianę jakościową. Procesy projektuje się, żeby mieć źródła danych do KPI, ale jak często widziałeś KPI które mierzyło to: "aby pracować efektywnie 6 godzin dziennie (nie więcej) i dowozić projekty w krótszym czasie"? Ja bym tak chciał, a Ty nie? Zamiast tego skupiamy się na ważnych, ale nie najistotniejszych tematach i palimy czas, godziny i wzrasta frustracja. W pewnym momencie pracownicy coraz więcej czasu spędzają w pokoju gier niż przy pracy projektowej lub po prostu "są" w pracy.

## Specyfikacja wymagań
Nie będę tutaj przytaczał wszystkich możliwych sposobów na poprawę procesów wytwarzania oprogramowania, jednak chciałbym skupić się na jednym z fundamentalnych zagadnień, na którym możemy najwięcej zyskać. Chodzi mi o wymagania wobec tworzonego oprogramowania. Mamy dziś różne zaawansowane narzędzia do zarządzania nimi, śledzenia zmian, potrafimy automatycznie przekładać je na testy i kod, a choćby na rezultaty testów. Ale co z ich jakością? Nie chodzi mi o ich książkową poprawność, aby były SMART, itd., ale o to, aby były kompletne, aby odzwierciedlały to czego oczekuje ich późniejszy użytkownik albo wręcz, aby dostarczyły mu więcej niż się spodziewał, tak aby był pozytywnie zaskoczony.

Zacznę od "Użytkownika". Nie powinniśmy zakładać, iż użytkownik wie dokładnie czego chce. Podejście typu, "no to co mam zrobić", prowadzi co najwyżej do "wyciśnięcia" z użytkownika wymagań, ale będą one "wymęczone" a nie dobre. Użytkownik często wie co mu przeszkadza, ale nie ma pojęcia o możliwościach technologii, która może jego problem rozwiązać inaczej niż sądzi. Być może zamiast wypełniać na formularzu kilka pól bzdurnymi statusami, bo użytkownik nic nie wie na ich temat, ale musi je obligatoryjnie wypełnić, można je ukryć i zmienić ten atrybut na opcjonalny. Ale skąd on ma o tym wiedzieć, kto ma mu podpowiedzieć, iż jest też ten inny lepszy świat.

Intuicyjnie odpowiedź przychodzi sama, jest to przecież rola Analityka Biznesowego. To fakt, ale co o ile ten analityk nie zna się na technologii, a "biznes" wymaga, aby implementacja była jak najtańsza? Jak to zrobić, aby wymaganie miało szansę być dobre, a nie po prostu być? Tutaj pojawia się element "ludzki": człowiek, jego intelekt i chęć do wykonania zadania lepiej. o ile założymy, iż lider dostawy (czasami zwany też kierownikiem), jest osobą, której się chce i rozumie skąd się bierze jakość, proponuję najpierw skupić się na zmotywowaniu ludzi, pokazaniu im, iż można robić to samo lepiej i sprawniej. o ile wiemy, iż użytkownik czy klient nie wie dokładnie czego chce, iż jest wiedza w grupie naszych specjalistów, ale analityk biznesowy nie ma korzeni technologicznych, to można zastosować prosty algorytm:

1. Prosimy, aby analityk biznesowy, w porozumieniu z użytkownikiem oraz developerami i testerami napisał najlepsze w swoim życiu wymagania, trzeba dać mu na to chwilę czasu, nie za długą, ale taką, aby realistycznie dało się to zrobić (w chaosie komunikacyjnym wszystko zajmuje więcej czasu, czym więcej ludzi, tym większy chaos i więcej czasu)
1. W zależności od wielkości opisu (mam na myśli efektywny tekst nie liczbę stron z obrazkami), rozsyłamy dokument (czy też link do niego) do wszystkich uczestników, z prośbą o zapoznanie się z dokumentem i ustalamy termin spotkania pod nazwą Requirements peer review (nie meeting). Czas wyznaczony na spotkanie musi dać szansę jego uczestnikom na zapoznanie się z dokumentem. Spotkanie powinno być zaplanowane jako "krótkie", w zależności od wielkości materiału do przejrzenia, na przykład 15 minut (co w wielu sytuacjach będzie szokiem kulturowym).
1. Podczas spotkania na samym jego początku zadajemy "sakramentalne" pytanie, czy wszyscy zapoznali się z dokumentem i czy są gotowi do przeglądu. Należy się w tym momencie upewnić, iż dokument został przeczytany a nie tylko otworzony. o ile w tym momencie ktoś zgłosi nieprzygotowanie (zazwyczaj będzie to coś w rodzaju, przeczytałem ile zdążyłem, albo zapoznałem się w swoim zakresie), to grzecznie podziękujcie wszystkim za przybycie. Zapytajcie się nieprzygotowanych, kiedy będą gotowi. I od razu ustalcie termin drugiego spotkania. Jest to pierwsza lekcja dla wszystkich, iż nie ma sensu się spotykać na przegląd istotnego dokumentu, o ile nie wszyscy się z nim zapoznali.
1. Podczas gdy wszyscy potwierdzili, iż zapoznali się z dokumentem, wtedy grzecznie, stanowczo i konkretnie prosimy każdego z osobna, ile czasu im to zajęło. o ile dokument jest duży, a ktoś mówi, iż 5 minut, to zadajemy mu pytania w jaki sposób to zrobił, jak nas nie przekona, to znów przekładamy spotkanie, z tego samego powodu. o ile wszystko jest OK, to wiemy, ile czasu każdy poświęcił na przygotowanie się do spotkania i iż każdy się przygotował (przynajmniej deklaratywnie).
1. Przystępujemy do spotkania. Prowadzący instruuje, iż będzie jedynie przechodził przez punkty dokumentu i pytał o uwagi do nich i prosi o ich zgłaszanie w trakcie przeglądu.
Jeżeli dokument jest bardzo istotnej wagi, jest to na przykład tekst, który stanowi istotny załącznik do kontraktu, to warto każdy punkt przeczytać na głos, gdyż choćby błędy składniowe mogą być kluczowe, a wymaganie nie powinno pozostawiać pola do interpretacji.
1. Teraz następuje magia, na początku moderowana przez lidera. Zadaje pytania, pyta o szczegóły implementacyjne czy je dobrze rozumie (np. parafrazując i zadając pytania: czyli w praktyce będzie to działać tak i tak, dobrze rozumiem?), pokazując przy okazji uczestnikom o co w tym spotkaniu chodzi. Gwarantuję, iż za chwilę pojawią się inne pytania, wyjdą niespójności w zrozumieniu, pomimo tego, iż każdy uczestniczył w przygotowaniu dokumentów. Bardzo istotnym jest zaangażowanie klienta, ale choćby z samym analitykiem biznesowym da się to zrobić.

Podczas tego spotkania, wszystko co nie zostało poprawione w czasie jego trwania (warto mieć jedną osobę, która zmienia dokument podczas spotkania i warto, aby nie był to prowadzący), jest dokumentowane jako defekt (tak samo jak bug software’owy) przypisany do konkretnej osoby.

Bardzo ważne jest, aby lider spotkania dbał o otwartą atmosferę, aby wszyscy poszukiwali błędów a nie oskarżeń innych. W tym momencie jakość wymagań będzie w dużej mierze zależeć od atmosfery, postawy uczestników oraz jasnego celu spotkania. Ucinamy też wszystkie rozmowy prowadzone nie na temat, o ile zdarzy nam się otworzyć tzw. "puszkę Pandory", to zapisujemy to jako defekt i przechodzimy dalej, nie przedłużamy, o ile nie da się tematu zamknąć na spotkaniu. Istotnym jest, aby uczestniczy zrozumieli, iż mają okazję zaadresować wszystkie swoje uwagi, iż będą one wysłuchane i uwzględnione. Wtedy ten dokument staje się nośnikiem informacji, dziełem wspólnym a nie analityka biznesowego, podnosi to też motywację, gdyż będziemy dostarczać coś co ma sens. Dodatkowo, spotkanie na temat, z odpowiednią dynamiką, dotyczące konkretów, nie będzie postrzegane jako dodatkowy narzut biurokratyczny, ale stanie się efektywnym narzędziem.

Ostatecznie, po przejrzeniu dokumentu ustalamy, iż obowiązuje nowa wersja wymagania z naniesionymi poprawkami. o ile nie ma innych defektów (rzadko się to zdarza), to aprobujemy wersję jako źródło wymagań i możemy przejść do kolejnej fazy dostawy.

Jeżeli znajdziemy defekty, to ustalamy czy po poprawieniu ich chcemy jeszcze raz się spotkać i wspólnie przejrzeć dokument (zazwyczaj tak się dzieje, gdy jest sporo defektów wymagających istotnego przeredagowania). Natomiast, o ile błędy są proste do implementacji, możemy się umówić na zaaprobowanie materiału elektronicznie bez konieczności odbywania kolejnego spotkania.

Pierwsze spotkania będą trudniejsze i dłuższe niż planowaliśmy, ale przy doświadczonym liderze, organizacja gwałtownie się nauczy jak się organizować. Dla tych, którzy lubią teorię, proponuję zapoznać się z metodą Fagana: [https://en.wikipedia.org/wiki/Fagan_inspection](https://en.wikipedia.org/wiki/Fagan_inspection)

## Kluczowa jest motywacja
Zachęcam do eksperymentowania i aplikowania wydajnych procesów wraz z motywacją uczestników. Metoda, którą pokazałem znacząco usprawni pracę, ale o ile Twoi ludzie są w trakcie poszukiwania innego miejsca pracy, bo u Was się nie da wytrzymać, to żadna metoda nie zmusi ich do wysiłku intelektualnego. o ile ludzie się nie utożsamiają z tym co robią, to tracimy wszystko i cieszymy się z dostarczenia ochłapów. Przeglądy się odbędą, ale problemy pozostaną, kod powstanie, ale będzie kiepski, deadline’y będę dotrzymane, ale produkt będzie nędzny. Dlatego biję na alarm do liderów, menedżerów, decydentów, skupcie się na ludziach, na ich motywacji, na pracy do wykonania i nie palcie czasu w niepotrzebne spotkania lub przychodzenie do pracy po to, aby być. o ile ludzie nie wiedzą co mają robić, po co i w czym uczestniczą, to czują się jak trybiki w maszynie. I nic tego nie zmieni, żadne spotkania integracyjne, motywacyjne przemowy, projekty wewnętrzne, a w szczególności metody stosowane przez HR, które są odbierane jak kiepski żart. Trzeba sięgnąć do źródeł ludzkiej motywacji, która aby była skuteczna i długotrwała musi wypływać z nich samych, Wasza rola to dać im szansę.