Pierwsza wersja aplikacji dla firmy - jak określić zakres MVP?

Co ma udowodnić pierwsza wersja aplikacji dla firmy

Pierwsza wersja aplikacji dla firmy ma pozwolić zespołowi wykonać jedno zadanie od początku do końca. W prawdziwej pracy, na prawdziwych danych, bez obejść. Tak rozumiemy zakres MVP przy wycenie i tak go sprawdzamy w testach. Zestaw ekranów do pokazania na spotkaniu tego nie sprawdzi. Makieta, w której nie da się zapisać sprawy, też nie.

Skrót MVP pochodzi z angielskiego i oznacza najmniejszą wersję, która ma już wartość dla użytkownika. W firmowej aplikacji ta wartość jest konkretna. Handlowiec widzi, kto opiekuje się klientem i co ustalono tydzień temu. Serwisant wie, gdzie jedzie jutro i co ma zabrać. Klient sprawdza status bez telefonu do biura. Jeśli pierwsza wersja nie pozwala na coś takiego, jest jeszcze projektem, a nie narzędziem.

Dlatego zanim spiszesz listę funkcji, zapisz jedno pytanie, na które ma odpowiedzieć wdrożenie. Na przykład: czy wspólna karta sprawy sprawi, że przekazanie klienta między handlowcem a serwisem przestanie gubić ustalenia. Albo: czy ekipa montażowa będzie zaglądać do aplikacji zamiast dzwonić do biura po adres. Takie pytanie wskazuje użytkowników, dane oraz czynności, które muszą znaleźć się w pierwszej wersji. Wszystko, co nie pomaga na nie odpowiedzieć, może poczekać.

Ten poradnik prowadzi od pomysłu do zakresu, który da się wycenić i zbudować. Zakładamy, że masz już przekonanie, że arkusz i skrzynka mailowa przestały wystarczać. Jeśli jeszcze go nie masz, zacznij od tekstu o tym, kiedy Excel przestaje wystarczać do obsługi zleceń. Jeśli rozważasz gotowy program, przeczytaj porównanie gotowego CRM-u z systemem dedykowanym. Tutaj zajmujemy się sytuacją, w której decyzja o własnej aplikacji zapadła i trzeba ją zmieścić w rozsądnym pierwszym kroku.

Pierwsza wersja nie jest też prototypem do wyrzucenia. Buduje się ją na strukturze danych i uprawnień, która ma unieść kolejne etapy. Mniejszy zakres oznacza mniej ekranów, nie mniej staranności przy projektowaniu bazy.

Jeden proces, który pierwsza wersja ma obsłużyć w całości

W ofercie na stronie aplikacji dla firm piszemy, że wybieramy jeden proces, który ma usprawnić pierwsza wersja. To zdanie brzmi prosto, a w rozmowach zajmuje najwięcej czasu. Firma ma zwykle pięć procesów, które bolą, i każdy dział wskazuje inny.

Proces nadaje się na pierwszą wersję, gdy spełnia kilka warunków. Ma wyraźny początek i koniec: zapytanie przychodzi, oferta wychodzi. Zlecenie wpada, protokół odbioru zostaje podpisany. Ma właściciela, czyli osobę, która potrafi go opowiedzieć i będzie go bronić w testach. Powtarza się na tyle często, że po uruchomieniu szybko zbierzesz prawdziwe uwagi. I ma dane, które już gdzieś istnieją, choćby w arkuszu.

Na pierwszy etap odpada proces, który zależy od działu niechętnego zmianie. Odpada też taki, który wymaga integracji z systemem bez dokumentacji. I taki, który zdarza się dwa razy w roku, choćby był bardzo bolesny. Po tym odsiewie zostaje zwykle jeden albo dwóch kandydatów. Wybór między nimi to rozmowa o tym, gdzie ginie najwięcej informacji.

Jak opisać proces, żeby dało się go wycenić

Nie potrzebujemy specyfikacji. Potrzebujemy opowieści o jednym zwykłym zleceniu i o trzech trudnych sytuacjach. Zwykłe zlecenie pokazuje, jakie dane przechodzą z ręki do ręki i kto decyduje na każdym etapie. Trudne sytuacje pokazują, gdzie aplikacja musi mieć wyjątki: klient zmienia termin, brakuje części, faktura ma iść na inną firmę niż zamówienie.

Dobrym materiałem jest anonimowy arkusz, w którym dziś prowadzicie ten proces, oraz kilka maili z typową wymianą. Z arkusza widać, jakie kolumny naprawdę wypełniacie, a które stoją puste od roku. Z maili widać, czego arkusz nie mieści: ustaleń, zdjęć, zmian na ostatnią chwilę. Jak przygotować zespół i dane przed takim projektem, opisujemy w poradniku o przygotowaniu firmy do wdrożenia CRM. Jeśli wygodniej Ci od razu wpisać to w formularz, brief aplikacji przyjmuje opis i pliki.

