Rozwój systemu do zarządzania firmą etapami: co powinno znaleźć się w pierwszej wersji

Pytanie „co umieszczamy w pierwszej wersji” niemal zawsze otrzymuje tę samą błędną odpowiedź: po trochu wszystkiego. Kawałek kartotek, kawałek zamówień, kawałek magazynu. To wybór, który wydaje się najbardziej ostrożny, a jest tym, którego nie da się użyć: żaden proces nie dobiega końca, a system pozostaje czymś, co trzeba wypełniać dodatkowo, obok tego, co już się robi.

Kryterium jest odwrotne: pierwsza wersja obejmuje cały proces, od początku do końca, nawet jeśli jest wąski. Lepiej mało i kompletnie niż dużo i urywkowo.

Cały proces, z widocznym rezultatem

„Cały” ma precyzyjne znaczenie: osoba, która go używa, musi móc zrezygnować z dotychczasowej metody dla tego fragmentu pracy. Jeśli po wprowadzeniu danych do systemu nadal wypełnia się też dawny arkusz, pierwsza wersja nie jest ukończona: to podwójna praca, która zostanie porzucona, gdy tylko firma przeżyje trudny tydzień.

Rezultat musi być widoczny dla kogoś: wystawiony dokument, lista, której wcześniej nie było, telefon, który przestaje być potrzebny. Służy to dwóm celom naraz: daje konkretny powód, by korzystać z systemu, oraz dowód, że projekt do czegoś zmierza.

Oddzielić niezbędne od usprawnień

Wnioski napływają wszystkie naraz i wszystkie jako pilne. Potrzebne są pytania, które je rozdzielą, i są to zawsze te same cztery pytania.

• Czy bez tej funkcji proces się zatrzymuje? Jeśli ktoś może zrobić to samo w inny sposób, na razie nie jest ona niezbędna.
• Kto z niej korzysta i jak często? Funkcje potrzebne dwa razy w roku mogą długo pozostać ręczne, i często pozostają ręczne na zawsze, bez czyichkolwiek zastrzeżeń.
• Co naprawdę się stanie, jeśli jej zabraknie? „Tracimy czas” i „nie możemy wystawić faktury” to nie ta sama odpowiedź.
• Czy to funkcja, czy przyzwyczajenie? Zdarza się, że trzeba odtworzyć krok, który istniał tylko dlatego, że stare narzędzie nie potrafiło nic innego.

Trzeba uważać na krótkie wnioski, które kryją za sobą cały świat: jeden dodatkowy status na dokumencie może wymagać uprawnień, powiadomień, historii zmian oraz reguły określającej, kto może go zmieniać. Kosztu nie mierzy się długością zdania, które go opisuje.

Zależności, których nie można odłożyć

Wdrażanie modułami działa tylko wtedy, gdy niektóre decyzje zostają podjęte od razu, nawet jeśli dotyczą części, które pojawią się dużo później. Jest ich niewiele, a zmiana ich później kosztuje tyle samo, co zrobienie wszystkiego od nowa.

• Dane wspólne: jak identyfikuje się klienta, produkt, zlecenie. Jeśli pierwsza wersja wymyśli własną numerację, druga będzie musiała uzgadniać dwa archiwa.
• Kto co widzi: uprawnienia projektuje się na początku, nawet jeśli na początku z systemu korzysta zaledwie troje ludzi. Dodanie ich później oznacza konieczność przejrzenia każdego ekranu.
• Skąd pochodzą dane, które nie powstają tutaj: jeśli stany magazynowe znajdują się gdzie indziej, już teraz ustala się, kto decyduje o ilości, nawet jeśli połączenie powstanie później.
• Jak rejestruje się historię: jeśli potrzebna jest wiedza, kto co zmienił, trzeba to przewidzieć od razu, ponieważ później nie da się tego odtworzyć.

Przykład: pierwsza wersja dla zleceń

Firma zajmująca się montażem instalacji chce systemu do obsługi zleceń. Lista życzeń zawiera około dwudziestu funkcji. Pierwsza wersja przyjmuje cztery z nich, ale doprowadza proces do końca.

Funkcje pozostawione poza zakresem nie są usunięte: pozostają na liście, z podanym obok powodem i warunkiem, który sprawi, że wrócą. To różnica między odłożeniem a zapomnieniem, i to właśnie ona pozwala odpowiedzieć osobom, które o nie prosiły.

Kryteria odbioru: jak stwierdzić, że praca jest ukończona

„Działa” nie jest kryterium. Kryterium to zdanie, które każdy może zweryfikować, spisane przed rozpoczęciem prac programistycznych.

1. Opisać rzeczywisty przypadek, a nie funkcję: „kierownik budowy otwiera zlecenie na podstawie zaakceptowanej wyceny, przydziela zespół i wypełnia raport z telefonu, na budowie”.
2. Wskazać, kto to weryfikuje: osobę, która będzie wykonywać tę pracę codziennie, a nie tę, która zleciła projekt.
3. Uwzględnić nietypowe przypadki: anulowane zlecenie, raport wypełniony bez zasięgu sieci, interwencję, której termin się przesuwa.
4. Ustalić, na jakich danych się testuje: prawdziwych i aktualnych, ponieważ dane wymyślone są zawsze bardziej uporządkowane niż rzeczywistość.

Wnioski napływające w trakcie

Będą napływać, i to dobry znak: oznacza, że ktoś korzysta z systemu. Problemem nie jest ich otrzymywanie, lecz szybkie ich klasyfikowanie.

• Błąd: to, co istnieje, nie robi tego, co zostało uzgodnione. Poprawia się od razu.
• Przeoczenie: jest potrzebne procesowi, a nikt o tym nie wspomniał. Ocenia się, czy zostanie włączone, a termin dostawy odpowiednio się przesuwa.
• Usprawnienie: ułatwia pracę. Trafia na listę, a nie do bieżącej wersji.
• Zmiana kierunku: firma zmieniła sposób pracy. Wymaga osobnej dyskusji, ponieważ nie jest to wniosek, lecz inny projekt.

Bez tego rozróżnienia każdy wniosek staje się pilny, a pierwsza wersja nigdy nie zostaje wydana. To najczęstszy sposób, w jaki takie projekty się zatrzymują: nie z powodu przeszkody technicznej, lecz z powodu nagromadzenia.

Czego ten przewodnik nie obejmuje

Tutaj mowa jest o zakresie i kolejności: co znajduje się w pierwszej wersji, co się odkłada i w jakiej kolejności. Testy, które należy wykonać, zanim zacznie się codziennie polegać na systemie, to osobny temat. A jeśli funkcja, którą trzeba ocenić, dotyczy wykorzystania automatycznego asystenta, kryteria oceny są inne, ponieważ wynik nie jest przewidywalny w ten sam sposób.