Do zespołu weszło dwóch inżynierów DevOps. Rekrutacja zajęła jedenaście dni roboczych, obaj mieli dokładnie te kompetencje, o które prosiliście, obaj zaczęli w poniedziałek. Miesiąc później nie wdrożyli na produkcję niczego.
Nie dlatego, że byli słabi. Dlatego, że przez ten miesiąc nikt nie podjął decyzji, czy wolno im dotknąć produkcji — a każde zadanie, które im dawaliście, kończyło się w tym samym miejscu: przygotowaną zmianą czekającą, aż ktoś z waszego zespołu ją zatwierdzi i uruchomi.
Nazywam się Bartosz Ciepierski, kieruję ARDURA Consulting i przez lata pracy przy pozyskiwaniu specjalistów IT widziałem ten scenariusz częściej niż jakikolwiek inny problem tego modelu. Dlatego ten tekst nie jest kolejnym przewodnikiem o tym, kogo zatrudnić. Jest o jednej tezie, z którą kompetentny czytelnik ma pełne prawo się nie zgodzić: w augmentacji DevOps wąskim gardłem prawie nigdy nie są ręce ani kompetencje, tylko uprawnienia — a czas do wartości jest funkcją opóźnienia nadania dostępu, nie czasu rekrutacji.
Jeśli szukacie odpowiedzi na inne pytania z tego obszaru, mamy je opisane osobno i celowo nie powtarzam ich tutaj. O tym, w jakiej kolejności obsadzać role w zespole DevOps, jest tekst o strukturze zespołu DevOps. O tym, które kompetencje najlepiej sprawdzają się w tym modelu współpracy — kompetencje w Staff Augmentation. O warstwie kulturowej i roli lidera — budowanie kultury DevOps. Tutaj jest o czymś, czego nie ma w żadnym z nich: o momencie, w którym ktoś w waszej organizacji musi powiedzieć „tak, ta osoba spoza firmy może zmienić konfigurację systemu produkcyjnego” — i o wszystkim, co trzeba rozstrzygnąć, zanim to zdanie padnie.
Dlaczego zespół, który dostał dwóch inżynierów, nadal nie wdraża szybciej?
Zacznijmy od diagnozy, bo to ona decyduje o wszystkim, co dalej.
Kiedy dział inżynierii mówi „nie nadążamy z wdrożeniami”, ma na myśli jedno z trzech zjawisk, a każde wymaga innej reakcji. Pierwsze to deficyt zdolności: pracy jest po prostu więcej, niż zespół zdąży wykonać, wszyscy wiedzą co robić, wszyscy mają dostęp, brakuje godzin. Drugie to deficyt kompetencji: zespół wie, co ma osiągnąć, ale nikt nie robił tego wcześniej — nie ma doświadczenia z operatorami Kubernetes, z siatką usług, z migracją stanu Terraform między kontami. Trzecie to deficyt decyzyjności: praca jest gotowa, kompetencje są, ale zmiana czeka na zgodę, której nikt nie chce wydać.
Augmentacja rozwiązuje pierwsze i drugie. Trzeciego nie rozwiązuje w ogóle — i tu jest sedno problemu, bo w organizacjach o wysokim rygorze zgodności trzecie zjawisko jest zwykle dominujące, a bywa mylone z pierwszym. Objaw jest identyczny: zaległości rosną, wdrożenia się opóźniają, zespół pracuje wieczorami. Przyczyna jest odwrotna.
Test rozstrzygający jest prosty i zajmuje jedno popołudnie. Weźcie dziesięć ostatnich zmian, które trafiły na produkcję, i dla każdej policzcie dwie wartości: ile czasu upłynęło od pierwszej linii kodu do momentu, w którym zmiana była gotowa do wdrożenia, oraz ile czasu upłynęło od tej gotowości do faktycznego wdrożenia. Jeżeli druga liczba jest systematycznie większa od pierwszej, macie deficyt decyzyjności, a nie zdolności. Dokładanie ludzi wydłuży pierwszy odcinek pracy i nie ruszy drugiego.
To ten sam mechanizm, który w klasycznej teorii ograniczeń opisuje się jednym zdaniem: zwiększanie wydajności czegoś, co nie jest ograniczeniem, jest złudzeniem, nie usprawnieniem. W praktyce augmentacji DevOps ograniczeniem jest zwykle brama uprawnień — a ona nie ma nic wspólnego z liczbą osób po jednej ani po drugiej stronie.
Warto dodać, że te trzy deficyty potrafią współistnieć, a wtedy kolejność ich adresowania decyduje o wyniku. Zespół z deficytem zdolności i decyzyjności naraz, który najpierw dokłada ludzi, zobaczy pogorszenie: nowe osoby generują zmiany szybciej, niż brama zgód potrafi je przepuścić, więc zaległości w kolejce akceptacji rosną, a razem z nimi rośnie liczba konfliktów przy scalaniu i ryzyko, że zmiana zaakceptowana po dwóch tygodniach dotyczy już nieaktualnego stanu systemu. Ta sama para deficytów zaadresowana w odwrotnej kolejności — najpierw brama, potem ręce — daje efekt złożony, bo dołożone zdolności trafiają na przepustowość, która je przyjmie.
Co właściwie mierzycie, mówiąc „czas do pierwszego dnia”?
Rynek usług augmentacji mierzy się czasem obsadzenia. To liczba, którą dostawcy podają w ofertach, bo jest pod ich kontrolą i dobrze wypada w porównaniu z rekrutacją wewnętrzną. Dla typowych profili DevOps liczy się ją w dniach roboczych: brief, prezentacja kandydatów, rozmowy, decyzja, start.
Problem w tym, że dla kupującego ta liczba nie jest odpowiedzią na jego pytanie. Kupujący nie potrzebuje, żeby ktoś przyszedł. Potrzebuje, żeby ktoś zaczął zmieniać rzeczywistość. Między jednym a drugim leży odcinek, którego nikt nie mierzy i który proponuję nazywać wprost: opóźnienie nadania uprawnień — czas od pierwszego dnia pracy do pierwszej samodzielnie wykonanej zmiany, która dotknęła środowiska produkcyjnego.
Ten odcinek składa się z rzeczy, które nie są techniczne i dlatego umykają planowaniu:
- ustalenie, czy w środowisku docelowym są dane osobowe, a jeśli tak, na jakiej podstawie zewnętrzny inżynier może je przetwarzać,
- podpisanie lub aneksowanie umowy powierzenia przetwarzania z podmiotem, przez który dana osoba pracuje, wraz ze zgodą na dalsze powierzenie,
- decyzja właściciela biznesowego systemu, że akceptuje dostęp podmiotu zewnętrznego,
- rejestracja tożsamości w katalogu firmowym, wpięcie do logowania jednokrotnego, wydanie sprzętu albo dopuszczenie sprzętu własnego,
- nadanie ról w konsoli chmurowej i w systemie zarządzania sekretami, zwykle przez inny zespół i w innym rytmie pracy,
- szkolenie z zasad bezpieczeństwa i potwierdzenie zapoznania się z politykami.
Każdy z tych punktów osobno wygląda na formalność jednodniową. Ustawione szeregowo, w organizacji, w której każdy krok obsługuje inny zespół z własną kolejką, dają tygodnie. I to jest liczba, którą płacicie stawką dzienną, bo umowa biegnie od pierwszego dnia, a nie od pierwszego dostępu.
Rada praktyczna, która nic nie kosztuje: zmierzcie tę liczbę wstecznie dla ostatniej osoby, która dołączyła do waszego zespołu z zewnątrz. Jeśli wyszło więcej niż pięć dni roboczych, macie tam ukryty koszt większy niż jakakolwiek różnica w stawkach, o którą będziecie negocjować.
Jak wygląda drabina uprawnień produkcyjnych i gdzie kończy się większość kontraktorów?
Rozmowa o dostępie jest zwykle prowadzona zero-jedynkowo: „ma dostęp do produkcji” albo „nie ma”. To za grube rozróżnienie, żeby cokolwiek nim zaplanować. W praktyce mamy pięć wyraźnie różnych poziomów i to, na którym z nich zatrzyma się wasz kontraktor, przesądza o tym, jakie zadania da mu się w ogóle powierzyć.
Poziom 0 — obserwator. Dostęp do repozytoriów, dokumentacji i systemu zadań. Może czytać kod i pisać propozycje zmian. Nie widzi żadnego środowiska uruchomieniowego. Może przygotować analizę, projekt architektury, przegląd konfiguracji.
Poziom 1 — telemetria. Dodatkowo wgląd w metryki, logi i ślady z produkcji, bez możliwości zmiany czegokolwiek. To poziom, na którym da się prowadzić realną diagnostykę wydajności i uczestniczyć w analizie po awarii. Zaskakująco dużo wartościowej pracy DevOps mieści się właśnie tutaj — i zaskakująco często ten poziom jest nadawany dopiero w trzecim tygodniu, mimo że nie niesie prawie żadnego ryzyka.
Poziom 2 — środowiska nieprodukcyjne. Pełne prawa do środowisk deweloperskich i przejściowych. Może budować, psuć i naprawiać. Tutaj powstaje większość kodu infrastruktury.
Poziom 3 — wdrożenie przez potok. Może uruchomić wdrożenie na produkcję, ale wyłącznie ścieżką zautomatyzowaną, z wymaganą akceptacją zmiany. Nie ma dostępu bezpośredniego do maszyn ani do konsoli z prawami zapisu. To jest poziom, który powinien być domyślnym celem dla augmentowanego inżyniera i który w większości organizacji da się nadać bezpiecznie.
Poziom 4 — dostęp bezpośredni. Prawa administracyjne w konsoli chmurowej, powłoka na maszynach produkcyjnych, możliwość działania poza potokiem. Poziom potrzebny do dyżurów i do reagowania na awarie. Nadawany rzadko, zwykle czasowo i z podniesieniem uprawnień na żądanie.
Większość kontraktorów zatrzymuje się na poziomie 2, a organizacja jest przekonana, że kupiła kogoś działającego na poziomie 3 lub 4. Rozjazd ujawnia się na pierwszym incydencie: człowiek, którego wzięliście po to, żeby skrócić czas przywrócenia sprawności, nie może się zalogować do systemu, który trzeba naprawić.
Dlaczego ten rozjazd jest tak trwały? Bo nikt go nie widzi w codziennej pracy. Na poziomie 2 kontraktor jest produktywny, commituje, jego zmiany trafiają do gałęzi głównej i wszystko wygląda normalnie — ostatni krok wykonuje ktoś inny i wykonuje go tak rutynowo, że przestaje to być zauważalne. Rozjazd ujawnia się dopiero w sytuacji, w której tego kogoś nie ma: w nocy, w weekend, w trakcie urlopu. Dlatego proponuję prosty test, który można przeprowadzić w dowolny wtorek: poproście kontraktora, żeby wykonał rutynowe wdrożenie sam, i zmierzcie, ile osób musiał o coś poprosić. Jeżeli odpowiedź brzmi „ani jednej”, jest na poziomie 3. Jeżeli brzmi „dwie”, jest na poziomie 2 i płacicie za pracę, którą i tak wykonuje wasz zespół.
Które zadania da się oddać na poziomie 1, a które wymagają poziomu 4?
To jest pytanie, które warto zadać przed briefem, bo odpowiedź często zmienia sam brief.
Na poziomie 0–1 mieści się więcej, niż zakłada się intuicyjnie: audyt konfiguracji chmurowej pod kątem kosztów i bezpieczeństwa, projekt docelowej architektury potoku, przegląd modułów Terraform, analiza wąskich gardeł wydajnościowych na podstawie telemetrii, przygotowanie zestawu wskaźników poziomu usług, napisanie dokumentacji operacyjnej, opracowanie planu migracji. Jeżeli wasze opóźnienie nadania uprawnień wynosi sześć tygodni, to jest dokładnie ta praca, którą można wykonać w międzyczasie zamiast płacić za czekanie.
Poziom 2 obejmuje główny ciężar wytwórczy: budowa potoków, konteneryzacja aplikacji, przygotowanie kart Helm, konfiguracja monitorowania, wprowadzenie zarządzania sekretami — o którym pisaliśmy szerzej w tekście o zarządzaniu hasłami i kluczami w potokach CI/CD — oraz testy odtworzeniowe infrastruktury.
Poziom 3 to wykonanie: przeprowadzanie wdrożeń, migracje wykonywane oknami serwisowymi, zmiany konfiguracji w środowisku żywym. Poziom 4 to wyłącznie dyżury i reagowanie na incydenty.
Praktyczny wniosek jest taki, że brief powinien deklarować poziom docelowy i datę, do której zostanie osiągnięty, a nie tylko listę technologii. Zdanie „szukamy inżyniera Kubernetes na sześć miesięcy” nie mówi nic o wartości, którą uda się dostarczyć. Zdanie „szukamy inżyniera Kubernetes, który od dnia szóstego działa na poziomie 2, a od dnia dwudziestego na poziomie 3” jest kontraktem, który da się rozliczyć — i, co ważniejsze, wymusza po waszej stronie decyzje, które inaczej nie zapadłyby wcale.
Dlaczego forma zatrudnienia zmienia to, co wolno wam nadać?
Tu wchodzimy w warstwę, której nie ma w anglojęzycznych przewodnikach o staff augmentation, bo struktura zatrudnienia w polskim IT wygląda inaczej niż na rynkach, z których te przewodniki pochodzą. U nas ta sama praca może być wykonywana w co najmniej trzech różnych reżimach prawnych, a każdy z nich inaczej ustawia to, co wolno wam zrobić.
Pracownik dostawcy na umowie o pracę, oddelegowany do was. Najprostszy przypadek z punktu widzenia praw do kodu, o czym za chwilę. Kierownictwo formalnie sprawuje jego pracodawca, wy wyznaczacie zadania merytoryczne.
Współpraca B2B. Dominujący model dla ról DevOps o wyższym stażu. Inżynier jest odrębnym przedsiębiorcą i to zmienia trzy rzeczy naraz: podstawę przetwarzania danych osobowych, mechanizm przejścia praw autorskich oraz ryzyko przekwalifikowania relacji. To ostatnie warto rozumieć precyzyjnie: Kodeks pracy nie pozwala zastąpić umowy o pracę umową cywilnoprawną przy zachowaniu warunków charakterystycznych dla stosunku pracy — pracy określonego rodzaju wykonywanej pod kierownictwem, w miejscu i czasie wyznaczonym. Im ściślej wpinacie kontraktora w swoją hierarchię, grafik i system ocen, tym bardziej zbliżacie się do tej granicy.
Praca tymczasowa przez agencję. Odrębny reżim, z własnymi limitami — kluczowy jest limit łącznego okresu wykonywania pracy tymczasowej na rzecz jednego pracodawcy użytkownika, wynoszący osiemnaście miesięcy w okresie kolejnych trzydziestu sześciu miesięcy. Dla długich programów transformacyjnych to twarda granica, którą trzeba zaplanować z góry, a nie odkryć w siedemnastym miesiącu.
Konsekwencja praktyczna dla uprawnień jest następująca: forma współpracy determinuje, jaki dokument musi istnieć, zanim nadacie dostęp do danych produkcyjnych. Przy pracowniku dostawcy będzie to zwykle umowa powierzenia zawarta z dostawcą. Przy B2B trzeba prześledzić cały łańcuch — czy inżynier jest podprzetwarzającym dostawcy, czy odrębnym przetwarzającym po waszej stronie — i czy macie zgodę na dalsze powierzenie. To nie jest formalność do wypełnienia po fakcie; to warunek, bez którego nadanie dostępu jest naruszeniem, niezależnie od tego, jak sprawnie działa wasza konsola uprawnień.
Kto jest właścicielem kodu infrastruktury napisanego przez kontraktora?
To pytanie zadaje się zwykle na koniec współpracy, kiedy jest już za późno, żeby na nie dobrze odpowiedzieć.
Polskie prawo autorskie traktuje program komputerowy szczególnie: jeżeli powstał w wyniku wykonywania obowiązków ze stosunku pracy, autorskie prawa majątkowe przysługują pracodawcy, o ile umowa nie stanowi inaczej. To wygodny mechanizm — działa sam, bez dodatkowych dokumentów. Przy współpracy B2B ten mechanizm nie działa. Prawa zostają przy twórcy i przechodzą na was wyłącznie na podstawie umowy, która dla przeniesienia autorskich praw majątkowych wymaga formy pisemnej pod rygorem nieważności i musi wymieniać pola eksploatacji wprost. Umowa milcząca w tej sprawie oznacza, że praw nie nabyliście.
Dlaczego to szczególnie boli w DevOps? Bo tutaj wytwarza się głównie kod, który nie wygląda na kod dla osób podpisujących umowy: moduły Terraform, karty Helm, definicje potoków w plikach konfiguracyjnych, skrypty operacyjne, reguły alertowania, szablony infrastruktury. Wszystko to są utwory. Organizacja, która po zakończeniu sześciomiesięcznego kontraktu odkrywa, że nie ma pisemnego przeniesienia praw do własnej infrastruktury jako kodu, ma problem, którego nie da się naprawić technicznie.
Do tego dochodzą dwie pozycje, o których warto pamiętać przy podpisywaniu:
- zależne prawa autorskie — zgoda na wykonywanie i zezwalanie na wykonywanie praw zależnych, czyli po ludzku: czy wolno wam ten kod dalej modyfikować i czy wolno wam zlecić modyfikację komuś innemu,
- licencje składników otwartych wciągniętych do modułów — ich warunki obowiązują niezależnie od waszej umowy z kontraktorem i potrafią nałożyć obowiązki na produkt, w którym zostaną użyte.
Najbardziej kosztowna wersja tego problemu nie polega zresztą na sporze sądowym, bo do niego dochodzi rzadko. Polega na tym, co dzieje się przy sprzedaży spółki, przy rundzie finansowania albo przy audycie przed dużym kontraktem: kupujący pyta o tytuł prawny do warstwy technologicznej, a wy nie potraficie wskazać dokumentu obejmującego moduły, na których stoi całe wasze środowisko. Odtworzenie tego tytułu po latach wymaga odnalezienia kilkunastu osób, które od dawna nie pracują dla was ani dla waszego dostawcy, i uzyskania od każdej z nich podpisu na dokumencie, którego nie ma obowiązku podpisać. To jest właśnie moment, w którym pominięta klauzula okazuje się droższa niż cały kontrakt, w ramach którego powstał kod.
Praktyczny wniosek: klauzula o przeniesieniu praw z wyliczonymi polami eksploatacji i zgodą na prawa zależne powinna być elementem umowy ramowej z dostawcą, weryfikowanym raz, a nie negocjowanym przy każdym inżynierze. To jest dokładnie ten rodzaj pracy, który wykonuje się przed briefem, bo później konkuruje o czas z zadaniami merytorycznymi i zawsze przegrywa.
Co NIS2 i przepisy o cyberbezpieczeństwie zmieniają w podwykonawstwie?
Dyrektywa NIS2 rozszerzyła krąg podmiotów objętych obowiązkami w zakresie cyberbezpieczeństwa i — co dla naszego tematu najważniejsze — wprost wymienia bezpieczeństwo łańcucha dostaw jako jeden z obowiązkowych środków zarządzania ryzykiem. Termin transpozycji upływał 17 października 2024 roku, a w Polsce wdrożenie następuje przez nowelizację ustawy o krajowym systemie cyberbezpieczeństwa.
Dla organizacji korzystającej z augmentacji oznacza to zmianę jakościową, nie tylko kolejny dokument. Do tej pory dostęp podmiotu zewnętrznego do systemów był kwestią wewnętrznej polityki. Teraz w podmiotach objętych regulacją staje się elementem zarządzania ryzykiem, który trzeba udokumentować, przeglądać i umieć pokazać — łącznie z tym, kto ma jakie uprawnienia, na jakiej podstawie i kiedy były weryfikowane po raz ostatni.
Praktyczne konsekwencje, które warto wbudować w proces, zanim ktoś o nie zapyta:
- rejestr dostępów zewnętrznych prowadzony jako element systemu zarządzania, a nie jako lista w arkuszu — z datą nadania, zakresem, uzasadnieniem i datą przeglądu,
- uprawnienia czasowe zamiast bezterminowych — konto kontraktora z rolą wygasającą automatycznie jest znacznie łatwiejsze do obrony niż konto, które trzeba pamiętać, żeby odebrać,
- rozliczalność działań — logowanie operacji wykonanych z tożsamości zewnętrznej w sposób pozwalający je odtworzyć,
- klauzule bezpieczeństwa w umowie z dostawcą, w tym obowiązek zgłaszania incydentów po jego stronie i prawo do weryfikacji.
Warto zauważyć, że wszystkie te wymogi działają w tę samą stronę co teza tego tekstu. Organizacja, która ma uporządkowany proces nadawania i odbierania dostępu, jednocześnie skraca opóźnienie nadania uprawnień i spełnia obowiązek regulacyjny. Organizacja, która tego procesu nie ma, płaci dwa razy: czasem oczekiwania i ryzykiem zgodności.
Jak wygląda checklist nadania dostępu, który da się przejść w pięć dni roboczych?
Poniższa lista jest ułożona według jednej zasady: wszystko, co nie wymaga obecności konkretnej osoby, dzieje się przed jej pierwszym dniem. To jedyny sposób, żeby zmieścić się w pięciu dniach.
Przed briefem — raz na dostawcę, nie na osobę:
- umowa ramowa z klauzulą przeniesienia autorskich praw majątkowych, wyliczonymi polami eksploatacji i zgodą na prawa zależne,
- umowa powierzenia przetwarzania z zapisem o dalszym powierzeniu, jeżeli inżynierowie pracują przez podmioty zależne,
- klauzule bezpieczeństwa: zgłaszanie incydentów, zakaz przenoszenia danych poza uzgodnione środowiska, zasady dotyczące sprzętu,
- uzgodniony wzorzec ról dostępowych dla kontraktora, przygotowany razem z zespołem bezpieczeństwa i zatwierdzony na poziomach 0–3.
Dni -5 do -1 — po decyzji o konkretnej osobie:
- utworzenie tożsamości w katalogu firmowym i wpięcie do logowania jednokrotnego,
- przypisanie do grup odpowiadających poziomom 0 i 1, z datą wygaśnięcia,
- przydzielenie opiekuna po waszej stronie — jednej osoby, nie zespołu,
- przygotowanie środowiska roboczego i dostępu do repozytoriów.
Dzień 1–2: szkolenie z polityk, potwierdzenie zapoznania, pierwsze zadanie na poziomie 1 — diagnostyczne, bez zmian.
Dzień 3–5: podniesienie do poziomu 2, pierwsza zmiana w środowisku przejściowym, przegląd kodu wykonany przez waszego inżyniera.
Dzień 6–20: podniesienie do poziomu 3 po spełnieniu warunku wejścia uzgodnionego z góry — na przykład po trzech zmianach zaakceptowanych bez uwag krytycznych.
To, co robi tę listę wykonalną, to punkty 1–4. Jeżeli są gotowe, reszta jest pracą administracyjną, którą da się zrównoleglić. Jeżeli nie są, żadna sprawność operacyjna nie pomoże, bo prawnik i inspektor ochrony danych mają własne kolejki. Szerzej o samym procesie wprowadzania kontraktora do zespołu pisaliśmy w tekście o onboardingu specjalistów zewnętrznych.
Jak wygląda mapa dojrzałości nadawania uprawnień?
Poniższa tabela jest narzędziem do samooceny. Warto ją przejść przed pierwszym briefem, bo poziom, na którym jesteście, przewiduje opóźnienie nadania uprawnień lepiej niż jakikolwiek inny wskaźnik.
| Poziom | Jak wygląda nadawanie dostępu | Typowe opóźnienie | Co realnie kupujecie | Pierwszy krok do awansu |
|---|---|---|---|---|
| 0 — reaktywny | Każdy dostęp to osobna prośba w systemie zgłoszeń, rozpatrywana indywidualnie; nie ma wzorca dla kontraktora | 4–8 tygodni | Analizy i dokumentację; wykonanie zostaje po waszej stronie | Spisać, kto faktycznie zatwierdza dostęp do produkcji — zwykle okazuje się, że nikt tego nie wie |
| 1 — udokumentowany | Istnieje pisemna procedura, ale wykonywana ręcznie, kroki sekwencyjne | 3–5 tygodni | Pracę na środowiskach nieprodukcyjnych | Zrównoleglić kroki, które nie zależą od siebie |
| 2 — powtarzalny | Jest wzorzec ról dla kontraktora, zatwierdzony raz; umowy ramowe gotowe | 5–10 dni | Wykonanie przez potok, z akceptacją zmiany | Wprowadzić daty wygaśnięcia zamiast ręcznego odbierania |
| 3 — zautomatyzowany | Role nadawane z katalogu, czasowo, na podstawie przypisania w systemie kadrowym | 1–3 dni | Pełny udział w cyklu wytwórczym | Dodać podnoszenie uprawnień na żądanie dla poziomu 4 |
| 4 — samoobsługowy | Uprawnienia podnoszone na żądanie, z uzasadnieniem i automatycznym wygaszaniem; pełna rozliczalność | godziny | Udział w dyżurach i reagowaniu na incydenty | Utrzymać — i przeglądać rejestr, bo to jest dowód zgodności |
Trzy obserwacje do tej tabeli.
Po pierwsze, awans o jeden poziom jest zwykle tańszy niż różnica w stawkach, o którą negocjujecie. Przejście z poziomu 1 na 2 to praca prawna i konfiguracyjna wykonywana raz, a oszczędza dwa–trzy tygodnie stawki dziennej przy każdym kolejnym inżynierze.
Po drugie, poziom nie jest cechą technologii, tylko organizacji. Widziałem firmy z bardzo nowoczesnym stosem technologicznym na poziomie 0, bo decyzja o dostępie zewnętrznym wymagała u nich akceptacji zarządu.
Po trzecie, poziomy 3 i 4 są jednocześnie odpowiedzią na wymogi regulacyjne opisane wyżej. To rzadki przypadek, w którym zgodność i sprawność operacyjna ciągną w tę samą stronę — warto to wykorzystać w rozmowie o budżecie.
Kiedy augmentacja DevOps jest złą odpowiedzią na dobre pytanie?
Uczciwość wymaga wskazania przypadków, w których ten model nie zadziała, niezależnie od tego, jak dobrze przygotujecie uprawnienia.
Gdy ograniczeniem jest decyzyjność. Opisane na początku. Dodanie osoby do kolejki oczekujących na zgodę wydłuża kolejkę.
Gdy nie macie po swojej stronie nikogo, kto oceni jakość. Augmentacja zakłada, że kierownictwo merytoryczne zostaje u was. Bez waszego lidera technicznego kupujecie kod, którego nikt nie recenzuje, i dowiadujecie się o jego jakości przy pierwszej awarii. Jeżeli takiej osoby nie ma, właściwym modelem jest usługa zarządzana z odpowiedzialnością za rezultat, a nie augmentacja.
Gdy zadanie zależy od wiedzy niejawnej. Migracja systemu, którego nikt nie udokumentował przez dziesięć lat, nie jest zadaniem dla nowej osoby, choćby najlepszej. Najpierw kupujecie czas osoby, która ten system zna, na przekazanie wiedzy — a dopiero potem ręce.
Gdy potrzeba jest trwała i przewidywalna. Jeżeli wiecie, że przez najbliższe trzy lata będziecie potrzebować dwóch inżynierów platformy w pełnym wymiarze, rachunek kosztu posiadania wychodzi na korzyść etatu. Augmentacja jest narzędziem na zmienność i na czas, w którym jeszcze nie wiecie, czy potrzeba jest trwała.
Gdy jedynym celem jest cięcie kosztów. Ten model kupuje szybkość i elastyczność, nie oszczędność. Kto oczekuje oszczędności, zwykle liczy niepełny rachunek — i zawiedzie się w trzecim miesiącu.
Jak liczyć koszt, żeby nie porównywać stawki dziennej do pensji?
Najczęstszy błąd w tej rozmowie ma postać jednego zdania: „to prawie dwa razy tyle, co pensja naszego inżyniera”. Zdanie jest prawdziwe i bezużyteczne, bo zestawia dwie wielkości, które nie są porównywalne.
Po stronie etatu do wynagrodzenia trzeba dodać obciążenia po stronie pracodawcy, płatne nieobecności, koszt stanowiska i narzędzi, koszt rekrutacji rozłożony na spodziewany czas zatrudnienia oraz koszt wakatu — czyli tego, że przez czas rekrutacji praca po prostu nie jest wykonywana. Po stronie kontraktu dochodzi marża dostawcy i utrata ciągłości wiedzy po zakończeniu współpracy. Pełne porównanie kosztu posiadania rozpisaliśmy osobno w tekście o body leasingu wobec rekrutacji wewnętrznej, a punkty odniesienia dla stawek — w benchmarkingu stawek body leasingu.
Do tego rachunku proponuję dopisać pozycję, której nie ma w żadnym arkuszu, a która wynika wprost z tezy tego tekstu: koszt opóźnienia nadania uprawnień. Liczy się go trywialnie — stawka dzienna razy liczba dni, w których opłacany inżynier nie miał dostępu pozwalającego wykonać powierzone zadanie. Przy dwóch inżynierach i trzech tygodniach oczekiwania na poziom 2 mówimy o trzydziestu opłaconych dniach roboczych, w których kupowaliście analizy zamiast wykonania.
I jeszcze jedna pozycja, po drugiej stronie bilansu: wartość niewykonanej pracy. Jeżeli opóźnione wdrożenie funkcji kosztuje was przychód, ten koszt trzeba postawić obok stawki, bo to on jest właściwym mianownikiem decyzji. Porównywanie stawki dziennej do pensji odpowiada na pytanie „ile to kosztuje”. Porównywanie stawki do kosztu opóźnienia odpowiada na pytanie „czy warto” — a to jest pytanie, które faktycznie zadajecie.
Co zrobić w pierwszym tygodniu, żeby nie stracić trzeciego?
Zamiast ogólnych zaleceń — konkretny plan pierwszych pięciu dni, pisany z założeniem, że punkty 1–4 checklisty macie już gotowe.
Dzień 1. Opiekun po waszej stronie przechodzi z nową osobą architekturę systemu i mapę własności: kto odpowiada za który komponent i kto zatwierdza w nim zmiany. To spotkanie zastępuje dwa tygodnie zgadywania. Równolegle uruchamiacie dostęp na poziomie 1 — telemetria, logi, ślady.
Dzień 2. Pierwsze zadanie diagnostyczne, wykonalne na poziomie 1 i mające realną wartość: przegląd najkosztowniejszych zapytań, analiza czasów wdrożeń z ostatniego kwartału, audyt konfiguracji uprawnień w chmurze. Efektem jest dokument, nie zmiana. To zadanie ma dwie funkcje — daje wartość natychmiast i pokazuje wam, jak ta osoba myśli, zanim dostanie prawa zapisu.
Dzień 3. Podniesienie do poziomu 2 i pierwsza zmiana w środowisku przejściowym, mała i odwracalna. Przegląd kodu wykonuje wasz inżynier, nie po to, żeby kontrolować, tylko żeby uzgodnić konwencje.
Dzień 4. Uzgodnienie warunku wejścia na poziom 3: co konkretnie musi się wydarzyć, żeby ta osoba wdrażała samodzielnie. Warunek zapisany, z datą. Brak tego zapisu jest głównym powodem, dla którego kontraktorzy zostają na poziomie 2 do końca kontraktu.
Dzień 5. Pierwszy pomiar: ile z zaplanowanych na ten tydzień zadań udało się wykonać, a ile utknęło na braku dostępu. Jeżeli utknęło więcej niż jedno, w przyszłym tygodniu priorytetem nie jest praca merytoryczna, tylko domknięcie ścieżki uprawnień.
Ten plan działa, bo odwraca domyślną kolejność. Zwykle najpierw daje się zadania, a dostęp załatwia się w miarę potrzeb — czyli reaktywnie, po jednym zgłoszeniu na raz, z pełnym opóźnieniem każdego z nich. Tutaj poziom dostępu jest planowany z góry, a zadania są dobierane do poziomu, który już jest.
Jakie są kluczowe wnioski?
Teza tego tekstu brzmiała: w augmentacji DevOps wąskim gardłem nie są ręce, tylko uprawnienia. Podsumujmy, co z niej wynika praktycznie.
Mierzcie dwa odcinki, nie jeden. Czas obsadzenia jest liczbą dostawcy. Opóźnienie nadania uprawnień jest waszą liczbą i to ona decyduje o tym, kiedy zaczniecie dostawać wartość. Jeżeli mierzycie tylko pierwszą, optymalizujecie odcinek, który i tak jest krótszy.
Diagnozujcie deficyt przed briefem. Deficyt zdolności i kompetencji augmentacja leczy. Deficytu decyzyjności nie leczy i próba pogarsza sprawę.
Projektujcie poziom dostępu, nie tylko profil kompetencji. Brief deklarujący poziom docelowy z datą wymusza po waszej stronie decyzje, które inaczej nie zapadną — i daje kontrakt możliwy do rozliczenia.
Załatwcie warstwę prawną raz, na poziomie umowy ramowej. Przeniesienie autorskich praw majątkowych w formie pisemnej z wyliczonymi polami eksploatacji, zgoda na prawa zależne, umowa powierzenia z zapisem o dalszym powierzeniu, klauzule bezpieczeństwa wynikające z przepisów o cyberbezpieczeństwie. Wykonane raz — działa dla każdego kolejnego inżyniera. Wykonywane przy każdym z osobna — jest stałym podatkiem od szybkości.
Awansujcie o jeden poziom dojrzałości zamiast negocjować stawkę. To zwykle większa oszczędność i, w odróżnieniu od negocjacji, działa również następnym razem.
Jeżeli chcecie zacząć od jednej liczby, zacznijcie od tej: ile dni upłynęło między pierwszym dniem pracy a pierwszą samodzielną zmianą na produkcji u ostatniej osoby, która dołączyła do was z zewnątrz. Ta liczba powie wam o waszym potencjale wzrostu w tym modelu więcej niż jakikolwiek przegląd rynku.
W ARDURA Consulting pracujemy przy takich uruchomieniach od strony dostawcy i od strony organizacji przyjmującej, więc widzimy obie kolejki naraz. Jeżeli chcecie sprawdzić, gdzie w waszym przypadku jest ograniczenie — zobaczcie dostępnych ekspertów albo napiszcie do nas przez formularz kontaktowy. Rozmowę zaczniemy od mapy uprawnień, a nie od życiorysów; jeśli okaże się, że ograniczeniem nie są ręce, powiemy to wprost.