„Myśleliśmy, że problem to wybór narzędzia. Okazało się, że problem to brak standardu. Kiedy developerzy dostali jedno dobre narzędzie z jasnymi zasadami, adopcja poszła sama.”
Tyle mówi VP of Engineering dużej firmy technologicznej, z którą pracowaliśmy przez cztery miesiące. Kiedy zaczęliśmy, organizacja miała 1200 inżynierów, 80+ zespołów i problem, który dobrze znają duże organizacje: każdy robił coś innego.
Stan przed: 80 zespołów, 80 podejść do AI
Z osiemdziesięciu zespołów developerskich kilkanaście aktywnie używało narzędzi AI. I każdy z nich na własną rękę.
Jeden zespół korzystał z ChatGPT, drugi z Copilota, trzeci z lokalnych modeli, czwarty zbudował własne skrypty wrappujące API. Fragmenty kodu produkcyjnego - włącznie z logiką biznesową i danymi klientów - trafiały do publicznych modeli bez żadnej weryfikacji. Nie dlatego, że developerzy działali w złej wierze - po prostu nikt nie ustalił zasad.
Reszta organizacji nie używała AI wcale. Nie z przekonania, że AI nie ma wartości - ale dlatego, że nikt nie powiedział im, jak bezpiecznie zacząć. W otoczeniu bez standardów, bierność była bezpieczniejsza niż działanie.
Zarząd wiedział, że to sytuacja nieoptymalna. Ale nie wiedział też, jak obronić decyzję o inwestycji w AI dla całej organizacji, skoro nie miał ani danych o efektach, ani zasad bezpieczeństwa. Temat był w kolejce od sześciu miesięcy.
Jak podeszliśmy do problemu
Zaczęliśmy od pytania, które rzadko pada na początku projektu standaryzacji AI: „Jakie są mierzalne warunki sukcesu - i co musi się stać, żebyśmy po czterech miesiącach mogli powiedzieć, że to zadziałało?”
Uzgodniliśmy trzy kryteria:
- Minimum 80% zespołów aktywnie używa AI po czterech miesiącach (aktywne = minimum X sesji tygodniowo per developer)
- Zero incydentów bezpieczeństwa związanych z AI od dnia wdrożenia polityki
- Lead time na feature spada o minimum 20% w ciągu sześciu miesięcy
To były twarde warunki go/no-go. Bez uzgodnienia tych warunków nie zaczęliśmy.
Etap 1: dowód wartości na czterech zespołach (3 tygodnie)
Zamiast od razu standaryzować dla 1200 osób, uruchomiliśmy dowód wartości na czterech zespołach pilotażowych: dwa używające AI „dziko”, jeden nieużywający AI wcale, jeden z Copilotem od roku.
Testowaliśmy Claude.ai i Claude Code w porównaniu z dotychczasowym zestawem narzędzi. Mierzyliśmy: czas code review, lead time na feature, adopcja (logowana aktywność). Zbieraliśmy feedback od developerów i team leadów.
Wynik dowód wartości po trzech tygodniach: jedno narzędzie lepsze od pozostałych na wszystkich mierzonych wymiarach. Lead time krótszy o 35% w stosunku do baseline. Adopcja w czterech zespołach: 89% w ciągu dwóch tygodni od dostarczenia standardów pracy.
Etap 2: Polityka bezpieczeństwa AI
Przed wdrożeniem dla 1200 osób: zdefiniowanie zasad. Co może trafić do modelu, co nie, jak obsługiwać dane wrażliwe i IP.
Zasady musiały być praktyczne - to znaczy: developer musi wiedzieć, jak postąpić w każdej sytuacji bez pytania security za każdym razem. Zasady zbyt ogólne („nie wysyłaj wrażliwych danych”) nie działają. Zasady operacyjne działają: „Kod produkcji bez danych klientów - ok. Kod z danymi klientów - użyj modelu lokalnego lub usuń dane przed wysłaniem - oto jak to zrobić.”
Security zatwierdziło politykę przed startem roll-outu, nie po nim. To była kluczowa różnica w stosunku do poprzednich prób: compliance był partnerem od początku, nie blokadą na końcu.
Etap 3: Governance - centralizacja narzędzia, licencji i monitoringu
Jedno narzędzie zamiast chaotycznego zestawu. Jedna licencja enterprise dla całej organizacji (konsolidacja kosztowo neutralna przy porównaniu sumy poprzednich wydatków). Centralny dashboard adopcji i kosztów - zarząd widzi, ile zespołów używa AI, ile sesji tygodniowo, jaki jest koszt per head.
Governance nie był papierową warstwą. Był mechanizmem operacyjnym: kto może dodawać wyjątki od zasad bezpieczeństwa, jak wygląda eskalacja incydentu, kto monitoruje anomalie w kosztach.
Etap 4: Szkolenia - warsztatowe, na realnych zadaniach
Zdecydowaliśmy się przeprowadzić szkolenia sami, zamiast zlecać zewnętrznym trenerom lub dawać „materiały do samodzielnego przejścia”. Powód: szkolenie z AI ma sens tylko wtedy, gdy uczestnicy pracują na własnym kodzie i własnych zadaniach.
Format: 4-godzinne sesje w grupach 12–15 osób, każda z własnym codebase’em. Developer przynosi swój task - my pokazujemy, jak AI wchodzi w jego konkretną pracę: definiowanie zadania, weryfikacja outputu, code review, testy. Nie prezentacje, nie demo na fikcyjnym projekcie.
Trzynaście sesji, wszystkie 80 zespołów w ciągu ośmiu tygodni.
Wyniki po czterech miesiącach
- 92% zespołów aktywnie korzysta z AI (baseline: kilkanaście procent)
- Lead time na feature skrócony o 35% (mierzony na próbce 40 feature’ów po wdrożeniu vs 40 przed)
- Czas onboardingu nowego developera: z 4–6 tygodni do 1,5 tygodnia (dzięki centralnej dokumentacji i standardom pracy)
- Koszt licencji: wzrost o 15% na głowę po konsolidacji, ale koszt wytworzenia netto się obniżył dzięki wzrostowi wydajności
- Zero incydentów bezpieczeństwa od dnia wdrożenia polityki
Warunek go, który uzgodniliśmy na początku: 80% adopcji, 0 incydentów bezpieczeństwa, -20% lead time. Wyniki: 92%, 0, -35%. Wszystkie warunki spełnione z zapasem.
Co zadziałało i czego wcześniej brakowało
Retrospektywa z VP of Engineering ujawniła kilka wniosków, które powtarzają się w podobnych projektach:
Wniosek 1: Narzędzie było wtórne. Poprzednie próby standaryzacji zaczęły się od wyboru narzędzia. My zaczęliśmy od pytania o warunki sukcesu i sposób pracy. Narzędzie wyłoniło się z dowód wartości - nie z prezentacji vendora.
Wniosek 2: Governance przed wdrożeniem, nie po. Każda poprzednia próba zatrzymała się na etapie „compliance mówi nie”. Tym razem compliance był w pokoju od tygodnia pierwszego. Zasady bezpieczeństwa były gotowe przed startem roll-outu - nie jako bloker, ale jako warunek zielonego światła.
Wniosek 3: Szkolenie musi dotyczyć konkretnej pracy. Godzinny webinar z demo narzędzia nie zmienia sposobu pracy. Warsztat z własnym kodem - zmienia. Różnica w adopcji między zespołami, które przeszły warsztat, a tymi, które dostały tylko materiały - była wyraźna: 95% vs 61% adopcja po tygodniu.
Wniosek 4: Pomiar był możliwy, bo baseline ustaliliśmy na początku. Wynik „92% adopcji” jest znaczący, bo wiemy, że baseline był „kilkanaście procent”. Wynik „-35% lead time” jest wiarygodny, bo mierzono tę samą próbkę feature’ów przed i po. Bez baseline’u wyniki są anegdotą, nie dowodem.
