Tworzenie MVP: określ pierwsze użyteczne wydanie
Na tej stronie
MVP to eksperyment zaprojektowany do sprawdzenia istotnego założenia dotyczącego produktu. W metodologii Lean Startup jego celem jest rozpoczęcie cyklu budowania, mierzenia i uczenia się. Do wczesnego pytania może wystarczyć prototyp lub usługa wykonywana ręcznie; pełne wydanie oprogramowania nie zawsze jest pierwszą potrzebną inwestycją.
Ten przewodnik dotyczy kolejnej sytuacji: rzeczywiści użytkownicy potrzebują działającego oprogramowania do sprawdzenia procesu biznesowego. Takie wydanie nadal wymaga danych, uprawnień, wyjątków i kontroli jakości właściwych dla zamierzonego użycia. Portal klienta, wewnętrzny system operacyjny i platforma handlowa mają różnych użytkowników i ryzyka startu. Przed wyceną i harmonogramem określ pytanie, na które wydanie ma odpowiedzieć.
Wybierz jeden proces i jedną decyzję
Zacznij od sytuacji skłaniającej kogoś do otwarcia produktu. Na przykład zespół dystrybucji potrzebuje zobaczyć zamówienia zagrożone opóźnieniem wysyłki, sprawdzić przyczynę i przypisać następne działanie. To bardziej użyteczne niż lista funkcji zatytułowana „panel zamówień”.
Zapisz:
- Kto rozpoczyna proces i co go uruchamia?
- Którym rekordom musi ufać?
- Jaką decyzję lub działanie powinien wspierać system?
- Który wyjątek może zatrzymać zwykłą ścieżkę?
- Po czym zespół rozpozna, że pierwsze wydanie działa?
Sformułuj hipotezę, którą wynik może podważyć. Dla naszego przykładu dystrybucji: udostępnienie dyspozytorom kolejki wyjątków z przypisaną osobą odpowiedzialną zmniejszy liczbę nierozwiązanych niedoborów w momencie odcięcia wysyłek, bez zwiększenia błędnych przydziałów zapasu. Oddziela to zamierzoną korzyść od warunku, który nie może się pogorszyć. To przykładowa hipoteza, nie zmierzony wynik klienta.
Zmapuj pełną ścieżkę wraz z wyjątkami
W przykładzie zamówień pierwsza ścieżka może wyglądać tak: przyjąć zamówienie, sprawdzić dostępny zapas, oznaczyć niedobór, pokazać odpowiedzialny zespół i zapisać decyzję. Może również potrzebować uprawnień, zachowanego rekordu klienta i wymiany z obecnym systemem magazynowym.
Scenariusz odbiorowy powinien opisywać zachowanie przy niewystarczającym zapasie lub nieudanej aktualizacji źródła. Zespół może wtedy oceniać działające wydanie względem sytuacji biznesowych, zamiast sprawdzać tylko obecność każdego ekranu.
Odłóż automatyzację zakupów, zaawansowane prognozy lub portal klienta, jeśli nie są potrzebne w wybranym procesie. Uzgodnij granicę zakresu z osobą odpowiedzialną za proces i zespołem realizacyjnym.
Zdecyduj, co zbudować, połączyć i odłożyć
Nie każda potrzebna funkcja powinna powstawać na zamówienie. Przejrzyj narzędzia i dane, które firma już ma. Obecny dostawca tożsamości, platforma księgowa lub środowisko raportowe mogą pozostać, jeśli spełniają wymagania i udostępniają użyteczne połączenie.
Sklasyfikuj każdą pozycję prostym językiem:
- Potrzebne do pierwszej użytecznej ścieżki: proces, role, rekordy, wyjątki i kontrole, bez których wydania nie można bezpiecznie używać.
- Potrzebne do działania: transfer danych, integracja, monitoring, dokumentacja i przygotowanie użytkowników.
- Kandydat do późniejszego wydania: wartościowa praca niewymagana dla pierwszego uzgodnionego rezultatu.
- Nadal nieznane: jakość danych, dostęp do usług zewnętrznych, reguły lub ograniczenia techniczne wymagające analizy przed wiarygodną wyceną.
Szkolenie użytkowników i przeniesienie danych należą do pierwszego zakresu, jeśli bez nich zespół nie rozpocznie pracy.
Zaplanuj istniejące dane przed implementacją
Jeśli użytkownicy już pracują w CRM, ERP lub arkuszach, pierwsze wydanie potrzebuje jasnego planu danych. Zdecyduj, jaka historia jest przenoszona, który system zarządza każdym rekordem podczas przejścia i czy wybrane dane muszą pozostawać zsynchronizowane.
Dla danych migrowanych określ mapowanie pól, obsługę duplikatów, próbne transfery i weryfikację ze źródłem. Dla bieżącego połączenia określ kierunek aktualizacji, częstotliwość, obsługę błędów i uzgadnianie. To różne zadania i powinny występować oddzielnie w wycenie.
Strona modernizacji starszego oprogramowania pokazuje objaśniający przykład przeniesienia rekordów klientów. Konfigurator systemu zawiera oddzielne interaktywne demo importu i synchronizacji na przykładowych danych.
Buduj raportowanie wokół działania
Raport należy do pierwszego wydania, gdy użytkownik potrzebuje jego odpowiedzi do obsługi procesu. W przykładzie zamówień „otwarte zamówienia po planowanej dacie wysyłki” wymagają definicji, daty raportu, rekordów źródłowych i sposobu sprawdzenia blokady. Potrzebny jest też właściwy dostęp dla każdej roli.
Możesz zbudować ten widok w nowym systemie, zintegrować obecne narzędzie BI lub synchronizować dane ze środowiskiem raportowym. Przed wyborem wykresu uzgodnij źródło, filtry, wymagania odświeżania i metodę weryfikacji. Strona dedykowanego ERP zawiera przykładowy raport wyjątków w zamówieniach.
Oceniaj działające wydanie etapami
Na etapie projektowania sprawdź główne kroki procesu. Podczas programowania weryfikuj uzgodnione scenariusze w działającym oprogramowaniu. Przed startem zakończ migrację i szkolenie użytkowników. Oferta powinna wskazywać osoby zatwierdzające, rezultaty i odpowiedzialność oraz wpływ zmian zakresu na koszt i termin.
Porządkowanie danych, dostęp do systemów zewnętrznych, wymagania dostępności i czas odbioru przez biznes wpływają na harmonogram. Oszacuj te zależności razem z programowaniem i przypisz odpowiedzialność za nierozstrzygnięte kwestie.
Co uwzględnić w budżecie
W Horizon Dynamics budżety pełnych projektów dedykowanego oprogramowania zaczynają się od 50 000 USD. Zależnie od współpracy pracujemy z zespołem rozliczanym godzinowo lub w stałej cenie za określony moduł. Analizę można wycenić oddzielnie, jeśli jest przydatna. Rzeczywisty szacunek zależy od uzgodnionych procesów, ról, danych, integracji, wymagań jakości i wdrożenia.
Koszty i proces wyjaśniają dwa modele płatności i pracę stojącą za wyceną. W Konfigurator systemu możesz wybrać moduły demonstracyjne i zobaczyć przykładowy budżet zestawu. Przedziały pomagają poznać zakres, zanim oferta wyceni Twój projekt.
Przed porównaniem ofert sprawdź, czy każda obejmuje analizę, projektowanie, testy, przeniesienie danych i wdrożenie. Nasze płatne wsparcie jest wymagane po starcie i wyceniane oddzielnie od przykładowego kosztu budowy. Zapytaj o objęte gwarancją poprawki oraz sposób ujęcia wsparcia, hostingu opłacanego przez klienta, licencji, płatnych API i przyszłego rozwoju w ofercie.
Oceń pierwsze wydanie przed zatwierdzeniem rozszerzenia
Sprawdź zwykłe zadanie, wyjątek, rekord z ograniczonym dostępem i nieudane przekazanie do systemu zewnętrznego. Wskaż osobę zatwierdzającą po stronie biznesu oraz dowody potrzebne do decyzji o starcie, uzgodnienia danych i uruchomienia planu awaryjnego. Nasz przykładowy brief realizacji łączy te kontrole z zakresem i kosztami.
Oceń wynik pilotażu
Przed startem określ okres obserwacji, kwalifikujące się zamówienia, punkt odniesienia i decyzję przeglądu. W przykładzie policz zamówienia nadal zablokowane niedoborem przy tym samym momencie odcięcia wysyłek i podziel przez wszystkie zamówienia do wysyłki w tym okresie. Zachowaj obie liczby: zmiana z 4 na 20 do 4 na 40 oznacza niższy odsetek, ale nie zmniejsza liczby zablokowanych zamówień. Konsekwentnie zapisuj anulowania i wyłączenia.
Obok tego wyniku śledź błędne przydziały, nierozwiązane błędy integracji i ręczne interwencje. Porównuj podobne typy zamówień, obsadę zespołu i obciążenie oraz zapisuj zmiany zatrudnienia lub działania dostawców. Pilotaż przed i po zmianie może wskazywać następny krok, ale sam nie oddziela wpływu oprogramowania od tych zmian. Małą próbkę raportuj jako liczby i obserwacje, nie precyzyjną prognozę przyszłych oszczędności.
Sprawdź, gdzie użytkownicy się zatrzymują i dlaczego rekordy są poprawiane. Uzgodnij, czy dowody uzasadniają rozszerzenie, zmianę czy zatrzymanie proponowanego procesu. Samo użycie nie dowodzi wartości, a przyjęcie narzędzia wewnętrznego nie dowodzi gotowości klientów zewnętrznych do zapłaty.
Jeśli planujesz pierwsze wydanie, przedstaw proces, obecne systemy i decyzje wymagające wsparcia. Możesz omówić projekt bez gotowej specyfikacji.
