Teza dzisiejszego tekstu jest prosta: nie jesteś konsumentem swojej pracy. Większość z nas pracuje w organizacjach, w których prowadzone są projekty na rzecz innych osób lub tworzone produkty, których odbiorcami wcale nie jesteśmy…
Kim jest konsument?
W świecie projektowym interesariusz lub klient to osoba, która ma zamiar skorzystać na owocach naszej pracy. Bardzo często jest ona inicjatorem projektu. Potrzebuje czegoś, co pozwoli jej pracować inaczej, wykorzystać szansę pojawiającą się na rynku lub po prostu pokonać konkurencję. Dlatego zdecydowała się na zatrudnienie grupy osób i powierzenie jej tego odpowiedzialnego zadania.
Ma to oczywiście swoje konsekwencje. Nasz klient wymaga od nas, aby tworzony produkt spełniał jego wymagania. Jak wiemy nie od dziś, często jest trudne do osiągnięcia. W tym miejscu pojawia się bowiem pułapka. Klient często nie jest „techniczny”, nie do końca ma wiedzę w zakresie możliwości realizacji jego założeń i marzeń. Zna on swój cel, może nawet wizję tego, ja ma wyglądać i działać jego system. Ale czy na pewno wie lepiej niż eksperci?
I tu pojawia się pokusa – może pomóc mu w tej trudnej sytuacji? Przecież bardzo często znamy się lepiej. Jesteśmy profesjonalistami, mamy doświadczenie i już nie raz realizowaliśmy podobne projekty…
Pierwsza zasada ZZTO
ZZTO to nic innego niż 12 Zasad Zwinnego Tworzenia Oprogramowania, czyli dodatek do Agile Manifesto. Pokazuje nam on, czym powinniśmy się kierować pracując zwinnie. Nagraliśmy o nich nawet długi film na naszym #białkowym kanale na YouTube. A gdyby tego było mało, to mamy również serię 12 klipów omawiającą szczegółowo każdą z zasad.
Przypomnijmy więc, o czym mówi pierwsza, według niektórych najbardziej kontrowersyjna zasada.
Najwyższy priorytet ma dla nas zadowolenie klienta dzięki wczesnemu i ciągłemu wdrażaniu wartościowego oprogramowania.
W ramach dzisiejszego wpisu interesuje nas jedynie pierwsza część oraz ostatnie dwa słowa tego zdania, choć całość jest jak najbardziej wartościowa. Zadowolenie klienta dzięki wdrożeniu wartościowego oprogramowania. Wartościowego dla niego, a nie dla nas. Możemy zrobić wszystko, opracować najlepsze rozwiązanie, ale jeśli nie będzie ono spełniało definicji „wartościowe” dla naszego interesariusza, nie osiągniemy w żaden sposób celu, jaki przed nami stoi.
Oczywiście, często jest tak, że współpracujemy z trudnym lub upartym klientem. I takiemu w żaden sposób nie wytłumaczymy, że coś jest „nierabialne„, niemożliwe do implementacji, że się po prostu nie da. Mamy jednak od tego ludzi i zwykle tak lub inaczej jesteśmy sobie w stanie z tym poradzić.
Dla kogo właściwie tworzę?
Odbiorca to kolejna (trzecia?) strona medalu. Często nie wiemy, kto jest naszym klientem albo mylimy go z odbiorcą lub użytkownikiem końcowym. Nie wiemy kto jest kim, bo jesteśmy tak hermetycznie zamknięci, że o naszym interesariuszu słyszeliśmy tylko z opowieści. To oczywiście jest złe. Tak samo jak to, że jesteśmy od niego oddzieleni sztucznymi bądź prawdziwymi barierami. I czasem to jest jeszcze gorsze, patrz: zespoły rozproszone.
Jak pokazuje doświadczenie, poznanie naszego klienta, obcowanie z nim, zrozumienie, w jaki sposób pracuje czy w końcu poznanie jego wymagań jest kluczem do sukcesu prawie każdego przedsięwzięcia. Nie da się dobrze wykonać zakładanego zadania nie wiedząc, jakie cele ma spełnić. Bo możemy posiadać najlepiej opisany backlog produktu, możemy wykonać swoją pracę najlepiej na świecie, ale możemy też „wyłożyć się” na najprostszym elemencie naszego systemu, bo nie wiemy po co on powstaje.
I tu oczywiście duża rola zarówno Product Ownera, jak i nas samych. Bo to PO powinien sprzedać nam wizję klienta i zarazić nas jego entuzjazmem. Z kolei my sami powinniśmy brać pod uwagę zarówno klienta jak i odbiorcę. W końcu „zespoły biznesowe i deweloperskie muszą ściśle ze sobą współpracować, w codziennej pracy przez cały czas trwania projektu”. A to znaczy kontakty z klientem (żeby zrozumieć wymagania), jak i z (potencjalnymi) odbiorcami (żeby móc zaproponować optymalny sposób realizacji).
Wiedza w zakresie tego, kto jest odbiorcą naszych działań jest krytyczna. Brak tych informacji nie spowoduje, że produkt, w ogóle nie powstanie. Ale może nie spowodować zadowolenia naszego klienta, może również wymagań zmian. Czy właśnie tego potrzebujemy?
Twórz odpowiedzialnie
Potrzebujemy zupełnie innego podejścia. Jeśli nie wiesz, dla kogo budujesz rozwiązanie – zrób wszystko, żeby się tego dowiedzieć. Zastanawiasz się, czego dokładnie potrzebuje Twój klienta? Zrób wszystko, żeby się tego dowiedzieć. Jeśli nie jesteś przekonany, że to co zrobiłeś spełni jego oczekiwania, zrób wszystko… No dobra, powiecie, że „łatwo się pisze”.
Łatwo się pisze, ale i łatwo wdraża w życie. Dlaczego Product Owner jest członkiem Scrum Team? Unikamy w ten sposób izolacji człowieka, który jest źródłem informacji o wizji i celu. Unikamy zabawy w „głuchy telefon”, która jak wiemy w 99% przypadków kończy się nieporozumieniami. W naszym przypadku rozjazdem między tym, czego klient oczekiwał a tym, co od nas dostanie. I pamiętajmy, że znajomość naszego odbiorcy pomoże nam w proponowaniu lepszych rozwiązań, ale to znajomość naszego klienta pozwoli nam na jego zadowolenie. A co za tym idzie – na osiągnięcie sukcesu z jego punktu widzenia.
Skracajmy więc dystans między klientem a nami do minimum. Pytajmy, sprawdzajmy, pokazujmy. Konfrontujmy nasze rozumienie wymagań z oczekiwaniami. Rezultaty przejdą najśmielsze oczekiwania. A w jaki sposób to zrobić? Odpowiedzi udziela chociażby metodyka Scrum, która zawiera wiele narzędzi wspomagających nasze potrzeby. Jakich? O tym piszemy przecież nieustannie na naszym blogu.