Zapisz też, co zostaje w obecnych narzędziach. Jeśli faktury wystawiacie w programie księgowym, pierwsza wersja aplikacji ich nie wystawia. Może co najwyżej przechowywać numer i link. Granica między aplikacją a resztą firmy jest częścią zakresu, tak samo jak lista funkcji.

Podział funkcji według zależności, nie według pilności

Gdy proces jest wybrany, lista pomysłów na funkcje rośnie szybko. Każdy, kto słyszy o aplikacji, dorzuca swoją. Żeby ją uporządkować, stosujemy cztery koszyki. Nie pytamy, co jest pilne, bo pilne jest wszystko. Pytamy, od czego zależy wykonanie zadania.

Przy każdej pozycji na liście zapisz dwie rzeczy: kto jej potrzebuje i co się stanie, gdy zabraknie jej w pierwszej wersji. Jeśli odpowiedź brzmi „handlowiec wpisze datę ręcznie”, funkcja jest wspierająca. Jeśli brzmi „nikt nie będzie wiedział, kto prowadzi sprawę”, jest konieczna. Taka rozmowa rozstrzyga spory lepiej niż głosowanie i lepiej niż oznaczenie wszystkiego jako pilne.

Ostatni koszyk wymaga uwagi w projekcie danych. Jeśli za rok ma powstać panel klienta, to już w pierwszej wersji każda sprawa musi mieć przypisaną firmę klienta, a nie samo imię osoby kontaktowej. Jeśli mają być raporty, statusy muszą być polami do wyboru, nie wolnym tekstem. Planów rozwoju nie budujemy od razu, ale uwzględniamy je w strukturze danych i uprawnień. Zmiana struktury po roku pracy kosztuje więcej niż zaplanowanie jej na starcie.

Przy platformie BliskoPracy.pl dwie grupy użytkowników, kandydaci i pracodawcy, mają osobne ścieżki w jednym serwisie, a zaplecze i dedykowany CRM wspierają obsługę całej platformy. Taki podział użytkowników trzeba znać przed projektem danych, nawet gdyby pierwsza wersja obsługiwała jedną grupę. Dopisanie drugiej grupy do struktury, która jej nie przewidziała, jest przebudową, nie rozszerzeniem.

Przykład z biurka: zapytania w firmie instalacyjnej

Firma montująca instalacje grzewcze zgłosiła się z pomysłem na „system do wszystkiego”. Lista z pierwszej rozmowy miała dwadzieścia sześć punktów. Od przyjmowania zapytań, przez magazyn części, po rozliczanie delegacji. Każdy punkt był prawdziwym problemem. Żadnego nie dało się zbudować jako pierwszego, bo wszystkie były ze sobą powiązane.

Krok pierwszy: wybór procesu. Zapytaliśmy, która sytuacja najczęściej kończy się tym, że ktoś dzwoni do biura z pytaniem o rzecz już ustaloną. Odpowiedź była jednoznaczna: zapytania od klientów. Przychodziły mailem, telefonem, przez formularz na stronie. Właściciel wpisywał je do arkusza, kiedy miał czas, a wyceny robił z notatek w telefonie. Gdy był na urlopie, nikt nie wiedział, które zapytania są w toku.

Krok drugi: podział funkcji. Do koszyka „konieczne” trafiły: przyjęcie zapytania z dowolnego źródła, przypisanie osoby odpowiedzialnej, zapis ustaleń z klientem, wyznaczenie kolejnego działania z datą i zamknięcie sprawy ze statusem. Do „wspierających”: powiadomienie mailowe o przypisaniu oraz lista spraw bez kolejnego kroku. Do „sprawdzenia”: szacowanie wartości zlecenia na etapie zapytania. Do „kolejnego etapu”: magazyn, delegacje, panel dla klientów i generowanie ofert PDF.

Krok trzeci: granice. Formularz ze strony miał trafiać do aplikacji jako nowa sprawa, więc sprawdziliśmy, co wysyła i w jakim formacie. Faktury zostały w programie księgowym. Zdjęcia z wizji lokalnej miały być załącznikiem do sprawy, bez obróbki i bez galerii. Wycena pierwszej wersji objęła ten zakres i nic więcej.

Krok czwarty: testy z zespołem na uzgodnionych scenariuszach. Dwie osoby z biura przeszły przez trzy prawdziwe zapytania z poprzedniego tygodnia. Pierwsza uwaga dotyczyła pola „źródło zapytania”, którego nikt nie chciał wypełniać. Zostało listą z trzema wartościami i wartością domyślną. Druga uwaga: brakowało miejsca na telefon drugiej osoby po stronie klienta. Dodaliśmy to przed uruchomieniem. Trzecia: właściciel chciał od razu raport miesięczny. Został w koszyku „kolejny etap”, bo bez miesiąca danych nie miałby czego pokazać.

