Wąskie gardło wpływu GenAI na biznes

AI może przyśpieszyć 10x dostarczanie. Ale ostateczny wpływ na organizacje dalej będzie koło 1x.

Dostęp do technologii dostarczania przestał być barierą. Jak grzyby po deszczu podstawją nowe narzędzia do generacji produktów. Influencerzy prześcigają się z wypuszczaniem kursów. Osoby jak Reuven Cohen wyglądają jakby działali w przyszłości.

Jednocześnie, jak mówi Teoria Ograniczeń, zawsze istnieje wąskie gardło. GenAI usuwa problem z dostarczaniem produktów, ale nie z wpływem produktów na klientów i biznes.

Załóżmy, że dostarczanie pojedynczej funkcji skraca się nam do 0. Że mamy pomysł, odpalamy RUN i jest live na produkcji - przetestowany i z właściwą jakością. Co zostanie wąskim gardłem?

Widzę 3 potencjalne miejsca - dwa związane z pętlą Build-Measure-Learn i jedno związane z pracą wielozespołową. W artykule miały być też rozwiązania, ale ostatecznie wyszedłby z tego zbyt długi artykuł 😃

Measure

Measure to faza, w której sprawdzasz czy wprowadzone zmiany działają zgodnie z oczekiwaniami.

GenAI przyspiesza dostarczanie funkcji, ale mierzenie zachowań klientów dalej wymaga czasu i odpowiednich praktyk.

Delivery nieprzystosowane do mierzenia

Zespoły dostarczają funkcje bez planowania ich pomiaru. Data pipeline nie istnieje. Monitoring dopiero planowany. Wszystko skupia się na dostarczaniu.

GenAI nie dostarczy Ci danych od klientów - musisz je zebrać sam. Trzeba określić jakie metryki śledzić, jakie procesy mierzyć, z jaką częstotliwością i w jakim zakresie dat.

Rezultat? Garbage in, garbage out - bez mierzenia klientów jedyne co masz to wdrożenie. GenAI wygeneruje kod, ale nie zastąpi analityki produktowej.

Wolne przetwarzanie danych

Eksperymenty robisz szybko, ale wyniki otrzymujesz wolno. GenAI dostarcza funkcję w godzinę. Analiza zajmuje tydzień. Problem leży w infrastrukturze danych.

ETL działa raz dziennie w nocy. Raporty generują się manualnie. Dashboard ładuje się 20 minut. Dane z wczoraj dostajesz jutro. GenAI przyspiesza tworzenie kodu, ale nie poprawi wydajności baz danych.

Tworzy się kolejka eksperymentów czekających na wyniki:

• Funkcja A wdrożona w poniedziałek - dane w piątek

• Funkcja B wdrożona we wtorek - dane w następny poniedziałek

• Funkcja C wdrożona w środę - dane za 10 dni

Kiedy w końcu otrzymujesz informacje, zespół już pracuje nad czymś innym. Decyzje podejmowane są na podstawie przestarzałych danych.

Brak atomowych eksperymentów

Masz przed sobą plan na 10 funkcji - co robisz?

• Odpalasz 10 agentów AI

• Każdy z nich dostarcza funkcję

• Wszystkie zostają wdrożone jednocześnie

• Na końcu metryki się poprawiają

Tylko która funkcja za to odpowiada? Trudno powiedzieć...

To klasyczny problem opisany w moim artykule „Mierzenie zmian w produkcie". Zespoły dostarczają kilka funkcji naraz. Potem widzą poprawę wskaźników. Ale nie wiedzą, która zmiana za to odpowiada.

Z GenAI będzie analogicznie, tylko bardziej 😅

Learn

Learn to faza, w której wyciągasz wnioski z zebranych danych i podejmujesz decyzje o dalszych krokach. GenAI sprawia, że zespoły dostarczają więcej eksperymentów, ale organizacyjne uczenie się z ich rezultatów nie przyspiesza automatycznie.

Skupienie na dostarczaniu zabija uczenie się

Zespół mierzy się velocity i story points. Nie ma czasu na analizę wyników. GenAI przyspiesza delivery, ale nikt nie sprawdza, czy to co dostarczamy ma sens.

Metryki zespołu koncentrują się na ilości dostarczonych funkcji. Nie na ich wpływie na klientów. Sprint Review pokazuje co zostało zrobione. Nie czy to przyniosło wartość.

GenAI wzmacnia ten problem. Zespoły dostarczają jeszcze więcej funkcji w tym samym czasie. Wszyscy ogłaszają sukces, tylko że sukcesu brak.

Brak czasu na przeprocesowanie wyników

