Jak zespół produktowy przynosi wartość organizacji?

W trzynastym odcinku podcastu „Zwinne organizacje” Paweł Tomkiel zastanawia się nad tym, czym jest wartość. Przygląda się wartości z perspektywy organizacji. Składa się na nią kilka obszarów, jak przychód, marżowość, wydajność operacyjna, ale również wydajność tego, jak korzystamy z naszych zasobów oraz to, jak organizacja jest zarządzana i efektywna. Zapraszamy do wysłuchania odcinka.

Transkrypcja odcinka

Gdy posłuchacie trenerów zwinności, każdy będzie odmieniał wartość przez wszystkie przypadki. Tylko, co tak naprawdę jest wartościowe? Słuchasz podcastu Delloite „Zwinne organizacje”, gdzie wraz z naszymi gośćmi dzielimy się najlepszymi praktykami wdrażania metodyk zwinnych w pojedynczych zespołach, jak i całych organizacjach. Notatki do tego i innych odcinków znajdziesz na naszym blogu „Zwinne organizacje” na stronie delloite.com. Zaczynamy!

Cześć, nazywam się Paweł Tomkiel i jestem Agile Coachem w Delloite Digital. W dzisiejszym odcinku powiemy sobie trochę o tym, czym jest wartość, co jest wartościowe. Kiedy intuicyjnie słyszymy to słowo, słyszymy słowo wartość, to możemy się odnosić do wartości moralnych, do wartości etycznych, do wartości naszych, jako ludzi, ale dzisiaj przyjrzymy się wartości z perspektywy organizacji, bo to o zwinnych organizacjach tutaj rozmawiamy. I o ile jestem fanem definiowania przez organizacje misji, wizji, budowania kultury, definiowania takich wartości, które są w organizacji wyznawane, które tworzą jej trzon, o tyle wszystkie organizacje na świecie mają de facto jeden nadrzędny cel, którym są pieniądze i zwiększanie wartości dla udziałowców. No i na tą wartość składa się kilka de facto obszarów, składa się na to przychód, składa się na to marżowość, jakaś wydajność operacyjna, składa się na to również wydajność tego, jak korzystamy z naszych zasobów oraz wydajność całej organizacji, to, jak jako organizacja jest zarządzana, jak jest efektywna. I teraz, jeżeli spojrzymy na te cztery obszary z perspektywy zespołu Scrum’owego, z perspektywy zespołu produktowego, który chce być zwinny, zwinny po to, żeby szybko dostarczać wartość dla klienta końcowego czy dla organizacji, to jak tak naprawdę zespół ma na to wpływ?

Rzecz pierwsza, przychód

Jak zespół produktowy ma wpływ na przychód? Więc zespół produktowy w Scrumie, ogólnie w metodykach zwinnych, musi być cross funkcjonalny, czyli taki, gdzie jest w stanie sam zrealizować, sam rozwijać produkt, bez zbędnej kooperacji z innymi jednostkami. Komplet kompetencji jest w zespole, żeby rozwijać produkt. To jest pierwsza rzecz. Druga rzecz jest taka, że w takim zespole produktowym jest przedstawiciel biznesu, jest właściciel produktu, product owner, manager produktu, różnie są nazywane te stanowiska, ale cel de facto jest jeden, jest to osoba, która jest w stanie samodzielnie, jest do tego umocowana, jest w stanie podejmować decyzje o rozwoju produktu, o tym, w którym kierunku idziemy, jakie funkcje w nim wdrożymy, jak będziemy rozwijać, jaka jest road mapa rozwoju danego produktu. No i jeżeli mamy taki zespół cross funkcjonalny, jest na pokładzie manager takiego produktu, to widzimy, że może on mieć informacje, może on zbierać dane na temat tego, jak użytkownicy, jak klienci końcowi i to de facto też o to chodzi, jak klienci końcowi są zadowoleni z danego produktu, jak go używają, co jest dla nich najbardziej potrzebne. A to przekłada się na przychód poprzez przyciąganie nowych klientów, ale również utrzymanie tych istniejących. Badając ciągle network promoter score, NPS, widzimy, jak nasi użytkownicy są zadowoleni z naszego produkt. Zbierając od nich feedback, pracując z nimi nad nowymi funkcjami, jesteśmy w stanie lepiej ich rozumieć, więc jednocześnie przygotowywać produkt bardziej dopasowany do ich potrzeb, produkt, który będą chcieli chętniej kupować i będą z niego dłużej korzystać. W odcinku podcastu z Olą Korzunowicz czy z Maćkiem Malesą rozmawialiśmy o tym, jak mierzyć wydajność takiego zespołu produktowego. I jednym z takich mierników, który jest używany gdzieś w terenie, jest używany przez organizacje, jest na przykład przychód na pracownika, czyli taki współczynnik, którym mierzymy, czy nasz przychód rośnie równie szybko, co rośnie nasza organizacja, co rośnie ilość pracowników, ilość zespołów w całej organizacji. Może nie do końca jest to wskaźnik do mierzenia wydajności konkretnego zespołu, ale de facto do mierzenia wydajności produktu, patrzenia na ilość osób pracujących nad produktem i na przychodowość tego produktu, to już jest dużo lepszy współczynnik.

