Programiści mają tendencję do skupiania się wyłącznie na samej technologii, designerzy na wyglądzie i UX, a modni ostatnio Scrum Masterzy na procesie wytwarzania oprogramowania. W efekcie często zdarza się, że każdy zajmuje się tylko swoją działką i zespół nie bardzo potrafi razem pracować na jeden najważniejszy cel, który dodatkowo często nie jest jasny.
Jak organizować zespół?
Dobrym rozwiązaniem w/w problemów jest rygorystyczne mierzenie wyników i organizowanie całej pracy wokół wspólnego celu. Cel ten musi być wyrażony liczbowo (skwantyfikowany), jako dobrze określony wskaźnik, mierzony i publicznie udostępniony całemu zespołowi. Przykładowy schemat organizacji zespołu wygląda następująco:
- Każdy tydzień zaczynamy planowaniem, na którym ustalamy co możemy zrobić, żeby poprawić wskaźnik, a kończymy podsumowaniem i sprawdzeniem, jak nasz wskaźnik zmienił się w wyniku pracy zespołu w ostatnim tygodniu.
- W ten sposób każdy tydzień to jeden lub kilka eksperymentów, które sprawdzają czy przybliżamy się do osiągnięcia naszego celu.
- Z czego mogą składać się eksperymenty? Mogą to być nowe funkcjonalności (lub prototypy nowych funkcjonalności), zmiany na landing page mające na celu poprawienie konwersji, zmiany w prowadzonych kampaniach reklamowych, czy nowe treści w serwisie. Wszystkie chwyty dozwolone. Byle przybliżyć zespół do celu.
Schemat: organizacja pracy w startupie
Pozostaje nam pytanie – co i jak mierzyć?
Odpowiedź na to pytanie może dać model Lean Analytics, który jest rozszerzeniem metodyki Lean Startup. Został on stworzony i opisany przez Alistaira Crolla i Benjamina Yoskovitza w książce “Metoda Lean Analytics”. Jest ona świetnym źródłem inspiracji przy organizacji zespołu startupowego.
Pierwszą istotną rzeczą do uświadomienia sobie jest fakt, że startup na wczesnym etapie ma z zasady ograniczone zasoby. Dlatego cały zespół powinien optymalizować tylko jedną metrykę. Ktoś może zapytać – tylko jedną?! Odpowiedź brzmi: tak, tylko jedną! Drugie pytanie, na które musimy sobie odpowiedzieć to: co mierzyć? A to zależy głównie od dwóch czynników – jaki produkt tworzymy (kategoria produktu) i na jakim etapie jesteśmy.
Engagement i churn
Jak mierzyć zaangażowanie? Na przykład analizując jaki procent użytkowników, którzy się zapisują np. do naszego newslettera wraca i korzysta z produktu chociaż raz w kolejnym tygodniu/miesiącu.
ENGAGEMENT = Ureturning / Utotal
Gdzie Utotal to liczba nowych użytkowników w danym przedziale czasu, a Ureturning to liczba nowych użytkowników w danym przedziale czasu, którzy powrócili w ciągu tygodnia/miesiąca.
Jak mierzyć drugi wskaźnik, czyli churn? Sprawdzając jaki procent użytkowników rezygnuje/wypisuje się z naszego produktu (np. rezygnuje z płatnej subskrypcji).
CHURN = Ucanceled / Uall
Ucanceled liczba użytkowników, którzy anulowali swoją subskrypcje w danym miesiącu. Uall – liczba wszystkich użytkowników, którzy posiadają subskrypcje w danym misiącu.
CAC i CLV
Na późniejszych etapach możemy mierzyć koszt zdobycia klienta i jego wartość dla firmy (odpowiednio: CAC – customer acquisition cost oraz CLV – customer lifetime value). Te dwa wskaźniki, będą definiować dochodowość naszego biznesu. Przyjmuje się, że mamy obiecujący model biznesowy, jeśli:
CLV > 3 x CAC
Żeby lepiej rozumieć jak nasz produkt się rozwija, na późniejszych etapach działania firmy, powinniśmy mierzyć już wiele wskaźników, a do każdego zespołu może być przypisane kilka metryk. Trzeba jednak uważać by Data Driven Development nie zamienił się w znany z korporacji KPI Driven Development.
Witamy w epoce post-agile
Celem zespołu startupowego jest dowiezienie wyników, a nie funkcjonalności, designu czy innych elementów. Zwróćmy zatem uwagę, że tak popularny ostatnio Scrum, który koncentruje się na dostarczeniu działającego oprogramowania, niekoniecznie jest najlepszym wyborem dla startupu. Jako, że metody zarządzania w startupach, często przechodzą później do “mainstreamu”, możemy powoli zacząć mówić o początku nowej epoki w wytwarzaniu oprogramowania: post-agile lub epoce Lean Startup, w której data driven development jest standardem, a sam działający software nie wystarczy.
Marek Kirejczyk
Dyrektor techniczny w firmie DaftCode, specjalizującej się w tzw. venture building – realizowaniu przedsięwzięć startupowych. Specjalista od zarządzania firmami informatycznymi. Propagator wiedzy o Agile i Lean Startup.
