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!