Jak wybrać software house: pytania, sygnały ostrzegawcze i umowa

Jak wybrać software house? Po tym, co da się sprawdzić, a nie po tym, co firma pisze o sobie. Każda oferta obiecuje doświadczony zespół, terminowość i elastyczność, więc te słowa niczego nie rozstrzygają. Rozstrzygają rzeczy weryfikowalne: wpis w rejestrze, działające realizacje, rozmowa z poprzednim klientem, odpowiedzi na konkretne pytania przed podpisaniem umowy i treść samej umowy, zwłaszcza w części o prawach do kodu. Żaden z kroków opisanych niżej nie wymaga znajomości programowania.

Zanim zaczniesz szukać: trzy zdania o projekcie

Wiele nieudanych wyborów zaczyna się od szukania firmy, zanim wiadomo, do czego jest potrzebna. Wykonawców porównuje się wtedy po wyglądzie ich stron i po stawkach. Zanim otworzysz wyszukiwarkę, zapisz trzy rzeczy. Co ma powstać i kto będzie z tego korzystał. Do kiedy i dlaczego akurat do wtedy. Co jest w tym projekcie najtrudniejsze albo najbardziej ryzykowne.

Ostatni punkt najczęściej się pomija, a to on decyduje, jakiego wykonawcy szukasz. Przy prostej stronie firmowej ryzykiem jest głównie termin i gotowość tekstów. Przy panelu, który pobiera zamówienia ze sklepu i przekazuje je do programu do faktur, ryzykiem są integracje. Przy platformie z płatnościami i kontami użytkowników ryzykiem jest bezpieczeństwo i to, kto będzie ją rozwijał za dwa lata.

Te trzy zdania zawężają poszukiwania. Firma, która w portfolio ma wyłącznie strony wizytówkowe, nie ma jak pokazać, że poradzi sobie z integracją z systemem księgowym. To nie jest ocena jakości, tylko dopasowania.

Software house, freelancer czy agencja: kto pasuje do jakiego projektu

Te trzy nazwy opisują różne modele pracy, a nie poziomy jakości. Różnią się tym, ile osób pracuje nad projektem, kto odpowiada za całość i co się dzieje, gdy jedna osoba przestaje być dostępna.

Przy małym, dobrze opisanym zadaniu freelancer bywa najlepszym wyborem i nie ma powodu płacić za strukturę, której projekt nie potrzebuje. Software house ma przewagę, gdy projekt wymaga kilku specjalizacji naraz albo ma żyć latami. Większość kroków opisanych dalej, w tym rejestry, referencje i prawa do kodu, stosuje się tak samo do freelancera.

Krótka lista: trzy do pięciu firm, nie piętnaście

Przy kilkunastu firmach nie da się rzetelnie odpowiedzieć na pytania każdej z nich, porozmawiać z ich referencjami i porównać ofert. Kończy się na wyborze po kwocie, czyli po jedynej liczbie, która nie mówi, co dostaniesz. Przy trzech do pięciu każdej można poświęcić godzinę rozmowy i kwadrans sprawdzania. Źródła, z których buduje się listę, różnią się wiarygodnością:

• Polecenie od kogoś, kto skończył projekt. Najcenniejsze, pod warunkiem że polecający był po stronie zamawiającego, a projekt jest już po wdrożeniu, nie w trakcie.
• Realizacje, które znasz jako użytkownik. Sklep albo aplikacja, z których korzystasz i które działają dobrze. Wykonawca bywa podany w stopce, a jeśli nie, można zapytać właściciela.
• Publiczny kod. Firmy, które publikują własne narzędzia albo poprawiają biblioteki open source, zostawiają ślad, który da się obejrzeć bez ich udziału.
• Rankingi i katalogi firm. Dobre do zebrania nazw, słabe do oceny. Sprawdź, czy kolejność na liście nie zależy od wykupionego miejsca.

Od razu odrzucaj firmy, które nie podają na stronie danych rejestrowych. Nazwa firmy, NIP i adres to minimum, które pozwala sprawdzić, z kim rozmawiasz.