Rzecz druga, marża operacyjna

Czyli to, jak efektywnie produkujemy nasze produkty, wytwarzamy nasz produkt, bo odnoszę się tutaj do doświadczenia z produktami cyfrowymi. To tam, gdzie zwinność jest najczęściej używana, czyli w środowiskach informatycznych, w środowiskach programistycznych. Sama zwinność już u samych podstaw, pierwsze założenia zwinności to było zwiększyć zwinność, czyli zwiększyć szybkość rozwoju produktu. Ta szybkość jest zwiększana przez minimalizowanie jakichkolwiek strat, jakiegokolwiek waste’u, minimalizowanie zależności pomiędzy zespołami, ale również optymalizację samego procesu. To znaczy usuwanie tych wszystkich elementów procesu produkcyjnego, które nie są potrzebne. To, dlatego na przykład framework Scrum ma kilka elementów, z których każdy jest kluczowy i niemożliwy już dalej do usunięcia, ale jednocześnie stara się minimalizować na przykład liczbę spotkań po to, żeby zespół mógł się skupić na rozwoju produktu, a nie na składaniu kolejnych raportów, a nie na spotkaniach, które czasem dryfują bez celu. Dążenie jest również do tego, żeby pomysł, który się pojawia gdzieś w organizacji, pomysł na nową funkcję w produkcie, żeby był wdrażany jak najszybciej po to, żeby go szybko zweryfikować i sprawdzić, czy to jest dobra droga, również po to, żeby pomysł się nie zdezaktualizował. Możemy to na przykład nazwać lit time, od momentu pojawienia się w organizacji do wdrożenia do klienta końcowego. Też rozmawialiśmy o tym w odcinku z Maćkiem Malesą, gdzie czasem z perspektywy programistów od momentu, kiedy ktoś u nich coś zamawia, a to dostarczą, to może być kilka tygodni, ale z perspektywy całej organizacji, jeżeli ten proces jest wydłużony, powstaje szczegółowa estymata. Na samym początku, zanim to zostanie przekazane do działu deweloperskiego, potem są testy, to taki lit time może się wydłużyć nawet do roku. I zwinność przez umieszczenie wszystkich kompetencji na pokładzie zespołu oraz umieszczenie tego przedstawiciela biznesowego, czyli właściciela produktu, osoby umocowanej do podejmowania decyzji o produkcie, w ten sposób pozwala samemu temu małemu zespołowi do dziesięciu osób podejmować od razu wszystkie decyzje i wdrażać to, co uważają za najbardziej wartościowe. Więc jak widzimy, marża operacyjna jest podstawą dla zwinności. Jest tym, co jest de facto osiągane w pierwszej kolejności, kiedy stajemy się bardziej zwinni w organizacji.

Rzecz trzecia, wydajność korzystania z zasobów

