Pierwsza wersja programu, która od razu pracuje

Pierwsza wersja ma jedno zadanie. Ma przestać boleć to, co dziś boli najbardziej. Nie budujemy połowy dużego systemu, tylko całość jednego procesu, tak żeby dało się z niej korzystać w poniedziałek rano.

Różnica jest praktyczna. Program, który obsługuje jeden proces od początku do końca, wchodzi do firmy i zostaje. Program, który obsługuje połowę pięciu procesów, leży w zakładce i ludzie wracają do arkusza.

Dlatego pierwsze pytanie na rozmowie nie brzmi „co chcesz zbudować”, tylko „co dziś zajmuje najwięcej godzin i kto je traci”.

Pierwsza wersja opłaca się wtedy, gdy proces już istnieje i już kosztuje. Nie trzeba go wymyślać, trzeba go zdjąć z ludzi.

• Firma, która utknęła w arkuszuExcel działał do czasu. Teraz są cztery kopie tego samego pliku, nikt nie wie, która jest aktualna, a jedna osoba spędza wieczory na scalaniu.
• Firma, która przepisuje dane między programamiZamówienie przychodzi mailem, ktoś przepisuje je do arkusza, potem do programu magazynowego, na końcu do faktury. Cztery razy to samo, cztery okazje do pomyłki.
• Firma, która ma pomysł na produktChcesz sprawdzić, czy klienci zapłacą, zanim wydasz budżet na pełny system. Pierwsza wersja daje odpowiedź na prawdziwych użytkownikach, nie na ankiecie.
• Firma po nieudanym wdrożeniuPoprzedni wykonawca zniknął albo oddał coś, czego nikt nie używa. Zaczynamy od jednego procesu i pokazujemy działającą wersję co tydzień, żebyś nie kupował kota w worku drugi raz.

Jeżeli proces jest jeden, ale duży i mocno związany z resztą firmy, sensowniej wejść od razu w program pod procesy firmy, a nie w pierwszą wersję.

Mówimy o tym na pierwszej rozmowie, zanim policzysz budżet. Są sytuacje, w których pierwsza wersja to strata pieniędzy i lepiej zrobić coś innego.

• Gdy proces musi być kompletny od pierwszego dniaRejestracja czasu pracy, rozliczenia z urzędem albo ewidencja, która ma podstawę w przepisach, nie znosi wersji częściowej. Tu albo działa całość, albo nie wolno tego włączyć. W takich miejscach idziemy w gotowy produkt, na przykład Auresta RCP, zamiast budować od zera.
• Gdy nie wiadomo, kto będzie tego używałJeżeli w firmie nie ma osoby, która powie „to jest moje i ja tego pilnuję”, program nie wejdzie do użytku niezależnie od tego, jak dobrze go napiszemy. Najpierw ustalamy właściciela procesu.
• Gdy problemem jest sam proces, nie brak programuCzasem firma prosi o program, który utrwali bałagan. Jeżeli dwie osoby robią to samo w dwóch miejscach, program tego nie naprawi, tylko przyspieszy. Wtedy najpierw prostujemy proces, a dopiero potem go zdejmujemy.
• Gdy gotowe narzędzie wystarczyJeżeli to, czego potrzebujesz, robi program za kilkaset złotych miesięcznie, powiemy to wprost i nie weźmiemy zlecenia. Budowanie własnego ma sens wtedy, gdy proces jest na tyle Twój, że gotowe pudełko go nie obsłuży.

To nie jest kurtuazja. Odradziliśmy kilka projektów i wolimy stracić zlecenie niż oddać coś, co przeleży rok bez użytkowników.

Zakres ustalamy na bezpłatnej rozmowie i zapisujemy przed startem. Poniżej to, co zwykle mieści się w pierwszych czterech do ośmiu tygodniach, i to, co świadomie zostawiamy.

Lista rzeczy odłożonych nie znika. Wraca na rozmowie po starcie i wtedy decydujesz, co wchodzi do drugiego etapu.

Pracujemy tygodniami. Na koniec każdego dostajesz działającą wersję pod adresem, który możesz otworzyć i kliknąć. Nie zrzuty ekranu i nie raport z postępu.

1. 1Ustalamy i pokazujemy szkieletRozpisujemy proces na kroki i budujemy klikalny szkielet. Na koniec tygodnia widzisz układ ekranów i mówisz, gdzie to nie pasuje do tego, jak pracujecie.
2. 2Wchodzą dane i logowanieProgram zaczyna zapisywać. Wczytujemy Twoje dane z arkusza, wchodzą konta i role. Od tego momentu da się na tym pracować na próbę.
3. 3Domykamy procesOstatnie kroki procesu, eksport, widok na telefonie. W tym tygodniu zwykle wychodzą rzeczy, o których nikt nie pomyślał na starcie, i to jest normalne.
4. 4Uruchomienie i szkolenieProgram idzie na serwer, zespół dostaje szkolenie, Ty dostajesz dostęp do kodu. Od tej chwili pracujecie na żywo, a my siedzimy przy telefonie.

