Orientacja na klienta zamiast kosztów utopionych – Jak uniknąć pułapki błędu kosztów utopionych?

Co łączy graczy w grę online Farmville z członkami zespołu projektowego? Na pierwszy rzut oka niewiele - jedni budują wirtualną farmę, drudzy opracowują produkt. Jednak po bliższym przyjrzeniu się okazuje się, że mają coś wspólnego: obie strony inwestują czas i wysiłek w osiągnięcie celów.

Sunk costs - koszty utopione

Co się dzieje, gdy gracz Farmville w pewnym momencie nie ma już ochoty na grę? Ciężko wypracowane postępy w grze ponownie znikają. I tu zaczyna się problem: decyzja o kontynuowaniu gry nie jest podejmowana racjonalnie. Zamiast zastanawiać się nad przyszłymi kosztami i korzyściami, ludzie myślą o tym, ile czasu już zainwestowali w grę. Zainwestowanego czasu nie da się odzyskać. Aby jednak nie stał się on “czasem straconym”, gracz decyduje się wydać więcej zasobów. 

Poniższy przykład pokazuje, co ma to wspólnego z zespołem projektowym: Po długiej fazie rozwoju produktu, gotowy produkt jest wreszcie gotowy. Zespół jest zadowolony; w końcu włożył wiele zasobów (zarówno czasowych, jak i poznawczych i finansowych) w rozwój. Następnym krokiem jest prezentacja produktu klientowi. 

Zespół wchodzi z optymizmem, ale wychodzi wstrząśnięty: klient inaczej wyobrażał sobie gotowy produkt, zmieniły się wymagania. Teraz zespół staje przed decyzją: albo zaczną od zera i opracują nowy produkt, albo zachowają produkt, który został już opracowany (ale nie spełnia potrzeb klienta) i zmienią kilka drobnych rzeczy. 

Racjonalnie rzecz biorąc, zespół powinien zdecydować się na opracowanie nowego produktu, który spełnia wymagania i życzenia klienta. Gdyby tylko nie te liczne zasoby, które już zainwestował w rozwój - te głupie utopione koszty.

Dlaczego nie możemy odpuścić? 

The Błąd kosztów utopionych Opisuje dokładnie ten przypadek, w którym dalsze zasoby są inwestowane w coś, co okazało się niecelowe lub nawet błędne (Arkes & Blumer, 1985). Ludzie lub zespoły, które podlegają temu błędowi decyzyjnemu, mają zazwyczaj trzy wspólne cechy (Brockner, 1992): 

1. Zainwestowałeś już dużo czasu, pieniędzy, pracy itp.
2. Zainwestowane zasoby nie doprowadziły do sukcesu. 
3. Mogą zdecydować, co zrobić teraz: zainwestować więcej zasobów w projekt lub anulować projekt. 

Pozostaje pytanie, dlaczego próbujemy ratować statek, który już zatonął. Psycholog i laureat Nagrody Nobla w dziedzinie ekonomii, Daniel Kahneman, twierdzi, że z jego Teoria perspektywy ma gotowe wyjaśnienie: Ludzie boją się strat (Kahneman i Tversky, 1979). Ten strach sięga tak daleko, że wolą zainwestować w mało prawdopodobną możliwość pomyślnego ukończenia skazanego na porażkę projektu, niż zaakceptować pewną porażkę.

Sunk Costs a orientacja na klienta - Scrum jako rozwiązanie?

Oczywiste jest, że zespoły trzymające się nieudanych projektów są sprzeczne z korzyściami dla klientów. Ale co mogą zrobić zespoły, aby nie stać się Błąd kosztów utopionych ulec? Jedną z odpowiedzi jest praca zwinna. Zorientowanie na klienta jest tam jedną z najważniejszych zasad. Dzięki priorytetowemu traktowaniu wartości dla klienta można uniknąć inwestowania jeszcze większej ilości zasobów. 

Podczas pracy zespołów Scrum klient jest zaangażowany w cały proces rozwoju, dzięki czemu można szybko reagować na zmieniające się potrzeby klienta. Ciągła wymiana zapewnia, że pod koniec fazy rozwoju nie ma momentu szoku, gdy staje się jasne, że klient oczekiwał innego produktu.

Jesteśmy gotowi odrzucić wykonaną pracę, jeśli wymaga tego nowy wgląd w potrzeby klientów. (Pozycja Echometer)

Konkretnie oznacza to, że zespoły muszą pracować w krótkich odstępach czasu. Sprinty praca. Na początku ustala się, nad czym będzie się pracować w ciągu najbliższych kilku tygodni. Na koniec sprintu sprawdza się, czy wyznaczone cele zostały osiągnięte. Historyjki użytkownika są ważnym narzędziem, z którego powinny korzystać zespoły Scrum. Przekładają one wymagania klienta na skoncentrowane na użytkowniku oświadczenie o produkcie zgodnie z formatem:

Jak Roll  Chciałbym  Cel/pragnienie, um Korzyści.

Po utworzeniu, historyjki użytkownika są przenoszone do rejestru produktu i stanowią podstawę treści dla pracy zespołu programistów. Podobnie jak wiele koncepcji w Scrumie, historyjki użytkownika nie są statyczne: jeśli zmieniają się wymagania klienta, zmienia się również historyjka użytkownika. 

Umożliwia to niezwykle wysoki poziom orientacji na klienta. Ponieważ zespoły Scrum pracują w sposób samoorganizujący się, ważne jest, aby analizować historie użytkowników z ostatniego sprintu w sprincie retro. Można na przykład zebrać powody, dla których dana historia poszła dobrze lub źle, aby zapewnić ciągłe doskonalenie.

Chcesz rozwijać się jako zespół? I wziąć pod uwagę najnowsze odkrycia psychologiczne? W takim razie polecamy Ci nasz warsztat zespołowy Retro Tool. Oto doświadczenia Holgera w tym zakresie:

Raport terenowy Holgera dotyczący narzędzia Team Workshop Tool

In a nutshell…

Iteracyjne podejście zespołów Scrum i ciągły przegląd potrzeb klientów pomaga uniknąć kosztów utopionych. Przyrosty produktu opracowywane w sprintach optymalnie nie powinny być zbyt zasobochłonne. Prowadzi to do tego, że zespół angażuje się w realizację nowych celów, gdy zmieniają się wymagania. Czy doświadczyłeś już problemu kosztów utopionych w swoim zespole? Spróbuj rozwiązać ten problem podczas retrospektywy i wspólnie opracujcie rozwiązania!

A jeśli interesuje Cię jeszcze więcej metod na zwiększenie swojej wydajności w zespole, możesz na przykład przeczytać o nich w naszym artykule Artykuł na temat niesamowitej prawdy kryjącej się za zwinnym sposobem myślenia spójrz.

Źródła

Arkes, H. R. & Blumer, C. (1985). Psychologia kosztów utopionych. Zachowania organizacyjne i ludzkie procesy decyzyjne, 35, 124–140.

Brockner, J. (1992). Eskalacja zaangażowania w nieudany sposób działania: w kierunku postępu teoretycznego. Przegląd Akademii Zarządzania, 17(1), 39-61.

Kahneman, D. & Tversky, A. (1979). Teoria perspektywy: analiza decyzji w warunkach ryzyka. Econometrica, 47, 262–291.