Wizja przyszłości

Wizja przyszłości

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)

Czy Scrum Master wnosi wartość do projektu?

Czy Scrum Master wnosi wartość do projektu?

Tytułowa hipoteza postawiona została nieco prowokacyjne, ale czytając dziesiątki publikacji naukowych na temat wpływu różnych stylów przywództwa na wdrażanie innowacji, nie mogłem uciec od wrażenia, że coś jest na rzeczy. Mam wrażenie, że rola Scrum Mastera (SM) albo jest pomijana, albo tak naprawdę jej wpływ na efektywność zespołu jet pomijalny.

Gdy zadałem sobie samemu pytanie, co by się stało z zespołami zwinnymi, gdyby nie było SM, ale byłby dostępny menedżer wyposażony w decyzyjność i reprezentujący styl transformacyjny, to doszedłem do konstatacji, że w sumie brak lidera jest o wiele większym problemem niż brak SM. Postaram się przytoczyć poniżej moje argumenty.

Na samym końcu tego artykułu przytaczam fragmenty, w których Scrum Guide odnosi się do roli Scrum Master, aby doprecyzować o jakiej roli jest tu mowa. W praktyce ludzie o takich tytułach w umowie o pracę pełnią rozmaite role, jak kierownicy projektów, liderzy zespołów technicznych, dyrektorzy, ale dla porządku będę odnosił się w tym tekście do wyidealizowanej definicji wziętej ze Scrum Guide.

Według źródła Scrum Master nie jest menedżerem w żadnym aspekcie związanym z decyzyjnością wokół projektu poza wspieranie miłej atmosfery, coachowanie i szkoleniem ze Scruma oraz eliminacją przeszkód ograniczających postęp zespołu. Według przewodnika SM odpowiada za efektywność zespołu, ale jest to dość enigmatycznie opisane jako stwarzanie odpowiednich warunków. Nie ma wskazania, jak umocowany decyzyjnie miałby być SM, jakie decyzje należą do jego wyłącznej kompetencji.

W przewodniku nie zakłada się, że SM jest właścicielem biznesowym wizji projektu, podejmuje decyzje odnośnie kierunku prac, przyznaje zasoby do projektu, rozwiązuje konflikty związane z techniczną wykonalnością, zapewnia finansowanie projektu, zmienia priorytety prac, podejmuje decyzje kadrowe w zespole, zaciąga zobowiązania w imieniu organizacji na zewnątrz (kontrakty), buduje narzędzia motywacyjne. Tego wszystkiego nie robi. To robią prawdziwi liderzy.

To doprecyzowanie było mi potrzebne, aby zagłębić się w problematykę tego, czy SM daje wartość. Tytułowa hipoteza odnosi się do tej wyidealizowanej definicji SM, a nie praktyki, w której SM jest kierownikiem projektu lub innym menedżerem.

Badań wokół wpływu lidera na zespół jest wiele. Sam zapoznałem się z artykułami, w których omawia się badania na około 100 tysiącach ludzi łącznie. Literatura naukowa jest pełna analiz na temat wpływu różnych stylów przywódczych na zespoły ludzkie. Z racji pisania książki i projektach odkrywających coś, skupiłem się na lekturze dotyczącej wpływu liderów na innowacyjność. Według dziesiątek artykułów rola lidera, szczególnie transformacyjnego, jest krytyczna dla powstawania innowacji. Zachęca ludzi, eliminuje negatywne zachowania, nadaje kierunek, zmusza do proaktywności, motywuje pozytywnie itd. Lider transformacyjny, paradoksalny, oburęczny, autentyczny pomaga w zespołach projektowych wytwarzać innowacje. Jednak jest to lider rozumiany jako właściciel kierunku, celu działania i mający decyzyjność. Jedno ze słynniejszych badań projekt Oxygen realizowany w Google (link) pokazał, że menedżerowie dodają wartość do zespołu.

Natomiast niewiele publikacji udało mi się znaleźć na temat zespołów projektowych działających bez lidera. Literatura naukowa używa tu terminu shared leadership. Tyle, że shared leadership oznacza, że to zespół piastuje funkcje przywódcze a nie SM. Zatem znowu nie ten kierunek poszukiwań.

