utworzone przez Marcin Żmigrodzki
GoodBA to narzędzie do automatycznego tworzenia dokumentacji wymagań systemu IT.
Użytkownik w pierwszym kroku wprowadza opis swojego pomysłu na system. GoodBA zintegrowana z GPT radzi sobie z opisami w języku polskim, ale lepiej jednak działa, gdy opis jest po angielsku. Dla lepszych wyników opis można uzupełnić o kontekst biznesowy zawierający cele, wymagania biznesowe, ograniczenia prawne itd.
W kolejnym kroku GoodBA generuje listę ról użytkowników, która często może być z marszu wykorzystana do dalszej analizy. Użytkownik może też wyedytować tą listę zanim przejdzie dalej.
Następnie dla każdej roli użytkownik może wygenerować funkcje. GoodBA podpowie, jakie funkcje każda rola może wykonywać. Te funkcje znowu można edytować, dodawać nowe, albo grupować, gdy funkcja się powtarza.
Od tego momentu użytkownik może wybrać dwie ścieżki:
- Dalej generować dokumentację wymagań.
- Przełączyć się na planowanie zakresu projektu w formie Product Backlogu lub Struktury Podziału Prac (WBS)
W przypadku wybrania ścieżki kontynuowania prac nad dokumentacją użytkownik może stworzyć proces na podstawie funkcji. Aktualnie GoodBA korzysta z GPT 3 i użytkownik samodzielnie musi opisać przebieg procesu językiem naturalnym. Na tej podstawie GoodBA narysuje diagram procesu w dwóch formatach: Dot Chart lub BPMN.
Robiliśmy testy na GPT 4 i okazuje się, że nowsza wersja tego algorytmu radzi sobie z tworzeniem opisów generycznych procesów, więc, jak tylko uzyskamy dostęp do API, rozszerzymy GoodBA o tą funkcję.
W ostatnim kroku użytkownik może wygenerować listę ekranów, które powinny znaleźć się w systemie. Znowu dzieje się to automatycznie, natomiast użytkownik może później edytować listę ekranów po swojemu.
Na koniec całą dokumentację można pobrać na komputer w postaci pliku PDF.
Jeżeli użytkownik przełączy się na funkcje planowania zakresu, GoodBA przygotuje dla niego backlog i wstawi go do prostej tablicy Kanban. Prostej, lecz można z nią normalnie pracować, zapisuje stan zadań, pozwala na edycję ich zawartości i dodawanie nowych.
Backlog można też pobrać do pliku arkusza kalkulacyjnego.
Użytkownik alternatywnie może też wygenerować strukturę podziału prac (WBS), a następnie pobrać ją na swój komputer w postaci arkusza kalkulacyjnego.
Zachęcamy do sprawdzenia możliwości naszej aplikacji: GoodBA. Wierzymy, że może ona wesprzeć zarówno analityków biznesowych, jak i pracowników nietechnicznych, którzy potrzebują zamówić w IT napisanie rozwiązania.
Szczególnie świetnie sprawdza się w przypadku aplikacji tzw. frontendowych, czyli takich, których główną funkcjonalnością jest odczytywanie, edytowanie i dodawanie danych przez użytkownika końcowego za pośrednictwem interface’u WWW, czyli przeglądarki internetowej.
Gorzej radzi sobie z aplikacjami, w których głównym komponentem są algorytmy obliczające zadane równania lub transferujące dane między różnymi systemami. Wynika to prawdopodobnie z tego, że GPT, z którym GoodBA jest zintegrowana został wytrenowany na danych obecnych w internecie, a tam można znaleźć więcej przykładów systemów tej pierwszej kategorii.
utworzone przez Marcin Żmigrodzki
PMBOK powstał jako encyklopedia zarządzania projektami, korzystając z której firmy muszą zbudować własną metodykę przez właściwą selekcję i adaptację metod.
Dwadzieścia lat temu pojawiło się kilkanaście metodyk zwinnych, z których świat zdominował Scrum z elementami Kanban i XP. Te podejścia zwane też procesami lub frameworkami mają nieco inną logikę. Przykładowo Scrum Guide prezentuje konkretny zestaw terminów, technik, spotkań, dokumentów, ról, które powinny się pojawić w zespole praktykującym zwinność.
(więcej…)
utworzone przez Marcin Żmigrodzki
Spójrz proszę na poniższy wykres. Prezentuje trend wyszukiwań dwóch haseł w Google w USA. Zwróciłeś uwagę, jak czerwona linia opada i przecina się z rosnącą linią niebieską? Otóż czerwona linia to hasło „pmbok”, a niebieska to „agile waterfall”.
Wielokrotnie w artykułach na blogu odnosiłem się do analiz firmy Gartner o nazwie Hype Cycle. Jednak dziś po spędzeniu poranka na przeglądania tuzinów wykresów hype’u w różnych kategoriach nie znalazłem odpowiedzi, co będzie trendem w zarządzaniu projektami w najbliższym okresie.
Sięgnąłem więc do drugiego źródła – aplikacji Google Trends. Google Trends pokazuje częstotliwość wyszukiwań wybranych haseł. Choć nie wyświetla bezwzględnej wartości w danym okresie, to pozwala na porównanie różnych haseł do siebie oraz spojrzenie wiele lat wstecz, aby dostrzec trendy.
Uznałem, że dla potrzeb prognoz tego, co się będzie działo w biznesie dobrze jest wybrać duży, dojrzały rynek, który inspiruje często resztę planety, czyli USA.
Oczywiście hasło „agile waterfall” może być użyte w wielu różnych kontekstach. Na przykład dla poczytania o różnicach między tymi podejściami, znalezienie rozwiązania na projekty hybrydowe, dowiedzenia się w ogóle więcej na temat tego, co dzieje się w świecie project management. Podobnie „kanban” może być wyszukiwany w kontekście zarządzania projektami, jak i produkcją lub magazynem. To są dwa różne światy. Ale zaryzykuję stwierdzenie, że ogólna dynamika i wzajemne proporcje popularności tych terminów są symptomatyczne.
Dla porównania kolejny wykres pokazuje takie terminy, jak: „scrum” (niebieski), „kanban” (czerwony), „pmbok” (źółty), „prince2” (zielony). Nie użyłem słowa „waterfall”, bo ma ono jeszcze inne znaczenia, co bardzo zaburzyłoby wykres.
Jak widać w 2004 wszystkie te hasła za wyjątkiem „prince2”, były na tym samym poziomie popularności. Ale… „pmbok” od lat powoli tracił, a „kanban” i „scrum” zyskiwały. Teraz widać, dlaczego PMI tak mocno przebudował PMBOK Guide w kierunku zwinności.
Dla porównania przyjrzałem się jeszcze innym czterem terminom: „pmbok” jako punkt odniesienia (niebieski), „kaizen” (czerwony), „six sigma” (żółty), „scrum” (zielony). Jak widać niesłychanie niegdyś modna Six Sigma w USA, zalicza spadek, choć wyhamowujący. Zgaduję, że odnalazła swoją niszę i tam jest stosowana, ale jest to dużo mniejszy obszar niż niegdyś. Podobnie ma się sytuacja z Kaizenem.
Moja interpretacja
Sądzę, że metody zwinne z sukcesem zdobywają kolejne dziedziny gospodarki i teraz sięgnęły do obszarów, które były zarządzane w sposób tradycyjny. Albo pracownicy z tych obszarów chcą dowiedzieć się, o co chodzi z tym agilem, albo szukają sposobu na wdrożenie go. Jeżeli prawdą jest, że próbuje się go wdrażać w dziedzinach nie związanych z produkcją oprogramowania, to zobaczylibyśmy to na wykresie popularności słów w wyszukiwaniach.
I… ta dam. Niebieska linia to słowo „pmbok”, a czerwona to „hybrid project”.
Widzisz trend opadający tej pierwszej i wznoszący tej drugiej?
Moja teza jest taka, że aktualnie mnóstwo organizacji poszukuje formuły połączenia filozofii kaskadowej ze zwinną. Z jednej strony chcą zachować kontrolę nad kosztami, celami, efektywnością zespołów i całych firm, a z drugiej chciałyby dać zespołom operacyjnym więcej autonomii, bo zauważają, że poczucie sprawczości wzmacnia motywację wewnętrzną, zwiększa reaktywność na zmiany oraz podnosi poziom innowacyjności. Przy okazji organizacją chcą jeszcze załatwić sobie problem skalowania Scruma do dużych struktur.
Jest pewna koncepcja, która obiecuje skalowalność Scruma, poczucie kontroli na poziomie strategicznym oraz pozostawienie zwinności na dole. To Scaled Agile Framework (SAFE). W internecie można znaleźć mnóstwo artykułów o zaletach i być może jeszcze więcej o słabościach tej koncepcji. Jednego nie można jej jednak zabrać, jest coraz bardziej popularna. Kilka lat temu PMI próbował gonić SAFE, nabywając metodykę Disciplined Agile Delivery (DAD). Jednak zobaczcie na efekty.
Żółta linia to właśnie „discipllined agile delivery”, to ta której nie widać. Czerwona to dla porównania „pmbok”, zaś niebieska to „scaled agile framework”.
Widzisz, drogi czytelniku, jak przecięły się w 2016 roku i jaką dynamikę mają teraz?
Nie sądzę, aby SAFE załatwił problem hybrydowości zarządzania. Zbyt wiele jest problemów przy jego wdrażaniu. Jednak jestem bardzo przekonany, że projekty hybrydowe oraz powiązane z tym skalowanie zwinności, będą istotnym trendem w przyszłości. Pewnie pojawią się kolejne koncepcje, aż w końcu znajdziemy coś, co będzie dostatecznie dobre.
Dodam jeszcze mój osobisty wkład w hybrydyzację projektów. Idea połączenia zwinności z kaskadą chodziła za mną od dłuższego czasu. Szczególnie interesował mnie wymiar zakresu. Z jednej strony mamy WBS, czyli hierarchiczną strukturę prac. Jest wygodny, bo zachowuje logikę, pozwala przechodzić od ogółu do szczegółu, a dzięki temu jest skalowalny. Z drugiej strony mamy Product Backlog, którego zaletą jest łatwość zarządzania, przejrzystość oraz prezentacja istotności poszczególnych wymagań.
Jakiś czas temu wymyśliłem koncepcję połączenia tych dwóch technik i wyszło mi coś takiego. Pierwsze wrażenia są bardzo obiecujące, sam własne projekty trzymam w takiej tablicy. Możliwość budowania hierarchii ułatwia utrzymanie porządku na liście zadań, a możliwość automatycznej konwersji do tablicy Kanban pozwala na płynne przejście do zarządzania ich wykonanie. Nie spotkałem takie funkcjonalności w komercyjnych systemach i ciekaw jestem, czy Ty, drogi czytelniku, gdzieś już ją widziałeś. Jeżeli tak, to koniecznie daj mi znać.
utworzone przez Marcin Żmigrodzki
Pod hasłem projekt ekstremalny, eksploracyjny, eksperymentalny odnalazłem przedsięwzięcia z różnych obszarów:
- Hackathony – to bardzo krótkie projekty od 24 do 36 godzin zwykle. Ekstremalność w nich wynika z innowacyjności rozwiązania i krótkiego czasu na produkcję.
- Początkowe fazy startupów – przez kilka pierwszych lat (od 2 do 5) istnienia startupy często podlega on rewolucyjnym zmianom modelu biznesowego, obietnicy wartości, sposobu organizacji. Nazywane są one pivotami a wynikają z olbrzymiej niepewności rynkowej i czasem technologicznej młodego biznesu.
- Testowanie nowych technologii – takie projekty można spotkać w dużych korporacjach, np. lotnictwie, jak i w mniejszych firmach, które niekiedy wręcz specjalizują się w usługach walidowania nowych technologii. Na wejściu projektu jest hipoteza, że określona technologia zadziała, a na wyjściu jest prototyp albo negatywna informacja zwrotna. Taką technologią może być prototyp urządzenia albo model AI.
- Projekty naukowe – ich niepewność wynika z obszaru, w którym są realizowane. Jeżeli celem projektu jest dokonanie odkrycia naukowego, to musi on być niepewny. Paradoksalnie instytucje finansujące takie badania często wymuszają planowanie i kontrolę takich projektów w sposób kaskadowy.
Koncepcję prowadzenia projektów w sposób bardziej elastyczny niż oferuje to Scrum pojawia się w wielu miejscach, np.:
Prowadząc rozmowy z kilkudziesięcioma praktykami projektów bardziej zwinnych niż agile zauważyłem kilka cech wspólnych. Za każdym razem wywiad prowadzony był w formie pytań otwartych i starałem się unikać naprowadzania rozmówcy na z góry założone wnioski. Mimo tego wielu rozmówców przywoływało podobne spostrzeżenia. Poniżej prezentuję pierwsze z nich. Kolejne będę publikował w późniejszych wpisach oraz w książce, którą prawdopodobnie skończę pisać po wakacjach 2022.
Zmienne iteracje
Cechą powszechnie wymienianą w tytułowych projektach jest to, że iteracje trwają różne odcinki czasu. Jeden z rozmówców wskazał, że u nich sprint w jednym projekcie może trwać od kilku godzin do dwóch tygodni.
Kiedy sprint powinien się skończyć? Otóż wymienia się tutaj dwa warunki. Po pierwsze, gdy zostanie dostarczona wiedza albo wykonany zadany zakres. Estymacje czasowe są tak niepewne, że regularnie sprint trwa krócej lub dłużej niż zakładano. Czasem długi czas wynika z tego, że trzeba czekać wiele dni na wyniki, a czasem dlatego, że zadania są niedoszacowane. Po drugie iteracje może zakończyć „zwrotnica” (termin użyty przez jednego z rozmówców). Projekt dochodzi do punktu, gdy pojawia się rozbieżność nie do wyeliminowania w ramach bieżących założeń. Sprint jest wówczas zakańczany, a zespół musi rozwiązać kolizję, stworzyć nową koncepcję i zaplanować dalszy zakres.
Ponadto generalnie iteracje są dużo krótsze niż w typowym projekcie Scrumowym. Zdarza się, że zespół integruje rozwiązanie co 2 dni i na nowo je planuje.
Mały zespół niezależnych ekspertów
Generalnie zespoły w takich projektach są conajmniej o połowę mniejsze niż w Scrumie. Typowy zespół to 4-6 osób, ale niektórych firmach zajmujących się sztuczną inteligencją podano mi przykłady zespołów dwuosobowych.
Dodatkowo często członkowie zespołu tak planują prace, aby móc działać niezależnie od pozostałych. Wszelkie interface’y między zadaniami tylko podnoszą złożoność projektu, a przez to ryzyko niepowodzenia. Super, gdy ludzie w ekipie projektowej mają rozdzielne kompetencje, np. ktoś od hardware, ktoś od programowania, ktoś od prezentacji, ktoś od modelu AI.
Współpraca stacjonarna
Nawet w hackathonach zdalnych zespół regularnie spotyka się u kogoś w mieszkaniu lub w biurze. Praca twórcza wymaga spędzania ze sobą czasu. Przykuwanie uwagi do problemu, szczególnie, gdy zespół jest zmęczony lub zestresowany, wymaga spotykania się. Jeżeli zespoły pracują w osobnych lokalizacjach to i tak regularnie się spotykają, aby uzgodnić postęp prac.
Powraca spostrzeżenie, że efektywność działań innowacyjnych w formule zdalnej spada i to znacząco. Brakuje dynamiki, brakuje poczucia wspólnego rytmu dowożenia zadań, brak koncentracji na celu, brakuje nieformalnego komunikacji, która potrafi przenosić góry w kilka minut.
Zmienne przywództwo
Wydawało mi się, że w projektach bardziej zwinnych niż Scrum lider będzie wzorem servant leadershipu. Pomyłka! Projekty tak zwinne często doświadczają pivotów, zmian kierunków, koncepcji, wizji. Dodatkowo są narażone na dużą presję ograniczeń czasu, kosztu, wymogów jakościowych. Ktoś musi podejmować szybkie decyzje.
To, co jest często wymieniane to lider z silną wizją, niekiedy wpadający w autokratyzm. Jednocześnie jednak taki, który w chwilach spokojnego produkowania zadanego zakresu oddaje władzę ludziom. Gdy wiadomo, co robić servant leader, gdy trzeba narzucić kierunek – autokrata. To działa w startupach i na hackathonach. Co więcej członkowie zespołów zdają się doceniać takie podejście, bo to dużo porzadkuje.
Podsumowanie
Na liście mam jeszcze kilkanaście wniosków, które nasuwają się po ponad 30 rozmowach z praktykami skrajnie niepewnych projektów. Chętnie będę o nich opowiadał w miarę zdobywania nowej wiedzy od moich rozmówców. Więc jeśli interesuje was tematyka projektów ekstremalnych, to wracajcie do bloga Octigo.
utworzone przez Marcin Żmigrodzki
Wiedzieliście, że Komisja Europejska rozwija własną metodykę prowadzenia projektów w duchu agile? Okazuje się, że tak.
Efektem prac tego zespołu jest stworzenie dwóch książek, które za darmo można pobrać ze stron Unii Europejskiej. Metodykę opracowała organizacja pod nazwą PM2 Alliance. Ku mojemu zaskoczeniu, bo nie wiedziałem do niedawna o jej istnieniu, PM2 Alliance oferuje sześć certyfikatów, członkostwo i własne standardy, a nawet program afiliacyjny dla firm szkoleniowych. Sprawdziłem jednak, czy są jakieś oferty pracy wymagające tych certyfikacji i na terenie EU nie znalazłem żadnej (szukałem w Linkedin). Więc chyba organizacja nie jest jeszcze zbyt rozpoznawalna. Ciekawe, jak się rozwinie.
PM2 Alliance prowadzi działalność również przez regionalne oddziały, organizując konferencje i seminaria. Jednak nie znalazłem żadnej aktywności w Polsce. Nie ma też oddziału w Polsce. Może to jest dobry moment, aby grupa wolontariuszy przejęła inicjatywę i ściągnęła PM2 Alliance do Polski? Trzecia konkurencyjna organizacja do IPMA i PMI? Czemu nie 🙂
Książka pierwsza to zwinne projekty. Podręcznik do zwinnego prowadzenia projektów ma 114 stron i jest za darmo do pobrania z pm2alliance.eu. Nazywa się PM2 – Agile Guide 3.0.1. Napisano go w formule tzw. body of knowledge, czyli leksykony zawierającego omówienie najważniejszych zagadnień z zarządzania zwinnego projektami. Nie jest to zatem metodyka tylko opis różnych podejść wrzuconych do wspólnego worka pod nazwa agile. Treści podzielono rozdziały o różnych metodykach zwinnych, rolach, ceremoniach (głównie chodzi o spotkania), dokumentach i technikach. Aby nie był to tylko spis zagadnień, autorzy dodali wstęp omawiający, czym jest agile i jak go stosować. Do poszczególnych technik dopisano też tabelki RAM, aby pokazać, jakie role są zaangażowane w daną technikę.
Książka druga to kaskadowe. Podręcznik do kaskadowego prowadzenia projektów ma 147 stron i napisano go w bardzo podobny sposób do PMBOK Guide. Nawet układ rozdziałów przypomina tą książkę tyle, że podziału dokonano nie na obszary wiedzy a na grupy procesów: inicjacja, planowanie, kontrola, koordynacja, zamykanie. Zaś podrozdziały z kolei przypominają procesy PMBOKowe. Mają inputy, role, kroki, outputy. W książce proponuje się całą listę nowych dla mnie ról, np. User Representative, Project Owner, Solution Provider, Business Implementation Group. Mam wątpliwości, czy to nazewnictwo się przyjmie, bo w projektach raczej zadomowił się Sponsor. Mam też spore wątpliwości, gdy metodyka oferuje dużo predefiniowanych ról. Pachnie mi to wówczas Prince2 lub AgilePM, czyli malowaniem strusia w barwy kolibra.
Książki są dość obszerne i są za darmo. To ich niewątpliwa zaleta. Jednak układ treści przypomina nieco PMBOK Guide, co utrudnia uczenie się z nich od deski do deski. Raczej mogą pełnić rolę reference book, czyli pozycji, które otwiera się na właściwej stronie, gdy ma się konkretny problem. Mi bardzo brakuje w nich przykładów zastosowania. W książkach pojawia się mnóstwo terminów, np. ArOw (architecture owner), ale brakuje pokazania, jak dany termin w praktyce ma funkcjonować. Wrzucenie tabelki RAM to za mało moim zdaniem, aby dobrze to zrozumieć. Książki natomiast mogą się sprawdzić przy podejściu do certyfikacji oferowanych przez PM2 Alliance, podobnie jak PMBOK Guide pomaga w egzaminie PMP. Wadą obu pozycji jest jeszcze pominięcie opisów technik. Uważa, że właśnie techniki najlepiej jest przedstawić w formie takiego body of knowledge / leksykonu, bo czytelnik może sobie z nich sam dobierać, co mu pasuje do sytuacji.
Ta inicjatywa przypomina inicjatywę, w której sam brałem udział w Polsce. Jej celem było stworzyć podręczniki, rekomendacje i program rozwoju kompetencji zarządzania projektami dla sektora publicznego. Była ona prowadzona pod egidą KPRM. Więcej informacji o niej znajdziecie tutaj.
Więcej informacji o inicjatywie Komisji Europejskiej znajdziecie tutaj. Natomiast samą książeczkę możecie pobrać tutaj i tutaj.
utworzone przez Marcin Żmigrodzki
Wspólnie z grupą zapaleńców podjęliśmy się kilka la temu wyzwania polegającego na spisaniu dobrych praktyk zarządzania projektami, programami i portfelem, które mogłyby być stosowane w administracji publicznej.
Początkowo inicjatywa była prowadzona pod egidą Biura Monitorowania Portfela w Ministerstwie Rozwoju, ale potem została wraz z tym biurem przeniesiona do Kancelarii Prezesa Rady Ministrów.
Zakres inicjatywy realizowanej pod egidą KPRM obejmował napisanie trzech rekomendacji, które być może w przyszłości rozwiną się do standardu: dla projektów, programów i biur portfeli projektów. Dodatkowo jej częścią miał być podręcznik, które stałem się autorem. Podręcznik wyszedł pod nazwą Przewodnik po zarządzaniu.
Wierzę, że tylko chwilowo jestem wyłącznym autorem tej książki, bowiem zamysł strategiczny jest taki, aby powołać komitet autorów, którzy wkrótce zajmą się pisaniem drugiej edycji tego podręcznika. Z mojej perspektywy najważniejsze jest to, aby powyższe pozycje żyły, rozwijały się, były stosowane w praktyce i stały się wspólną własnością. Być może dzięki nim będziemy marnowali nieco mniej pieniędzy na projekty „sasinowe”.
Wszystkie te dokumenty dostępne są w postaci elektronicznej za darmo. Zapraszam zatem do korzystania.
Tu możecie znaleźć wspomniane dokumenty: https://www.gov.pl/web/zarzadzanie-projektami/materialy-do-pobrania
