Czasem pytacie nas, w jaki sposób zaprojektować swoją aplikacje. Skąd wiedzieć, jakie powinna mieć funkcje i na czym się skupić.
Nie tylko kod!
Po co? Dlaczego? Jaki cel biznesowy temu przyświeca? To są naprawdę kluczowe zagadnienia dla każdego projektu oprogramowania. Jak dobrze zmapować pomysł na aplikację? Albo, co powinienem rozumieć z dokumentacji od klienta? Obecnie, coraz większy nacisk kładzie się na zrozumienie potrzeb biznesu przez programistę — dzięki temu, nie koduje on “bezmyślnie” wg dokumentacji, a swoimi rozwiązaniami stara się zrealizować cele i zaspokoić potrzeby klienta. Jeśli więc rozpoczynasz nowy projekt dobrze zmapować go i uporządkować informację, a jeśli to Ty jesteś autorem pomysłu, powinieneś umieć dokładnie go przeanalizować. Brzmi jak wyzwanie? To nie takie trudne, bo możemy skorzystać z super narzędzia — Lean Canvas.
Lean Canvas
To nic innego jak prosta tabela, której uzupełnienie zmusza Cię do przeanalizowania pomysłu na projekt. Dzięki temu, lepiej zrozumiesz jego sens, a być może zmienisz jego założenia, by skupić się na realizowanym celu. Zacznijmy jednak od początku — w każdym mądrze realizowanym projekcie powinnaś na początku pomyśleć o potrzebach klienta/użytkownika. Potrzebach, a nie rozwiązaniach, gotowych metodach. Na to przyjdzie czas potem. Chcę i potrzebuję to nie to samo!
Wróćmy więc do Lean Canvas. To proste narzędzie do projektowania aplikacji, autorstwa Ash Maurya, który inspirował się narzędziem Business Canvas Model. Poniżej możesz zobaczyć jak wygląda.
Przejdźmy do opisu poszczególnych pól.
Problem
Opisuje problem/ realną potrzebę użytkownika. Autor zaleca, by wypisać ich 3 lub więcej. Pamiętaj, że problemem użytkownika rzadko jest brak aplikacji do …, a częściej brak czasu na zrobienie tego ręcznie, brak motywacji do …, natłok informacji o …, brak informacji o… itp. To nie jest pole w którym 1:1 opisujesz swój pomysł! Wejdź w buty osoby, której potrzeby będzie realizować Twoja aplikacja i zastanów się czego konkretnie potrzebuje, i dlaczego, teraz jest właśnie tak jak jest.
Tutaj jest też miejsce na opisanie istniejących rozwiązań/alternatyw do twojej aplikacji.
Customer Segments
Kim jest Twój klient(a nie użytkownik, mówimy tu o osobie, która płaci za produkt, w modelu open source możesz skupić się na użytkowniku)? Wymieniasz grupy, które mają opisane wcześniej potrzeby. Pamiętaj by robić to dokładnie. Młodzi ludzie — to zbyt ogólna informacja, która nie ułatwi Ci stworzenia fajnego rozwiązania. Pomyśl o tym, co robią, w jakim są wieku, gdzie mieszają, jak wygląda ich dzień — poznaj swojego potencjalnego klienta. Pamiętaj, że zbyt uniwersalne rozwiązania się nie sprawdzają! Twój klient nie może być każdym, musi być kimś konkretnym. Nie bój się wyszczególnić kilku grup, a jeśli są bardzo różne przygotuj osobne tabele dla każdego z nich.
Poza klientami, warto pomyśleć o użytkownikach. Np. platforma Worpress — jej klientami są blogerzy, użytkownikami czytelnicy — część potrzeb klientów nie będzie potrzebą użytkowników (np. interfejs graficzny do tworzenia wpisów interesuje tylko blogera).
W końcu, warto zastanowić się, która z grup klientów będzie tzw. early adopters, czyli sięgnie po nasz produkt stosunkowo szybko.
Solution
Czas na opis funkcjonalności — skupmy się jednak na tych główny. Co Twoje rozwiązanie daje klientowi?
Unique Value Proposition (Value)
Jaką niepowtarzalną korzyść dostarczasz swojemu klientowi? To, tak naprawdę jedno z najważniejszych pytań dla Twojego projektu. Co stanowi o wyróżniku, efekcie wow, dlaczego mamy wybrać właśnie ten produkt? Jest to potrzebne również do dobrego marketingu twojej aplikacji.
Channels
To nic innego jak sposoby pozyskania klientów. O nich również powinieneś pomyśleć. Przykładowo, jeśli chcesz mocno reklamować swoją aplikację w Social Media może warto przygotować odpowiedni sposób zakładania konta zintegrowany np. z facebookiem? A jeśli twoimi odbiorcami są np. inni programiści to już teraz warto pomyśleć jak im przedstawisz swoją aplikację.
Revenue
Czyli przychody, sposób w jaki aplikacja ma na siebie zarabiać. W szczególności w przypadku samodzielnych projektów warto o tym pomyśleć, i opracować (bądź nie, założyć, że aplikacja jest open source) sposób zarabiania.
Costs
Koszty związane z projektem. Warto wziąć pod uwagę, nawet w małym prywatnym projekcie — serwery, licencje itp. Wszystko kosztuje i dobrze wiedzieć ile nas to wyniesie. W kosztach powinno się też ująć wszystko to, co nie jest związane bezpośrednio z programistyczną pracą jak np. promocja, księgowość itp.
Key Metric
W jaki sposób zmierzysz sukces swojej aplikacji? Ilością pobrań, użytkowników, znalezieniem nowej pracy ;) czy może poprzez ilość wykupionych subskrybcji? Warto określić to na początku i zawsze mierzyć.
Unfair Advantage
Wyróżnik Twojego projektu, który ciężko skopiować konkurencji. Tak, nie zawsze będziesz w stanie go podać, jednak jeśli znalazłaś coś, co powoduje, że pozytywnie odstajesz od innych, warto to podkreślić!
Jak pracować?
Pamiętaj, że Lean Canva to narzędzie, możesz więc iteracyjnie weryfikować założenia swojego projektu. Kreślić, zmieniać. Warto mieć je zawsze przy sobie, by mieć pewność, że rozumiesz, co tworzysz. My z Buisness Model Canvas i Lean Canvas korzystaliśmy wielokrotnie, chociażby projektując tego bloga, czy przy pisaniu mojej pierwszej aplikacji. Ja sama, czuję się o wiele pewniej, gdy rozumiem cel tego, co tworzę. Dlatego w codziennej programistycznej pracy próbuję właśnie w taki sposób mapować sobie aplikacje i wyciągać potrzeby, na które mój kod będzie odpowiadał.
Poniżej link do wersji online. Spróbujesz wykorzystać Lean Canvas w swojej pracy?
https://canvanizer.com/new/lean-canvas
A więcej o pracy z Lean Canvas znajdziesz w świetnym manualu: http://startangels.ch/downloads/LeanCanvasInstructions.pdf
PS. Jak pewnie wiesz, w tym tygodniu można na nas głosować w konkursie na Blog Roku. O swojej motywacji do konkursu napisaliśmy tutaj, jeśli podoba Ci się to, co robimy, prosimy o SMS o treści E11382 na numer 7124. Dzięki!