Wyszukiwanie w Researchgate i Academia tematu wpływu SM na efektywność zespołu zwróciło mniej niż 10 artykułów. To bardzo mało, porównując tą liczbę do liczby artykułów na temat roli lidera w zespole. Szczególnie zabawny wydał mi się wniosek z jednego badań ankietowych prowadzonego na 67 osobach. „Scrum Master miał tendencję do oceniania siebie wyżej niż zespół ocenił odpowiedniego Scrum Mastera, podczas gdy Scrum Master miał tendencję do oceniania zwinnego zespołu niżej.” Heh! Jedno z większych badań prowadzone na 5000 ludzi i 2000 zespołów, prowadzone przez 7 lat pokazuje rozmaite czynniki wpływające na efektywność zespołów, ale pomija rolę SM. Interpetuję, że pośrednio wspomina o tej roli pod hasłem „management support”, ale znaczenie „management support” jest dużo szersze. Z resztą jego wpływ na zespól jest przeciętny jedynie w obszarze autonomii zespołu, w pozostałych badanych obszarach (ciągłe doskonalenie, zainteresowanie interesariuszy, responsywność) jest niski. Jako ciekawostkę dodam, że największy wpływ ma autonomia zespołu na jego ciągłe doskonalenie. Innymi słowy, zespoły wyposażone w autonomię, chętniej się doskonalą.

Sądzę, że aby lider faktycznie wpływał na efektywność zespołu zwinnego, musi być wyposażony w decyzyjność. To musi być decyzyjność w obszarze celów projektu i wizji rozwoju firmy, zapewnienia zasobów ludzkich, maszynowych i finansowych, polityki wokół projektu, kierowania ludźmi, motywowania ich i rozwiązywania sporów. Jeżeli brakuje któregoś z tych obszarów u SM, to moim zdaniem jego wartość jest znikoma. Sama facylitacja, coaching i przypominanie o zasadach Scrum, to moim zdaniem za mało, aby wpłynąć na efektywność zespołu zwinnego.

Znikoma, ale nie zerowa. Bowiem na początku stosowania Scruma potrzeba kogoś, kto wejdzie w rolę trenera i nauczy, jak stosować tą metodykę.

Rola Scrum Master wg Scrum Guide

„Scrum wymaga, aby Scrum Master przyczyniał się do tworzenia środowiska, w którym:

  1. Product Owner porządkuje pracę potrzebną do rozwiązania złożonego problemu, tworząc Product Backlog.
  2. Scrum Team przekształca wybraną część tej pracy w wartościowy Increment w trakcie Sprintu.
  3. Scrum Team oraz jego interesariusze sprawdzają efekty i dostosowują swoje działania na potrzeby kolejnego Sprintu.
  4. Powtórz

Scrum Master ponosi odpowiedzialność za to, aby Scrum był stosowany zgodnie z tym, co zostało opisane w tym Przewodniku. Realizuje to zadanie, pomagając wszystkim w zrozumieniu teorii i praktyki Scruma, zarówno w samym Scrum Teamie, jak i w organizacji.

Scrum Master ponosi odpowiedzialność za efektywność Scrum Teamu. Czyni to poprzez stwarzanie mu odpowiednich warunków do poprawy stosowanych przez niego praktyk, zgodnie z regułami Scruma. Scrum Masterzy to prawdziwi liderzy działający na rzecz Scrum Teamu, jak i szerzej rozumianej organizacji.

Scrum Master wspiera Scrum Team na kilka sposobów, m.in.:

  • instruuje członków zespołu, na czym polega samozarządzanie i interdyscyplinarność;
  • pomaga Scrum Teamowi skupić się na wytwarzaniu wartościowych Incrementów zgodnych z Definicją Ukończenia;
  • sprawia, że przyczyny ograniczające postępy Scrum Teamu zostają usunięte; oraz
  • dba o to, aby wszystkie wydarzenia scrumowe się odbywały, były konstruktywne i produktywne
  •  oraz by mieściły się w wyznaczonych ramach czasowych.

Scrum Master wspiera Product Ownera na kilka sposobów, m.in.:

  • pomaga znajdować techniki pozwalające na skuteczne określenie Celu Produktu oraz zarządzanie Product Backlogiem;
  • pomaga Scrum Teamowi zrozumieć potrzebę jasnego i zwięzłego formułowania elementów Product Backlogu;
  • pomaga wprowadzać empiryczne podejście do planowania pracy nad produktem w złożonym środowisku; oraz
  • wspomaga współpracę z interesariuszami, kiedy zostanie o to poproszony lub kiedy zachodzi taka potrzeba.

Scrum Master wspiera organizację na różne sposoby, m.in.:

  • przewodzi organizacji, szkoli i instruuje ją w procesie wdrażania Scruma;
  • planuje i doradza w wykorzystaniu Scruma w organizacji;
  • pomaga pracownikom i interesariuszom w zrozumieniu oraz stosowaniu empirycznego podejścia do złożonych problemów; oraz
  • usuwa bariery pomiędzy interesariuszami a Scrum Teamami.”

