Wszystko na raz
Nasz pierwszy pomysł na aktualizację strony brzmiał mniej więcej tak: „odświeżymy grafikę i za miesiąc podmienimy całą stronę”. Dwa miesiące później mieliśmy dużą ilość pomysłów, sporo mockupów i trochę prawie działającej funkcjonalności. Po raz kolejny udowodniliśmy, że podejście „dostarczmy wszystko na raz” słabo się sprawdza z kilku powodów:
- Użytkownicy i klienci muszą długo czekać na efekt końcowy
- My nie mamy żadnej informacji zwrotnej
- Narastają ryzyka związane z zależnościami między poszczególnymi funkcjonalnościami nad którymi pracujemy
- Nie bardzo wiemy, ile nam jeszcze zostało pracy. Prawie zawsze wygląda na to, że „prawie już skończyliśmy”.
- Jeżeli nie pójdziemy na produkcie to tak naprawdę nie mamy pewności czy dana funkcjonalność działa czy nie.
- Próbujemy pracować nad wszystkimi funkcjonalnościami równocześnie, co oznacza, że nic nie jest tak naprawdę ważne.
Jednak czasami rzadkie relesowanie może mieć sens. Pracowałem kiedyś z klientem, którego system jeździł w ciężarówkach po całej Europie, a aktualizacja wiązała się z kosztownym przesłaniem paczki przez GPRS. W innych przypadku może rozbić się o regulacje np. finansowe.
Częste Wydania
Po nieudanej próbie dostarczenia wszystkiego zdecydowaliśmy się zacząć podmieniać stronę po kawałku. Na początek zdecydowaliśmy się na bloga. Stało za tym kilka powodów. Po pierwsze, na starej stronie był dość mocno ukryty. Po drugie, blog nie jest krytyczną częścią naszej strony, więc ewentualne problemy nie będą dla nas zabójcze w skutkach. Po trzecie, stara wersja była mało czytelna, więc zmiana powinna zwiększyć zainteresowanie naszym blogiem. Od tego czasu co tydzień staraliśmy się podmieniać jakąś część naszej strony. Oczywiście przez chwilę miało to wadę, że użytkownik mógł kilka razy przechodzić ze starej na nową i na odwrót. Ale w zamian:
- Daliśmy lepszy produkt użytkownikom
- Dostaliśmy od nich informację zwrotną
- Skupiliśmy się na najważniejszych rzeczach
- Czuliśmy lepszą motywację do pracy, wiedząc, że najpóźniej za tydzień znów idziemy na produkcję
- Z dużo większą łatwością planowaliśmy naszą pracę
Jeżeli tylko możesz idź na produkcję jak najczęściej. Super, jeżeli co iteracje, jeszcze lepiej – kilka razy w trakcie iteracji. Twoje praktyki inżynieryjne (brak automatyzacji testów, skomplikowane środowisko, zależności, niepraktyczne środowisko wersjonowania) mogą Ci to utrudniać. Ale jeżeli inne firmy to potrafią, co stoi na przeszkodzie Wam?
Minimal Viable Product (MVP)
MVP to najtańszy, najprostszy eksperyment, który pozwoli nam zebrać informacje o potrzebach i zachowaniach naszych użytkowników. W naszym przypadku są to krótkie wpisy na bloga, których ostatnio dodajemy dość sporo, żeby zobaczyć co Was najbardziej interesuje. Staramy się następnie rozwijać nasze produkty w tym kierunku. MVP mogłoby też być np. utworzenie strony ze szkoleniem, żeby zobaczyć czy ktoś w ogóle na nie zagląda.
MVP często jest mylone z pierwszym releasem produktu. Tymczasem wcale nie musisz mieć produktu, żeby sprawdzić swoją hipotezę. Czasami wystarczy popytać swoich użytkowników. Dlatego MVP stosujemy, gdy nie jesteśmy pewni czy:
- dobrze zidentyfikowaliśmy potrzeby naszych użytkowników
- nasz produkt adresuje te potrzeby
- nasi klienci są gotowi zapłacić za ten produkt
- możemy skalować nasze rozwiązanie.