Po uruchomieniu zbieraliśmy uwagi z codziennego użycia. Lista spraw bez kolejnego kroku okazała się najczęściej otwieranym widokiem. Szacowania wartości zlecenia na etapie zapytania nikt nie używał, więc nie trafiło do drugiego etapu. Drugi etap objął generowanie ofert PDF z danych sprawy, bo tę czynność biuro wykonywało ręcznie przy każdym zapytaniu. Magazyn czeka dalej, bo arkusz na części nadal wystarcza.

Pierwszy zakres w zależności od tego, czym się zajmujesz

Proces, który najczęściej nadaje się na pierwszą wersję, zależy od branży. Poniżej te, które wracają w rozmowach z firmami z regionu, z pierwszym zadaniem i z tym, co odkładamy na później.

Serwis i instalacje

Pierwsze zadanie: zgłoszenie od klienta przechodzi od przyjęcia do zamknięcia, z osobą odpowiedzialną i terminem. Serwisant widzi na telefonie, gdzie jedzie jutro i co ma zabrać. Biuro widzi, które zgłoszenia nie mają terminu. Do pierwszej wersji wchodzi karta zgłoszenia, lista według dnia i osoby oraz zmiana statusu z telefonu. Odkładamy: rozliczanie czasu pracy, magazyn części, protokoły z podpisem na ekranie. Jak budujemy takie narzędzia, opisujemy na stronie aplikacji do obsługi zleceń, a sposób doboru funkcji w poradniku o wyborze funkcji aplikacji do zleceń.

Produkcja B2B

Pierwsze zadanie: zapytanie ofertowe z parametrami przechodzi od wpływu do wysłanej oferty, a potem do zamówienia. Handlowiec widzi, które zapytania czekają na wycenę od technologa. Technolog widzi, co ma wycenić i do kiedy. Do pierwszej wersji wchodzi karta zapytania z parametrami, przekazanie do wyceny i status. Odkładamy: planowanie produkcji, kalkulatory kosztów, panel dla stałych odbiorców. Przy realizacji dla Nomatec zakres objął stronę WWW, branding i CRM wspierający obsługę zapytań oraz kontakt handlowy. Kolejne moduły są osobną decyzją, nie częścią pierwszego zakresu.

Handel i dystrybucja

Pierwsze zadanie: zamówienie od stałego odbiorcy trafia do realizacji bez przepisywania z maila. Do pierwszej wersji wchodzi przyjęcie zamówienia, status realizacji i historia zamówień klienta. Odkładamy: cenniki indywidualne, limity kredytowe, połączenie z systemem magazynowym, jeśli nie ma do niego dokumentacji. Tutaj najczęściej pada pytanie, czy pierwszą wersją ma być panel dla klientów, czy narzędzie dla handlowców. Sprawdź, kto dziś przepisuje zamówienia. Jeśli handlowiec, zacznij od jego widoku. Co ma zawierać panel dla odbiorców, opisujemy w poradniku o panelu klienta B2B. Jeśli sprzedajesz też klientom indywidualnym, sklep jest osobnym projektem, o czym piszemy w tekście jak zacząć sklep internetowy.

Usługi dla firm: biura rachunkowe, kancelarie, agencje

Pierwsze zadanie: sprawa klienta ma opiekuna, termin oraz miejsce na dokumenty, a klient dostaje odpowiedź bez pytania „u kogo to jest”. Do pierwszej wersji wchodzi karta klienta, lista spraw z terminami i załączniki. Odkładamy: rejestrację czasu, rozliczenia, portal dla klientów do przesyłania dokumentów. W biurze rachunkowym kusi, żeby zacząć od portalu, bo klienci przysyłają faktury mailem i zdjęciami z telefonu. Zaczynamy jednak od porządku wewnątrz, bo portal bez uporządkowanej listy spraw przeniesie bałagan na ekran klienta. Jak ułożyć taki CRM, żeby informacje szły razem ze sprawą, opisujemy w poradniku o CRM-ie dla firmy usługowej.

Firma budowlana

Pierwsze zadanie: budowa ma listę zadań z odpowiedzialnymi, a kierownik widzi, co blokuje postęp. Do pierwszej wersji wchodzi karta budowy, zadania z terminem i osobą oraz zdjęcia z placu przypięte do zadania. Odkładamy: kosztorysy, obmiary, rozliczenia z podwykonawcami, protokoły odbioru z podpisem. Osobnym tematem jest dostęp dla inwestora, który chce widzieć postęp. To typowy „kolejny etap”, ale dane o postępie muszą być od początku w formie, którą da się pokazać na zewnątrz.

