Blog
Blueprint: jak projektujemy, zanim zbudujemy
Dobry rysunek techniczny oszczędza tygodnie pracy. W oprogramowaniu działa to tak samo jak na budowie: tanio jest przesunąć linię na rysunku, drogo — przebudować ścianę. Dlatego zanim padnie pierwsza linijka kodu, rysujemy. Granice systemu, przepływy danych, punkty integracji i listę rzeczy, których świadomie nie robimy w pierwszej wersji.
Jak wygląda proces tworzenia oprogramowania na zamówienie?
Cztery etapy. Rozmowa techniczna, 60–90 minut. Blueprint, czyli rysunek rozwiązania plus klikalny prototyp. Budowa w dwutygodniowych iteracjach, na końcu każdego coś, co da się kliknąć. Wdrożenie i utrzymanie. Blueprint zwykle trwa od kilku dni do dwóch tygodni, zależnie od liczby integracji.
Kolejność nie jest przypadkowa. Każdy etap zamyka jedną klasę niewiadomych, zanim zaczniemy na nią poświęcać czas. Rozmowa zamyka pytanie „jaki problem naprawdę rozwiązujemy”. Blueprint zamyka pytanie „z czego to się składa i gdzie to pęknie”. Dopiero potem kod.
Co konkretnie powstaje przed kodem?
Sześć rzeczy: granice systemu, model danych, przepływy, punkty integracji, rejestr ryzyk i lista funkcji świadomie odłożonych. Razem to zwykle 3–5 stron dokumentu plus klikalny prototyp. Nie dwadzieścia stron specyfikacji, których nikt nie doczyta do końca.
Granice systemu
Co jest w środku, co zostaje na zewnątrz, kto jest właścicielem czego. Najtańsza decyzja w całym projekcie i najdroższa do zmiany później. W BARVEA granica brzmiała: przeglądamy i wersjonujemy modele zgodnie z ISO 19650, ale nie jesteśmy narzędziem do projektowania.
Model danych
Jakie byty istnieją, jakie mają relacje, który system jest źródłem prawdy dla każdego pola. Większość sporów o to, że „miało działać inaczej”, to w rzeczywistości spory o model danych — tylko nikt ich tak nie nazwał.
Przepływy
Ścieżka użytkownika i ścieżka danych, razem ze stanami pośrednimi i wyjątkami. Stany są ważniejsze od ekranów. W BARVEA to statusy S0–S6 z ISO 19650: dokument nie jest „gotowy albo nie” — przechodzi przez kolejne statusy według ustalonych reguł.
Punkty integracji
Konkretne API, formaty, limity, sposób uwierzytelniania. Sprawdzone, nie założone. Na tym etapie wysyłamy prawdziwe zapytania do cudzych systemów i patrzymy, co wraca. To zwykle najbrzydszy dzień w projekcie i najbardziej opłacalny. W autoPolar oznaczało to przepuszczenie realnych zdań NMEA 0183 i strumienia SignalK przez prototyp przeliczania AWA na TWA, zanim powstał jakikolwiek interfejs.
Rejestr ryzyk
Lista rzeczy, które mogą projekt zatrzymać, z odpowiedzią na pytanie „co robimy, jeśli to się wydarzy”. Ryzyko bez planu B to nie rejestr ryzyk, tylko lista zmartwień.
Lista rzeczy, których NIE robimy
Najbardziej niedoceniany dokument w branży. Wypisujemy funkcje świadomie odłożone na później i uzasadniamy dlaczego. Dzięki temu po trzech miesiącach nikt nie pyta „a co z modułem X” — bo stoi czarno na białym, że modułu X nie ma w pierwszej wersji i była to decyzja, nie przeoczenie.
Dlaczego projekt IT się przeciąga?
Prawie zawsze z trzech powodów: zakres odkrywany w trakcie, integracja z systemem, którego nikt wcześniej nie sprawdził, i decyzje odkładane „na później”. Rysunek techniczny likwiduje pierwszy powód, w dużej mierze drugi, a trzeci przesuwa na początek — kiedy zmiana decyzji kosztuje godziny, nie tygodnie.
Zakres odkrywany w trakcie
Projekt startuje z hasłem „system do obsługi zamówień”. W ósmym tygodniu okazuje się, że typy zamówień są trzy, dwa z nich mają osobną ścieżkę akceptacji, a jeden trafia do księgowości innym kanałem. To nie jest zmiana wymagań. To wymaganie, które istniało od początku, tylko nikt go nie narysował.
Integracja z systemem, którego nikt nie sprawdził
Dokumentacja API mówi jedno, produkcja robi drugie. Limit zapytań jest niższy, niż pisze w opisie. Pole, które miało być unikalne, unikalne nie jest. Wyjdzie to albo w trzecim dniu projektu, albo w trzecim miesiącu. Różnica w koszcie jest wielokrotnością, nie procentem.
Decyzje odkładane
„Ustalimy to później” to najdroższe zdanie w projektach IT. Zespół buduje wtedy dwie wersje naraz albo buduje coś, co i tak trzeba będzie przerobić. Blueprint nie sprawia, że decyzje stają się łatwe. Sprawia, że zapadają wtedy, kiedy są jeszcze tanie.
Klikalny prototyp czy specyfikacja — co daje więcej?
Prototyp wygrywa wszędzie tam, gdzie chodzi o zrozumienie i akceptację rozwiązania. Dokument wygrywa tam, gdzie chodzi o granice, decyzje i rzeczy, których na ekranie nie widać. W praktyce robimy jedno i drugie, tylko w innych proporcjach, niż przyjęło się w branży.
| Kryterium | Specyfikacja na 20 stron | Klikalny prototyp |
|---|---|---|
| Czas do pierwszej reakcji klienta | Dni — trzeba to przeczytać | Minuty — wystarczy kliknąć |
| Kto potrafi to ocenić | Osoba techniczna | Każdy, kto będzie z tego korzystał |
| Wykrywanie nieporozumień | Rzadko, obie strony czytają „swoje” | Natychmiast, brakujący krok widać |
| Koszt zmiany | Niski, ale zmiana bywa niezauważona | Niski i od razu widoczny |
| Pokazuje stany i wyjątki | Tak, jeśli ktoś je opisał | Tylko te, które narysowano |
| Utrwala decyzje i granice | Tak, to jego główna rola | Nie |
| Przydatność po wdrożeniu | Rzadko czytana ponownie | Zostaje punktem odniesienia dla UI |
Dlatego dokument ma u nas 3–5 stron i zawiera wyłącznie to, czego prototyp nie pokaże: granice, model danych, ryzyka i listę rzeczy nierobionych. Reszta jest do kliknięcia.
Tanio jest zmienić linię na rysunku. Drogo — przebudować ścianę.
Co dostaję po pierwszej rozmowie?
Zarys rozwiązania na jedną stronę: co budujemy, z czym się to integruje, co odkładamy i jakie widzimy ryzyka. Do tego wycena, zwykle w jeden dzień roboczy. Nie dostajesz oferty na dwadzieścia stron, bo na tym etapie byłaby zgadywaniem w ładnym formacie.
Potem, co dwa tygodnie, dostajesz coś, co da się kliknąć. Nie raport o postępie prac — działający kawałek systemu. To jedyny uczciwy sposób raportowania w oprogramowaniu, bo jako jedynego nie da się napisać z sufitu.
Kiedy ten etap można skrócić, a kiedy nie warto?
Skrócić można, gdy zakres jest mały i zamknięty, nie ma integracji z cudzymi systemami, dane nie podlegają regulacjom, a użytkownik jest jeden i siedzi w tym samym pokoju. Wtedy blueprint to pół dnia rozmowy i jeden szkic. Nie ma sensu rysować przez tydzień czegoś, co zbudujemy w tydzień.
Skracanie tego etapu bywa natomiast najdroższą decyzją w całym projekcie. Dzieje się tak, gdy występuje choć jedno z poniższych:
- Integracja z systemem, którego nie kontrolujesz. ERP, bramka płatnicza, cudze API. Koszt niesprawdzonego założenia rośnie tu z każdym tygodniem, bo na tym założeniu stoi już reszta kodu.
- Sprzęt. W ClimaBoxie zmiana w oprogramowaniu to godziny. Zmiana w płytce to tygodnie i nowa seria.
- Dane osobowe albo regulacje. Model danych ustala, co gdzie leży i jak długo. Poprawianie tego po wdrożeniu to migracja, nie refaktor.
- Więcej niż jedna grupa użytkowników o sprzecznych interesach. Zamawiający, wykonawca, kontrola jakości. Ich konflikty trzeba rozstrzygnąć na rysunku, bo w kodzie rozstrzygnie je przypadek.
- Migracja danych ze starego systemu. Stare dane zawsze są brudniejsze, niż ktokolwiek pamięta.
Dlaczego dwuosobowy zespół rysuje więcej, a nie mniej?
RIDOA to dwie osoby. Piszemy to wprost, bo zmienia to sposób pracy, a nie tylko wielkość faktury. Osoba, która rysuje, jest tą samą, która potem buduje. Nie ma przekazania między analizą a wykonaniem, więc nie ma miejsca, w którym gubi się kontekst. Nie mamy za to zapasu ludzi, którymi można nadrobić błąd projektowy. Dlatego rysunek musi być dobry.
Nasze cztery produkty powstały dokładnie w ten sposób: BARVEA (platforma BIM/CDE — IFC, BCF 2.1, COBie, plugin do Revita), ClimaBox (urządzenie IoT mierzące temperaturę, wilgotność i CO2, z panelem live), Let'Zapp (mapa wydarzeń na żywo) i autoPolar (asystent trymu dla żeglarzy, działający offline na pokładzie). Każdy zaczął się od rysunku i od listy rzeczy, których nie robimy. Można je obejrzeć w projektach.
Czego nie robimy i nie będziemy udawać, że robimy: stron na WordPressie z szablonu, samego hostingu bez projektu, wynajmu programisty do cudzego zespołu ani drobnych zleceń poniżej progu, przy którym cały ten proces ma sens. Jeśli szukasz jednej z tych rzeczy, znajdziesz lepszego wykonawcę niż my. Zakres, w którym pracujemy, opisaliśmy w ofercie.
Jeśli masz proces, który się sypie, i nie wiesz, od czego zacząć — napisz do nas. Pierwsza rozmowa jest techniczna i kończy się rysunkiem, nawet jeśli nic z tego dalej nie wyniknie.