Pytanie brzmi banalnie, dopóki nie trzeba na nie odpowiedzieć w konkretnej sytuacji: zmiany partnera wdrożeniowego, audytu, awarii w piątek po południu albo rozmowy z nowym programistą. Wtedy okazuje się, że „nasz system" i „nasz dostęp do systemu" to dwie różne rzeczy.
Trzy rzeczy, które łatwo pomylić
W projekcie na odoo.sh własność rozkłada się na trzy warstwy i każda z nich może należeć do kogoś innego.
Subskrypcja — umowa z Odoo, na którą wystawiana jest faktura. Jeżeli figuruje na partnerze, klient nie jest stroną relacji z producentem oprogramowania.
Repozytorium kodu — Git, w którym leży cały kod projektu: moduły dedykowane, modyfikacje, historia zmian. Jeżeli należy do organizacji partnera, klient nie ma dostępu do tego, za co zapłacił.
Projekt na odoo.sh — środowiska produkcyjne, testowe i deweloperskie, kopie zapasowe, logi. To warstwa operacyjna, w której naprawdę pracuje się z systemem.
Zdarza się, że klient ma dostęp do bazy produkcyjnej jako użytkownik i uznaje sprawę za zamkniętą. To najwęższa z możliwych perspektyw — konto administratora w Odoo nie daje ani kodu, ani kopii zapasowych, ani możliwości uruchomienia systemu gdzie indziej.
Kilka zespołów przy jednym Odoo: gdzie kończy się czyja odpowiedzialność
Coraz częściej przy jednym wdrożeniu pracuje więcej niż jedna firma. Klient ma własnego programistę, drugi dostawca dowozi integrację, partner wdrożeniowy prowadzi resztę. To układ, który działa — pod warunkiem, że zanim ktokolwiek dotknie repozytorium, jest jasne, kto za co odpowiada.
Współudział jest wart zachodu
Programista po stronie klienta zna procesy lepiej niż ktokolwiek z zewnątrz. Rozumie, dlaczego dana wartość jest liczona akurat tak, i nie musi dopytywać przy każdym wyjątku. Drugi dostawca, który dowozi wąską integrację, robi to zwykle szybciej niż zespół uczący się cudzego systemu od zera.
Dochodzi trzeci efekt, mniej oczywisty: kompetencja zostaje w firmie. Po zakończeniu wdrożenia jest ktoś, kto potrafi przeczytać kod i ocenić wycenę kolejnej zmiany. To realna wartość, niezależnie od tego, kto tę zmianę wykona.
Gdzie rozmywa się odpowiedzialność
Problem nie polega na tym, że ktoś napisze zły kod. Polega na tym, że przy kilku rękach na jednym repozytorium przestaje być oczywiste, czyj był ostatni ruch.
Moduł dołożony bez wiedzy pozostałych zespołów potrafi zablokować aktualizację wersji. Zmiana w standardowym widoku, nadpisana przez czyjeś dziedziczenie, przestaje działać bez żadnego komunikatu. Pole dodane w Studio na produkcji nie istnieje w kodzie i znika przy kolejnym wdrożeniu z gałęzi.
Najbardziej kosztowna jest jednak sytuacja, w której coś przestaje działać i nikt nie potrafi wskazać momentu, od którego przestało. Diagnoza pochłania wtedy więcej czasu niż sama naprawa, a rozmowa schodzi na ustalanie winy zamiast na rozwiązanie.
Warto powiedzieć to wprost: gwarancja obejmuje kod, który przeszedł przez uzgodniony proces. Nie dlatego, że ktoś chce się uchylić, tylko dlatego, że nie da się odpowiadać za zachowanie systemu, którego stanu się nie zna.
Co ustalić, zanim zacznie się praca
- Jedna gałąź produkcyjna z ograniczonym prawem scalania. Każdy może zaproponować zmianę, wdraża ją wskazana osoba. To nie kwestia hierarchii, tylko jednego punktu kontroli.
- Prefiksy modułów per zespół. Po nazwie katalogu od razu widać, kto jest autorem i kogo pytać.
- Przegląd kodu w poprzek firm. Zmiana jednego zespołu czytana przez drugi wyłapuje konflikty, których autor nie widzi, bo nie zna drugiej połowy systemu.
- Zakaz zmian bezpośrednio na produkcji. Dotyczy również Studio. Wszystko, co ma przetrwać kolejne wdrożenie, musi być w kodzie.
- Wspólny rejestr zmian. Krótki wpis: co, po co, kto, kiedy. Dwie linijki, które później oszczędzają dwie godziny.
- Ustalone środowiska testowe. Każdy zespół ma gdzie sprawdzić swoją zmianę, zanim spotka się z cudzą.
Na koniec
Współudział klienta i innych wykonawców nie jest zagrożeniem dla wdrożenia. Zagrożeniem jest niedopowiedzenie — dostęp przyznany bez ustalenia zasad i odpowiedzialność opisana dopiero wtedy, gdy coś przestanie działać.
Te sześć punktów mieści się na jednej stronie i zajmuje jedno spotkanie. Kosztuje mniej niż pierwsza awaria, przy której trzeba będzie odtwarzać, co się właściwie wydarzyło.