Czasami zdarza się tak, że czegoś chcemy i to bardzo - nie myślę tutaj o chwilowej fanaberii, ale czymś narastającym przez wiele miesięcy, co może przyczynić się do dużej poprawy jakości czy efektywności i tym samym przynieść nam zysk lub przewagę konkurencyjną. Wówczas zaczyna się szukanie sposobu na urzeczywistnienie danego pomysłu. Jeśli nie jesteśmy w stanie zrobić tego samodzielnie lub jest to nieopłacalne czasowo - najczęściej zwracamy się o pomoc do jednego z wykonawców, korzystając z jego wiedzy eksperckiej, doświadczenia i umiejętności. Projekt jest analizowany, warunki uzgadnianie, firma IT (gdyż to o takich wykonawcach zwykle piszemy w naszych artykułach) rozpoczyna pracę, przesyła kolejne rezultaty klientowi... I co dalej?

Scrum zakłada wiele rzeczy, ale jedną z ważniejszych jest realny udział klienta w powstawaniu projektu. Często jest to realizowane poprzez spotkania, konsultacje czy właśnie oddawanie wyników kolejnych sprintów i ustalenia dotyczące następnych prac. Ale czy to wystarczy? W tym jednym punkcie Manifestu Agile niektórym umyka także inna rzecz - klient musi się poczuć członkiem zespołu. Czasami wręcz pada stwierdzenie, że powinien siedzieć z programistami i w ten sposób spełniać rolę natychmiastowego konsultanta, natomiast to jest oczywiście przesada, niemożliwa do wykonania w większości przypadków - dlatego wymyślono rolę Product Ownera. Jednak fakt, że reprezentanci zleceniodawcy powinni aktywnie uczestniczyć choćby w testowaniu. I tutaj dochodzimy do tematu dzisiejszego artykułu, ponieważ z tym aspektem różnie bywa.

Projekty IT tworzone na zamówienie są przeznaczone do osiągania konkretnych celów biznesowych, które są wcześniej wyznaczane podczas spotkań projektowych. Warto jednak pamiętać, że są to cele klienta - to dla niego realizowany jest system i to jemu ma przynosić korzyści w pierwszej kolejności. A co za tym idzie, to on (lub ona) wie, co mu (lub jej) jest potrzebne oraz jak przydzielić priorytety. Ale żeby to prawidłowo zrobić i pomagać w sterowaniu właściwym kursem projektu, musi być na bieżąco z pracami. A mimo spotkań w trakcie oraz na końcu każdego sprintu to za mało, aby wyrobić sobie pojęcie o tym, w jakim miejscu znajduje się całe przedsięwzięcie. A jak można to poprawić? Testując aplikację na bieżąco, choćby poprzez zwykłe klikanie.

Każdy sprint z założenia przynosi pewną porcję spełnienia celu biznesowego i co za tym idzie - w teorii pozwala nieskończonemu oprogramowaniu być już wykorzystywanym w produkcyjny sposób. Oczywiście, nie zawsze tak można, natomiast ideą zwinności i podejść w rodzaju MVP jest między innymi przyspieszenie stworzenia najbardziej wartościowych biznesowo funkcji. Jednak nikt od wykonawcy nie wie, kiedy się zatrzymać z pracami, zmienić kurs czy przesunąć nacisk na coś innego, gdy klient nie powie, jakie są braki jego zdaniem. Do tego dochodzą zwykłe, małe niedoskonałości oprogramowania, które - nie ukrywajmy - zawsze się pojawiają i czasami są zwykłym niedopatrzeniem, a czasami właśnie wynikają z braku wiedzy o tym, na co klient zwróci baczniejszą uwagę. Bo bądźmy szczerzy - możemy spędzić tygodnie, a nawet miesiące na dyskusjach analitycznych, pieczołowicie spisując wymagania funkcjonalne i pozafunkcjonalne, tworząc makiety oraz projektując architekturę, ale i tak zawsze pozostanie coś, co nie zostanie uwzględnione, gdyż jego brak, nadmiar lub potrzeba modyfikacji zostanie zauważona dopiero w "ruchu". I wiemy, że im wcześniej te niedostatki zostaną zauważone, tym nie tylko prędzej zostaną podjęte odpowiednie działania naprawcze, ale też istnieje duża szansa, że wpłynie to pozytywnie na dalszy przebieg prac już w innych obszarach.

Krótko mówiąc, potrzebne jest, aby klient poświęcał każdorazowo choć 20 minut na zwykłe przeklikanie realizowanego systemu we własnym gronie, próbując korzystać z niego tak, jak uważa to za słuszne. Tylko w ten sposób jest w stanie zorientować się, czy wszystko idzie w dobrym kierunku, a jednocześnie może zapoznać się z efektem czegoś, na co wydaje pieniądze. Pamiętajmy, że branża IT jest o tyle komfortowa, że tutaj wcześniejsze testowanie jest łatwe - trudne byłoby np. w motoryzacji testowanie ferrari, za które się zapłaciło i weryfikacja wymarzonego auta w etapach. Kliencie, wykorzystaj ten informatyczny dobrostan i poklikaj udostępnioną aplikację, nawet jeśli nie jest skończona i nie możesz w niej jeszcze nic zdziałać produkcyjne. Potencjalne korzyści to:

