Piotr FilipowiczOfertę software house'u warto oceniać nie tylko po cenie i terminie, ale przede wszystkim po siedmiu elementach: założeniach estymacji, dopasowaniu rozwiązania do celu biznesowego, jakości i kryteriach odbioru, modelu współpracy, bezpieczeństwie, własności rozwiązania oraz warunkach wyjścia ze współpracy. Dobra oferta jasno pokazuje również niewiadome, ryzyka i odpowiedzialność obu stron.
Najbardziej niebezpieczna oferta software house'u bardzo często wygląda najlepiej.
Ma konkretną cenę, precyzyjny harmonogram i długą listę funkcji. Sprawia wrażenie, że po stronie dostawcy wszystko zostało już policzone i przemyślane. Zarząd dostaje liczby, procurement może porównać tabelki, a projekt wydaje się przewidywalny.
Problem pojawia się wtedy, gdy ta precyzja nie wynika z dobrego rozpoznania projektu, tylko z założeń, których nikt nie pokazał.
Przed podpisaniem umowy nie oceniamy przecież dokumentu. Oceniamy przyszłą współpracę, sposób podejmowania decyzji i ryzyko zainwestowania często kilkuset tysięcy złotych w rozwiązanie, które ma działać przez lata. Sama liczba roboczogodzin mówi o tym bardzo niewiele.
Dobra oferta nie musi usuwać całej niepewności. W projektach software'owych byłoby to mało wiarygodne. Powinna natomiast pokazać, że dostawca tę niepewność rozumie, potrafi nią zarządzać i nie próbuje przenieść jej po cichu na klienta.
Nie zaczynaj od porównania ceny
Cena jest ważna, natomiast ma sens dopiero wtedy, gdy wiemy, co właściwie zostało wycenione.
Dwie oferty po 600 tysięcy złotych mogą dotyczyć zupełnie różnych zobowiązań. W jednej dostawca uwzględni analizę procesów, testy bezpieczeństwa, monitoring, migrację danych, stabilizację po wdrożeniu i przekazanie wiedzy. W drugiej zobaczymy przede wszystkim implementację funkcji opisanych w briefie.
Jeszcze trudniej porównać ofertę za 400 tysięcy z ofertą za 700 tysięcy, jeżeli nie znamy ich założeń dotyczących jakości, dostępności systemu, odpowiedzialności klienta, integracji i utrzymania.
Dlatego przed oceną kwoty warto sprowadzić wszystkie propozycje do wspólnego mianownika:
- jaki wynik biznesowy ma zostać osiągnięty,
- jaki zakres odpowiedzialności bierze dostawca,
- jakie ryzyka uwzględnił,
- co uznaje za gotowy produkt,
- co pozostaje poza wyceną,
- ile będzie kosztować nie tylko uruchomienie, ale również utrzymanie, zmiana i ewentualne przejęcie rozwiązania.
W przeciwnym razie nie porównujemy ofert. Porównujemy liczby opisujące różne projekty.
01
Czy dostawca rozumie wynik biznesowy, czy tylko listę funkcji?
Pierwszy sygnał jakości pojawia się jeszcze przed sekcją techniczną. Dobra oferta powinna pokazywać, jaki problem ma rozwiązać system i po czym wspólnie poznamy, że inwestycja przyniosła efekt.
Jeżeli dokument zaczyna się od frameworków, liczby ekranów i składu zespołu, ale nie potrafi nazwać celu biznesowego, dostawca najprawdopodobniej wycenił produkcję oprogramowania, a nie odpowiedzialność za rezultat.
Warto sprawdzić, czy oferta odpowiada na pytania:
- Kto będzie korzystał z rozwiązania i w jakim procesie?
- Co dzisiaj ogranicza przychód, tempo operacji albo jakość obsługi?
- Które elementy są niezbędne na pierwsze wdrożenie, a które mogą poczekać?
- Jakie zachowanie użytkownika albo wynik procesu ma się zmienić?
- Jakie decyzje biznesowe stoją za proponowanym zakresem?
To ważne również komercyjnie. Brytyjskie wytyczne dotyczące kontraktowania projektów cyfrowych rekomendują opisanie oczekiwanych rezultatów oraz zasad współpracy zamiast udawania, że na początku można ostatecznie zamknąć cały plan i wszystkie wymagania. Podkreślają też, że wymagania będą rozwijane w trakcie projektu, a funkcjonalność, wymagania niefunkcjonalne i wydajność powinny być traktowane łącznie (Contracting for Agile Guidance Note, GOV.UK).
Nie oznacza to, że zakres może być dowolny. Oznacza, że oferta powinna oddzielać rzeczy rozpoznane od hipotez i pokazywać mechanizm dochodzenia do kolejnych decyzji.
02
Czy założenia i niewiadome są jawne?
Estymacja bez listy założeń jest tylko liczbą.
Na cenę i termin wpływają między innymi jakość obecnych danych, gotowość API innych systemów, dostępność osób decyzyjnych po stronie klienta, wymagania regulacyjne, liczba środowisk, sposób autoryzacji czy rzeczywisty stan zastępowanego rozwiązania. Jeżeli dostawca nie sprawdził tych elementów, nie może ich znać. Może je tylko założyć.
Dojrzała oferta pokazuje:
- na jakich informacjach powstała estymacja,
- które elementy wymagają potwierdzenia,
- jaki margines błędu przyjęto,
- co może zmienić cenę albo harmonogram,
- kiedy i w jaki sposób zostaną zweryfikowane najważniejsze hipotezy,
- kto podejmuje decyzję, gdy założenie okazuje się błędne.
Paradoksalnie oferta zawierająca kilka dobrze opisanych niewiadomych bywa bezpieczniejsza od tej, która na trzydziestu stronach nie przyznaje się do żadnej.
W książce The Software Architect Elevator Gregor Hohpe opisuje decyzje architektoniczne jak opcje. Im większa niepewność, tym większą wartość ma możliwość odroczenia kosztownej decyzji, zmiany kierunku albo ograniczenia inwestycji. Z punktu widzenia kupującego oznacza to, że dobra architektura i dobry model realizacji nie tylko dowożą zakres. Zachowują biznesowi możliwość ruchu.
W ofercie powinno być więc widać, które decyzje trzeba podjąć od razu, które można bezpiecznie odłożyć i ile będzie kosztowała zmiana kierunku.
03
Czy rozwiązanie wynika z kontekstu, czy z domyślnego stosu dostawcy?
Każdy software house ma technologie, zespoły i wzorce, które zna najlepiej. To naturalne i często korzystne. Problem zaczyna się wtedy, gdy narzędzia stają się odpowiedzią jeszcze zanim dobrze zdefiniowano pytanie.
Neal Ford, Mark Richards, Pramod Sadalage i Zhamak Dehghani w Software Architecture: The Hard Parts opisują pułapkę decyzji podejmowanych poza kontekstem. Rozwiązanie może mieć wiele zalet i jednocześnie nie posiadać jednej cechy krytycznej dla konkretnej organizacji. Lista ogólnych plusów nie zastępuje analizy rzeczywistego przypadku.
Dlatego oferta powinna wyjaśniać:
- jakie czynniki biznesowe i techniczne wpłynęły na projekt,
- jakie alternatywy rozważono,
- dlaczego wybrano właśnie ten wariant,
- jakie koszty i ograniczenia świadomie zaakceptowano,
- w jakich warunkach rekomendacja przestanie być właściwa.
Jeżeli dostawca proponuje mikroserwisy, chmurę, konkretny CMS albo platformę low-code, powinien umieć pokazać nie tylko korzyści, ale również koszt operacyjny, zależności i scenariusze, w których ten wybór będzie przeszkadzał.
Brak pokazania kompromisów i konsekwencji jest sygnałem ostrzegawczym. Każda istotna decyzja architektoniczna coś upraszcza i coś komplikuje. Jeżeli oferta pokazuje wyłącznie zalety, prawdopodobnie czytamy materiał sprzedażowy, a nie analizę rozwiązania.
04
Czy jakość została zdefiniowana tak, żeby dało się ją odebrać?
Zdania takie jak „system będzie skalowalny, bezpieczny i wysokowydajny” brzmią dobrze, ale kontraktowo znaczą niewiele.
Skalowalny do jakiego obciążenia? Bezpieczny według jakiego procesu i standardu? Jaki czas odpowiedzi jest akceptowalny? Jak szybko system ma wrócić po awarii? Ile błędów krytycznych może pozostać przed uruchomieniem?
Autorzy Building Evolutionary Architectures proponują fitness functions, czyli obiektywne miary chroniące ważne cechy architektury w miarę jej rozwoju. Nie każda taka miara musi być automatycznym testem. Może nią być próba odtworzenia backupu, test wydajnościowy, kontrola zależności, przegląd bezpieczeństwa albo procedura wymagana regulacyjnie. Kluczowe jest to, że jakość przestaje być deklaracją i staje się czymś, co można sprawdzić.
W ofercie szukaj zatem konkretnych progów i sposobów weryfikacji:
- Definition of Done i kryteriów odbioru,
- wymagań dotyczących wydajności i dostępności,
- sposobu testowania oraz odpowiedzialności za naprawę błędów,
- kryteriów bezpieczeństwa,
- monitoringu, alertów i logów,
- procedury backupu i odtworzenia,
- dokumentacji technicznej i operacyjnej,
- warunków uruchomienia produkcyjnego.
Wytyczne GOV.UK mówią wprost o zdefiniowaniu standardów jakości, Definition of Ready, Definition of Done oraz akceptowalnego poziomu błędów po wdrożeniu. Rekomendują również wiązanie płatności z rezultatami lub wydaniami kodu, a nie z samym faktem wykonania określonej liczby sprintów (Contracting for Agile Guidance Note, GOV.UK).
Jeżeli nie da się opisać, jak zostanie sprawdzone słowo „gotowe”, bardzo trudno będzie później rozstrzygnąć, czy dostawca rzeczywiście dowiózł projekt.
05
Czy model współpracy pokazuje odpowiedzialność obu stron?
Projekt software'owy nie jest usługą kurierską. Klient nie przekazuje paczki wymagań, żeby po sześciu miesiącach odebrać gotowy system.
Dostawca będzie potrzebował decyzji produktowych, dostępu do użytkowników, wiedzy domenowej, danych, środowisk i osób odpowiedzialnych za integracje. Jeżeli oferta tego nie nazywa, harmonogram może opierać się na założeniu, że wszystko będzie dostępne natychmiast.
Sprawdź, czy dokument opisuje:
- właściciela produktu i osoby decyzyjne po stronie klienta,
- skład zespołu dostawcy oraz realną dostępność kluczowych osób,
- częstotliwość prezentowania działającego rozwiązania,
- proces priorytetyzacji i akceptacji zmian,
- czasy potrzebne klientowi na decyzje i odbiory,
- eskalację problemów,
- sposób raportowania budżetu, ryzyk, jakości i postępu,
- zasady zmiany składu zespołu.
Warto również dowiedzieć się, kto konkretnie przygotował ofertę i kto będzie realizował projekt. Prezentacja senior architekta podczas sprzedaży nie gwarantuje jego udziału po podpisaniu umowy.
Dobra oferta nie przerzuca całej odpowiedzialności na klienta, ale też nie udaje, że klient nie ma wpływu na powodzenie przedsięwzięcia. Pokazuje zależności i ustala rytm współpracy, zanim pojawi się pierwszy konflikt.
06
Czy bezpieczeństwo jest częścią produktu, a nie dopiskiem do infrastruktury?
Certyfikat dostawcy może być wartościowy, natomiast nie odpowiada jeszcze na pytanie, jak będzie chroniony konkretny produkt.
CISA zwraca uwagę na różnicę między bezpieczeństwem przedsiębiorstwa dostawcy a bezpieczeństwem wytwarzanego oprogramowania. Zaleca, aby kupujący sprawdzali podejście producenta do bezpieczeństwa przed zakupem, wpisywali odpowiednie wymagania do kontraktu i oceniali wyniki również po zawarciu umowy (Secure by Demand Guide, CISA). NIST SSDF wskazuje między innymi na dokumentowanie wymagań bezpieczeństwa, śledzenie ryzyk i decyzji projektowych oraz pochodzenia komponentów użytych w wydaniu (Secure Software Development Framework, NIST).
W praktyce oferta powinna wyjaśniać:
- jak bezpieczeństwo będzie uwzględniane w analizie i projektowaniu,
- kto odpowiada za aktualizacje zależności i usuwanie podatności,
- czy powstanie zestawienie użytych komponentów i licencji,
- jak będą przechowywane sekrety i dane wrażliwe,
- jakie testy bezpieczeństwa zostaną wykonane,
- jak wygląda obsługa incydentu i zgłoszonej podatności,
- co obejmuje gwarancja, a co późniejsze utrzymanie.
Sformułowanie „stosujemy best practices” nie jest odpowiedzią. Poproś o proces, dowody i odpowiedzialność.
07
Czy od pierwszego dnia wiadomo, jak zakończyć współpracę?
To pytanie brzmi mało romantycznie, szczególnie przed rozpoczęciem projektu. Jest jednak jednym z najlepszych testów dojrzałości oferty.
Klient powinien wiedzieć:
- kto jest właścicielem kodu, dokumentacji, konfiguracji i danych,
- gdzie znajdują się repozytoria oraz konta chmurowe,
- czy ma bieżący dostęp do kodu i artefaktów projektu,
- w jakim formacie może wyeksportować dane,
- jak wygląda przekazanie wiedzy innemu zespołowi,
- które elementy są zależne od własnościowych narzędzi dostawcy,
- ile może kosztować migracja albo przejęcie utrzymania,
- jakie obowiązki ma dostawca po wypowiedzeniu lub wygaśnięciu umowy.
Koszt wyjścia jest częścią całkowitego kosztu rozwiązania, nawet jeżeli dziś nie planujemy zmieniać partnera. Brytyjskie zasady otwartych standardów rekomendują szacowanie kosztów wyjścia i migracji już na początku projektu (Open Standards principles, GOV.UK). Z kolei Digital, Data and Technology Playbook wskazuje, że umowa powinna od początku zawierać jasne zasady zakończenia i przejścia, w tym zwrot danych i informacji, transfer wiedzy, odpowiedzialności, kamienie milowe oraz kryteria jakości (Digital, Data and Technology Playbook, GOV.UK).
Nie oznacza to, że zawsze trzeba za wszelką cenę unikać zależności od dostawcy albo technologii. Czasem managed service lub wyspecjalizowana platforma daje dużą przewagę. Decyzja powinna być jednak świadoma, a koszt zmiany możliwy do oszacowania.