Outcomes ponad outputs – to mantra, która w ciągu ostatnich kilku lat ogarnęła społeczność zajmującą się zarządzaniem i rozwojem produktów, a nawet doprowadziła do powstania książki, opisującej tę koncepcję. U podstaw tego stwierdzenia leży przekonanie, że dostarczanie coraz większej liczby funkcji produktu przez zespoły deweloperskie (output), nie jest dobrym sposobem na tworzenie świetnych produktów. Zamiast tego warto się skupić na wartości dla klienta (outcomes), a co za tym idzie dla firmy.

W tym artykule chciałbym Wam przybliżyć oba pojęcia i wyjaśnić, dlaczego outcomes są istotniejsze od output (choć oba pojęcia są bardzo ważne). 

Reklama



Będę używał angielskich słów outcomes i outputs, ponieważ polski odpowiednik dla obu jest taki sam – wynik.

Outcomes ponad outputs wywodzi się z myślenia, że skupienie się na wydajności lub „szybkości” ulepszania produktów (tego, co dostarcza zespół deweloperski, czyli outputs) jest krótkowzroczne. Koncentracja na outputs promuje sposób myślenia i kulturę „fabryki funkcji” (ang. Feature Factory), w której zespoły opracowujące produkty (np. deweloperskie) przypominają linię montażową, która jak najszybciej dostarcza funkcje, które zostały stworzone przez kogoś innego (np. “biznes”).

Stała presja, by dostarczać szybciej, przy niewielkim wpływie na to, co się dzieje sprawia, że ​​członkowie zespołu czują się jak trybiki w maszynie.

Jeszcze większym wyzwaniem jest to, że koncentracja na outputs jest nieskuteczna. Większość pomysłów (funkcji systemu / produktu) albo nie przyniesie wartości, albo nawet ją obniży. Stosowanie Feature Factory kończy się na wypuszczaniu szeregu funkcji, które mogą nie zapewnić wartości dla użytkownika, jednocześnie wypalając zespół nad nimi pracujący.

Z powyższych argumentów powstało stwierdzenie outcomes ponad outputs. Opiera się ono na uświadomieniu sobie, że tworzenie funkcji produktu (ang. feature), nie jest celem samym w sobie. Powinniśmy dążyć do poprawienia outcomes, czyli wartości, która jest dostarczana dla użytkownika końcowego lub firmy, w postaci np. przychodów.

Poniżej znajdziecie rysunek, zaczerpnięty z artykułu “Why “Outcomes Over Outputs” Is Flawed Advice” Jens-Fabiana Goetzmana, pokazujący korelację outputs i outcomes.

Czego brakuje na tym rysunku?

Inputs, czyli danych wejściowych. Jest to element, który daje nam “wsad” do działania, wytworzenia outputs. Inputs to informacje i procesy, które zasilają nasz Rejestr Produktu, które są wykorzystywane do generowania outputs (który z kolei tworzy outcomes).

Jeszcze jeden kontekst, bardzo istotny w tym modelu. Mianowicie chodzi o jakość pozyskiwanych informacji, zasilających “proces”.  Często im bardziej innowacyjny jest produkt lub wytwarzana funkcja, tym bardziej będzie istotna jakość danych wejściowych. Jest na to powiedzenie, które usłyszałem dawno temu (przepraszam z góry za dosadność) – shit in, shit out.

Jeżeli dane wejściowe będą słabej jakości, pomysł / funkcja, nad którą pracuje zespół może być kierunkowo poprawna, lecz jej implementacja może być wadliwa, prowadząc do niezrealizowanych wyników (outcomes). 

Z punktu widzenia rozwoju produktu, dane wejściowe (inputs) oznaczają wszystkie dane i badania, które wpływają na projektowanie i rozwój. Zarządzanie jakością tych danych jest często uwarunkowane jakością fazy discovery, czyli odkrywania potrzeb klienta i wywiadów, które będziemy z nim przeprowadzać (polecam kurs z metodyki Customer Development, dzięki której możemy realizować fazę discovery bardziej systemetycznie).

Informacja zwrotna

Mamy pełny obraz “procesu”, czyli dane wejściowe, wynik pracy zespołu w postaci outputs oraz outcomes, czyli jak wpływamy na naszego klienta.

Dobrym przykładem takiego podejście jest rysunek zamieszczony poniżej. Nie jest on związany z “produkcją” nowych funkcji systemu (rysunek pochodzi z assemblyresearchmatters.org).

“Proces” wymaga jeszcze jednego elementu – sprzężenia zwrotnego (ang. feedback loop), łączącego wyniki (outcomes) z danymi wejściowymi (inputs).

Oprócz danych wejściowych, outputs i outcomes ważne jest również aktywne zarządzanie pętlą informacji zwrotnej. Bazowanie na informacji pochodzącej z outcomes jest kluczowe, aby zarówno budować na osiągniętych sukcesach (wzmacniać je), jak i nie realizować powtórnie tych samych błędów (bazowanie na lessons learned). 

Bazowanie na informacjach pochodzących z outcomes wydaje się proste, gdy produkt jest opracowywany przez stabilny i mały zespół – członkowie zespołu będą z łatwością mieć dostęp do informacji zwrotnej. Jednak im większa staje się organizacja opracowująca produkt (np. kilka zespołów z różnych pionów, dywizji firmy), tym ważniejsze jest sformalizowanie tej pętli informacji zwrotnej i zarządzanie nią tak, aby zespoły i osoby mogły korzystać z informacji przez nią dostarczanej.

Przykłady działań i artefaktów (produktów) pętli informacji zwrotnej mogą obejmować takie rzeczy jak retrospektywy czy wyniki badań ilościowych i jakościowych.

Podsumowanie

Podsumowując, rozwojem produktów należy zarządzać za pomocą nakładów (inputs), produktów prac (outputs), wyników prac (outcomes) i uczenia się (feedback loop). Optymalizacja tylko jednego ze wskazanych elementów, nie poprawi całego procesu w dłuższej perspektywie.

Sztuką  jest również odpowiednie ustalanie priorytetów (kompromisów) między poszczególnymi elementami “procesu”, w zależności od okoliczności. Czy bardziej nas interesuje w tym momencie efektywność zespołu deweloperskiego, czy jakość fazy discovery? A może oba wskazane elementy? Czy mamy potrzebne “zasoby”, aby właściwie wesprzeć i realizować te elementy?

Ta strona używa Cookies, korzystając z niej wyrażasz zgodę na używanie ciasteczek zgodnie z ustawieniami przeglądarki. Nasza Polityka Prywatności
Akceptuję, bo lubię Was czytać.
x