Przyszłość zarządzania projektami IT

Nudny wstęp

W 2006 roku obroniłem pracę doktorską po 4 lata zbierania materiałów i pisania. Źródłem dla niej były wdrożenia naszego systemu zarządzania wiedzą Pyton, który na tamte lata był nowatorskim rozwiązaniem. Oferował analizę języka naturalnego, elementy strukturalizacji treści, wyszukiwanie, kategoryzację. Jednak biznesowo Pyton okazał się klapą, a wnioski z badań prowadziły do smutnych konkluzji, że zarządzanie wiedzą nie ma przyszłości. Oczywiście wiedza jest coraz bardziej potrzebna ludziom i firmom, ale idea, że da się nią zarządzać nie znajdywała potwierdzenia. Barier można było zauważyć kilka:

Technologiczna - ówczesne algorytmy słabo radziły sobie z analizą tekstów pisanych językiem naturalnym. Istniały próby oceny ważności poszczególnych wyrazów i fraz (o tokenach nikt nie słyszał), próbowano implementować mechanikę gramatyczną (w polskim języku było to szczególne wyzwanie), jednak brakowało algorytmów wyczuwających kontekst i intencję człowieka. Szczytem myśli technologicznej znajdującej zastosowanie w biznesie była autokorekta w Word i wyszukiwanie algorytmem page rank w Google. Podejście skryptowe, takie jak w słynnym chatbot Eliza czy ekspertowe, było już dawno uznane za ślepą uliczkę ze względu na brak elastyczności. Niestety sztuczna inteligencja wówczas działała tylko dla wąskich problemów, nie istniały rozwiązania ogólnego zastosowania, do wymyślenia transformerów brakowało ponad dziesięciu lat.
Motywacji - odkryliśmy, że wielu pracowników traktuje wiedzę jak władzę, jaką mają w organizacji. “Ja wiem, inni nie wiedzą, więc jestem niezbędny”, albo “Jak powiem wszystko, co wiem, to mnie zwolnią”. Niewielu ludzi i tak jest moim zdaniem do dzisiaj reprezentuje model mentalny nastawiony na rozwój, a raczej skupia się na utrzymaniu status quo (cytuję za Carol Dweck). Gdy w systemie zarządzania wiedzą uruchomionym w jednej z większych firm finansowych uruchomiliśmy grupy dyskusyjne, to okazało się po paru miesiącach, że generalnie są martwe. Ludzie nie chcą rozmawiać o pracowych tematach w oficjalnym medium. Za wyjątkiem jednej - gdzie wokół miasta znajdują się fajne łowiska. Okazało się, że firma zatrudnia wielu zapalonych wędkarzy.
Kosztu osobistego - dzielenie się wiedzą obnaża mechanizm racjonalnej ignorancji. Moja chęć do wyszukiwania informacji jest odwrotnie proporcjonalna do takiej formuły: P * C, gdzie
P - wiara, że nie znajdę potrzebnej informację w bazie wiedzy,
C - oczekiwany koszt potrzebny na przeszukanie bazy wiedzy.
Koszty w tamtych czasach był wysoki, więc wiara w istnienie potrzebnej informacji w bazie wiedzy też musiała być spora, aby ktoś w ogóle zacząć szukać. Już łatwiej było zadzwonić do przyjaciela z innego piętra, albo pójść na fajkę.
Ten koszt osobisty okazał się jeszcze bardziej dojmujący w inny obszarze - dostarczania wiedzy. Stworzenie artykułu pod potencjalnego czytelnika to często koszt kilku godzin pracy. A jeżeli zada nieco inne pytanie, to mój artykuł może nie zostać znaleziony, albo może zostać opacznie zrozumiany (taką wątpliwość szczególnie często zgłaszali prawnicy). Skoro tak, to jakie są szanse, że ktoś skorzysta z moich treści. A skoro nie skorzysta to, po co je w ogóle tworzyć.
I pętla racjonalnej ignorancji zamykała się. Ludzie nie szukali w bazie, bo przecież tam nic niema. Inni ludzie nie pisali treści do bazy, bo przecież tam nikt nie szuka.
Wiarygodności - szybko w głowach pracowników pojawiła się wątpliwość, czy to, co znajdują w bazie jest rzetelne. Co się stanie, gdy postąpię tak, jak jest napisane i popełnię błąd. Kto będzie za to odpowiadał: autor artykułu, czy ja? To może lepiej zapytam szefa, on i tak bierze odpowiedzialność za moje poczynania. W efekcie okazało się, że zarządzanie wiedzą ma sens tylko w obszarze powtarzalnych procesów, gdzie wiedza jest mocno ustandaryzowana, np. Call center, decyzje kredytowe, windykacja, sprzedaż.

Kolejne dwadzieścia lat pokazały, że zarządzanie wiedzą w postaci scentralizowanej i sformalizowanej słabo działa. To, co działa, to osobista chęć ludzi do uczenia się, relacje z mądrymi kolegami i kameralne, nieformalne spotkania, jak wspólnoty praktyków, czy retrospektywy, czy rozmowy w kuchni.

Jednym z istotniejszych wniosków, obok tego, że ludzie nie korzystają powtórnie z wytworzonej wiedzy, tylko ciągle pytają kolegów, była ogromna asymetria wiedzy. W moich badaniach wyszło, że maksymalnie 3% odpowiedzi była odczytywana przez osobę inną niż ta, która zadała uprzednio pytanie.

Drugim wnioskiem było to, że niewielka grupa pracowników wytwarzała zdecydowaną większość odpowiedzi, czy to w bazie wiedzy, czy to przez telefon, czy to w trakcie rozmów przy kawie. Większość raczej poszukiwała wiedzy, jak handlowcy, którzy chcieli dowiedzieć się o zasady sprzedaży produktu, obsługa klienta, która nie umiała odpowiedzieć na reklamację, czy księgowość, która dostawała dane i nie była pewna, jak je interpretować. Dobrze ilustruje to poniższy wykres.

