Jak prowadzić projekt szybkiego prototypowania
Szybkie prototypowanie może być pomocnym narzędziem dla nas, kierowników projektów cyfrowych, pomagającym klientom, którzy zadają pytania: „Ale czy to zadziała?” oraz „Jak to będzie działać?”. Często prosta, choć frustrująca odpowiedź brzmi po prostu: „Jeszcze nie wiemy — ale pozwól nam pomóc ci to ustalić”. Świetnym sposobem na znalezienie odpowiedzi, który zyskuje coraz większą popularność wśród agencji i klientów, jest szybkie prototypowanie — niewielka inwestycja pozwalająca podjąć świadomą decyzję dotyczącą zasadności produktu przed dokonaniem większych inwestycji.
Nasza branża rozwija się z zawrotną prędkością, a jako kierownicy projektów cyfrowych musimy szybko dostosowywać się do nowych sposobów pracy. Aktualnym przykładem jest szybkie prototypowanie. Dziewięć miesięcy temu nigdy nie pracowałem nad projektem szybkiego prototypowania, a teraz właśnie zakończyłem mój czwarty projekt tego typu, którego celem było szybkie przetestowanie zasadności produktu. Jeśli więc jeszcze nie pracowałeś nad projektem szybkiego prototypowania, nie mam wątpliwości, że taki projekt jest tuż za rogiem.
Ten wpis wyjaśnia różne sposoby badania zasadności produktu i przedstawia kilka zasad, które pomogą ci z pewnością siebie zarządzać szybko zmieniającymi się projektami cyfrowymi lub analogowymi.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Ale najpierw: czym jest szybkie prototypowanie?
Szybkie prototypowanie odnosi się do procesu stosowanego przy tworzeniu weryfikacji koncepcji lub szybkich prototypów. Prototyp dobrze sprawdza się przy testowaniu słuszności koncepcji. Pozwala opracować więcej funkcji i zrobić to szybciej, ale zwykle odbywa się to kosztem jakości, dlatego produkt będzie w większości przypadków przeznaczony do wyrzucenia.
Prototypy mają różne kształty i rozmiary
Chociaż istnieją różne sposoby badania zasadności produktu, oto trzy wyraźnie odmienne podejścia:
- Weryfikacja koncepcji – Weryfikacja koncepcji to bardzo uproszczony, jednorazowy demonstrator produktu, którego celem jest przetestowanie idei stojącej za produktem przed jego zbudowaniem.
- Szybki prototyp – Szybki prototyp to uproszczona pierwsza wersja produktu, którą można przetestować z rzeczywistymi użytkownikami, aby zwiększyć pewność co do produktu przed stworzeniem jego pełnej wersji.
- Minimalny opłacalny produkt (MVP) – MVP to pierwsza wersja produktu o jakości produkcyjnej, zawierająca w pełni działające funkcje dla użytkowników.
To, które podejście należy wybrać, powinno zależeć przede wszystkim od poziomu pewności co do produktu.
Im bardziej ryzykowny pomysł, tym szybciej należy działać.
Niektórzy mogą powiedzieć, że jeśli pomysł jest ryzykowny, należy poświęcić więcej czasu na przemyślenie go przed rozpoczęciem budowy. Pod pewnymi względami mają rację. Można zweryfikować potrzebę niemal bez tworzenia czegokolwiek. Istnieje wiele przykładów testów walidacyjnych, które warto przeanalizować.
Jednak gdy już wiesz, że istnieje taka potrzeba, jedynym sposobem, aby ją potwierdzić, jest zbudowanie czegoś, udostępnienie tego tak szybko, jak to możliwe, w najbardziej surowej formie, zebranie opinii i wprowadzenie kolejnych iteracji. Wielokrotnie przekonaliśmy się, że podczas badania pomysłu klient nieuchronnie mówi: „Kupiłbym to”, a gdy produkt trafia na rynek, sprzedaż nie rusza.
„Zdecydowanie bym to kupił” — 100 osób
Osoby, które rzeczywiście to kupią = 10
Jeff Sheldon (@ugmonk) September 1, 2016
Szybkie prototypowanie za każdym razem ogranicza ryzyko, skracając pętlę informacji zwrotnej i zapewniając, że tworzysz produkt, który będzie się sprzedawał.
Jak dowiedzieć się, które rozwiązanie jest dla ciebie odpowiednie
| Styl prototypowania | Pewność | Jak bardzo pozorowany | Jak bardzo jednorazowy |
|---|---|---|---|
| Weryfikacja koncepcji | Niska | Całkowicie | Całkowicie |
| Szybki prototyp | Średnia | Częściowo | Częściowo |
| Minimalny opłacalny produkt | Wysoka | Bardzo mało/nie | Zbudowany z myślą o trwałości |
Aby szybko budować rozwiązania, musisz być otwarty na opracowywanie nowych procesów i sposobów pracy.
Zasady zarządzania projektami szybkiego prototypowania
Praca w sposób opisany poniżej wymaga zmiany nastawienia. Zalecam rozpoczęcie projektu od wewnętrznego spotkania rozpoczynającego projekt, podczas którego omówicie te zasady i wyjaśnicie, dlaczego są ważne. Pomoże to zapewnić, że cały zespół będzie od początku zgodny, będzie wiedział, czego się od niego oczekuje, oraz będzie świadomy tego, gdzie i dlaczego projekt może różnić się od tego, do czego jego członkowie są przyzwyczajeni.
1. Przygotuj się na robienie mniejszej liczby rzeczy
Prawdopodobnie będzie to oznaczać mniej planowania na początku niż to, do czego jesteś przyzwyczajony, a także pogodzenie się z tym, że:
- Brak kryteriów akceptacji lub minimalne kryteria akceptacji
- Brak zadań podrzędnych w historyjkach
- Brak oszacowań
To, co tracisz przez sztywny proces, zyskujesz dzięki szybkości, zaufaniu i komunikacji. Zaakceptuj brak kontroli.
Ta zasada przypomni całemu zespołowi, że można porzucić dobrze znane procesy na rzecz szybszego dostarczenia działającego oprogramowania. Warto regularnie pytać siebie i zespół: „czy to najszybszy sposób, aby zrobić x?”.
2. Pokazuj, nie opowiadaj
Ponieważ na początku planujesz mniej, podczas tworzenia będziesz więcej rozmawiać i rysować. Możesz chcieć wydłużyć spotkania scrumowe, aby omówić funkcję nieco bardziej szczegółowo, zanim tego dnia zespół zacznie ją tworzyć. Jak mówi powiedzenie, obraz wyraża więcej niż tysiąc słów. Czasami szkic strony, model treści lub diagram pokazujący, jak system zostanie zbudowany, wystarczą, aby rozpocząć pracę, a następnie można na tej podstawie iteracyjnie go rozwijać.
Ta zasada wzbudzi zaufanie zarówno w tobie, jak i u klienta. Każdy lubi widzieć postępy, a regularne prezentowanie pracy umożliwia uzyskiwanie informacji zwrotnych we właściwym czasie, dzięki czemu minimalizuje się marnotrawstwo.
3. Proś o wybaczenie, nie o pozwolenie
W większości rygorystycznych procesów tworzenia oprogramowania kluczowy jest konsensus. Chcesz, aby właściciel produktu zatwierdził kryteria akceptacji, a jako kierownik projektu chcesz mieć pewność, że twój zespół zrozumiał wymagania, zanim napisze choćby jedną linię kodu.
W przypadku szybkich prototypów ważne jest, aby zespół czuł się upoważniony do stworzenia rozwiązania najlepiej, jak potrafi, w oparciu o aktualne rozumienie tematu, a następnie jak najszybciej zaprezentował swoją pracę, uzyskał informacje zwrotne i wprowadził kolejne iteracje.
Uzyskiwanie konsensusu od samego początku spowolni pracę, a praca rzadko idzie na marne, jeśli zespół wcześnie i często pokazuje, nad czym pracuje.
Ta zasada jest szczególnie przydatna dla programistów, ponieważ nakłada na nich odpowiedzialność za początkowe zaprojektowanie i zbudowanie funkcji przy niewielkim wpływie z zewnątrz. Często tworzymy zbyt wiele i nadmiernie komplikujemy rozwiązania, ponieważ nie zawsze dostrzegamy złożoność techniczną związaną z naszymi prośbami. Dlatego świetnym podejściem jest zaufanie programistom w zespole i pozwolenie im zdecydować, jaka jest najbardziej podstawowa implementacja, a następnie zbudowanie właśnie jej.
Aby to zadziałało, niezbędne jest, by programiści doskonale rozumieli projekt, dzięki czemu będą mogli podejmować właściwe decyzje dotyczące projektu i zawsze tworzyć tylko wystarczająco dużo.
4. Zawsze zachęcaj zespół do pokazywania tego, nad czym pracuje (nawet jeśli wygląda to nie najlepiej)
Ten proces jest inspirowany zasadami prototypowania rządowych usług cyfrowych.
Zazwyczaj pokazujemy klientom funkcje dopiero wtedy, gdy są gotowe. W projektach opartych na szybkim prototypowaniu ważne jest, aby pokazywać je, gdy tylko działają, dzięki czemu można minimalizować marnotrawstwo, iterować i w razie potrzeby zmienić kierunek.
Spraw, żeby działało. Pokaż to.
Spraw, żeby wyglądało dobrze. Pokaż to.
Spraw, żeby się skalowało. Pokaż to.
Ta zasada uwalnia członków zespołu od poczucia, że powinni pokazywać pracę dopiero wtedy, gdy została sprawdzona przez projektanta lub w pełni przetestowana. Doceniaj pracę w toku.
5. Wybieraj procesy fizyczne zamiast internetowych
Jak powiedział Brett Harned, zarządzamy projektami za pomocą umysłu, a nie narzędzi. Nie bój się porzucić swoich narzędzi do zarządzania projektami. Zwizualizuj pracę, korzystaj z fizycznego rejestru zadań, przyklej na ścianie szkice, przepływy użytkowników i persony, a następnie omawiaj je podczas spotkań scrumowych. Często do nich wracaj i zachęcaj ludzi do przejęcia odpowiedzialności za przenoszenie kart oraz świętowanie wdrażania nowych funkcji. Jeśli klient nie pracuje w tej samej lokalizacji, fotografuj wszystko i udostępniaj na Slacku, aby nie został pominięty.
Wypróbowanie nowego procesu może być trudne, a wizualizowanie pracy prawdopodobnie wywoła rozmowy, które nie odbyłyby się, gdybyście korzystali ze spotkań online i patrzyli na cyfrową tablicę. Szybko stanie się jasne, jeśli fizyczna karta nie została przesunięta przez cały dzień lub jeśli jest zbyt dużo pracy w toku. Korzystanie z procesów fizycznych zapewnia dodatkową warstwę przejrzystości, za którą — uwierz mi — będziesz wiecznie wdzięczny, gdy wszystko zacznie wydawać się niejasne.
6. Traktujcie się nawzajem wspaniale
To naturalne, że czujesz się przytłoczony, gdy próbujesz wdrożyć nowy proces i sposób pracy, szczególnie jeśli sam również dopiero się z nim zapoznajesz. Mimo to przewodź z pewnością siebie i wspieraj zespół, gdy napotyka trudności. Uważnie słuchaj jego obaw i bądź gotowy modyfikować proces w miarę postępów. Upewnij się, że proces nie wywiera dodatkowej presji na zespół — szybkie prototypowanie polega na mądrzejszej, a nie cięższej pracy.
W zależności od osobowości członków Twojego zespołu niektórzy z nich z entuzjazmem przyjmą ten nowy sposób pracy, podczas gdy inni mogą się mu opierać. Wszyscy uczymy się w różnym tempie, a każda dziedzina będzie mierzyć się z innymi wyzwaniami podczas dostosowywania się do pracy w nowy sposób. Jako PM pamiętaj o tym i staraj się stworzyć dla zespołu wspierające i bezpieczne środowisko – usiądźcie razem, napijcie się herbaty i regularnie sprawdzaj, jak wszyscy sobie radzą.
7. Minimalizuj rozpraszacze
Czasami jako PM trudno jest wiedzieć, na jakie kompromisy można pójść w przypadku nowego procesu, a przy czym należy obstawać. Jeśli chodzi o akceptowanie nowych zmian w trakcie sprintu, nadal wyrażaj sprzeciw i mów „nie”. Ważne jest, aby po rozpoczęciu sprintu nic nie zakłócało pracy Twojego zespołu — ochrona jego czasu to najcenniejsza rzecz, jaką możesz zrobić.
Ta zasada daje zespołowi możliwość odrzucania próśb. Prawdopodobnie będziecie pracować w tygodniowych sprintach, a przy tak krótkim czasie nie możecie sobie pozwolić na jego utratę. Zadbaj o poparcie całej firmy, aby ludzie czuli, że mogą przełożyć wewnętrzne spotkania lub odłożyć na później dodatkowe obowiązki i w tym czasie skupić się na pracy.
Jak sprawić, by szybkie prototypowanie działało na Twoją korzyść
Uważam, że to nowe podejście do pracy jest niezwykle satysfakcjonujące, choć chwilami wydawało się chaotyczne, nieuporządkowane i wymykające się spod kontroli. Trudno jest wiedzieć, w jakim stopniu i w jaki sposób należy odejść od obecnego procesu, ale zachęcam Cię do eksperymentowania, szybkiego ponoszenia porażek i otwartego rozmawiania z zespołem o tym, czego od niego potrzebujesz.
Zdarzało się, że usuwaliśmy kluczową część procesu, a później ją przywracaliśmy, ponieważ stawało się jasne, że bez niej trudno było mi zarządzać projektem. W takich momentach projektu upewniałem się, że potrafię jasno wyjaśnić pozostałym członkom zespołu konsekwencje usunięcia tego procesu. Jako zespół omawialiśmy, czy istnieje alternatywny sposób na uzyskanie przeze mnie tych informacji, a jeśli nie udało nam się znaleźć lepszego rozwiązania, przywracaliśmy proces. Właśnie w takich chwilach można czerpać korzyści z budowania wspierającego środowiska opartego na wzajemnym zaufaniu i szacunku. Na każdym etapie uczymy się, wprowadzamy poprawki i idziemy dalej jako cały zespół.
Podziękowania dla Chrisa Thorpe’a za te zasady — wszystko, co wiem, zawdzięczam jemu.