Przy większym zakresie tygodni jest sześć albo osiem. Rytm zostaje ten sam, co tydzień działająca wersja, a płatność idzie w ratach za kolejne etapy.

Firma usługowa, dziewięć osób, zlecenia przychodzą mailem i telefonicznie. Jedna osoba prowadzi wszystko w arkuszu i przepisuje to potem do faktur. Tak wygląda rachunek przed i po.

Osoby pracujące na zleceniach

9

Zleceń miesięcznie

ok. 180

Przepisywanie i scalanie arkuszy

6 godzin tygodniowo

Szukanie, co ustalono z klientem

3 godziny tygodniowo

Poprawki po pomyłkach w przepisywaniu

2 godziny tygodniowo

Razem do odzyskania

11 godzin tygodniowo

Zakres pierwszej wersji

4 tygodnie

Przy jedenastu godzinach tygodniowo pierwsza wersja zwraca się zwykle w kilka miesięcy.

To przykład, nie Twoja wycena. Dokładny rachunek robimy na bezpłatnej rozmowie, na Twoich liczbach, i dopiero potem podajemy jedną stałą cenę na piśmie.

Widzieliśmy je u siebie i u firm, które przychodzą po nieudanym wdrożeniu. Każdy z nich kosztuje tygodnie.

1. 1Zakres ustalony listą życzeńGdy zakres powstaje z zebrania, na którym każdy dorzuca swoje, pierwsza wersja rośnie do pół roku i nikt jej nie widzi po drodze. Zakres ma wynikać z jednego procesu, nie z listy działów.
2. 2Budowanie pod wyjątek, nie pod regułęFirma opisuje najtrudniejszy przypadek z zeszłego roku i program powstaje pod niego. Potem okazuje się, że dziewięćdziesiąt procent zleceń wygląda zupełnie inaczej i jest niepotrzebnie skomplikowane.
3. 3Odkładanie danych na koniecImport zostawiony na ostatni tydzień to najczęstsza przyczyna poślizgu. Prawdziwe dane zawsze są brudniejsze niż zapowiadano, dlatego wczytujemy je w drugim tygodniu.
4. 4Brak osoby po stronie firmyJeżeli nie ma kogoś, kto co tydzień obejrzy wersję i powie „tak” albo „nie”, decyzje podejmuje wykonawca. To zawsze kończy się programem, który pasuje do wyobrażeń wykonawcy, nie do firmy.
5. 5Traktowanie startu jak końcaPierwsze dwa tygodnie po uruchomieniu to moment, w którym widać prawdę. Kto na starcie zamyka projekt i znika, ten zostawia firmę z programem, którego nikt nie poprawił po pierwszym zderzeniu z rzeczywistością.

Obiekt hotelarski na Podkarpaciu, kilkudziesięciu pracowników recepcji, kuchni, SPA i sprzątania, w większości na zmianach. Ewidencja czasu pracy szła na papierowych listach obecności, a nadgodziny liczono ręcznie w Excelu na koniec miesiąca. Zdarzały się pomyłki i spory z pracownikami, a ludzie odbijali się nawzajem.

Zaczęliśmy od jednego procesu, nie od całej platformy. Pierwszy działający moduł to Auresta RCP, czyli rejestracja czasu pracy z terminalem, logowaniem jednorazowym kodem QR albo PIN-em i liczeniem nadgodzin bez arkusza. Działa na serwerze klienta, więc dane pracowników zostają u niego.

Efekt jest prosty do sprawdzenia. Papierowe listy obecności zniknęły, a główna księgowa prowadzi pełną ewidencję i miesięczne raporty zdalnie, będąc na opiece nad dzieckiem. Reszta platformy powstaje etapami, już na działającym fundamencie.

• 0papierowych list obecności
• 16typów nieobecności wg Kodeksu pracy
• zdalniepełna ewidencja i raporty
• u klientadane zostają na jego serwerze

Całą historię tego wdrożenia opisaliśmy w realizacji Auresta RCP, razem z listem referencyjnym od klienta.

Trzy teksty, które odpowiadają na pytania zadawane najczęściej przed pierwszą rozmową.

• Ile kosztuje MVP →Rynkowe widełki, co podbija cenę i gdzie najczęściej się przepłaca.
• Co zdążysz w MVP w 4 do 8 tygodni →Co realnie mieści się w pierwszym miesiącu, a co nie ma szans.
• MVP czy od razu pełna aplikacja →Jak podjąć decyzję, zanim wydasz budżet na funkcje, których nikt nie użyje.