Firma z kilkoma oddziałami

Pierwsze zadanie: ta sama czynność wykonywana w każdym oddziale w ten sam sposób, z widokiem dla centrali. Tutaj pierwsza wersja ma dodatkowy warunek: uprawnienia według oddziału od pierwszego dnia. Kierownik w Nowym Tomyślu widzi swoje sprawy, kierownik w Lesznie swoje, a właściciel wszystkie. Do pierwszej wersji wchodzi jeden proces i struktura oddziałów. Odkładamy: przenoszenie spraw między oddziałami, porównania między nimi, lokalne wyjątki od procesu. Jeśli oddziały pracują dziś inaczej, to przed aplikacją trzeba ustalić jeden sposób. Aplikacja nie uzgodni tego za Was.

Czego nie da się odłożyć, nawet w najmniejszej wersji

Ograniczanie zakresu ma granicę. Są elementy, które nie są funkcjami i dlatego łatwo je pominąć na liście. Bez nich aplikacja nie nadaje się do pracy na prawdziwych danych. Ustalamy je przed budową, niezależnie od tego, jak mały jest pierwszy zakres.

Logowanie i uprawnienia

Kto może przeglądać, kto zmieniać, kto eksportować. W małej firmie kusi „wszyscy widzą wszystko”. Przy pięciu osobach to działa, przy dziesięciu ktoś usunie cudzą sprawę przez pomyłkę. Rola nie musi być rozbudowana, ale musi istnieć w strukturze, bo dodanie jej później oznacza przejrzenie każdego ekranu od nowa. Ukrycie przycisku nie zastępuje kontroli po stronie serwera. Wadliwa kontrola dostępu otwiera zestawienie najczęstszych błędów bezpieczeństwa OWASP Top Ten i to nie jest przypadek.

Obsługa błędów i sytuacji nietypowych

Co się dzieje, gdy formularz ze strony wyśle zapytanie bez numeru telefonu. Co widzi użytkownik, gdy integracja nie odpowie. Co z duplikatem klienta. Pierwsza wersja nie musi obsługiwać wszystkich wyjątków automatycznie, ale musi je pokazać i nie zgubić danych. Jeżeli część procesu zostaje ręczna, nazwij ją wprost i przypisz odpowiedzialność. „Zapytania z komunikatora przepisuje do aplikacji osoba z biura do końca dnia” jest lepsze niż udawanie, że wszystko wpływa samo. Użytkownicy muszą wiedzieć, na czym mogą polegać.

Kopie zapasowe i miejsce utrzymania

Gdzie działa aplikacja, kto robi kopie, jak często i kto sprawdził, że da się je odtworzyć. Miejsce utrzymania i kopie zapasowe ustalamy przed budową, bo przeniesienie działającej aplikacji na inny serwer po uruchomieniu jest osobną pracą. Jeśli firma ma już serwer albo wymagania co do miejsca przechowywania danych, powiedz o tym na starcie.

Ochrona danych osobowych

Aplikacja z danymi klientów jest zbiorem danych osobowych, nawet jeśli to tylko imię i telefon. Firma jest administratorem tych danych, a my przy projekcie odpowiadamy za stronę techniczną: szyfrowane połączenie, właściwe przechowywanie haseł, dostęp według ról, dziennik zmian tam, gdzie jest potrzebny. Obowiązki administratora opisuje rozporządzenie dostępne na EUR-Lex, a wyjaśnienia Urzędu Ochrony Danych Osobowych znajdziesz na uodo.gov.pl. Jeśli w pierwszej wersji ma być usługa zewnętrzna, na przykład AI do streszczania rozmów, decyzja o tym, jakie dane do niej trafiają, zapada przed budową.

Instrukcja i zgłaszanie problemów

Nawet pięć ekranów wymaga krótkiej instrukcji i jednego miejsca, w którym użytkownik zgłosi, że coś nie działa. W ofercie określamy sposób zgłaszania problemów, czas reakcji i zakres utrzymania. Bez tego pierwsze tygodnie zamieniają się w telefony do osoby, która akurat zna aplikację najlepiej. A ta osoba ma też swoją pracę.

Dane: co przenieść do pierwszej wersji, a co zostawić

Druga po liście funkcji rozmowa dotyczy danych. Firma ma arkusz z klientami od ośmiu lat, drugi arkusz ze zleceniami i skrzynkę mailową, w której jest reszta. Pytanie brzmi, ile z tego ma trafić do aplikacji w dniu uruchomienia.