Sprawdź firmę w rejestrach, zanim umówisz rozmowę

Kwadrans w publicznych rejestrach odpowiada na pytania, których nie warto zadawać na rozmowie. Poniższe źródła są bezpłatne i nie wymagają logowania.

Biała lista ma też skutki podatkowe. Gdy jednorazowa wartość transakcji z innym przedsiębiorcą przekracza 15 000 zł, płatność musi przejść przez rachunek płatniczy (art. 19 Prawa przedsiębiorców). Jeśli zapłacisz czynnemu podatnikowi VAT na rachunek, którego na dzień zlecenia przelewu nie ma w wykazie, nie zaliczysz tej płatności do kosztów podatkowych (art. 15d ustawy o CIT, art. 22p ustawy o PIT). Wyjątkiem jest zawiadomienie złożone do Twojego urzędu skarbowego w ciągu 7 dni od zlecenia przelewu.

Liczy się wartość całej transakcji, a nie pojedynczej raty, więc projekt płatny w trzech częściach po 6 000 zł też podlega tej zasadzie. Sprawdzenie numeru konta w wykazie przed przelewem zajmuje minutę.

Data rejestracji nie jest oceną jakości. Młoda spółka może być nowym podmiotem doświadczonego zespołu. Rejestr odpowiada na prostsze pytania: czy podmiot, z którym podpiszesz umowę, istnieje, kto go reprezentuje i czy jego skala pasuje do Twojego projektu.

Portfolio: co możesz zweryfikować samodzielnie

Portfolio przygotowuje sama firma, więc trzeba je sprawdzić, a nie tylko obejrzeć. Zacznij od tego, czy realizacje działają. Otwórz kilka z nich na telefonie, przejdź przez formularz kontaktowy albo koszyk, sprawdź, czy treści są aktualne. Projekt, który przestał działać rok po wdrożeniu, to temat do pytania na rozmowie, nawet jeśli to klient zrezygnował z opieki.

Potem zmierz. Wpisz adres realizacji w PageSpeed Insights i zobacz wynik dla urządzeń mobilnych. Jeden pomiar to nie wyrok, bo wynik różni się między uruchomieniami i zależy też od tego, co klient dodał po oddaniu strony. Słabe wyniki na wszystkich realizacjach to jednak wzorzec.

Najważniejsze pytanie do portfolio brzmi: co dokładnie zrobiliście w tym projekcie. Duże realizacje często powstają w kilka firm. Jedna przygotowuje projekt graficzny, druga frontend, trzecia integracje. Każda może uczciwie pokazać projekt w portfolio, ale tylko jedna odpowiada za część, która Cię interesuje. Poproś o opis roli i o kontakt do osoby po stronie klienta, która może ją potwierdzić.

Część projektów jest objęta poufnością i to normalne przy systemach wewnętrznych. Można wtedy poprosić o opis problemu bez nazwy klienta albo o pokaz na danych demonstracyjnych. Firma, której całe portfolio jest poufne, ma jednak problem z udowodnieniem czegokolwiek.

Publiczny kod jest dowodem, którego nie da się przygotować pod konkretnego klienta. Jeśli poprawki firmy trafiają do cudzych bibliotek open source, przeszły review opiekunów tych projektów, którzy nie mają powodu być pobłażliwi. Nie musisz czytać kodu, żeby z tego skorzystać: przyjęte zmiany, daty i komentarze opiekunów są zrozumiałe bez znajomości programowania. My kontrybuujemy między innymi do Proxmox VE, PHPMailer i ILSpy, a nasze projekty zebraliśmy na stronie open source.

Referencje: o co pytać poprzedniego klienta

Pytanie "czy jesteście zadowoleni" dostaje odpowiedź "tak", bo żadna firma nie poda kontaktu do niezadowolonego klienta. Wartość referencji leży w szczegółach, o które trzeba zapytać wprost. Poproś o kontakt do klienta z podobnego projektu, zakończonego co najmniej kilka miesięcy temu, bo klient w trakcie projektu nie zna jeszcze odbioru i wsparcia po wdrożeniu. Potem zadaj pytania, na które nie da się odpowiedzieć jednym słowem:

