Tworzenie oprogramowania nie rozpoczyna się od napisania pierwszej linijki kodu. Za punkt startowy nie należy nawet uznawać zaprojektowania architektury czy interfejsu. Tak naprawdę projekt zaczyna się w momencie, kiedy dowiadujemy się o nim czegoś więcej i rozpoczyna się etap zbierania wymagań. Celem tego procesu jest zgromadzenie i przeanalizowanie bardziej szczegółowych wytycznych dotyczących nie tylko tego, jak system ma się zachowywać, ale przede wszystkim jaki jest kontekst biznesowy, w jakim będzie działać oprogramowanie oraz co tak naprawdę jest w nim najważniejsze, czyli cel biznesowy do spełnienia. Taka analiza (przez niektórych nazywana audytem, ale przyznaję, że nie pasuje mi to określenie akurat w tym przypadku) skutkuje lepszym poznaniem oczekiwań klienta oraz trafniejszym wyspecyfikowaniem wymagań, co pozwala potem stworzyć odpowiedni dokument. Jednak niezależnie od tego, jak starają się obie strony (zarówno software house, jak i zleceniodawca), zawsze pozostaną niedopowiedzenia, które zostaną odkryte dopiero na dalszym etapie.

Roboczo nazywam to ukrytą wiedzą dziedzinową, która może przybierać różne formy, ale zawsze jest zaskoczeniem dla wszystkich zaangażowanych osób, choć z różnych powodów. Dzisiaj porozmawiamy o tym zjawisku.

Czym jest ukryta wiedza dziedzinowa?

Aby to dobrze wyjaśnić, muszę odnieść się do przykładu. Być może trochę uproszczonego, ale jak najbardziej występującego w rzeczywistości.