Zanim odpowiemy, sprawdzamy możliwość eksportu, format, jakość oraz ilość danych. Ustalamy, które informacje przenosimy, jak traktujemy duplikaty i jak sprawdzimy wynik migracji. Arkusz z klientami ma zwykle tę samą firmę wpisaną na trzy sposoby, telefony w różnych formatach i kolumnę „uwagi”, w której jest wszystko. Przeniesienie tego bez czyszczenia daje aplikację, która od pierwszego dnia pokazuje bałagan, tylko ładniej.

Porównujemy trzy warianty:

• Przenosimy wszystko po czyszczeniu. Ma sens, gdy historia jest potrzebna do pracy, na przykład przy stałych klientach z wieloletnimi ustaleniami. Kosztem jest czyszczenie, próbna migracja i sprawdzenie wyniku.
• Przenosimy tylko aktywne sprawy i klientów z ostatniego okresu. Reszta zostaje w arkuszu tylko do odczytu. To najczęstszy wybór przy pierwszej wersji, bo ogranicza czyszczenie do danych, których zespół naprawdę używa.
• Zaczynamy od zera. Ma sens, gdy stare dane są nieaktualne albo proces zmienia się tak bardzo, że stare statusy nic nie znaczą. Zespół wpisuje klientów przy pierwszym kontakcie po uruchomieniu.

Próbna migracja na części danych pokazuje, co się nie zgadza, zanim przeniesiemy całość. Przy arkuszu ze zleceniami wychodzi na przykład, że kolumna „status” ma czternaście różnych wartości, bo każdy pisał po swojemu. Ustalenie, które z nich odpowiadają pięciu statusom w aplikacji, jest decyzją firmy, nie programisty. My pokazujemy listę, Wy mówicie, co znaczy „w toku 2”.

Ustal też, kto po uruchomieniu odpowiada za dane w aplikacji. Jeśli dwie osoby wpisują tego samego klienta, aplikacja powinna to wyłapać, ale decyzję o scaleniu podejmuje człowiek. Przy pierwszej wersji wystarczy ostrzeżenie o podobnym wpisie. Pełne scalanie z historią jest funkcją na później.

Integracje i AI: kiedy do pierwszej wersji, a kiedy później

Dwie rzeczy najczęściej rozsadzają zakres pierwszej wersji: połączenia z innymi systemami i funkcje AI. Obie bywają dobre. Obie wymagają osobnej decyzji.

Integracje

Integracja trafia do pierwszej wersji wtedy, gdy bez niej nie da się wykonać wybranego zadania. Jeśli proces zaczyna się od formularza na stronie, połączenie formularza z aplikacją jest konieczne. Jeśli proces kończy się fakturą w programie księgowym, a fakturę i tak wystawia księgowa, połączenie z programem księgowym może poczekać. Numer faktury wpisany ręcznie w pierwszej wersji nie jest porażką.

Przed wyceną integracji sprawdzamy, co system po drugiej stronie udostępnia: dokumentację, API, eksport albo inny dopuszczony sposób wymiany danych. Ustalamy też ograniczenia dostawców i dodatkowe koszty dostępu, bo część systemów każe płacić za interfejs osobno. Zdarza się, że program, z którym firma pracuje od lat, nie ma żadnej dokumentacji wymiany danych. Wtedy omawiamy alternatywy i ich ograniczenia, zamiast obiecywać połączenie. Zakres takich prac opisujemy na stronie integracji systemów, a przykład połączenia formularza z CRM-em w poradniku o integracji strony z CRM-em.

Przy integracji w pierwszej wersji ustalamy jeszcze trzy rzeczy. Co jest źródłem prawdy dla każdego pola, bo dwa systemy nie mogą oba zmieniać tego samego statusu. Jak często dane się wymieniają: przy zdarzeniu czy okresowo. I co się dzieje, gdy drugi system nie odpowiada: rejestr błędów, ponowienie oraz informacja dla osoby odpowiedzialnej.

Funkcje AI

AI w firmowej aplikacji dobrze robi kilka rzeczy: streszcza rozmowy, odczytuje dane z dokumentów, wyszukuje w firmowej wiedzy, szkicuje odpowiedzi. Żadna z nich nie jest potrzebna, żeby zespół obsłużył zapytanie od początku do końca. Dlatego w pierwszej wersji AI pojawia się rzadko, chyba że właśnie to zadanie jest celem wdrożenia. Firma, która codziennie dostaje dziesiątki zamówień w PDF-ach różnych formatów, może zacząć od odczytu dokumentów, bo to jest jej proces.

Gdy AI wchodzi do zakresu, ustalamy koszt użycia, zakres danych przekazywanych do usługi zewnętrznej i czynności, które wymagają akceptacji człowieka. Szkic odpowiedzi do klienta może powstać automatycznie, ale wysyła go handlowiec. Gdzie AI pomaga, a gdzie potrzebna jest kontrola, opisujemy w poradniku o AI w aplikacji firmowej.

