Zatrudniłeś software house. Kto pilnuje Twoich interesów?

Software house ma dobrych programistów i uczciwe intencje — w większości przypadków to po prostu prawda. A mimo to projekty zamawiane przez firmy bez własnego działu IT regularnie zbaczają z kursu. Nie dlatego, że ktoś oszukuje. Dlatego, że wszystkie techniczne decyzje w projekcie zapadają po jednej stronie stołu — a po Twojej stronie nikt nawet nie wie, że właśnie zapadły.

Dobra wiadomość: do pilnowania własnych interesów nie potrzebujesz studiów informatycznych. Większość przewagi, jaką daje osoba techniczna w tych rozmowach, sprowadza się do kilku pytań — i umiejętności czytania odpowiedzi. Oto trzy z nich, z historii, które widziałem z bliska.

Estymacja nie jest pomiarem. Jest ofertą

Klient dostał wycenę rozbudowy systemu: 340 godzin. Taka liczba wygląda jak wynik pomiaru — konkretna, rozbita na pozycje, zsumowana w arkuszu. Ale estymacja niczego nie mierzy. Jest ciągiem decyzji o tym, jak coś zostanie zrobione, przebranym za arytmetykę. I każda z tych decyzji, jeśli nikt o nią nie pyta, naturalnie wypada bezpiecznie dla tego, kto ją podejmuje.

W tamtej wycenie blisko połowa godzin szła na przepisanie modułów, które działały i nikomu nie przeszkadzały. Z perspektywy wykonawcy ruch zrozumiały: za kod, który sam napisał, łatwiej mu ręczyć. Tylko że za ten komfort płaci klient — który nie wiedział, że ma wybór.

Pytanie, które tę strukturę odsłania: „co się stanie, jeśli tej pozycji nie zrobimy?". Odpowiedzi od razu dzielą wycenę na dwie części. Jedne pozycje bronią się konkretem: „przy obecnym tempie przyrostu danych system przestanie wyrabiać w pół roku". Inne bronią się ogólnikiem: „tak będzie porządniej". Te drugie nie są złe — są opcjonalne. A opcje się wybiera, nie kupuje w pakiecie.

Po takiej rozmowie z 340 godzin zostało 190. I co ciekawe, współpraca na tym zyskała — rozmowa o zakresie jest dla obu stron zdrowsza niż przeciąganie liny o stawkę.

Kupujesz kod, nie pokaz

Comiesięczne demo robiło świetne wrażenie i nie było w tym żadnej manipulacji — pokazywane funkcje naprawdę działały. Rzecz w tym, że demo pokazuje produkt, a Ty kupujesz coś innego: kod, który ktoś będzie rozwijał przez lata. Funkcja na ekranie to pokwitowanie. Aktywem jest to, czego na ekranie nie widać. Trochę jak przy kupnie mieszkania: na prezentacji oglądasz salon, ale o koszcie życia w nim zdecydują instalacje w ścianach.

W tym projekcie pierwszy przegląd repozytorium pokazał brak testów, brak migracji bazy danych i produkcyjne hasła trzymane w kodzie. Żadna z tych rzeczy nie psuje demo. Każda decyduje o tym, czy zmiana w drugim roku życia produktu zajmie dzień, czy tydzień — i czy zrobi ją dowolny programista, czy tylko ten jeden, który pamięta, gdzie co leży.

Dlaczego tak się dzieje? Nie z lenistwa. Zespół rozliczany z tego, co widać, inwestuje w to, co widać — to nie cynizm, to racjonalna odpowiedź na sposób, w jaki klient odbiera pracę. Dlatego działa rzecz pozornie drobna: ustalona na starcie zasada, że raz na sprint ktoś po stronie klienta zagląda do kodu. Nie po to, żeby przyłapywać. Po to, żeby jakość wewnętrzna przestała być niewidzialna — wtedy rachunek inwestycji zespołu zmienia się sam.

A jeśli nie masz komu zajrzeć, zostaje pytanie, które możesz zadać bez czytania kodu: „gdyby ten projekt przejmował jutro inny zespół, ile zajęłoby mu wprowadzenie pierwszej bezpiecznej zmiany?". To jest stan kodu przetłumaczony na język ryzyka.

