Wyobraź sobie, że otrzymujesz zadanie: nauczyć małpę stojącą na postumencie żonglować płonącymi pochodniami. Czy zaczniesz od budowy solidnej podstawy, czy od szkolenia małpy? Ten wybór może wpłynąć na końcowy sukces lub porażkę. A co, jeśli okaże się, że małpy w ogóle nie da się nauczyć żonglowania? W świecie biznesu, technologii, oraz życiu prywatnym, podobne dylematy zdarzają się często.
O co chodzi z tą małpą?
Nie chciałbym wyjść tutaj na dręczyciela zwierząt. Powyższe “zadanie” to tylko eksperyment myślowy, stosowany (kiedyś?) w Google. Podczas startu nowego projektu, zespół rozpoczynał analizę od zadania sobie pytania, co jest dla niego małpą, a co postumentem.
Celem takiego podejścia jest ustalenie, które elementy projektu są proste do wykonania, a które stanowią największe ryzyko lub niepewność.
Integracja pomiędzy systemami
Zostawmy na chwilę małpę i przenieśmy się do typowego wyzwania w programowaniu. Wyobraź sobie, że twój zespół ma zbudować aplikację, która połączy się z zewnętrznym API dostarczającym dane na temat upraw buraków cukrowych w Polsce.
Dzięki temu użytkownicy będą mogli zobaczyć szczegółowe dane na temat wielkości i lokalizacji upraw, wspomagani kolorowymi mapami, wykresami i tabelami. To pomoże im podjąć lepsze decyzje związane z zakupem tego warzywa do przetwórstwa lub wykorzystania w inny sposób.
Pierwszy krok w integracji
Najczęściej zaczynamy tworzenie aplikacji od określenia wymagań klientów i potencjalnego wyglądu naszej aplikacji. Problem pojawia się, gdy skupiamy się na pięknych interfejsach i wyborze narzędzi, zanim sprawdzimy, czy podstawowe dane są dostępne oraz istnieje grupa użytkowników, zainteresowanych naszym rozwiązaniem.
Co złego może się stać?
Po kilku miesiącach może okazać się, że API nie dostarcza potrzebnych danych, działa niestabilnie lub jest zbyt wolne, aby sprostać wymaganiom użytkowników. Takie problemy mogą znacząco utrudnić realizację projektu. W najgorszym wypadku może się nawet okazać, że jest on niemożliwy.
Dokumentacja API, na podstawie której przyjmuje się założenia, może nie wystarczyć.
Od czego naprawdę powinieneś zacząć?
Zamiast zaczynać od budowy podstaw, warto najpierw odpowiedzieć na pytanie: czy aplikacja w ogóle jest potrzebna i czy zewnętrzne API pozwoli ją zbudować?
Wracając do metafory z małpą, w pierwszym kroku trzeba się zastanowić, czy w ogóle da się ją nauczyć żonglerki. Budowę postumentu możemy sobie zostawić na później, gdy zweryfikujemy najważniejsze hipotezy. Tu ryzyko problemów jest znacząco niższe.
Dlaczego często zaczynamy od tego, co łatwe?
Dlaczego więc wiele inicjatyw w naszej branży zaczyna się od najłatwiejszej części? Powodów może być wiele.
Często chcemy pokazać biznesowi, managerom, lub innym interesariuszom, że coś już mamy. Z obawy przed porażką, która w najlepszym wypadku może zaowocować brakiem podwyżki lub awansu, zaczynamy od rzeczy prostych i przewidywalnych. W ten sposób, chcąc zmniejszyć ryzyko problemów, paradoksalnie możesz je znacznie zwiększyć
Takie działanie odracza problemy i daje chwilę oddechu, możliwość spokojnej pracy. Niestety, im bardziej taka sytuacja się przeciąga, negatywny efekt może zostać spotęgowany. Pokazywanie pięknych interfejsów użytkownika, gdy nie wiemy, czy aplikacja będzie działać, może wprowadzać w błąd interesariuszy.
Jeśli po pół roku ciężkiej pracy i pokazywania aplikacji powiemy, że jej główna planowana funkcjonalność jest trudna, lub niemożliwa do zrealizowania, ktoś może się zdenerwować. Zmiana kierunku na tym etapie będzie czasochłonna i kosztowna.
Zacznij od najtrudniejszego elementu
Podejście zwinne właśnie w tym celu promuje krótkie pętle uczenia. Warto je wykorzystać na początku do zweryfikowania, czy wybrany pomysł na realizację jest możliwy i czy ma sens.
W powyższym przykładzie można, bez budowania skomplikowanych interfejsów użytkownika, sprawdzić na prostych mockupach, czy aplikacja kogokolwiek zaciekawi. Zweryfikujesz w ten sposób, czy ktokolwiek będzie jej używać.
Z drugiej strony, po określeniu najbardziej podstawowych funkcjonalności, możesz zacząć od proof of concept i sprawdzić, czy zewnętrzne API umożliwia ich stworzenie. Następnie przejdź do kolejnych ryzykownych elementów.
Eksperyment i pętle uczenia
Frameworki zwinne, takie jak Scrum, zostały stworzone po to, by w krótkich iteracjach eksperymentować, weryfikować hipotezy i szybko zdobywać wiedzę o produkcie. Dzięki temu możemy wcześniej zrozumieć, czy obecny kierunek jest dobry, lub nie.
Jeśli wykryjesz, że dane podejście jest zbyt trudne, lub nawet nieosiągalne, możesz wykonać pivot. Ważne, aby zweryfikować to najwcześniej, jak to możliwe, unikając nadmiernych kosztów.
W ten sposób nie skończysz z inwestowaniem w coś, co strategicznie nie ma sensu.
Slack: historia sukcesu dzięki pivotowi
Jednym ze znanych przykładów udanego pivotu jest Slack – jeden z najpopularniejszych komunikatorów na świecie. Jego historia zaczęła się od wewnętrznego narzędzia stworzonego przez zespół pracujący nad grą MMO o nazwie Glitch.
Jeśli nazwa Glitch nic Ci nie mówi, to nie bez powodu – gra nie zdobyła wystarczającej liczby użytkowników, aby stać się dochodowym produktem. Twórcy gry zauważyli natomiast, że narzędzie do komunikacji zespołowej, które stworzyli na własne potrzeby, jest nie tylko użyteczne, ale także ma potencjał, aby stać się produktem rynkowym.
Tak narodził się Slack – efekt zmiany kierunku działania i szybkiej weryfikacji nowych możliwości. Obecnie komunikator jest używany przez miliony użytkowników na całym świecie.
Historia Slacka pokazuje, jak ważna jest szybka weryfikacja kluczowych hipotez. Gdyby zespół dalej inwestował czas i zasoby w projekt Glitch, zamiast szybko dostrzec jego ograniczenia, sukces w postaci nowego produktu mógłby nigdy nie nadejść.
Co jest twoją małpą, a co postumentem?
Gdy zaczynasz pracę nad nowych produktem, projektem lub dodaniem funkcjonalności do istniejącego rozwiązania, zastanów się, co w twoim przypadku jest największym wyzwaniem i od tego zacznij. To pozwoli uniknąć problemów i skuteczniej osiągnąć sukces.
Be First to Comment