Literatura

  • Acar S., et.al: Socio-Economic Status and Creativity: A Meta-Analysis, Journal of Creative Behavior, Vol. 0, 2022.
  • Amabile, T. M.: Motivating Creativity in Organizations: On doing what you love and
  • loving what you do. California Management Review, 40: 39-58, 1997.
  • Anderson N., Potocnik K., Zhou J.: Innovation and Creativity in Organizations: A State-of-the-Science Review, Prospective Commentary, and Guiding Framework, Journal of Management 40 (5), 2014.
  • Benabdelhadi A.: An investigation of the theoretical links between creativity and innovation in
  • Organisations, African Scientific Journal, Vol : 3, Numéro 14 , Octobre 2022.
  • Bledow, R., Frese, M. and Mueller, V. (2011), „Ambidextrous leadership for innovation: the influence of culture”, Mobley, W.H., Li, M. and Wang, Y. (Ed.) Advances in Global Leadership (Advances in Global Leadership, Vol. 6), Emerald Group Publishing Limited, Leeds, pp. 41-69.
  • Brughmans I.: Paradoxical Leadership. How to Make Complexity an Advantage, University of Toronto Press 2023.
  • Choi J.: Individual and Contextual Predictors of Creative Performance: The Mediating Role of Psychological Processes, Creativity Research Journal, Vol. 16, Nos. 2 & 3, 187–199 2004.
  • Gumusluoglu L., Ilsev A.: Transformational Leadership and Organizational Innovation: The Roles of Internal and External Support for Innovation, The Journal of Product Innovation Management, 26:264-277, 2009.
  • Har M., Sadikin A.: The Effect of Authentic Leadership in Increasing Employees’ Psychological Capital and Creativity Moderated by Job Satisfaction, International Journal of Scientific Research and Management, Volume 09, 2021.
  • Hu H., Gu Q., Chen J.: How and when does transformational leadership affect organizational creativity and innovation?, Nankai Business Review International Vol. 4 No. 2, 2013.
  • Hulsheger U., Anderson N.: Team-Level Predictors of Innovation at Work: A Comprehensive Meta-Analysis Spanning Three Decades of Research, Journal of Applied Psychology, Vol. 94, No. 5, 1128–1145, 2009.
  • James M.,  Badri S., Ramos H.: Linking middle-managers’ ownership feelings to their innovative work behavior: the mediating role of affective organizational commitment, Journal of Management & Organization January 2022.
  • Jesus S., Rus C., Lens W., Imaginario S.: Intrinsic Motivation and Creativity Related to Product: A Meta-analysis of the Studies Published Between 1990–2010, Creativity Research Journal, 25(1), 80–84, 2013.
  • Jung K., Kang S., Choi S.: Paradoxical Leadership and Involvement in Creative Task via Creative Self-Efficacy: A Moderated Mediation Role of Task Complexity, Behav Sci (Basel). Oct 2022.
  • Lee A, Lyubovnikova J, Zheng Y and Li ZF: Paradoxical leadership: a meta-analytical review. Front. Organ. Psychol, 2023.
  • Muceldili B., Turan H., Erdil O.: The Influence of Authentic Leadership on Creativity and Innovativeness,  Social and Behavioral Sciences 99, 673 – 681, 2013.
  • Mustafa M., Badri S.: Linking middle-managers’ ownership feelings to their innovative work behavior: the mediating role of affective organizational commitment, Journal of Management & Organization · January 2022.
  • Ononye U.: Authentic Leadership, Leader- Member Exchange, Job Thriving and Creativity Nexus from Public Organisation Context, European Journal of Management Issues, Volume 31(2), 2023.
  • Pirola-Merlo A., Mann L.: The relationship between individual creativity and team creativity: aggregating across people and time, Journal of Organizational Behavour 25, 235-257, 2004.
  • Price C.: Leadership and the art of plate spinning, McKinsey Quarterly, November 1, 2012.
  • Scott-Young C., Maged G., Grisinger A.: Shared leadership in project teams: An integrative multi-level model and research agenda, International Journal of Project Management, 37(4):565– 581, 2019.
  • Rosing K. et al.: Explaining the heterogeneity of the leadership-innovation relationship: Ambidextrous leadership, The Leadership Quarterly 22 (2011) 956–974, 2011.
  • Se-Hyung D., Longzhu D., Nahm A., Gyu-Chang Y.: Fostering innovation and involvement in problem solving through trust and psychological safety: The role of paradoxical leader behaviors, Asia Pacific Business Review 29(2), June 2021.
  • Semedo A. i inni: Effects of authentic leadership, affective commitment and job resourcefulness on employees’ creativity and individual performance, Leadership & Organization Development Journal Vol. 37 No. 8, pp. 1038-1055, 2016.
  • Sun M., He K., Wen T.: The Impact of Shared Leadership on Team Creativity in Innovation Teams—A Chain Mediating Effect Model, Sustainability 15, 1212, 2023.
  • Spiegler S., Graziotin D., Heinecke C., Wagner S.: A Quantitative Exploration of the 9-Factor Theory: Distribution of Leadership Roles between Scrum Master and Agile Team, 2020.
  • Tetlock P.: Expert Political Judgment: How Good Is It? How Can We Know?, Princeton University Press 2017.
  • Tierney P., Farmer S.M., Graen G.B. An Examination of Leadership and Employee Creativity: The Relevance of Traits and Relationships. Pers. Psychol. 1999.
  • Tierney P., Farmer S.M. Creative Self-efficacy: Its Potential Antecedents and Relationship to Creative Performance, Academy of Management Journal 2002.
  • Yuosre B, Saeed F.: Transformational leadership and innovative work behavior, Industrial Management & Data Systems, Vol. 114 Iss 8 pp. 1270 – 1300, 2014.
  • Verwijs C., Russo D.: A Theory of Scrum Team Effectiveness, ACM Transactions on Software Engineering and MethodologyVolume 32 Issue 3 Article No.: 74pp 1–51, 2023.
  • Wang X., Kim T., Lee D.:Cognitive Diversity and Team Creativity: Effects of Team Intrinsic Motivation and Transformational Leadership, Journal of Business Research 69(9), March 2016.
  • Wendy S., Marianne L.: Both/And Thinking: Embracing Creative Tensions to Solve Your Toughest Problems,  Harvard Business Review Press 2022.
  • Xiaosong L.: The State of Shared Leadership Research, Frontiers in Business, Economics and Management Vol. 10, No. 2, 2023.
  • Zhang Y., Waldman D.A., Han Y.L., Li X.B. Paradoxical Leader Behaviors in People Management: Antecedents and Consequences, Academy of Management Journal 2015.
  • Zeb A., Abdullah N., Hussain A., Safi A.: Authentic leadership, knowledge sharing, and employees’ creativity, Management Research Review · December 2019.
