Przed pierwszą rozmową o integracji albo aplikacji nie potrzebujesz gotowej specyfikacji. Potrzebujesz za to jednego procesu, który da się pokazać od początku do końca.
Najlepiej wziąć prawdziwe zamówienie, reklamację albo zgłoszenie. Otwórz formularz, wiadomości, arkusz i programy użyte przy tej sprawie. Z takiego materiału można wyciągnąć znacznie więcej niż z listy planowanych funkcji.
Weź jedną prawdziwą sprawę
Załóżmy, że chcesz wycenić system do obsługi zamówień. Zamiast pisać „moduł klientów, zamówień i raportów”, wybierz ostatnie zakończone zamówienie. Pokaż, gdzie wpłynęło, kto je otworzył, co skopiował, co sprawdził, komu przekazał i jaki dokument zamknął sprawę.
Nie poprawiaj procesu na potrzeby opisu. Jeśli ktoś dopisał informację ręcznie, dzwonił po potwierdzenie, szukał pliku na dysku albo wrócił do wcześniejszego kroku, zapisz to. Każde takie obejście może zmienić zakres rozwiązania.
Nie musisz przed pierwszą rozmową znać technologii, rozrysowywać bazy danych ani projektować każdego ekranu. Potrzebny jest materiał, na którym można odróżnić fakty od pomysłów.
Wyznacz granice
Wybierz jeden proces z rozpoznawalnym początkiem i końcem. „Obsługa klienta” jest zbyt szeroka. „Od wysłania formularza zamówienia do wystawienia faktury” daje zakres, który można przejść krok po kroku.
Następnie wybierz jedną zakończoną sprawę i odtwórz jej rzeczywisty przebieg. Zapisz, kto ją rozpoczął, jakie informacje otrzymał, w którym narzędziu pracował, komu przekazał wynik i po czym następna osoba wiedziała, że może działać. Najprostszy zapis to: osoba → czynność → narzędzie → wynik.
Na tym etapie wystarczą prostokąty i strzałki. Szkic na kartce, w dokumencie albo na tablicy w zupełności wystarczy do rozpoczęcia rozmowy.
Przygotuj kartę procesu
Opis zmieści się na jednej lub dwóch stronach, jeśli każde pole będzie dotyczyć obserwowalnego faktu. Dołącz materiały, które już istnieją: pusty wzór formularza, zanonimizowany arkusz, przykładowy dokument albo treść komunikatu błędu. Nie przesyłaj prawdziwych danych osobowych, danych logowania ani sekretów dostępowych.
Co zapisać przed wyceną
- Początek i koniec procesu opisane jednym zdaniem
- Osoby lub role wykonujące kolejne czynności
- Używane programy, arkusze, formularze i dokumenty
- Dane pobierane na wejściu oraz tworzone na wyjściu
- Decyzje, zgody i warunki zmieniające dalszy przebieg
- Wyjątki, poprawki oraz miejsca powrotu do wcześniejszego kroku
- Częstotliwość procesu i dostępne dane o jego koszcie
- Ograniczenia prawne, umowne, techniczne i organizacyjne
- Oczekiwany rezultat oraz sposób sprawdzenia, czy został osiągnięty
Jeśli nie masz danych o częstotliwości albo koszcie, oznacz to jako brak zamiast wstawiać szacunek. Możesz najpierw zmierzyć czas i poprawki w jednym ręcznym procesie. Rzeczywista obserwacja jest bardziej użyteczna niż precyzyjnie wyglądająca liczba bez źródła.
Pokaż wyjątek
Opis idealnego przebiegu zwykle pomija część, która najbardziej wpływa na zakres. Załóżmy, że zwykłe zamówienie przechodzi z formularza do CRM-u, a potem do księgowości. Co dzieje się, gdy brakuje numeru NIP, klient zmienia adres po akceptacji albo płatność ma zostać podzielona?
Wystarczy jeden zwykły przypadek i dwa różne wyjątki, które naprawdę wystąpiły. Przy każdym dopisz, kto zauważa problem, gdzie sprawdza brakującą informację, kto może podjąć decyzję i jak sprawa wraca do głównego przebiegu. Właśnie tutaj często ujawniają się potrzebne uprawnienia, historia zmian, powiadomienia albo obsługa błędów integracji.
Poproś osobę, która wykonuje tę pracę, żeby pokazała ostatni wyjątek na konkretnych materiałach. Opis z pamięci łatwo pomija dodatkowy telefon, notatkę, drugi arkusz albo ręczne sprawdzenie. Zapisz te obejścia bez oceniania. Dopiero później zdecyduj, czy dany krok powinien znaleźć się w systemie, czy zniknąć z procesu.
Oddziel rezultat od funkcji
Zapisz stan obecny i potrzebny rezultat osobno. „System ma wysyłać e-mail po zmianie statusu” jest już pomysłem na funkcję. Potrzeba może brzmieć: „Osoba realizująca zamówienie musi wiedzieć, że klient zaakceptował wycenę, zanim rozpocznie pracę”. E-mail, zadanie w CRM-ie albo zmiana na wspólnej liście to różne sposoby spełnienia tej potrzeby.
Dodaj także elementy poza zakresem. Jeżeli na pierwszym etapie nie zmieniamy księgowości, nie przenosimy archiwalnych danych albo nie obsługujemy oddziału zagranicznego, zapisz to wprost. Brak tej granicy sprawia, że każda kolejna rozmowa może dotyczyć innego projektu.
Dopiero z takim materiałem można sensownie przejść do wyboru między gotowym systemem, integracją i własnym oprogramowaniem. Czasem karta procesu pokaże, że wystarczy usunąć zbędny krok. To również jest dobry wynik analizy.
Co wysłać
Przygotuj krótki pakiet: kartę procesu, prosty szkic przepływu oraz zanonimizowane przykłady materiałów używanych w pracy. Dodaj listę osób, które powinny odpowiedzieć na pytania o wyjątki, dane i ograniczenia. Nie próbuj zamieniać tego pakietu w ostateczną specyfikację — część założeń trzeba będzie sprawdzić podczas analizy.
Taki opis nie gwarantuje ceny bez dodatkowych pytań. Pozwala jednak szybciej ustalić, co naprawdę ma się zmienić, które niewiadome wpływają na zakres i czy budowa oprogramowania w ogóle jest właściwym następnym krokiem.