Jak ustalamy zakres MVP w naszym procesie

Na stronie oferty opisujemy cztery etapy pracy nad aplikacją. Zakres pierwszej wersji powstaje w dwóch pierwszych i jest sprawdzany w dwóch kolejnych. Poniżej, co w każdym z nich przychodzi od Ciebie i co dostajesz.

Zakres zapisany w ofercie jest tym, co wyceniamy. Jeśli w trakcie budowy pojawia się pomysł, zapisujemy go do koszyka na kolejny etap, chyba że bez niego zadania nie da się wykonać. Wtedy rozmawiamy o zmianie zakresu, a zmiana zakresu oznacza zmianę wyceny. Mówimy to na starcie, bo ta zasada chroni pierwszą wersję przed dwudziestoma dobrymi pomysłami.

Testy z zespołem to moment, w którym zakres pierwszej wersji jest sprawdzany najostrzej. Użytkownicy przechodzą przez uzgodnione scenariusze: przekazanie pracy, dokumenty, wyjątki, uprawnienia. Jeśli scenariusz da się dokończyć, zakres był dobry. Jeśli użytkownik utknął, bo brakowało pola, to pole wchodzi do pierwszej wersji. Jeśli utknął, bo chciałby mieć raport, raport czeka.

Jeśli chcesz zobaczyć, jak może wyglądać karta sprawy, lista zleceń albo widok klienta, na stronie oferty jest demonstracja na fikcyjnych danych. Pokazuje układ ekranów i przebieg zadań. Nie jest wdrożeniem konkretnego klienta i nie pokazuje zakresu, który powstanie u Ciebie, bo ten zależy od Waszego procesu.

Pytania do wykonawcy przed zamówieniem pierwszej wersji

Te pytania zadaj każdemu wykonawcy, także nam. Pokażą, czy myśli o pierwszej wersji jak o narzędziu do pracy, czy jak o pierwszej racie dużego projektu.

1. Który jeden proces obsłuży pierwsza wersja od początku do końca i kto będzie jej użytkownikiem.
2. Co zostaje w obecnych narzędziach i gdzie przebiega granica między aplikacją a resztą firmy.
3. Jak wykonawca sprawdzi, że pierwsza wersja działa: jakie scenariusze testowe i z kim.
4. Jak zaplanowano dane i uprawnienia pod kolejne etapy, których jeszcze nie budujemy.
5. Które integracje są konieczne w pierwszej wersji i czy sprawdzono dokumentację systemów po drugiej stronie.
6. Co się dzieje, gdy integracja nie odpowiada, i kto się o tym dowiaduje.
7. Jak wygląda migracja danych: co przenosimy, jak czyścimy, jak sprawdzamy wynik.
8. Kto ma prawa do kodu i danych po zakończeniu, co obejmuje dokumentacja i jakie dostępy dostaje firma.
9. Co obejmuje utrzymanie, jak zgłasza się problemy i co jest rozliczane osobno: licencje, usługi zewnętrzne, rozbudowa.
10. Jak wykonawca policzy koszt drugiego etapu, jeśli pierwsza wersja się sprawdzi.

W naszej ofercie odpowiedzi na ostatnie trzy pytania są zapisane. Określamy dokumentację, dostępy, licencje oraz prawa do kodu. Utrzymanie, licencje zewnętrzne i późniejszą rozbudowę ujmujemy osobno. Co składa się na koszt i jak przygotować porównywalne zapytanie do kilku firm, opisujemy w poradniku ile kosztuje aplikacja dla firmy.

Najczęstsze błędy przy określaniu zakresu pierwszej wersji

Każdy z tych błędów widzieliśmy w rozmowach o aplikacjach więcej niż raz. Większość wynika z dobrych chęci.

• Pierwsza wersja dla wszystkich działów naraz. Sprzedaż, serwis oraz księgowość mają inne zadania, a ich wspólnym mianownikiem jest pusta baza klientów. Aplikacja, która robi po trochu dla każdego, nie robi niczego do końca.
• Zakres ustalony przez osobę, która nie będzie używać aplikacji. Właściciel zamawia raporty, a zespół potrzebuje listy spraw na dziś. Raporty bez danych z listy spraw są puste.
• Makieta zamiast działającej wersji. Klikalne ekrany pokazują wygląd, ale nie pokazują, czy zespół zapisze w nich prawdziwą sprawę w biegu. Decyzję o rozwoju podejmuje się na podstawie użycia, nie oglądania.
• Odkładanie uprawnień „bo jesteśmy małą firmą”. Dodanie ról do aplikacji, która ich nie przewidziała, oznacza przebudowę każdego ekranu i każdego zapytania do bazy.
• Integracja wpisana do zakresu bez sprawdzenia dokumentacji. Wycena rośnie w trakcie, bo okazuje się, że system po drugiej stronie udostępnia eksport raz dziennie, a nie interfejs.
• Migracja całej historii „żeby nic nie zginęło”. Czyszczenie ośmiu lat arkusza zajmuje więcej niż budowa pierwszej wersji, a zespół i tak zagląda do spraw z ostatniego kwartału.
• AI w pierwszym zakresie, bo jest w każdej prezentacji. Bez uporządkowanych danych i procesu AI streszcza bałagan.
• Brak miernika przed uruchomieniem. Po kwartale nikt nie potrafi powiedzieć, czy jest lepiej, bo nikt nie zapisał, jak było.
• Pomysły z testów wrzucane do pierwszej wersji bez rozmowy o zakresie. Każdy z osobna jest mały. Razem potrafią odsunąć uruchomienie o długie tygodnie.
• Pierwsza wersja bez osoby po stronie firmy, która zbiera uwagi i podejmuje decyzje. Uwagi rozchodzą się po mailach, a wykonawca dostaje sprzeczne polecenia od trzech osób.