W obliczu wątpliwości o przyszłość zarządzania wiedzą przeniosłem się do świata zarządzania projektami i od dwudziestu lat praktykuję i uczę tego tematu. Z czasem potrzeby rynku i osobiste zainteresowanie nakierowały mnie na projekty IT w szczególności. Z kolegami uruchomiliśmy studia podyplomowe dla kierowników projektów i analityków biznesowych. Przez mój kraj przetoczyła się najpierw fala zainteresowania kanonami zarządzania projektami zawartymi w PRINCE2, PMBOK Guide, Ten Step, CCPM, IPMA i pewnie paru innych

Fala zainteresowania metodykami kaskadowymi była trochę przesunięta w czasie względem fali dotyczącej Scrum.

Dobrze ilustruje to poniższy wykres trendów wyszukiwania w Google w światowym internecie.

Jak widać fala kaskadowa nie może się równać skali zainteresowania fali Scrum, ale nawet Scrum od kilku lat sukcesywnie opada w wyszukiwaniach. Jakiś czas temu zaryzykowałem termin zarządzanie strugą zadań (https://octigo.pl/news/8AD6QjXM6ekwEoytIg1t). Presja na innowacyjność stale rośnie, skracają się cykle życia kolejnych produktów, przełomy technologiczne następują coraz szybciej, a AI tylko obiecuje to wszystko jeszcze bardziej przyspieszyć. Więc organizacje działają w coraz większej “bieżączce”.

Gdy byłem na studiach uczono mnie, że perspektywa strategiczna firm powinna sięgać 10-20 lat. Potem skróciła się do 3-5 lat i na tyle przygotowywane były prezentacje strategiczne. Bank, w którym pracowałem miał plan strategiczny na następny rok. Teraz mam wrażenie, że wiele firm wie, co będzie robić w ciągu najbliższego półrocza.

Zatem pozwolenie, aby taka struga zadań swobodnie płynęła przez firmę jest jedyną opcją na stole. Oczywiście nie zapominam, że istnieje świat projektów inwestycyjnych, które swoją dynamikę mają dużo dłuższą. Przykładowo pozwolenia na budowę nie uzyska się w tydzień i nie zmieni się go po dwóch tygodniach, gdy nowe wymagania wypłyną na powierzchnię. Podobnie w tydzień nie otrzyma się kredytu inwestycyjnego.

No i w takim krajobrazie w roku 2020 wgalopowała na scenę sztuczna inteligencja oparta na modelach językowych.

Moje doświadczenia z pracą z modelami

Z uwagą przyglądam się zarówno światowi technologii, jak i organizacji pracy zespołów w obszarze innowacji. W liceum i na studiach trochę programowałem, bardziej hobbystycznie niż edukacyjne i zawodowo. Kiedy nastał Covid postanowiłem na nowo spróbować swoich sił w teraźniejszych środowiskach i językach.

W 2019 roku trzymałem w ręku, a właściwie na komórce model Bert i testowałem jak streszcza dokumenty. A jednocześnie pamiętałem, jak bardzo męczyliśmy się z generowaniem streszczeń w systemie Pyton piętnaście lat wcześniej. Wtedy kombinowaliśmy z wyławianiem kluczowych zdań z tekstu i klejeniem z tego abstraktu. Efekt był przeciętny, ale nic więcej nie udawało się wycisnąć, szczególnie w tak fleksyjnym języku jak polski. Bert spowodował, że ciarki mnie przeszły. Robił to genialnie, zadawałem mu tylko długość abstraktu i za każdym razem podawał sensowny rezultat. I to niezależnie od rodzaju tekstu. Zrozumiałem, że coś wielkiego się zbliża, ale wtedy nie wiedziałem, że nadchodząca zmiana będzie aż tak rozległa.

Około 2023 roku podłączyłem edytor Code do Cursora i nagle poczułem, że jadę na elektrycznym rowerze pod górę i podziwiam widoki. Co napisałem linijkę kodu, on dopisywał drugą połowę. Dwa razy więcej linijek niż kliknięć i zdecydowana większość nie wymagała poprawek. Pomyślałem sobie, że o ile juniorzy mogą mieć problem z wejściem na rynek, to seniorzy będą w stanie wytworzyć dużo więcej w osobodzień i ich siła na rynku pracy wzrośnie.

W połowie 2025 roku z ciekawości zacząłem się bawić generatorami aplikacji takimi, jak Replit, Lovable, czy Base44 i wyobraziłem sobie, jak to będzie, gdy świat zaleją miliony systemów tworzonych przez laików. Jaki dług techniczny to wytworzy, jakie dziury bezpieczeństwa, ale z drugiej strony jakie poczucie swobody będzie miał biznes. Wygenerowałem kilka systemów WWW i wyglądały pięknie, niewiele robiłī, ale zewnętrzy layout był dużo lepszy niż sam bym go był w stanie zaprojektować. Doszedłem do wniosku, że może takie rozwiązania są dobre dla małych aplikacji, ale przy dłuższym rozwoju systemu, przez wielu ludzi, to może nie zadziałać. Chaos w kodzie może okazać się nie do utrzymania.

I wtedy listopadzie 2025 zacząłem korzystać z Claude do rozmowy o moim kodzie. Początkowo nieśmiało, ale po kilku tygodniach wykorzystywałem go do usuwania trudniejszych błędów, optymalizacji, projektowania frontendu, sprawdzania czy na backend poszczególne funkcje nie ścigają się, wreszcie objaśniania mi, co on robi i czy dobrze rozumiem jego intencje.

Piszę o tej ewolucji dlatego, że równolegle w głowie próbowałem wyobrazić sobie, jak będą wyglądać zespoły projektowe w świecie IT, a później w świecie produktów, a później w świecie w ogóle biznesu. Idąc dalej, jak będzie wyglądać rola lidera i metodyki projektowe, Czy będzie coś takiego jak lider i metodyki?

Dzisiaj mój sposób korzystania z modelu podczas programowania wygląda tak, że jeden model działa cały czas w tle i dopisuje kontynuację linii kodu, drugi natomiast odpalony jest w okienku obok i ma dostęp do całej biblioteki. Gdy chcę dopisać coś oczywistego, choć czasem pracochłonnego już w ogóle tego nie programuję. Po prostu piszę: Claude’owi “zrób to i to”, “upewnij się, że to tak działa”, albo “czym różnią się te funkcje, bo chyba robią to samo”. Gdy model ma wątpliwości wklejam linka do dokumentacji i mówię mu, aby sobie poczytał i nie zawracał mi głowy. Gdy są błędy, wklejam komunikaty z serwera i pytam, co się stało. I to po prostu działa. Jeden Marcin wykonuje robotę dawnych 3 lub 4 Marcinów.

Spekulacyjne rozwinięcie

Zatem jak organizacja pracy może wyglądać za rok - dwa lata. Poniższe spostrzeżenia są oczywiście spekulacjami i jak to z prognozami bywa pewnie się mylę, ale mam nadzieję, że mylę się mniej niż przeciętny członek zespołu.

Świat praktyków LLM w projektach jakiś czas temu ukuł rolę Buildera AI, czyli osoby, która łączy w sobie rolę analityka, programisty i testera. To ktoś, kto bierze wymagania funkcjonalne, czyli to, co ma robić dane rozwiązanie i produkuje je. Gdybyśmy byli u krawca lub szewca nazwalibyśmy taką osobę rzemieślnikiem. Klient komunikuje, jak ma wyglądać sukienka, jakie wrażenie ma sprawiać, zaś rzemieślnik dobierze właściwy materiał, weźmie pomiary z klienta, doradzi, jakie pomysły się sprawdzą, a jakie nie, następnie narysuje całą koncepcję i uzyska zatwierdzenie. Gdy już wszystko gotowe dotnie, zszyje, wykończy, naniesie poprawki i odda gotową sukienkę. Cały proces w rękach jednej osoby, chyba wracamy do średniowiecza, jeżeli chodzi o organizację pracy, bo wtedy dominowali kowale, rymarze, murarze, tkacze, stolarze i kucharze. Zatem z polskiego proponuję nazwę AI rzemieślnik.

Produkcja IT bazuje na zasadzie rozdzielenia kompetencji, gdzie jedną z korzyści jest to, że jedni sprawdzają po drugich. Programista weryfikuje wykonalność po analityku, tester sprawdza po programiście itd. Proces produkcyjny spowalnia cykle dostarczania, ale też stabilizuje i wspiera harmonizację rozwiązania z całą platformą i dobrymi praktykami.

Jeżeli teraz weźmiemy pod uwagę fakt, że cykle dostarczania skrócą się, wszak każdy rzemieślnik w zespole może oddawać swoją porcję pracy kilka razy na dzień, a nie czekać do piątku oraz fakt, że to LLM de facto produkuje, to możemy być świadkami lawinowo narastającego bałaganu. Może okazać się, że po miesiącu rozwiązanie co prawda działa, ale…:

Rzemieślnik A nie wie, co robi funkcja napisana przez B.
W systemie jest pięć funkcji, które robią to samo.
Funkcja C jest sprzeczna z D.
Wykorzystanie funkcji E razem z F powoduje dziurę bezpieczeństwa.
Architektura opracowana przez rzemieślnika G jest totalnie sprzeczna z tym co wymyślił H. Dopóki się nie spotkają, nikt nie widzi problemu, ale za pół roku spotkają się na pewno i wtedy BUM!

Zatem pojawia się potrzeba istnienia kogoś, kto zapewni optymalność i spójność wszystkich aspektów rozwiązania. Kogoś, kto będzie rozumiał, jakich nici użył rzemieślnik A i czy tkaninę od rzemieślnika B można wykorzystać też do zasłon. I gdy ubierzemy człowieka w te buty, spodnie, koszule, kapelusz i płaszcz, czy nie będzie wyglądał jak bywalec festiwali Burning Man. Moim zdaniem pojawia się potrzeba, kogoś kto ma dogłębną wiedzę o technologii i nie ufa sztucznej inteligencji, aby był hamulcowym w tej wesołej drezynie nazywanej projektem. Pozostańmy przy nazwie hamulcowy.

Hamulcowy regularnie przegląda tworzone rozwiązanie i narzuca zasady. Owe zasady rzecz jasna mogą stać się częścią systemowego prompta, jaki jest wysyłany do LLM. Hamulcowy patrzy w poprzek i skupia się na technologii. Dzisiaj taka rola realizowana jest przez głównego programistę, architekta, analityka systemowego, release managera, czy devopsa. W przyszłości być może to będzie jedna osoba, obejmująca całość perspektywy i wsparta niezależnym modelem językowym.

No i ostatnia rola menedżer. Jeden rzemieślnik dzięki wsparciu narzędzi sztucznej inteligencji jest w stanie wykonać pracę kilku ludzi, ale to nie musi oznaczać, że takich rzemieślników będzie trzy, cztery razy mniej niż dzisiaj. To może oznaczać, że apetyt firm wzrośnie trzy lub czterokrotnie, albo może nie wzrośnie i 75% ludzi będzie musiała się przebranżowić. Limitem jest tutaj zapotrzebowanie rynku, a zagadnieniu strategicznej przewagi poświęcę kolejny rozdział.

Poniżej metaforycznie przedstawiłem porównanie dzisiejszego stanu i możliwego rozwinięcia przyszłości. Załóżmy, że mamy przykładową firmę YIT, w której pracują 3 zwinne zespoły. Każdy zespół ma na czela product ownera / kierownika projektu, którzy zarządzają kontraktami lub kształtują rozwój produktów IT. Na czele całego działu stoi menedżer, który nadaje kierunek rozwoju firmy, rozmawia z klientami na poziomie strategicznym. Dodatkowo te zespoły są wspierane i kontrolowane przez zespół fachowców od bezpieczeństwa, governance, utrzymania. Potrzebna jest też funkcja helpdesku. Całość organizacji w uproszczonej formie może wyglądać tak, jak poniżej. Mamy ponad 30 specjalistów i 4 menedżerów.

A teraz wyobraźmy sobie, że po pierwsze produkcja i testowanie oprogramowania realizowane jest przez model, który jest zasilany przez człowieka. Badanie The Impact of AI on Developer Productivity: Evidence from GitHub Copilot z 2023 pokazywało już wtedy wzrost o 55%. Inne badanie Generative AI changes how employees spend their time pokazało, że programiści dzięki AI zredukowali czas na zarządzanie projektem o 24%. Badanie We are Changing our Developer Productivity Experiment Design z 2025 roku pokazuje skrócenie czasu pracy doświadczonych programistów o 18%. Te badania były realizowane zanim pojawił się model Claude 4.5. Osobiste doświadczenie pokazuje, że aktualnie Claude pozwala mi pisać 3-4 razy więcej niż gdybym to robił całkowicie samodzielnie. A na horyzoncie jest nowa wersja 4.7 i model Mythos. Same badania Anthropic wskazują, że w 2025 roku programiści deklarowali, że mogą w pełni zdelegować do 20% swoich prac.

Zatem przyjmijmy jako prawdziwe założenie o wzroście efektywności pojedynczego programisty 4 razy w ciągu kilku lat oraz redukcji pracy potrzebnej na zarządzanie projektem. Struktura naszej firmy YIT przy założeniu, że dostarcza ten sam zakres prac, może zatem wyglądać tak w 2028 roku.

Zostaje nam 1 menedżer i 11 specjalistów. Zapotrzebowanie na zarządzanie spada, gdy jest mniej ludzi, a co za tym idzie struktura organizacji się spłaszcza. Redukcja dokona się nie tylko w obszarze produkcji, ale i wspierających. Już dziś model Mythos był w stanie wykryć dziurę w systemie Linux mającą 20 lat. Na fali obaw o możliwości LLM akcje firmy cybersecurity jak Crowdstrike spadły o około 15% w pół roku, a Palo Alto Networks o 21% w tym samym czasie.

Pośrednim efektem wpływu LLM może być jeszcze większa asymetria kompetencji w organizacjach. Utrudni to wejście młodym, jeszcze niewykształconym na rynek pracy. Wcześniej pisałem, że grupa ludzi w firmie posiada unikalne kompetencje, a większość z nich czerpie, wykonując bardziej powtarzalne zadania.

Otóż dzisiaj mam przekonanie, że ten wykres jeszcze bardziej się wygnie. Jeszcze mniejsza grupa ludzi będzie zaangażowana w wytwarzanie nowej wiedzy, która daje firmie przewagę. I jeszcze większa grupa będzie korzystać z istniejącej wiedzy po to, aby sprawnie wypełniać powtarzalne obowiązki. To może też zaowocować jeszcze większym rozwarstwieniem wynagrodzeń. Co więcej część etatów powtarzalnych przejmie AI.

Wreszcie ostatni argument za tezą o redukcji zespołów. Im projekt jest bardziej innowacyjny, tym zespół staje się mniejszy. Projekty kaskadowe mogą mieć po kilkuset członków, bardziej zmienne od nich projekty zwinne wg Scrum Guide powinny mieć do 9 osób, zaś projekty discovery zwykle są o połowie mniejsze niż Scrum, mają przeciętnie 3-5 członków. Wprowadzenie automatyzacji opartych na sztucznej inteligencji spowoduje, że oczywiste funkcjonalności typu przerobienie ekranu, aby się lepiej prezentował, modyfikacja kroków użytkownika na formularza, treść raportu lub dodanie wykresu będą realizowane w największym stopniu przez AI. Dla przykład dzisiaj w rozwijanym przez siebie narzędziu Didascal zauważyłem, że mam listę 100 pozycji na jednym z ekranów. Zamiast samemu zmienić layout, poprosiłem Claude, aby coś z tym zrobił. Po pięciu minutach miałem efekt w postaci: dwóch zakładek (zawierających krótką i długą listę elementów), pole filtrowania listy oraz style zmienione w ten sposób, że lista się przewija w ograniczonym oknie. A najlepsze jest to, że nie zdefiniowałem Claude’owi, co ma zrobić, tylko napisałem, że nie podoba mi się tak długa lista, bo jest niewygodna.

Zatem mniejsze zespoły ludzkie zostaną zepchnięte do obszarów bardziej innowacyjnych niż to, co potrafi wykombinować AI. A to oznacza bardziej ryzykowne, krótsze i bardziej dynamiczne projekty realizowane przez mniejsze zespoły.

Wróćmy do aktualnego obszaru moich zainteresowań zarządzania projektami i tego, jak może się zmienić.

Kierownicy projektów

Przewaga kierowników opierała się dotąd na jednej lub kilku naraz z trzech kompetencji:

Społecznej - wiedza i umiejętności na temat tego, jak dogadywać się z ludźmi. W to wchodzi też posiadanie rozległych relacji interpersonalnych z innymi pracownikami, dostawcami i klientami.
Technicznej - znajomość technologii informatycznych, umiejętność nawiązania profesjonalnego dialogu ze specjalistami IT, samodzielnej weryfikacji jakości i postępu prac.
Biznesowej - wiedza o branży, w której działa firma, umiejętność zdefiniowania albo zrewidowania wymagań w kontekście możliwych do osiągnięcia korzyści w postaci przychodów, ekspansji na rynku, gotowości do startowania w nowych przetargach itd.

Tak, jak to starałem się wykazać powyżej, dzięki rozprzestrzenianiu się AI dojdzie redukcji liczby i liczebności zespołów. To oznacza spadek popytu na kompetencje społeczne. Po prostu mniej ludzi w grupie oznacza mniej obszarów konfliktowych i nieporozumień. Przy 20 osobach wspólne spotkanie statusowe byłoby długie i nużące, trzeba je jakoś zorganizować. Przy 4 osobach dogadają się same bez wsparcia facylitatora.

Co zatem pozostaje kierownikowi projektu? Skupienie się albo na technologii, albo na biznesie. Jednak z technologii stopniowo ludzie są wypierani właśnie przez AI. W obszarze technologicznym kierownik projektu napotka testerów, junior programistów, analityków, administratorów, którzy też próbują ocalić swoje miejsca pracy.

W takiej sytuacji bardziej naturalnym kierunkiem okazuje się biznes. Kierownik projektu będzie musiał potrafić wykreować zysk, wartość materialną z projektu, sprzedać kontrakt, a nie tylko go koordynować. Największym ryzykiem wciąż nie jest to, czy potrafi się zbudować dane rozwiązanie. Największym ryzykiem jest, czy ono w ogóle przyniesie wartość. Nie sztuka przekopać mierzeję wiślaną. Sztuka spowodować, aby pływały przez nią żaglówki.

Nowym aspektem, który być może wpadnie w orbitę zainteresowań kierowników projektów może być zarządzanie budżetem tokenów. Dzisiaj główną pozycją kosztową projektów IT są osobodni zespołu. Jednak wraz z ekspansją AI ta pozycja będzie redukowana na rzecz kosztów mocy obliczeniowej. Mała dygresja w tym miejscu się należy. Transfer pieniędzy z osób na tokeny przyśpieszy nie tylko dzięki większemu wykorzystaniu AI, ale również z powodu prawdopodobnego wzrostu ceny tokenów. Dzisiejsi dostawcy LLM są generalnie nierentowni. Openai traci rocznie kilkanaście miliardów dolarów. Mówi się, że cena tokena powinna wzrosnąć czterokrotnie. Pewnie będzie mniej filmów z kotkami, ale to i tak będzie taniej niż etat programisty.

Choć być może nawet to zostanie zabrane PMom, bo ile to roboty przejrzeć raport zużycia tokenów w rozbiciu na członków zespołu. Biuro projektów może to z powodzeniem robić dla wszystkich projektów naraz.

Czynnikiem pozytywnym może być rosnąca dynamika transformacji przedsiębiorstw. Tak, jak pisałem wcześniej 30 lat temu strategie firm planowano na 10-20 lat naprzód. 20 lat temu ten okres skrócił się do 5-10 lat. Potem skrócił się do 1-3 lat. Dzisiaj wiele firm ma plany rozwojowe na najbliższe dwa kwartały. Okazje i zagrożenia gonią się nawzajem jak dwa pawiany walczące o głowę antylopy.

To oznacza, że w przyszłości firma dużo częściej będzie musiała dokonywać strategicznej transformacji. I ktoś będzie do tego potrzebny. Być może kierownicy projektów przesuną się bardziej w stronę takich inicjatyw. To by oznaczało, że będą musieli również wypatrywać takich okazji i zagrożeń strategicznych zbliżających się do firmy. Oczywiście przy wsparciu agentów AI 😀.

Warto tu wspomnieć o jeszcze jednym zjawisku - umieraniu metodyk. 20 lat temu PMBOK Guide albo PRINCE2 były kanonem. Wypadało i niektóre organizacje z tego rozliczały, prowadzić projekty według ustalonych zasad. Potem z jednej strony popularność zdobyły podejścia zwinne, z których na placu boju pozostał Scrum (pozostałe odeszły w zapomnienie), a z drugiej strony metodyki kaskadowe zaczęły promować “tailoring”, przycinanie ich do potrzeb organizacji. Po kolejnych kilku lata Scrum w literalnym rozumieniu Scrum Guide'a również przestał być powszechny. Bowiem organizacje zaczęły przycinać do swoich potrzeb także Scruma.

Dzisiaj zaczyna dominować podejście bez metodyczne, które określiłem mianem zarządzania strugę zadań, albo próbą uregulowania Gangesu.

Zadania płyną sobie bezładnie, jedne szybciej, drugie wolniej. Z kolejnych dopływów, działów firmy, wpadają nowe zadania. I na końcu w delcie Gangesu wypływają wykonane prace. Sztuką jest popychać Ganges do szybszego płynięcia oraz wyławiać z brunatnej mazi te zadania, które dają największą wartość. Taka “metodyka” nie daje dużego pola do popisu dla kierowników projektów, natomiast nadal pozostawia zapotrzebowanie na wsparcie PMO.

Ale to tylko spekulacje.

Analitycy biznesowi

Dziś zawód analityka biznesowego jest często identyfikowany jako szwajcarski scyzoryk. To człowiek od różnych zadań na styku technologii i biznesu. Ktoś, kto jednocześnie wie, po co jest dana funkcja, i rozumie, jak z grubsza będzie modelowana w rozwiązaniu.

I ten zawód ma największy potencjał, moim zdaniem, aby zdominować przyszłe projekty IT. Analitycy, rozumiejąc biznes, albo przynajmniej umiejąc rozmawiać z tymże, są w stanie wyciągnąć listę wymagań. Odróżnić zachcianki od istotnych rzeczy. Z drugiej strony są również w stanie tak zdekomponować wymagania, aby dało się zaprojektować dla nich optymalne rozwiązanie.

Rolą o podobnym profilu jest product owner, czyli osoba stojąca na przejściu granicznym między imperium zamawiającym funkcjonalności, a autonomicznym obwodem, który ma je wyprodukować.

Tylko, że w przyszłości strona wykonawcza będzie stopniowo zastępowana przez AI. W ten sposób analityk będzie migrować w stronę AI buildera. Osoby, która faktycznie jak szwajcarski scyzoryk definiuje wymagania, planuje ich wykonanie, nadzoruje egzekucję kody, nadzoruje testy i wdraża.

Kluczowe kompetencje w takiej sytuacji będą polegały na elicytacji potrzeb i zrozumieniu kontekstu biznesowego oraz umiejętności zlecenia prac agentom AI. Analityk biznesowy przyszłości będzie specjalistą od bankowości detalicznej, tradingu, ubezpieczeń, dystrybucji artykułów spożywczych do sklepów, procesów obsługi klienta w telekomunikacji, sprzedaży telefonów, ecommerce. To jest trwała przewaga, jaką może zbudować to stanowisko.

Praktyki product discovery, w szczególności obserwowanie i słuchanie użytkowników, jak najbardziej pozostaną w mocy. Rozbijanie dużego problemu na małe kawałki za pomocą map procesów, burz mózgów pewnie też. Zbieranie dany o wąskich gardłach, reklamacjach, zapętleniach w procesach i innych defektach również. Jednakowoż analiza dokumentacji, specyfikowanie wymagań, projektowanie UI już mogą być zautomatyzowane.

Czynniki przewagi strategicznej

Wzrost produktywności oznacza wzrost podaży. Wzrost podaży przy stałym popycie oznacza spadek cen. Spadek cen to spadek marż producentów i wydłużenie się ogona. Analogicznym przykładem jest rynek gier mobilnych, wg Sensor Tower w 2014 roku 46% gier było płatnych, w 2019 roku udział płatnych gier spadł do 13%. Jednocześnie liczba gier wzrosła z 170 tysięcy do 400 tysięcy w tym czasie. Płatności za gry przeniosły się do przychodów z reklam lub do dobrowolnych mikrotransakcji w trakcie rozgrywki. Na Itunes początkowo jedna piosenka kosztowała niemal od 0.7 do 1.3 dolara i przez 23 lata mimo inflacji na poziomie ponad 60% ta cena nie zmieniła się. A dodatkowo w międzyczasie Spotify zaoferował abonament miesięczny na wszystkie piosenki za 13 dolarów.

Oczywiście czynnikiem, który może podnieść popyt może być paradoks Jevonsa. Jevons zauważył, że udoskonalenie maszyny parowej przez Jamesa Watta (a więc wzrost efektywności i spadek kosztu wykorzystania węgla) nie zmniejszyło zużycia węgla w Anglii, tylko je gwałtownie zwiększyło – bo tańsza energia otworzyła zupełnie nowe zastosowania i rynki. Zatem spadek kosztu usług IT może spowodować, że nowe obszary zastosowań wyłonią się. A to prowadzi nieuchronnie do rynku, na którym:

Spadają koszty przełączania się między jednym rozwiązaniem a drugim.
Istnieje bardzo szeroka i różnorodna oferta rozwiązań. Samych systemów realizujących Kanban naliczyłem kiedyś grubo ponad 100. A teraz każdy będzie mógł sobie napisać Kanbana.
Popytem na rynku rządzą krótkotrwałe trendy, mody, emocje i zmienne preferencje klientów.

Takie rynku nazywane są rynkami długiego ogona.

Na rynkach o długim ogonie wygrywają marketplace’y, ale takich graczy jest zaledwie paru. Przykładem jest Amazon, Appstore, Ebay, Etsy w pewnym sensie Netflix, Youtube czy Spotify. Na rynkach o długim ogonie tylko garstka zarabia duże pieniądze, zdecydowana większość otrzymuje skromny przychód na swoich produktach. Rządzą nimi mody, chwilowe impulsy i opinie.

Czy powstanie marketplace dla rozwiązań informatycznych? W pewnym sensie takie rynki istnieją już dzisiaj, przykładem jest rynek rozszerzeń do Jira czy Salesforce. Kolejny przykład to rynek aplikacji mobilnych Google Play.

Jednak drastyczny spadek kosztów produkcji rozwiązań informatycznych może zaowocować pojawieniem się rynku agentowych systemów, albo systemów zakodowanych przez agentów. Strzelam, że Openai, Perplexity, Google czy Anthropic stworzą i wypromują takie rozwiązanie.

Przeciętny gracz potrafi dziennie przetestować kilkanaście gier mobilnych. Parę sekund w jednej grze, cyk, i ściąga następną i następną. Koszty przełączania są żadne. Jednak rynek rozwiązań SaaS charakteryzował się dotąd wysokimi kosztami przełączania się. Trzeba było skonfigurować rozwiązanie, przeszkolić użytkowników, przekonać ich do korzystania, dostosować firmowe procesy pod narzędzie, zalać je firmowymi danymi i podłączyć integrację po API.

AI może rozwiązać również i to wyzwanie. Protokół MCP (Model Context Protocol) jest pierwszym krokiem w kierunku płynnego przełączania się między narzędziami AI. To wręcz AI może zacząć decydować, jakie narzędzie przetestować, gdzie przelać nasze dane i komu zapłacić opłatę licencyjną.

Gdzie zatem szukać przewag konkurencyjnych? W sympatiach użytkowników. Większość systemów IT wymaga zaangażowania grupy ludzi. Niewiele rozwiązań zakłada pracę indywidualną, przykładem może być baza wiedzy Obsydian. Im więcej ludzi naraz “siedzi” w danym systemie, tym więcej śladów w nim zostawia. Pamięć ich agentów, baza wiedzy, nawyki pracowe. To buduje kotwicę. Skoro lubię dyskutować z kolegami na Slacku, albo przyjemnie obsługuje się zadania na Trello, to po co się przełączać.

Drugie źródło przewag konkurencyjnych to jakość wnioskowania i tu bezwzględnie wygrywają producenci najlepszych modeli językowych: Google, Anthropic, Openai, wkrótce być może Microsoft, Meta i Amazon. Inwestycja w LLM jest tak potężna, że ciężko jest nowym graczom do niej doskoczyć. Openai wydał już ponad miliard dolarów na wytrenowanie kolejnych generacji LLM. Potwornie głęboka fosa. Zatem sądzę, że faktycznie marketplace aplikacji pojawią się wokół tych graczy.

Trzecie źródło przewag to dostęp do unikalnych danych. Gdybym przykładowo miał dostęp do wszystkich wypisów ze szpitali w Polsce i całej historii pacjentów, i mógł to wykorzystać do trenowania modelu, byłbym niezmiernie bogaty. Palantir i Oracle nie bez powodu wchodzą w zarządzanie danymi medycznymi w USA. Openai stworzyło Chat GPT Health i przejmuje startupy z tego obszaru za setki milionów dolarów.

Czwarte źródło przewag to stopa w drzwiach wielkich korporacji. Mistrzem tutaj jest Microsoft ze swoją usługą Copilot. Już widzę oczyma wyobraźni, jak Microsoft otwiera rynek narzędzi Copilota. Software house’y mogą oferować na nim swoje rozwiązania dla setek korporacji, które uwierzyły, że Copilot jest bezpieczny, w zamian za niewielką opłatę, powiedzmy na poziomie 30% licencji.

Tak czy siak koszt produkcji projektów IT raczej spadnie, ich cykl życia się skróci, a przeciętny użytkownik, nawet o tym nie wiedząc, będzie w ciągu dnia korzystał z tuzinów narzędzi od różnych dostawców, bo o doborze narzędzi będzie decydował jego agent. Słowo chmura nabierze nowego znaczenia.

Zarządzanie wiedzą

Na początku artykułu wspomniałem o okresie mody na zarządzanie wiedzą, która potem zgasła. Z perspektywy zarządów obiecywano wtedy, że możliwe będzie “zassanie” wiedzy z głów pracowników. To zjawisko wtedy okazało się mrzonką.

Ale dzisiaj krajobraz uległ zmianie na skutek postępu technologicznego.

Poniżej możecie zobaczyć, jak wyszukiwania hasła knowledge management spadały od początku tego wieku i od roku zaczynają rosnąć. Równolegle hasło Scrum dla porównania osiągnęło swój szczyt kilka lat temu i teraz jest w trendzie powoli opadającym (ostatni skok obu haseł traktuję raczej jako anomalię).

Jak widać na powyższym diagramie zainteresowanie zarządzaniem wiedzą zaczyna ponownie rosnąć od około roku i dogania słowo Scrum.

Koszty dostarczania wiedzy do bazy wiedzy drastycznie spadają. AI potrafi zinterpretować informacje, podsumować, skategoryzować, opisać tagami. Umie nawet analizować nagrania dźwiękowe ze spotkań, obrazki i filmiki. Zatem wstawianie bazy wiedzy sprowadza się już dziś do udostępnienia pliku. Jedyny koszt, jaki pozostał nienaruszony, to koszt wyciągnięcia wiedzy z głowy pracownika. Odbywa się to ciągle tak samo. Ktoś musi zadać pytanie mądremu pracownikowi, ten musi chwilę się zastanowić, pogrzebać w swoich materiałach, sformułować odpowiedź. Samą odpowiedź, albo wypowie na głos, wyśle w emailu lub na Slacku/Teamsie/Discordzie.

Jednak użycie nowego interfejsu w postaci czatu może i ten aspekt zmienić. W lutym 2026 pojawił się nowy sposób wykorzystania AI - czat z narzędziami lub skillami. Najpierw rozpropagował go OpenClaw, a potem wprowadził Anthropic, Perplexity i Openai. Schematycznie ilustruje go poniższy rysunek.

Pracownik w tym modelu pracy cały czas rozmawia ze swoim agentem. Czat jest interfejsem nie tylko to rozmowy, ale i wyszukiwania, wywoływania aplikacji, wykonywania komend. Agent pamięta kontekst, preferencje pracownika, jeżeli ten chce aby zwracać się do niego per “Wasza Ekscelencjo”, to to zrobi. Jednak agent oprócz rozmowy jest w stanie wywoływać narzędzia. Może też dysponować spersonalizowaną strategią wnioskowania oraz posiadać dostęp do określonych zasobów, z których korzysta pracownik.

Poniżej zamieszczam przykład takiego dialogu z agentem, który wykrywa konieczność wywołania dwóch narzędzi: daty i określenia o jak odległą prognozę chodzi oraz połączenia z serwisem pogodowym i wyciągnięcia pogody dla danego terminu i miejsca. Dodatkowo agent kieruje się we wnioskowaniu pamięcią kontekstu, wpisanymi założeniami ograniczającymi wnioskowanie oraz triggerami alertów. Na poniższym obrazku celem agenta było wnioskowanie o zużyciu prądu na podstawie jednej reguły: gdy pogoda w zadanym zakresie, zapotrzebowanie na prąd będzie wysokie.

Powyższy dialog, może niemerytoryczny (skonfigurowałem agenta tylko dla celów testowych), pokazuje styl pracy w takim środowisku.

Taki agent staje się stopniowo asystentem lub alter ego pracownika. W efekcie każdy komentarz, każde wyszukanie, każdy znaleziony dokument oprócz pojawienia się w dialogu, zostają zapamiętane w bazie wiedzy. Gdy ktoś pracownika zapyta o coś, pytanie wraz z odpowiedzią automatycznie zostaną dopisane do aktywów intelektualnych firmy.

Ma on jeszcze jedną właściwość, może rozmawiać z innymi agentami, co ilustruje kolejny obrazek.

A tu już robi się grubo. Bo partnerem do rozmów stają się agenci. To agent może z drugim agentem negocjować termin spotkania, stawki umowy, dostępność czasową ludzi. Może zlecać prace, odbierać prace. I równolegle cały czas wiedza gromadzi się w bazie firmowej.

Wyszukiwanie wiedzy jest jeszcze łatwiejsze, bo mechanizm RAG i semantycznego wyszukiwania załatwia problem interpretacji potrzeb człowieka.

Gromadzenie wiedzy staje się na sztywno wplecione w interakcję człowiek - komputer, co sprowadza koszt tworzenia nowej wiedzy niemal do zera. MIT w jednym z raportów jako barierę wdrażania LLM w firmach podało konieczność przełączania się pracowników między czatem a normalną pracą. W jednym oknie piszę raport, a w drugim mam otwartego LLM i przeklejam komunikaty między oknami. Aby adopcja wzrosła, AI musi być zintegrowany z naturalnym workflow pracownika. Jeżeli zatem naturalnym workflow stanie się czat z agentem, który ma pamięć, dostęp do narzędzi, możliwość wywoływania poleceń i komunikacji z innymi agentami, to każdy przepływ pracy umysłowej integruje AI już na samym początku.

I być może za dostęp do tak żywej bazy wiedzy firmy zapłacą i zmuszą pracownikom do dostosowania się do tego modelu. Bo z jednej strony uzyskają większe bezpieczeństwo w sytuacji odejścia człowieka, a z drugiej będą budowały przewagę rynkową na bazie aktywów intelektualnych.

Wyobraź sobie taką sytuację, w firmie handlowej od roku całość rozmów o kontraktach, przetargach oraz duża część negocjacji odbywa się za pośrednictwem czatów, w których uczestniczą agenci AI. Od roku firma zbiera komentarze z rozmów, oceny klientów, dokumentacje, gromadzi też oferty tworzone przez handlowców. I teraz w połowie negocjacji człowiek, Kowalski, który je prowadził idzie na urlop, bo nie w wakacje nic pilnego nie miało się dziać. Ale dzieje się, bo klient nagle dostał zgodę na podpisanie umowy. W kilka minut inny handlowiec, Nowacki, zaczyna rozmawiać z agentem AI reprezentującym Kowalskiego. Rozmawia z nim tak, jakby rozmawiał z kolegą z pracy. Po piętnastu minutach ma zestawienie różnych założeń, taktyk negocjacyjnych oraz oczekiwań klienta. Po kolejnych piętnastu minutach ma na ekranie gotową ofertę taką, jakby przygotował ją Kowalski.

Jeszcze tylko jedną konstatację mam, tym razem smutną. Taki schemat, gdzie człowiek rozmawia przede wszystkim ze swoim asystentem, a dopiero agenci AI rozmawiają ze sobą, brzmi bardzo samotnie. Miałbym duże poczucie wyalienowania, gdybym nie miał bezpośredniego kontaktu z drugim człowiekiem. W jaki sposób wypełnić pustkę powstałą po wprowadzeniu agentów do środowiska pracy człowieka?

Podsumowanie

Podsumowując:

Rosnąca jakość LLM spowoduje, że więcej specjalistów będzie ufać wynikom generowanym przez nie.
To spowoduje wzrost produktywności i automatyzacje prostszych zadań, np. związanych z tworzeniem frontendu.
To spowoduje spadek zapotrzebowania na specjalistów IT oraz redukcję wielkości zespołów.
To z kolei odbije się na zapotrzebowaniu na menedżerów projektów.
Natomiast członkowie zespołów staną się bardziej uniwersalni, rola AI buildera. W naturalny sposób w tą rolę łatwo wskoczą analitycy biznesowi.
Spadające koszty gromadzenia i wyszukiwania wiedzy doprowadzą do renesansu baz wiedzy, w których część treści będzie automatycznie ekstrahowana przez AI.
Potrzeba transferu wiedzy oraz wygoda narzędzi AI spowoduje rozpowszechnienie się interfejsu dialogowego, w którym partnerem dla każdego pracownika będzie jego agent AI.
Spadające koszty produkcji doprowadzą do rozszerzenia oferty na rynku rozwiązań informatycznych.
To z kolei w połączeniu z łatwiejszą integracją i przełączaniem się między narzędziami doprowadzi do spadku lojalności użytkowników i krótszych cykli życia produktów IT.

W powyższym przykładzie skupiłem się na branży IT, bo to w niej widzimy największą adopcję i postęp. Anthropic, Google, Openai trenują swoje modele dokładnie pod zadania pisania kodu. Programowanie charakteryzuje się tym, że:

język jest dość precyzyjny, choć niejednoznaczny, bo tą samą intencję można zaprogramować na dziesiątki sposobów,
istnieje gigantyczna baza tekstów, na których można trenować model językowy,
dość łatwo jest zweryfikować, czy wygenerowany kod jest poprawny,
obszar ten kosztuje firmy miliardy dolarów, bo daje zatrudnienie milionom specjalistów.

Jednak, gdy spojrzymy szerzej, to więcej dziedzin biznesu charakteryzuje się takimi cechami: precyzja, zbiór uczący, jasne kryteria weryfikacji i wysoki koszt. Pierwsze, co mi przychodzi do głowy do księgowość i sprawozdawczość finansowa. Na świecie są miliony firm, które publikują regularnie raporty finansowe i rejestrują dane księgowe. Istnieje w każdym kraju mnóstwo przepisów prawa precyzujących, co to znaczy poprawne sprawozdanie. Jest sporo analiz giełdowych spółek interpretujących kondycję firm z perspektywy ich sprawozdań.

Kolejny przykład to dokumenty prawne. Język już nie jest tak precyzyjny, jak kod, ale baza treści prawnych jest gigantyczna. Istnieją tony przepisów, które mogą być kryterium poprawności tekstów generowanych przez AI i mamy pierwsze startupy na potwierdzenie mojej tezy, np. Legora, wyceniany na ponad 5 miliardów dolarów. Zaś od pojawienia się LLM akcje innej firmy, Legalzoom, która z kolei postawiła na sieć ludzkich prawników spadły o ponad 80%.

Kolejny przykład to firmowe procedury, polityki, instrukcje. W każdej szanowanej korporacji takich wewnętrznych dokumentów są miliony. Ale gdyby spojrzeć na rynek korporacji szerzej, to okazałoby się, że różne firmy generują i pielęgnują podobne dokumenty: RODO, ogłoszenia o pracę, instrukcje obsługi systemów, skrypty rozmów z klientem, opisy produktów, szablony wniosków. Tu tylko problemem jest brak publicznego dostępu do takich dokumentów. Chyba, że myślimy o sektorze … publicznym. Dokumenty urzędowe są dostępne publicznie i mogą stanowić podstawę do treningu modeli LLM.

Dość odważnie przedstawiłem powyższe tezy, jednak mam świadomość, że przyszłość bywa mocno nieprzewidywalna i rzeczywistość może potoczyć się innym torem. Może okazać, że pojawi się nowa “zima AI” i technologia dotknie sufitu. Może okazać się, że koszt wnioskowania skoczy tak mocno, że taniej będzie posadzić człowieka. Może okazać się, że na rynku pojawią się inne modele biznesowe, o których nie mam pojęcia. Wreszcie może okazać się, że pojawią się regulacje prawne chroniące dane lub pracowników przed transformacją AI. Przede wszystkim chodziło mi o sprowokowanie do myślenia.