„Pożyczymy dziesięć osób na cztery miesiące, a potem je oddamy”. To jedno zdanie w planie mocy przerobowych sprowadza zysk z AI z powrotem do zera.
Wdrożenie AI w firmie to nie projekt z datą zakończenia. Celowo nazywam to adopcją AI: to udział prawdziwej pracy produktowej, którą Twoje zespoły dowożą z narzędziami AI, mierzony obok tego, ile czasu zmergowana zmiana potrzebuje, żeby trafić na produkcję.
Lepsze narzędzia nie znaczą, że ludzie zaczną ich używać. Nowa wersja Javy nikomu nie pomoże, dopóki ktoś czegoś z nią nie dowiezie.
VP of Engineering, nazwijmy go Tomas, dostał zielone światło na transformację AI. O samym przekonywaniu piszę w tekście jak sprzedać business case dla AI stronie produktowej. Ten tekst jest o tygodniu po tym „tak”, kiedy decydujesz, kto wykona pracę i po czym poznasz, że zadziałało.
Nie ma projektu transformacji AI
Pierwszy plan Tomasa miał klasyczny kształt: weź dziesięć osób, zbuduj środowisko AI, po kilku miesiącach oddaj je wszystkie do zespołów produktowych, a zysk dalej sam się pomnaża. To fałszywe założenie. AI zmienia się tak szybko, że cały czas potrzebujesz zespołu, który się tym zajmuje. Nie dziesięciu osób, ale co najmniej trzech.
Typowe rady ujmują to jako program. HBS Online wymienia cztery dźwignie AI w transformacji: strategię, nadzór, architekturę i kulturę. Wszystkie cztery są prawdziwe. Żadna z nich nie mówi, kto w poniedziałek przestaje robić pracę produktową, a to właśnie ta decyzja uruchamia pozostałe cztery.
Badanie DORA prowadzone przez Google pokazało w 2025 roku, że 90% respondentów już używa AI w pracy, a AI jest „wzmacniaczem, który powiększa mocne i słabe strony organizacji”. Narzędzia są wszędzie. Wzmacniają Twój system dowożenia, taki, jaki jest.
Raport MIT NANDA z 2025 roku ujął to ostrzej: 95% organizacji miało zerowy zwrot z pilotaży generatywnej AI. Jego metoda jest dyskusyjna, opiera się na 153 odpowiedziach z ankiety, ale ten obraz zgadza się z tym, co widzę w mentoringu: pilotaż się kończy, ludzie wracają, zysk zanika.
To jak pytanie, po co masz inżynierów wsparcia, skoro funkcja jest już gotowa. Funkcja nigdy nie była całą pracą.
Siedem decyzji na pierwszy tydzień
1. Odetnij zespół od pracy produktowej
Jeśli nie wyjmiesz tych ludzi i nie zbudujesz wokół nich nowego zespołu, stara praca dalej będzie ich zjadać. Kiedy robiliśmy to w firmie, z którą teraz pracuję, wysłaliśmy odcięty, ośmioosobowy zespół AI na dwunastotygodniową misję, celowo w ciemność, jak rakietę, którą się wystrzeliwuje. Zespół z nikim na ziemi nie rozmawiał, więc ludzie mieli czas i nikt im nie przeszkadzał.
Odwrotna wersja, „dalej robią produkt, a na AI dajemy im 4% mocy przerobowych”, nie działa.
2. Utrzymaj stały rdzeń trzech osób
Jedna osoba to edukator, który śledzi trendy. Druga prowadzi ewaluacje (evals) i eksperymenty. Trzecia ciągle dostraja narzędzia dla agentów i je wdraża. Zespół Tomasa sam oszacował już, że na dłuższą metę potrzebuje około trzech osób. Nie podzielił tylko ról w ten sposób, a tej trójki nie było jeszcze w planie mocy przerobowych.
3. Po kilku miesiącach rozpuść resztę
Moja reguła kciuka: z dziesięciu osób, które bierzesz, trzy zostają, a siedem wraca do zespołów. Uczą innych, jak z tego korzystać, przy prawdziwych funkcjach. Tej części nie załatwi żadne szkolenie.
4. Zaplanuj budżet na adopcję, nie tylko na narzędzia
Wewnętrzna komunikacja o tym, po co to robicie, warsztaty, hackathony, czasem pomoc z zewnątrz. Nie każda osoba w Twojej firmie jest AI-native. Firmy, w której wszyscy są, w życiu nie widziałem.
Zwykle jest garstka ludzi, wokół których to budujesz. Czasem firma pożycza taką osobę jako kontraktora, który wygląda jak ktoś z wewnątrz, żeby to rozkręcić.
Jeśli pominiesz ten budżet, ludzie widzą grupkę gości, którzy coś tam robią, potem słyszą, że mają z tego korzystać, i są wkurzeni. O tym, co zrobić z ludźmi, którzy odmawiają, pisałem w tekście jak zwolnić pracownika, który blokuje wdrożenie AI.
5. Dobierz budującym komunikatora do pary
Mocni ludzie, którzy budują narzędzia, zwykle nie należą do komunikatywnych i nie wezmą na siebie wyjaśniania, którego potrzebujesz. Niezależnie od tego, jak dobre są Twoje narzędzia, jeśli nie połączysz z nimi ludzi bez tarcia, przegrałeś. Ludzie tego chcą, tylko powiedzą, że boli. Szukasz kogoś, kto sam z tego korzysta na co dzień, pali się do tego i pokazuje zespołom: „ta funkcja zajęła trzy dni zamiast dwóch tygodni”.
6. Zrób z czasu od commita do produkcji drugie KPI
Tomas chciał mierzyć transformację tym, jak szybko zespół dowozi pierwszą wersję rozwiązania. W porządku. Potem opisał, co się dzieje po napisaniu kodu, i zadałem mu pytanie hipotetyczne: a co, jeśli problemem nie jest AI, tylko droga od commita do produkcji?
| Krok po napisaniu kodu | Typowe czekanie w organizacji Tomasa |
|---|---|
| Code review w repozytorium innego zespołu | 2-3 dni |
| Testy end-to-end | przez noc |
| Pociąg wydań (release train) | do 2 tygodni |
| Stopniowe wdrożenie u wszystkich klientów | około 1 tygodnia |
| Od zmergowania do pierwszego prawdziwego ruchu na produkcji | do ~3 tygodni |
Jedna prawdziwa organizacja inżynierska, zanonimizowana. Agenci nie mieli też dostępu do odczytu metryk produkcyjnych, więc nie mogli sprawdzić własnej pracy.
DORA nazywa to change lead time, „czasem potrzebnym, żeby commit albo zmiana w kodzie z sukcesem trafiły na produkcję”, a według raportu z 2024 roku najlepsze zespoły robią to w mniej niż jeden dzień. Zespoły Tomasa potrzebowały do trzech tygodni, a każdy z tych dni to koszt opóźnienia (cost of delay).
Jeśli przyspieszysz tylko pisanie, zoptymalizowałeś najkrótszy krok.
Drugie KPI, mierzone od zmergowania do produkcji, wyciąga na wierzch pociąg wydań, kolejkę do review i brak dostępu do produkcji w trybie tylko do odczytu jako problemy AI. Bo nimi są. Jeśli chcesz spojrzenia z zewnątrz na to, gdzie ucieka Twój czas dowożenia, to właśnie mierzy audyt produktywności zespołu.
7. Weź to na siebie na poziomie VP, głośno
Jeden ruch, który bardzo lubię, kiedy VP może sobie na to pozwolić: osobiście przejmij pracę nad AI na pół roku, a budżetowanie, planowanie roadmapy i część incydentów oddaj komuś na tym samym szczeblu. Mówisz głośno, przed zarządem i resztą kadry kierowniczej, że odpowiadasz za to i bierzesz na siebie ryzyko, bo w to wierzysz.
Jedno ostrzeżenie: to nie jest pełne przekazanie obowiązków. To raczej „dzięki, że przez jakiś czas tego przypilnujesz, dalej będę Ci pomagać z systemami i procesami”, a ona dostaje w zamian zespoły produktowe, które dowożą szybciej.
Nazwij to adopcją i mierz jak adopcję
Samo używanie nie jest problemem, ale nie jest też dowodem. W badaniu METR z 2025 roku doświadczeni programiści potrzebowali z narzędziami AI o 19% więcej czasu i mimo to byli przekonani, że są o 20% szybsi. Raport licencji zaliczyłby ich wszystkich do tych, którzy przyjęli AI.
Lepsze narzędzia nie znaczą, że ludzie zaczną ich używać.
Dlatego dashboard, który chciałbym mieć w pierwszym miesiącu, ma dwie linie, a nie dziesięć: pierwsza dowieziona wersja i czas od zmergowania do produkcji. Do tego jedno szczere pytanie do każdego strumienia prac na comiesięcznym przeglądzie: co w tym miesiącu narzędzia AI zmieniły w waszym sposobie pracy?
Odpowiedź, na którą czekasz, brzmi tak, jak Tomas opowiadał o własnej pracy: jego agent w pięć minut buduje tabelę postępów dla zarządu, Tomas wkleja ją na Slacka i godzina robienia slajdów znika. To jest adopcja: zmieniła się praca, a nie liczba licencji.
Co się psuje w trzecim miesiącu
Produkt zaczyna przeklinać platformę
Odcięty zespół kończy, ludzie wracają, nikt nie aktualizuje narzędzi, a trzy miesiące później zespoły produktowe mówią, że platforma obiecała im rzeczy, które nie działają. W ich oczach to porażka platformy, bez względu na przyczynę. Stały rdzeń trzech osób jest po to, żeby do tego nie doszło.
Najlepsza osoba od AI rozdarta na trzy
Osoba, która u Ciebie najbardziej praktycznie zajmuje się AI, to zwykle też ta, bez której nie mogą się obyć produkcja i backlog. Jeśli nie uwolnisz jej rąk, wszystkie trzy rzeczy zrobi źle. Uwolnij ją i znajdź kogoś innego do pozostałych dwóch.
Zostajesz czarnym charakterem
Kiedy adopcja się nie udaje, zespoły nie obwiniają zespołu od narzędzi. Obwiniają VP, który nie zadbał o komunikację. Dlatego decyzja 4 i decyzja 7 należą do Ciebie, a nie do zespołu.
Tomas jeszcze nie wybrał swojego zespołu. Kiedy to zrobi, czas od commita do produkcji będzie pierwszą liczbą, na którą spojrzę.
Ile dziś trwa droga zmergowanej zmiany na Twoją produkcję? Jeśli chcesz pomocy w ustawieniu zespołu i tych dwóch KPI w swojej organizacji, to jest praca, którą robię jako fractional CTO.
[Czas pisania: 3 h]
