Rozwiązuj problemy, odhaczaj zadania

Ostatnio zakończyłem wnioskiem, iż bezwładny proces dostarczania oprogramowania, czyli taki, w którym czynności "dookoła" developmentu zajmują mnóstwo czasu oraz skłaniają Twoich klientów do ciągłego i nadmiernego dorzucania rzeczy do zrobienia, co w konsekwencji sprawia, iż proces pozostało bardziej ociężały.

Pierwszym rozwiązaniem jest rozróżnienie między output a outcome.

Pracę trudno podzielić na kawałki, gdy jej celem jest dowiezienie całego zakresu prac. Tak, wiem, iż często wrzucają Cię w sam środek prac, przydzielają zakres odpowiedzialności albo zadania i każą jechać z tematem. Wtedy wykonanie paczki funkcjonalności i dostarczenie zakresu projektu jest dokładnie tym, czym masz się zająć. Jednakże...

Jak reklamuję w podtytule tego newslettera - insightful newsletter for business problem solvers - jeżeli chcesz rozwiązywać problemy biznesowe, musisz nieustannie dopytywać o outcome.

Przypomnę rozróżnienie, które opisywałem w jednym z pierwszych maili, że:

• output to jest to, co produkujemy,
• outcome to jest to, za co nam płacą.

Tu rządzi prosta zasada: tego, co mierzysz, dostajesz więcej.

Poniżej zbieram pytania, które możesz zadać interesariuszom, aby sprecyzować outcome albo output.

• Jakiego przychodu z tej funkcjonalności się spodziewamy?
• W jakim terminie spodziewamy się osiągnąć ten zysk?
• Za co konkretnie są gotowi zapłacić nasi klienci/użytkownicy? Ile?
• W jaki sposób się dowiemy, iż użytkownicy cenią tę funkcjonalność?
• Gdybyśmy mogli wdrożyć jedną rzecz dziś, to co by to było? Dlaczego?
• Rezygnacja z której funkcjonalności spowoduje drastyczny spadek przychodów?

• Które funkcjonalności mamy dostarczyć? Na kiedy?
• Skąd mamy wziąć specyfikację?
• W jaki sposób możemy podzielić tę funkcjonalność na mniejsze kawałki?
• Jak zmierzymy jakość kodu?
• Na jakiej architekturze oprzemy to rozwiązanie?

Jak widzisz pytania o outcome i output różnią się od siebie znacznie. Nie zadając pytań o outcome siłą rzeczy będziesz optymalizować output, czyli starać się dostarczyć umówiony zakres w ustalonym terminie w założonych kosztach. Pytania o outcome pomagają Ci popatrzeć na pracę z perspektywy klienta lub użytkownika, z perspektywy wartości dla nich.

Możesz czasem usłyszeć, iż najważniejszy jest outcome, natomiast output się nie liczy. To nie do końca prawda. Spotkałem kiedyś błyskotliwe stwierdzenie, iż output jest poprzezem do outcome, ponieważ możemy uzyskać to, za co nam płacą (czyli outcome) poprzez wyprodukowanie odpowiednich rzeczy (a więc output).

Przyjmijmy na chwilę, iż pracujesz nad oprogramowaniem do zawierania umów ubezpieczeniowych. Przypuśćmy, iż zadając powyższe pytania o outcome odkryłeś/aś, iż klienci najbardziej cenią szybkość zawierania umowy ubezpieczeniowej i są skłonni zapłacić nieco więcej, jeżeli tylko umowa zostanie zawarta wystarczająco szybko.

W tym przypadku pytanie, na którym masz się skupić w następnej kolejności brzmi: Które funkcjonalności musimy dostarczyć, aby jak najbardziej skrócić czas zawierania umowy ubezpieczeniowej? W jaki sposób możemy mierzyć i monitorować ten czas?

Na jednym obrazku wygląda to tak:

Twój upór w namierzeniu outcome zostanie nagrodzony zmniejszeniem zakresu prac w danym momencie. Outcome jest jednym ze sposobów rozwiązania problemu ciągłego dorzucania pracy przez biznes, który przedstawiłem w jednym z poprzednich maili. Dodatkowo rozmowa o outcome "uelastycznia" myślenie. Zamiast negocjować dostarczenie sztywnego zakresu, negocjujemy oczekiwany outcome i wspólnie pracujemy nad zakresem, który pomoże ten outcome osiągnąć.