Kustomizacja vs unifikacja procesów

Zaczyna się to tak — kilka zespołów niezależnie wymyśla sobie proces dostosowany do ich potrzeb i znajduje/tworzy narzędzia, którymi ten proces automatyzuje. Zazwyczaj jest to proces code review, budowania kodu, system CI, system do dzielenia się wiedzą, zarządzania sprzętem, czy wreszcie jakieś rozwiązanie do efektywnej wewnątrz-zespołowej komunikacji (co w czasach COVIDu jest nam bardziej niż bliskie).

Każdy zespół z osobna zajmuje się utrzymaniem własnych narzędzi, co na ogół kończy się tym, że jest jedna lub dwie osoby, które “ogarniają jak to działa”. Po jakimś czasie ktoś (na ogół jakiś manager) wpada na pomysł, że może efektywniej by było utworzyć osobny mini-zespół, który zajmowałby się utrzymywaniem tych systemów. Wszyscy z entuzjazmem przyjmują ten pomysł, bo w ten sposób zostają odciążeni, a w międzyczasie nowo utworzony mini-zespół szybko dochodzi do wniosku, że unifikacja użytych narzędzi pozwoliłaby na znaczną redukcję kosztów. 

Unifikacja jest już mniej entuzjastycznie przyjęta przez zespoły, bo nowe, generyczne rozwiązanie w mniejszym stopniu adresuje ich potrzeby, ale cięcie kosztów jest na tyle atrakcyjne dla managementu, że, tak czy owak, wdrożenie nowych narzędzi i procesów zostaje przeforsowane. W takiej sytuacji zespoły mają dwa wyjścia — akceptacja rozwiązań, które są gorzej dostosowane do ich potrzeb, albo wyłamanie się i tworzenie czegoś customowego na własną rękę. I tu się koło zamyka.

Część zespołów pójdzie pierwszą ścieżką, bo nowe rozwiązanie nie będzie odbiegać aż tak bardzo od tego, czego używali do tej pory, ale co najmniej kilka innych pójdzie w kierunku customizacji niektórych procesów. Po jakimś czasie management zorientuje się, że zespołom znów przydałaby się pomoc z utrzymaniem narzędzi, a mini-zespół supportujący, który zdążył się już przerodzić w ministerstwo unifikacji, bardzo szybko znów robi swoje.

Efektem tego zjawiska jest niekończący się cykl naprzemiennej customizacji i unifikacji, gdzie w obu fazach koszt ponoszą same zespoły. Gdyby tylko istniało lepsze rozwiązanie…

Ministerstwo customizacji

Stojąc przed wyborem “customizacja czy unifikacja? ” warto zadać sobie pytanie “ dlaczego nie oba na raz?”. Część procesów i narzędzi da się z dużym sukcesem zunifikować. Przynajmniej do takiego stopnia, żeby większość zespołów mogła je ze sobą współdzielić. Natomiast tam, gdzie customowe rozwiązania okażą się znacznie lepsze, można po prostu odpuścić unifikację. 

Brzmi to aż za prosto, prawda? I słusznie, bo jest tu mały haczyk.

Zarówno w unifikacji jak i w customizacji może pomóc zespół supportujący, ale powstaje wewnętrzny konflikt interesów, kiedy ten sam zespół zajmuje się obiema rzeczami na raz. W końcu trudno jest być jednocześnie adwokatem dwóch przeciwstawnych koncepcji

Rozwiązaniem jest utworzenie jeszcze jednego zespołu supportującego, który zajmowałby się wyłącznie tematem customizacji. Tam, gdzie unifikacja się nie sprawdza, wchodzi customizacja i robi rozwiązania szyte na miarę.

Czy takie rozwiązanie nie jest droższe?

Na pewno jest droższe w excellowych tabelkach, gdzie nie widać faktycznych kosztów ponoszonych przez zespoły, które zmuszone są korzystać z niedostosowanych procesów i narzędzi albo robić swoje własne “pod dywanem”. W praktyce takie rozwiązanie pomaga robić to, co powinna robić każda organizacja, żeby pomóc inżynierom skuteczniej wykonywać swoją pracę — nie przeszkadzać.