Jak wybrać software house: 7 pytań i wymijające odpowiedzi

Jak wybrać software house — rozstrzyga nie portfolio i nie liczba opinii, tylko sposób, w jaki wykonawca odpowiada na pytania o sytuacje, w których coś idzie nie tak. Poniżej jest siedem takich pytań do zadania na pierwszej rozmowie, a przy każdym opis, jak brzmi odpowiedź wymijająca. GESEL.IO sam jest software housem i te pytania dotyczą nas dokładnie tak samo jak każdej innej firmy — zadaj je również nam.

Jak wybrać software house, skoro lista „portfolio, opinie, komunikacja” niczego nie rozstrzyga

Kryteria powtarzane w poradnikach nie różnicują wykonawców, bo każdy odpowie na nie tak samo. Software house to firma, która na zlecenie projektuje, buduje i utrzymuje oprogramowanie — i praktycznie każda pokaże portfolio, powie, że pracuje w sprintach dwutygodniowych, i wymieni typowy skład zespołu: kierownik projektu, analityk, projektant UX/UI, developerzy i tester (QA). Te odpowiedzi są prawdziwe i bezużyteczne przy porównaniu.

Różnicuje tylko takie pytanie, na które szczera odpowiedź kosztuje wykonawcę: ogranicza jego swobodę, obniża koszt Twojego wyjścia albo przenosi na Ciebie kontrolę nad czymś, co dotąd trzymał u siebie. Siedem pytań poniżej ma dokładnie taką konstrukcję. Zadaj je na piśmie wszystkim zapytanym firmom w tym samym brzmieniu — dopiero zestawienie odpowiedzi obok siebie coś pokazuje. Same pytania nie zastąpią opisu projektu, więc zakres, role i systemy do integracji zbierz osobno; jak to zrobić, pokazujemy w tekście o tym, jak napisać brief dla software house.

Pytanie 1: kto będzie właścicielem repozytorium w trakcie projektu i po nim

Repozytorium powinno od pierwszego dnia należeć do Twojej organizacji, a wykonawca ma w nim dostać uprawnienia — nie odwrotnie. W praktyce oznacza to konto organizacji w GitHubie, GitLabie albo Bitbuckecie założone na Twoją firmę i Twoją domenę, rolę właściciela po Twojej stronie i imienne konta zespołu wykonawcy, które da się odebrać jednym kliknięciem.

Ten sam test zastosuj do reszty infrastruktury: domena i DNS, hosting albo konto chmurowe, konto Google Play Console i Apple Developer, klucze podpisujące aplikację, konta usług zewnętrznych i bramek płatności. Właścicielem konta i płatnikiem faktury powinieneś być Ty.

Odpowiedzią wymijającą jest też samo „oczywiście, kod jest Wasz” — bez wskazania, na czyim koncie repozytorium leży dziś i kto ma w nim rolę właściciela. Własność repozytorium to nie to samo co prawa do kodu: umowa o przeniesienie autorskich praw majątkowych wymaga formy pisemnej pod rygorem nieważności (art. 53 ustawy o prawie autorskim i prawach pokrewnych), a resztę rozbieramy w tekście o tym, komu przysługują prawa autorskie do kodu. Ten materiał ma charakter informacyjny i nie jest poradą prawną.

Pytanie 2: czy osoby z prezentacji będą realnie w projekcie

Konkretna odpowiedź to imienny skład zespołu w załączniku do umowy, z rolą i deklarowanym zaangażowaniem każdej osoby. Do tego zapis, że zmiana osoby kluczowej wymaga uprzedzenia i wskazania zastępstwa o porównywalnym doświadczeniu. Bez tego kupujesz nazwisko z prezentacji, a dostajesz dowolną osobę dostępną w dniu startu.

Sprawdzisz to trzema ruchami. Poproś o rozmowę z osobą, która ma prowadzić projekt, a nie z handlowcem. Zapytaj, w ilu projektach ta osoba pracuje równolegle i jaka część jej czasu przypada na Twój. Poproś, żeby to ona poprowadziła spotkanie startowe i przygotowała pierwszą estymatę — ktoś, kto naprawdę będzie w projekcie, zadaje pytania o Twój proces, a nie o budżet.

Odpowiedzi wymijające brzmią tak: „mamy zespół kilkudziesięciu osób i przydzielimy najlepszych dostępnych”, „gwarantujemy odpowiednie doświadczenie”, „skład ustalimy, gdy poznamy termin startu”.

Pytanie 3: czy da się zadzwonić do klienta z portfolio

Weryfikowalne portfolio to takie, w którym wykonawca wskaże projekt zbliżony skalą do Twojego, poda swoją rolę w nim i umówi Cię na rozmowę z osobą, która ten projekt odbierała po stronie klienta. Zrzuty ekranu i logotypy nie są dowodem na nic.

Referenta zapytaj o cztery rzeczy:

• czy terminy się przesuwały i w którym momencie o tym usłyszał,
• kto prowadził projekt i czy ta osoba zmieniała się w trakcie,
• co poszło źle i w jaki sposób wykonawca to naprawił,
• kto utrzymuje system po wdrożeniu i na jakich zasadach.

