Umowa z Software House’m - na co zwrócić uwagę przy podpisywaniu?

12 Jan 2017 | Adam Przymusiała

Jakiś czas temu prowadziłem warsztat w TechHubie w Google Campus w Warszawie na temat umów z firmami tworzącymi oprogramowanie (ze szczególnym uwzględnieniem kodowania dla startupów).

Uderzyła mnie ilość historii uczestników związanych z “niepowodzeniami” we współpracy z wykonawcami (zarówno freelancerami jak i firmami). Będąc reprezentantem tej “drugiej strony” jestem wciąż w szoku, że projekty mogą się “wykładać” na rzeczach które dla mnie wydają się oczywiste. Chciałbym podzielić się z Wami trzema “czek-listami”:

techniczną, o prawach autorskich oraz inne - czyli kategorią tradycyjnie najszerszą ;). Mam nadzieję, że to co znajduje się poniżej, pomoże komuś zaoszczędzić w przyszłości sporo $ i jeszcze więcej nerwów.

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/początkującymi lub kimś kto nigdy nie robił większych projektów.

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, bitbucket 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ę.

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 (znaczenie testów rośnie wręcz wykładniczo z czasem trwania projektu),
  • 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 teamowi 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.

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.

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.

Kodowanie 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,

Dokumentacja - nie wyobrażam sobie by można było traktować projekt jako “utrzymywalny” na dłuższą metę jeśli nie posiada on opisu ważniejszych funkcji lub metod.

Znany framework a 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ć = oszczędzamy $.

Serwer stagingowy, testowy i produkcja - czyli możliwość obejrzenia kodu i cząstkowych efektów prac na innym serwerze niż ten który odwiedzają nasi użytkownicy.

Prawa autorskie

To coś o czym można na początku zapomnieć ale w przypadku sukcesu porojektu może się nam odbić czkawką:

  • Po pierwsze, trzeba zadbać o ich przekazanie ;) od dostawcy.
  • Jeśli współpracujemy ze spółką to trzeba sprawdzić czy ona zadbała o przekazanie praw autorskich od podwykonawców - jeśli programiści pracują inaczej niż na umowę o pracę.
  • Brak bibliotek AGPL - to może nie dotyczyć wszystkich projektów, ale jeśli nie chcemy otwierać naszego kodu to.. lepiej ich nie używać ;).
  • Zawrzeć zapis o "oprogramowaniu standardowym" - 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 któremu szybciej jest nam dostarczany produkt.
  • 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.

Inne ;)

W BinarApps pracowaliśmy do tej pory nad dziesiątkami (jak nie setkami) projektów. Myślę że proces dogadywania poszedłby nam dużo sprawniej, jeśli zamawiający miałby wcześniej przemyślane kwestie takie jak:

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.

Do poruszenia przy konstruowaniu umowy

  • 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).
  • Określenie czasu na odbiór i dostarczenie dla obydwu stron - nie możemy sobie pozwolić żeby odbiory mogły trwać w nieskończoność.
  • 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.
  • Jakie są warunki do odbioru częściowego a jakie do końcowego.
  • Czym różnić się będzie utrzymanie i rozwój - na co możemy liczyć jak dostawca będzie tylko doglądał naszego systemu?
  • Kiedy możemy (my lub dostawca) odstąpić od umowy?
  • Przygotować NDA, nie tracić czasu na wpisywanie dużych kar umownych.
  • Wyrażenie lub nie zgodę na wystąpienie w portfolio dostawcy,
  • Dowiedzieć się kto i jak wdraża aplikacje na serwer? Kto i jak odpowiada za dostępność serwera na którym zostanie ona uruchomiona.
  • Kary umowne - zwrócić uwagę, za co mogą być naliczane.
  • "Last but not least": skonsultować umowę z prawnikiem :).

Jeśli w tej liście brakuje jeszcze jakiegoś ważnego punktu, będę bardzo wdzięczny za poruszenie go w komentarzach poniżej.


Dodaj komentarz!

Czytaj dalej:

01 Aug 2017
25 pozycji na lato czyli książkowe podsumowanie roku 2016/2017
Czytaj dalej