Różne oblicza tablicy zadań Kanban

Różne oblicza tablicy zadań Kanban

Tablica zadań inspirowana ideą Kanban niesłychanie rozprzestrzeniła się wśród zespołów projektowych. Oferuje niesamowitą przejrzystość i elastyczność. Przejrzystość wynika z prostoty i tego, że od razu wszystko widać. Kto zajmuje się danym zadaniem, na jakim statusie znajduje się zadanie, ile zadań czeka w ogonku. Elastyczność, bo w kanban obowiązuje tylko kilka zdroworozsądkowych zasad.

Znacznie upraszczając tą metodę można powiedzieć, że:

  1. Zadania płyną z lewa na prawo zgodnie z ustalonym porządkiem kolumn i raczej się nie cofają.
  2. Zespół ustalił jasne kryteria, kiedy zadanie może przeskoczyć między kolumnami.
  3. Zadania posortowane są według ważności z góry na dół.
  4. Członkowie zespołu mają autonomię, jeżeli chodzi o tempo brania zadań do realizacji.
  5. Klient może regularnie dodawać zadania do pierwszej kolumny i zmieniać ich priorytety.
  6. W idealnej sytuacji każdy członek zespołu może podjąć się dowolnego zadania, co zapewnia najoptymalniejszą alokację mocy przerobowych.

Wokół zadań mogą trwać dyskusje, zadania mogą mieć listy kontrolne, można załączać pliki i obrazki do nich.

Jednak jak obserwuję różne zespoły to praktyka stosowania tablicy kanban bywa różna. Za chwilę omówię przykłady, ale najpierw chciałbym rozstrzygnąć powody.

Pierwszym ograniczeniem Kanbana jest liniowość. Zakłada się, że zadania nie wracają i wędrują tą samą ścieżką. Dopóki dla różnych zadań można stworzyć taki sam zestaw etapów, dopóty mogą one być zarządzane wspólną tablicą. Jednak natura prac nawet w jednym projekcie bywa różna. Przykładowo inaczej produkuje się oprogramowanie, inaczej szkoli pracowników, a inaczej projektuje materiały reklamowe. Natomiast wszystkie te zadania mogą być realizowane przez jeden zespół w jednym projekcie.

