Strona działa, faktura za projekt została opłacona, ale po kilku miesiącach okazuje się, że domena jest zarejestrowana na wykonawcę, kod znajduje się na jego prywatnym koncie, a firma nie ma dostępu do hostingu. Wtedy zwykła zmiana dostawcy może zamienić się w kosztowny projekt ratunkowy.
Przy przejmowaniu strony lub aplikacji sprawdzam więc nie tylko to, czy serwis działa. Znacznie ważniejsze jest pytanie: czy firma może samodzielnie utrzymywać, rozwijać, przenieść i odtworzyć system bez zgody dotychczasowego wykonawcy? Poniżej pokazuję, co powinno zostać przekazane i jak to praktycznie zweryfikować.
Domena i hosting powinny być pod kontrolą firmy, nie wykonawcy
Pierwsze miejsce, które sprawdzam, to domena. Firma powinna być wskazana jako jej abonent lub właściciel zgodnie z zasadami danego rejestratora oraz posiadać dostęp do konta, z którego można domenę przedłużyć, zmienić jej konfigurację DNS albo przenieść do innego operatora.
Problem często zaczyna się niewinnie. Agencja podczas uruchamiania strony „załatwia domenę za klienta” i rejestruje ją ze swojego konta. Przez kilka lat wszystko działa, dopóki firma nie chce zmienić wykonawcy albo dotychczasowy dostawca przestaje odpowiadać.
Podobnie wygląda dostęp do hostingu. Jeżeli serwer lub środowisko chmurowe są potrzebne do działania systemu, firma powinna mieć konto administracyjne albo przynajmniej formalną możliwość przejęcia usługi. Najbezpieczniejszy model to taki, w którym konto rozliczeniowe należy do klienta, a wykonawca otrzymuje dostęp techniczny tylko na czas współpracy.
Nie oznacza to, że każda mała strona musi mieć własną rozbudowaną infrastrukturę chmurową. Przy prostej stronie firmowej zarządzany hosting utrzymywany przez agencję może mieć ekonomiczny sens. W umowie powinno być jednak jasno określone, co stanie się ze stroną po zakończeniu współpracy i w jaki sposób można ją przenieść.
Repozytorium kodu i baza danych muszą pozwalać odtworzyć działający system
Samo otrzymanie paczki ZIP z plikami nie oznacza jeszcze, że firma może przejąć projekt. Jeżeli strona lub aplikacja jest rozwijana programistycznie, oczekuję dostępu do repozytorium, czyli miejsca przechowującego kod wraz z historią jego zmian. Najczęściej będzie to GitHub, GitLab, Bitbucket albo podobna usługa.
Kod źródłowy aplikacji powinien być dostępny dla firmy w aktualnej wersji, najlepiej na koncie organizacyjnym należącym do niej. Dzięki temu nowy zespół może zobaczyć nie tylko końcowe pliki, lecz także sposób rozwoju projektu, wersje i wprowadzone poprawki.
Drugi element to baza danych. W sklepie internetowym mogą znajdować się w niej produkty, zamówienia i konfiguracja systemu, a w aplikacji biznesowej również dane użytkowników oraz procesów. Przy odbiorze projektu warto sprawdzić, czy można wykonać eksport bazy oraz czy wiadomo, jak przywrócić ją na nowym środowisku.
W praktyce zadaję proste pytanie: czy inny kompetentny wykonawca, dysponując przekazanymi materiałami, byłby w stanie uruchomić system? Jeżeli odpowiedź brzmi „nie, ponieważ tylko obecna agencja wie, jak to zrobić”, projekt nadal jest zależny od dostawcy.
Konta zewnętrzne i klucze API są równie ważne jak sam kod
Nowoczesna strona rzadko działa samodzielnie. Może korzystać z systemu wysyłki e-maili, płatności, map, analityki, CRM, narzędzi marketingowych, usług SMS czy zewnętrznego systemu logowania. Każda z takich integracji może mieć osobne konto i dane dostępowe.
Przy odbiorze sprawdzam więc, kto jest właścicielem kont oraz kto kontroluje płatności. Szczególnie niebezpieczna jest sytuacja, w której kluczowa usługa została uruchomiona na prywatnym koncie pracownika wykonawcy. Po jego odejściu odzyskanie dostępu potrafi być trudniejsze niż sama migracja aplikacji.
Osobną kategorią są klucze API, czyli techniczne „hasła”, dzięki którym system komunikuje się z innymi usługami. Firma nie musi znać każdego klucza na pamięć ani przechowywać go w arkuszu. Powinna jednak wiedzieć, gdzie znajduje się bezpieczny magazyn takich danych i kto może generować nowe klucze.
Po zmianie wykonawcy często zalecam wygenerowanie nowych kluczy oraz odebranie dostępu osobom, które nie powinny go już posiadać. To prostsze i bezpieczniejsze niż zakładanie, że stare dane uwierzytelniające nigdy nie zostały zapisane poza firmową infrastrukturą.
Kopia zapasowa i dokumentacja pokazują, czy system naprawdę można przejąć
Backup istniejący wyłącznie „gdzieś na serwerze wykonawcy” daje niewielkie poczucie bezpieczeństwa. Firma powinna wiedzieć, co jest kopiowane, jak często powstają kopie, jak długo są przechowywane oraz przede wszystkim — jak wygląda ich odtworzenie.
Dobrym testem jest próba przywrócenia systemu na osobnym środowisku. Dopiero wtedy wiadomo, czy kopia zawiera wszystkie potrzebne elementy. Sam komunikat „backup wykonywany codziennie” nie gwarantuje, że da się go skutecznie wykorzystać podczas awarii.
Podobną rolę pełni dokumentacja. Nie chodzi o tworzenie kilkuset stron dokumentów, których nikt później nie przeczyta. Przy typowym projekcie wystarczy praktyczny opis infrastruktury, sposobu uruchamiania aplikacji, wykorzystywanych usług, kopii zapasowych, ważnych kont oraz procedury publikowania zmian.
Dla niewielkiej strony dokumentacja może mieć jedną lub dwie strony. Dla rozbudowanej aplikacji będzie obszerniejsza. Jej zakres powinien odpowiadać rzeczywistej złożoności systemu, a nie wymaganiom formalnym oderwanym od sposobu pracy firmy.
Dostęp do kodu nie jest tym samym co prawa do jego używania
To jeden z najczęściej pomijanych tematów przy odbiorze projektu. Firma może dostać komplet plików i nadal nie mieć jasno określonego prawa do ich modyfikowania lub dalszego rozwijania.
Dlatego w umowie powinno być wskazane, co dzieje się z prawami do dedykowanego kodu po zakończeniu projektu. W zależności od modelu współpracy może chodzić o przeniesienie autorskich praw majątkowych albo odpowiednio szeroką licencję. Szczegóły warto ocenić pod kątem konkretnej umowy, zwłaszcza przy systemach mających istotną wartość biznesową.
Trzeba też oddzielić kod napisany specjalnie dla firmy od elementów zewnętrznych. Framework, biblioteka open source, płatna wtyczka czy font mogą działać na własnych licencjach i nie stają się automatycznie własnością klienta. Ważne jest więc nie tyle żądanie „praw do wszystkiego”, ile wiedza, które elementy firma może swobodnie rozwijać, a które zależą od cudzej licencji lub abonamentu.
Przed odbiorem projektu sprawdź tę krótką listę
Praktyczny odbiór projektu nie powinien kończyć się na kliknięciu kilku podstron. Ja sprawdziłbym przynajmniej poniższe elementy:
- domena jest zarejestrowana na firmę i firma ma dostęp administracyjny,
- hosting lub chmura mogą zostać przejęte albo zmigrowane,
- firma ma dostęp do aktualnego repozytorium kodu,
- istnieje możliwość eksportu i odtworzenia bazy danych,
- kluczowe konta zewnętrzne są założone na firmę,
- wiadomo, gdzie znajdują się klucze API i inne dane dostępowe,
- działają kopie zapasowe i znana jest procedura ich odtworzenia,
- przekazano podstawową dokumentację techniczną,
- umowa jasno określa prawa do kodu i pozostałych elementów projektu,
- po zakończeniu współpracy można odebrać wykonawcy zbędne dostępy.
Tę listę warto wykorzystać nie tylko przy odbiorze gotowej strony. Najlepszy moment na ustalenie zasad własności i przekazywania dostępów jest przed rozpoczęciem projektu, ponieważ wtedy nie trzeba później negocjować wydania elementów nieopisanych w umowie.
Uzależnienie od wykonawcy nie zawsze jest celowe. Częściej wynika z wygody, pośpiechu i odkładania kwestii organizacyjnych „na później”. Dobrze zaprojektowane przekazanie projektu pozwala firmie nadal współpracować z tym samym wykonawcą, ale z wyboru, a nie dlatego, że technicznie nie ma innej możliwości.
Sprawdź tę listę jeszcze przed podpisaniem umowy z wykonawcą.