Vendor lock rzadko jest wynikiem złej woli. Zwykle narasta po cichu: dostawca zakłada serwer na swoje konto, bo tak szybciej, trzyma kod u siebie, bo nikt nie poprosił o dostęp, a dokumentację obiecuje “na koniec projektu”. Przez lata nic się nie dzieje, bo współpraca układa się dobrze. Problem pojawia się dopiero wtedy, gdy trzeba ją zakończyć - albo choćby poważnie o tym pomyśleć.

Dobra wiadomość jest taka, że stopień uzależnienia da się sprawdzić, zanim stanie się kłopotem. Wystarczy jedno pytanie i krótka lista.

Jedno pytanie, które warto zadać każdemu wykonawcy

Gdybyśmy jutro zakończyli współpracę, co dokładnie dostaniemy i ile czasu zajmie innemu zespołowi przejęcie systemu?

Liczy się nie tylko treść odpowiedzi, ale też jej forma. Dobry dostawca odpowiada od razu i konkretnie: repozytorium już macie, konta są na Was, dokumentacja leży tu, przekazanie wiedzy zajmie tyle i tyle. Taka odpowiedź nie wymaga przygotowań, bo opisuje stan, który istnieje od początku.

Sygnałem ostrzegawczym jest odpowiedź wymijająca: “wszystko przekażemy, jak przyjdzie czas”, “to zależy”, “nie przewidujemy takiej sytuacji”. Nie musi świadczyć o złych intencjach. Świadczy natomiast o tym, że dziś nie macie w ręku niczego, co pozwalałoby odejść bez zgody i pomocy dostawcy.

Co powinno być po Waszej stronie od pierwszego dnia

Każda z tych rzeczy jest prosta do zapewnienia na starcie projektu i trudna do odzyskania po latach. Dlatego warto o nie zadbać, zanim padnie pierwsza linijka kodu.

1. Repozytorium kodu

Kod powinien leżeć w repozytorium założonym na Waszą firmę albo przynajmniej z Waszym dostępem właścicielskim. Nie chodzi o paczkę z kodem przesłaną raz na jakiś czas, tylko o repozytorium z pełną historią zmian. Historia pokazuje, kto, kiedy i dlaczego coś zmienił - a to bywa bezcenne dla zespołu, który kiedyś system przejmie.

2. Serwery, chmura i domena

Konta hostingowe i chmurowe, domena oraz zarządzanie jej rekordami powinny być zarejestrowane na Was. Dostawca może mieć w nich pełne uprawnienia do pracy, ale właścicielem jest firma. To ta pozycja najczęściej decyduje, czy zmiana partnera będzie spokojnym przekazaniem, czy wyścigiem z czasem o działający system.

3. Dokumentacja i instrukcja uruchomienia

Opis architektury i instrukcja, jak postawić system od zera, powinny powstawać na bieżąco, a nie na koniec. Dokumentacja odkładana do zamknięcia projektu zwykle nie powstaje wcale, bo zawsze jest coś pilniejszego. Prosty test: czy ktoś spoza zespołu dostawcy byłby w stanie uruchomić system, mając tylko to, co leży po Waszej stronie?

4. Kontekst dla narzędzi AI

To pozycja, której jeszcze niedawno nie było na żadnej liście. Zespoły programistyczne coraz częściej pracują z asystentami AI, a te korzystają z przygotowanego kontekstu: opisu projektu, przyjętych zasad, kluczowych decyzji i konwencji. To skondensowana wiedza o Waszym systemie. Jeśli zostaje wyłącznie u dostawcy, nowy zespół zaczyna bez niej. Warto, żeby była częścią repozytorium, tak jak dokumentacja.

5. Majątkowe prawa autorskie

Umowa powinna przenosić na Was majątkowe prawa autorskie do kodu, z wymienionymi polami eksploatacji. Bez tego nawet pełny dostęp do repozytorium nie daje pewności, że możecie system rozwijać z innym wykonawcą. Szczegóły zapisów warto skonsultować z prawnikiem - ważne, żeby temat w ogóle znalazł się w umowie.

Co zrobić, jeśli test wypadnie źle

Wiele firm odkrywa problem dopiero wtedy, gdy zadaje sobie powyższe pytania. To nie jest sytuacja bez wyjścia, ale kolejność działań ma znaczenie.

Zacznijcie od tego, co chroni ciągłość działania: dostępy do kont, na których działa system, i do danych. Potem repozytorium i dokumentacja. Rozmowę z dostawcą warto prowadzić spokojnie, jako uporządkowanie współpracy, a nie zapowiedź jej końca. Prośba o przeniesienie kont i założenie repozytorium po Waszej stronie jest uzasadniona w każdej relacji, także dobrej.

Nawet jeśli części rzeczy nie da się odzyskać, system zwykle da się przejąć. Wielokrotnie przejmowaliśmy systemy bez dokumentacji, a często nawet bez repozytorium kodu. W takiej sytuacji najpierw trzeba dobrze poznać procesy, które działają w firmie i które system wspiera, a potem w toku prac budować dokumentację od zera. Z czasem daje to dobre rezultaty. Do tego potrzeba ostrożności i zdrowego rozsądku przy każdej zmianie - w systemie, którego nikt nie opisał, każda poprawka może dotknąć czegoś, o czym nikt już nie pamięta.

Lista kontrolna

  1. Czy repozytorium kodu z pełną historią zmian jest na Waszym koncie albo macie do niego dostęp właścicielski?
  2. Czy serwery, konta chmurowe i domena są zarejestrowane na Waszą firmę?
  3. Czy istnieje aktualna dokumentacja i instrukcja uruchomienia systemu od zera?
  4. Czy kontekst, z którego korzystają narzędzia AI w zespole dostawcy, jest częścią repozytorium?
  5. Czy umowa przenosi na Was majątkowe prawa autorskie do kodu?
  6. Czy dostawca odpowiedział konkretnie na pytanie o zakończenie współpracy?

Podsumowanie

Vendor lock nie zaczyna się od podpisania złej umowy. Zaczyna się od drobnych wygód na starcie projektu, których nikt potem nie odkręca. Jedno pytanie i pięć sprawdzeń wystarczą, żeby wiedzieć, na czym stoicie - a dobry dostawca nie będzie miał nic przeciwko temu, żebyście to wiedzieli.