AI w zespole inżynierskim
Od mierzenia aktywności zespołu do mierzenia efektu dla odbiorcy.
Co Engineering Manager ma zmienić w pracy zespołu, gdy inżynierowie używają AI, a wynik się nie poprawia: standardy pracy, rozwój ludzi, miary efektu i wąskie gardła.
Dla kogo: engineering managerowie i liderzy zespołów inżynierskich
Jak wygląda szkolenie
Plan szkolenia
Na żywo, na Waszych realnych przypadkach. Rytm dnia dostosowujemy do zespołu, który będzie na sali.
120 minPrzypadek biznesowy i pierwsza mapa transformacji
Dział inżynierski w firmie regulowanej: w rok obciążenie się podwaja, rekrutacja jest zamrożona, a koszty mogą wzrosnąć najwyżej o jedną piątą.
Przypadek biznesowy i pierwsza mapa transformacji
Dział inżynierski w firmie regulowanej: w rok obciążenie się podwaja, rekrutacja jest zamrożona, a koszty mogą wzrosnąć najwyżej o jedną piątą.
- pierwsza mapa transformacji
- pułapki wraz z sygnałami ostrzegawczymi
- pokazanie na mapie, gdzie przeprojektowanie techniczne rozsypuje się bez strony ludzkiej, i odwrotnie
Scenariusz
Kierujecie działem albo zespołem inżynierskim w globalnej firmie działającej w branży regulowanej. Wasze zespoły programistów, analityków biznesowych, product managerów i inżynierów jakości są zorganizowane wokół portfela produktów.
W ciągu dwunastu miesięcy Wasz dział przejmuje pracę podobnego działu w innej lokalizacji, który jest redukowany. Jednocześnie macie dostarczać własne produkty szybciej. Obciążenie działu faktycznie się podwaja. Rekrutacja jest wstrzymana, a koszty operacyjne mogą wzrosnąć najwyżej o 20%, wliczając w to inwestycje w AI. Jakość, bezpieczeństwo, zgodność regulacyjna i stabilność operacyjna muszą zostać utrzymane.
Wprowadzenie pojedynczych asystentów AI prawdopodobnie nie wystarczy. Zadaniem jest przekształcić dział w taki, w którym ludzie i agenci AI pracują razem na całym cyklu dostarczania, przy czym dostarczanie trwa dalej, a zespoły przechodzą przez tę zmianę razem z Wami.
Przypadek rozwija się w trakcie szkolenia. Po każdym bloku dostajecie nowe informacje o dziale i podejmujecie jedną decyzję. Na końcu składacie te decyzje w jeden plan transformacji.
30 minDiagnoza wykorzystania AI w zespole
Rozpoznać problem zespołu, odróżnić aktywność od efektu i wskazać decyzję należącą do EM-a.
Diagnoza wykorzystania AI w zespole
Rozpoznać problem zespołu, odróżnić aktywność od efektu i wskazać decyzję należącą do EM-a.
- Przypadek otwierający: około 80% PR wspieranych przez AI, przy niewielkiej poprawie dostarczania. Jakie pytania powinien wtedy zadać EM?
- Cztery etapy zmiany: dostęp, standardy, skalowanie, wartość. Sprawdzenie etapu własnego zespołu.
- Rozróżnienie: użycie narzędzi, ukończona praca, wdrożona zmiana i efekt dla odbiorcy.
- Zakres odpowiedzialności: EM uzgadnia oczekiwania, warunki nauki i przegląd wyników; decyzje produktowe podejmuje z Product Managerem, a rozwiązania techniczne z odpowiednimi inżynierami. Dokładny podział zależy od organizacji.
- Wspólny przykład: jeden zespół pod presją większego zakresu pracy. Co EM może zmienić sam, a co wymaga uzgodnienia lub eskalacji?
- Ćwiczenie: Diagnoza problemu i zakresu wpływu EM-a na wspólnym przykładzie → sekcja 1 karty. Omówienie 20 min, ćwiczenie 10 min.
45 minOczekiwania i standardy pracy zespołu
Uzgodnić dwa standardy pracy, sposób ich przeglądu oraz realistyczne zobowiązanie zespołu.
Oczekiwania i standardy pracy zespołu
Uzgodnić dwa standardy pracy, sposób ich przeglądu oraz realistyczne zobowiązanie zespołu.
- Małe zadania i PR, sprawne przeglądy kodu i ograniczenie oczekiwania. EM wraz z zespołem wybiera reguły odnoszące się do faktycznego problemu.
- Standardy wymagają wsparcia: dostęp do narzędzi, czas na naukę, odpowiedzialność za przeglądy i obsługę wyjątków.
- Przykład oczekiwania: krótszy czas dostarczenia porównywalnych zmian przy utrzymaniu jakości. Wskaźnik użycia AI sam nie jest celem wyniku.
- Praktyka prowadzącego: cele czasu PR −40% i liczby PR/zgłoszeń +30%; opisane wyniki: czas PR 50 → 23 h, czas zgłoszeń 85 → 25 h, liczba PR +33% i zgłoszeń +35% na inżyniera rok do roku.
- Interpretacja wyników: uwzględnienie wielkości zadań, składu zespołu i równoczesnej zmiany sposobu pracy. Wyniki przypadku nie są obietnicą dla innego zespołu.
- Rytm EM-a: regularny przegląd przeszkód i comiesięczna ocena efektów wraz z zespołem.
- Ćwiczenie: Uczestnicy formułują dwa standardy, potrzebne wsparcie oraz komunikat EM-a do zespołu → sekcja 2 karty. Omówienie 25 min, ćwiczenie 20 min.
40 minRozwój ludzi i wdrażanie nowych sposobów pracy
Rozpoznać przyczynę trudności, przeprowadzić rozmowę z inżynierem i zaplanować sprawdzalne działanie rozwojowe.
Rozwój ludzi i wdrażanie nowych sposobów pracy
Rozpoznać przyczynę trudności, przeprowadzić rozmowę z inżynierem i zaplanować sprawdzalne działanie rozwojowe.
- Diagnoza w rozmowie: brak umiejętności, niewystarczający kontekst, nieodpowiednie narzędzie, obawa o jakość czy brak czasu na naukę?
- Wspólne oczekiwania dotyczą jakości pracy i odpowiedzialności za wynik; sposób korzystania z AI może zależeć od zadania i doświadczenia inżyniera.
- Praktyka prowadzącego: sesje wymiany doświadczeń, warsztaty tworzenia agentów i wspólne instrukcje. EM rezerwuje na nie czas i sprawdza zmianę w pracy.
- Krótki przykład agenta analizującego błąd testu: kto sprawdza propozycję, jakie są uprawnienia i kiedy wracamy do pracy ręcznej? n8n jako publiczna ilustracja; pozostałe platformy w materiałach uzupełniających.
- Rozmowa rozwojowa kończy się konkretnym zadaniem, wsparciem i terminem sprawdzenia rezultatu.
- Ćwiczenie: Omówienie 20 min, przykład agenta 5 min, symulacja rozmowy w parach 15 min: rozmowa 5 min, zamiana ról 5 min, informacja zwrotna i wpis do sekcji 3 karty 5 min. Rezultat: działanie rozwojowe, wsparcie i kryterium oceny.
35 minOcena wyników, jakości i kosztów
Wybrać miary wyniku zespołu i prowadzić przegląd efektów z uwzględnieniem jakości, kosztów oraz kontekstu pracy.
Ocena wyników, jakości i kosztów
Wybrać miary wyniku zespołu i prowadzić przegląd efektów z uwzględnieniem jakości, kosztów oraz kontekstu pracy.
- Wspólna ocena czasu dostarczenia, jakości i kosztu; punkt odniesienia i ten sam zakres pracy w porównywanych okresach.
- Cele z doświadczeń prowadzącego: utrzymanie SLO, 30% mniej błędów widocznych dla klientów na inżyniera rok do roku i średni koszt poniżej X USD za PR. To przykłady celów, nie progi dla każdej organizacji.
- Pułapki: sztuczne dzielenie PR, różna trudność zadań i zmiana składu zespołu; dane na inżyniera nie stanowią samodzielnego rankingu pracowników.
- Koszt narzędzi uzupełniamy o czas przeglądu, poprawek i utrzymania agentów. Koszt PR nie jest pełnym kosztem dostarczonej funkcji.
- Uczestnik wybiera jedną miarę efektu dla odbiorcy, np. czas od zgłoszenia problemu klienta do wdrożonej poprawki, oraz miarę jakości i kosztu. Samo wdrożenie nie potwierdza wykorzystania ani wartości zmiany.
- Rozmowa o indywidualnym wkładzie uwzględnia trudność zadań, współpracę, przeglądy i wsparcie innych; metryki przepływu pomagają diagnozować proces zespołu.
- Ćwiczenie: Dobór miary efektu dla odbiorcy, jakości i kosztu wraz z punktem odniesienia → sekcja 4 karty. Omówienie 20 min, ćwiczenie 15 min.
45 minPriorytety i wąskie gardła dostarczania
Wybrać jedno ograniczenie do usunięcia i uzasadnić koszt tej decyzji dla bieżącego planu zespołu.
Priorytety i wąskie gardła dostarczania
Wybrać jedno ograniczenie do usunięcia i uzasadnić koszt tej decyzji dla bieżącego planu zespołu.
- Gotowy kod może czekać na przegląd, testy lub wydanie. EM analizuje cały przepływ, zanim zwiększy oczekiwania wobec implementacji.
- Przypadek prowadzącego: monolit, tygodniowe wydania, niestabilne testy; migracja testów do Playwright i stabilizacja wspierana AI. Opisany wynik: procesy budowania i testowania szybsze o 40%, pierwsze zespoły na ciągłym dostarczaniu.
- Decyzja EM-a: praca nad funkcją, poprawa testów, skrócenie kolejki czy zadanie dla agenta? Wybór według ograniczenia i kosztu utraconych możliwości.
- Uzgodnienie z Product Managerem: ile czasu przeznaczamy na eksperyment, co odraczamy i jaki dowód pozwoli zmienić zobowiązania. Uwolniony czas można przeznaczyć na zakres, jakość lub zaległe usprawnienia.
- Gdy ograniczenie leży w innym zespole, EM przedstawia zależność i potrzebną decyzję. Nie deklaruje samodzielnie poprawy całego procesu.
- Kontrola napraw testów: nie uznajemy wyłączenia testu lub osłabienia sprawdzenia za dowód usunięcia błędu.
- Ćwiczenie: Wybór jednej interwencji i przygotowanie propozycji dla Product Managera: korzyść, czas zespołu, odraczana praca i zależności → aktualizacja sekcji 2 i 5. Omówienie 25 min, ćwiczenie 20 min.
45 minPlan EM-a dla własnego zespołu
Przygotować plan jednego eksperymentu dla własnego zespołu oraz sprawdzić jego wykonalność w rozmowie z drugim EM-em.
Plan EM-a dla własnego zespołu
Przygotować plan jednego eksperymentu dla własnego zespołu oraz sprawdzić jego wykonalność w rozmowie z drugim EM-em.
- Przeniesienie wniosków ze wspólnego przypadku na własny zespół: problem, dwie zasady pracy, wsparcie dla ludzi i jedna interwencja.
- Pierwszy tydzień: rozmowa z zespołem i Product Managerem, zebranie brakujących danych, wskazanie osoby odpowiedzialnej.
- 30 dni: punkt odniesienia i warunki eksperymentu; 60 dni: ocena pierwszych wyników; 90 dni: decyzja o kontynuacji, korekcie lub zatrzymaniu.
- Trzy miary: efekt dla odbiorcy, jakość i koszt; budżet czasu zespołu oraz sposób kontroli wyniku AI.
- Plan obejmuje działania w zakresie wpływu EM-a i osobno potrzebne uzgodnienia. Wynik pilotażu nie stanowi jeszcze podstawy do obietnicy podwojenia możliwości zespołu.
- Ćwiczenie: Wprowadzenie 5 min, indywidualny plan dla własnego zespołu 15 min, wzajemny przegląd w parach 10 min, omówienie wybranych wniosków i pierwszy krok 15 min. Rezultat: własna Karta Eksperymentu SDLC. Kryteria: problem, wsparcie ludzi, miary, koszt czasu i zakres wpływu EM-a.
Zapytaj o termin lub wersję dla Twojej organizacji
Programy in-company dopasowujemy do Waszych procesów i systemów. Napisz, kto będzie na sali — doradzimy zakres i konfigurację.
Zapytaj o termin