W tym rozdziale
W moim podejściu zespół opiera się na dwóch rolach: dziedzinowym Product Ownerze i AI Engineers. Product Owner rozumie problem i decyduje, co ma powstać. AI Engineer z agentami prowadzi zmianę przez całą aplikację, sprawdza ją i przygotowuje do wydania.
Od wielu ról do odpowiedzialności za całą zmianę
Wcześniej zespoły miały taki podział ról — w różnych konfiguracjach, czasem kilka funkcji w jednej osobie. Dziś układam to tak:
| Wcześniej | Obecnie |
|---|---|
| Product Owner i analityk | Dziedzinowy Product Owner ze smykałką do analizy. Wyjaśnia potrzebę, reguły i wyjątki. Ustala priorytet oraz odbiera działanie produktu. |
| Tech lead / architekt | AI Engineer podejmuje i zapisuje decyzje techniczne. Przy zmianie wspólnych części wiadomo, który z inżynierów prowadzi decyzję. |
| Frontend developer i backend developer | AI Engineer dowozi całą funkcję: ekran, logikę i dane, korzystając z agentów. |
| DevOps | Wskazany AI Engineer odpowiada za środowiska, wdrożenie, obserwowanie awarii i możliwość cofnięcia zmiany. |
| Tester manualny i tester automatyzujący | AI Engineer z agentami przygotowuje i uruchamia sprawdzenia, przechodzi aplikację oraz poprawia błędy. Inny agent robi niezależny przegląd, a Product Owner sprawdza rezultat od strony użytkownika. |
| Scrum Master | Zespół uzgadnia pracę bez osobnej roli do prowadzenia ceremonii. Krótkie rozmowy służą decyzji, usunięciu blokady albo pokazaniu wyniku. |
To opis mojego kierunku. Nie zakładam osobnego testera ani stałego przekazywania zadania między frontendem i backendem. Testy, architektura i utrzymanie nadal mają właściciela. AI Engineer musi umieć ocenić wynik agentów i rozpoznać, kiedy potrzebuje pomocy.
Product Owner i AI Engineer: dogadajcie intencję
Otwórzcie jedno bieżące zadanie i aplikację. Product Owner pokazuje problem. AI Engineer sprawdza, czy rozumie oczekiwany efekt. Jeśli temat jest duży, wybierzcie pierwszy fragment do demo.
Krótka rozmowa powinna zostawić cztery ustalenia:
- Dla kogo i po co to robimy? Co tej osobie dziś przeszkadza?
- Co ma się zmienić? Jaki wynik pokażemy w aplikacji?
- Czego teraz nie robimy? Gdzie kończy się to zadanie?
- Co wymaga odpowiedzi przed startem? Która reguła lub wyjątek nadal jest niejasny?
AI potrafi napisać dużo tekstu. Potrzebuję z niego wyciągnąć sedno. Poproście agenta o krótkie podsumowanie tych ustaleń, a Product Owner niech potwierdzi, że oddaje jego intencję. Przy niejasności porozmawiajcie, zamiast przekazywać sobie kolejne wygenerowane opisy. Uzgodnienie zostaje przy zadaniu; AI Engineer wraca z działającym fragmentem do pokazania.
Ustalcie design na początku
Na starcie warto dobrze przygotować design system, czyli wspólne elementy i zasady interfejsu: przyciski, formularze, kolory, typografię oraz zachowanie ekranów. W działającym produkcie zacznijcie od tego, co już macie.
- Wybierzcie główną czynność użytkownika i pokażcie graficzną próbę jej ekranów. Uwzględnijcie też pusty widok, błąd i telefon, jeśli ma być obsługiwany.
- Product Owner zatwierdza przebieg oraz kierunek wyglądu. Na tym etapie można skorzystać z pomocy projektanta.
- AI Engineer zapisuje zaakceptowane zasady i wskazuje agentowi istniejące komponenty, z których ma budować kolejne widoki.
Potem Product Owner prowadzi decyzje o produkcie i interfejsie, a AI Engineer z agentem realizuje je w tych samych zasadach. Nie potrzebuję osobnego przekazywania projektu graficznego przy każdej zmianie. Gdy nowa funkcja nie mieści się w design systemie, uzgadniamy rozszerzenie i zapisujemy je dla kolejnych zadań.
Sprawdźcie, co trzeba zmienić w waszej pracy
Przejdźcie historię ostatniego zadania: na kogo czekaliście, ile razy przekazywaliście pracę dalej i co trzeba było tłumaczyć ponownie? Przy następnym zadaniu spróbujcie ograniczyć jedno takie przekazanie. Ustalcie prowadzącego, Product Ownera odbierającego wynik i pomoc w mniej znanej części aplikacji.
Niech jedna osoba pokaże rozmowę z agentem: polecenie, wynik i poprawkę. Jeśli ktoś nie ufa wynikom albo brakuje mu satysfakcji z pisania kodu, porozmawiajcie o tym na konkretnym przykładzie. Samo „teraz każdy robi wszystko” nie przygotuje nikogo do pracy. Zaplanujcie czas na naukę i wspólne sprawdzenie pierwszej zmiany.
Zapiszcie punkt odniesienia przed próbą: liczbę zadań, czas do produkcji i powroty z powodu błędów. Brakujących danych nie zgadujcie. Jak mierzyć efekt pracy z AI? pokazuje, co zebrać i jak porównać wynik.
Połączcie zadanie z celami na kwartał
U nas patrzymy na cele z roadmapy, czyli planu ważniejszych zmian w produkcie. Ludzie mają też przypisane cele indywidualne i zakres odpowiedzialności na kwartał. Przy bieżącym zadaniu chcę wiedzieć, do którego celu nas przybliża i kto odpowiada za wynik.
W planie rozdzielam cele zespołu, cele osób oraz tygodniowy przegląd priorytetów. Taki układ możecie zastosować u siebie:
| Co ustalacie | Co warto zapisać | Jak to połączyć z pracą |
|---|---|---|
| Roadmapa i cele zespołu | Potrzeba, oczekiwany rezultat, kolejność, horyzont, właściciel i współpraca | Zadania prowadzą do właściwego celu; sam status nie zastępuje opisu wyniku |
| Cel indywidualny na kwartał | Wynik, zakres odpowiedzialności, sposób sprawdzenia i potrzebne wsparcie | Wiadomo, za co osoba odpowiada, co uzgadnia z innymi i jak cel mieści się obok bieżącej pracy |
| Tygodniowy przegląd | Co ukończono, co blokuje cel i jaki jest następny krok | Otwieracie rzeczywiste zadania oraz dowody, podejmujecie potrzebne decyzje |
To nie jest wyścig na liczbę zamkniętych zadań. Jedna osoba może dowozić funkcję, druga odpowiadać za stabilność obszaru, a trzecia usuwać zależność od wiedzy jednej osoby. Każdy z tych celów potrzebuje jasnego rezultatu. Agent pomaga w pracy, ale odpowiedzialność za cel zostaje u człowieka.
Do pobrania · Plik tekstowyRoadmapa i cele kwartalne — wzory dokumentów zespołu i osóbteam-cele-i-roadmapa-pl.mdPobierzPobierzcie plik i załączcie go do rozmowy w projekcie. Są w nim tabele do waszej roadmapy, planu zespołu, celu indywidualnego i tygodniowego przeglądu. Dopisałem pola na dowody i powiązania między dokumentami. Jeśli macie już plan w Confluence, uzupełnijcie go — nie twórzcie drugiej listy tych samych celów.
Przeczytaj wzór i nasz plan [źródła]. Pokaż powiązanie: cel roadmapy → cel zespołu na kwartał → cel indywidualny i odpowiedzialność → bieżące zadania. Uwzględnij też utrzymanie i potrzebne wsparcie. Wskaż, gdzie nie wiadomo, jaki wynik ma powstać lub kto go sprawdzi. Nie wymyślaj celów, terminów ani przypisań osób. Przygotuj propozycję uzupełnienia istniejącego planu i tabelę tygodniowego przeglądu. Pokaż je do wspólnego uzgodnienia, bez zapisywania w zewnętrznych systemach.
Zróbcie próbę i porozmawiajcie o wyniku
Do pobrania · Plik tekstowyRozmowa o przejściu do pracy z AIteam-ai-transition-pl.mdPobierzPobierzcie plik, dołączcie go do rozmowy z agentem używanym w projekcie i wklejcie prompt. Nie wpisujcie prywatnych spraw ani danych pracowników. Szablon ma pomóc w rozmowie, nie oceniać ludzi.
Weźmy jedno bieżące zadanie: [opis]. Przeczytaj załączony plik. Zapytaj mnie, na co czekamy, komu przekazujemy zadanie dalej i co tłumaczymy za każdym razem od nowa. Potem zapytaj, co robimy już z agentem, gdzie mu nie ufamy i gdzie potrzebujemy pomocy drugiej osoby. Pytaj po jednym temacie. Nie oceniaj ludzi ani nie proponuj zmian zatrudnienia. Na koniec pokaż podział przed i po: co ustala Product Owner, co prowadzi AI Engineer, co wykonują agenci i kto sprawdza wynik. Zapisz krótko intencję, zakres oraz to, co pokażemy na demo. Uwzględnij czas na naukę i to, co już działa. Pokaż ustalenia do sprawdzenia przed zapisaniem ich w dokumentach zespołu.
Co ma zostać po rozmowie: podział odpowiedzialności przed i po, jedno zadanie z uzgodnioną intencją, osoba prowadząca, dostępne wsparcie i termin demo. Po próbie wróćcie do pytań: co poszło szybciej, ile było poprawek i jak pracowało się ludziom. Przy legacy uwzględnijcie też przekazanie wiedzy od osób znających stary system.
Dalej: GTM i specjaliści One Man Army
Moim zdaniem rozwój oprogramowania będzie tanieć, a większe znaczenie zyska dotarcie z nim do ludzi i dostarczenie im wartości. Dlatego widzę miejsce dla GTM Engineera — od *go-to-market*, czyli wprowadzenia rozwiązania na rynek. W tym określeniu łączę znajomość technologii i AI z rozumieniem, komu pomóc, jak dostarczyć rozwiązanie i jak je sprzedać lub poprawić.
Widzę też miejsce dla specjalistów One Man Army: osób, które znają swoją dziedzinę i dzięki AI potrafią samodzielnie zbudować użyteczne rozwiązanie. To moja prognoza, a nie gwarancja niższych kosztów każdego projektu.
Zastosujcie to przy swojej roadmapie: wybierzcie jedną funkcję i zapiszcie, kto dotrze do jej użytkowników, jak pokaże im korzyść i po czym poznacie, że zaczęli z niej korzystać. Samo wdrożenie nie odpowiada jeszcze na te pytania.
Jak zmieniła się nasza praca nad AppEnergo
AppEnergo zaczęliśmy budować jeszcze przed boomem na AI. Przy projekcie pracowało blisko 15 osób, wspólnie z zewnętrznym software house’em. Z czasem zaczęliśmy korzystać z AI wewnątrz naszej organizacji i coraz wyraźniej widziałem, że dotychczasowy sposób pracy nie nadąża za nowymi możliwościami.
Ceremonie, analizy i przekazywanie wiedzy między osobami trwały zbyt długo w stosunku do tego, jak szybko mogliśmy już sprawdzać pomysły i wprowadzać zmiany. Potrzebowaliśmy zmienić cały przepływ pracy, a nie tylko dodać agentowi dostęp do kodu.
Dziś rozwijamy AppEnergo w 3–4 osoby. Z mojej perspektywy tempo rozwoju jest zbliżone do wcześniejszego. To moja obserwacja z prowadzenia projektu, nie pomiar produktywności ani porównanie identycznych zakresów pracy.
Same etapy nadal są rozpoznawalne: zrozumienie potrzeby, analiza, wykonanie, sprawdzenie i oddanie wyniku. Zmieniło się to, jak przez nie przechodzimy i jak się komunikujemy. W naszej codziennej pracy wiele przejść między nimi jest wielokrotnie szybszych. Odpowiedzialności rozłożone wcześniej między kilka osób częściej łączy dziś jedna osoba wspierana przez agentów.
Zniknął u nas dawny sztywny podział na frontend i backend. Każdy pracuje de facto fullstackowo — przechodzi przez interfejs, logikę i dane, żeby dowieźć działający fragment produktu. Nie oznacza to, że każdy ma identyczną wiedzę w każdym obszarze. Szerszy zakres pracy nadal wymaga współpracy i sprawdzenia wyniku.
Mój kierunek jest jasny: kod nie będzie powstawał tak jak wcześniej. Przejście wymaga prób, uczenia się i korekt, ale samo dołożenie AI do niezmienionych procesów nie wystarcza. Nie ma dla mnie półśrodków w docelowym sposobie pracy — do zmiany dochodzimy jednak etapami, na rzeczywistych zadaniach.
Dlatego rozmowę o AI-first zaczynam także od ludzi: co daje im satysfakcję, czego potrzebują, żeby zaufać wynikom, i jak przygotować ich do odpowiedzialności za szerszy rezultat.