Sytuacja
Firma produktowa IT, zespół dwunastu deweloperów. AI było w codziennym użyciu: każdy miał podpowiadanie kodu w edytorze, każdy z tego korzystał. Nikt nie miał wątpliwości, że to pomaga.
Metryki mówiły co innego. Lead time, throughput i backlog nie zmieniały się od kwartałów. Presja biznesu rosła, a CTO szukał sposobu na większą wydajność bez powiększania zespołu.
Obserwacja z audytu była prosta: AI przyspieszało pisanie kodu, ale nie dostarczanie wartości. Deweloper nadal zaczynał każde zadanie od pustego pliku i ręcznie przechodził przez te same kroki, czyli analizę wymagań, decyzje projektowe, plan, testy, przegląd kodu i dokumentację. Podpowiadanie działało wyłącznie na poziomie wpisywania znaków, a wpisywanie to ułamek czasu dostarczania.
„Nie chodziło o to, żeby pisać kod szybciej. Chodziło o zmianę sposobu pracy. Kiedy deweloper zaczyna od zdefiniowania zadania, a nie od pustego pliku, zmienia się cały proces, a nie jeden krok.“
CTO, firma produktowa IT
Jak wyglądał proces przed zmianą
AI tylko przy klawiaturze. Podpowiadanie w edytorze, a poza pisaniem kodu AI nie wchodziło nigdzie. Wymagania, projektowanie, testy i dokumentacja robione po staremu.
Pusty plik jako punkt startowy. Każde zadanie zaczynało się od otwartego edytora. Strukturę deweloper wymyślał w trakcie, a zakres i kryteria akceptacji zostawały nieformalne.
Powtarzalne operacje ręcznie. Podstawowe operacje na danych, testy jednostkowe, dokumentacja interfejsów, szkielety modułów. Zespół robił to w kółko, bez wspólnych szablonów.
Onboarding jako wąskie gardło. Nowy deweloper potrzebował tygodni, żeby osiągnąć samodzielność, bo wiedza o standardach i wzorcach żyła w głowach kilku osób, nie w dokumencie.
Co zmierzyliśmy przed startem
Punkt odniesienia był łatwy do ustalenia, bo zespół miał go w systemie zarządzania pracą i nie zmieniał się od kwartałów.
Zmierzyliśmy dwie rzeczy. Throughput, czyli liczbę zadań przechodzących przez cykl w jednostce czasu, liczoną punktami i liczbą wdrożonych funkcji. Oraz lead time, czyli czas od podjęcia zadania do wdrożenia go na produkcję.
Nie mierzyliśmy liczby wygenerowanych linii kodu ani odsetka kodu napisanego z AI. Obie te liczby rosną, gdy zespół używa podpowiadania, i obie rosły w tym zespole przez cały czas, kiedy metryki stały w miejscu. Taki pomiar usypia czujność.
Co zrobiliśmy
Definicja zadania jako punkt startowy. Deweloper nie otwiera pustego pliku, tylko zaczyna od spisania zakresu, kryteriów akceptacji i kontekstu technicznego. AI pomaga uzupełnić braki w definicji i zadaje pytania, na które warto odpowiedzieć przed kodem. Najmniej efektowny element całej zmiany i zarazem najbardziej wpływowy.
AI w całym cyklu, nie tylko przy pisaniu. Model wchodzi w analizę wymagań, plan implementacji, kod, testy jednostkowe, opis zmiany i dokumentację techniczną. Deweloper odzyskuje czas w analizie i projektowaniu.
Jedno oficjalne narzędzie zamiast kilku prywatnych. Umowa firmowa, logowanie firmowe, brak uczenia modeli na kodzie klienta, integracja ze środowiskiem i z pipeline’em. Nieoficjalne narzędzia przestają mieć sens, kiedy oficjalna ścieżka jest szybsza.
Wiedza zespołu zapisana w plikach. Standardy pracy, konwencje kodu, wzorce architektoniczne i katalog powtarzalnych zadań zapisane w plikach wersjonowanych razem z kodem. Model i nowy deweloper startują z tym samym kontekstem co senior z zespołu.
Wynik w liczbach
| Co | Przed | Po | Jak mierzone |
|---|---|---|---|
| Throughput zespołu | punkt odniesienia z kwartałów przed zmianą | wyższy trzykrotnie | punkty i liczba wdrożonych funkcji, ten sam zespół, pomiar po sześciu miesiącach |
| Lead time na funkcję | 3 tygodnie | 5 dni | czas od podjęcia zadania do wdrożenia, dane z systemu zarządzania pracą |
| Wielkość zespołu | 12 osób | 12 osób | wzrost bez zatrudniania, warunek postawiony przez CTO na starcie |
| Dokumentacja techniczna | powstawała osobno i szybko traciła aktualność | powstaje przy okazji przeglądu zmian | zmiana mechanizmu, bez pomiaru ilościowego |
Ostatni wiersz opisuje zmianę mechanizmu, bo aktualności dokumentacji nie mierzyliśmy. Zauważalnym skutkiem jest krótszy czas dochodzenia nowego dewelopera do samodzielności, ale i tego nie policzyliśmy osobno.
Co z tego wynika dla podobnego zespołu
Jeśli zespół używa AI codziennie, a metryki dostarczania stoją, sprawdźcie najpierw, w którym miejscu cyklu AI faktycznie pracuje. W większości zespołów pracuje w jednym: przy wpisywaniu kodu. Wpisywanie to ułamek czasu, który upływa od podjęcia zadania do wdrożenia.
Kolejność ma znaczenie i jest odwrotna niż zwykle. Najpierw przepisujecie przepływ zadania, czyli wymagania, plan, kod, testy i dokumentację, a dopiero potem dobieracie narzędzie do tego przepływu. Odwrotna kolejność latami blokowała efekt w metrykach w tym zespole i blokuje go w większości, które widzieliśmy.
Warunek brzegowy jest jeden: deweloper weryfikuje każdy artefakt i to on podpisuje zmianę. To odpowiedź na najczęstszą obawę zespołu, czyli kto bierze odpowiedzialność za kod, którego nie napisał znak po znaku.
Produkt użyty i następny krok
Zespół zaczął od Warsztatu AI dla zespołów IT na własnym kodzie i zadaniu z bieżącego backlogu. Zmiana modelu pracy weszła w ramach usługi AI w wytwarzaniu oprogramowania, a wybór obszaru poprzedził Dowód wartości AI. Prowadzili to partnerzy, którzy sami odpowiadali za organizacje inżynierskie: zobacz, kto poprowadzi projekt.
Jak ta sama zmiana wygląda w organizacji z ponad tysiącem deweloperów, gdzie dochodzi pomiar adopcji i rozliczanie kosztów, opisaliśmy w case’ie o standaryzacji AI w software house.