Masz wyniki eksperymentu. Wiesz, że funkcja A działa, funkcja B nie. Co dalej? Potrzebujesz czasu na zrozumienie dlaczego tak się stało.

Przeprocesowanie to proces głębszego zrozumienia wyników. Nie wystarczy wiedzieć "co". Trzeba zrozumieć "dlaczego". To wymaga dyskusji zespołowej, analizy danych, testowania hipotez.

GenAI dostarcza kolejne funkcje zanim zespół zrozumiał poprzednie:

• Poniedziałek: wyniki eksperymentu A

• Wtorek: nowy eksperyment B na produkcji

• Środa: nowy eksperyment C na produkcji

• Czwartek: wyniki eksperymentu B

Kiedy masz czas na przemyślenie wyników? Na wyciągnięcie wniosków? Na zastanowienie się nad przyszłymi eksperimentami?

Hierarchia spowalnia uczenie się

CTO potrzebuje miesiąc na zrozumienie, że kierunek jest zły. Zespół czeka. GenAI dostarcza błędne rozwiązania coraz szybciej.

Decyzje o kierunku produktu przechodzą przez hierarchię. Każdy poziom potrzebuje czasu na zrozumienie danych. W międzyczasie zespół pracuje dalej w błędnym kierunku.

Często interesariusze pracują na roadmapie, do której się zobowiązali. Wyniki eksperymentów pokazują dziury w naszym planie, sugerując zmianę kierunku. Ale trzeba dalej realizować to co zaplanowane. Bo przecież "się umówiliśmy".

Klasyczna sytuacja: zespół dostarcza 5 funkcji w tygodniu dzięki GenAI. Dyrektor produktu analizuje wyniki co miesiąc. Przez 3 tygodnie zespół rozwija funkcje, które nie działają. Marnotrawstwo rośnie wykładniczo.

Praca wielozespołowa

Praca wielozespołowa to obszar, gdzie GenAI ma wątpliwy wpływ na przyspieszenie. Może wygenerować kod dla jednego zespołu, ale nie rozwiąże problemów między zespołami. Tu leżą najgłębsze ograniczenia organizacyjny.

Lead time end-to-end

Deployment zespołu trwa 5 minut. Zmiana przez organizację przechodzi 2 miesiące. GenAI nie pomoże z wewnętrznymi procedurami i procesami.

Zespół może dostarczyć funkcję w godzinę dzięki GenAI. Ale żeby wdrożyć ją na produkcję, potrzebuje approval od bezpieczeństwa, architektów, product managerów z innych zespołów. Każdy etap to tydzień czekania.

Przykładowa ścieżka zmiany:

• Zespół A tworzy funkcję - 1 dzień z GenAI

• Approval od zespołu bezpieczeństwa - 1 tydzień

• Koordynacja z zespołem B (API) - 2 tygodnie

• Approval od architektów - 1 tydzień

• Wdrożenie przez ops - 3 dni

GenAI skrócił developement z tygodnia do dnia. Ale całość dalej trwa miesiąc.

Optymalizacja lokalna zamiast globalnej

Każdy zespół ma swój backlog, swoje metryki, swoje cele. Product Manager A walczy z Product Managerem B o priorytety. Zespół frontend ma inne cele niż backend. Optymalizujemy lokalnie, psując globalnie.

GenAI wzmacnia ten problem. Każdy zespół dostarcza więcej funkcji. Ale nie koordynują się między sobą. Rezultat?

• Zespół A optymalizuje swoją część - metryki rosną

• Zespół B niezależnie optymalizuje swoją część - jego metryki też rosną

• Globalne metryki spadają - systemy ze sobą nie współgrają

Każdy zespół lokalnie wygrywa. Organizacja przegrywa.

Chaos w decyzjach technologicznych

Zespół A wybiera MongoDB, zespół B PostgreSQL, zespół C Redis jako główną bazę. Każdy ma swoje powody. Nikt nie patrzy na całość. Zwiększamy dopasowanie zespołów do problemu, ale w organizacji rośnie technologiczny chaos.

Problem nasila się z GenAI:

• Zespoły eksperymentują szybciej z nowymi technologiami.

• GenAI samo rekomenduje kolejne serwisy do wykorzystania.

• Łatwiej stworzyć proof of concept w nowym frameworku.

GenAI może wygenerować rozwiązanie w każdej możliwej technologii. Ale kto będzie to wszystko utrzymywał?

Organizacja kończy z technologicznym zoo. Każda zmiana wymaga innej ekspertyzy. Rotacja w zespołach staje się koszmarem.

Pytanie na koniec

Które wąskie gardło wydaje Ci się najbardziej prawdopodobne? Masz może na myśli inne miejsce?