Wdrożenie dodatku kończy się niepowodzeniem zwykle nie z powodu kodu, lecz dlatego, że nie ustalono, co dokładnie ma robić.
1. Opisać potrzebę, nie rozwiązanie
„Chcemy przycisk, który wystawi dokument” to opis rozwiązania. „Wystawiamy dziennie sto dokumentów przepisując dane z zamówień, co zajmuje trzy godziny i generuje pomyłki” to opis potrzeby — i pozwala znaleźć lepsze wyjście.
2. Zmierzyć stan obecny
Liczba operacji, czas, liczba błędów. Bez tego nie da się ocenić, czy dodatek się opłacił.
Wystarczą proste miary zbierane przez tydzień: ile dokumentów, ile czasu, ile poprawek. Nie chodzi o dokładność, tylko o punkt odniesienia — bez niego ocena po wdrożeniu opiera się na wrażeniach.
3. Sprawdzić standard
Czy system już tego nie potrafi. Krok pomijany zaskakująco często, a bywa, że kończy sprawę.
Warto pytać nie tylko dostawcy systemu, ale i osób, które pracują w nim najdłużej. Wiele funkcji istnieje, tylko nie są używane, bo nikt ich nie pokazał.
4. Ustalić przypadki brzegowe
Co przy braku danych, co przy różnicy, co przy przerwaniu operacji. To rozstrzygnięcia biznesowe i muszą zapaść przed pisaniem kodu.
Rozstrzygnięcia trzeba spisać. Zdanie „ustaliliśmy na spotkaniu” po dwóch miesiącach oznacza dwie różne wersje w dwóch głowach, a różnica wychodzi przy odbiorze. Więcej o samych przypadkach piszemy przy testowaniu dodatków.
5. Testy na kopii z udziałem użytkowników
Na prawdziwych danych i przy prawdziwym sposobie pracy.
Na tym etapie wychodzą zwykle braki w opisie potrzeby, a nie błędy w kodzie. To dobry moment, żeby je poprawić — później każda zmiana kosztuje więcej.
6. Uruchomienie i praca równoległa
Przez ustalony czas obie drogi, z porównaniem wyników.
Warto uruchamiać etapami: najpierw jedna osoba albo jeden rodzaj dokumentów, potem reszta. Wdrożenie obejmujące od razu cały zespół nie zostawia miejsca na wycofanie się.
7. Utrzymanie
Kto sprawdza dodatek po aktualizacji systemu, kto poprawia, na jakich warunkach. Ustalone na początku, a nie przy pierwszej awarii.
Do utrzymania należy też sprawdzanie dodatku po zmianach wersji — temat opisujemy przy aktualizacjach i własnych rozszerzeniach. Ten koszt jest stały i lepiej uwzględnić go od początku.
Ile to trwa i jak się rozlicza
Zależy od zakresu. Wiele rozwiązań jest gotowych i wymaga tylko dostosowania, więc proste wdrożenia zamykają się w kilka dni. Największą częścią pracy bywa nie kod, lecz ustalenia po stronie firmy — dlatego pierwsze cztery kroki mają realny wpływ na czas całości. Rozliczenie prowadzimy stawką godzinową albo wyceną za projekt, zależnie od zakresu.
Czego się spodziewać
Że po pierwszym tygodniu pojawią się przypadki, których nikt nie przewidział. To normalne — dlatego okres pracy równoległej ma sens.
Warto też z góry przyjąć, że część zgłoszeń okaże się prośbą o zmianę procesu, a nie o poprawkę dodatku. To normalne i wraca do pytania, kiedy dodatek, a kiedy zmiana sposobu pracy.