Drugim ograniczeniem jest bałagan. Kanban dobrze sprawdza się dopóki lista zadań nie przekracza dwóch, trzech ekranów przewijania. Przy dłuższych listach zaczyna się bałagan. Przy większej liczbie zadań pojawia się także potrzeba klasyfikowania, grupowania, zagnieżdżania zadań. Dobrze obrazuje to użycie WBS w projektach budowlanych, albo dzielenie zadań na moduły w projektach typ hardware.

Trzecim ograniczeniem są kompetencje. Bardzo często jednym zadaniem nie może zająć się dowolny członek zespołu, bo się po prostu na tym nie zna. Konkretne zadanie musi trafić do konkretnego eksperta. Wówczas wspólna tablica nie służy balansowaniu zasobów tylko demonstrowaniu bieżących wyzwań i priorytetów.

Czwartym ograniczeniem jest różny cykl produkcyjny. Jedne zadania można machnąć w dzień lub maksymalnie w sprint. Inne jednak wymagają dużo dłuższego czasu, zatem przeskoczą między sprintami. W projektach eksploracyjnych rozwiązuje się to po prost wprowadzając sprinty o nieregularnej długości. Jednak sytuacja, gdy jakieś zadanie wisi na tablicy tygodniami, bo albo zespół czeka na dostawę komponentu z Chin, albo mozolnie zbiera dane badawcze, wprowadza zamieszanie.

Zatem, w jaki sposób zespoły przełamują te ograniczenia kanbana.

Pierwszy z omawianych projektów realizowany był w sektorze kosmicznym. Był to projekt hardware’owy, czyli jego celem było stworzenie urządzenia. Początkowo zespół stworzył klasyczną tablicę z kolumnami reprezentujacymi statusy prac. Tablica była regularnie przeglądana i zadania wędrowały z lewa na prawo. Jednak po kilku miesiącach wykorzystanie tej techniki zaczęło ewoluować. Po ponad roku tablica wyglądała mniej więcej tak:

Jak widać kluczowym wyzwaniem było pokazać stan prac w podziale na główne moduły. Wynikało to z tego, że moduły były różne kompetencyjnie i zajmowały się nimi różne zespoły.

W innym projekcie, tym razem był to startup z obszaru usług internetowych, tablica Kanban wyglądała tak:

W tym projekcie zespół też zaczął od tradycyjnego kanbana, ale po jakimś czasie zaczął modyfikować tablicę. Jak widać ważne dla niego było dodanie trzech kolumn zawierających backlog. Wynikało to z tego, że ów startup miał mnóstwo pomysłów i trzeba było wprowadzić lejek, który porządkowałby ich napływ.

W jeszcze innym projekcie IT wprowadzono kolumny reprezentujące zakresy kolejnych wdrożeń systemu. W innym dodano strumienie prac reprezentujące główne zakresy merytoryczne. W jeszcze innym podzielono prace na eksploracyjne (discovery) i produkcyjne (delivery), dodając odpowiednie kolumny z backlogami.

Czy to źle, że zespoły modyfikują metodyką? Skądże, najważniejsze kryterium to czy dane rozwiązanie działa i przynosi korzyść. Żeby działało, zespół musi się z nim utożsamiać.

Ograniczenia tablicy Kanban dostrzeżono już wcześniej i pojawiło się kilka rozszerzeń.

W niektórych systemach takich, jak Proofhub, Trello można do zadania dodać podzadania. Takie dwa poziomy zadań ułatwiają zarządzanie zakresem, gdy backlog jest bardzo długi.

W innych, jak Teamwork i Productboard, wprowadzono storymap. Jest to tablica Kanban z dodanym wymiarem Y. Zadania są podzielone również na wiersze reprezentujące kolejne etapy lub wdrożenia rozwiązania. Przyklad poniżej:

Wreszcie sam, nieskromnie dodam, również postanowiłem zająć się tym problemem i opracowałem rozwiązanie pozwalające na dowolne zagnieżdżanie zadań. To połączenie logiki WBS i tablicy Kanban.

Wroolo to ciągle jeszcze prototyp, ale starałem się zademonstrować, że możliwe jest dowolnie elastyczne zagnieżdżanie zadań w ramach jednej tablicy. Mimo możliwości przenoszenia ich przez kolejne kolumny, można nie utracić porządku w stworzonej strukturze prac.

Chętnych do sprawdzenia, jak działa filozofia kanban zapraszam do naszych dwóch symulatorów:

  • Agile Game – gra indywidualna na tablicy Kanban, pokazuje różne wykresy dostępne w ramach tej metodyki.
  • Scale Agile – gra zespołowa demonstrująca problemy bilansowania zasobów, wielozadaniowości i priorytetyzowania prac między projektami zwinnymi.