Zapytaj też wprost, jaką część wdrożenia firma wykonała. Praca jako podwykonawca fragmentu cudzego projektu bywa prezentowana jako realizacja własna, a to zupełnie inna odpowiedzialność. Odpowiedź wymijająca to „NDA nam nie pozwala” podane przy każdej realizacji albo „klienci nie życzą sobie kontaktu”: umowa o poufności bywa prawdziwą przeszkodą przy pojedynczym wdrożeniu, ale firma pracująca od lat ma zwykle kogoś, kto zgodzi się na rozmowę. Jeśli równolegle szukasz wykonawcy widoczności w wyszukiwarce, to osobna intencja i inny zestaw pytań — zebraliśmy je w tekście o tym, jak zweryfikować agencję SEO.

Pytanie 4: jak wygląda przekazanie projektu, gdyby współpraca skończyła się wcześniej

Konkretna odpowiedź to exit plan zapisany w umowie: okres wypowiedzenia, zamknięta lista rzeczy przekazywanych i płatne wsparcie dla zespołu przejmującego przez określony czas po zakończeniu. Dokumentacja odbierana od wykonawcy obejmuje kod źródłowy, specyfikacje oraz dokumentację użytkownika i deweloperską — a poza nią komplet dostępów, dane produkcyjne w formacie do importu, instrukcję uruchomienia środowiska od zera i wykaz zależności wraz z ich licencjami.

Uzupełniające pytanie brzmi: czy w ciągu ostatnich dwóch lat przejmowaliście projekt po innej firmie i co było wtedy największym problemem. Odpowiedź pokazuje, czy wykonawca traktuje przekazanie jako czynność techniczną z listą kroków, czy jako temat, o którym woli nie rozmawiać.

Pytanie 5: co dokładnie obejmuje gwarancja i kto utrzymuje system po wdrożeniu

Gwarancja bez definicji błędu jest deklaracją, a nie zobowiązaniem. Poproś o cztery rozstrzygnięcia na piśmie: co jest błędem, a co zmianą zakresu; jaki jest czas reakcji, a jaki czas naprawy dla każdej kategorii zgłoszenia; w jakich godzinach i jakim kanałem przyjmowane są zgłoszenia; co unieważnia gwarancję, na przykład zmiany w kodzie wprowadzone przez inny podmiot.

Osobno zapytaj o utrzymanie po okresie gwarancji: hosting, monitoring, aktualizacje zależności i wymagań sklepów mobilnych, poprawki bezpieczeństwa. To pozycja, która najczęściej znika z pierwszej oferty i wraca jako koszt rok później — z czego naprawdę składa się kwota wdrożenia, rozbieramy w tekście o tym, ile kosztuje aplikacja mobilna.

Wymijająco brzmi „gwarancja 12 miesięcy” bez definicji błędu, „jesteśmy zawsze dostępni dla naszych klientów” oraz „warunki wsparcia doprecyzujemy po wdrożeniu”.

Pytanie 6: czy zgodzicie się na audyt kodu przez podmiot trzeci

Konkretna odpowiedź to zgoda wpisana do umowy przed startem, z ustalonym momentem audytu i wskazaniem, kto go opłaca — zwykle zamawiający. Ustal też, co audytor dostanie: repozytorium z pełną historią zmian, dokumentację, dostęp do środowiska testowego i listę zależności.

Sensowny moment na taki przegląd to pierwsze działające wydanie: architektura już istnieje, a w budżecie zostają jeszcze środki na poprawki. Audyt po odbiorze końcowym jest materiałem do sporu, a nie narzędziem naprawczym. Gdzie ten moment wypada w całym harmonogramie, pokazujemy w przewodniku po tym, jak stworzyć aplikację mobilną.

Odpowiedzi wymijające: „mamy wewnętrzne przeglądy kodu, audyt nie jest potrzebny”, „to kwestia zaufania”, „zgodzimy się, ale dopiero po zakończeniu projektu”, „zewnętrzny audytor pozna nasze know-how”.

Pytanie 7: jak wygląda procedura zmiany zakresu

Konkretna odpowiedź nazywa formę zgłoszenia, termin wyceny w dniach roboczych, osobę decyzyjną po każdej stronie i skutek zmiany dla harmonogramu. Elastyczność bez procedury oznacza, że o koszcie zmiany dowiadujesz się po fakcie, przy fakturze albo przy przesuniętym terminie. Sama procedura wygląda inaczej przy rozliczeniu ryczałtowym i godzinowym, co porównujemy w tekście o tym, czy wybrać fixed price czy time and material.

Wymijająco brzmi „jesteśmy elastyczni, zawsze się dogadujemy”, „drobne zmiany mamy wliczone w cenę” bez podania limitu oraz „to standardowo aneks” bez terminu na wycenę.

Wszystkie siedem pytań wyślij w jednej wiadomości, w tym samym brzmieniu, do każdej firmy na krótkiej liście. Poniższy fragment wystarczy skopiować.

Porównuj nie tyle treść odpowiedzi, ile ich formę: kto odpowiedział punkt po punkcie i zaproponował brzmienie zapisu w umowie, a kto odesłał ogólną prezentację i propozycję spotkania. Jeśli dopiero układasz opis projektu, przez komplet pytań o cel, zakres i ramy przeprowadza w sześciu krokach kreator briefu.