Mam dwie książki, które ukształtowały moje myślenie o produkcie: Inspired Marty’ego Cagana i Gestão de Produtos Joki Torresa, u którego na dodatek miałem szczęście odbyć mentoring. Przez lata te dwie były moją mapą: kim jest PM, kim jest product designer, kim jest inżynier, kto co robi. Każda rola z wyraźnym konturem.
Przez ostatni rok, patrząc, jak mój zespół pracuje z AI w Prolog, zacząłem czuć, że te kontury się rozmywają. Nie żeby książki stały się błędne: to warstwa, na której dzieje się każda rola, podniosła się.
W pierwszym tekście z serii opowiedziałem o niepokoju, który kazał mi zacząć przebudowę tech w Prolog, a w drugim, czym jest harness, infra, dzięki której AI naprawdę dowozi. Na końcu pierwszego obiecałem otworzyć jedną konkretną część: jak zmienia się praca każdego stanowiska, gdy to AI zaczyna budować. I o tym jest ten tekst.
Praca nie znika, wchodzi o warstwę wyżej
AI nie wymazuje roli każdego zawodu, zmienia warstwę, na której się on dzieje.
Łatwa interpretacja, ta, która sprzedaje strach, brzmi „AI zastąpi stanowisko X”, i nie to widziałem. Widziałem, jak treść pracy zmienia miejsce: to, co wcześniej było robieniem, stało się kierowaniem i krytykowaniem tego, kto robi.
Inżynier, który pisał kod, teraz sprawdza to, co napisał agent. PM, który pisał speca, teraz ocenia prototyp, który z niego powstał w kilka godzin. Człowiek jest ten sam, zmieniło się narzędzie w jego ręku.
Kiedy wróciłem do Cagana i Joki z tym w głowie, olśnienie przyszło inaczej. Obaj opisują, starannie, wykonanie każdej roli (konkretne zadanie, deliverable, to, co pod koniec dnia wychodzi z twoich rąk), i to właśnie przejmuje AI. Człowiekowi zostaje druga połowa: zdecydować, co warto zbudować, znaleźć dziurę w tym, co zbudowano, mieć taste, żeby wiedzieć, co jest dobre. Osąd, nie wykonanie.
Zrobię więc to, co zrobiłem u siebie: wziąć definicję każdej roli z książek i zapytać, co z niej AI zjada, a co zostaje (i staje się droższe).
Zespół trójki, według książek
Zanim rozłożę to rola po roli, warto przypomnieć, jak książki składają zespół. Joca jest bezpośredni: udany produkt musi być pożądany, opłacalny i możliwy do zbudowania, i to definiuje „trzy niezbędne funkcje do stworzenia udanego produktu” (rozdz. 2): projektant UX, product management i deweloper, trójka, którą nazywa core team. Cagan, w Inspired, opisuje te same role w rozdziale otwierającym, „Key Roles and Responsibilities”.
Obaj podkreślają punkt, do którego wrócę na końcu: to nie relacja szefa i podwładnego. Słowami Joki, „inżynieria produktu, product management i UX to zespół, między żadną z tych grup nie ma podległości” (rozdz. 31), a u Cagana ta sama myśl brzmi tak, że PM i inżynieria są „równi sobie, żadna pozycja nie jest podporządkowana drugiej” (rozdz. 5, w moim tłumaczeniu). A gdy AI wchodzi w środek tej trójki, to właśnie to partnerstwo najbardziej zmienia kształt.
Tabela: każdy zawód w tech awansuje o warstwę. Inżynieria z producenta kodu staje się krytykiem agenta; produkt, ze spec writera architektem iteracji; design, z producenta ekranów dyrygentem eksperymentu; jakość, z testera budowniczym walidacji.
Rola każdego zawodu w tech
Ta sama rola, o warstwę wyżej
wykonanie przechodzi do agenta · osąd zostaje przy tobie: decydować, krytykować, mieć gust
Inżynier: od producenta kodu do krytyka agenta
W inżynierii liczy się już nie to, ile kodu produkujesz: liczy się to, jak dobrze krytykujesz to, co wyprodukował agent.
Definicja Joki jest tak jasna, że aż boli czytać ją teraz: „inżynieria produktu odpowiada za rozwój produktu i utrzymanie go w działaniu”, a dalej, inżynieria „buduje produkt” (rozdz. 31). Budować było czasownikiem. Cagan dopełnia to z drugiej strony, mówiąc o relacji z produktem: „product manager odpowiada za zdefiniowanie rozwiązania, ale to zespół inżynierii wie najlepiej, co jest możliwe, i to on ostatecznie dowozi to rozwiązanie” (rozdz. 5, w moim tłumaczeniu). Definiować z jednej strony, dowozić z drugiej.
Teraz dowiezienie pierwszej wersji należy do agenta. To, co się nie zmieniło, a stało się droższe, to wszystko, co Cagan przypisywał inżynierowi jako źródło innowacji: „inżynierowie wiedzą lepiej niż ktokolwiek, co jest możliwe” (rozdz. 5). Wiedzieć, co jest możliwe, znaleźć dziurę w planie, który zaproponował agent, dostrzec trade-off wydajności albo bezpieczeństwa, którego on nie widzi, zdecydować, kiedy wejść, a kiedy dać temu biec. To waży coraz więcej z każdym miesiącem. Składnia z pamięci, boilerplate ręcznie, przeczesywanie Stack Overflow, ilość kodu jako osobiste trofeum: to waży mniej.
W Prolog powiedziałem to zespołowi wprost: nikt nie będzie oceniany po liniach kodu. Kto zawsze był dobry w „znajdowaniu dziur”, staje się cenniejszy, a kto utożsamiał się z „produkowaniem dużo kodu szybko”, będzie musiał przekalibrować, gdzie inwestuje. I to nie umniejsza inżynierii. Jej wartość zawsze tkwiła bardziej w wiedzy o tym, co się nadaje, niż w szybkim produkowaniu, a teraz to po prostu staje się jawne.
PM: od spec-writera do architekta iteracji
PM czuje to, gdy prototyp staje się tani: jego praca przestaje być pisaniem dokumentu, a staje się wyborem, który pomysł zasługuje na czas zespołu.
Cagan jest kategoryczny co do sedna tej pracy: „ktoś musi odkryć, czym jest rozwiązanie, produkt, wraz z funkcjonalnościami, doświadczeniem użytkownika i kryteriami wydania. Tym kimś jest product manager, i to zadanie jest sednem jego pracy” (rozdz. 1, w moim tłumaczeniu). Joca zarysowuje to szeroko: product management to „funkcja odpowiedzialna za wszystkie aspekty produktu cyfrowego, przez cały cykl życia tego produktu, od jego koncepcji aż po koniec życia” (rozdz. 2).
Zauważ, że u obu słowem kluczowym jest odkryć, nie wyspecyfikować. Cagan ma cały rozdział poświęcony obronie tezy, że praca to discovery, nie „wymagania”: software ma dwa etapy, „odkryć, co budować (właściwy produkt), i zbudować (produkt we właściwy sposób). Pierwszy zdominowany jest przez discovery, drugi to wykonanie” (rozdz. 12, w moim tłumaczeniu). To zawsze było jego przesłaniem, a AI tylko uczyniła je dosłownym.
Bo gdy build kurczy się z tygodni do godzin, wąskim gardłem przestaje być budowanie, a staje się decydowanie, co warto zbudować. Długi spec przeglądany w komitecie, zamknięte planowanie kwartalne, status report jako deliverable, kierowanie ruchem między inżynierią a designem: to wszystko waży mniej. Więcej waży szybki discovery (prototypować, żeby zrozumieć, nie specować, żeby budować), kuratorstwo hipotez (który pomysł zasługuje na czas zespołu) i decydowanie, czego nie robić, częściej. Niektóre firmy nazywają już takiego PM-a „Edytorem” albo „Architektem”. To nie mniej PM: to inny PM, ten, kto kuratoruje, kto decyduje z taste, kto nadaje kierunek. To, co było centralne w starym, pisanie speca, właśnie zrobiło się lekkie.
Product designer: od producenta ekranów do dyrygenta eksperymentu
W designie jednostka pracy przenosi się z ekranu na system, który produkuje ekrany, a product designer zaczyna wybierać, która wariacja przetrwa.
U Joki definicja UX to zrozumieć, żeby projektować: „UX odpowiada za dogłębne zrozumienie użytkownika i problemu, który chce się dla niego rozwiązać” (rozdz. 32). A przepływ, który opisuje, to rytuał, który każdy zna: prototyp papierowy, potem wireframe, potem „wizualny projektant UX zaczyna nadawać tym ekranom kolor i formę”. Cagan tnie tę rolę na dwie tą samą logiką: interaction designer „rozwija głębokie zrozumienie użytkowników i tworzy zadania, nawigację i przepływ”, odwzorowuje to w wireframe’ach i przekazuje visual designerowi, który „obleka wireframe w ciało” (rozdz. 4, w moim tłumaczeniu).
Ten łańcuch, zrozumieć, naszkicować, dopracować ekran po ekranie, to właśnie to, co AI skraca. Jednostka pracy przestaje być „ekranem”, a staje się „systemem, który generuje ekrany”. Przerabianie tej samej wariacji pięć razy w Figmie, specyfikowanie komponent po komponencie, pixel-perfect handoff jako obrzęd: waży mniej. Prototypowanie w tempie iteracji (kilka opcji równolegle, odrzucasz złe), definiowanie systemu wizualnego zamiast każdego ekranu z osobna i szybka krytyka wizualna (zobaczyć, jak AI coś proponuje, i rzutem oka wychwycić, że jest źle, zanim wychwyci to użytkownik): waży więcej.
I tu Cagan mówi, jeszcze w 2008 roku, coś, co chroni product designera przed poczuciem, że stał się klikaczem przycisków: jego praca nigdy nie polegała tylko na ładnym rysowaniu. „Dobry produkt wymaga dobrego doświadczenia użytkownika. A dobre doświadczenie wymaga bliskiej współpracy produktu i designu” (rozdz. 4, w moim tłumaczeniu). AI generuje wariację, a o tym, która z nich zasługuje, żeby dotrzeć do użytkownika, wciąż decyduje człowiek z taste.
QA: od testera do budowniczego walidacji
QA to przypadek najciekawszy, bo to rola, którą książki ledwie wyodrębniły, i ta, którą AI rusza najbardziej.
Zauważ: w trójce Joki (designer, PM, deweloper) i w rolach Cagana jakość pojawia się rozproszona, jako odpowiedzialność zespołu, nie jako własne krzesło z własną metodą. Przez długi czas to miało sens, ale teraz już nie ma, a powód jest prosty: jeśli agent buduje szybko, a walidacja pozostaje ręczna, to wyprodukowałeś tylko dług techniczny na dużej prędkości.
Więc QA przestaje być tym, kto ręcznie odpala przypadek testowy, a staje się tym, kto projektuje testing harness, system, który testuje system: skonfigurować AI, żeby pisała testy do kodu, który napisała inna AI, wykrywać regresję zanim zrobi to użytkownik, myśleć o tym, gdzie defekt zwykle się pojawia. W praktyce stało się to pytaniem operacyjnym, które przyjęliśmy: każdy bug, który się prześlizgnie, zamienia się w „jak wykryjemy to automatycznie następnym razem?”. Wyczerpujący ręczny test znanego przepływu, regresja odpalana ręcznie przy każdym release, QA jako jedyna bramka przed wdrożeniem: waży mniej. Walidacja jako system, nie jako podanie piłki na końcu taśmy.
To rola, która najbardziej podnosi się o warstwę właśnie dlatego, że była najsłabiej zdefiniowana. Tam, gdzie książki nie wyryły konturu, AI rysuje nowy.
Stała: to, co książki już mówiły, że liczy się najbardziej
Jest jedna rzecz, która się nie zmienia, i była ukryta na widoku w obu książkach: to, co stawiają jako najważniejszą cechę, to dokładnie to, czego AI nie robi.
Joca otwiera rozdział o cechach dobrego PM-a bez owijania: „najważniejsza ze wszystkich jest, bez cienia wątpliwości, empatia” (rozdz. 4). To nie tabela funkcji ani deliverable: to zdolność postawienia się na miejscu tego, kto używa. Cagan ze swojej strony spędza całą książkę, broniąc discovery, taste i osądu ponad procesem, i obaj, każdy na swój sposób, mówili to samo: tego, co oddziela dobrego od przeciętnego, nigdy nie stanowiła mechaniczna część pracy.
A mechaniczna część to właśnie ta, która poszła do agenta. Napisać speca, zaprojektować ekran, napisać kod, odpalić test. To, co zostało, i stało się droższe, to zmysł krytyczny, taste (wiedzieć, co jest dobre), osąd w niejednoznaczności, ciekawość, troska o tego, kto używa tego, co robisz. Podsumowując zdaniem, którego użyłem z zespołem: treść pracy się zmienia, człowiek, który ją wykonuje, nie.
Diagram w dwóch warstwach. Na górze to, co zostało przy nas i stało się droższe: taste (wiedzieć, co jest dobre), osąd w niejasności, empatia wobec użytkownika, decydować, czego nie robić, to, co książki już mówiły, że liczy się najbardziej. Praca awansowała o warstwę. Na dole to, co poszło do agenta: pisać speca, projektować ekran, pisać kod, odpalać ręczny test.
Zostało przy nas · i stało się droższe
to, co książki już mówiły, że liczy się najbardziej
praca awansowała o warstwę
Poszło do agenta
Co to będzie kosztować (bez frazesów)
Nie chcę zamykać tego zbyt ładnie, bo takie nie jest. Ta zmiana kosztuje konkretne rzeczy, i żadna nie jest wygodna.
Pierwsza to zostawić za sobą nawyki z dekady. Kto od pięciu, dziesięciu lat tkwi w starym sposobie, nosi wzorce, które pomogły dojść aż tu, i to właśnie te wzorce ciążą przy zmianie. Nie ma skrótu, a dyskomfort jest do przewidzenia.
Potem, krytykować AI tak samo, jak z nią tworzyć: przyjąć sugestię, która się pojawiła, to nie praca; znaleźć dziurę w planie, który zaproponowała, już tak. To, co zawsze było drogie (myślenie krytyczne, taste, osąd), staje się droższe.
Jest też mylić się jako zespół, nie jako jednostka. Nie zwalniamy inżyniera za bug na produkcji, poprawiamy review, a gdy AI się myli, to harness wzmacniamy. Bug agenta to proces, nie człowiek: zobowiązanie, nie slogan.
I najbardziej niewygodne: przyjąć, że niektóre funkcje zmieniają się bardziej niż inne. To rodzi dyskomfort u tych, którzy do tej pory zmienili się mało, i nie da się udawać, że wszystko jest tak samo. Da się natomiast wynieść to na otwartą rozmowę.
I żeby nie brzmieć jak ktoś, kto dotarł do celu: Prolog jest wciąż na początku tego. Nadal jesteśmy AI-assisted, z zyskiem 10 do 20%, nie AI-first na poziomie 5x czy 10x. Opowiadam o kierunku, który budujemy, z trafieniami i z błędami, nie o zwycięstwie.
Co z tego wynoszę
Książki nie stały się błędne. Opisywały wykonanie każdej roli z precyzją, którą naprawdę zrozumiałem dopiero teraz (napisać speca, zaprojektować ekran, zbudować produkt, odpalić test), a to wykonanie należy teraz do agenta. Człowiekowi została druga część, oceniać, krytykować, mieć taste, dbać o tego, kto używa, co, wracając do Cagana i Joki, jest tym, co mówili, że liczy się najbardziej, od pierwszej strony.
Może to jest ta dobra strona: praca, którą AI zabrała nam z rąk, to ta najbardziej powtarzalna, a to, co zostawiła, to to, co zawsze było najtrudniejsze i najciekawsze. Będę dalej opowiadał, jak idzie.
Źródła
- Marty Cagan, Inspired: How to Create Products Customers Love (1. wydanie, 2008). Definicje ról pochodzą z rozdziałów 1 (Key Roles and Responsibilities), 4 (Product Management vs. Design), 5 (Product Management vs. Engineering) i 12 (Product Discovery). Tłumaczenia fragmentów są moje.
- Joca Torres, Gestão de produtos: Como aumentar as chances de sucesso do seu software (Casa do Código). Definicje pochodzą z rozdziałów 2 (Czym jest zarządzanie produktami cyfrowymi?), 4 (Główne cechy managera produktu), 31 (Inżynieria produktu i product management) i 32 (UX i product management).
- Odczyt o roli wchodzącej o warstwę wyżej wspiera całą serię: OpenAI, Harness Engineering, i Peter Pang, CTO CREAO.