Chętnych do sprawdzenia, jak działa system Wroolo, zapraszam pod adres wroolo.com.

Jedno zastrzeżenie chcę zgłosić. Powyższe rozumienie tablicy Kanban jest zupełnie różne od tego stosowanego w zarządzaniu magazynem lub produkcją. Wspomniany w tym artykule Kanban jest znacznie uproszczoną wersją magazynowo – produkcyjnego, który był jego pierwowzorem.

Hybrydowe zarządzanie projektami

Hybrydowe zarządzanie projektami

Podejście kaskadowe (15000 lat testów) oferuje uporządkowanie i przewidywalność, przynajmniej teoretycznie. Z góry przemyślany produkt finalny, dowożony w terminie i koszcie. W praktyce oferuje natomiast inną korzyść – porządek w dużej skali.

Estymacje mogą okazać się błędne, natomiast jeżeli projekt prowadzony jest metodycznie, to wiadomo dokładnie, w którym miejscu znajduje się błąd i jakiej jest skali. To w konsekwencji umożliwia realizację nawet dużych inwestycji bez wpadania w chaos.

Podejście zwinne (30 lat testów) oferują zaś sprawność działania, przynajmniej teoretycznie. Jednak zbudowanie postaw, modelu mentalnego nastawionego na obserwacje i akceptację zmian zwiększa responsywność projektu na nowe pomysły. To w efekcie ma prowadzić do większej wartości, kosztem utraty kontrolowalności projektu. Ta utrata kontroli mści się ze spotęgowaną siłą, gdy skala projektu rośnie. Zaryzykuję tezę, że agile jest raczej dla projektów małych.

Hybrydowe zarządzanie projektami (dalej będę używał skrótu HPM) powinno być hybrydowe w różnych wymiarach. Zatem dalsze rozważania przeprowadzę po kolei według zakresu, czasu, kosztu, jakości i zespołu.

Zakres

WBS kontra Product Backlog. WBS super moce:

  • Uporządkowanie odgórne.
  • Możliwość uporządkowanego poruszania się po nawet bardzo dużym zakresie, o ile wprowadzono sensowną strukturę.
  • Zgodność z metodami ścieżki krytycznej i wartości wypracowanej. Dla projektów kaskadowych dużą wartością jest możliwość precyzyjnej kontroli stanu. Dzięki WBS jest możliwe wykorzystanie precyzyjnych metod kontroli.

WBS słabości:

  • Odporność na zmiany. WBS zniechęca kierownika projektu do wprowadzania zmian w zakresie.
  • Konsekwencje zmian w WBS w innych wymiarach. Przykładowo zmiana tylko sposobu poukładania komponentów w WBS może wysadzić w powietrze wskaźniki wartości wypracowanej.
  • Ryzyko niekontrolowanego pełzania zmian w sytuacji, gdy planowany produkt finalny nie odpowiada potrzebom klienta.

Product backlog super moce:

  • Niski próg wejścia. Każdy kto miał mamę, pamięta listy zakupów. Backlog to taka lista zakupów tyle, że posortowana według ważności a nie kategorii.
  • Elastyczność wobec zmian. Gdy pojawia sie nowy, ważniejszy pomysł, po prostu ląduje na górze backlogu.
  • Zgodność z tablicą Kanban.

Słabości backlogu:

  • Próbowaliście kiedyś zarządzać backlogiem mającym 200 pozycji? Już przy backlogu długim na dwa ekrany pojawia się problem z utrzymaniem jego aktualności.
  • Brak wewnętrznej logiki i struktury. Backlog to po prostu worek życzeń. Gdyby święty Mikołaj nie był w stanie zapamiętać wszystkich dzieci na świecie, to pewnie używałby backlogu.

W naturalny sposób pojawia się pytanie, dlaczego nie można połączyć obu podejść. I wybrane systemy do zarządzania projektami czynią w tym kierunku kroki. W Trello można wstawiać podzadania do zadania w formie checklisty, w Proofhub dopuszczalne są dwa poziomy zagłębień zadań, w Teamwork karta wymagania może być zdekomponowana na zadania i dopiero one wędrują po kanbanie.

Sam również pokusiłem się, o takie rozwiązanie i byłem strasznie zadowolony, gdy udało mi się je zaimplementować.

Czas

Kaskadowe projekty zakładają istnienie harmonogramu z datami, miejscami alokacji zasobów ludzkich i nieludzkich. Dzięki temu można identyfikować wąskie gardła, optymalnie przydzielać ograniczone zasoby do wielu projektów naraz, przewidywać przepływy finansowe oraz kontraktowe zobowiązania.