• zorientowanie się w statusie prac - może być tak, że zyskasz potwierdzenie, że wszystko jest na dobrym kursie i poprawi Ci to nastrój. Ale równie ważne są sytuacje, w których zorientujesz się, że nie wszystko przebiega z Twoją wizją (najczęściej w bardzo dużych detalach) i w ten sposób możesz szybciej o tym dać znać zespołowi.
• przypływ nowych pomysłów - nic tak nie pobudza kreatywności, jak rozpoczęcie pracy nad daną rzeczą. Przeklikując się przez fragment aplikacji może przyjść Ci na myśl jakieś ciekawe, sprytne rozwiązanie kwestii, z którymi się zmagasz w pracy. Czasami jest to zupełnie nowa funkcja, a czasami inne podejście do sprawy, którą już omawiałeś z wykonawcą. W końcu wszystkim chodzi o to, aby oprogramowanie było jak najlepsze i jak najtrafniej trafiało w Twoje potrzeby.
• stopniowa nauka korzystania z aplikacji - kiedyś w końcu nadejdzie dzień, w którym Ty lub Twoi pracownicy będziecie korzystać z aplikacji produkcyjnie. Początek nauki naturalnie wiąże się z oporem przed nieznanym, ale można go zminimalizować poprzez stopniowe przyzwyczajanie sie do interfejsu.
• testowanie intuicyjności - to wiąże się z poprzednim punktem, gdyż trudno lepiej sprawdzić intefejs aplikacji niż testując go "w boju", choćby udawanym. W ten sposób można wypracować rozwiązania, które następnie zostaną powielone na innych ekranach. Podczas klikania uświadamiasz sobie, że jesteś przyzwyczajony do pewnego sposobu korzystania z oprogramowania? Powiedz o tym wykonawcy.
• równoważenie poprawek - nie da się ukryć, że testowanie może ujawnić potrzebę pewnych poprawek, które będzie trzeba realizować wraz z kolejnymi sprintami. Jednak ważne jest ich obciążenie - dużo lepiej przetwarzać wiele mniejszych poprawek i to na początkowych etapach niż wielką gromadę na sam koniec, kiedy programiści nagle widzą przed sobą setki zgłoszeń. Podzielenie tego na partie w trakcie trwania projektu jest znacznie lepsze i zdrowsze dla obu stron.
• motywacja dla programistów - zespół IT lubi, gdy to, nad czym pracowali w pocie czoła często przez parę tygodni lub miesięcy rzeczywiście jest używane i nawet się podoba. To daje duży zastrzyk energii na kolejne wyzwania.

Warto zastanowić się też nad tym, dlaczego klienci nie weryfikują (zazwyczaj, gdyż są bardzo chlubne przypadki) oprogramowania na bieżąco. Najważniejszym powodem jest naturalnie brak czasu i z tym trudno walczyć, ponieważ zleceniodawca musi ciągle dbać o swój biznes i normalnie funkcjonować. Warto jednak pamiętać, że przeklikanie się przez fragment systemu zazwyczaj nie zajmuje naprawdę więcej niż te 20 minut, a to jest możliwe do zrobienia w jakiejś przerwie lub na zasadzie odstresowania się i odpoczynku od aktualnych obowiązków. Można nawet żartobliwie powiedzieć, że w ten sposób można znaleźć sposób na ponarzekanie na kogoś (choć, oczywiście, software house'y wolałyby być obiektem chwały, a nie pretensji :)). Innym, równie częstym powodem jest przeświadczenie klienta, że "teraz nie ma sensu testować, bo i tak się wszystko zmieni". Otóż - nie zmieni się, jeśli ktoś ze strony klienta tego nie przetestuje i nie powie, co ma ulec modyfikacjom w słuszną stronę. Owszem, funkcjonalność będzie się rozrastała, a pewne przepływy w aplikacji będą wyglądały nieco inaczej, ale nie zmienia to faktu, że np. interfejs nie ulegnie zmianie, gdy ktoś z zewnątrz nie powie "ale przecież my będziemy używać tego inaczej".

Dlatego, drogi kliencie - testuj aplikację, nawet kawałek po kawałku. Nikt tak, jak Ty nie powie zespołowi IT, czy to, co tworzą, ma jakikolwiek sens w kontekście spełnienia Twoich potrzeb. Nie opieraj się tylko na wcześniejszym etapie analizy - dawaj na bieżąco znać zespołowi, czy jesteś zadowolony z realizowanej usługi czy nie. To na pewno będzie mile widziane przez wykonawcę oraz w konsekwencji wpłynie pozytywnie na końcowy rezultat, z którego to Ty masz być zadowolony.

Pozdrawiam i dziękuję - Jakub Rojek.