Zaraz po studiach pracowałem w dużej międzynarodowej korporacji. Projekt, do którego trafiłem uważałem za wzorowego Scruma. Przestrzegaliśmy wręcz książkowo wszystkich praktyk ze Scrum Guida. Byliśmy bardzo zmotywowani i zaangażowani. Potrafiliśmy z dużą dokładnością określić swój commitment1 na następny Sprint. Product Owner często powtarzał, że jest bardzo zadowolony z szybkich postępów prac i jej jakości. Zarówno samoorganizujący się zespół jak i proces wytwarzania softu były na bardzo wysokim poziomie. Management często nas chwalił i stawiał za wzór. Dopiero po kilku latach dotarła do mnie smutna refleksja. To co 20 osób w pocie czoła robiło przez ponad dwa lata i kosztowało miliony dolarów nie miało kompletnie sensu! W naszym dziale od wielu lat istniała już aplikacja, która robiła coś bardzo podobnego do naszej. Jak łatwo się domyśleć szybko wytworzyła się niepotrzebna rywalizacja w walce o userów i dwa standardy – kompletny waste!
Niestety w projektach IT bardzo często zapomina się o aspektach biznesowych. Cała uwaga jest skupiona na tym, jak wykonać projekt, natomiast nikt, łącznie z Produkt Ownerem/Project Managerem, nie potrafi odpowiedzieć na kluczowe pytania: „Jaki problem rozwiązuje aplikacja?”, „Co wyróżni nas od konkurencji?”, „Dla kogo ją tworzymy?” oraz „Jak aplikacja będzie na siebie zarabiać?”. Pominięcie obszaru biznesowego często prowadzi do katastrofy. Projekt jest uznany za sukces, natomiast jego rezultat nie przynosi większej wartości albo jest nawet szkodliwy.
Strategia biznesowa w projekcie IT to konieczność. Lean Canvas to proste narzędzie, dzięki któremu można jej podstawową formę mieć już w około godziny. Jest to tabelka wydrukowana na kartce A4. Aby ją wypełnić trzeba znaleźć odpowiedzi z 9 kluczowych dla biznesu obszarów. Jeżeli jesteś w stanie to zrobić, możesz powiedzieć, że rozumiesz strategię biznesową danego produktu. Lean Canvas do druku
Bardzo często doradzam Product Ownerom/Project Managerom, aby razem ze Stake Holderami2 wspólnie uzupełnili Lean Canvas. Zazwyczaj okazuje się, że ich punkty widzenia są rozbieżne. Jest to świetna okazja, aby razem je uwspólnić. Największa jednak wartość Lean Canvas objawia się w momencie gdy wychodzi na jaw, że niektóre istotne kwestie nigdy nie były brane pod uwagę, np. jakie metryki należy badać, aby określić sukces projektu.
Wyniki ustaleń warto przedstawić deweloperom albo jeszcze lepiej, zaprosić ich do wspólnego ze Stake Holderami warsztatu. Większa świadomość biznesowa programistów zawsze przekłada się na software lepiej spełniający potrzeby biznesowe. Realnie zwiększa to szanse na sukces projektu.
Czasami po wypełnieniu Lean Canvas możemy dojść do wniosku, że projekt nie ma sensu. Dobrze to wiedzieć jak najwcześniej. Można zaoszczędzić dużo pieniędzy i rozczarowań.
***
Poniżej znajduje się opis krok po kroku, jak uzupełnić Lean Canvas. Przykładowe wpisy pochodzą z projektu, w którym pracowałem jako konsultant. Zarówno ja jak i Product Owner byliśmy w tym projekcie dopiero od tygodnia. W przeciągu godziny strategia biznesowa była dla wszystkich jasna.
1. Problem
Należy określić cel tworzenia aplikacji z punktu widzenia ostatecznych użytkowników. Definiuje się to poprzez zdefiniowanie problemów, które będą za jej pomocą rozwiązywane.
Pytania pomocnicze:
– Jakie problemy usera rozwiąże stosowanie produktu?
– Co dzięki Twojej aplikacji zmieni się w życiu użytkownika ?
Przykład:
– Kibice (piłki nożnej) nie zawsze mogą oglądać mecz np. są w pracy albo w podróży, ale chcą doświadczyć emocji z tym związanych
– Kibice chcą być na bieżąco z wynikami meczy podczas: turniejów, ligi
– Kibice chcą uczestniczyć w życiu klubu również poza meczami (np. chcą poznać informacje o nowym zawodniku)
Warto w tym miejscu zadać sobie dodatkowe pytanie: „Jaka aplikacja na rynku już rozwiązuje te problemy?”. Być może rozpoczynanie projektu nie ma najmniejszego sensu.
2. Customer Segments
Określenie, kto będzie używał naszego produktu. Jeżeli wiemy dla kogo robimy produkt mamy większą szansę, że spełnimy jego oczekiwania.
Pytania pomocnicze:
– Kim są użytkownicy Twojej aplikacji ?
– Kto będzie korzystał z Twojej aplikacji ?
Przykład:
– Arabowie: Obywatele Arabii Saudyjskiej i Bliskiego Wschodu
– Priorytet: Mężczyźni w wieku 16-25 lat
– Drugi priorytet: Mężczyźni w wieku 26-38 lat
3. Unique Value Proposition
Należy określić przewagę konkurencyjną aplikacji. Czyli co ona będzie posiadać czego nie ma konkurencja. Jeżeli produkty konkurencji będą lepsze od naszego, nie wygramy z nimi walki o użytkowników i projekt zakończy się porażką.
Pytania pomocnicze:
– Co czyni Twoją aplikację wyjątkową ?
– Co ma Twoja aplikacja czego nie mają inne ?
– Dlaczego powinienem użyć akurat Twojej aplikacji ?
– Wymień proszę 2-3 aplikacje na rynku które rozwiązują już problemy o których wspomniałeś. Co będzie miała Twoja aplikacja, co pokona konkurencję ?
Przykład:
– Piękny wygląd
– Posiada intuicyjny UX – nawet osoby powyżej 38 lat potrafią jej użyć. Konkurencyjne produkty są bardzo skomplikowane
– Jest w języku arabskim i angielskim. Konkurencja obsługuje tylko angielski.
– Aplikacja jest dostosowana do potrzeb i gustów Arabów
– Dane są potwierdzone przez Opta – gwarancja wiarygodności statystyk
4.Solution
Są to najważniejsze elementy produktu. To im trzeba nadać najwyższy priorytet i wydać MVP3 tylko z nimi.
Gdy zagrożony jest deadline, pierwsze co można zrobić to przesunięcie mniej istotnych funkcjonalności na kolejne releasy. Niestety jeżeli mniej istotne funkcjonalności są już wykonane może nie starczyć czasu na te „must have”. Dlatego prawie zawsze jest wskazane zaczynać pracę od najwyższych priorytetów.
Pytania pomocnicze:
– Jakie funkcjonalności w aplikacji są kluczowe ?
– Jakie funkcjonalności w aplikacji dadzą największą wartość użytkownikom ?
– Bez których funkcjonalności aplikacja dalej mogłaby istnieć ?
– Bez których funkcjonalności aplikacja pod żadnym pozorem nie może zostać wydana ?
Przykład:
– Natychmiastowe powiadomienie o strzeleniu przez drużynę gola
– Niezawodne push notyfikacje – informacja o zdarzeniu w czasie meczu przesyłana musi być w ciągu kilku sekund (karny, bramka, rzut rożny)
– Dostęp do statystyk z najważniejszych lig piłkarskich Arabii Saudyjskiej i Bliskiego Wschodu
5. Channels
Sposoby na dotarcie do end-userów. Często spotykam się z sytuacją, że została stworzona bardzo dobra aplikacja, jednak mało kto o niej wie. Marketing i reklama jest często kluczem do sukcesu projektu.
Pytania:
– W jaki sposób planujesz dotrzeć do klientów ?
– Co umożliwi/ułatwi Ci dotarcie do klientów ?
Przykład:
– Informacje w social media, np. Facebook
– Filmiki video o tematyce piłkarskiej z info o aplikacji na końcu
– Gwiazdy piłki nożnej zostaną wynajęte do reklamowania aplikacji
6. Unfair Advantage
Należy określić, jakie „asy w rękawie” będziemy mieli poza samą aplikacją.
Pytanie pomocnicze:
– Zakładając, że konkurencja wykradła Ci pliki źródłowe i wydała aplikację identyczną z Twoją. Co będziesz miał Ty, czego nie będzie miała konkurencja ?
Przykład:
– Baza 600k użytkowników (z istniejącej już innej aplikacji)
– Posiadamy uznaną markę w Arabii Saudyjskiej od 2011 roku
7. Revenue Streams
Źródła przychodów. Trzeba jak najszybciej określić, skąd będziemy mieli w projekcie pieniądze na jego prowadzenie oraz jak produkt będzie zarabiał w przyszłości.
Pytania pomocnicze:
– W jaki sposób planujesz zarabiać na aplikacji ?
– Jak aplikacja może na siebie zarobić ?
Przydkład:
– Mamy dwóch sponsorów – jeżeli ich potrzeby zostaną spełnione to będą nam płacić
– Bannery reklamowe w aplikacji
– Płatna wersja aplikacji – z dodatkowymi funkcjonalnościami
8. Cost Structure
Wszystkie koszty jakie będziemy musieli pokryć. Zbyt duże koszty to najczęstsza przyczyna porażki start’upów. Warto więc bardzo dokładnie przeanalizować, które koszty są konieczne, a których warto uniknąć. Na pewno trzeba o nich wiedzieć, aby zaplanować budżet. Czasami z niektórymi inwestycjami (np. zwiększenie zespołu) lepiej poczekać, aż aplikacja zacznie przynosić dochody.
Pytania pomocnicze:
– Jakie koszty będziesz musiał pokrywać w czasie tworzenia produktu ?
– Jakie koszty będziesz musiał pokrywać po wydaniu produktu na rynek ?
– Które koszty są niezbędne – nie da się ich usunąć ?
– Które koszty można zmniejszyć albo przesunąć w czasie ?
Przykład:
– Amazon Web Services
– PushWoosh
– Serwery
– Zespół deweloperski
– Zarządzanie contentem aplikacji
– Publikowanie newsów w mediach społecznościowych
– Tworzenie video (przyszłość)
– Social Media Manager (przyszłość)
9. Key Metrics
Kluczowe wielkości, które określają sukces naszego przedsięwzięcia. Jeżeli nie potrafimy dokładnie określić po czym poznamy sukces projektu, nawet nie będziemy wiedzieć, że idziemy w złym kierunku.
Pytania pomocnicze:
– Po czym poznasz, że aplikacja osiągnęła sukces ?
– Podaj proszę aplikację, która jest obecnie dla Ciebie największą konkurencją. Po czym poznajesz, że ta aplikacja osiągnęła sukces ?
Przykład:
– Ilość pobrań z App Store (w przyszłości również Android Market)
– Ilość aktywnych użytkowników którzy używają aplikacji
Terminologia:
1. W Scrum Guide w momencie gdy prowadzony był opisywany projekt nie było jeszcze pojęcia „forecast” tylko „commitment”.
2. Stake Holder to inaczej interesariusz, czyli osoba, której decyzje mają wpływ na kierunek rozwoju produktu. Może to być np. klient software house’u.
3. MVP (minimum viable product) – wersja produktu posiadająca tylko te funkcjonalności, które są niezbędne, aby uzyskać informacje od użytkowników czy rozwój aplikacja idzie we właściwym kierunku. Pozwala to na szybki feedback od użytkowników i szybkie dostosowanie dalszego developmentu, aby aplikacja była dla nich atrakcyjna.