Silne strony podejścia kaskadowego:

  • subiektywne poczucie władzy nad czasem,
  • transparentna komunikacja mapy drogowej.

Słabości:

  • niska wiarygodność estymacji,
  • skomplikowane zarządzanie, gdy wprowadzimy wiele zależności do ścieżki krytycznej.

Zwinne projekty zakładają istnienie stałego rytmu (iteracji) i niezdeterminowanego końca.

Silne strony podejścia zwinnego:

  • duża elastyczność zmian wymagań,
  • przejrzystość zadań,
  • wsparcie samoorganizacji zespołu,
  • oparcie na empirycznych czasach a nie teoretycznych estymacjach.

Słabości:

  • łatwość zabałaganienia w przypadku większych projektów,
  • nie odzwierciedlenie różnych procesów produkcyjnych zadań.
  • nie odzwierciedlenie zależności i ograniczeń zadań.

Ta rozbieżność rodzi ryzyka, że projekt kaskadowy zawierający w sobie zwinny rozjedzie się w czasie.

Silne strony filozofii zwinnej:

  • budowanie motywacji wewnętrznej,
  • wzmacnianie postaw nastawionych na innowacji i dostarczanie wartości.

Słabe strony:

  • rozproszenie odpowiedzialności,
  • chaos komunikacyjny w większych zespołach,
  • brak twardego rozliczania i narzędzi motywacji negatywnej w przypadku porażek.

W podejściu hybrydowym często obarczamy kierownika projektu ryzyko rozjazdu sprintów z Ganttem. Większość systemu do kanbana pozwala na wprowadzenie dat zadań (co jest w istocie niezgodne z ideą kanbana), a wiele z nich również pozwala na wyświetlenie widoku kanbana na kalendarzu albo na uproszczonym Ganttcie.

Koszt

Tu mam największą zagwozdkę. Bo agile nic nie mówi o koszcie projektu a waterfall dużo.

Jednak mając rozliczone co do godzin zadania (co jest nie do końca zgodne z ideą autonomii zespołu) można śledzić zużycie środków finansowych w czasie i śledzić szansę zmieszczenia się w budżecie. Raportowanie kosztu wspiera większość systemu do kanbana, np. Proofhub, Monday, Clickup, Jira, a nawet Trello po zainstalowaniu odpowiedniego pluginu.

Zespół

I tutaj mamy największy rozjazd stylów współpracy. Kaskada wspiera przywództwo w stylu dziel i kontroluj. PM dekomponuje zadania, deleguje je na członków zespołu, a potem odpytuje, czy praca idzie zgodnie z planem.

Silne strony podejścia kaskadowego:

  • nieograniczone możliwości skalowania zespołu przez delegowanie i pionizowanie struktury organizacyjnej,
  • jasny podział odpowiedzialności.

Słabości:

  • redukcja motywacji wewnętrznej i innowacyjności zespołu,
  • kierownik projektu może stać się wąskim gardłem.

Natomiast w agile nie ma kierownika projektu. Zespół zbiorowo odpowiada za zadania i autonomicznie je sobie przydziela.

Myślę, że dużo zależy od stylu. Jeżeli mamy kierownika projektu, który z jednej strony potrafi  wyciągnąć estymacje czasu i kosztu z zespołu, a z drugiej strony kontroluje postęp prac w sposób nieinwazyjny, wspiera w trudnych momentach i ufa ludziom, to ma to szansę zadziałać. Przyjazna dyktatura jest kwestią stylu.

Podsumowanie

Od kilku lat zaczyna się pojawiać, narazie nieśmiało, hasło hybrydowego zarządzania projektami. Poniżej zamieszczam wykres Google Trends pokazujący jego rosnącą popularność.

 

 

 

 

Dlaczego HPM może okazać się nowym trendem? Bo ciągle pozostaje problem skalowalności agile’a. SAFe spotyka się dzisiaj z olbrzymią falą krytyki, ale potrzeba organizacji, aby jednocześnie dać autonomię i otworzyć projekty na zmiany oraz zapewnić kontrolę i uzgadnianie z zadaną strategią pozostaje.

Bo projekty kaskadowe lepiej zapobiegają nieprzewidzianym kosztom zmian, a projekty zwinne lepiej odkrywają wartość dla użytkownika końcowego.

Na tytułowym obrazku hybrydowy project manager według koncepcji MidJourney. Żeby nie zostać posądzonym o seksizm, załączam też wersję ilustracji kobiecą.

 

Green Project Management

Green Project Management

