utworzone przez Marcin Żmigrodzki
Historia tego, jak powstała baza wiedzy w systemie Wroolo i jak ją wykorzystuję na codzień.
Pisząc książkę o zwinnych projektach, zacząłem gromadzić sporo treści. Jedne od razu cytowałem w rozdziałach, a inne wydawały się inspirujące, ale nie do wykorzystania od razu. Z czasem nazbierało się dziesiątki cytatów i PDFów. Niesamowitym źródłem dla mnie był na przykład ResearchGate. To serwis z publikacjami naukowymi. Zdarzało mi się, że nawet jeżeli artykuł nie był dostępny w pełnej treści, wiadomość do autora wystarczała, aby go dostać.
Wiedzy przybywało, projekt książka rozkręcał się i coraz trudniej było mi znaleźć potrzebne fragmenty. W pewnym momencie przekroczył poziom 200 porcji wiedzy. Część z nich zapisywałem w postaci dokumentów na Google Drive, ale wyszukiwanie w tym jest trudne, szczególnie, gdy szukasz czegoś, co składa się z jednego zdania.
Postanowiłem ułatwić sobie życie, ale najpierw je utrudniłem. Bowiem zaprojektowałem bazę wiedzy dostępną przez WWW. Pierwotnie przypominała feed z instagrama, i to działało mi całkiem nieźle dopóki liczba postów nie przekroczyła 50. Poniżej przedstawiam próbkę takiego feeda.
Ale wiedzy przybywało. Zacząłem kopiować fragmenty stron WWW, skany stron z książek i linki. Okazało się, że dodawanie nowej wiedzy musi być maksymalnie proste. Po prostu kopiuj – wklej i system musi zrobić resztę. Tak narodził się inspirowany Notion, Nuclino i notatnikami laboratoryjnymi edytor składający się z wielu pól o różnych typach. Poniżej załączam przykład losowej strony wklejonej do tego edytora.
Poszczególne sekcje można przesuwać, usuwać, dodawać nowe.
I mniej więcej wtedy pojawił się GPT, a chwilę później Sebastian Kondracki opowiedział mi o modelu RAG. I bam, miesiąc później miałem wyszukiwarkę semantyczną niezależną od języka. Mogłem po polsku wyszukać angielskie treści i na odwrót. To był przełom. Ponieważ dotarcie do dowolnej wiedzy zabierało mi raptem kilka sekund, to zacząłem wrzucać wszystko, co wydało się interesujące, jak leci. Algorytm i tak to odnajdzie, gdy będę potrzebował.
Na poniższym przykładzie widać, jak na hasło w języku polskim system wynalazł artykuły w PDF po angielsku.
Ale RAG to nie tylko wyszukiwanie, ale również dyskusja z własnymi dokumentami. Znalezione treści są wysyłane w postaci prompta to GPT, a ten w odpowiedzi generuje wiedzę. Teraz, gdy potrzebuję szybko znaleźć jakiś drobny fakt, to po prostu rozmawiam z moim prywatnym mentorem. Jeżeli dana wiedza znajduje się w znalezionych dokumentach i pytanie jest dość precyzyjne, to naprawdę działa rewelacyjnie. W przypadku chatu zauważyłem, że lepiej działa jednak po angielsku.
Oczywiście, jak to LLM, czasem halucynuje, więc przed zastosowaniem wiedzy warto sprawdzić źródła, ale mam je poniżej, wiec to jest dość szybkie.
W ten sposób rozwinąłem bazę wiedzy o pojemności 200 wpisów, która stała się dla mnie codziennym towarzyszem w pisaniu książki Bardziej niż Agile. Gdy zorientowałem się, że moduł wiedzy w systemie Wroolo wpisuje się w obszar nazwany PKMS (Personal Knowledge Management System), doszedłem do wniosku, że wpisuje się również w grupowe zarządzanie wiedzą.
Natychmiastowym eksperymentem było stworzenie bazy wiedzy na temat zarządzania projektami, którą utworzyłem z wpisów z bloga, książek i portalu wiedzy Octigo. Łącznie uzbierałem 600 porcji wiedzy i udostępniłem go moim studentom i absolwentom. Dzisiaj korzysta z niej kilkuset użytkowników. Większość pewnie w celu przygotowania się do egzaminu na studiach 🙂
Sądzę, że upowszechnienie architektury RAG i jednocześnie wprowadzenie ułatwień wprowadzania wiedzy i jej opisywania, mogą zlikwidować główną barierę zarządzania wiedzą, jaka doprowadziła do zarzucenia tej koncepcji 20 lat temu. Wiem, co mówię, bo niegdyś zrobiłem z tego doktorat i zmieniłem branżę 🙂
Sytuacja, gdy wystarczy zrobić kopiuj / wklej dowolnej treści, bez konieczności tagowania, opisywania, kategoryzowania, bardzo ułatwia budowanie bazy wiedzy. A sytuacja. gdy mogę wpisać dowolne zapytanie i uzyskać nie tylko pasujący artykuł, ale i bezpośrednią odpowiedź zdecydowanie zachęca do korzystania z takiej bazy wiedzy.
Gdyby zainteresował Was system Wroolo, to serdecznie zapraszam do przetestowania go na wroolo.com.
Baza wiedzy to połowa systemu Wroolo, jednak o drugiej połowie jeszcze nie piszę, bo ciągle ją dopieszczam. Będzie koncentrowała się na zarządzaniu zadaniami, ale w specyficzny sposób. Pozwalający na połączenie świata zwinnego z kaskadowym.
Zakładam, że do osobistego użytku Wroolo będzie darmowy. Ewentualny model biznesowy chcę oprzeć na zespołach projektowych.
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.
utworzone przez Marcin Żmigrodzki
Moja najnowsza książka na temat technik i metod zarządzania projektami oraz sposobu budowania organizacyjnej metodyki już jest dostępna.
I od razu wskoczyła na listę bestsellerów wydawnictwa Onepress.
Książkę można nabyć w sieci Empików, ale i w księgarniach internetowych.
Zawiera ponad 100 technik, metod i narzędzi stosowanych w zarządzaniu projektami. W tym zawiera uproszczoną listę procesów z PMBOK Guide 6, dla tych, dla których PMBOK Guide jest opasłą encyklopedią napisaną prawniczym żargonem.
Link do księgarni Onepress zamieszczam poniżej, jakby ktoś był zainteresowany: https://onepress.pl/ksiazki/instrukcja-obslugi-projektu-marcin-zmigrodzki,inopro.htm#format/d
utworzone przez Marcin Żmigrodzki
Jeżeli zamiast czytać, wolisz słuchać kojącego barytonu lektora, to z radością informujemy, że już jest dostępny audiobook książki W tym szaleństwie jest metoda.
Książkę można pobrać z poniższych serwisów:
Słuchanie trwa 12 godzin, a sama treść została specjalnie przeredagowana przez wydawnictwo, aby lepiej dopasować ją do możliwości tej technologii.
Ps.
Uprzedzając pytania, to nie autor czyta, tylko profesjonalista zawodowo operujący głosem.
utworzone przez Marcin Żmigrodzki
Wiedza jest ważna. To truizm. Jednak w projektach wiedza ma szczególny wymiar.
Poniżej opiszę, jakie są główne sposoby zarządzania wiedzą w projektach, które można napotkać lub których nie można napotkać, ale zaleca je metodyka.
Dobrze obrazuje to poniższy wykres przyrostu wiedzy w trakcie projektu.
Wiedza w projekcie przyrasta sukcesywnie, im więcej zakresu jest wykonane i im więcej czasu upłynie. Na końcu wiemy zdecydowanie więcej, niż na początku. Główne wyzwanie polega na tym, że większość decyzji podejmujemy na początku, gdy musimy zgadywać.
Drugi aspekt funkcjonowania wiedzy to rosnąca zmienność projektu w czasie, co symbolicznie ilustruje poniższy diagram.
Jeżeli na pionowej osi zaznaczylibyśmy trafność prognoz, na przykład terminu, kosztu, pracochłonności, różnych aspektów jakościowych, a na poziomej czas projektu, to okazałoby się, że błąd prognoz rośnie w czasie. Rośnie aż do sytuacji, gdy projekt wymyka się spod kontroli. W wynika to z faktu, że po drodze pojawia się szereg czynników środowiskowych, które pozostają poza kontrolą oraz z tego, że poprzednie etapy sprzedają swoje problemy następnym. Jeden dzień opóźnienia na etapie planowania, staje się pięcioma albo więcej dniami opóźnienia na etapie odbiorów.
Zatem, w jaki sposób zarządza się wiedzą w projektach w praktyce. Podzieliłbym to na dwa sposoby: formalny i nieformalny.
Formalny to taki, w którym istnieje jakaś procedura, sposób postępowania, której należy przestrzegać. Wiedza projektowa uzyskuje tu namacalną formę. W ramach tego podejścia wyróżniłbym dwie kolejne kategorie: ilościowe oraz jakościowe.
Jakościowe formalne to podejście zalecane przez PRINCE2, PMBOK Guide i oznacza ono tyle, że po projekcie należy siąść i spisać raport poprojektowy. Warto w nim opisać przebieg projektu, wnioski, dobre praktywki, problemy etc. dla potomnych. Takie podejście zakłada, że z projektu na projekt będą gromadziły się raporty, tworząc obszerną bibliotekę. A następnie każdy kolejny kierownik projektu będzie z niej korzystał, aby ustrzec się podobnych błędów. Moim zdaniem to nie działa, ale fajnie brzmi.
Ilościowe formalne to podejście, w którym ktoś z boku przygląda się różnym projektom. Gromadzi dane o nich na wybrany temat. Na przykład, gdy dla firmy ważne jest pilnowanie kosztów, to zbiera dane o planach i wykonaniach kosztów w różnych projektach. Ma je pogrupowane na rozmaite sposoby, jak data, rodzaj klienta, rodzaj kosztu, wielkość, etap, osoba decydująca o koszcie, miejsce i wiele innych. Następnie, gdy taki analityk już uzbiera dość danych, to zaczyna się przez nie przekopywać. Poszukuje powtarzających się zależności i czynników środowiskowych na przestrzeni wielu projektów. Na tej podstawie wyciąga wnioski i proponuje modyfikację procesów projektowych. Przykładowo może ustalić, że koszt materiału A zawsze jest o 10% niższy, gdy zamawia go doświadczony kierownik projektu. To oznacza, że warto by przeszkolić pozostałych kierowników, aby uzyskać oszczędności na poziomie 10%. Takie podejście, moim skromnym zdaniem, może naprawdę świetnie działać. Wymaga niestety dużych ilości danych z projektów oraz sprytnego analityka, który raz na jakiś czas siądzie do nich i zada sobie pytanie „co tu się powtarza?”.
Nieformalne podejście ostatnio stało się popularne pod nazwa retrospektywa. Jednak nie jest to wcale nowa filozofia postępowania. W armiach różnych krajów przykładowo od tysięcy lat istniała praktyka omawiania ostatniej operacji, dzisiaj nazywana After Action Review. w obszarze zarządzania produkcją od kilkudziesięciu lat znany jest termin koła jakości. Tak czy siak, idea, by grupa ludzi jadących na tym samym wózku na chwilę odłożyła narzędzia lub maczugi i zastanowiła się, w jaki sposób zoptymalizować swoją pracę jest atrakcyjna. Wszystko jedno, czy chodzi o większą produktywność kolejnego sprintu, eliminację defektów, czy zabijanie wroga. Moim zdaniem, retrospektywa może być niesłychanie skuteczna.
O tym dlaczego uważam, że formalne jakościowe zarządzanie wiedzą w praktyce słabo działa, a retrospektywa czy analiza danych dobrze, napiszę w kolejnym wpisie.
Ps.
Tematyka zarządzania wiedzą w projektach jest mi szalenie bliska z racji napisanego doktoratu oraz systemu zarządzania wiedzą, który onegdaj projektowałem i koordynowałem realizację w ramach nieistniejącej już firmy Pyton.
