utworzone przez Marcin Żmigrodzki
Obok budowania motywacji wewnętrznej, skalowanie zwinnych projektów na całą organizację jest moim zdaniem Graalem, którego poszukują zarządy.
Tak, jak warto mieć zaangażowanych ludzi, którym chce się podważać status quo i wdrażać innowacje, to duże organizacje chciałyby sklonować ideę małego zwinnego projektu na całość firmy.
Przez nasz kraj, podobnie, jak przez całą zachodnią gospodarkę przelała się fala transformacji zwinnych. Dotknęła ona szczególnie sektor finansowy i telekomunikacyjny, czyli wszędzie tam, gdzie wymagana jest wysoka innowacyjność oraz większość projektów zależy od zmian w głównych systemach informatycznych. Co ciekawe ta fala transformacji agile nie dotknęła sektora produkcji, ani usług publicznych. Jednak tam, gdzie pojawiła się, pozostawiła ślad. W poniższym tekście zbiorę moje refleksje na temat tego, jak mogłaby a jak wygląda taka transformacja.
Kontrola vs. zwinność
Duże organizacje potrzebują kontroli i struktur. Struktur organizacyjnych: działów, pionów, sekcji, bo człowiek ma ograniczoną rozpiętość kierowania i komunikacji, struktur zakresu: WBS, epic/feature/story/task, bo długie listy zadań mają tendencję do zaśmiecania się, struktur kosztów: budżety działowe, projektowe, zadaniowe, bo tak jak łatwiej rozliczać i kontrolować wydatki, struktury czasu: plany strategiczne, mapy drogowe, kamienie milowe, daty wypuszczeń, Gantty, wersje, bo podobnie jak przy kosztach tak łatwiej jest kontrolować rzeczywistość.
Natomiast pojedynczy zespół dobrze, aby pozostawał zwinny, ze zbiorową odpowiedzialnością, płaską strukturą, krótką listą zadań, planem na najbliższy sprint i nie zwracaniem uwagi na budżet.
Według metodyk skalujących agile gdzieś po drodze powinna zajść transformacja z klasycznego zarządzania i waterfall na agile. I jeszcze powinna ona być niezauważona dla zespołów, aby nie psuć zaangażowania. Na górze mamy plany bazowe, procenty realizacji KPI, odchylenia od terminów mapy drogowej, a na dole autonomię i swobodę.
Toteż dochodzi do wypaczeń. Przykładowo wg SAFE nadal wyceniajmy zadania w storypointach, ale cichaczem umówmy się, że 1 storypoint = 1 dzień i porównujmy produktywność między zespołami oraz wprowadźmy analizę odchyleń.
To magiczne przejście od agile do waterfall zachodzi przez stopniowe dokładanie kolejnych wskaźników kontrolnych. To tak jakby gotować żabę, jak będziemy robili to powoli, to może nie zorientuje się, że już nie jest taka zwinna. Drugi sposób na przejście to zrzucenie odpowiedzialności na kierowników projektów. Od góry można ich rozliczać z celów i planów bazowych, a od dołu zmusić do współpracy z niezależnymi zespołami. Piszę to z dużą ironią, bo oba sposoby na przejście od agile do waterfall często generują serie konfliktów.
Ciekawy przykładem kontroli na górze a zwinności na dole jest model spiralny Barry’ego Boehma stosowany w DARPA. Projekt w nim przechodzi przez cykle inicjacji, produkcji i walidacji, które pozwalają na utrzymanie kontroli inwestycyjnej, ale na dole, na poziomie zespołu może być tak zwinny, jak tylko chce.
Jeden ze znajomych, poddany transformacji agile, przytoczył mi ciekawy argument. Na ogólne narzekanie na bałagan powstały po transformacji zapytałem go, a gdzie to dobrze działa. Odparł, że tam, gdzie jest dobry product owner z biznesu, który wie czego chce, rozumie naturę technologii i ma na wyłączność zwinny zespół technologów. Podoba mi się ten argument. Aby transformacja agile powiodła się musimy mieć wielu product ownerów o wysokich kompetencjach biznesowych i elementarnych technicznych, którzy wiedzą czego chcą i mają na wyłączność swoje zespoły. Wraca nam idea lidera transformacyjnego, ale w wydaniu nie dyrektora a product ownera.
Problemem tylko jest fakt, że zespoły częstokroć nie są dostępne na wyłączność. Ludzie migrują, zespoły migrują i generalnie mamy dużą macierzowość. Podejście kaskadowe za pomocą szczegółowego planowania radzi sobie z tym wyzwaniem, natomiast agile ma tu problem i ludzie często wpadają w multitasking.
Motywacja do innowacji
Dlaczego organizacje potrzebują przejścia od kontroli do zwinności na poziomie pojedynczego zespołu. Powodów jest kilka: moda, argumenty rekrutacyjne dla nowych kandydatów („my nie jesteśmy złą korporacją, żółty ptak z ulicy Sezamkowej też był wielki a jaki sympatyczny”). I wreszcie mamy najważniejszy argument, tj. pozostawienie autonomii, bo ta buduje motywację wewnętrzną, zaś motywacja wewnętrzna jest silnie skorelowana z innowacyjnością.
To nie jest niewykonalne. Mimo skomplikowanych metodyk można nie niszczyć zaangażowania. Wszystko zależy od stylu, tak stylu, który każe powstrzymywać się od przesadnej ingerencji i wysłuchać maluczkich, bowiem w nich tkwi potencjał.
Pozytywny wniosek jest taki, że styl zachowania się lidera, niezależnie od przyjętego frameworku pozwala zachować poczucie autonomii w zespole. Chodzi o to, aby ludzie rozumieli uzasadnienie decyzji i mogli wywrzeć na nią wpływ.
Inżynieria oprogramowania
SAFE fajnie uwzględnił to, że oprogramowanie buduje się w specyficzny sposób, inaczej niż domy, inaczej niż nowe produkty AGD i inaczej niż kampanie marketingowe dla przykładu. Znajdziemy tu architektury, infrastruktury, wydania, stabilizację jakości, specyficzne role, jak analitycy, programiści i testerzy. I moim zdaniem dobry framework powinien uwzględniać specyfikę produkcji w danym sektorze.
Stosowanie sztywnych wydań, gdy sednem projektów jest tworzenie hardware’ów i logistyka komponentów nie działa tak, jak pisanie kodu, nie ma sensu. A z takiej założenia wychodzi Scrum for Hardware, co z resztą było gwoździem do jego trumny.
Dzielenie się wiedzą
Innowacje potrzebują kilku rzeczy, wybrane z nich, które akurat sobie przypomniałem to: zasoby, autonomia, presja na kreatywność oraz wiedza. Bez wiedzy odkrywamy koło na nowo i rzucamy infantylne pomysły.
Zwinność niestety może powodować zamykanie się zespołów w swoich bąblach poznawczych. Owszem w Scrumie regularnie dochodzi do dzielenia się wiedzą: na standupach, w ciągu dnia na kawie, na Slacku, czy na retrospektywie, ale ten oddziaływanie jest ograniczone do zespołu. Wiedza nie paruje na całą organizację tak, jakby mogła.
Spotify proponuje odpowiedź na to w postaci idei gildii, SAFe wspólnoty praktyków, DAD proponuje wszystko, co się da, więc pewnie też coś na dzielenie się wiedzą. Jednak bariery siedzą w mentalności ludzi a nie w technikach. Ja muszę nie bać się zadać pytania, ja muszę być krytyczny wobec siebie, aby wiedzieć, kiedy stanąłem pod ścianą i dopiero wówczas poproszę o pomoc. Z drugiej strony mój światły kolega musi mieć czas na udzielenie mi pomocy. Tego nie zbuduje się technikami, tylko budowaniem motywacji oraz świadomości.
Wdrażanie
I tu dochodzimy do szalenie ważnego aspektu, który bywa pomijany przez takich gigantów zarządzania, jak IPMA, PMI, IIBA, natomiast całkiem ładnie obsłużył go SAFE. W jaki sposób wdrożyć daną metodykę? PMBOK Guide ma z dodatkami około 1000 stron, a wdrażaniu metodyki na nim opartej poświęcono może z dwie. Nie da się wziąć encyklopedii i jej zainstalować w organizacji, a o tym zapomnieli twórcy DAD.
Potrzebne jest opracowanie drogi wdrażania skali w agile, a niekoniecznie konkretnego frameworku. Z resztą sam Spotify oznajmił ustami jednego z technologów, że model nazwany imieniem firmy już dawno wygląda inaczej. Nie ma właściwie modelu Spotify, jest kultura organizacyjna, która prowokuje do ciągłej ewolucji w imię autonomii zespołów i skoordynowanego rozwoju strategicznego.
Warto wspomnieć, że tą rolę, przewodnika po drodze ku transformacji, starają się też wypełnić konsultanci oraz wewnętrzni liderzy zmian.
To, co ostatecznie przebije się po dzisiejszym kryzysie transformacji agile, to podejście indywidualne. Organizacje raczej będą konstruowały własne frameworki, nazywając je jedynie za pomocą znanych terminów jak SAFE czy Spotify. Zwinność jest raczej drogą niż celem. Takie podejście sprawdziło się w lean i waterfallu. Do doskonałości można dążyć, podejmując dziesiątki racjonalnych decyzji i wybierając własną ścieżkę. Ale doskonałości nigdy nie osiągniemy.
Organizacje krok po kroczku powinny wskazywać priorytety w uzwinnianiu i utrzymywaniu kontroli. Tutaj wyraźnie widoczna jest cykliczność, na przemian zarząd uelastycznia zespoły, dając im autonomię i usztywnia przywracając kontrolę. Wszystko po to, aby znaleźć właściwy balans.
Z każdą taką pętlą uzwinniania/usztywniania wdrażane są kolejne techniki i metody pracy. A to retrospektywa, a to zakres opisany od strategii do zadania, a to sprinty, a regulowane release’y, a to samoorganizujące się zespoły, a to monitorowanie pracy, aby wyłapać wąskie gardła. Nie ma jednej drogi. Jest odkrywani, co organizacji pasuje najlepiej w danej chwili, a co trzeba zmienić.
Dla uczciwości dodam, że DAD przywołuje koncepcję Choose Your WOW, czyli wybierz swój sposób pracy. Ale robi to na tak ogólnym poziomie i zasypuje tak dużą ilością technik od sasa do lasa, że DAD staje się niestrawny.
Podsumowanie
W tytule artykułu przytoczyłem wykres popularności wyszukiwania Google Trends dla SAFe i kilku innych frameworków/metodyk. Jak widać trakcję uzyskały dwa, a jej skalę widać w porównaniu do na przykład PMI DAD – Disciplined Agile Delivery – to ta czerwona niewidoczna linia na wykresie.
Dlaczego akurat SAFE i Spotify się przebiły? Mam dwa argumenty: właściwy czas, łatwość wdrażania, adresowanie właściwych problemów. Oba modele pojawiły się dość wcześnie, gdy zainteresowanie skalowaniem dopiero narastało. DAD dołączył dużo później, co IMHO wykluczyło go z rywalizacji. Oba modele też adresują istotne potrzeby. SAFE streściłbym do potrzeby przez zarząd kontroli wśród wielu „zwinnych” projektów. Celowo słowo „zwinny” oprawiłem w cudzysłów, bo często przy wdrażaniu SAFE gubiona jest filozofia i mindset agile. DAD natomiast stara się budować kulturę współpracy z pominięciem wielu „twardych” aspektów, jak inżynieria oprogramowania, czy struktury decyzyjne. Na swoje nieszczęście LESS i S@S znalazły się w rozkroku pomiędzy dwoma atraktorami. Jak zarząd chciał utrzymania kontroli w zwinności uwaga firm ściągana była przez SAFE, jak natomiast firma chciała zbudować zwinną kulturę, nie ingerując w operacje i projekty, to w kierunku Spotify.
Jednak jak widać nawet te dwa wiodące podejścia również szczyt mają już za sobą.
utworzone przez Marcin Żmigrodzki
Zabawa wyobraźnią
Gdybyśmy przewinęli czas pięć lat naprzód, zobaczylibyśmy nieskończoną liczbę możliwych scenariuszy. Jedne bardziej prawdopodobne, inne mniej. Zaryzykowałem i stosując posiadaną wiedzę spróbowałem opisać moim zdaniem dość prawdopodobny scenariusz w aspekcie zarządzania projektami IT. Ale wróćmy do marca 2024 roku.
Dysponujemy czterema podejściami do zarządzania projektami: kaskadowym (20 tysięcy lat), zwinnym (30-20 lat), optymalizacyjnym (około 60-40 lat), eksploracyjnym (?). Jednak rewolucja AI właśnie się zaczęła. Pierwsze algorytmy rozwiązujące uniwersalne problemy, w przeciwieństwie do poprzedniej klasy AI, która była dedykowana tylko do jednego typu zadania, właśnie dowiodły swojej wartości w obszarze generowania tekstów, obrazów, dźwięków, muzyki i nawet wideo.
Wędrujemy do przodu na osi czasu. Po roku już mało kto kwestionuje użyteczności modeli LLM i innych, tak jak mało kto kwestionuje użyteczność wyszukiwarki internetowej. Rozwiązania się mnożą. Następuje zachłyśnięcie optymalizacją kosztową, jaką niesie nowa technologia. Wszędzie tam, gdzie pracownicy w sposób powtarzalny przetwarzają informacje tekstowe, obrazowe, dźwiękowe, filmowe, następują stopniowe transformacje AI. Ludzie zmieniają zawody i przenoszą się do dziedzin, które oferują trochę trwalszą przewagę nad algorytmami sztucznej inteligencji: posady kreatywne, związane z relacjami z ludźmi, wymagające brania odpowiedzialności za decyzje lub wymagające chwytnych dłoni i przeciwstawnych kciuków. Właściwie nie ma pracownika firmy, który przynajmniej kilka razy dziennie nie wspierałby się rozwiązaniami klasy AI, do streszczania za długich tekstów (nigdy więcej Too Long Didn’t Read), do tłumaczenia, do przypominania spotkań i zadań, do wyszukiwania, ostrzegania o szczególnych sytuacjach. Ale to dopiero początek.
W pewnym momencie zaufanie do systemów AI wzrośnie na tyle, że pozwoli im się podejmować decyzje w biznesie. Skupmy się na świecie projektów. Głównym kryterium optymalizacji jest przez ostatnie lata jest moim zdaniem wskaźnik Time To Market. Aby go skracać, narodził się agile, product discovery i kilka innych koncepcji. Presja na coraz krótszy Time To Market (TTM) wzmoże się jeszcze bardziej, a wyścig między firmami przybierze na sile. Przełomowe innowacje zejdą z poziomu strategicznego (lat) na poziom taktyczny (miesięcy). A optymalizacje produktów zejdą z poziomu taktycznego (miesiące) na operacyjny (dni). To będzie mogło być możliwe dzięki dwóm czynnikom: spadającemu kosztowi nanoszenia zmian i spadającemu progowi kompetencyjnemu.
Dobrym przykładem z dzisiaj są technologie Low code/No code pozwalające szybko tworzyć standardowe systemy, które w wielu miejscach zastępują z powodzeniem dorosłe rozwiązania. Innym przykładem jest tworzenie zapytań do baz danych i hurtowni, niegdyś wymagały znajomości składni SQL, dzisiaj można pytać językiem naturalnym. Na etapie prototypu jest szereg rozwiązań pozwalających tworzyć strony internetowe na podstawie prompta (ciekawa lista takich narzędzi). Jak wieszczy prezes Nvidia, w krótkim czasie przestaniemy potrzebować programistów, bo kod będzie pisany językiem naturalnym.
Zatem, jak może za kilka lat wyglądać zespół projektowy w obszarze IT?
Wyobrażam sobie, że nadal potrzeba osób, które będą miały pomysł. Zrozumieją problem biznesowy i postawią właściwe pytania. Tyle, że postawią je nie sobie a algorytmom AI. Rozwiązanie techniczne będzie powstawać przez zadawanie dziesiątek pytań i generowanie kolejnych wersji oprogramowania. To przypomina sylwetkę analityka biznesowo/systemowego. Dzisiaj takie systemy, jak choćby mój GoodBA, czy Dot Chart, działają na dość prostym poziomie. Brak im głębi, ale patrząc na dynamikę rozwoju, coś co nie istniało rok temu, za rok może mieć potworne możliwości.
Zatem mamy niewielką grupę analityków, którzy zlecają zadania algorytmom. W efekcie w jedną godzinę może powstać 10, 20, 50 wersji systemów, które następnie są weryfikowane przez inne algorytmy. Przecież istnieją już dzisiaj automatyczne testy, a za chwilę mogą pojawić się automatyczne testy użytkownika. Wystarczy, że jeszcze jednemu algorytmowi analityk powie, żeby wszedł w rolę użytkownika o danym profilu o ocenił sposób korzystania z proponowanych 50 wersji systemu, a na koniec wybrał najfajniejszy z nich.
Tak, jak dzisiaj w trakcie odkrywania potrzeb użytkownika zespół tworzy jeden, dwa lub nawet trzy warianty funkcji (przykładowe testy A/B wymagają dwóch wariantów), tak za kilka lat normą może być tworzenie średnio 86 wariantów dla każdej z 50 funkcji. Co z tego, że to daje 86 do potęgi 50. Automatyczne heurystyki pozwolą wyeliminować najmniej obiecujące kombinacje i zacząć od tych potencjalnie dobrych. W ten sposób zespół otrzyma las wariantów tworzonego rozwiązania i jego zadaniem będzie znaleźć najoptymalniejszą ścieżkę pokonania go.
Aby skutecznie maszerować przez las wariantów rozwiązania, zespół musi szybko eliminować ślepe ścieżki. Zatem nadal będzie spotykał się i rozmawiał o kierunkach prac, a potem każdy członek zespołu wróci do swojego komputera. Rytm prac narzucać jednak będzie nie stały odcinek czasu nazywany sprintem, a moc obliczeniowa chmury. Gdy spłyną rozwiązania, warto się spotkać i je omówić, gdy nadal będą trwały obliczenia oraz automatyczne programowanie, trzeba poczekać. Czas będzie zdeterminowany mocą obliczeniową komputerów.
Skoro czas zależy od mocy obliczeniowej, to od czego zależy budżet projektu. Po stronie ludzkiej zamiast 50 programistów mamy 3 analityków. Więc te koszty stają się mniej istotne. To, co staje się istotne, to koszt obliczeń. Podejrzewam, że wzrośnie rola megacentrów danych, które będą obsługiwały tysiące projektów. I największym kosztem będzie dostęp do ich mocy. Chcesz mieć szybko innowacyjny system, grę mobilną, usługę? Zapłać dużo. Nie masz wystarczająco budżetu, poczekaj na wolne moce. A w tym czasie ci bogatsi zrealizują swoje koncepcje.
Czym w takim razie zajmuje się kierownik projektu?
Ponieważ wieszczę (autoironia zamierzona), że zespoły będą dużo mniejsze, to kompetencji społecznych potrzeba będzie dużo mniej. Natomiast wzrośnie rola tworzenia właściwej wizji i wskazywania obiecujących kierunków. Zatem raczej rola kierownika projektów będzie łączona z rolą product menadżera / wizjonera / menedżera liniowego. Po prostu menadżer biznesowy dobierze sobie zespół analityków/prompterów, którzy zrealizują jego marzenie.
I w tym miejscu pojawia się ciekawy obszar problemowy. Ale dla porządku cofnijmy się do wstępu tego artykułu. Dysponujemy dzisiaj czterema podejściami do zarządzania projektami. Rozwój możliwości technicznych może sprowokować do pojawienia się piątego podejścia. Podejścia opartego na wizji, prowadzącego do gwałtownych przełomów. Takie podejście musiałoby skupić się też na obszarach, które rozwijają się daleko wolnie, tu postęp mierzony jest dekadami, czyli w obszarze ludzkich postaw i mindsetu. Krótko mówiąc, skupiłoby się na polityce.
Przykład z przeszłości dobrze to ilustruje. Londyńska Giełda kilkadziesiąt lat temu miała wizję stworzenia systemu do digitalizacji obrotu akcjami – Taurus. Projekt miał trwać rok i przynieść spektakularny sukces. Skończył się po 10 latach totalną klapą i przekroczenie budżetu 37 razy. Jedną z przyczyn było pełzanie zakresu wynikające z niedogadania się z bankami oraz niedocenienie skali rozwiązania.
A teraz co by było, gdyby ten Taurus powstawał w 2035 roku. Zespół czterech analityków w kilka dni opisałby koncepcję przekazaną przez prezesa giełdy. Po dwóch tygodniach 10 wersji systemu byłoby gotowych wraz z oceną ich użyteczności oraz analizą koniecznych zmian w otaczających systemach. Banki znów zaczęłyby sabotować Taurusa, wprowadzając żądania zmian. Jednak prezes giełdy dokupiwszy moc obliczeniową, zacząłby z zespołem generować 20 równoległych wersji systemu, aby odpowiedzieć na te zmiany. Jego głównym zmartwieniem byłoby to, że banki tak powoli odpowiadają na prezentowane warianty rozwiązań. Im więcej zmian interesariusze by zgłaszali, tym więcej mocy trzeba dokupić, aby utrzymać tempo prac. Po raz pierwszy w historii ludzkości czas stałby się niemal całkowicie wymienny na pieniądze. Jedynym progiem nie do przejścia, byłby ludzki opór przed zmianą.
Budowanie przewagi polegać będzie na tym, że wizjoner danego rozwiązania potrafi trafniej wskazać, co warto rozwijać i jak przejść przez las wariantów. Wariantów generowanych automatycznie, jak opisałem wyżej. A następnie ów wizjoner skutecznie przekona odbiorców do korzystania z nowego rozwiązania, zdobędzie ich atencję. Masz dobry pomysł i pieniądze, możesz go natychmiast zbudować i sprawdzić. Chwilę później okaże się, czy pomysł był faktycznie dobry i czy nie przepaliłeś w tydzień wszystkich pieniędzy. Zaryzykuję tezę, że nie będzie liderów projektów nie będących jednocześnie merytorycznymi w obszarze tworzonego rozwiązania.
Podsumowanie
Jak wskazuje wielu futurologów, zawody, które się bronią dotyczą interakcji międzyludzkich (wielu woli pogadać z fryzjerem lub pójść do ludzkiej kasy), działań kreatywnych (LLM są kreatywne tylko na tyle, na ile znajdą kreatywny pomysł w swoich zbiorach danych), manipulacji rękami (trudno mi powiedzieć, kiedy roboty będą równie sprawnie co ludzie zachowywały się w zmiennym środowisku).
Jednak wszędzie, gdzie na wejściu jest informacja i na wyjściu ma być wygenerowana inna informacja, a samo przetwarzanie informacji opiera się na gigantycznych zbiorach analogicznych przetworzeń (zbiory uczące), tam nastąpi przełom. Zaowocuje on wzrostem skali działania i konwersją czasu na koszty przede wszystkim obliczeń.
Powyższe rozważania mają charakter spekulacyjny i są hipotetycznym scenariuszem. Spisałem je porwany romantyzmem atmosfery rozwoju AI w ostatnich miesiącach. Nikt nie wie, co się wydarzy i kiedy zbudujemy kolonie na Tytanie albo zetrzemy siebie samych z powierzchni Ziemii, albo jedno i drugie.
Obrazki wygenerowane przez AI rzecz jasna (https://openart.ai/create)
utworzone przez Marcin Żmigrodzki
Wprowadzenie
Pojawienie się algorytmów generatywnych języka naturalnego uruchomiło lawinę rozwiązań. Dzisiaj mamy na rynku dostępnych grubo ponad 1000 startupów, które wykorzystują GPT. Za chwilę, gdy Google udostępni swojego Palm, pojawią się dziesiątki rozwiązań opartych na tym algorytmie.
Generalnie traktuję te algorytmy jako „czarne skrzynki” przetwarzające jedne teksty w drugie i to całkiem sprytnie, czyli takie, które człowiek może twórczo interpretować. Dotyczy to wszelkich prac biurowych w sektorze publicznym (decyzje, pisma urzędnicze), jak i prywatnym (komunikacja z klientem, księgowość, ofertowanie, treści marketingowe, dokumenty prawne).
Gdzie sztuczna inteligencja już działa
W aspekcie zarządzania projektami miejsce zastosowania takich algorytmów pojawia się wszędzie tam, gdzie mamy do czynienia z tekstem na wejściu i tekstem na wyjściu. Idąc od początku cyklu życia projektu, takie miejsca można zauważyć na przykład na etapach:
- Inicjacji projektu – odpowiednio podrasowany GPT potrafi już tworzyć typowe dokumenty. Brzmią one dosyć generatywnie, jak gdyby pisał je student zarządzania projektami, ale to moim zdaniem kwestia zbioru uczącego. Dobry fine-tuning modelu i karty projekty będą wyglądały, jak złoto. Obok macie przykład project chartera wygenerowanego dla zadanego przykładu. Z resztą możecie sami sprawdzić na GoodBA, jak to działa. Dodam tylko, że GoodBA korzysta z GPT 3, a załączony przykład jest z GPT 4 i widać tu postęp technologiczny.
- Analizy wymagań – aby sprawdzić, możliwości automatyzowania analizy wymagań, stworzyłem system GoodBA. W mojej opinii, dla generatywnych aplikacji działa to całkiem nieźle. Więcej o takim podejściu do analizy wymagań przeczytasz tutaj.
- Planowania zakresu – mając dobrze opisane wymagania, GPT naprawdę nieźle daje sobie radę ze stworzeniem planu zakresu w formule WBS, czy tez Backlog. Naprawdę niewiele trzeba po nim poprawiać, bo w tym wypadku robi to, co umie najlepiej restrukturyzuje podany mu tekst.
- Planowania ryzyk – wyobrażam sobie i chętnie sprawdziłbym to na przykładzie jakiejś firmy, że gdyby wytrenować model GPT na zbiorze danych o ryzykach z przeszłych projektów, to mógłby generować całkiem porządną wstępną analizę ryzyk dla kolejnego. Zakładam, że musiałaby to być baza zawierająca nie tyle przewidywane ryzyka, co rzeczywiście występujące w historycznych projektach.
- Prz
ygotowania kontraktów – w tym obszarze pojawiło się wiele startupów, które pozwalają na generowanie pism prawnych, w tym umów. Niech najlepiej o możliwościach automatyzacji obszaru prawnego świadczy olbrzymi spadek notowań giganta prawnego z USA – Legalzoom, który można było obserwować w momencie wydania GPT 3. Obok macie wykres kursów Legalzoom – spadek o 70%!
- Komunikacji z interesariuszami – Notion wypuściło moduł AI, a Nuclino – Sidekick. Oba to integracje z GPT mające na celu przyśpieszyć komunikację z użytkownikami. Wystarczy napisać swój komunikat, a potem poprosić, aby automat dodał do tego trochę energii, zmienił klimat na weselszy, wydłużył o dwa akapity oraz przetłumaczył na mongolski. I wszystko to automatycznie.
A gdzie jeszcze nie działa AI
GPT słabo sobie daje radę z wnioskowaniem symbolicznym. Widziałem próby pytania go o działania matematyczne, ale poziom błędowości tutaj jest wciąż wysoki. Jest to algorytm do przewidywania, jaki tekst powinien być napisany po zadanym prompt’cie. W efekcie dopisuje absurdalne wyniki. W przypadku matematyki obejściem tego problemu jest skorzystanie z pluginu Wolfram. Jednak, jeżeli wyobraziłbym sobie wygenerowanie tabeli z kosztami projektu na podstawie opisu wymagań i obciążenia zasobów, to bym poległ.
Pewne nadzieje daje technika pisania promptów zwana chain of thought, czyli tworzenie serii zapytań, w toku których powstaje ustrukturalizowany opis, na podstawie którego z kolei można wygenerować bardziej zaawansowane modele. Sam wykorzystuję to do generowania map procesów w systemie Dot Chart. Obok macie przykład mapy procesu, która została wygenerowana automatycznie na podstawie opisu językiem naturalnym.
Oczami wyobraźni widzę algorytm, który z jednej strony przetwarza teksty pisane językiem naturalnym, ale równolegle z drugiej strony identyfikuje wartości zawarte w tekście i wnioskuje na ich podstawie w sposób bardziej symboliczny tak, jak robią to algorytmy uczenia maszynowego. Taka hybryda GPT i ML.
Kolejny problem związany z brakiem wnioskowania symbolicznego jest słaba jakość rewizji utworzonej dokumentacji. Właściwie zawsze człowiek musi przejrzeć to, co utworzył GPT i przynajmniej lekko zmodyfikować. Algorytm nie potrafi skutecznie wykryć wszystkich luk i niespójności w wygenerowanym tekście na podstawie zadanych kryteriów. Testowałem go na przykładzie studów przypadków biznesowych i osiąga tutaj połowiczny sukces.
Wreszcie GPT słabo sobie radzi z treściami specyficznymi dla konkretnej firmy lub organizacji publicznej. To, co generuje jest raczej dość ogólne. Gdyby chcieć stworzyć opis programu na przykład do obliczania ryzykowności klientów banku detalicznego, to zapewne polegnie. Ale mamy tutaj rozwiazanie pod ręką, a jest nim „fine-tuning”. Jestem po lekturze dokumentacji, jak podkręcać GPT, ale niestety nie mam dostępu do przykładowych treści z jakiejś organizacji, aby przeprowadzić samodzielne testy. Mam nadzieję, że przez wakacje uda mi się wygenerować jakiś prototyp również w tym aspekcie.
Podsumowanie
Całość mógłbym podsumować stwierdzeniem, że zniknie syndrom czystej kartki. Chodzi mi o sytuację, gdy kierownik projektu będzie siadał do planowania projektu z czystą kartką i ją mozolnie wypełniał. Wkrótce będzie siadał z wstępnie wypełnionym dokumentem, czyli zawierającym 80%-90% treści, który będzie musiał sprawdzić, uzupełnić o braki i nadać mu bardziej ludzki ton, np. wprowadzić kilka drobnych błędów. 😉
Ale rewolucja AI w moim przekonaniu oznacza koniec pracy nad czystą kartką. Coś na starcie zawsze będzie na niej wpisane przez algorytmy sztucznej inteligencji.