Wspólnym mianownikiem tych błędów jest pomylenie pierwszej wersji z wersją okrojoną. Okrojona wersja robi wszystko po trochu. Pierwsza wersja robi jedną rzecz do końca i mówi wprost, czego jeszcze nie ma.

Jak ocenić pierwszą wersję i zdecydować o rozwoju

Decyzja o drugim etapie zapada na podstawie użycia, nie na podstawie wrażeń z prezentacji. Żeby była możliwa, przed uruchomieniem trzeba zapisać dwie rzeczy: miernik i punkt wyjścia.

Miernik powiązany z problemem

Przed wdrożeniem ustalamy, co chcemy poprawić: czas obsługi, liczbę ręcznych czynności albo dostępność informacji. Miernik ma być prosty do policzenia i związany z pytaniem z pierwszej sekcji. Liczba zapytań bez przypisanego opiekuna na koniec dnia. Liczba telefonów do biura z pytaniem o adres montażu. Czas od wpływu zapytania do pierwszej odpowiedzi, sprawdzony na kilkunastu sprawach. Sama liczba logowań nic nie mówi, bo ludzie logują się też po to, żeby sprawdzić, czy coś działa.

Punkt wyjścia

Zanim aplikacja ruszy, policz ten sam miernik w obecnym sposobie pracy. Tydzień z kartką przy telefonie wystarczy. Bez tej liczby po uruchomieniu będziecie się spierać, czy jest lepiej, i każdy będzie miał rację. Zapisz też, które czynności wykonujecie ręcznie i ile osób je wykonuje.

Zbieranie uwag

Po uruchomieniu zbieramy uwagi z codziennego użycia. Najlepiej działa jedno miejsce na zgłoszenia i jedna osoba w firmie, która je zbiera i odsiewa. Uwagi dzielimy tak samo jak funkcje na starcie: co blokuje pracę, co pomaga, co jest pomysłem do sprawdzenia. Blokady poprawiamy w ramach utrzymania. Pomysły trafiają do listy na drugi etap.

Trzy możliwe decyzje

Po kilku tygodniach pracy ocena tych samych zadań daje jeden z trzech wyników. Pierwszy: zakres się sprawdził i zespół ma listę rzeczy, których brakuje. Wtedy drugi etap bierze z koszyków „wspierające” i „kolejny etap” to, co użytkownicy potwierdzili. Drugi: zakres się sprawdził, ale nic więcej nie jest potrzebne. To dobry wynik, nie porażka. Aplikacja zostaje w utrzymaniu, bez rozbudowy. Trzeci: założenie się nie sprawdziło. Zespół nie używa aplikacji, bo proces wygląda inaczej, niż go opisano. Wtedy wracamy do etapu poznawania pracy. Koszt tego powrotu jest mniejszy, niż gdyby błędne założenie zbudowano w pełnym zakresie.

Co dostajesz po uruchomieniu

Po uruchomieniu powinieneś mieć dostęp administracyjny do aplikacji, informację, gdzie działa i gdzie są kopie, dokumentację w zakresie z oferty oraz zasady zgłaszania problemów. Osobno rozliczane są licencje zewnętrzne, usługi takie jak AI czy wysyłka SMS, oraz rozbudowa. Dostępy do aplikacji traktuj jak klucze do biura: gdy ktoś odchodzi, jego konto wyłącza się tego samego dnia.

Słownik pojęć z rozmów o zakresie

Kilka słów, które pojawią się w ofercie i w rozmowie o pierwszej wersji.