Wyobraźmy sobie projekt systemu dla motoryzacyjnego zakładu produkcyjnego. Są tam wytwarzane i montowane samochody, motocykle, a także inne pojazdy oraz części do nich. Oprogramowanie ma wspomagać wiele rzeczy, a jedną z nich jest harmonogram produkcji. Hale zawierają wiele maszyn, dostępna jest pewna pula pracowników, ale jest też dużo zleceń o różnych wymaganiach - trudno jest to wszystko zaplanować ręcznie, zwłaszcza w taki sposób, aby zasoby zakładu zostały optymalnie wykorzystane, żaden pracownik się nie nudził (i nie było nadmiaru ludzi), a jednocześnie zadbać o balans eksploatacji poszczególnych maszyn. Nowa aplikacja ma to ułatwić, proponując automatyczne propozycje grafiku prac - w skrócie sprowadzi się to do tego, która część zlecenia jest wytwarzana na danej maszynie w którym momencie. Oczywiście, w grę wchodzi równoległość zadań, uwzględnienie dat wykonania (tzw. deadline'ów) oraz warunki przy danych czynnościach (np. konieczność skorzystania z określonej maszyny lub kompetencje pracownika). Klient to wszystko cierpliwie tłumaczy software house'owi, ci drudzy zadają pytania doprecyzowujące oczekiwania i w końcu powstaje projekt rozwiązania, który po konsultacji jest realizowany.

Po pewnym czasie klientowi wraz z którymś sprintem oddawana jest początkowa wersja funkcji harmonogramu. Jest ona przedstawiana na spotkaniu, zespół programistów pokazuje przygotowane wcześniej scenariusze testowe, a klient weryfikuje funkcjonalność we własnym zakresie. I nagle pada pytanie od użytkowników zleceniodawcy: "a jak mogę przypisać dwie maszyny do jednej czynności lub jedną maszynę do dwóch czynności? Często tak robię.". Okazuje się, że ten wątek nie pojawił się podczas rozmów o wymaganiach dotyczących harmonogramu, a pracownicy rzeczywiście regularnie z tej sposobności korzystają, w ten sposób przyspieszając produkcję. Powstaje problem, gdyż taka zmiana wiąże się ze sporymi modyfikacjami algorytmu układającego harmonogram, a w dodatku klient nie do końca zgadza się z tym, że to coś, za co powinien dopłacić.

Każda komunikacja pomiędzy klientem a wykonawcą IT zachodzi w obie strony i polega między innymi na wymianie wiedzy i doświadczenia. Zleceniodawca ma tzw. wiedzę biznesową i wie bardzo dużo o dziedzinie, którą ma modelować system. Takie informacje potrzebuje software house, gdyż musi je "przetłumaczyć" na kwestie techniczne. Z kolei specjaliści od oprogramowania mają wiedzę techniczną i podczas rozmów mogą zaproponować inne, lepsze rozwiązania, z których klient nawet nie zdawał sobie sprawy. Co więcej, mogą czasem uświadomić drugą stronę, że dana kwestia jest niemożliwa do zrealizowania w sposób przewidywany przez użytkowników lub ta forma znacznie wykracza poza budżet. Wiele razy podczas rozmów z klientami w Wilda Software mieliśmy poczucie, że nie tylko dowiadujemy się czegoś nowego, ale i klient rozszerza swoją wiedzę na temat rozwiązań IT, gdyż przez lata żył w niewiedzy lub był przyzwyczajony do pewnego sposobu działania.

Natomiast musimy pamiętać o drugiej stronie medalu - dla każdej z tych stron są aspekty w ich dziedzinach, które wydają się oczywiste. To trochę tak, jakby specjalista od remontów powiedział "młodemu", że ma pierwszy raz zawiesić szafkę i wskazałby mu wiertarkę oraz pokazał, jak się wierci, który haczyk potem wkręcić, natomiast zapomniał powiedzieć o tym, że w ścianę wbija się kołek, w efekcie czego mebel spada na ziemię lub ściana jest w ruinie. W przedstawionym wyżej przykładzie dla przedstawicieli zakładu produkcyjnego było oczywiste, że zadania mogą być związane z więcej niż jedną maszyną i odwrotnie, natomiast nie przekazali tej wiedzy software house'owi, bo uznali, że to naturalne i szkoda czasu na wspominanie o tym. A jak widać, nie było to takie oczywiste, podobnie jak dla klienta nie byłoby oczywiste, że np. aplikacji webowej nie trzeba instalować na komputerze użytkowników (historia prawdziwa). Jest to coś, co nazywamy ukrytą wiedzą dziedzinową lub biznesową. Są to kwestie tak oczywiste dla jednej ze stron, że nie wspomina o nich (lub wspomina niedostatecznie dokładnie) drugiej stronie w nieuzasadnionej wierze, że jest to dla niej równie zrozumiałe.

Jak groźna jest ukryta wiedza?

Tak, jak pisałem, powyższy przykład jest nieco uproszczony, gdyż akurat taka kwestia jak podwójne wykorzystanie maszyn to rzecz na tyle ważna w harmonogramie, że ujawniłaby się podczas analizy. Nawet, jeśli nie podczas rozmowy, to podczas przeglądania przykładowych harmonogramów, walidacji testowego scenariusza czy wycieczki po fabryce i obserwacji pracowników (czasem praktykuje się takie rzeczy, tylko potrzebny jest przewodnik ze strony firmy, aby było to efektywne). Natomiast podobne przypadki się zdarzają i ich efekt może być różny.

Rzadko zdarza się, aby ujawnienie jakiegoś aspektu wymagało bardzo dużej refaktoryzacji, a jeśli już, to dzieje się to w początkowej fazie projektu, więc o taką modyfikację jest jeszcze stosunkowo łatwo. Dużo częściej fragment ukrytej wiedzy dziedzinowej powoduje:

• znaczne skomplikowanie algorytmu wykonującego obliczenia,
• modyfikacje schematu bazy danych,
• sparametryzowanie danego modułu,
• szukanie rozwiązania zastępczego.

Bywają też odwrotne sytuacje - w wyniku nadmiernej ostrożności software house założy zbyt dużą elastyczność i rozdzielenie od siebie obiektów, po czym okazuje się, że np. maszyna i urządzenie, stosowane w opowieści klienta i potencjalnie mające różne znaczenie w procesie biznesowym, są tak naprawdę tym samym, a prezentujący zwyczajnie stosował synonimy. Jest to lepsza sytuacja z punktu widzenia realizacji projektu IT, gdyż wymaga uproszczenia, a nie rozszerzenia, ale tutaj z kolei powstaje często kłopot zostawienia nieużywanej funkcjonalności lub niewykorzystanej tabeli w bazie danych, gdyż nigdy nie ma pewności, czy rozdzielenie w przyszłości nie będzie potrzebne. A skoro już nastąpiło w aplikacji, to następuje "zostawmy, może się przyda". Nie jest to chlubna praktyka, ale biorąc pod uwagę napięte terminy, niepewność dotyczącą wymagań i konstrukcję kodu, czasem ma to miejsce.

W ostatnim zdaniu wspomniałem o niepewności i to też aspekt ukrytej wiedzy, o którym warto pamiętać - to naturalne, że podczas omawiania planu projektu klient nie zawsze pamięta o wszystkim lub pewne potrzeby pojawiają się później. Stąd taka popularność metodyk zwinnych, które pozwalają radzić sobie z podobnymi sytuacjami poprzez rozwijanie i oddawanie oprogramowania w etapach. Tym niemniej, należy przygotować się na to, że nie wszystkie wymagania określone na początku zachowają swój poziom priorytetu aż do końca oraz że ta lista nie jest kompletna. Nawet przy odpowiednio elastycznej architekturze będą sytuacje, w których trzeba będzie przeprojektować lub rozszerzyć już napisane fragmenty oprogramowania.

Jak poradzić sobie z tym zjawiskiem?

Na początku trzeba powiedzieć jasno jedną, smutną rzecz. Niezależnie od tego, jak bardzo obie strony będą się starać, to nie ma idealnego sposobu na uniknięcie zjawiska ukrytej wiedzy dziedzinowej. Taka sytuacja może być rzadsza, a nawet szczęśliwie może też w ogóle nie wystąpić (np. w bardzo małych projektach), natomiast nie ma metody, aby przewidzieć wszystko na samym początku. Oznaczałoby to, że software house zaczynałby z wiedza o środowisku biznesowym równą lub większą od tej, którą posiada klient, a jest to niemożliwie do osiągnięcia poprzez szereg spotkań, wymianę maili i nawet najbardziej dokładne prototypy. Nawet jeśli przedstawiciele software house'u kupiliby książki z dziedziny, w której ma się poruszać aplikacja lub przeszliby odpowiednie kursy, to nigdy nie będą mieli takiego doświadczenia jak klient oraz informacji o wszystkich wewnętrznych procedurach obowiązujących w danej firmie. Bo wiadomo, że na to wszystko nakłada sie fakt, że w poszczególnych środowiskach pracy ludzie są przyzwyczajeni do określonego sposobu działania.

Dlatego tego zjawiska nie można się całkowicie pozbyć - można za to zminimalizować ryzyko jego wystąpienia i znaczenia. Jest na to kilka sposobów, które zostały wspomniane w tekście, ale warto je usystematyzować.

Pierwszą i najważniejszą sprawą jest podzielenie projektu na etapy i przejście na metodykę zwinną lub przynajmniej częściowo zwinną. W ten sposób w sytuacji, w której wystąpi przypadek ukrytej wiedzy dziedzinowej (a już pisaliśmy, że najczęściej pojawia się w początkowych fazach projektu i podczas walidacji przez klienta, co w agile jest częstsze), oprogramowanie nie będzie aż tak rozbudowane, przez co wprowadzenie ewentualnych zmian będzie prostsze. Nie zawsze jest to możliwe, ale na pewno daje to zwiększenie szans na prawidłową reakcję.

Drugą kwestią jest przygotowanie dobrych scenariuszy pokazujących przykładowe korzystanie z systemu. Nie mam tutaj na myśli ani prototypów (choć te również mogą być elementem scenariusza), ani typowych manualnych testów akceptacyjnych. Wiele razy zdarzało nam się, że dyskusja o jakimś module dochodziła do momentu, w którym obie strony nie do końca rozumiały nawzajem, co nie jest jasne. Wówczas warto zwyczajnie przygotować przykład i wizję, w jaki sposób będzie on obsługiwany w systemie, tj. gdzie należy nacisnąć i co się stanie po wprowadzeniu danych. W znakomitej większości przypadków już samo ułożenie przykładu pokazuje klientowi, czy software house dobrze pojął temat, a dodatkowo może ocenić proces użytkowania względem swoich (czasem niewyrażonych) oczekiwań. Ta technika jest pracochłonna, ale użyta w odpowiednich momentach przydaje się obu stronom, gdyż nawet przygotowywanie takiego dokumentu wymaga bardziej szczegółowej analizy i w ten sposób składania do zadania właściwych pytań. To również dobry sposób, gdy klient jest przyzwyczajony do jednego typu oprogramowania i ma trudności w pojęciu innej filozofii działania.

Przy tej okazji warto wspomnieć, że podobne dokumenty przygotowuje się w przypadku projektowania algorytmów, choć nie mają one wówczas formy scenariusza, a raczej pokazania krok po kroku, jak liczony jest dany przypadek, W ten sposób można uzgodnić zachowanie systemu dla ciekawych kombinacji danych, choć należy wspomnieć, że np. przy wspomnianym wcześniej szeregowaniu zadań produkcyjnych przygotowywanie takiego przykładu może być jeszcze bardziej czasochłonne. Tym niemniej, zazwyczaj opłaca się to w dłuższej perspektywie.

Trzecia technika to dobry, wręcz "przesadzony" pod kątem detali słownik terminów. Można to przyrównać do opisania obiektów biznesowych, jednak w bardziej szczegółowej formie, której przygotowanie sprawia, że niezbędne jest rozważenie wręcz każdego słowa i tym samym znalezienie przypadków szczególnych lub stwierdzenie, że tutaj nie występują. Ta metoda może zostać wykorzystana w specyficznych przypadkach, aby zorientować się, jak bardzo elastyczne obiekty musi założyć wykonawca IT, natomiast nie da się ukryć, że jest dość pracochłonna, wymaga dużej uwagi i dyskusji z obu stron (przypomina trochę "łapanie za słówka"), a na dodatek powinna być wykonana na początkowym etapie, kiedy tak naprawdę nie wiadomo jeszcze, gdzie pojawią się nieporozumienia. Tym niemniej, warto o tym wspomnieć, w szczególności przy osobach preferujących ścisłe podejście do tematu.

Czwarta metoda polega na wprowadzeniu trzeciej strony, a mianowicie konsultanta, który łączy w sobie wiedzę dziedzinową oraz techniczną. Jego pochodzenie może być różne - bywa, że jest to osoba zupełnie z zewnątrz, która na co dzień zarządza zespołami w danej branży lub jest naukowcem zajmującym się danym obszarem, ale może być to też osoba wyznaczona przez klienta, która ma stosunkowo dużą wiedzę techniczną. Jest to swego rodzaju przekaźnik pomiędzy obiema stronami (stanowiącymi nadal jeden zespół), który w niektórych przypadkach szybciej zidentyfikuje sedno problemów i potencjalne nieporozumienia. Jest to też osoba bardzo pomocna przy przekonywaniu firmy o tym, jak aplikacja może zmienić ich sposób funkcjonowania na lepsze, ale także poinformować wykonawcę IT o tym, co w praktyce będzie stanowiło trudność dla zleceniodawcy. Niestety, wadą jest to, że zatrudnienie takiej osoby zazwyczaj kosztuje niemało, a ponadto nawet człowiek znający obie branże nie zawsze prawidłowo odgadnie wszystkie ukryte problemy trapiące obie strony.

Wreszcie piąta kwestia nie tyle minimalizuje ryzyko wystąpienia nieporozumień, co ich skutki. Mowa o ostrożniejszym szacowaniu pracochłonności lub przyjęcia elastycznego sposobu rozliczania. Wówczas zarówno software house jest zabezpieczony i ma bufor na poprawki wynikające m.in. z ukrytej wiedzy dziedzinowej, jak i klient płaci rzeczywiście za to, co zostało wykonane i ma nad tym większą kontrolę. W niektórych przypadkach dobrym rozwiązaniem jest "przedwczesne" wprowadzenie umowy serwisowej.

Podsumowanie

Problem istnieje i to nie tylko w branży IT, ale w każdej, gdzie nakładają się na siebie obszary z różnych dziedzin lub nawet różnej filozofii działania firm. Należy się z tym pogodzić i nie reagować na nieporozumienia w sposób alergiczny. Oczywiście, ich pojawienie się nie jest witane aplauzem i nierzadko powoduje negatywne emocje, natomiast są techniki, które pozwalają je ograniczać i się na nie przygotować.

Warto wyciągnąć z tego wniosek, że etap analizy jest często ważniejszy niż się wydaje i trzeba poświęcić na niego więcej czasu. Z drugiej strony, bardzo dokładna analiza działania dużej firmy zajmuje tak dużo czasu, że w większości przypadków trzeba ją zarzucić na rzecz ogólnego planowania na początku, a następnie szczegółowych rozmów dotyczących konkretnych kwestii w przyszłości. Żadne podejście, nawet najbardziej drobiazgowe poznawanie zasad funkcjonowania danej branży, nie ustrzeże przed wystąpieniem nieporozumień. Jedyne, co możemy robić, to minimalizować ich wpływ na projekt IT.

Pozdrawiam i dziękuję - Jakub Rojek.