Kod, dostępy, dokumentacja: co musisz mieć po zakończeniu projektu

„Bez uzależniania od siebie” obiecuje prawie każdy wykonawca, ja też. Obietnica nic nie kosztuje, więc zamiast w nią wierzyć, warto ją sprawdzić. Ten tekst to lista rzeczy, które po zakończeniu projektu powinny fizycznie być u Ciebie, i test, który pokazuje, czy są.

Sześć rzeczy, które powinny być Twoje

• Kod z historią

  Repozytorium i zapis umowny, że kod jest Twój.

• Konta na firmę

  Domena, serwer, poczta, płatności. Wykonawca jako dodatkowy użytkownik.

• Dokumentacja uruchomienia

  Jak postawić projekt od zera na nowym serwerze.

• Odtworzona kopia

  Nie sama kopia, tylko dowód, że da się z niej wrócić.

• Lista licencji

  Co jest użyte, na jakich warunkach i co trzeba odnawiać.

• Hasła w menedżerze

  Nie w archiwum poczty, gdzie leżą potem latami.

1. Kod z historią zmian, wydawany na żądanie

Repozytorium to miejsce, w którym leży kod strony razem z historią wszystkich zmian. Nie musi stać na koncie Twojej firmy: równie dobrze może prowadzić je wykonawca. Ma natomiast wynikać z umowy, że kod jest Twój i że dostajesz go na żądanie, razem z historią zmian, bez negocjacji i bez czekania. Ryzykowny jest tylko układ, w którym możesz jedynie „poprosić o kopię” z dobrej woli: kopia z zeszłego miesiąca nie jest tym samym co bieżący kod.

2. Konta zarejestrowane na firmę

Domena, serwer, skrzynka pocztowa, konto w systemie płatności, mapy, narzędzia do wysyłki wiadomości. Każde z nich ma właściciela i to Ty masz nim być. Wykonawca dostaje dostęp jako dodatkowy użytkownik i traci go, gdy współpraca się kończy, bez przenoszenia czegokolwiek.

3. Dokumentacja uruchomienia

Nie opis funkcji, tylko instrukcja: jak postawić projekt od zera na nowym serwerze, jakie ustawienia trzeba podać, jak zrobić kopię i jak ją odtworzyć. Dobry test: czy inny programista pracujący w tej samej technologii uruchomiłby projekt bez telefonu do autora. Jeśli dokumentacja tego nie umożliwia, jest niekompletna.

4. Kopie zapasowe, które ktoś odtworzył

Kopia, której nikt nigdy nie odtworzył, to nadzieja, nie zabezpieczenie. Przy odbiorze poproś, żeby wykonawca odtworzył stronę z kopii przy Tobie, choćby na serwerze testowym. Zajmuje to godzinę i rozstrzyga sprawę.

5. Lista komponentów i ich licencji

Prawie każda strona składa się w większości z gotowych elementów: biblioteki, wtyczki, czcionki, szablony. Część jest darmowa na określonych warunkach, część płatna co rok. Powinna zostać u Ciebie lista: co jest użyte, na jakiej licencji i co trzeba odnawiać. Bez tego pierwsza wiadomość o wygasłej licencji przyjdzie w najgorszym momencie.

6. Hasła w menedżerze, nie w skrzynce

Dostępy przekazane mailem leżą potem w archiwum poczty przez lata. Załóż firmowy menedżer haseł i poproś wykonawcę, żeby wpisał tam wszystko, czego używa. To godzina pracy, która rozwiązuje problem „gdzie było to hasło” na zawsze.

Kod na zamówienie a narzędzie wykonawcy

To rozróżnienie decyduje o tym, czego możesz się domagać. Kod napisany specjalnie pod Twój projekt jest Twój i powinien przejść na Ciebie w umowie. Ale wielu wykonawców buduje strony na własnym narzędziu, na przykład na systemie do edycji treści, który rozwija dla wszystkich klientów. Tego narzędzia nie kupujesz na własność, bo wtedy wykonawca musiałby przestać go używać u innych. Dostajesz do niego licencję.

Trzy pytania, które trzeba zadać o taką licencję. Czy jest bezterminowa, czy wygasa razem ze współpracą? Czy pozwala zlecić zmiany komuś innemu? Czy dostajesz kod źródłowy narzędzia, czy tylko działającą stronę? Trzy razy „tak” oznacza, że nie jesteś uzależniony. Każde „nie” to pole do negocjacji przed podpisaniem, nie po.

U mnie: kod napisany pod Twój projekt przenoszę na Ciebie w umowie, a jeśli strona korzysta z mojego autorskiego systemu do edycji treści, dostajesz do niego bezterminową licencję z prawem do zmian na własne potrzeby. Szczegóły są w umowie, nie na stronie, bo to umowa wiąże.

Co warto mieć w umowie

• Przeniesienie praw do kodu napisanego pod projekt i licencja na narzędzia wykonawcy, z opisem, co możesz z nimi robić.
• Moment przekazania. Dostępy od pierwszego dnia, kod na każde żądanie, nie dopiero po ostatniej fakturze.
• Dokumentacja jako element odbioru. Projekt nie jest skończony, dopóki jej nie ma.
• Dostęp do kopii danych na żądanie, także w trakcie współpracy.
• Co się dzieje po zakończeniu utrzymania: kto ma dostępy, co zostaje wyłączone, w jakim czasie.

To lista do rozmowy z prawnikiem, nie gotowa umowa. Wykonawca, który reaguje na nią spokojnie, prawdopodobnie i tak to robi. Wykonawca, który reaguje nerwowo, właśnie powiedział Ci coś ważnego.

Test na koniec projektu

Wyobraź sobie, że wykonawca jutro znika: telefon milczy, maile wracają. Odpowiedz na cztery pytania. Czy masz kod i wiesz, gdzie jest? Czy zalogujesz się do serwera, domeny i panelu strony bez niczyjej pomocy? Czy inny programista uruchomi projekt z dokumentacji? Czy odtworzysz stronę z kopii?

Każde „nie wiem” to rzecz do załatwienia przed odbiorem, kiedy jeszcze masz argument w ręku. Po ostatniej fakturze ten sam wniosek kosztuje dużo więcej.

Jak to wygląda u mnie

Serwer, domena i konta usług stoją na Twoich danych, a kod i dane dostajesz na żądanie w każdej chwili; repozytorium prowadzę u siebie albo na koncie Twojej firmy, jak wolisz. Dokumentację piszę tak, żeby inny programista pracujący w Laravelu uruchomił projekt bez rozmowy ze mną. Przy dłuższej współpracy ustalamy z góry, kto przejmuje sprawę, gdybym wypadł z gry. To nie jest gest dobrej woli, tylko warunek, przy którym mogę uczciwie mówić „bez uzależniania od siebie”.

Jeśli przejmujesz stronę po kimś innym i nie masz części z tej listy, zacznij od tekstu o pierwszym tygodniu po przejęciu. Tam jest kolejność, w jakiej odzyskuje się kontrolę.