1. Co w projekcie poszło inaczej, niż planowaliście, i jak wykonawca na to zareagował?
2. O ile końcowy koszt i termin różniły się od tych z oferty i z jakiego powodu?
3. Z kim rozmawialiście na co dzień i czy ta osoba znała szczegóły techniczne?
4. Jak wyglądał odbiór i ile błędów wyszło w pierwszych tygodniach po starcie?
5. Czy dostaliście kod, dostęp do repozytorium i dokumentację?
6. Czy wykonawca kiedyś powiedział, że czegoś nie zrobi albo że coś jest złym pomysłem?
7. Czy zleciłbyś mu kolejny projekt, a jeśli nie, to dlaczego?

Najwięcej mówi pierwsze pytanie. Każdy projekt ma problemy, a referencja, w której nic nie poszło źle, oznacza zwykle, że rozmówca nie pamięta szczegółów albo nie chce o nich mówić. Dobra odpowiedź brzmi mniej więcej tak: "integracja z hurtownią okazała się trudniejsza, wykonawca powiedział o tym w drugim tygodniu, zaproponował dwa warianty i razem wybraliśmy prostszy". Widać w niej, że problem został zgłoszony wcześnie, razem z możliwymi rozwiązaniami, a decyzję podjął klient.

Szóste pytanie sprawdza coś, czego nie widać w portfolio: czy wykonawca potrafi się nie zgodzić. Firma, która robi wszystko, o co ją poproszono, bez jednego "a czy na pewno", przerzuca na Ciebie odpowiedzialność za decyzje techniczne, na których nie musisz się znać.

Pytania do software house'u przed podpisaniem umowy

Pierwszą rozmowę prowadzi zwykle ktoś, kto dobrze opowiada o firmie. Twoim celem jest wyjść poza tę opowieść i zobaczyć, jak firma pracuje. Najlepiej robią to pytania, na które trzeba odpowiedzieć konkretem.

Zwróć też uwagę, czy rozmówca zadaje pytania Tobie. Wykonawca, który dopytał o użytkowników, dane i systemy dookoła, wyceni projekt rzetelniej niż ten, który od razu podaje kwotę. Kwota podana przed jakimkolwiek pytaniem pochodzi z szablonu, a nie z analizy Twojego projektu.

Dobrym testem jest prośba o radę: "czy w mojej sytuacji to w ogóle ma sens". Rzetelny wykonawca czasem odpowie, że problem rozwiąże gotowe narzędzie albo mniejszy zakres.

Komunikacja: sprawdzisz ją, zanim cokolwiek podpiszesz

Przed podpisaniem umowy firma ma najsilniejszą motywację, żeby odpowiadać szybko i konkretnie. Jeśli już teraz odpowiedzi przychodzą po tygodniu albo omijają pytania, w trakcie projektu nie będzie lepiej. Kilka rzeczy sprawdzisz w pierwszej wymianie wiadomości:

• Przewidywalność odpowiedzi. Nie chodzi o minuty. Firma, która pisze "odpowiemy jutro do południa" i dotrzymuje słowa, jest lepsza od tej, która raz odpisuje od razu, a raz po tygodniu.
• Odpowiedź na każde pytanie. Wyślij pięć pytań w jednej wiadomości i policz, na ile dostałeś odpowiedź. Pominięte pytania to często te, na które odpowiedź jest niewygodna.
• Język. Z odpowiedzi rozumiesz, co się wydarzy, bez słownika skrótów. Żargon nie dowodzi kompetencji. Umiejętność wytłumaczenia rzeczy technicznej osobie spoza branży już tak.
• Podsumowanie po rozmowie. Czy po spotkaniu przychodzi pisemna lista ustaleń. W trakcie projektu takie podsumowania chronią obie strony przed sporem "przecież mówiliśmy inaczej".

