Pomiar adopcji AI w zespołach deweloperskich: lead time krótszy o 18 procent

Sytuacja

Software house z ponad tysiącem deweloperów. AI było w użyciu od wielu miesięcy, oddolnie: różne narzędzia, różne konfiguracje, każdy zespół po swojemu. Koszty rozchodziły się po organizacji, a wiedza o tym, co działa, nie przechodziła między zespołami.

Zarząd zadawał jedno pytanie: ile z tego mamy. IT nie miało jak odpowiedzieć. Licznik licencji pokazywał, kto dostał dostęp, a nie kto i jak używa. Ankiety dawały deklaracje.

Problem nie leży w narzędziach. Organizacji brakuje języka, którym da się opisać, gdzie stoi.

„Przestaliśmy pytać, ilu deweloperów używa AI. Pytamy, gdzie zespół stoi w matrycy i jaki jest następny krok. To zmieniło rozmowę z adopcji narzędzia na dojrzałość procesu wytwórczego.“

VP Engineering, software house

Jak wyglądał proces przed zmianą

Każdy zespół zaczynał pracę z AI od zera. Własne wzorce, własne ustawienia, własne wnioski. To, czego jeden zespół nauczył się trzy miesiące wcześniej, było niedostępne dla pozostałych.

Kontekst projektu, czyli konwencje, decyzje architektoniczne i zabronione wzorce, żył w głowach kilku osób na zespół. Nowy deweloper i narzędzie AI startowały z zupełnie różną wiedzą o kodzie, w którym pracują.

Koszt AI lądował w budżecie IT, a korzyści rozkładały się po jednostkach biznesowych. Przy takim układzie każda kolejna inwestycja wymagała obrony, której nie było czym poprzeć.

Co zmierzyliśmy przed startem

Zanim cokolwiek wdrożyliśmy, ustaliliśmy, jak będziemy mówić o adopcji.

Odpowiedź na pytanie „ilu deweloperów używa AI“ jest bezużyteczna, bo zespół może pracować samodzielnie przy budowie kodu i w ogóle nie tykać AI przy przeglądzie ani przy utrzymaniu. Dlatego zamiast jednej liczby powstała matryca: siedem faz cyklu wytwarzania oprogramowania razy pięć poziomów dojrzałości, od braku użycia po pełną samodzielność.

Siedem faz cyklu wytwarzania:

• Wymagania
• Projektowanie
• Budowa
• Testy
• Przegląd kodu
• Wdrożenie
• Utrzymanie

Pięć poziomów dojrzałości:

• Brak użycia AI w tej fazie
• Wspomaganie, czyli AI podpowiada, człowiek robi resztę
• Samodzielność, czyli zespół realizuje z AI całe zadania na podstawie zdefiniowanego zakresu
• Koordynacja, czyli AI pracuje na wielu krokach zadania i przekazuje wyniki między nimi
• Samodoskonalenie, czyli zespół rozwija własne wzorce pracy na podstawie tego, co zadziałało

Zespół może być na poziomie samodzielności przy budowie kodu i na poziomie braku użycia przy utrzymaniu. Jedna liczba tego nie pokaże.

Pomiar jest deterministyczny, nie deklaratywny. Głównym sygnałem jest wpis w stopce commita mówiący, że przy zmianie pracowało AI. Do tego dane o czasie przejścia zadań z systemu zarządzania pracą i dane o aktywności licencji z API administracyjnego. Nic z tego nie wymaga ankiety ani modelu oceniającego, który raz sklasyfikuje podobną zmianę tak, a raz inaczej.

Dwie zasady, które ustaliliśmy na starcie i które okazały się ważniejsze od samej matrycy. Mierzymy per zespół i per jednostkę biznesową, nigdy per osoba. Dane indywidualne zostają w narzędziu, dostępne wyłącznie dla samego użytkownika. Gdy liderzy widzą tylko agregaty, zespoły mówią prawdę o tym, co działa.

Co zrobiliśmy

Jeden ekosystem zamiast zbioru narzędzi. Wybór padł na rozwiązanie z jednym kontraktem, logowaniem firmowym, API administracyjnym i możliwością trzymania organizacyjnego katalogu wzorców pracy.

Narzędzie pomiaru zbudowane od podstaw. Nasłuch zdarzeń z repozytoriów, dane z systemu zarządzania pracą i z API administracyjnego trafiają do jednej bazy, a z niej na dwa widoki: dla lidera zespołu z pozycją w matrycy i trendem tygodniowym, oraz dla jednostki biznesowej z dojrzałością i kosztem.

Katalog wzorców pracy. Zestaw sprawdzonych schematów dla powtarzalnych zadań, wersjonowany i walidowany, dystrybuowany do wszystkich zespołów. To, czego nauczył się jeden zespół, przestaje być jego prywatną wiedzą.

Rozliczanie kosztów na jednostki biznesowe. Podstawa licencji zostaje w budżecie centralnym, a zużycie rozliczane jest kwartalnie na jednostki według przypisania zespołów. Dyrektor jednostki widzi koszt AI obok miernika dojrzałości swoich zespołów.

Wynik w liczbach

Ostatni wiersz opisuje zmianę mechanizmu, bo tu nie ma czego liczyć: koszt nie spadł, tylko trafił tam, gdzie powstaje korzyść. To był warunek dalszych inwestycji.

Co z tego wynika dla podobnej firmy

Jeśli zarząd pyta, ile macie z AI, a odpowiedź brzmi „większość zespołów korzysta“, to nie jest odpowiedź, tylko jej brak. Odsetek osób z dostępem do narzędzia nie mówi nic o tym, czy cokolwiek zmieniło się w sposobie pracy.

Pierwszym krokiem nie jest wybór narzędzia ani szkolenie, tylko ustalenie, czym jest dojrzałość w Waszym cyklu wytwarzania. Zespół może być samodzielny przy budowie kodu i zupełnie nie tykać AI przy przeglądzie. Jedna liczba to zamaskuje, matryca pokaże, gdzie następna inwestycja szkoleniowa da najwięcej.

Drugi warunek jest polityczny, nie techniczny: pomiar musi być agregowany do zespołu, nigdy do osoby. W organizacji, w której deweloper podejrzewa, że jest oceniany po liczbie commitów z AI, dane przestają być prawdziwe w ciągu miesiąca.

Produkt użyty i następny krok

Projekt zaczął się od czterotygodniowego Dowodu wartości AI na czterech zespołach, a skończył wdrożeniem w ramach usługi AI w wytwarzaniu oprogramowania. Zespoły przechodziły przez Warsztat AI dla zespołów IT na własnym kodzie i zadaniach z bieżącego backlogu. Prowadzili to partnerzy, którzy sami odpowiadali za organizacje inżynierskie: zobacz, kto poprowadzi projekt.

Jak wygląda ta sama zmiana w małym zespole, bez matrycy i bez rozliczania kosztów, opisaliśmy w case’ie o AI w cyklu wytwarzania w firmie produktowej.