Nie pytaj o przyszłość. Pytaj o przeszłość

„Potrzebujemy jeszcze trzech sprintów" — najtrudniejszy moment projektu. Bez zaplecza technicznego masz pozornie dwa ruchy: uwierzyć na słowo albo się postawić. Oba w ciemno. Pierwszy uczy wykonawcę, że terminy są miękkie; drugi psuje współpracę, która może być zupełnie zdrowa.

Trzeci ruch opiera się na jednej zasadzie: deklaracje o przyszłości są nieweryfikowalne, więc pytaj o przeszłość. „Co okazało się trudniejsze, niż zakładała wycena — i dlaczego?". „Które z tych niespodzianek są już za nami, a które mogą wrócić?". „Co z pozostałego zakresu można odłożyć, żeby zdążyć z resztą?".

Tu nie chodzi nawet o treść odpowiedzi, tylko o jej fakturę. Zespół z uczciwym opóźnieniem odpowiada konkretami — często z ulgą, bo wreszcie ktoś pyta o coś, na co ma dobrą odpowiedź. Zespół, który dryfuje, odpowiada mgłą: „złożoność", „integracje", „dług technologiczny". Konkret albo mgła — to rozróżnienie słychać bez technicznego wykształcenia.

Dobrze napisany dokument już o niczym nie świadczy

Przez lata w zlecaniu pracy działała cicha zasada: jeśli dokument jest staranny, to potrzeba za nim jest przemyślana. Mętny trzyzdaniowy mail prowokował telefon i godzinę dopytywania; porządna specyfikacja — nie, bo po co, skoro widać, że ktoś odrobił lekcję. Ta heurystyka właśnie przestała działać.

Scenariusz, który widuję coraz częściej: właściciel firmy opisuje problem czatowi AI i dostaje dokument jak od analityka — user stories, kryteria akceptacji, podział na etapy. Wysyła. Software house wycenia i buduje dokładnie to, co napisano. Problem w tym, że tego dokumentu nikt nie przemyślał: AI wypełniło luki w opisie prawdopodobnymi domysłami, a domysł i faktyczna potrzeba wyglądają na papierze identycznie. Trzy miesiące później istnieje solidnie wykonany moduł, który rozwiązuje problem wymyślony przez model językowy.

Wniosek nie brzmi „nie używaj AI" — sam używam jej codziennie. Wniosek brzmi: skoro porządną formę można dziś mieć za darmo, to po formie nie poznasz już, czy ktoś dokument przemyślał. Ciężar weryfikacji wraca tam, skąd przyszedł — do rozmowy. Przy każdym wymaganiu ktoś musi umieć zapytać: „skąd się to wzięło?" — i odróżnić odpowiedź „z naszego procesu reklamacji" od „tak wyszło w generowaniu".

Po co Ci w takim razie ktoś techniczny

Wszystkie pytania z tego tekstu możesz zadać sam — i namawiam, żebyś zadawał. Osoba techniczna po Twojej stronie stołu robi różnicę w tym, co dzieje się po odpowiedzi: rozumie ją, widzi, kiedy konkret jest pozorny, wie, które z trzech wyjaśnień otwiera furtkę na kolejne miesiące dryfu.

W praktyce to nie jest etat. Kilka godzin w tygodniu: udział w planowaniu, przegląd kodu raz na sprint, obecność przy decyzjach architektonicznych — i tłumaczenie w obie strony, potrzeb biznesu na język techniczny i konsekwencji technicznych na język biznesu. Wbrew intuicji dobre software house’y takich klientów lubią: pytania o zakres mają adresata, decyzje zapadają w dni, a nie tygodnie, a nieporozumienia kończą się rozmową zamiast aneksem.

Koszt to rząd wielkości jednej dniówki software house’u miesięcznie. Zatrudnienie kogoś do komunikacji to najtańsze ubezpieczenie projektu, jakie można kupić — z tą miłą różnicą, że wypłaca się również wtedy, gdy nic złego się nie dzieje.