Zapytaj też, jak często dostaniesz informację o postępie bez proszenia. Raport co tydzień albo dwa, z tym, co zrobiono, co jest następne i co blokuje pracę, wystarcza w większości projektów.

Kto naprawdę napisze kod i co z tego wynika dla praw

Software house może pracować z programistami zatrudnionymi na umowę o pracę, z osobami współpracującymi na podstawie umów cywilnoprawnych albo z podwykonawcami. Każdy z tych modeli jest legalny i powszechny. Dla Ciebie ma znaczenie z dwóch powodów: ciągłości projektu i łańcucha praw autorskich.

Ciągłość to pytanie o to, co się stanie, gdy osoba prowadząca Twój projekt odejdzie. Zapytaj, czy powstaje dokumentacja i czy kod przechodzi przez review drugiego programisty. Jeśli tak, wiedza o projekcie nie siedzi w głowie jednej osoby.

Łańcuch praw jest mniej oczywisty. Prawa majątkowe do programu komputerowego stworzonego przez pracownika w ramach obowiązków ze stosunku pracy przysługują pracodawcy, o ile umowa nie stanowi inaczej (art. 74 ust. 3 ustawy o prawie autorskim i prawach pokrewnych). Ten przepis dotyczy jednak pracowników. Gdy kod pisze programista współpracujący z firmą na podstawie umowy B2B albo podwykonawca, prawa powstają u niego, a software house nabywa je dopiero na podstawie umowy z nim. Software house nie przeniesie na Ciebie praw, których sam skutecznie nie nabył.

Dlatego umowa powinna zawierać oświadczenie wykonawcy, że przysługują mu prawa do przekazywanego kodu w zakresie potrzebnym do ich przeniesienia, oraz zobowiązanie, że roszczenia osób trzecich dotyczące tego kodu wykonawca przejmie na siebie. Firma z uporządkowanymi umowami z programistami podpisze to bez dyskusji.

Prawa do kodu: zapisy, bez których umowa nie chroni zamawiającego

O tym, czy kod jest Twój, decyduje umowa, a nie opłacona faktura. Ustawa o prawie autorskim i prawach pokrewnych zawiera kilka przepisów, które działają na niekorzyść zamawiającego, jeśli umowa ich nie uwzględni.

Pierwszy dotyczy formy. Umowa o przeniesienie autorskich praw majątkowych wymaga formy pisemnej pod rygorem nieważności (art. 53). Forma pisemna oznacza własnoręczny podpis albo kwalifikowany podpis elektroniczny, który Kodeks cywilny uznaje za równoważny (art. 78 i art. 78¹ KC). Akceptacja oferty mailem nie jest skuteczną umową przeniesienia praw, nawet jeśli w ofercie było zdanie "prawa do kodu przechodzą na klienta".

Drugi dotyczy pól eksploatacji. Umowa przenosi prawa tylko na polach eksploatacji wyraźnie w niej wymienionych (art. 41 ust. 2) i może dotyczyć tylko pól znanych w chwili jej zawarcia (art. 41 ust. 4). Ogólne "przenosimy wszelkie prawa" bez listy nie wystarcza. Dla programu komputerowego lista powinna obejmować co najmniej uprawnienia z art. 74 ust. 4: trwałe lub czasowe zwielokrotnianie programu w całości lub w części, jego tłumaczenie, przystosowywanie, zmianę układu i wszelkie inne zmiany oraz rozpowszechnianie, w tym użyczenie i najem. W praktyce dopisuje się też udostępnianie w sieci, wprowadzanie do pamięci serwerów i prawo do zlecania zmian osobom trzecim.

Trzeci dotyczy domniemania licencji. Jeśli umowa nie mówi wyraźnie o przeniesieniu praw, przyjmuje się, że twórca udzielił licencji (art. 65). Licencja bez innych ustaleń uprawnia do korzystania z utworu przez pięć lat na terytorium państwa, w którym licencjobiorca ma siedzibę, a potem wygasa (art. 66). Niedopracowana umowa może więc dać Ci prawo do używania własnego systemu tylko przez pięć lat.