• MVP. Najmniejsza wersja aplikacji, która pozwala wykonać jedno zadanie od początku do końca w prawdziwej pracy. W naszej ofercie to „pierwsza wersja”.
• Zakres. Lista funkcji, ról, danych oraz integracji, które powstaną w danym etapie. Wycena dotyczy zakresu, więc jego zmiana oznacza zmianę wyceny.
• Proces. Ciąg czynności od zdarzenia początkowego do końcowego, na przykład od wpływu zapytania do zamknięcia sprawy. Pierwsza wersja obsługuje jeden.
• Rola. Zestaw uprawnień przypisany do typu użytkownika: handlowiec, serwisant, kierownik, administrator. Określa, co kto widzi i zmienia.
• Scenariusz testowy. Opis konkretnej sytuacji, którą użytkownik przechodzi w aplikacji podczas testów, na przykład „klient zmienia termin po przypisaniu serwisanta”.
• Kryteria odbioru. Lista warunków, po spełnieniu których etap uznaje się za zakończony. Ustalane przy zakresie, sprawdzane przy testach.
• Integracja. Połączenie aplikacji z innym systemem. Wymaga sprawdzenia, co ten system udostępnia i na jakich warunkach.
• API. Interfejs, przez który jeden system udostępnia dane drugiemu. Jego brak nie wyklucza integracji, ale ogranicza ją do eksportu i importu plików.
• Migracja. Przeniesienie danych z obecnych narzędzi do aplikacji, z czyszczeniem i sprawdzeniem wyniku. Zakres migracji jest częścią zakresu etapu.
• Źródło prawdy. System, który jako jedyny może zmieniać daną informację. Przy integracji ustalane dla każdego pola osobno.
• Utrzymanie. Opieka nad działającą aplikacją: poprawki, kopie, aktualizacje, reakcja na zgłoszenia. Ustalane w ofercie osobno od budowy.
• Kolejny etap. Zakres, który powstaje po ocenie pierwszej wersji. Osobna wycena, ale uwzględniony w projekcie danych od początku.

Lista kontrolna przed rozmową o zakresie

Zaznacz, co masz, co masz do ustalenia, a czego świadomie nie będzie w pierwszej wersji. Z taką listą pierwsza rozmowa kończy się propozycją zakresu, a nie kolejną listą pytań.

1. Jedno pytanie, na które ma odpowiedzieć wdrożenie.
2. Jeden proces z wyraźnym początkiem i końcem oraz osoba, która jest jego właścicielem.
3. Opowieść o jednym zwykłym zleceniu i trzech trudnych sytuacjach.
4. Anonimowy arkusz albo przykład obiegu, w którym proces działa dzisiaj.
5. Lista użytkowników pierwszej wersji z rolami: kto przegląda, kto zmienia, kto administruje.
6. Funkcje podzielone na konieczne, wspierające, do sprawdzenia i na kolejny etap.
7. Co zostaje w obecnych narzędziach i gdzie jest granica aplikacji.
8. Systemy do połączenia w pierwszej wersji, z informacją, czy mają dokumentację.
9. Decyzja o danych: przenosimy wszystko, tylko aktywne, czy zaczynamy od zera.
10. Plany na kolejne etapy, które muszą być uwzględnione w strukturze danych.
11. Wymagania co do miejsca utrzymania, kopii oraz ochrony danych, jeśli firma je ma.
12. Miernik i punkt wyjścia zapisane przed uruchomieniem.
13. Osoba po stronie firmy, która zbiera uwagi i zatwierdza etapy.
14. Osoby do testów z zespołem i zgoda na to, że testy odbędą się na prawdziwych sprawach.

Punkty od 1 do 4 wystarczą, żeby zacząć rozmowę. Reszta może dojść na etapie poznawania sposobu pracy. Jeśli któryś punkt budzi w firmie spór, zapisz obie wersje. Spór o zakres przed wyceną kosztuje rozmowę. Ten sam spór w trakcie budowy kosztuje przebudowę.

TL;DR

• Zapisz jedno pytanie, na które ma odpowiedzieć pierwsza wersja, i wybierz jeden proces, który obsłuży od początku do końca.
• Podziel funkcje na konieczne, wspierające, do sprawdzenia i na kolejny etap. Do pierwszej wersji wchodzą konieczne.
• Uprawnień, kopii zapasowych, obsługi błędów i ochrony danych nie da się odłożyć. Dopasowujemy je do wielkości aplikacji.
• Przenoś tylko dane, których zespół używa. Próbna migracja pokazuje problemy przed przeniesieniem całości.
• Integracja wchodzi do pierwszej wersji, gdy bez niej zadania nie da się wykonać. AI rzadko, chyba że jest celem wdrożenia.
• Dane i role planuj pod kolejne etapy już teraz, nawet jeśli ich nie budujesz.
• Przed uruchomieniem zapisz miernik i punkt wyjścia. Decyzję o rozwoju podejmuj na podstawie użycia, nie wrażeń.

FAQ