Jeden ze sposobów na zadowolenie naszego klienta to „continuous delivery of valuable software”. „Delivery” oznacza wdrożenie i wbrew temu co niektórzy sądzą, oddawanie oprogramowania do testów wcale tutaj nie wystarczy.
Wartościowy produkt
W zeszłym tygodniu poruszyłem temat celu zwinności. Jest nim nic innego niż zadowolenie (satysfakcja) naszego klienta. Za tym oczywiście idą takie wymierne rzeczy, jak częstsza i bardziej perspektywiczna współpraca, a także dobra reputacja naszej firmy. Trudno umniejszać wagę obu tych rzeczy. Sami jako #białko widzimy, jak pomagają one w rozwoju naszej działalności.
Metodyki agile sugerują pewne sposoby i techniki, które mają pomóc w osiągnięciu satysfakcji odbiorcy. Wśród nich znajdą się praca iteracyjna oraz budowanie MVP (Minimum Viable Product), czyli takich fragmentów naszego rozwiązania, które są użyteczne i mogą zostać dostarczone szybko.
Wszystko to dzieje się po to, aby przygotowywany przez nas produkt miał wysoką wartość. To znaczy: żeby faktycznie rozwiązywał problemy naszego klienta bądź spełniał jego oczekiwania. Przy tym nie ma tu znaczenia czy są to potrzeby, o których już nam powiedział, czy dopiero dowie się o nich, gdy zacznie używać rzeczonego produktu.
Duża w tym rola Product Ownera (albo odpowiadającej mu roli w innej metodyce), żeby zapewnić „wysoką wartość” i dobrze odgadnąć rzeczywiste potrzeby. Natomiast nic tak nie pomoże w ich zidentyfikowaniu, jak oddanie gotowego produktu (np. oprogramowania) do użytku.
Czyli wdrożenie, a nie „UAT-y”.
Jazda testowa
Jazda testowa to coś, na co decydują się osoby poszukujące nowego samochodu, gdy już doskonale wiedzą, co chcą kupić. Bo skoro już wsiadamy do tego konkretnego modelu, to przeważnie po to, żeby móc sobie potem zracjonalizować nasz wybór.
Spójrzmy prawdzie w oczy, kto nie będzie zadowolony z jazdy fabrycznie nowym samochodem? Czy po jeździe testowej ktokolwiek kiedyś faktycznie narzekał na jakieś cechy samochodu, o których wcześniej nie wiedzieliście? A nawet jeśli, to czy odwiodło go to od zakupu?
To, co faktycznie może wpłynąć na nasz teoretycznie już dokonany wybór to niespełnienie wymagań funkcjonalnych. Np. w bagażniku według specyfikacji powinny zmieścić się narty i jest to dla nas wymaganie kluczowe. My na jazdę testową przyjeżdżamy z całym ekwipunkiem i okazuje się, że nie ma szans tego wszystkiego zmieścić. Klapa.
Głównym problemem jest jednak to, że jazda testowa w ogóle nie odpowiada rzeczywistym warunkom, w jakich używamy pojazd. Nie dowiemy się też o takich rzeczach jak spalanie, pakowność, manewrowość, awaryjność, wygoda użytkowania komputera pokładowego, itd. Nie będzie na to czasu, a nawet jeśli, to nie zostaną one sprawdzone w życiowych sytuacjach.
Jeżeli chcielibyśmy dokładnie sprawdzić czy faktycznie dany samochód odpowiada naszym potrzebom, zamiast go testować, powinniśmy zacząć go używać. Pojeździć nim przez tydzień lub dwa, najlepiej w okresie urlopowym.
Dopiero wtedy zobaczymy czy faktycznie ten cudowny napęd jest w stanie podjechać pod nasze ulubione schronisko. Zobaczymy też, czy w pełni załadowany nadal będzie tak żwawo pomykał po autostradach. Przekonamy się ile pali przy naszym użytkowaniu i czy schowki są dla nas odpowiedniej wielkości, czy też np. nie mamy gdzie schować naszego portfela czy telefonu.
Jazda testowa nie da nam odpowiedzi na pytania o użyteczność pojazdu, bo zamiast samochodu używać, będziemy go „testować”. A i tak wiadomo, że chcemy po prostu uspokoić swój umysł, który ostrzega nas przed zakupem w ciemno. Teraz możemy powiedzieć „przetestowałem go” i spokojnie dokonać zakupu.
Produkcja, a nie testy
Wspomniane we wstępie „continuous delivery of valuable software” to „dostarczanie do użytku”. Oddając nasz produkt jedynie do testów praktycznie gwarantujemy sobie, że nie obejrzą go jego przyszli użytkownicy. Przede wszystkim – nie mają oni na to czasu, bo są zajęci pracą. W tym celu korzystają zapewne z poprzednich rozwiązań. Trudno więc oczekiwać, żeby robili wszystko podwójnie.
Nawet jeśli uda nam się „zmusić” użytkowników końcowych do testów, to potraktują to jako upierdliwy obowiązek i przetestują absolutne minimum. Nic dziwnego, wspominaliśmy o tym dyskutując o motywacji. Skoro nie mają z tego żadnej korzyści, to dlaczego mieliby się do tego przykładać?
Zupełnie inaczej sytuacja wygląda, gdy po prostu dostaną nasz produkt do codziennego użytku. Wtedy zyskujemy szansę na zapewnienie „wysokiej jakości”, bo od razu okaże się, czy spełnia on potrzeby klienta i czy faktycznie w czymkolwiek pomaga. Jeśli są jakieś problemy bądź niewygody, to na pewno znajdą się użytkownicy, którzy nam o tym powiedzą. A my wykorzystamy to przy budowie kolejnej wersji.
Scrum pomaga „w produktywny i kreatywny sposób wytwarzać produkty o najwyższej możliwej wartości”, a nie „oddawać je do testów”. O Przyroście również mówimy, że jest „potencjalnie wdrażalny”, a nie „testowalny”. Z kolei Product Owner podejmuje decyzję o „wdrożeniu”, a nie „oddaniu do testów”.
Nie testujmy na produkcji!
To wszystko sugeruje, że powinniśmy jak najszybciej oddać do użytku gotowe rozwiązanie, bądź jego fragmenty. I to prawda, przy czym kluczowe słowo to „gotowe”.
Omawiając MVP podkreślaliśmy fakt, że nie oddajemy rozwiązania kiepskiej jakości, ale takie, które spowoduje uśmiech na twarzy odbiorców. Przy tym, wcale nie musi być ono kompletne i zawierać wszystkich wodotrysków schowanych w backlogu. Wystarczy, że rozwiążemy co najmniej jeden problem bądź usprawnimy jeden proces.
Także i w tym kontekście sprawdzi się podejście iteracyjne. Nie budujmy całego rozwiązania od razu, ale uczmy się zadowalać klienta w trakcie tworzenia kolejnych wersji. Mogą one pokrywać kolejne dziedziny działalności, inne obszary geograficzne (bądź nawet inne części biura) lub zapewniać większą automatyzację czy wygodę.
Możliwości pracy iteracyjnej jest wiele i to już temat na osobny wpis. Natomiast niezależnie od wybranej ścieżki, jeśli chcemy aby kolejne wydania produktu obejmowały praktyczne uwagi użytkowników, to nie mogą oni go tylko testować. Muszą go używać.
