Od 10-Osobowych Zespołów Scrum do 3-Osobowych AI Pods
Contents
W świecie dostarczania oprogramowania dzieje się właśnie cicha rewolucja, a większość liderów delivery nie jest na nią gotowa.
Osiem do dziesięciu osób, dwutygodniowe sprinty, przewidywalna prędkość wytwarzania, dobrze rozumiane modele pojemności zespołu. Każdy framework dostarczania, każdy kalkulator zatrudnienia, każdy model marży w każdym software house'ie na świecie opiera się na tym założeniu.
To założenie właśnie przestaje obowiązywać.
Najnowsze dane branżowe od czołowych firm doradczych i technologicznych wskazują na fundamentalną zmianę: zespoły deweloperskie kurczą się z ośmiu–dziesięciu osób do dwóch–trzech, cykle sprintów skracają się z dwóch tygodni do jednego dnia, a wzrosty produktywności mierzy się nie w procentach, lecz w wielokrotnościach.
Nie mówimy tu o stopniowych ulepszeniach dotychczasowych sposobów pracy. Mówimy o strukturalnej zmianie w tym, jak powstaje oprogramowanie, a co za tym idzie, jak delivery organizuje się, mierzy i sprzedaje.
Jako osoba zarządzająca operacjami delivery w software house'ie, obserwuję tę zmianę od środka. Ten artykuł to nie ćwiczenie teoretyczne. To praktyczna analiza tego, co dzieje się z organizacjami delivery, gdy fundamentalna jednostka produkcji zmienia się tak drastycznie , i co liderzy delivery powinni z tym zrobić w ciągu najbliższych dwunastu miesięcy.
Trzy horyzonty AI w tworzeniu oprogramowania
Aby zrozumieć, dokąd zmierzamy, warto opisać obecny krajobraz w kategoriach trzech horyzontów adopcji, które rozgrywają się jednocześnie w całej branży.
Horyzont 1: Narzędzia. Tu dziś znajduje się większość organizacji. Deweloperzy korzystają z narzędzi do kodowania wspomaganych przez AI, GitHub Copilot, Cursor, Claude Code , by przyspieszyć indywidualne zadania. Autouzupełnianie na sterydach. Struktura zespołu pozostaje taka sama, proces pozostaje taki sam, ale poszczególni pracownicy są nieco szybsi. Wzrosty produktywności są realne, lecz skromne: co najwyżej 1,2x. Model delivery nie wymaga zmian.
Horyzont 2: Agenty. Tu zaczyna się prawdziwe zainteresowanie. Zespoły używają agentów AI do realizacji zadań end-to-end , nie tylko uzupełniania kodu, ale pełnego wdrażania funkcji, generowania testów, przeglądu kodu i dokumentacji. Struktura zespołu zaczyna się zmieniać. Wyspecjalizowane role (dedykowane QA, dedykowany frontend, dedykowany backend) zaczynają konsolidować się w szersze role „builderów" wspieranych przez agenty. Sprinty się skracają. Przekazania znikają. Produktywność skacze do 2–3x. Model delivery wymaga korekty.
Horyzont 3: Agentic Factories. Tu paradygmat całkowicie pęka. Inżynierowie nie piszą kodu z agentami , tworzą systemy agentowe, które piszą kod. Zespół liczy dwie do trzech osób: definiujący produkt i jeden lub dwóch builderów orkiestrujących przepływy pracy agentów. Praca odbywa się asynchronicznie , „dzienna zmiana", podczas której ludzie wyznaczają kierunek, przeglądają wyniki i podejmują decyzje, oraz „nocna zmiana", podczas której roje agentów wykonują zadania. Wyniki skalują się wraz ze zużyciem tokenów, a nie liczbą głów. Potencjał produktywności przekracza 10x. Model delivery trzeba zbudować od zera.
Większość dojrzałych firm technologicznych jest gdzieś między Horyzontem 1 a wczesnym Horyzontem 2. Startupy AI-native i garstka wiodących innowatorów już działają na poziomie Horyzontu 3. Przepaść między tymi grupami szybko się powiększa.
Czego nauczyło nas wdrożenie AI Pod
Chcę podzielić się konkretnym przykładem, bo abstrakcyjne frameworki przydają się tylko wtedy, gdy łączą się z rzeczywistością.
Niedawno realizowaliśmy projekt, do którego klasyczne podejście wymagałoby wieloosobowego zespołu, deweloperzy backendu, deweloperzy frontendu, QA, PM, designer, analityk biznesowy , pracujących przez około trzy miesiące, by dostarczyć MVP. Właśnie ten rodzaj zaangażowania, pod który są skrojone nasze modele pojemności, arkusze marż i szablony ofert.
Zamiast tego spróbowaliśmy czegoś innego.
Zbudowaliśmy to, co dziś nazwałbym , choć wtedy nie używaliśmy jeszcze tego określenia.
Rdzeń podu stanowił nasz najbardziej doświadczony Engineering Manager, pracujący jednocześnie z wieloma modelami AI , Claude, GPT, Gemini , nie jako asystentami do kodowania, lecz jako partnerami deweloperskimi obejmującymi cały stack. Inżynier QA i designer byli częścią podu, ale oboje współtworzyli też kod, nie ograniczając się do swoich tradycyjnych dziedzin. Analityk biznesowy pisał specyfikacje. PM pełnił rolę facylitatora i administratora.
Rezultat: w pełni działające rozwiązanie, zbudowane zgodnie z właściwymi wzorcami projektowymi, bez anty-wzorców deweloperskich ani technicznych skrótów, dostarczone w dwa miesiące zamiast trzech. Przez zespół, który pod względem liczebności był mniej więcej o połowę mniejszy niż wymagałoby tego tradycyjne zaangażowanie.
To nie był proof of concept.
To było wdrożenie produkcyjne. I nauczyło nas kilku rzeczy, których żadna lektura o AI-assisted development nie byłaby w stanie zastąpić:
Po pierwsze, seniorność ma znaczenie bardziej niż kiedykolwiek. Nasz Engineering Manager mógł skutecznie orkiestrować wiele modeli AI właśnie dlatego, że miał architektoniczny osąd, który pozwalał mu oceniać wyniki, , egzekwować wzorce i podejmować decyzje projektowe, których modele nie potrafiły podjąć samodzielnie.
Junior deweloper używający tych samych narzędzi nie osiągnąłby tego samego rezultatu , wyprodukowałby więcej kodu szybciej, ale gorszej jakości.
Po drugie, granice ról zacierają się. Gdy AI przejmuje mechaniczną pracę wdrażania, rozróżnienie między „deweloperem frontendu" a „deweloperem backendu" traci na znaczeniu. Liczy się to, czy ktoś potrafi jasno zdefiniować problem, krytycznie ocenić rozwiązanie i szybko iterować. Nasz inżynier QA pisał funkcje.
Nasz designer implementował komponenty. Tradycyjna macierz ról przestała obowiązywać.
Po trzecie, wąskie gardło przesuwa się. W tradycyjnym zespole ograniczeniem jest zazwyczaj pojemność deweloperska , brakuje rąk do pisania kodu. W AI Pod ograniczeniem jest przepustowość decyzyjna. Ludzie w pętli muszą podejmować więcej decyzji na godzinę: przeglądać wyniki, akceptować lub odrzucać sugestie, przekierowywać pracę agentów, rozwiązywać niejasności.
To jest wymagające poznawczo w inny sposób niż tradycyjne tworzenie oprogramowania.
Co zmienia się w modelu operacyjnym delivery
Jeśli zarządzasz delivery w software house'ie lub kierujesz inżynierią w firmie produktowej, skutki tej zmiany dotykają niemal każdego elementu Twojego modelu operacyjnego. Przejdźmy przez kluczowe obszary.
Struktura zespołu i definicje ról
ma dobrze zdefiniowane role z wyraźnymi granicami: project manager, Scrum master, tech lead, senior developer, mid developer, junior developer, inżynier QA, designer, analityk biznesowy. Modele obsady personalnej buduje się wokół tych ról. Cenniki je wyceniają. Macierze kompetencji je oceniają.
W modelu AI Pod role konsolidują się dramatycznie. Na podstawie tego, co obserwujemy, zarówno wewnętrznie, jak i w całej branży , wyłaniający się archetyp zespołu wygląda mniej więcej tak:
Product Definer (ewolucja tradycyjnej roli PM/PO), który odpowiada za wyniki biznesowe, wyznacza cele, definiuje progi jakości dla przepływów agentycznych i weryfikuje, czy efekty pracy są zgodne z intencjami użytkowników i interesariuszy. Ta osoba potrzebuje głębszej znajomości technikaliów niż tradycyjny product manager, bo ocenia rezultaty generowane przez AI , nie tylko pisze kryteria akceptacji dla ludzi.
Tech Lead (ewolucja, bliżej dziś principal engineera) rozumiejący pełny stack produktu i platformy, kierujący decyzjami technicznymi i dbający o skalowalną, bezpieczną, wysokiej jakości delivery. W kontekście AI Pod ta osoba pełni też rolę głównego „orkiestratora" agentów AI , wybiera, który model stosować do którego zadania, projektuje przepływy agentów i utrzymuje spójność architektury.
Builder (ewolucja tradycyjnej roli developera) prowadzący codzienny cykl wytwarzania oprogramowania, skupiony na walidacji i przeglądaniu artefaktów generowanych przez AI oraz na ich ręcznym tworzeniu tam, gdzie agenci zawodzą. Ta osoba może też odpowiadać za doskonalenie samej fabryki agentycznej , dopracowywanie promptów, budowanie własnych agentów i optymalizację przepływów.
Zauważ, czego brakuje: dedykowanego QA, dedykowanego podziału frontend/backend, Scrum mastera, juniorów jako samodzielnej roli. Nie oznacza to, że testowanie znika ani że specjalizacja przestaje mieć znaczenie. Oznacza to, że te kompetencje zostają wchłonięte przez mniej liczne, bardziej seniorsie, bardziej wszechstronne role.
Dla liderów delivery rodzi to natychmiastowe wyzwanie: Twoje modele obsady personalnej, ramy kompetencyjne i ścieżki kariery muszą ewoluować. Ścieżka PM → Senior PM → Delivery Lead nadal ma sens, ale umiejętności na każdym poziomie wyglądają inaczej. Delivery Manager w 2027 roku musi rozumieć , ekonomię tokenów i pomiar oparty na wynikach , nie tylko przepływy w Jirze i wykresy burndown.
Planowanie pojemności i wykorzystanie zasobów
Tradycyjne planowanie pojemności jest stosunkowo proste: masz X osób, każda dostępna przez Y godzin tygodniowo, zaangażowana na Z% wykorzystania. Mnożysz i znasz swoją pojemność. Przychód jest funkcją liczby pracowników, stawki i wykorzystania.
W modelu AI Pod to równanie się rozpada.
Wynik nie koreluje już liniowo z liczbą osób w zespole. Trzyosobowy pod, skutecznie korzystający z AI, może wyprodukować to, co wcześniej wymagało dziesięcioosobowego zespołu, ale struktura kosztów jest inna.
Masz mniej, za to droższych ludzi (seniorzy żądają wyższych stawek) . Wykorzystanie jako metryka traci na znaczeniu, bo czynnikiem ograniczającym nie są dostępne godziny, lecz podjęte decyzje i dostarczone wyniki.
Dla software house'ów ma to szczególnie głębokie konsekwencje.
Cały model biznesowy tradycyjnego software house'u opiera się na sprzedawaniu czasu , czy to w formie T&M, czy zapakowany jako fixed-price z wewnętrznymi szacunkami czasowymi.
Gdy trzyosobowy zespół dostarcza w dwa miesiące to, co wcześniej zajmowało dziesięcioosobowemu trzy miesiące, stoisz przed wyborem: czy wyceniasz według starego nakładu pracy (i przejmujesz ogromną marżę), według nowego nakładu (i kompresujesz przychody), czy według dostarczonego wyniku (i całkowicie zmieniasz model biznesowy)?
Moim zdaniem branża będzie przesuwać się , powoli, lecz nieuchronnie , w stronę wyceny opartej na wynikach i wartości. Nie dlatego, że jest to filozoficznie lepsze, ale dlatego, że zmuszają do tego ekonomia. Gdy Twój koszt produkcji spada o 60–70%, a wartość dla klienta pozostaje ta sama, wycena oparta na czasie jest coraz trudniejsza do uzasadnienia i łatwiejsza dla klientów do zakwestionowania.
Zdrowie projektu i metryki
Większość organizacji delivery śledzi standardowy zestaw metryk: velocity, burndown, cycle time, gęstość defektów, a czasem earned value (EVM) dla projektów fixed-price. Te metryki zakładają stabilny zespół pracujący w regularnych rytmach.
W modelu AI Pod metryki muszą się zmienić. Oto jak wyobrażam sobie nowy dashboard:
Czas od pomysłu do dostarczenia zastępuje velocity jako główną miarę. Gdy sprinty skracają się z dwóch tygodni do jednego dnia, mierzenie story pointów na sprint traci sens. Liczy się to, jak szybko potrzeba biznesowa przekłada się na działające oprogramowanie.
Przepustowość decyzji staje się wiodącym wskaźnikiem. Ile cykli przegląd-akceptacja-odrzucenie mogą obsłużyć członkowie zespołu ludzkiego dziennie? To jest prawdziwe wąskie gardło w AI Pod i jeśli spada, wszystko zwalnia.
Wskaźnik akceptacji wyników AI mówi Ci o skuteczności Twojego ustawienia agentycznego. Jeśli ludzie odrzucają 50% kodu generowanego przez AI, Twoje prompty, kontekst lub dobór modelu wymagają pracy. Jeśli akceptują 95%, możliwe, że nie przeglądają wystarczająco krytycznie.
Metryki wynikowe (adopcja przez użytkowników, KPI biznesowe, satysfakcja klienta) zyskują na znaczeniu, bo model delivery wprost optymalizuje pod wyniki, a nie pod output.
Tradycyjny EVM nadal działa w projektach fixed-price, ale wymaga rekalibracji. Twoje krzywe planned value będą wyglądać zupełnie inaczej, gdy trzyosobowy zespół dostarcza funkcjonalności w tempie 3–5 razy szybszym niż tradycyjny zespół.
Modele zaangażowania i relacje z klientami
To być może najbardziej znacząca zmiana z punktu widzenia biznesowego. Gdy Twoje możliwości delivery zmieniają się tak fundamentalnie, sposób, w jaki angażujesz klientów, musi zmienić się razem z nimi.
Tradycyjne zaangażowanie software house'u wygląda tak: klient potrzebuje zbudowanego produktu, proponujesz zespół (zazwyczaj pięć do dziesięciu osób), uzgadniacie stawkę lub fixed-price, zespół pracuje przez kilka miesięcy, dostarczasz. Propozycja to w istocie plan obsady personalnej z harmonogramem.
Zaangażowanie AI Pod wygląda inaczej: klient potrzebuje gotowego produktu, Ty proponujesz określony wynik (działające MVP, zestaw funkcji, zakończona migracja), zobowiązujesz się do harmonogramu i standardu jakości, wdrażasz mały pod, który klient może prawie nie widzieć, i dostarczasz. Propozycja to dokument zakresu i oczekiwanych wyników – nie plan kadrowy.
To fundamentalnie zmienia rozmowę z klientem. Nie sprzedajesz już mocy przerobowych. Sprzedajesz kompetencje i szybkość. Pytanie przestaje brzmieć „ilu deweloperów będzie nad tym pracować?", a zaczyna: „jak szybko to dostarczysz i ile to będzie kosztować?"
Dla liderów delivery oznacza to konieczność przemyślenia sposobu definiowania zakresu projektów, pisania propozycji, kształtowania oczekiwań klientów oraz zarządzania relacją w trakcie realizacji. Klient przyzwyczajony do widoku ośmiu osób na codziennym standup może czuć się niekomfortowo, gdy zobaczy trzy – nawet jeśli te trzy osoby dostarczają szybciej.
Pięć decyzji, które liderzy delivery muszą podjąć w ciągu najbliższych dwunastu miesięcy
Zakończę czymś konkretnym. Jeśli zarządzasz delivery w firmie technologicznej, oto decyzje, których nie możesz odkładać.
1. Zdefiniuj swój archetyp AI Pod. Jak wygląda minimalny wykonalny zespół dla Twojego najczęstszego typu projektu? Jakie role obejmuje? Jakie poziomy seniority? Z jakich narzędzi AI i modeli korzysta? Potrzebujesz powtarzalnego szablonu, a nie jednorazowych eksperymentów.
2. Przeprojektuj swój framework kompetencyjny. Ścieżki kariery i kryteria oceny muszą uwzględniać umiejętności orkiestracji AI, wszechstronność cross-funkcjonalną oraz podejmowanie decyzji w warunkach niepewności. Starszy deweloper, który nie potrafi efektywnie współpracować z agentami AI, nie jest seniorem w 2027 roku.
3. Przetestuj wycenę opartą na wynikach w co najmniej jednym projekcie. Nie musisz z dnia na dzień transformować całego modelu cenowego. Musisz jednak zacząć poznawać, jak delivery oparte na wynikach działa operacyjnie – jak definiujesz zakres, jak śledzisz postępy, jak zarządzasz ryzykiem marży. Wybierz mały projekt i przeprowadź eksperyment.
4. Przebuduj swój model pojemności. Jeśli Twoje planowanie nadal zakłada liniową korelację między liczbą osób a efektami, jest błędne. Zbuduj nowy model uwzględniający , koszty tokenów oraz wyższy koszt przypadający na osobę w zespołach zdominowanych przez seniorów.
5. Inwestuj w seniorskie talenty – bez kompromisów. Model AI Pod działa na seniority. Utalentowany junior z narzędziami AI jest wartościowy, ale nie zastąpi architektonicznego osądu, rozpoznawania wzorców i szybkości podejmowania decyzji charakterystycznej dla doświadczonego inżyniera, który buduje systemy od piętnastu lat. Walka o seniorskie talenty zaraz znacząco się zaostrzy.
Transformacja nie zajdzie z dnia na dzień – ale będzie szybsza, niż myślisz
Chcę być precyzyjny: nie sugeruję, że każdy zespół powinien jutro stać się trzyosobowym AI Pod. Transformacja będzie stopniowa, nierównomierna i zależna od kontekstu. Silnie regulowane branże będą się zmieniać wolniej. przez dłuższy czas będą wymagać większego udziału ludzkiego osądu. Niektóre typy projektów nadal będą lepiej obsługiwane przez większe zespoły.
Kierunek jest jednak bezsporny.
Fundamentalna jednostka produkcji oprogramowania się kurczy, szybkość dostarczania przyspiesza, a ekonomia tworzenia oprogramowania ulega restrukturyzacji. Liderzy delivery, którzy to rozumieją i odpowiednio dostosowują swoje modele operacyjne, zdobędą znaczącą przewagę konkurencyjną. Ci, którzy poczekają, aż zmiana stanie się oczywista, znajdą się z modelem operacyjnym zaprojektowanym dla świata, który już nie istnieje.
Pytanie nie brzmi, czy Twój model delivery się zmieni. Pytanie brzmi, czy poprowadzisz tę zmianę, czy pozwolisz, by Cię ona wyprzedziła.
