Pierwsza wersja była dramatycznie uboga, miała tylko podstawowe funkcjonalności, była brzydka i robiona na narzędziach do szybkiego prototypowania. I dlatego wszystko potoczyło się tak szybko, bo to było tak naprawdę zupełne MVP.

Zuzanna Stańska, pomysłodawczyni i project managerka DailyArt

O tym, jak aplikacja DailyArt rozwinęła się z poziomu MVP (minimum viable product) do nagradzanej aplikacji, z której korzysta miesięcznie 450 000 osób na całym świecie, można przeczytać w raporcie Kultura, biznes, aplikacje. Historia sukcesu polskich aplikacji i gier mobilnych.

Studium wykonalności

Studium wykonalności pozwala na przenalizowanie możliwości realizacji danego projektu pod kątem ekonomicznym, technicznym i finansowym. Wykonanie studium wykonalności jest najczęściej zlecane zewnętrznym firmom. W jego zakres wchodzi ocena ryzyk oraz szans zakończenia całego projektu z sukcesem. Jeżeli szukasz przykładu takiej analizy, możesz się zapoznać ze studium wykonalności Platformy Edukacyjnej Teatru Polskiego w Warszawie. Pamiętaj jednak, że przy mniejszych projektach tak obszerny dokument nie będzie potrzebny.

Specyfikacja

Elementy, które powinny się znaleźć w specyfikacji, to zdefiniowanie celów biznesowych (tak by były zrozumiałe dla dostawcy), lista typów użytkowników narzędzia cyfrowego (np. administrator), lista funkcjonalności (np. w formie backlogu), założenia techniczne, które musi spełniać produkt (np. obsługa dużego ruchu na stronie, dostępność aplikacji mobilnej zarówno dla systemu Android, jak i iOS).

Opracowanie wizualizacji projektu oraz klikalnej makiety kluczowych lub problematycznych elementów produktu czy opis architektury informacji to również elementy naszej specyfikacji. Jeżeli jest to możliwe, warto kontynuować współpracę z wykonawcami, którzy sprawdzili się w pracach koncepcyjnych. Jeżeli mamy ograniczone środki, nawet samodzielne narysowanie tego, jak produkt ma wyglądać, może pomóc.

Ile czasu ma trwać projekt? Jak długo chcemy korzystać z naszego narzędzia cyfrowego? To pytania, które powinny paść podczas analizy budżetu, a także w pracach nad specyfikacją techniczną. Rzeczywistość technologiczna bardzo szybko się zmienia i wymaga regularnego aktualizowania wdrożonych produktów, np. aplikacji. Trzeba to uwzględnić choćby na poziomie budżetu. Więcej wskazówek na temat tego, jak napisać prostą specyfikację, znajdziecie w tym artykule.

Backlog

Backlog produktu to lista funkcjonalności, które składają się na działanie naszego produktu cyfrowego i budują jego wartość. Backlog jako sposób porządkowania zakresu prac jest charakterystyczny dla projektów realizowanych w metodykach zwinnych (np. Scrum). Sprawdza się też, gdy rozliczamy się z dostawcą na zasadach time & material, czyli płacimy za przepracowane godziny. Funkcjonalności w backlogu możemy rozpisać za pomocą user stories – w naszym filmiku tłumaczymy, jak to zrobić. Mając je spisane w jednym miejscu, możemy się zastanowić nad MVP (minimum viable product), czyli ustaleniem, które z tych funkcjonalności są niezbędne, by móc uznać produkt za działający i gotowy do wypuszczenia na rynek. Dzięki temu będziemy mogli świadomie zarządzać budżetem i dobrze priorytetyzować zadania. Tworząc backlog i ustalając zakres MVP, trzeba cały czas pamiętać o odbiorcach i ich potrzebach – o tym, jakie funkcjonalności są im niezbędne.

Sprawdzone rozwiązania
Czy jesteśmy gotowi udostępnić naszym odbiorcom produkt posiadający wyłącznie takie funkcjonalności? To pytanie pomoże nam sprawdzić, czy dobrze określiliśmy MVP naszego produktu i czy osoby decyzyjne w naszej instytucji rozumieją je tak samo jak lider projektu. To ważne pytanie i powinno być regularnie zadawane w trakcie trwania projektu. MVP nie jest listą funkcjonalności, które realizujemy w pierwszej kolejności. To lista funkcjonalności, których realizacja pozwala nam uznać nasz produkt za skończony na podstawowym, ale satysfakcjonującym nas poziomie

Stworzenie dokumentacji projektu

Na tym etapie wiemy już bardzo dużo na temat zakresu projektu. Dlatego zadaniem lidera projektu jest stworzenie dokumentacji podsumowującej dotychczasowy wysiłek (np. w formie prezentacji podstawowych założeń projektu, która zostanie przedstawiona dyrekcji).

Jakich kompetencji potrzebujemy?

Zanim zaczniemy szukać dostawcy, dobrze zdefiniujmy, kogo potrzebujemy. Tworząc zespół projektowy, należy uwzględnić wszystkie aspekty zadania, z którym się mierzymy. Prace nad koncepcją rozwiązania oraz wizją produktu powinny dać nam obraz tego, jakie kompetencje mamy w zespole, a jakich musimy poszukać na zewnątrz. Budowa nawet prostego narzędzia cyfrowego, np. portalu udostępniającego zasoby instytucji, wymaga zaangażowania:

• programisty,
• grafika,
• osoby odpowiedzialnej za UX portalu,
• osoby odpowiedzialnej za serwer strony i zarządzanie domeną,
• osoby odpowiedzialnej za testy z użytkownikami,
• osoby odpowiedzialnej merytorycznie za treści, które będą udostępniane na stronie,
• osoby odpowiedzialnej za redakcję i korektę treści,
• product ownera/menedżera projektu,
• prawnika, który przygotuje odpowiednią umowę z wykonawcą zewnętrznym.

Narzędzia i dobre praktyki

Zainspiruj się
Poznaj ,,Szlaki Tułaczy” portal stworzony w Pracowni Otwierania Kultury we współpracy z Fundacją Ośrodek Karta.
Poznaj ,,Muselfie” aplikację stworzoną przez pracowników Muzeum Narodowego w Warszawie razem z zespołem Pracowni Otwierania Kultury.

Przykład
Lider projektu na spotkaniu z pozostałymi osobami zaangażowanymi w projekt sformułował treść manifestu. Ustalono, że aplikacja powinna działać przez dwa lata. Następnie spotkał się z dyrektorką zaprzyjaźnionej organizacji, która wdrożyła podobne rozwiązanie. Okazało się, że kod tego produktu jest otwarty, więc zadaniem instytucji będzie jedynie dostosowanie go do swoich potrzeb. Wpłynie to na znaczne oszczędności w budżecie, które zostaną wykorzystane do aktualizacji aplikacji po roku jej funkcjonowania. Spotkanie z dyrektorką zaowocowało również listą dodatkowych wskazówek oraz rekomendacji na temat dostawców.