Zasady inżynieryjne

Każda współpraca zaczyna się od zrozumienia domeny — ograniczeń fizycznych, słownika operacyjnego, istotnych trybów awarii. Dla operatora BESS oznacza to zrozumienie, ile przychodów z dyspozycji faktycznie kosztuje degradacja SOH — zanim napisze się choć jedno zapytanie. Dla nadawcy — zrozumienie, dlaczego pojedyncza utracona klatka na wejściu może skutkować niezgodnym pakietem dostawczym.

Wiedzy dziedzinowej nie traktujemy jako czegoś, co dostarcza klient, a my tylko konsumujemy. Sami w nią inwestujemy: czytamy dokumenty standardów, prowadzimy symulacje i zadajemy pytania, które wydają się podstawowe — bo to właśnie one najczęściej zapobiegają kosztownym poprawkom na późnych etapach.

Konsekwencją jest to, że nasze szacunki są zakorzenione w realiach domeny, a nie w optymistycznych analogiach do poprzednich projektów. Gdy zakres zawiera niepewności, nazywamy je wprost, zamiast po cichu wchłaniać je w bufor dostarczania.

Złożone systemy nie upraszczają się same — wymaga to celowego upraszczania na każdej warstwie abstrakcji. Decyzje architektoniczne traktujemy jako artefakty komunikacyjne: granica komponentu to stwierdzenie, co zmienia się niezależnie; model danych to stwierdzenie, co system powinien wiedzieć.

W praktyce oznacza to, że opieramy się pokusie sięgania po frameworki rozwiązujące problemy, których jeszcze nie mamy. Gdy dodajemy zależność, dokumentujemy: dlaczego — i ile kosztowałoby jej usunięcie. Celem jest baza kodu, w której kolejny inżynier może zrozumieć intencję ze struktury, a nie tylko z komentarzy.

Interfejsy użytkownika niosą ten sam obowiązek. Dashboard wymagający szkolenia do zrozumienia to dashboard, który zostanie zignorowany w krytycznym momencie. Projektujemy z myślą o operatorze, który czyta te liczby o drugiej w nocy — nie o środowisku demonstracyjnym.

Niewidoczny postęp rodzi niepokój, a niepokój prowadzi do pochopnych decyzji. Dzielimy się pracą w toku — nie dopracowanymi wynikami, lecz działającymi prototypami i roboczymi szkicami, które pozwalają klientowi dawać feedback, zanim inwestycje się utrwalą.

Gdy decyzja techniczna wiąże się z istotnym kompromisem, ujawniamy go wprost, zamiast prezentować gotowy wniosek. Gdy założenie dotyczące zakresu okazuje się błędne, informujemy o tym natychmiast, zamiast po cichu dostosowywać harmonogram dostarczania.

Dotyczy to również negatywnych wniosków. Jeśli zaproponowana przez nas technologia w miarę poznawania projektu okazuje się nieodpowiednia, mówimy to wprost. Koszt wczesnej korekty jest prawie zawsze niższy niż koszt późnej.

Jakość kodu jest konieczna, lecz niewystarczająca. Dobrze przetestowany moduł, który rozwiązuje niewłaściwy problem lub jest dostarczony sześć tygodni za późno, nie stworzył wartości. Niezawodność dostarczania traktujemy jako metrykę jakości pierwszej klasy — na równi z pokryciem testami i benchmarkami wydajności.

Używamy pipeline CI/CD, systemów typów i linterów nie dlatego, że są modne, lecz dlatego że czynią kolejną zmianę tańszą. Piszemy testy na poziomie, na którym najtaniej je utrzymywać i na którym najprawdopodobniej wykryją realne regresje. Profilujemy przed optymalizacją i optymalizujemy przed przepisywaniem.

Gdy zobowiązujemy się do daty dostarczenia, zobowiązujemy się razem z zakresem i założeniami, które tę datę czynią wiarygodną. Jeśli założenia się zmieniają, harmonogram jest otwierany ponownie — i informujemy was o tym natychmiast.

Prototypy przeznaczone do zastąpienia rzadko są zastępowane. Gdy budujemy coś, co będzie działać na produkcji, traktujemy to jako produkcję od pierwszego commita: parytety środowisk, ustrukturyzowane logowanie, granice błędów, graceful degradation przy częściowej awarii.

Dla systemów czasu rzeczywistego oznacza to myślenie o backpressure przed pierwszym połączeniem WebSocket. Dla dashboardów przetwarzających telemetrię w skali — myślenie o modelu danych pod obciążeniem, zanim wyrenderuje się pierwszy wykres. Dla potoków strumieniowych — testowanie przy bitratingach i opóźnieniach odpowiadających rzeczywistym warunkom eksploatacji, a nie demonstracyjnym.

Nie prosimy o sprint porządkowy na końcu projektu. Jego koszt jest zawsze wyższy niż rozproszona uwaga przez cały czas trwania projektu, a wynikowy system jest mniej spójny.

Ukończony projekt nie jest wynikiem — to kamień milowy. Wynikiem jest system, który nadal dostarcza wartość w miarę ewolucji wymagań, zmian skali i przemian samej domeny. Od początku projektujemy z myślą o tej trajektorii: punkty rozszerzeń, udokumentowane uzasadnienia decyzji i przekazanie, które rzeczywiście pozostawia zespół klienta zdolnym do samodzielnego kontynuowania.

Wolimy klientów, którzy traktują nas jako długoterminowego partnera technologicznego, a nie jako dostawcę usług. Nie ze względów komercyjnych, lecz dlatego że praca jest lepsza, gdy rozumiemy kontekst biznesowy wystarczająco głęboko, by kwestionować wymagania, które za dwanaście miesięcy stworzą problemy.

Gdy projekt się kończy, traktujemy zgromadzoną wiedzę jako zasób klienta, a nie nasz. Dokumentacja, diagramy architektury i runbooki są częścią każdego dostarczenia.