Błędne formułowanie umów z software house’ami lub freelancerami często wynika z braku technicznych umiejętności u zamawiającego, który prowadzi do niemożności zweryfikowania kompetencji programistów, czy dobrania odpowiedniego sposobu rozliczania projektu. Z drugiej strony, kluczowa jest też znajomość chociażby prawa autorskiego.
Aby łatwiej przebrnąć przez proces zawierania umowy z software housem lub programistą, która zapewni spokój ducha i prawidłową realizację zlecenia, warto skorzystać z checklisty, zawierającej trzy kategorie spraw.
1. Sprawy techniczne
Czyli tematy, które trzeba zbadać i nie wchodzić we współpracę, jeśli dostawca nie spełnia ich w 100%. Jeśli zespół, z którym chcemy zacząć tworzenie naszego startupu ich nie spełnia, to jest to poważny sygnał, że możemy mieć do czynienia z amatorami, osobami początkującymi lub firmą, która nigdy nie realizowała większych projektów.
Przed podpisaniem umowy koniecznie należy sprawdzić, czy:
1. kod trzymany jest w repozytorium – dzięki temu:
- można zawsze wrócić do starszej wersji kodu,
- zespół może współpracować ze sobą nad tworzeniem kodu,
- kod zawsze jest na lokalnej maszynie oraz na serwerze (github, gitlab itp.),
- dużo łatwiej się go backupuje (jeśli jest np. na github’ie, to martwi się o to zewnętrzna firma, jeśli na gitlabie, to jest to odpowiedzialność dostawcy),
- można uruchamiać automatyczne sprawdzanie jakości kodu na zdalnym serwerze,
- można pracować nad wieloma wersjami/ficzerami jednocześnie,
- jeśli pracujemy z freelancerem i repozytorium jest u nas nie stracimy dostępu do kodu po rozstaniu się.
2. są tworzone testy automatyczne – bez testów nie ma mowy o poważnym podejściu do tematu. Zapewniają one:
- możliwość wykrycia czy dodanie/zmienienie funkcjonalności w module A ma wpływ na moduł B,
- możliwość szybkiego dodania kolejnej osoby do projektu (jeśli ona coś “popsuje” w trakcie kodowania to testy jej o tym powiedzą zanim kod trafi na serwer produkcyjny),
- wymuszają przemyślenie wielu rzeczy zanim dany kawałek funkcjonalności zostanie zakodowany,
- przekazania developmentu innemu zespołowi, który dodając/zmieniając elementy kodu nie “zepsuje” tego co już mamy,
- przy testach warto wspomnieć o dziale Quality Assurance (Q&A). Nie jest to co prawda wymagane, ale dobrze świadczy o całym procesie tworzenia kodu.
3. jest przeprowadzany code review, czyli proces, w którym każdy kawałek kodu jest przeglądany przez inną osobę. Jest to szczególnie ważne ponieważ ktoś, kto nie tworzył danego kodu ma świeże spojrzenie i może:
- wyłapać błąd, którego nie widzi autor,
- zaproponować lepsze rozwiązanie danego problemu.
4. jest zapewniony CI (continuous integration), czyli dodatkowy serwer, który po przeniesieniu kodu do repozytorium:
- uruchamia wszystkie testy automatyczne w całym projekcie,
- sprawdza czy w kodzie nie ma użytych przeterminowanych bibliotek zewnętrznych a także sprawdza czy kod jest poprawnie zbudowany,
- sprawdza czy nie ma potencjalnych luk bezpieczeństwa,
- dodatkowo nigdy nie zdarzy się sytuacja żeby do głównej gałęzi rozwojowej projektu wszedł kod, w którym nie przechodzą testy.
5. kodowanie odbywa się po angielsku – niby mało istotna sprawa, ale czytanie kodu, który częściowo jest pisany po polsku, częściowo po angielsku jest:
- mało wygodne,
- sprawia wrażenie niechlujności,
6. tworzona jest dokumentacja – nie można traktować projektu jako “utrzymywalnego” na dłuższą metę, jeśli nie posiada on opisu ważniejszych funkcji lub metod.
7. wykorzystywany jest znany framework, a nie autorski system (lub kod spaghetti) – to punkt, który może być trudny do weryfikacji dla kogoś nie będącego osobą techniczną. Użycie znanego frameworka:
- zabezpiecza nas przed związaniem się z jedną firmą i pracującymi w niej programistami, którzy jako jedyni na świecie znają nasz kod,
- pozwala łatwo dołączyć kolejne osoby/firmy do projektu,
- pozwala korzystać z zasobów i bibliotek tworzonych przez międzynarodową społeczność,
- to społeczność troszczy się o utrzymanie, rozwój i bezpieczeństwo podstawy naszego kodu,
- dzięki społeczności mamy dostęp do wielkiej bazy gotowych komponentów, których nie musimy kodować, więc w efekcie oszczędzamy pieniądze.
8. dostarczany jest serwer stagingowy, testowy i produkcyjny, czyli mamy możliwość obejrzenia kodu i cząstkowych efektów prac na innym serwerze niż ten, który odwiedzają nasi użytkownicy.
2. Prawa autorskie
Na początku biznesowej drogi zdarza się o nich zapominać, ale w przypadku sukcesu projektu może się to odbić czkawką. Dlatego należy zadbać o następujące kwestie:
1. przekazanie praw autorskich przez wykonawcę.
2. jeśli współpracujemy ze spółką, trzeba sprawdzić czy ona zadbała o przejęcie praw autorskich od swoich podwykonawców – jeśli programiści pracują inaczej, niż na umowę o pracę.
3. brak bibliotek AGPL – to może nie dotyczyć wszystkich projektów, ale jeśli nie chcemy otwierać naszego kodu lepiej ich nie używać.
4. zawarcie zapisu o “oprogramowaniu standardowym” – który określa do czego dostajemy prawa, a do czego nie. Software house może w naszym projekcie używać kodu, który znajduje się w jego bibliotece i rozwiązywać jakiś standardowy problem (np. logowanie). Nie dostajemy do niego pełni praw, ale dzięki temu szybciej jest nam dostarczany produkt.
5. warto zwrócić uwagę na licencje do darmowych grafik/skryptów – niektóre wymagają, by na stronie pojawiły się informacje o ich użyciu.
3. Cała reszta
Z naszego kilkuletniego doświadczenia wynika, że proces dopinania umów przebiega dużo sprawniej, kiedy zamawiający ma wcześniej przemyślane następujące kwestie:
1. rozliczanie się godzinowo vs. etapami vs. fix dla całego projektu – jest to jedna z poważniejszych decyzji:
- rozliczenie godzinowe daje maksymalną elastyczność dla obydwóch stron:
– pozwala modyfikować projekt w trakcie i sprawia, że wszyscy dążą do wspólnego celu,
– rozkłada równomiernie obciążenie finansowe,
– wymaga zaufania, że firma jest rzetelna i wykorzystuje godziny w efektywny sposób, - rozliczenie jedną ceną za całość – dzięki temu mamy wrażenie, że wiemy, ile zapłacimy jednak… jest to dość złudne:
– życie pokazuje, że na pewno coś się zmieni w projekcie lub w jego otoczeniu i będziemy musieli podpisywać aneks,
– wykonawca będzie bardzo niechętny żeby robić cokolwiek poza specyfikacją, jeśli nie dopłacimy,
– wykonawcy zależy żeby najmniej się narobić, a nam zależy żeby jak najwięcej upchnąć ponad specyfikację, - rozliczenie etapami – to model hybrydowy – ustalamy stałą cenę za małe moduły. W zależności od ich wielkości łączy w sobie (w różnych proporcjach) zalety i wady powyższych ;),
- myślę, że warto przed podjęciem decyzji zapoznać się z książką “Lean startup” Eric’a Ries’a.
2. sposób przekazywania efektów wykonanych prac – czy odbieramy całość na koniec developmentu czy z tygodnia na tydzień (dając swój feedback i zbierając go od swoich użytkowników).
3. określenie czasu na odbiór i dostarczenie dla obydwu stron – nie możemy sobie pozwolić żeby odbiory mogły trwać w nieskończoność.
4. opieka nad aplikacją po wdrożeniu, parametry SLA – w umowie trzeba zawrzeć to, że wykonawca nas nie “porzuci” po oddaniu projektu. Prawdziwe życie zaczyna się dopiero, jak oprogramowanie zacznie być używane przez prawdziwych, końcowych użytkowników.
5. jakie są warunki do odbioru częściowego a jakie do końcowego.
6. czym różnić się będzie utrzymanie i rozwój – na co możemy liczyć, jak dostawca będzie tylko doglądał naszego systemu?
7. kiedy możemy (my lub dostawca) odstąpić od umowy?
8. NDA – warto przygotować zawczasu i nie tracić czasu na wypisywanie dużych kar umownych,
9. zgoda lub jej brak na wystąpienie w portfolio dostawcy,
10. kto i jak wdraża aplikacje na serwer? kto i jak odpowiada za dostępność serwera, na którym zostanie ona uruchomiona?
11. kary umowne – należy zwrócić uwagę, za co mogą być naliczane.
Last but not least: zawsze warto dodatkowo skonsultować umowę z prawnikiem.
–
Adam Przymusiała
Współzałożyciel łódzkiego softwear house’u Binar::Apps oraz agencji interaktywnej Binar.Link
Na co dzień CEO tego pierwszego. Programista z wieloletnim doświadczeniem oraz wieloma startupami w swoim portfolio. Od 2009 roku zaangażowany w biznes online. Entuzjasta idei Lean Startup, certyfikowany Scrum Master i trener Ruby on Rails. Propagator dobrze zorganizowanej pracy zespołowej. Wie wszystko o zarządzaniu startupami i o narzędziach IT, wspierających biznes.
