Z reguły w umowach, które firmy IT zawierają ze swoimi klientami, często znajduje się zapis, że za zmiany w systemie klient płaci, natomiast błędy usuwane są za darmo w ramach gwarancji czy maintenance’u.
Wydaje się to proste i zrozumiałe. Ale w praktyce bardzo często zdarzają się sytuacje, w których dyskusje „czy to jest błąd, czy to jest zmiana” pochłaniają bardzo dużo czasu oraz energii. Dlaczego tak się dzieje?
Teoria modelu kaskadowego wygląda tak: spisujemy jakieś wymagania, implementujemy system, testujemy go, oddajemy klientowi. Jeżeli następuje jakaś wątpliwość „błąd czy zmiana” – sięgamy po dokumentację systemu (a dokładniej po spisane wymagania), ta dokumentacja opisuje bardzo dokładnie jak system powinien działać i rozwiązuje nasz problem.
A w praktyce? W praktyce problem „błąd czy zmiana” pojawia się bardzo często w fazie testów systemu (często określanej jako User Acceptance Tests), testów pilotażowych oraz w okresie bezpośrednio po wdrożeniu systemu. I w większości przypadków problem jest nierozwiązywalny przy pomocy dokumentacji, ponieważ:
- problem dotyczy sytuacji szczególnej, która nie jest opisana przez dokumentację,
- albo dokumentacji po prostu nie ma,
- albo zagadnienie jest na tyle trywialne, że nie zostało opisane w dokumentacji,
- albo – i to są najweselsze przypadki – kwestia jest opisana w dokumentacji, ale jest opisana w taki sposób, że IT i klient rozumieją ten zapis zupełnie inaczej. Bywa i tak, że wymagania z różnych miejsc są sprzeczne ze sobą…
Dwa małe przykłady z rzeczywistości, żeby zilustrować problem:
Przykład 1. Dokumentacja zmiany została bardzo dokładnie opisana. Do tej dokumentacji zostały dołączone prototyp systemu (strony w HTML-u) oraz referencyjny opis systemu zastosowanego w innym kraju. Głównym wymaganiem brzmiało „system ma wyglądać dokładnie tak samo jak prototyp”. Toteż programiści tworząc zmianę wzorowali się na prototypie, traktując opis istniejącego systemu jako dokumentację pomocniczą. W momencie testów systemu klient stwierdził, że błędem jest pominięcie jednej z funkcjonalności nie zawartej w prototypie, a opisanej w dokumentacji referencyjnej.
Przykład 2. Dokumentacja nowego produktu dla klientów korporacyjnych zawierała zdanie brzmiące: „limity dla produktu mają działać analogicznie jak istniejące limity produktu dla klientów indywidualnych”. Zespół IT po prostu skopiował do nowego produktu istniejący kod dotyczący limitów i limity te były sprawdzane na poziomie klientów indywidualnych. W trakcie testów pilota systemu okazało się, że wyrażenie „analogicznie jak istniejące limity” w opisie wymagań tak naprawdę oznaczało dla klienta, iż „limit, który jest obecnie sprawdzany dla klientów indywidualnych, w nowym produkcie ma być sprawdzany nie na poziomie klienta indywidualnego lecz na poziomie całej korporacji” – a to zmieniało całkowicie projekt systemu.
W tych przykładach zagadnienie „błąd czy zmiana” nie było wcale akademickim rozważaniem, gdyż pojawiało się na finalnym etapie testów systemy, termin wdrożenia był już określony, a implementacja poprawki błędu/nowego wymagania była oszacowana na kilka osobomiesięcy. Od rozstrzygnięcia tej kwestii zależały więc niemałe pieniądze…
Jak sobie próbują radzić z tym problemem firmy IT? Jest kilka sposobów, z których żaden nie jest idealny…
Pierwszym sposobem jest powiedzenie sobie „spróbujmy mówić wspólnym językiem i lepiej się rozumieć”. Robione są wspólne spotkania jako „kick-off” projektu, spotkania projektowe, rysowanie na tablicach, definiowanie wspólnego słownika. Wszystkie moje doświadczenia z takimi inicjatywami są jak najbardziej pozytywne – nierzadko byłem świadkiem sytuacji, kiedy dwugodzinne spotkanie rozwiązywało problem, którego nie udało się rozwiązać w dwutygodniowej wymianie maili… Od razu tutaj rodzi się pytanie: skoro ten sposób działa, to czemu jest to tak rzadko stosowany? Myślę, że nakładają się tutaj dwa czynniki. Pierwszym są koszty: w dużych projektach czy projektach międzynarodowych takie spotkania nie są proste, często też łączą się z wyjazdem zagranicznym. A drugi powód to czynnik ludzki: skoro jestem przekonany, że rozumiem wymagania i wszystko jest w nich dla mnie oczywiste – to po co mam się ruszać zza wygodnego biurka?
Drugi sposób to sformalizowanie zapisów wymagań: „zapiszmy tak nasze wymagania, żeby były zrozumiałe i jednoznaczne”. Najczęściej w takich przypadkach do zapisywania używa się notacji UML. I tutaj nie jest już tak prosto – bo tutaj zarówno IT, jak i klient, muszą potrafić i lubić posługiwać się tym językiem. W mojej praktyce spotkałem się z dokumentacją, która wykorzystywała niektóre diagramy UML-a jako pomoc – ale nigdy jeszcze nie spotkałem się z projektem, który w całości czy chociażby w dużej części był opisany tym językiem.
Trzecim sposobem jest tworzenie prototypów systemu. W niektórych przypadkach to działa – zwłaszcza tam, gdzie mamy do czynienia ze zmianą mocno opartą o interfejs użytkownika. Znam przypadek, kiedy malowane ręcznie w Visio screenshoty służyły za główną dokumentację projektową – zamiast nanosić kolejne zmiany w oficjalnej dokumentacji, która opisywała tworzone formatki, analityk i klient po prostu nanosili zmiany na testowych zrzutach ekranu i dopisywali do nich swoje komentarze. I w tym projekcie działało to bardzo dobrze! Ale nie każda zmiana może być opisana w prototypie. W opisanych wyżej przypadkach stworzenie prototypu nic by nie dało – w przypadku pierwszym prototyp i tak istniał, w drugim przypadku problem był raczej nie do wyłapania przy tworzeniu prototypu. Prototypy nie wyłapują również niejasności dotyczących działania systemu w sytuacjach granicznych – z reguły prototyp pokazuje działanie systemu w sytuacji kiedy wszystkie operacje przebiegają prawidłowo.
Te wszystkie sposoby dotyczyły kwestii technicznych. Ale na cały problem nakłada się jeszcze „czynnik ludzki” i praktyka współpracy między klientem a dostawcą.
Po pierwsze: dotykamy tutaj trudnego kwestii wzajemnego zrozumienia dostawcy (IT) i klienta. IT często nie rozumie wymagań klienta, zwłaszcza jeżeli chodzi o rzeczy, które dla klienta wydają się „tak oczywiste, że wszyscy to wiedzą i nie trzeba ich tłumaczyć”. Klient nie rozumie, że niektóre zmiany można wprowadzić w systemie bardzo łatwo (bo są np. sparametryzowane na poziomie bazy danych – wystarczy jedno polecenie by je zmienić), natomiast inne zmiany wymagają włożenia sporego wysiłku w przebudowanie systemu. Czasami powoduje to wypowiedzi klienta typu: „skoro to zmieniliście mi od ręki, to dlaczego nie chcecie zmienić mi tamtego?”.
Po drugie: kolejna ważną rzeczą, której deficyt potęguje problem, jest wzajemne zaufanie. Jeżeli mamy dobre relacje z klientem, jeżeli ufamy sobie nawzajem, to tak naprawdę żadne zaawansowane kryteria rozróżnienia między błędem a zmianą nie są potrzebne. Jeżeli relacje są złe, pojawiają się podejrzenia o matactwa i oszustwa – to nawet jeżeli zdefiniujemy bardzo dokładne i precyzyjne kryteria rozróżnienia – i tak dochodzi do wątpliwości, przepychanek, podejrzeń i eskalacji… Co ciekawe, moje doświadczenia są takie, że często łatwiej jest wypracować to zaufanie w relacji z klientem zewnętrznym (klientem dla którego tworzymy oprogramowanie w ramach kontraktu za konkretne pieniądze) niż w relacji z klientem wewnętrznym. Dlaczego tak jest – to już temat na osobny wpis…
Tak wygląda sprawa w świecie klasycznego modelu kaskadowego wytwarzania oprogramowania. A jak wygląda ten problem w świecie metodyk lekkich, np. Scruma? Teoretycznie powinno być lepiej – iteracja powinna dostarczać funkcjonalności bez błędów, natomiast znalezione problemy czy braki funkcjonalne zawsze można dodać jako nowe zadanie do kolejnej iteracji. Ale jak to się sprawdza w praktyce – nie wiem. Jeżeli ktoś ma jakieś doświadczenia w tej kwestii – zapraszam do podzielenia nimi się w komentarzach. Lub opisania tego w artykule, który zamieścimy na „Trzeciej kawie”.