Przy okazji niedawnego szkolenia w ręce wpadła mi metodyka PRISM przygotowana przez stowarzyszenie Green Project Management. Postanowiłem się podzielić moimi spostrzeżeniami na temat tej metodyki i w ogóle podejścia Green Project Management.

GPM jest stowarzyszeniem przypominającym nieco PMI 40 lat temu. Chyba stowarzyszeniem, bo trudno mi było znaleźć na ich witrynie konkretne dane rejestrowe. Ale odnoszę wrażenie, że grupa woluntariuszy zorganizowała się wokół wspólnej idei uczynienia inwestycji projektowych bardziej zielonymi.

GPM oferuje 3 poziomy certyfikatów, które w formule ich zdobywania bardzo przypominają PRINCE2 Foundation i Practitioner. Krótkie test albo studium przypadku i rozmowa. Szybki test ilości ogłoszeń o pracę wymagających któregoś z tych certyfikatów pokazuje, że jeszcze długa droga przed nimi. Dla porównania PMP w momencie pisania tego tekstu występował w Polsce w ponad 5000 ogłoszeń, GPM-b + GPM-s + GPM-m w żadnym, dosłownie zero ogłoszeń. Rozszerzyłem wyszukiwanie na USA i wyniki były identyczne 347 000 do zera na korzyść PMP. Nie oceniam w żadnym wypadku merytoryki tych certyfikatów tylko popularność wśród pracodawców, ale uważam, że ten wskaźnik jest niestety bardziej pragmatyczny.

Wiedza na certyfikacji bazuje na kolejnym komponencie, czyli metodyce PRISM. De facto nie zdefiniowałbym PRISM jako metodyki, ale raczej nakładki na metodykę, która podkreśla istotność pewnych obszarów. Czyli PRISM nie powie, jak prowadzić projekt, tylko, jakie postawy i zachowania są pożądane w projekcie.

A te postawy należą do trzech grup: środowisko naturalne, lokalna społeczność i prawa człowieka. PRISM promuje prowadzenie projektów zgodne z prawem, promujące lokalną ekonomię, dbanie o interesy lokalnej ludności, poszanowanie praw człowieka takich, jak work-life balance, uczciwa płaca, brak dyskryminacji itp.

Problemem dla mnie jest fakt, że te dobre praktyki są przedstawione na poziomie bardzo ogólnym. PRISM nie mówi, co operacyjnie robić, tylko, co warto mieć na uwadze. Oznacza to, że z dużą łatwością można wdrożyć PRISM bardzo fasadowo. Wystarczy zademonstrować kiika przykładów właściwych starań.

PRISM jest metodyką kaskadową. Promuje się z góry zdefiniowany cykl życia projektu składający się z inicjacji, 4 etapów projektowych i etapu obserwowania korzyści po projekcie. Fajne jest uwzględnienie zarządzania korzyściami, którego brakuje w PMBOK a jest obecne w Standard for Program Management PMI.

Godne uznania jest też ujęcie w cyklu życia etapu eksploracji, w trakcie którego zespół zdobywa wiedzę o możliwych do realizacji koncepcjach. Jak widać eksploracja przebija się powoli do świadomości w różnych inicjatywach.

Za wyjątkiem jednak kilku praktyk brakuje w PRISM konkretów. Brakuje operacyjności, czyli wiedzy jak wdrożyć PRISM w konkretnej sytuacji. Jest to szczególnie istotne, bo GPM proponuje audyt organizacji w zakresie wdrożenia ich metodyki.

Podsumowując, GPM jest mało znaną inicjatywą, która od kilkunastu lat próbuje się przebić na rynek. Przebija się za pomocą certyfikatów, metodyki PRISM oraz audytów organizacji PSM3. Jednak odnoszę wrażenie, że o ile jakaś regulacja unijna nie wymusi malowania projektów na zielono, to długa droga przed GPM, aby osiągnąć status zbliżony do PRINCE, IPMA, czy PMI.

Tytułowe zdjęcie: Bart Ros https://www.pexels.com/pl-pl/zdjecie/drewno-droga-swit-krajobraz-10915473/

Ps.

Emilia wysłała mi informacje rejestracyjne GPM, które udało się odnaleźć po rejestracji znaku towarowego. GPM okazuje się być spółką z ograniczoną odpowiedzialnością (LLC) zlokalizowaną w Fort Wayne.

Syndrom czystej kartki – AI w zarządzaniu projektami

Syndrom czystej kartki – AI w zarządzaniu projektami

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. Przygotowania 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%!
  6. 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.

Zapisz się na nasz newsletter

Zapisz się na nasz newsletter

Twój e-mail został zapisany