Czwarty dotyczy momentu przejścia praw. Jeśli umowa milczy, prawa przechodzą z chwilą przyjęcia utworu (art. 64). Wiele umów wiąże przejście praw z zapłatą, co jest uczciwe wobec wykonawcy. Zadbaj tylko, żeby było jasne, co dzieje się z kodem z etapów już opłaconych.

Poza prawami potrzebujesz fizycznego dostępu do tego, co kupujesz:

Co musi zawierać dokumentacja, żeby przejęcie projektu przez inny zespół było realne, opisaliśmy w tekście o monitoringu i utrzymaniu po wdrożeniu.

Umowa: co jeszcze sprawdzić poza prawami autorskimi

Kilka innych zapisów decyduje o tym, jak skończy się ewentualny spór:

• Zakres jako załącznik. Umowa powinna odsyłać do opisu funkcji, na podstawie którego da się sprawdzić, czy coś zostało zrobione. Zdanie "wykonanie sklepu internetowego" nie jest zakresem.
• Procedura odbioru. Ile masz dni na sprawdzenie, w jakiej formie zgłaszasz błędy i kiedy odbiór uznaje się za dokonany, jeśli nie zgłosisz uwag.
• Zmiany w trakcie. Kto je wycenia i czy prace mogą ruszyć przed Twoją akceptacją kosztu.
• Kary umowne. Opóźnienia biorą się też z czekania na materiały i decyzje zamawiającego, więc umowa powinna mówić, jak liczy się termin, gdy czeka się na Ciebie. Wykonawca może żądać zmniejszenia kary rażąco wygórowanej albo takiej, która dotyczy zobowiązania wykonanego w znacznej części (art. 484 § 2 KC).
• Rękojmia i gwarancja. Do wad dzieła stosuje się przepisy o rękojmi przy sprzedaży (art. 638 KC), a między przedsiębiorcami rękojmię można rozszerzyć, ograniczyć albo wyłączyć (art. 558 § 1 KC). Jeśli umowa ją wyłącza, sprawdź, czy w zamian jest gwarancja: jak długo trwa, czego dotyczy i w jakim czasie wykonawca reaguje na zgłoszenie.
• Dane osobowe. Jeśli wykonawca będzie miał dostęp do danych Twoich klientów, na przykład przy imporcie bazy albo utrzymaniu serwera, potrzebna jest umowa powierzenia przetwarzania danych spełniająca wymagania art. 28 RODO.
• Zakończenie współpracy. Jak rozlicza się wykonaną pracę, gdy któraś strona kończy współpracę przed czasem, i w jakim terminie dostajesz kod, dokumentację i dostępy.

Ostatni punkt działa jak ubezpieczenie: nie planujesz z niego korzystać, ale dzięki niemu rozstanie kosztuje czas, a nie cały projekt.

Sygnały ostrzegawcze przy wyborze wykonawcy

Żaden z poniższych sygnałów nie dowodzi nieuczciwości wykonawcy, część wynika z pośpiechu. Każdy jest jednak powodem, żeby zadać pytanie i poczekać na odpowiedź, zanim cokolwiek podpiszesz.

Reakcja na pytanie mówi więcej niż sam sygnał. Firma, która na pytanie o przeniesienie praw odpowiada "prześlemy wzór umowy z listą pól eksploatacji", rozwiązała problem jednym zdaniem. Firma, która zmienia temat albo proponuje rabat, pokazuje, jak będą wyglądały rozmowy w trakcie projektu.

Płatny pierwszy etap zamiast zakładu o cały projekt

Przy większych projektach dobrym sposobem na sprawdzenie wykonawcy jest zlecenie najpierw małego, zamkniętego etapu. Może to być analiza i opis zakresu, prototyp interfejsu albo jedna integracja, która jest najbardziej ryzykowną częścią systemu. Taki etap kończy się czymś, co zostaje Twoje niezależnie od dalszej decyzji.

