Jak wybrać software house: pytania, które warto zadać

Polski rynek outsourcingu i software house’ów jest jednym z najbardziej konkurencyjnych w Europie, co ma swoją dobrą stronę — szeroki wybór — i złą: trudno odróżnić dostawców po samej stronie internetowej, bo prawie każdy pokazuje podobne portfolio i podobne obietnice. “Jak wybrać software house” to pytanie, które zwykle pojawia się po tym, jak ktoś już usłyszał — albo przeżył — projekt, w którym terminy się podwoiły, komunikacja urwała się na tygodnie, albo dostawca zniknął tuż po podpisaniu umowy. Ładne portfolio żadnemu z tych problemów nie zapobiega. Właściwe pytania, zadane przed podpisaniem, owszem.

Zapytajcie, kto naprawdę pisze kod

Wiele software house’ów sprzedaje z udziałem seniorów na rozmowie handlowej, a projekt przydziela temu, kto akurat ma wolny czas — często osobom z mniejszym doświadczeniem w konkretnym typie problemu, jaki macie. To niekoniecznie źle — ale warto wiedzieć o tym wcześniej, a nie odkryć w połowie projektu. Zapytajcie wprost: kto będzie pisał kod, i czy to ta sama osoba, z którą teraz rozmawiacie?

Mniejsze zespoły zwykle odpowiadają na to pytanie lepiej, z powodu strukturalnego: mniej osób oznacza mniej przekazań, a mniej przekazań oznacza mniej okazji, żeby projekt oddalił się od tego, o co faktycznie prosiliście.

Zapytajcie, jak często zobaczycie działający produkt

Poważny software house nie pokazuje prezentacji w połowie projektu — pokazuje prawdziwe, klikalne ekrany co kilka tygodni. To nie jest tylko gest przejrzystości: to mechanizm, który pozwala poprawić błędne założenie w drugim tygodniu, a nie w dziesiątym, kiedy zmiana kosztuje dużo więcej.

Jeśli odpowiedź na pytanie “kiedy zobaczymy coś działającego” brzmi “na końcu” — to sygnał, który warto potraktować poważnie, a nie jako szczegół organizacyjny.

Zapytajcie, co się dzieje z kodem po wdrożeniu

Wycena, która nie wspomina o kodzie źródłowym, dostępie do repozytorium i dokumentacji, nie jest kompletną wyceną — brakuje w niej części, która decyduje o tym, co dzieje się po wdrożeniu. Oprogramowanie, którego nie jesteście właścicielem, to w praktyce abonament w przebraniu: każda przyszła zmiana musi przejść przez tego, kto trzyma kod, po stawce, jaką ta strona ustali, gdy nie będziecie już mieli alternatywy.

Zapytajcie wprost: czy otrzymacie pełny kod źródłowy, dostęp do repozytorium i dokumentację — i na jakim etapie projektu, a nie tylko na końcu?

Zapytajcie, jak traktowane są integracje

Jeśli projekt ma rozmawiać z systemami, których już używacie — ERP, CRM, platforma e-commerce — zapytajcie, jak dostawca ocenia tę część pracy, zanim poda liczbę. Dostawca, który wycenia integrację bez sprawdzenia, co faktycznie udostępnia drugi system, zgaduje, a nie szacuje.

Pytanie	Co pokazuje
Kto naprawdę będzie pisał kod	Realną wielkość zespołu, ciągłość
Jak często zobaczymy działający produkt	Ryzyko późnych niespodzianek
Czy otrzymamy kod źródłowy i dokumentację	Realną własność oprogramowania
Jak wyceniacie integrację z naszymi systemami	Rzetelność procesu analizy
Co się dzieje, gdy zakres zmienia się w trakcie	Uczciwość modelu wyceny

Nie ufajcie liczbie podanej zbyt wcześnie

Cena podana, zanim zakres projektu został spisany — ekrany, role, przepływy danych, co jest w środku, a co wyraźnie poza — nie jest wyceną. To placeholder czekający na rozmowę, która uczyni go realnym. Poważny software house proponuje najpierw etap analizy, nawet krótki, a dopiero potem liczbę powiązaną z tym, co faktycznie zrozumiał o projekcie.

To dotyczy też samego modelu wyceny: stała cena za etap ma sens dla projektu z jasno określonym punktem docelowym, a miesięczna pojemność zespołu ma sens dla produktu, który będzie się dalej rozwijał po wdrożeniu. Żaden z nich nie jest z natury tańszy — to odpowiedzi na różne pytania, a pomylenie ich to jeden z najczęstszych sposobów, w jaki projekt “na zamówienie” zamienia się w fakturowanie bez końca.

Zapytajcie byłych klientów, co się działo w trudnym momencie

Referencje mają znaczenie, ale tylko jeśli pada właściwe pytanie. “Czy byliście zadowoleni” niemal zawsze daje grzeczne “tak”. “Co się stało, gdy w połowie projektu coś poszło nie tak” daje odpowiedź, z której naprawdę można coś wyciągnąć — bo każdy projekt prędzej czy później napotyka niespodziankę: zmieniający się wymóg, integrację trudniejszą niż zakładano, termin, który się przesuwa. To, co odróżnia poważnego dostawcę, to nie brak takich momentów, tylko sposób, w jaki są komunikowane, gdy się pojawiają — od razu, z konkretną propozycją, czy dopiero wtedy, gdy jest już za późno, żeby coś zmienić.

Nie ufajcie też wycenie, która wygląda zbyt gładko

Prawdziwy projekt, z integracjami do systemów jeszcze nie do końca poznanych, rzadko daje na pierwszym spotkaniu idealnie okrągłą liczbę. Wycena, która przychodzi już podzielona na konkretne pozycje, spójna z tym, co było omawiane, z jawnie zaznaczonymi obszarami niepewności tam, gdzie faktycznie istnieją, jest zwykle lepszym sygnałem niż jedna sucha liczba podana podczas tej samej rozmowy, w której projekt został opisany po raz pierwszy.

Jak my pracujemy, dla porównania

Celowo utrzymujemy małe zespoły, dostarczamy działające oprogramowanie co kilka tygodni, i przekazujemy kod źródłowy, dostęp do repozytorium i dokumentację na każdym etapie projektu, nie tylko na końcu. Nie mówimy tego, żeby się wyróżnić słowami — to kryteria, którymi sami kierowalibyśmy się jako zamawiający, oceniając dostawcę.

Od czego zacząć

Jeśli porównujecie kilku dostawców, zadajcie każdemu te same pytania z tego artykułu i porównajcie odpowiedzi, nie tylko wyceny. Konkretne przykłady naszego sposobu pracy znajdziecie na stronie realizacje, a więcej o naszym podejściu do oprogramowania na zamówienie — na stronie usługi.

Portfolio pokazuje, co zostało dostarczone. Nie pokazuje, jak do tego doszło — a to, bardziej niż wynik końcowy, decyduje o tym, czy wasz projekt się uda.

Jeśli projekt dotyka też integracji z KSeF, artykuł integracja z KSeF: co to naprawdę oznacza rozwija tę część osobno. Poza tym krótka rozmowa to najszybszy sposób, żeby sprawdzić, czy jesteśmy właściwym dostawcą dla waszego projektu.