Odnosimy się tu do przykładu produktów cyfrowych, do których uruchomienia zazwyczaj jest potrzebna po prostu infrastruktura, jakieś serwery, jakieś narzędzia, ogólnie technologiczne, więc kiedy mówimy tutaj o wydajności korzystania z zasobów, będę się odnosił przede wszystkim do wydajności korzystania z serwerów, z jakichś zasobów chmurowych do uruchomienia aplikacji. I zwinność ma tutaj też swoją odpowiedź, prawdopodobnie jest Ci znane pojęcie DevOps. DevOps, czyli taki zestaw praktyk, takie spojrzenie na zarządzanie infrastrukturą IT, które łączy, DevOps, łączy deweloperów i operatorów systemowych. Czyli to, co wcześniej było zamknięte w zespołach funkcjonalnych, czyli mieliśmy zespół deweloperów, który wytwarzał oprogramowanie, a potem zespół operatorów, który to oprogramowanie wdrażał na serwery. W DevOps programista od razu pisze aplikację ze świadomością tego, jak ona będzie działać na infrastrukturze, na konkretnych serwerach. Czyli jest rozbijany kolejny silos, jest tworzona synergia pomiędzy samym kodem a tym, jak on działa, na czym on działa. I to de facto podejście DevOps pozwoliło na tak zaawansowane korzystanie z chmury obliczeniowej. Chmura obliczeniowa, która na samym początku była po prostu skalowalnymi serwerami, czyli to, co wcześniej stało w serwerowni, serwer, stał się nagle skalowalny, mogliśmy zacząć do niego dokładać w locie, w trakcie działania dokładać procesory, dokładać RAM, dokładać przestrzeń dyskową. To był taki pierwszy etap działania chmury. To, gdzie doszliśmy teraz i pewnie to też jest temat na kolejny odcinek, ale doszliśmy teraz do momentu, gdzie mamy właściwie wszystkie funkcje udostępniane, jako usługi. To znaczy ja, jako programista mógłbym skorzystać z gotowych funkcji u różnych dostawców chmurowych, na przykład do przetwarzania obrazu, do analizy sentymentu osób, które są na danym obrazie, do translacji tekstu mówionego, do przepisywania tego tekstu od razu do bazy danych. Są gotowe usługi, z których programista może od razu skorzystać, tylko wymaga to od niego wiedzy o takich usługach i wiedzy, jak się z nimi połączyć. Gdybyśmy zostali w starym świecie, operator systemowy, który zarządza takimi usługami, zarządza infrastrukturą, musiałby sam modyfikować kod. Dlatego w podejściu DevOps znowu mamy zespół cross funkcjonalny, który tutaj działa na styku samego kodu i infrastruktury, na której on działa. A od chmury już jest naprawdę niedaleko do większej wydajności korzystania z zasobów, które ma organizacja, bo de facto przy korzystaniu z chmury obliczeniowej płacimy za to, czego używamy, płacimy za to, z czego korzystamy. Jeżeli nie korzystamy z jakiegoś serwera, możemy go po prostu wyłączyć. To nie jest możliwe w tradycyjnej serwerowni, gdzie kupiliśmy serwery na pięć lat w przód, mamy nadmiar tej mocy obliczeniowej, większość jest nieużywana przez większość czasu, ale czekają na jakiś plik, który się zdarzy na przykład w okolicy Świąt Bożego Narodzenia. I to zwinność, to podejście DevOps pozwala na skorzystanie z chmury, pozwala na korzystanie z niej w sposób zwinny, w sposób elastyczny i na płacenie tylko za to, co jest faktycznie potrzebne, na taką optymalizację kosztów tego, co jest konieczne do działania produktu. Temat chmury pewnie poruszymy jeszcze w innych odcinkach, ale już teraz widać, że ta wydajność korzystania z infrastruktury jest znacznie większa, jeżeli zaczniemy na to patrzeć holistycznie. Drugim aspektem zwinności i podejścia DevOps jest to, że automatyzujemy, co się tylko da. To znaczy usuwamy wszystkie czynności powtarzalne, które byłyby wykonywane przez ludzi i automatyzujemy nasz cykl wdrożenia, automatyzujemy to, co się dzieje z naszym kodem, to, co się dzieje z naszym produktem, tak żeby wdrożenie nie trwało tydzień, tylko żeby było możliwe kilka razy dziennie.

Rzecz czwarta, przewaga operacyjna

Jak zespół produktowy, jak zespoły zwinne mogą zwiększać przewagę operacyjną? Myślę, że w słowie zwinność jest to już od razu ukryte. Zwinność zakłada możliwość zmiany kierunku. Ta zmiana kierunku wynika najczęściej ze zmieniających się warunków, w jakich działa nasza organizacja, w jakich działa nasz biznes, co oznacza, że im szybciej będziemy w stanie dostosować nasz produkt do tego, jak zmienia się rynek, tym większą przewagę nad konkurencją zdobywamy. Jeżeli jesteśmy w stanie w przeciągu dwóch tygodni, w przeciągu miesiąca wdrażać nowe funkcje, odpowiadać na te potrzeby rynku, to ta przewaga konkurencyjna po prostu rośnie. Wracamy tu jednak do tego, co już powiedziałem na początku, mianowicie do tego, że potrzebujemy do tego zespołu produktowego, który jest cross funkcjonalny i który jest umocowany w postaci właściciela produktu, umocowany do podejmowania decyzji o produkcie. Bo jak mówiłem w jednym z poprzednich odcinków, to de facto czas podejmowania decyzji i wysokość struktury organizacyjnej potrafi znacząco nas opóźnić w dostarczaniu wartości w samym produkcie do użytkownika końcowego. Więc im szybciej jesteśmy w stanie podejmować decyzje o kierunku, tym szybciej jesteśmy w stanie odpowiadać na to, jak zmienia się nasz klient. I to jest właśnie sedno utrzymania przewagi konkurencyjnej.

Podsumowanie

Jestem ciekawy, jak Ty definiujesz wartość w swojej organizacji, co jest dla was wartościowe, jak mierzycie tą wartość. Odezwijcie się do nas przez naszego bloga „Zwinne organizacje” lub napiszcie do mnie ptomkiel@deloittece.com. A jeżeli chcesz posłuchać więcej o tym, co było dzisiaj wspomniane, to po pierwsze zasubskrybuj nasz podcast i będzie to rozwijane w kolejnych odcinkach, ale zapraszam Cię też do odcinka z Maćkiem Malesą i odcinka z Olą Korzunowicz, gdzie rozmawialiśmy o mierzeniu wydajności zespołów Scrum’owych, a także do odcinka o planowaniu rocznym, gdzie było trochę powiedziane o tym, jak czas decyzji managementu może znacząco wpłynąć na zmniejszenie zwinności organizacji. Do usłyszenia!