Pierwszy etap odpowiada na pytania, na które nie odpowie żadna rozmowa: jak wykonawca dopytuje, jak dotrzymuje terminów i raportuje. Jeśli współpraca się nie układa, masz opis zakresu albo prototyp, z którym możesz pójść do innej firmy. Żeby to działało, zapisz w umowie, że wynik tego etapu przechodzi na Ciebie na tych samych zasadach co reszta projektu.

Jak wybrać software house spośród finalistów

Po rozmowach, referencjach i ofertach zostają zwykle dwie albo trzy firmy. Porównanie ich po kwocie jest kuszące, ale kwota mówi najmniej, jeśli oferty opisują różny zakres. Lepiej ocenić każdą firmę w kilku kategoriach i dopiero potem zestawić wynik z ceną.

Każdą kategorię oceń w skali od 1 do 3, gdzie 1 oznacza "nie wiem albo słabo", a 3 "sprawdziłem i jest dobrze". Firma z najwyższą sumą nie musi wygrać, ale jeśli najtańsza oferta ma najniższą sumę, wiesz, na czym oszczędzasz. Przy remisie wybieraj firmę, o której więcej wiesz z niezależnych źródeł.

Najczęściej zadawane pytania

Ile firm zapytać o ofertę?

Trzy do pięciu. Przy mniejszej liczbie nie masz porównania, przy większej nie zdążysz rzetelnie sprawdzić każdej firmy i skończysz na wyborze po kwocie.

Czy wybrać najtańszą ofertę?

Najpierw sprawdź, czy wszystkie oferty dotyczą tego samego zakresu. Najtańsza oferta często pomija elementy, które inni wycenili, na przykład testy, wdrożenie albo poprawki po starcie. Jeśli po wyrównaniu zakresu nadal jest najtańsza, a weryfikacja firmy wypadła dobrze, nie ma powodu jej odrzucać.

Czy podpisać NDA przed pierwszą rozmową?

Tak, jeśli w rozmowie mają paść informacje, które naprawdę muszą zostać poufne, na przykład dane klientów albo szczegóły umów z partnerami. Do ogólnego opisu projektu NDA zwykle nie jest potrzebne, a jego negocjowanie opóźnia pierwszą rozmowę.

Co zrobić, jeśli wykonawca nie chce przenieść praw do kodu?

Zapytaj, dlaczego. Czasem chodzi o własną bibliotekę, z której firma korzysta w wielu projektach. Rozsądnym rozwiązaniem jest wtedy przeniesienie praw do kodu napisanego dla Ciebie i licencja na element wspólny z prawem do modyfikacji i zlecania zmian innym firmom. Zwróć uwagę na czas licencji: udzieloną na czas nieoznaczony twórca może wypowiedzieć na rok naprzód, jeśli umowa tego nie wyklucza (art. 68 ust. 1). Jeśli wykonawca nie zgadza się na żadną z tych opcji, kupujesz usługę, a nie system.

Sprawdź nas tą samą listą

Nie prosimy, żeby wierzyć nam na słowo. Działamy od 2020 roku i napisaliśmy ponad 5 mln linii kodu. Nasze poprawki trafiają do projektów open source, między innymi Proxmox VE, PHPMailer i ILSpy, i każdą z nich można obejrzeć publicznie. Strony oddajemy z wynikiem 95+ w PageSpeed, który zmierzysz sam, a po zakończeniu projektu dostajesz prawa do kodu i dokumentację, która pozwala przejąć projekt innemu zespołowi.

Jak wygląda współpraca krok po kroku, opisaliśmy na stronie Jak pracujemy, a więcej o firmie znajdziesz na stronie o nas. Jeśli masz już krótką listę wykonawców i chcesz dopisać do niej nas, napisz przez formularz kontaktowy. Na pytania z tego tekstu odpowiemy tak konkretnie, jak oczekujesz tego od każdego innego wykonawcy.