Wybór dostawcy oprogramowania IT na początku wydaje się prosty: dostajesz kilka ofert, patrzysz na ceny i referencje, wybierasz firmę, która wydaje się wiarygodna. Problemy jednak pojawiają się później — zakres projektu zaczyna rosnąć, terminy się przesuwają, a Ty nie masz pewności, czy inwestujesz w realny postęp, czy tylko w kolejne „statusy” na papierze. Największy koszt błędnej decyzji to nie zawsze wysoka stawka. Dużo boleśniejsze okazują się miesiące utraconego czasu, rozmyty budżet oraz brak kontroli nad produktem. Dzieje się tak, gdy zamiast realnego procesu, kupujesz dobrze przygotowaną prezentację — nie sprawdzając wcześniej sposobu pracy zespołu. Poniżej znajdziesz prosty przewodnik: od określenia własnych potrzeb, przez analizę oferty, aż po konkretne pytania i sygnały ostrzegawcze, na które warto zwrócić uwagę jeszcze przed rozpoczęciem współpracy.
Artykuł sponsorowany
Zanim porównasz oferty: ustal, czego naprawdę potrzebujesz
Najczęstszy błąd zaczyna się przed pierwszą rozmową z software house’em. Firma zbiera oferty, nie mając jasnej odpowiedzi na pytanie: jaki problem ma rozwiązać ten projekt i po czym poznamy sukces.
Zanim poprosisz o wycenę, zapisz cztery rzeczy:
- Jaki wynik biznesowy ma powstać. Nie „nowa aplikacja” albo „modernizacja systemu”, tylko konkret: skrócenie czasu przygotowania oferty, spadek liczby błędów w zamówieniach, uruchomienie nowego kanału sprzedaży, odzyskanie kontroli nad produktem, który dziś stoi.
- Co już macie. Legacy system, Excel i skrypty, gotowe narzędzie z półki, niedokończony MVP: to zmienia zarówno zakres, jak i profil dostawcy.
- Jaki model współpracy ma sens. Fixed Price działa przy jasnym, zamkniętym zakresie. Time & Materials lepiej sprawdza się wtedy, gdy produkt będzie się uczył w trakcie. Dedicated team ma sens, gdy potrzebujesz ciągłej pojemności rozwojowej, a nie jednorazowego wdrożenia.
- Kto po Waszej stronie podejmuje decyzje. Bez właściciela biznesowego projekt szybko zamienia się w kolejkę życzeń. Dostawca może dowozić zadania, ale nie zastąpi osoby, która mówi: to robimy, tego nie, a sukces wygląda tak.
Jak czytać ofertę, żeby nie kupić prezentacji
Oferta software house’u często wygląda profesjonalnie: ładne slajdy, znane technologie, obietnica „doświadczonego zespołu” i „elastycznego procesu”. To za mało, żeby podjąć decyzję. Patrz na 3 obszary.
Stawka godzinowa to nie koszt projektu. Niska stawka przy słabej jakości, dużej rotacji albo braku automatyzacji zwykle wychodzi drożej. Pytanie nie brzmi „ile kosztuje godzina”, tylko „ile godzin i jakiej jakości pracy potrzeba, żeby dowieźć wynik”. Dopytaj, co wchodzi w stawkę, kto realnie będzie w zespole i jak dostawca ogranicza marnotrawstwo: testami, code review, CI/CD, jasnym Definition of Done.
Skład zespołu ma znaczenie większe niż logo firmy. Sprawdź, czy ludzie z oferty to stali pracownicy, czy mają dopiero zostać zrekrutowani. Poproś o rozmowę z Tech Leadem albo Product Managerem, który miałby prowadzić projekt. Kupujesz kompetencje konkretnych osób, nie folder sprzedażowy.
Pierwsze 30–60 dni powinny być przewidywalne. Firma, która regularnie startuje projekty, umie opowiedzieć, jak wyglądał onboarding w podobnym case’ie: co zbierają na początku, kiedy powstaje repozytorium, kiedy pojawia się pierwsze demo i ile zaangażowania potrzebują od klienta. Chaos na starcie rzadko znika z czasem. Zwykle eskaluje.
Pytania, które oddzielają partnera od sprzedawcy
Na rozmowie nie oceniaj, czy dostawca „brzmi profesjonalnie”. Sprawdź, czy potrafi zejść z poziomu z deklaracji do faktów. Te pytania zwykle wystarczą, żeby zobaczyć różnicę.
O wynik i zakres
- Po czym poznamy po 6–8 tygodniach, że współpraca idzie w dobrą stronę?
- Co musicie wiedzieć o naszym biznesie, zanim zaczniecie kodować?
- Jak zarządzacie zmianą zakresu, gdy w trakcie projektu pojawia się nowa potrzeba?
O zespół i sposób pracy
- Kto konkretnie będzie w zespole i czy mogę z nimi porozmawiać przed decyzją?
- Ilu ludzi to stali pracownicy, a ilu będzie rekrutowanych pod ten projekt?
- Jak wygląda Wasze Definition of Done i co blokuje wdrożenie na produkcję?
O ryzyko i kontrolę
- Opowiedzcie o projekcie, w którym coś poszło źle. Kiedy powiedzieliście o tym klientowi i co zrobiliście?
- Kto będzie właścicielem kodu źródłowego i dokumentacji?
- Jak wygląda przekazanie projektu, jeśli kiedyś zechcemy zmienić dostawcę?
Mocna odpowiedź jest konkretna: zawiera przykład, datę albo etap, rolę decyzyjną i skutek. Słaba odpowiedź broni się hasłami: „dbamy o jakość”, „jesteśmy elastyczni”, „dobierzemy proces po kick-offie”. Jeśli słyszysz głównie to drugie, nie masz jeszcze partnera.
Warto też sprawdzić, czy firma potrafi mówić o produkcie, a nie tylko o technologii. Dobry dostawca oprogramowania pomaga zdecydować, co budować, a czego nie, bo każda zbędna funkcja kosztuje nie tylko napisanie, ale też utrzymanie. Tak pracują zespoły product development, w tym m.in. Pragmatic Coders, które od lat łączą inżynierię z decyzjami biznesowymi zamiast dokładać kod „na zapas”.
Czerwone flagi przed podpisaniem umowy
Nie każda wątpliwość dyskwalifikuje dostawcę. Są jednak sygnały, przy których lepiej zwolnić albo wyjść z procesu.
Opór przed rozmową z osobą techniczną. Jeśli do końca procesu rozmawiasz wyłącznie ze sprzedażą, nie wiesz, kto będzie dowoził projekt. Poproś o Tech Leada. Brak zgody albo wieczne przekładanie takiej rozmowy to poważny sygnał.
Brak przykładu z podobnego typu projektu. Nie chodzi o identyczną branżę za wszelką cenę. Chodzi o podobny rodzaj problemu: budowa MVP, rozwój istniejącego produktu, integracje, ratowanie niedowożonego systemu. Jeśli dostawca nie potrafi pokazać analogii, uczysz go na własnym budżecie.
Oferta bez założeń i ryzyk. Profesjonalna wycena mówi nie tylko „ile”, ale też „przy jakich założeniach”. Brak listy zależności po stronie klienta, brak ryzyk i brak warunków zmiany zakresu zwykle oznacza, że dopłaty pojawią się później, w najmniej wygodnym momencie.
Niejasna własność kodu i dostępów. Zanim podpiszesz umowę, ustal: kto jest właścicielem kodu, gdzie leży repozytorium, kto ma dostępy do środowisk i jak wygląda exit. Vendor lock-in rzadko zaczyna się od złej woli. Zaczyna się od braku zapisanych zasad.
Sukces zdefiniowany jako „dowieziemy scope”. Scope to lista zadań. Sukces to zmiana w biznesie albo w produkcie, którą da się zauważyć. Jeśli dostawca nie chce rozmawiać o metryce wyniku, łatwo skończysz z działającym systemem, który nie rozwiązuje problemu, za który zapłaciłeś.
Decyzja, która chroni budżet
Wybór dostawcy oprogramowania IT to nie konkurs na najładniejszą ofertę i najniższą stawkę. To decyzja o tym, kto przez kolejne miesiące będzie współtworzył (albo obciążał) Twój produkt.
Zanim podpiszesz umowę, upewnij się, że:
- potrafisz nazwać wynik biznesowy projektu,
- wiesz, kto po Waszej stronie podejmuje decyzje,
- znasz realny skład zespołu po stronie dostawcy,
- rozumiesz model rozliczeń i zasady zmiany zakresu,
- masz jasność co do jakości, własności kodu i pierwszych tygodni współpracy.
