W zarządzaniu projektami IT od lat krąży przekonanie, które brzmi mniej więcej tak: zmiana na etapie dokumentacji kosztuje jedną jednostkę, na etapie testów dziesięć, a po wdrożeniu na produkcję sto. Z tego wynika klasyczna kolejność prac: najpierw długa analiza i szczegółowy opis, potem programowanie, potem testy. Im więcej uzgodnimy na papierze, tym mniej poprawek będziemy wprowadzać później, kiedy są najdroższe.
To rozsądne rozumowanie. Ale jedna z jego przesłanek przestała być prawdziwa.
Co się zmieniło
Do niedawna zrobienie makiety ekranów, a tym bardziej działającego prototypu, było pracochłonne. Dlatego lepiej było opisać wszystko na papierze, a dopiero potem budować. Dziś duże modele językowe potrafią na podstawie opisu wytworzyć działający kod, a nawet przygotować środowisko, w którym uruchomisz aplikację. Wireframe, prototyp, a nawet pierwsza wersja produktu (MVP) powstają w godzinach, a nie w tygodniach czy miesiącach. Koszt takiej pierwszej wersji jest wielokrotnie niższy niż kilka lat temu.
Wniosek jest prosty: dla małych i średnich systemów prototyp może być dziś tańszy niż dokument, który próbuje opisać każdy szczegół. Nie mówię o ogromnych systemach, w których dokumentacja nadal jest niezbędna. Mówię o narzędziach, w których jest kilka powiązanych ze sobą tabel, formularze i listy: rejestry, proste CRM-y, ewidencje, panele zgłoszeń.
Dlaczego prototyp jest lepszą specyfikacją
Doskonały, szczegółowy dokument opisujący każdą klasę, relację i przypadek użycia byłby oczywiście najlepszym punktem wyjścia dla programisty. Tylko że przygotowanie takiego dokumentu jest długie i drogie, a mimo to każdy czyta go trochę inaczej. Prototyp ma kilka zalet, których nie ma papier:
- Możesz go kliknąć. Zobaczysz, jak narzędzie działa, zanim zapłacisz za jego dopracowanie. Wiele wątpliwości znika po pięciu minutach, bo okazuje się, że ekran, który wydawał się oczywisty, jest niewygodny, albo że brakuje pola, o którym nikt nie wspomniał.
- Jest zrozumiały dla każdego. Tom dokumentacji rozumie analityk. Prototyp rozumie księgowa, magazynier i prezes.
- Porządkuje dane. Powstaje od razu schemat danych, który potem możesz rozwijać, podłączać do niego kolejne narzędzia i łączyć z programami używanymi w firmie.
- Pokazuje wąskie gardła. Gdy zespół zaczyna pracować na prototypie, widać, które sprawy czekają w kolejce i kto ma zbyt wiele na głowie.
- Jest żywym dokumentem dla wykonawcy. Jeśli później zdecydujesz się zlecić profesjonalną wersję firmie wdrożeniowej, możesz przekazać jej działającą aplikację z zastrzeżeniem: „zrób to samo, ale bezpiecznie i na docelowych serwerach”. Zamiast opisu, który każdy zrozumie trochę inaczej, wykonawca dostaje wzór. Ryzyko, że zbuduje rzeczy niepotrzebne albo niezrozumiałe, maleje, bo od razu widzi, co jest potrzebne.
Podobnie jest, gdy narzędzie zbudowane najpierw w prostszej technologii trzeba przenieść na „prawdziwy” kod: zamiast pisać obszerną dokumentację, wystarczy pokazać programistom demo. „Tu klikam, tu mi działa, tu chcę zmienić”. Wtedy mają przed sobą gotowe ekrany, widoki i logikę biznesową, a nie wyobrażenia.
Częste pokazy zamiast jednego odbioru
Prototyp pomaga też w pilnowaniu, żeby wykonawca budował to, co masz w głowie. W projektach zdarza się, że przedsiębiorca przez cały czas ufa, że zespół „czyta w jego myślach”, a po roku okazuje się, że kierunek został wybrany źle już na początku. Częste, krótkie demo, na którym oglądasz małe fragmenty gotowej funkcji, jest najlepszym zabezpieczeniem. Drobna uwaga z Twojej strony potrafi uratować projekt przed skrętem w złą stronę, a drobny szczegół interfejsu może podpowiedzieć Ci pomysł lub uświadomić, że coś trzeba zmienić jak najwcześniej.
Czego prototyp nie załatwi
Prototyp to nie produkt. Warto być w tym uczciwym:
- Bezpieczeństwo. Jeśli chcesz zacząć szybko, nie zabezpieczysz narzędzia tak profesjonalnie, jak powinno być zabezpieczone narzędzie w publicznym internecie. Dlatego zaczynam od wersji wewnętrznej, dostępnej tylko dla pracowników. To ograniczenie, ale w zamian od razu dostajesz coś, co działa i porządkuje chaos.
- Wdrożenie. Później narzędzie można profesjonalnie zabezpieczyć i umieścić na odpowiednio chronionych serwerach. Dopiero wtedy da się je otworzyć na zewnątrz, na przykład dla klientów, którzy będą się logować, albo dla procesów łączących się z innymi systemami.
- Duże systemy. Przy rozbudowanych systemach, w których kluczowe są integracje, wydajność i odpowiedzialność prawna, dokumentacja nadal jest potrzebna. Prototyp jej nie zastąpi, tylko uzupełni.
Jak to wygląda w praktyce
- Opisz problem i miarę sukcesu (Zacznij od problemu, nie od rozwiązania).
- Zbuduj najprostszą wersję, która rozwiązuje jedno zadanie.
- Przeklikaj ją z ludźmi, którzy będą z niej korzystać, i zapisz uwagi.
- Popraw prototyp i pokaż jeszcze raz.
- Dopiero teraz spisz krótką specyfikację, a prototyp dołącz do niej jako załącznik.
- Zbierz oferty od wykonawców na podstawie tego samego materiału. Wyceny będzie łatwiej porównać.
W warsztatach, które prowadzę, pierwszy działający prototyp zespół ma zwykle po jednej, dwóch sesjach. Zobacz na przykład, jak klient sam zbudował narzędzie dla inspektorów w jeden dzień, a ja dopracowałem je i wdrożyłem na jego serwerze.
Jak mogę pomóc
Jeśli planujesz zlecić system i chcesz mieć coś, co wykonawcy wycenią tak samo, zobacz usługę Prototyp i specyfikacja przed zleceniem. Jeśli wolisz zbudować narzędzie samodzielnie, a ja mam poprowadzić Twój zespół, przeczytaj o warsztatach budowy aplikacji dla firm.