W tym rozdziale
Ja patrzę na liczbę wykonanych zadań, czas dojścia zmiany do produkcji i realizację celów roadmapy. Ludzie mają cele indywidualne oraz zakres odpowiedzialności na kwartał. Chcę wiedzieć, co dowieźliśmy i co nadal nas zatrzymuje.
Poniżej proponuję, jak sprawdzić to u siebie. Otwórzcie aktualny plan, zadania i ostatnie wydania. Na nich zróbcie przegląd.
Zbierzcie wynik z waszego projektu
| Co sprawdzić | Co otworzyć i zapisać |
|---|---|
| Co dowieźliśmy? | Cel z roadmapy, odpowiedzialność na kwartał i działający wynik. Przy celu wskażcie, co już zrobiono i co zostało |
| Jak długo szło do produkcji? | Datę wejścia zadania do mierzonego procesu oraz potwierdzonego wdrożenia. Obok pokażcie zmiany nadal niewydane i czas ich oczekiwania |
| Ile skończyliśmy? | Liczbę odebranych zadań w porównywanych okresach. Oddzielcie nowe funkcje, naprawy i utrzymanie; zaznaczcie, które zmiany są już na produkcji |
| Ile wróciło do poprawy? | Zadania z potwierdzonym błędem, problemy po wydaniu i czas ich naprawy. Zapiszcie, co nie zadziałało i jaki był wpływ na użytkownika |
| Czy ludzie korzystają z agentów? | Ile osób w zespole użyło agenta w rzeczywistym zadaniu i do czego. Pokażcie konkretny przyjęty wynik oraz taki, który trzeba było poprawić lub odrzucić |
Przed liczeniem ustalcie, co u was znaczy „wejście”. Nie zamieniajcie daty wdrożenia na datę odbioru lub połączenia kodu. Zadania niewymagające produkcji sprawdzajcie według ich uzgodnionego rezultatu.
Porównajcie podobną pracę przed zmianą i po niej
Weźcie dwa równe okresy. Policzcie zakończone zadania i czas do produkcji. Nie doliczajcie podzadań drugi raz. Zaznaczcie zmiany wielkości zadań, składu i dostępności zespołu. Brakuje historii? Zacznijcie zbierać ją od dziś.
Obok wyniku zapiszcie liczbę porównanych zadań i najdłużej czekające zmiany. Błędy obserwujcie przez taki sam czas po wydaniu — świeża zmiana mogła jeszcze nie ujawnić problemu. Brak danych to nie zero. Jeżeli zmieniliście również zakres lub sposób pracy, nie przypisujcie całej różnicy agentowi.
Sprawdźcie, czy szybciej nadal znaczy dobrze
Do porównania weźcie także wynik testów i przeglądu dla wydanej wersji. Przy zmianie dotyczącej danych użytkowników sprawdźcie konkretnie:
- Czy jedna osoba może zobaczyć lub zmienić dane drugiej bez uprawnienia?
- Czy nowy kod lub pliki nie zawierają haseł i kluczy?
- Czy użyte biblioteki mają wykryte, istotne problemy bezpieczeństwa?
- Czy zgłoszoną usterkę naprawiono i ponownie sprawdzono?
Przy każdym sprawdzeniu potrzebny jest wynik i dowód. Samo „agent zaakceptował” lub „nikt nie zgłosił błędu” nie wystarczy. Pozostałe kontrole dobierzcie do zmiany; te cztery pytania nie obejmują całego bezpieczeństwa aplikacji. Poważny, potwierdzony problem rozwiążcie przed wydaniem.
Z wyniku ma wyjść konkretna zmiana
| Co widzicie | Co zrobić dalej |
|---|---|
| Kod powstaje szybciej, ale czeka na przegląd | Otwórzcie najstarszą czekającą zmianę. Ustalcie, kto ją sprawdzi i co potrzebuje dostać od autora |
| Agent stale pyta o tę samą regułę | Uzupełnijcie właściwy opis i sprawdźcie na następnym zadaniu, czy agent potrafi z niego skorzystać |
| Rośnie liczba poprawek | Weźcie ostatni błąd, odtwórzcie go i dodajcie sprawdzenie, które wykryje go przed kolejnym wydaniem |
| Zadań jest więcej, ale cel roadmapy stoi | Wróćcie do brakującego rezultatu. Uzgodnijcie, co kończycie, kto to prowadzi i co odkładacie |
| Tylko część zespołu pracuje skutecznie z agentem | Niech pokaże pozostałym jedno prawdziwe zadanie: polecenie, wynik, poprawki i sposób sprawdzenia |
U nas to praca zespołu wewnętrznego. Jeśli rozliczacie się z klientem, po pierwszym dostarczonym fragmencie porównajcie zakładany czas i koszt z rzeczywistym — razem z testami i poprawkami. Zaktualizujcie pozostały zakres, termin oraz kwotę do uzgodnienia z klientem. Sam fakt używania AI nie określa ceny.
Pobierzcie wzory i zróbcie przegląd z agentem
Do pobrania · Plik tekstowyPrzegląd pracy z AI — karta do uzupełnieniateam-ai-transition-pl.mdPobierzDo pobrania · Plik tekstowyRoadmapa i cele kwartalne — wzory dokumentów zespołu i osóbteam-cele-i-roadmapa-pl.mdPobierzDołączcie potrzebny plik do rozmowy w projekcie i wskażcie dane, do których agent może mieć dostęp. Wzór celów pomoże połączyć wynik z roadmapą i odpowiedzialnością osoby. Karta przeglądu zbiera liczby, problemy oraz następną decyzję.
Przejrzyj nasz plan, zadania i wydania z okresów [przed] i [po]: [źródła]. Sprawdź, czy możemy je porównać. Zapytaj o definicję wejścia do pomiaru. Pokaż: wykonane zadania, czas do potwierdzonej produkcji, zmiany nadal niewydane, poprawki i wynik celów roadmapy. Uwzględnij odpowiedzialności kwartalne, dostępność zespołu i dowody sprawdzeń jakości oraz bezpieczeństwa. Przy liczbach podaj źródło i liczbę obserwacji. Braków nie zamieniaj w zera. Wskaż, gdzie agent pomógł, a gdzie nadal czekamy lub poprawiamy jego pracę. Nie przypisuj całej różnicy AI i nie oceniaj osób liczbą zadań. Zaproponuj jedną zmianę: co robimy, kto to bierze i przy którym zadaniu sprawdzimy wynik. Pokaż propozycję do uzgodnienia, bez zapisywania w usługach.
Po przeglądzie ma zostać jedna decyzja do zastosowania w pracy, osoba odpowiedzialna i termin sprawdzenia wyniku.
Koniec głównej ścieżki
Zastosujcie wybraną zmianę przy kolejnym zadaniu i wróćcie do pomiaru w ustalonym terminie.
Opcjonalnie: MiddleBrain — z mojego warsztatu