Wyzwania w dzieleniu projektów na mniejsze części

Być może często słyszysz w zespole „Niech ktoś to podzieli” i nie bardzo wiadomo, kto dokładnie powinien się za to zabrać. To jedno z częstych wyzwań w dzieleniu projektów na mniejsze części. Omawiamy też jeszcze kilka innych problemów z tym związanych. Dostaniesz od nas po kilka gotowych rozwiązań do każdego z nich. Odciąży to Twój zespół i sprawi, że dzielenie pracy stanie się naturalnym elementem codziennego działania.
Porządny Agile · Wyzwania w dzieleniu projektów na mniejsze części
Spis treści
Problem z dobrym zrozumieniem celu projektu
Presja biznesu na wdrożenie całości
Wyważenie perspektywy technologii i biznesu przy podziale
Czasochłonność procesu dzielenia
Mentalność „Niech ktoś podzieli”
FAQ: Wyzwania w dzieleniu projektów na mniejsze części
Transkrypcja podcastu „Wyzwania w dzieleniu projektów na mniejsze części„
Problem z dobrym zrozumieniem celu projektu
Naszym zdaniem jest to częsty bloker, który sprawia, że bardzo trudno przystąpić do sensownego podziału projektu czy inicjatywy, jeżeli tak naprawdę nie rozumiemy, co chcemy uzyskać. Oczywiście, bez zrozumienia celu możemy mechanicznie spróbować podzielić projekt na mniejsze części, ale prawdziwa różnica pojawia się wtedy, gdy bardzo dobrze rozumiemy cel. W takiej sytuacji otwierają się możliwości zrealizowania pewnych rzeczy w znacznie mądrzejszy sposób, zamiast patrzeć na projekt bez zrozumienia, co tak naprawdę chcielibyśmy tym projektem uzyskać. Zrozumienie celu jest tutaj fundamentalnym wstępem do dobrego podziału, dlatego pierwsza porada może wydawać się oczywista.
1. Zapewnij, że cel jest zrozumiały
Można to osiągnąć na kilka sposobów. Jednym z nich jest dobre spotkanie typu kick-off, czyli otwarcie inicjatywy, projektu, zmiany produktowej lub kolejnego etapu rozwoju produktu.
Nie zakładaj, że inni wiedzą to samo, co ty. Zadbaj o klarowny wstęp, krótkie exposé i odpowiednie wprowadzenie zespołu w dotychczas zebrane informacje oraz kontekst biznesowy, który uzasadnia realizację danego przedsięwzięcia. Takie przygotowania do kick-offu nie pójdą na marne, ponieważ zrozumienie celu można wzmacniać również przez powtarzanie tych informacji. Warto zatem wypracować praktykę regularnego wracania do celu przy każdej nadarzającej się okazji. Mogą to być Przeglądy Sprintów, jeśli stosujesz Scruma, a także demo, spotkania projektowe, warsztaty lub podsumowania prac. Każde z tych miejsc, w których zbiera się zespół lub jego wyraźna część, stanowi okazję do przypomnienia, jaki jest cel i na czym polega istota aktualnie realizowanych działań. Warto przyjąć założenie, że wielokrotne powtarzanie – także w różnych formach – pomoże utrwalić cel i umożliwi jego trwalsze osadzenie w zespole.
Dzięki temu, gdy nadejdzie moment związany z podziałem pracy, zarówno na początku, jak i w dalszych etapach, cel będzie pamiętany, łatwy do przywołania i na tyle zrozumiały, że stanie się dla zespołu oczywistością.
2. Używanie sprawdzonych technik wspierających pracę na celach
Warto rozważyć takie techniki jak impact mapping, podejście golden circle, product vision board, OKR-y czy opportunity solution tree. Jeśli te nazwy są ci obecnie mało znane, możesz je łatwo wyszukać w internecie. Mamy doświadczenie z większością tych narzędzi i możemy potwierdzić, że nie tylko wspierają zrozumienie, po co realizowane są poszczególne działania, lecz także są zazwyczaj narzędziami wizualnymi. Praca z nimi to nie tylko rozmowa, to również element wizualny, który znacząco poprawia i zwiększa zrozumienie tego, co stanowi istotę danej zmiany.
W sytuacji, gdy zespół przygotowuje się do sesji dzielenia, a zespół nie korzystał wcześniej z tych narzędzi, warto sięgnąć po jedno z nich jako rozgrzewkę lub wstęp. Jeśli zespół pracował z nimi wcześniej, dobrze wrócić do nich na początku sesji.
3. Sprawdzenie zrozumienia – na przykład parafraza przez uczestników
Trzecia praktyka polega na jak najczęstszym sprawdzaniu, czy zespół rozumie cel. Nie tylko osoba zarządzająca projektem, lider produktu czy manager zespołu może komunikować cel, bo możesz poprosić uczestników, aby w formie ćwiczenia lub krótkiej wypowiedzi swoimi słowami opisali, jaki jest cel danej inicjatywy. Dzięki temu sprawdzisz, czy cel jest zrozumiały, a jednocześnie wprowadzisz element, który aktywizuje lub rozgrzewa zespół, i wykorzystasz różnorodność zespołu, różne perspektywy i specjalizacje, dzięki którym uczestnicy patrzą na sprawy w inny sposób. Parafraza celu lub próba jego opisania z różnych perspektyw poprawia jakość zrozumienia. Dlatego regularnie sprawdzaj zrozumienie, na przykład prosząc osoby z zespołu o parafrazę celu.
Presja biznesu na wdrożenie całości
Mamy na myśli wdrożenie całego projektu, całego zakresu, całej inicjatywy albo czasami pełnej funkcji w produkcie. Taka sytuacja może wywołać niechęć lub poczucie bezsensu dzielenia pracy. Pojawia się wtedy pytanie: po co dzielić, skoro na końcu i tak trzeba wdrożyć całość zgodnie z pierwotną definicją, a presja biznesu lub managementu może wywołać wrażenie, że podzielenie pracy to proszenie się o kłopoty, bo strona wywierająca presję może uznać, że zespół próbuje wycofać się z części zakresu. To może wywołać różne negatywne emocje i sprawić, że zespół nie chce podjąć się dzielenia pracy.
1. Pokazanie korzyści, które wynikają z dekompozycji na wczesnym etapie
Warto założyć, że nie wszyscy znają te korzyści ani ich wcześniej nie doświadczyli. Mamy na myśli przede wszystkim wczesne ograniczanie ryzyk biznesowych. Dzięki temu możesz wcześniej sprawdzić, czy proponowane rozwiązanie odpowiada na potrzebę rynkową i czy jest poprawnie zaprojektowane. Możesz również ograniczyć ryzyka technologiczne, na przykład upewniając się, że zespół potrafi pracować z wybraną technologią. A także ryzyka społeczne, czy osoby odpowiedzialne za implementację potrafią ze sobą skutecznie współpracować. Ryzyka to jedna strona tej sytuacji, a druga strona dotyczy dostarczenia najważniejszej wartości, esencji zmiany, możliwie jak najwcześniej.
2. Zrozumienie obaw interesariuszy, które blokują ich przed podziałem
Warto uruchomić empatię i wczuć się w perspektywę interesariuszy. To, co z perspektywy zespołu wykonawczego wygląda jak niezrozumiała albo nawet nieracjonalna presja, może wynikać z unikalnych doświadczeń konkretnej osoby, managera lub grupy w organizacji. Możesz tego nie dostrzegać, a mimo to warto to uwzględnić. Co to oznacza w praktyce? Odniesiemy się do przykładu z jednej z firm, z którą współpracowaliśmy. Zespół odpowiedzialny za operacje, na przykład za działania posprzedażowe i obsługę klienta, obawiał się, że ich narzędzia zostaną uznane za nieistotne albo w ogóle nie powstaną w ramach projektu, dlatego podchodzili do negocjacji twardo i sceptycznie oraz nie chcieli dzielić zgłoszonych wymagań czy potrzeb narzędziowych. Wynikało to z doświadczeń z poprzednich projektów, w których pod presją czasu narzędzia dla nich w ogóle nie powstawały, a zespół musiał obsługiwać klientów za pomocą Excela i ręcznie pisanych maili, ponieważ system nie obejmował ich potrzeb, mimo że pierwotnie był tak planowany. Dlatego warto uwzględnić tę perspektywę i zrozumieć obawy interesariuszy.
Innym przykładem obawy jest sytuacja, w której ktoś obiecał komuś bardzo precyzyjny i często rozbudowany zakres. Często te osoby nie mówią o tym wprost albo trudno im przyznać, że złożyły taką obietnicę, dlatego z oporem podchodzą do pomysłu podzielenia tej całości na mniejsze części. Obawiają się, że podział może stać się pretekstem do usunięcia części zakresu.
W części organizacji pojawia się pęd do realizowania dużych i spektakularnych projektów. W takim kontekście idea dzielenia może wydawać się sprzeczna z tym podejściem. Wynika to z potrzeby tworzenia dużych projektów strategicznych, spektakularnych premier oraz zdobywania nagród za przełomowe odkrycia lub innowacje. Warto uwzględnić tę perspektywę, bo ktoś może przygotowywać się na konferencję dotyczącą innowacji w bankowości i chce opowiedzieć na scenie o dużych, efektownych planach, na przykład o nowych implementacjach opartych na AI. To nie oznacza, że spektakularnych projektów nie da się podzielić, ale warto uwzględnić kontekst i zadbać o komunikację, ponieważ jedno nie wyklucza drugiego. W najgorszym razie wdrożenie może odbyć się jako spektakularna premiera, ale wciąż warto dzielić pracę wcześniej i dostarczać ją etapami, nawet jeśli część rezultatów nie trafi od razu do publikacji.
3. Przepracowanie z biznesem różnicy między podziałem na części a obietnicą realizacji całości
W skrócie: podział pracy na mniejsze części nie oznacza automatycznie rezygnacji z wdrożenia całości. Jednocześnie widzimy tu pewną kontrowersję, bo możesz mieć doświadczenia z obecnej lub poprzednich firm, w których podział pracy prowadził do wdrożenia tylko części rozwiązania z powodu ograniczeń czasowych. Zdarza się, że ta część jest satysfakcjonująca, a elementy, których nie udało się zrobić wcześniej, nie trafiają już do realizacji, bo organizacja przechodzi do kolejnych koncepcji. W założeniu nie musi to wyglądać w ten sposób, ale rozumiemy, że wcześniejsze doświadczenia mogą skłaniać do ostrożnego podejścia do tej porady.
W szczegółach pojawia się druga kontrowersja – koncepcja potrzebnej całości. Może się okazać, że ktoś kurczowo trzyma się wyobrażenia całości zakresu lub rozwiązania, które powstało na bardzo wczesnym etapie. Czasami niektórzy trzymają się tej wizji, zakładając, że od początku wiedzieli, czego potrzeba, i że cały pierwotny zakres odpowiada dokładnie na potrzeby rynku lub klienta. To prowadzi z powrotem do kwestii ryzyk biznesowych. Zbyt wiele decyzji podjętych na zbyt wczesnym etapie może tworzyć złudzenie, że wiadomo, czego naprawdę potrzeba. To dlatego ta rada wiąże się z podwójną kontrowersją, ale na bardzo wczesnym etapie bardziej dyplomatyczne może być stwierdzenie: „Podzielimy na kawałki i wdrożymy to, co okaże się potrzebną całością”, przy jednoczesnym założeniu, że potrzebna całość nie musi oznaczać pełnego zakresu rozumianego na dziś, bo dopiero czas pokaże, co dokładnie stanie się tym, co warto wdrożyć.
Wyważenie perspektywy technologii i biznesu przy podziale
Mamy na myśli sytuację, którą można zobaczyć po dwóch stronach tej samej osi. Z jednej strony podział powstaje wyłącznie w izolacji biznesowej, bez udziału osób technologicznych, co sprawia, że zespół traci ważną perspektywę wykonalności, a także dostęp do opcji proponowanych przez osoby technologiczne, które widzą rozwiązania spoza perspektywy biznesowej. Z drugiej strony pojawia się próba stworzenia podziału wyłącznie technologicznego, która może doprowadzić do sensownego rozbicia pracy na mniejsze elementy, ale jeśli zespół nie rozumie aspektów biznesowych albo nie może dopytać o ich konsekwencje, na przykład o biznesowy wpływ rozwiązania, taki podział będzie jedynie częściowy, i na pewno nie stanie się podziałem optymalnym.
1. Zaproś przemyślany skład będący reprezentacją potrzebnych stron
To podejście wykracza poza dwie skrajne perspektywy wspomniane wcześniej, bo możesz potrzebować również perspektywy prawnej, perspektywy user experience, więc liczba uczestników warsztatów lub aktywności związanych z podziałem będzie zależeć od kontekstu i specyfiki produktu. Zapraszając osoby, warto od razu wyjaśnić, po co ktoś ma się pojawić, z jaką wiedzą przychodzi i jaką perspektywę ma reprezentować. Często słyszymy, że zaproszono przedstawicieli IT, architektów czy senior developerów, ale podczas spotkania te osoby prawie się nie odzywały, nie zabierały głosu i nie wnosiły swojej perspektywy, nawet gdy ktoś je o to prosił. Problem może wynikać z tego, że zaproszono te osoby „bo tak trzeba”, „bo wypada”, podczas gdy te osoby nie wiedziały, po co w ogóle pojawiły się na spotkaniu. Dlatego osoba zapraszająca, niezależnie od roli, odgrywa kluczową rolę, ponieważ powinna jasno wyjaśnić uczestnikom, czego od nich oczekuje, w jakiej roli mają wystąpić i jakiego wkładu oczekuje od każdej osoby. Dzięki temu nikt nie będzie się bał, wycofywał ani powstrzymywał z wypowiedzią, szczególnie że podczas dzielenia pracy mogą pojawić się tarcia. Ktoś może zaproponować podział korzystny biznesowo, ale niepasujący technologicznie, inny pomysł może wyglądać dobrze z perspektywy biznesu i technologii, ale straci sens z punktu widzenia prawa, albo bezpieczeństwa. Każdy powinien rozumieć, dlaczego uczestniczy w warsztacie lub spotkaniu, i jaką rolę pełni w tych aktywnościach.
2. Ustal facylitatora i oczekuj od tej osoby, że zadba o każdą perspektywę. 
Druga wskazówka polega na tym, aby ustalić facylitatora i oczekiwać od tej osoby zadbania o każdą perspektywę. Aby wszystkie dostępne perspektywy wybrzmiały równomiernie, zgodnie z tym, o czym wspomniano wcześniej, a także aby rozmowy miały właściwą głębokość. Na przykład facylitator powinien dbać o to, aby zespół nie schodził w bardzo niskopoziomowe detale technologiczne, ponieważ może to wywołać u osób nietechnicznych wrażenie, że spotkanie jest źle poprowadzone. Kto może poprowadzić takie spotkanie? Może to zrobić analityk, lead developer albo architekt. Nazwa roli nie ma tutaj większego znaczenia. Ważne, aby ta osoba była dobrze przygotowana do poprowadzenia warsztatu, a czasem całej serii warsztatów, ponieważ nie zawsze jest to jednorazowe działanie, oraz aby facylitator dbał o równomierne uwzględnianie wszystkich perspektyw, zamiast reprezentować jedynie własny punkt widzenia. W przeciwnym razie spotkanie nie stworzy dobrej reputacji dla podobnych inicjatyw w przyszłości.
3. Zastosować techniki wizualne, które są zrozumiałe zarówno dla biznesu jak i IT
Mamy na myśli przede wszystkim Story Mapping, technikę, którą lubimy, której używamy, często rekomendujemy i stosujemy w pracy biznesowej oraz przy tworzeniu podcastu. Story Mapping jest na tyle powszechną techniką, że wielu odbiorców powinno go już znać, ale jeśli nadal go nie znasz, zdecydowanie zachęcamy, aby się z nim zapoznać lub wziąć udział w warsztacie, w którym się go stosuje. Story Mapping świetnie sprawdza się w wizualizacji zakresu i dostępnych opcji, oraz pomaga zrozumieć, czym jest całe przedsięwzięcie i na jakie mniejsze elementy można je podzielić. Elementy te najczęściej bazują na perspektywie użytkownika, dzięki czemu pozostają czytelne zarówno dla biznesu, jak i dla osób odpowiedzialnych za implementację. Obiecująco prezentuje się także zastosowanie Event Stormingu. Jeśli facilitator dobrze poprowadzi takie spotkanie, Event Storming może przynieść rezultat podobny do Story Mappingu, choć działa według nieco innych zasad.
Czasochłonność procesu dzielenia
Często, gdy przekonujemy zespół, że warto dzielić pracę, słyszymy argument, że dzielenie wymaga dodatkowej pracy, ktoś musi to zrobić i wprowadzić do systemu, a pojawi się wiele elementów, którymi trzeba później zarządzać i je koordynować. Zgadzamy się, że wymaga to dodatkowego wysiłku, ale dla wielu zespołów i organizacji największym wyzwaniem jest to, jak właściwie zacząć. Co w takiej sytuacji rekomendujemy?
1. Zmiana myślenia: dzielenie to nie koszt, lecz inwestycja w proces dostarczania
Przede wszystkim warto zmienić sposób myślenia i nie traktować dzielenia jako kosztu, lecz traktować je jako inwestycję w proces dostarczania, która pomaga zespołowi lepiej zrozumieć zakres, daje lepszą kontrolę nad postępem prac, ponieważ praca na mniejszych elementach ułatwia monitorowanie zmian, a jednocześnie zmniejsza złożoność poszczególnych kroków dużej inicjatywy. Idzie za tym również wiele korzyści technicznych, ponieważ przepływ pracy w zespole przy mniejszych elementach powinien przyspieszyć, dzięki temu, że szybciej można coś zaimplementować, szybciej przeprowadzić code review, szybciej dokonać merge’u, a ostatecznie szybciej wypuścić na środowisko produkcyjne. Zyskujemy więc wiele pozytywnych efektów, pod warunkiem, że zainwestujemy czas w podzielenie pracy na mniejsze fragmenty.
2. Reużywalność narzędzi i instrukcji
W praktyce ta inwestycja może zajmować określony czas, a część tego czasu pochłania przygotowanie lub zbędne zagłębianie się w techniki i narzędzia związane z dekompozycją. Warto, aby osoby pełniące role liderskie lub odpowiadające za proces pracy wykorzystywały każdą okazję do przygotowania i ponownego używania checklist, na przykład sposobów dzielenia pracy. To może być prosta lista metod, którymi można podzielić projekt lub element omawiany na warsztacie. Mogą to być również przygotowane szablony lub wcześniej opracowane wersje technik, o których wspominaliśmy, na przykład gotowe tablice w Miro albo elementy przygotowane do przeniesienia na flipchart czy kartki. Warto także korzystać ze schematów, które zespół już zna. Dzięki temu nie trzeba za każdym razem zastanawiać się, o co chodzi facylitatorowi, bo zespół wypracowuje z czasem gotowe ścieżki działania, które często wymagają minimalnych instrukcji i pozwalają wejść w pracę niemal automatycznie. Oczywiście instrukcje nadal powinny istnieć, ale mogą być zwięzłe i nie wymagać dodatkowych wyjaśnień, a jednocześnie powinny umożliwiać płynne wejście w zadanie. Dzięki temu zespół od razu przechodzi do pracy, bez dyskusji typu „o co chodzi?” lub „co masz na myśli?” bo wszyscy wiedzą, co oznaczają polecenia dotyczące dzielenia na elementy, te schematy są już znane i naturalne. To daje realną okazję do oszczędności czasu, o ile zespół podchodzi do tego świadomie i dzięki temu kolejne procesy dzielenia, oparte na check listach lub schematach, wymagają mniej czasu.
3. Nabranie wprawy w dzieleniu
Gdy zespół zbuduje doświadczenie i będzie korzystał z checklist oraz narzędzi, które ułatwiają pracę, wtedy dzielenie staje się naturalne, płynne i oczywiste i przebiega w sposób sprawny. Przestaje wymagać zastanawiania się, nic nie blokuje zespołu, znika obawa dotycząca tego, jak to przeprowadzić, bo dzielenie staje się naturalną częścią pracy zespołu, czymś oczywistym, na co warto poświęcić czas. To nie wydarzy się samo, ale pierwsze, drugie i trzecie podzielenie pracy zazwyczaj przynosi wartościowe efekty, które budują w „pamięci mięśniowej” zespołu przekonanie, że warto to robić, więc z czasem pojawia się nie pytanie „czy to zrobimy”, ale „kiedy to zrobimy”, bo zespół wie, że to działanie jest potrzebne i ma sens. Zespół kojarzy również, że wykonał to wiele razy, więc zrobi to ponownie z równą łatwością, gdy pojawi się kolejna okazja lub potrzeba, aby wykorzystać te umiejętności.
Wyzwanie związane z czasochłonnością dzielenia często przecenia lub niepotrzebnie podkreśla ta grupa, która tego dzielenia nie wykonuje. Tymczasem osoby, które dzielą pracę rutynowo, traktują to jako nieodłączną część pracy, wykonują to płynnie i nie tworzą wokół tego niepotrzebnego zamieszania.
Mentalność „Niech ktoś podzieli”
To sytuacja, w której nie wiadomo, kto właściwie powinien podjąć się dzielenia pracy. Możemy czuć, że warto byłoby podzielić pracę, ale zakładamy, że nie my powinniśmy się tym zająć. Uważamy, że powinni zrobić to „oni” albo „ktoś”. Jeśli wiele osób w organizacji myśli w ten sam sposób, unikając wzięcia odpowiedzialności za działanie, czas będzie mijał, co jest nieuniknione, i zaczniemy pracować na tym, co mamy, czyli na projekcie w obecnym stanie, bez jakiegokolwiek podziału. Jak zatem poradzić sobie z taką mentalnością?
1. Zasada: „Widzisz linię podziału, zgłaszasz propozycję podziału”
Pierwsza praktyka, choć nie uderza w problem bezpośrednio, polega na podziale na poziomie całego portfela. Nie rozwiązuje to wprost mentalności „ktoś inny powinien podzielić”, bo w pewnym sensie sugeruje, że podział faktycznie może wykonać ktoś inny, że do zespołów wykonawczych, produktowych lub projektowych trafiają elementy o bardzo dużej skali, często już wstępnie zdefiniowane w sposób, który utrudnia ich podział. Dlatego warto na poziomie portfela, produktu, roadmapy lub całego zbioru projektów jeśli tak działa dana organizacja, rozważyć wprowadzenie podziału na wczesnym etapie, czy to jako wymóg, czy jako dobrą praktykę. Kiedy do zespołu trafi mniejszy element, mniejszy etap projektu, mniejszy fragment celu lub realizacja jednego z kluczowych aspektów inicjatywy, wtedy podział na poziomie zespołu stanie się znacznie łatwiejszy. Dlatego mentalność „niech ktoś podzieli” często wynika z tego, że zespół dostaje elementy zbyt duże i przytłaczające, a rozwiązaniem jest podział na wcześniejszym etapie, ponad poziomem zespołu, na poziomie strategicznym lub co najmniej taktycznym.
2. Zasada: „Widzisz linię podziału, zgłaszasz propozycję podziału”
Oznacza to, że gdy przychodzi Ci do głowy sposób podziału, po prostu go komunikujesz. Skąd wynika ta propozycja? Często podczas superwizji obserwujemy, jak pracuje zespół. Pada pytanie i nikt nie odpowiada. Można wtedy odnieść wrażenie, że zespół nie ma żadnych pomysłów. Jednak gdy porozmawia się spokojnie z pojedynczymi osobami,albo gdy zastosuje się strukturę, która lepiej aktywizuje uczestników, okazuje się, że zespół ma wiele pomysłów, ale z różnych powodów nie dzieli się nimi publicznie. Proponowana zasada ma budować śmiałość w zespole. Dzięki niej zespół uprości sobie pracę – jeśli ktoś zauważy dobry sposób podziału, po prostu od razu go zgłosi. Choć brzmi to banalnie, doświadczenie pokazuje, że pojedynczy sygnał lub komentarz potrafi uruchomić wartościową zmianę w zespole. Zdecydowanie rekomendujemy umówienie się na takie proaktywne działanie.
3. Kształtowanie przez management konieczności dzielenia
Dzielenie powinno być wyraźnym oczekiwaniem wobec zespołu. Jeśli zespół stosuje ustaloną zasadę dzielenia, powinien być za to doceniany. Jeśli zespół jej nie stosuje, tłumaczy się stagnacją, brakiem postępów albo tym, że ryzyka projektowe się zmaterializowały, ponieważ nie podzielono pracy to powinno prowadzić do poważnej rozmowy o tym, że pojawia się realny problem, ponieważ management, niezależnie od roli, powinien wymagać, aby dzielenie pracy rzeczywiście następowało. Dlatego warto jasno określić dzielenie jako oczekiwanie, udzielać feedbacku, gdy zespół dzieli pracę, i udzielać feedbacku również wtedy, gdy tego nie robi. Warto także wspierać pomysły na podział, zwłaszcza te bardziej odważne, które dotykają aspektów biznesowych wyższego poziomu lub wymagają głębszego zrozumienia celu. Wszystkie te działania warto konsekwentnie wzmacniać. Trzeba też unikać sytuacji, w których zespół czuje, że ma zablokowaną możliwość dzielenia pracy. Chodzi o wytyczne lub komunikaty, które sugerują, że wszystko musi zostać wdrożone jako całość, lub inne blokery i komunikaty, które sprawiały, że zespół obecnie nie wierzy w efekty pracy przyrostowej i przestaje widzieć sens w dzieleniu pracy. 
Dzielenie pracy na mniejsze części to zawsze dobry pomysł. Nie spotkaliśmy zespołu, który byłby zawiedziony efektami dobrze przeprowadzonego podziału pracy. Dzielenie to supertaktyka. Można je porównać do „superfood” w świecie praktyk zespołowych. Przynosi korzyści na wielu poziomach i stanowi jeden z fundamentów efektywności zespołów. Warto budować kulturę pracy, która wspiera dzielenie pracy na mniejsze części oraz aktywnie mierzyć się z wyzwaniami związanymi z tą praktyką.
FAQ: Wyzwania w dzieleniu projektów na mniejsze części
Czy podzielenie projektu na mniejsze części jest opłacalne?
Jeśli będziesz dzielić projekt na mniejsze części, to możesz dostarczać wartość szybciej i z mniejszym ryzykiem. Zyskasz też większą przewidywalność i o wiele mniej stresu w zespole
W czym pomoże dobre zrozumienie celu projektu?
Gdy wszyscy rozumieją cel, łatwiej znaleźć sprytne skróty i priorytety. W efekcie mniej czasu tracisz na poprawki i gaszenie pożarów.
Jakie techniki mogą pomóc w zrozumieniu celu projektu?
Do zrozumienia celu projektu rekomendujemy wykorzystanie jednej z tych technik:
Impact Mapping
Golden Circle
Product Vision Board
OKR
Opportunity Solution Tree
Jakie konkretne korzyści zyskasz, pokazując dekompozycję już na początku?
Obniżanie ryzyk biznesowych, technologicznych i społecznych, najważniejsza wartość dostarczona  wcześniej to główne korzyści podzielenia projektu już na początku.
Jak zdobyć odwagę interesariuszy do podziału projektu?
Zacznij od zrozumienia ich obaw. Pokaż im, że chronisz to, co dla nich kluczowe i często unikalne. Dzięki temu zmniejszysz strach przed utratą zakresu, skrócisz czas do pierwszych efektów i zbudujesz zgodę na mniejsze kroki.
Jakie narzędzia pomogą wyważyć perspektywy biznesu i IT i są zrozumiałe dla obu stron?
Dla Biznesu i IT zastosuj techniki wizualne. Rekomendujemy Story Mapping, obiecująco wygląda też zastosowanie Event Stormingu.
Co można przygotować, aby kolejne procesy dzielenia były mniej czasochłonne?
Kolejne procesy dzielenia będą mniej czasochłonne, jeśli użyjesz reużywalnych narzędzi takich jak: checklisty, szablony i znane zespołowi schematy.
Co zyskasz, gdy przestaniesz traktować dzielenie jako koszt?
Traktuj dzielenie jako inwestycję. Szybciej osiągniesz dobre zrozumienie zakresu i odzyskasz poczucie kontroli nad postępem. Zespół wtedy działa na prostszych krokach, zatem mniej się blokuje i dostarcza wartość szybciej, z mniejszym ryzykiem i stresem.
Na czym polega problem mentalności „Niech ktoś podzieli”?
Postawa „Niech ktoś podzieli” polega na tym, że w zespole lub organizacji nie bardzo wiadomo, kto dokładnie powinien się zabrać za dzielenie. Często też wynika z tego, zespół jest konfrontowany ze zbyt dużym projektem, co sprawia, że podział jest trudny.
Co powinien robić management, aby wspierać kulturę dzielenia pracy?
Wspieranie kultury dzielenia pracy przez management to: stawianie jasnych oczekiwania, dawanie feedbacku, wspieranie pomysłów na podział i nie blokowanie swoimi decyzjami możliwości pracy przyrostowej.
Jak nabrać wprawy w dzieleniu projektu?
Zbuduj doświadczenie w dzieleniu i wtedy staje się ono czymś naturalnym, płynnym i sprawnym. Stanie się naturalną częścią pracy zespołów, nad którą nie trzeba będzie się zastanawiać.
Dodatkowe materiały
Dlaczego warto dzielić pracę na małe części?
Sztuka dzielenia user stories – skuteczne metody i wzorce
Kiedy i jak aktualizować dokumentację – koszt, partia i zwinne podejście
Jak dzielić user stories, by szybciej dostarczać wartość
Transkrypcja podcastu „Wyzwania w dzieleniu projektów na mniejsze części„
Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu Porządny Agile.
Kuba: Niedawno zakończyłem serię warsztatów na temat praktyk dzielenia większych inicjatyw produktowych i projektowych na mniejsze części. Grupa mierzyła się m.in. z tematem wyzwań, jakie występują przy okazji procesu dzielenia. Wypracowaliśmy w poszczególnych grupach bardzo wartościową treść, zarówno jeśli chodzi o samą definicję tych wyzwań, jak i możliwe rozwiązania, więc tutaj postanowiliśmy, że wycinek tej treści, a konkretnie te konkretne wyzwania, które grupy wygenerowały, będą stanowiły wsad do tego nagrania. A przy okazji serdecznie pozdrawiam wszystkie pięć grup. Wiecie dobrze, że przepracowaliśmy o wiele więcej wątków, ale w odcinku może zmieścić się tylko część z tego, co omawialiśmy.
Jacek: Spis treści na dzisiaj to wyzwania, jakie poruszymy. A są to problem z dobrym zrozumieniem celu projektu, presja biznesu na wdrożenie całości, wyważenie perspektywy technologii i biznesu przy podziale, czasochłonność procesu dzielenia i mentalność – niech ktoś to podzieli.
Kuba: Schemat odcinka będzie dosyć prosty. Wejdziemy w definicję tego, co konkretnie oznacza daną wyzwanie. Te hasła nie zawsze są zrozumiane na pierwszy rzut oka. No i potem wygenerujemy po trzy rozwiązania, jakie przychodzą nam do głowy jako takie najczęściej się sprawdzające w praktyce rzeczy, które są w naszym doświadczeniu możliwym rozwiązaniem albo chociaż minimalizacją danego wyzwania.
Jacek: Pierwsze wyzwanie to problem z dobrym zrozumieniem celu projektu. Jest to naszym zdaniem popularny bloker, który powoduje, że bardzo trudno jest zasiąść do mądrego podzielenia projektu czy inicjatywy, jeżeli tak naprawdę nie rozumiemy, co chcemy uzyskać. Oczywiście bez zrozumienia celu możemy tak bardzo mechanicznie spróbować podzielić pewien projekt na mniejsze części, ale prawdziwa magia dzieje się wtedy, kiedy bardzo dobrze rozumiemy cel, ponieważ wtedy otwierają nam się furtki do tego, jak pewne rzeczy możemy zrealizować w o wiele mądrzejszy sposób, niż tak patrząc na projekt bez zrozumienia, co tak naprawdę chcielibyśmy tym projektem uzyskać.
Kuba: I jest tak, że to zrozumienie jest tutaj fundamentalnym wstępem do dobrego podziału, więc pierwsza porada może być dosyć oczywista. Zapewnij, że cel jest zrozumiały. Tutaj mamy na myśli kilka możliwych realizacji tego zapewnienia. Jedną z rzeczy na pewno jest dobry kick-off, czyli jakiś rodzaj spotkania otwierającego daną inicjatywę, dany projekt, daną zmianę produktową czy dany etap rozwoju danego produktu. Nie przechodź do założenia, że ludzie wiedzą, bo ty wiesz, tylko zapewnij jakiś wstęp, jakieś exposé, jakieś dobre wtajemniczenie ludzi w dotychczas zebrane badania, w taki kontekst biznesowy, dlaczego pewną rzecz realizujemy. I te przygotowania się do tego kick-offu nie pójdą na marne, bo też zapewnienie zrozumienia celu może być poprzez powtarzanie tych informacji. Czyli też zbuduj sobie praktykę wracania do celu przy każdej nadarzającej się okazji. To mogą być jakieś Przeglądy Sprintów, jeśli stosujesz Scruma, to mogą być jakieś demo, spotkania projektowe, jakieś warsztaty, jakieś podsumowania. Wszystkie te miejsca, gdzie zebrany jest zespół lub jego wyraźna część, to mogą być okazje do tego, żeby wrócić do tej mantry, co jest celem, co jest istotą tego, co jest realizowane w danym momencie. No i tutaj trochę założenie, że wielokrotne powtórzenie, być może powtórzenie na pewne różne sposoby, przekazanie tej informacji sprawi, że ten cel będzie rozumiany, da okazję do tego, żeby się tak mocniej w zespole osadzić. No i tym samym, gdy przyjdzie moment na aktywność związaną z dzieleniem, czy na początku jakiegoś kroku, czy w trakcie już dalszych prac, to ten cel będzie pamiętany, łatwy do przypomnienia, czy po prostu tak już na tyle zrozumiały, że w zasadzie wszyscy to traktują jako oczywistość.
Jacek: Druga porada jest pewnego rodzaju pogłębieniem tego, co powiedział Kuba, czyli rekomendujemy użycie sprawdzonych technik, które wspierają pracę na celach, lepsze zrozumienie tego, czym ten cel właściwie jest. I mamy tutaj na myśli szereg różnych technik, podejść. Chcielibyśmy je teraz troszeczkę wymienić, tak żeby rozsypać takie ziarenka możliwości. Na pewno sensowną techniką do rozważania jest impact mapping, podejście golden circle, koncepcja product vision board, OKR-y czy opportunity solution tree. Jeżeli te nazwy niewiele ci mówią na ten moment, żadna strata po prostu wyszuka je w internecie, jeśli jeszcze ich nie znasz. Mamy z Kubą doświadczenie w większości tych narzędzi no i faktycznie możemy potwierdzić, że nie dość, że są fajnym narzędziem, które wspomaga zrozumienie, po co pewne rzeczy robimy, to zwykle są to też narzędzia, które są wizualne. Tak więc praca z nimi to nie jest tylko rozmowa, jest też ta część taka widoczna, która bardzo mocno poprawia i zwiększa zrozumienie tego, co on tak naprawdę jest esencją danej zmiany.
Kuba: I tu konkretnie, jeśli by zespół zawierał się do jakiejś sesji dzielenia, to jeśli do tej pory nie zostało to zrobione, to rekomendujemy wykorzystanie jako swego rodzaju rozgrzewki czy wstępu właśnie któregoś z tych narzędzi lub powrotu do tych narzędzi, jeśli one zostały już przepracowane na wcześniejszych etapach. 
Kuba: I trzecia praktyka, którą rekomendujemy to stosowanie tak często, jak tylko się da sprawdzenia zrozumienia celu. To nie tylko osoba zarządzająca projektem, lider produktu czy manager zespołu, może być osobą, która komunikuje, jaki jest cel, ale możemy też poprosić o to, aby to uczestnicy w jakiejś formie ćwiczeniowej albo po prostu na zasadzie takiej szybkiej śmierci po prostu powiedzieli, przypomnieli, czy swoimi słowami opowiedzieli, jaki jest cel danej inicjatywy. To może być okazja do tego, żeby w ogóle sprawdzić, czy to jest zrozumiałe, to może być też narzędzia aktywizujące czy rozgrzewające uczestników, ale też jest fajna okazja do tego, żeby skorzystać z różnorodności zespołu, różnych perspektyw, różnych osób, z różnych profesji, które na sprawy patrzą trochę inaczej. Również warsztatowo na wspomnianym szkoleniu przeze mnie było to bardzo doceniane. Mieliśmy miks osób o bardzo różnych specjalizacjach na warsztacie i też właśnie ten aspekt wychodził. Pewne osoby patrzą na sprawy bardziej systemowo, inne bardziej biznesowo. No i ta parafraza celu albo próba zrozumienia celu też może być atakowana na różne sposoby i w efekcie to zrozumienie jest lepsze. Więc dąż do tego, żeby sprawdzać zrozumienie na przykład poprzez parafrazę przez osoby zaangażowane w zespół.
Kuba: Przejdźmy zatem do drugiego wyzwania. Jest to presja biznesu na wdrożenie całości. Co mamy na myśli? Całości projektu, całości zakresu, całości inicjatywy, czasami może całość jakiejś zdefiniowanej funkcji w produkcie. To zjawisko może powodować, że jest pewna niechęć czy pewne poczucie bezsensu dzielenia. No bo po co dzielić, jeśli i tak musimy na końcu wdrożyć wielką całość tak, jak została ona zdefiniowana, a czasami z tą presją biznesu może się wręcz wiązać czy z presją może managementu, może się nawet wiązać takie poczucie, że podzielenie to proszenie się o kłopoty, bo być może ta strona, która wywiera tę presję, może wręcz zaraz zacząć dostrzegać się, że my chcemy spróbować się wyślizgnąć z jakiegoś kawałku zakresu. Więc szereg pewnych takich negatywnych emocji, które mogą powodować, że tego dzielenia nie chce zespół zrealizować.
Jacek: I pierwsza nasza rekomendacja odnośnie do tego wyzwania jest taka, żeby pokazać korzyści, które wynikają z tej dekompozycji na wczesnym etapie. Warto założyć, że nie wszyscy wiedzą, nie wszyscy doświadczyli tego, jakie to są korzyści. A myślimy tutaj przede wszystkim o wczesnym obniżaniu ryzyk, zarówno biznesowym. Czyli mamy okazję wcześniej przekonać się, że to, co wymyśliliśmy, faktycznie trafia w potrzebę rynkową, jest właściwie rozwiązane. Ryzyk technologicznych, czyli czy potrafimy posługiwać się konkretną technologią, której chcemy użyć, czy ryzyk społecznych, czyli czy ta grupa osób, która odpowiada na implementację tego rozwiązania, czy potrafią ze sobą efektywnie współpracować. Więc ryzyka to jest jakby jedna strona tej monety, a z drugiej strony jest taka koncepcja, że chcielibyśmy tę najważniejszą wartość, tę esencję tak naprawdę, konkretne zmiany projektu czy inicjatywy, chcielibyśmy dostarczyć jak najwcześniej. Jeżeli ten temat jest dla Ciebie interesujący, to zdecydowanie polecamy nasz wcześniejszy odcinek, odcinek, który nazwaliśmy „Dlaczego warto dzielić praca na małe części?”, ponieważ zawarliśmy tam całą masę pomysłów, koncepcji i wskazówek, dlaczego warto dzielić. Odsyłamy do odcinka numer 76 dostępnego pod adresem porzadnyagile.pl/76.
Kuba: Drugi z możliwych rozwiązań na presję biznesu na wdrożenie całości jest zrozumienie obaw interesariuszy, które blokują ich na tenże podział. Tutaj proponuję uruchomić empatię, proponuję zrozumieć i wczuć się w perspektywę tych Interesariuszy. Coś, co widać z zewnątrz z perspektywy też może konkretnego zespołu wykonawczego jako jakiegoś rodzaju niezrozumiała albo wręcz nieracjonalna presja, może tak naprawdę być czymś unikalnym dla tej osoby, dla tego konkretnego managera czy tej konkretnej grupy ludzi z jakiejś części organizacji. To może być coś, czego ty nie doceniasz, a jednak trzeba zagospodarować. Co mam tu na myśli? Bardzo konkretny przykład z konkretnej firmy, w której uczestniczyłem. Na przykład zespół odpowiedzialny za operację, czyli jakieś takie działania związane z usługami, na przykład po sprzedaży i obsługą klienta. Bardzo bał się, że ich narzędzia zostaną uznane za nieistotne, albo w ogóle nie zostaną zrealizowane w całym projekcie, dlatego oni byli bardzo sceptyczni i bardzo tacy twardzi w negocjacjach, bardzo niechętni do jakiegokolwiek dzielenia tego, co oni zgłosili, jakichś puli, ich wymagań, ich potrzeb narzędziowych. No bo ich życiowe doświadczenie z przeszłości jakichś poprzednich projektów pokazywało, że często kończyło się tym, że pod presją czasu w ogóle żadne narzędzia dla nich nie były wykonywane i muszą obsługiwać klienta Excelami i mailami pisanymi z ręki, bo system nie zagospodarował tego, choć pierwotnie było to planowane. Więc tutaj warto wziąć na to poprawkę, warto wczuć się w tę perspektywę i też zrozumieć ewentualne obawy.
Jacek: Innym przykładem obawy może być sytuacja, w której ktoś komuś obiecał bardzo precyzyjny i zwykle bardzo rozbudowany zakres. Często jest tak, że osoby te nie mówią tego wprost albo po prostu może trochę im jest trudno też przyznać, że gdzieś tam komuś coś takiego obiecały no i będą opornie podchodzić do tematu, żeby ten duży kawałek, tą całość podzielić. Z takiej obawy, że to dzielenie będzie jednak być może pretekstem do tego, żeby z tego zakresu wyleciało.
Kuba: Taki przykład specyficzny już dla pewnej grupy firm to to, że jest też w niektórych organizacjach taki pęd ku robieniu dużych, spektakularnych rzeczy. I tutaj w tym kontekście idea dzielenia trochę stoi z tym w poprzek. No bo trzeba robić wielkie projekty strategiczne, robić wielkie wow, mieć wielkie premiery, mieć wielkie nagrody za jakieś tam przełomowe niesamowite odkrycia czy innowacje w danej branży. W tym sensie warto tę perspektywę też złapać, że może być tak, że osoba właśnie szykuje się na przyszłą konferencję innowacji w bankowości i tam naprawdę ma wielką ochotę wyskoczyć na scenę i poopowiadać, jak to wielkie, wspaniałe, nowe implementacje, pewnie w tym roku AI w apce, ma w planach. Oczywiście to nie oznacza, że spektakularne rzeczy muszą być niepodzielone, ale warto może mieć tutaj świadomość tej sytuacji i ewentualnie dbać o tę komunikację, bo jedno nie stoi w przyszłości z drugim. W najgorszym razie faktycznie wdrożenie może mieć miejsce jako wielki wow, co nie znaczy, że nie warto podzielić na wcześniejszych etapach i też dostarczać kawałkami, być może kawałkami, które nie będą jeszcze publikowane.
Jacek: I to, co Kuba powiedział, to właściwie przesuwa nas do trzeciej porady, czyli przepracowania z biznesem różnic pomiędzy podziałem na części, a obietnicą realizacji całości. W największym skrócie chodzi o to, że to, że podzielimy na mniejsze kawałki pracę, nie musi automatycznie oznaczać, że nie wdrożymy potrzebnej całości. Przy czym jednak tutaj oczywiście dostrzegamy pewną kontrowersję, no bo może być tak, że masz doświadczenie z aktualnej firmy czy z wcześniejszych firm, że jednak ze względu zwykle na jakieś ograniczenia czasowe taki podział powoduje, że do konkretnej daty jednak wdrażana jest jakaś tam część. Bywa, że ona jest satysfakcjonująca i nie są realizowane te rzeczy, których nie zdążyliśmy zrobić w dalszej kolejności, tylko realizowane są jakieś kolejne inne koncepcje. Więc co do zasady nie musi tak być, ale rozumiemy, że doświadczenie i historię wcześniejszych projektów mogą podpowiadać, że z tą poradą trzeba byłoby czy do tej porady podchodzić w ostrożny sposób.
Kuba: W szczegółach jest też druga kontrowersja, to koncepcja potrzebnej całości. Może się okazać, że tutaj ktoś się bardzo kurczowo trzyma tego czegoś, co jest wyobrażeniem całości zakresu czy całości rozwiązania, co powstało na bardzo wczesnym etapie. No i czasami niektórzy zbyt kurczowo się trzymają tej wizji raczej zakładając, że od początku mieli rację co do tego, co jest potrzebne, od początku wiedzieli, że dokładnie ten cały zakres jest tym, czego potrzebuje rynek czy potrzebuje klient. Więc tutaj wracamy też do ryzyk biznesowych. Zbyt dużo decyzji podjętych na zbyt wczesnym etapie może być, tak naprawdę złudzeniem co jest potrzebne. Więc rada z podwójną kontrowersją jak to pokazaliśmy, ale mimo wszystko na etapie takim bardzo wczesnym, być może bardziej dyplomatyczne jest powiedzenie, „Podzielimy na kawałki i wdrożymy to, co jest potrzebną całością”, gdzie ja w swojej głowie mówię, potrzebna całość to nie będzie cały zakres, tak jak go czujemy dzisiaj, bo jeszcze czas pokaże, co to dokładnie będzie to coś, co wdrożymy.
Jacek: Trzecie wyzwanie to wyważenie perspektywy technologii i biznesu przy podziale. Mamy tutaj na myśli sytuację po dwóch stronach osi. Z jednej strony, kiedy podział dzieje się wyłącznie w izolacji biznesowej i osoby technologiczne do tego podziału nie są zapraszane, co oczywiście powoduje, że tracimy bardzo istotny aspekt wykonalności, jak również dostępnych opcji, które płyną nie z głów biznesowych, a od osób technologicznych. Z drugiej strony próba podziału wyłącznie technologicznego, co może się udać z perspektywy podziału tego na mniejsze kawałki, ale dobrze nie rozumiejąc aspektów biznesowych albo nie mając możliwości dopytania – przykładowo, jaki to będzie miało impakt biznesowy – również spowoduje, że taki podział będzie jakiś, ale na pewno nie będzie to podział optymalny.
Kuba: Rozwiązanie pierwsze jest dosyć oczywiste. Zaproś przemyślany skład, będący reprezentacją potrzebnych stron. I to idzie trochę dalej niż tylko te dwie skrajne kawałki osi, które wymienił Jacek, bo to może być też perspektywa na przykład prawna, to może być perspektywa user experience, więc tutaj uczestników tego typu warsztatów czy aktywności związanych z podziałem powinno być prawdopodobnie sporo w zależności od kontekstu i specyfiki twojego produktu. Natomiast w tej Radzie „Zaproś” jest też koncept tego, że w ogóle rozmawiamy po co, kto, z czym ma przyjść i jaką perspektywę reprezentować. Mnie serce boli, jak często słyszę ze strony biznesowej, że zaprosili na przykład przedstawicieli IT, jakiś architektów, jakiś senior developerów, po czym się okazało, że te osoby były bardzo ciche na spotkaniu, nie za bardzo zabierały głos, nie za bardzo dokładały od siebie – nawet zapytane. Moim zdaniem tu może być taki błąd pierwotny w tym, że ktoś zaprosił te osoby, przyszły, bo warto, bo trzeba, bo tak wypada, bo taki jest zwyczaj, natomiast tak naprawdę te osoby mogłyby nie wiedzieć, po co na danym spotkaniu są. Więc tutaj pojawia się bardzo ważna rola osoby zapraszającej, ktokolwiek to jest w danym kontekście, która również wyjaśnia wszystkim obecnym czy wszystkim planowanym do wzięcia udziału w tych czynnościach, żeby jednak bardzo jasno wyrazić, na co liczę, na czego oczekuję od Ciebie, jako uczestnika tego typu warsztatów. Żeby też nikt się nie bał, nie krygował, nie hamował, zwłaszcza, że prawdopodobnie w ramach takiego dzielenia się będzie trochę tarć. Ktoś zaproponuje podział biznesowy, który nie do końca jest dobry technologicznie, któryś podział biznesowo-technologicznie fajnie się zapowiadający będzie trochę bezsensowny z perspektywy prawnika, czy z perspektywy osoby odpowiedzialnej za bezpieczeństwo. Więc tutaj się rzeczy będą tarcia, więc każdy musi rozumieć też, po co jest na tym warsztacie, czy na tym spotkaniu, czy uczestniczy w tych aktywnościach.
Jacek: Druga wskazówka ustal facylitatora i oczekuj od tej osoby, że zadba o każdą perspektywę. Mówiąc prostszym językiem, zadba, żeby była osoba, która zadba o to, żeby przebieg tego warsztatu był maksymalnie efektywny, żeby równomiernie wybrzmiały dostępne na spotkaniu perspektywy, nawiązując do tego, co powiedział Kuba, jak również, żeby zbalansować też głębokość tych rozmów. Czyli przykładowo, żeby nie zabrnąć w jakieś super niskopoziomowe detale na przykład technologiczne, bo to może powodować, że wszystkie te inne osoby, które nie są tak techniczne, może się o nich rodzić poczucie, że to spotkanie tak nie do końca jest dobrze poprowadzone. Kto może prowadzić takie spotkanie? To może być ogarnięty analityk, to może być lead developer, to może być architekt. Tak naprawdę nie ma to znaczenia, jak nazywa się ta konkretna rola. Ważne jest natomiast, żeby ta osoba była po pierwsze dobrze przygotowana do poprowadzenia takich warsztatów, czasem serii warsztatów, bo to może być więcej niż jednorazowa akcja, i żeby starała się ta osoba trzymać perspektywę wszystkich stron będących na tym spotkaniu równomiernie, a nie była tylko reprezentantem tej jednej. Bo tak jak wspomniałem przed chwilą może to spowodować, że nie do końca będzie to dobra reklama na przyszłość dla tego typu inicjatyw w organizacji.
Kuba: I trzecia porada, jak sobie poradzić z wyważeniem perspektywy technologii i biznesu, to zastosować techniki wizualne, które są zrozumiałe zarówno dla biznesu, jak i IT. Mamy tu konkretnie przede wszystkim na myśli Story mapping, który lubimy, robimy, często rekomendujemy i sami też regularnie wręcz stosujemy do swojej własnej pracy biznesowej czy pracy związanej z podcastem. Podobnie jak z poprzednimi wymienionymi technikami, nie będziemy tutaj w odcinku ich opisywać. Zakładam, że Story Mapping jest już na tyle powszechną techniką, że akurat on powinien być wśród odbiorców znany naszego podcastu, ale jeśli nadal go nie znasz, to mocno rekomendujemy sprawdź to, może dołącz do jakiegoś warsztatu, gdzie jest to realizowane, bo technika jest supermocna, jeśli chodzi o wizualizację, jeśli chodzi o pokazanie zakresu, pokazanie opcji, ale też między innymi w kontekście tego, o czym tu mówimy, takie pokazanie sobie, czym jest w ogóle to przedsięwzięcie, które realizujemy, jaką ono się dzieli na mniejsze kawałeczki i te kawałeczki najczęściej są realizowane z perspektywy użytkownika, więc zrozumiałe są zarówno dla biznesu, jak i dla strony tych osób, które będą później to implementować. Obiecująco wygląda też zastosowanie Event stormingu. Ja sam osobiście nie prowadzę tych sesji, ale kilkukrotnie uczestniczyłem jako obserwator czy jako uczestnik. Mam tu mniejsze doświadczenia, ale jeśli ktoś umie to poprowadzić, to uważam, że może dać bardzo podobny rezultat co Story mapping, choć rządzi się trochę innymi prawami.
Jacek: Zanim pójdziemy dalej, krótka informacja, mamy dostępny z Kuba webinar dotyczący kwestii tego, jak dzielić pracę na mniejsze kawałki. Ten webinar nauczy Cię formułować celne argumenty za tym, że w ogóle warto dzielić, nauczy Cię też używać w praktyce wyselekcjonowanych przez nas konkretnych metod dzielenia. W webinarze pokazujemy wszystko na bazie łatwych, do zrozumienia przykładów, jak dzielić oraz podpowiadamy sporo wskazówek z naszej praktyki, jak lepiej dzielić elementy, angażując w to wydarzenie całe zespół. Więcej informacji oraz możliwości zakupu webinaru znajdziesz na stronie porzadnyagile.pl/deco.
Kuba: Czwartym wyzwaniem jest czasochłonność procesu dzielenia. Często, gdy przekonuję jakiś zespół do tego, że warto dzielić, słyszę jako jeden z argumentów przeciwko dzieleniu, jest to, że to jest praca do wykonania, ktoś to musi zrobić, ktoś to musi wpisać, tu będzie dużo elementów, które później trzeba zarządzić, skoordynować. I przyjmuję do wiadomości, że to jest pewna praca, to jest pewien wysiłek, ale dla wielu zespołów czy w wielu organizacjach jest to po prostu pewnego rodzaju wyzwanie, jak się za to zabrać. Co tutaj rekomendujemy?
Jacek: Przede wszystkim warto zadbać o zmianę myślenia, że dzielenie to nie jest koszt i tak nie nazywać tego procesu, tylko raczej myśleć o tym, że to jest inwestycja w proces dostarczania, która pomoże zespołowi uchwycić po pierwsze dobre zrozumienie zakresu, da też o wiele lepszą kontrolę nad postępem prac, przez to, że będziemy pracować na trochę mniejszych klockach i też zmniejszy złożoność danego kroku większej inicjatywy, które mamy do wykonania. Za tym wszystkim płynie cały szereg technicznych aspektów, a mianowicie sam przepływ pracy wewnątrz zespołu powinien tak naprawdę przy pracowaniu na mniejszych kawałkach przyspieszyć, przez to, że szybciej coś zostanie zaimplementowane, szybciej będziemy w stanie to przetestować, szybciej będziemy w stanie zrobić code review, czy ostatecznie szybciej pewne rzeczy zmergować, czy wypuścić na środowisko produkcyjne. Jest więc cała masa bardzo pozytywnych rzeczy, które dostaniemy, tylko jeśli zainwestujemy czas w to, żeby tę pracę, która na nas czeka, po prostu, żeby ją podzielić na mniejsze fragmenty.
Kuba: Druga rada to wykorzystaj reużywalność narzędzi i instrukcji. Faktycznie może być tak, że ten koszt czy inwestycja, jak to Jacek przed chwilą bardzo wyraźnie wskazał czy skorygował, może po prostu zajmować pewien konkretny czas i częścią tego czasu może być przygotowywanie się lub niepotrzebne wgryzanie się w techniki czy w narzędzia związane z dekompozycją czy właśnie dzieleniem elementów. Tutaj mocno rekomenduję, zwłaszcza osobom, które pełnią jakieś funkcje liderskie w zespole, czy odpowiadają za proces pracy, by jak najmocniej wykorzystywać okazję do szykowania czy reużywania checklist, na przykład metody dzielenia. To jest bardzo prosta checklista, jakimi metodami możemy podzielić dany projekt czy dany element, który podlega właśnie warsztatowaniu. To mogą być przygotowane szablony, wymieniliśmy konkretne już techniki, te techniki można mieć już przygotowane, jakieś boardy na jakimś miro czy jakieś przygotowane gotowe kawałki do przepisania na flipchart czy do przepisania na jakieś kartki. Ale chodzi też o znane zespołowi schematy. Nie trzeba się silić za każdym razem, żeby zrozumieć o co chodzi tej osobie, która prowadzi daną sesję warsztatową, tylko zespół się dopracowuje z czasem gotowych ścieżek, tych, które już można nawet prawie nie dawać żadnych instrukcji, tylko po prostu wejść na takim trochę automacie. Oczywiście nie sugeruję, te instrukcje zawsze jednak jakieś powinny być, ale one mogą być super związłe, niewymagające żadnych dodatkowych omówień i też wchodzące zespołowi, tak nazwij, gładko. Czyli zespół płynnie wchodzi w temat, nie ma żadnych dyskusji, ale o co ci chodzi, gdy każesz nam tu coś rozpisać albo co masz na myśli, gdy mówisz o dzieleniu po jakiś tam elementach, bo to wszystko zespół już zna, czuje. Więc też w jakimś sensie jest okazja do oszczędności czasowej, jeśli tylko do tego podchodzi się w taki bardzo świadomy sposób i dzięki temu, zwłaszcza kolejne dzielenia, gdy już bazujesz na checklistach albo schematach, są już mniej czasochłonne.
Jacek: To co powiedział Kuba jest wprowadzeniem do trzeciej porady, czyli nabierzmy wprawy w dzieleniu. Kiedy zbudujemy doświadczenie, kiedy będziemy mieć te wszystkie checklisty, te wszystkie rzeczy, które nam ułatwiają, wtedy dzielenie staje się czymś naturalnym, płynnym, oczywistym i jest po prostu przeprowadzane w sposób generalnie dosyć sprawny. Przestaje być tematem, na którym trzeba się zastanawiać, nic nas nie blokuje, nie ma tej obawy jak to zrobimy, tylko po prostu staje się tu naturalną częścią pracy zespołów, coś co jest absolutnie oczywiste i należy poświęcić na to trochę czasu. To nie jest tak, że to się po prostu wydarzy, ale pierwsze podzielenie, drugie, trzecie. Zwykle pojawiają się bardzo wartościowe efekty dzielenia, powodują, że w tej pamięci mięśniowej zespołu zostaje taka myśl, że to po prostu warto robić, więc z perspektywy czasu nie ma już myślenia, czy to zrobimy, tylko tak naprawdę, kiedy to zrobimy, bo po prostu wiemy, że to po prostu trzeba robić, że to ma sens. I też skojarzenie jest takie, że zrobiliśmy to tyle razy, że zrobimy to z równą łatwością, kiedy przyjdzie kolejna okazja czy konieczność, żeby wykazać się tymi umiejętnościami.
Kuba: I pokuszę się o taką szpileczkę, że wyzwanie z czasochłonnością dzielenia, szczególnie przecenia czy niepotrzebnie uwypukla ta grupa, która tego dzielenia nie robi. Czyli tutaj jest pewnego rodzaju obietnica osoby, które realizują dzielenie rutynowo, po prostu uważają to za nieodłączną część pracy, robią to dosyć płynnie i nie robią z tego niepotrzebnego szumu.
Jacek: Ostatnie wyzwanie, które chcemy pokryć w dzisiejszym odcinku, to mentalność, niech ktoś podzieli. Czyli jest to sytuacja, w której nie do końca wiadomo, kto powinien się zabrać za dzielenie. Może i czujemy, że dobrze by było podzielić, ale to na pewno nie powinniśmy robić my. To powinni zrobić oni, albo to powinien zrobić ktoś. Jeżeli więcej osób w organizacji pomyśli w ten sam sposób, odrzucając trochę tę rękawicę pod tytułem wezmę i zrobię, to może się okazać, że czas sobie będzie płynął, co jest nieuniknione i po prostu zaczniemy pracę z tym, co mamy, czyli będziemy pracować z projektem w takim stanie, jaki jest, bez podziału. Jakie mamy pomysły na to, żeby sobie z tą mentalnością poradzić?
Kuba: Pierwsza praktyka, chociaż nieatakująca problemu wprost, to podział na poziomie całego portfela. Mówię, że nie atakuję to wprost, bo to nie rozwali tej mentalności, że ktoś inny powinien podzielić, a w pewnym sensie nawet wręcz właśnie rekomenduję, żeby faktycznie ktoś inny podzielił, ale mam tu na myśli to, że jednym z problemów tego takiego przytłoczenia albo potrzeby, żeby ktoś podzielił, jest właśnie ta perspektywa, że często do zespołów wykonawczych, czy takich zespołów produktowych, projektowych trafia coś, co jest bardzo dużych rozmiarów i to tak z góry zdeterminowane, czy z góry zdefiniowane w taki sposób, że ten podział nie jest prosty. Więc tutaj mocno rekomenduję, by to na poziomie portfela, czy produktu, czy Road mapy, czy całego portfela projektów, jeśli tak to funkcjonuje w twojej organizacji, zastanowić się, czy by tego podziału jednak w jakimś sensie, albo nie wymusić, albo chociaż propagować jako dobrą praktykę. Bo wtedy, jeśli do zespołu trafi coś, co jest mniejszą cząstką, jakimś mniejszym etapem projektu, mniejszym wycinkiem celu, albo realizacją tylko jednego z najważniejszego celu spośród kilku, które dana inicjatywa pierwotnie miała realizować, to ten podział w tym zespole już konkretnym będzie trochę prostszy. Więc ta mentalność niech ktoś podzieli, moim zdaniem może m.in. częściowo bazować na tym, że zespół jest konfrontowany z trochę za dużymi elementami i rozwiązaniem na to jest podział na wczesnym etapie, jeszcze tak trochę ponad zespołem, czy na tym etapie takim strategicznym, albo chociaż taktycznym.
Jacek: Druga porada to zasada, którą chcemy zaproponować, że warto się na nią umówić w zespole, która brzmi, jak widzisz linię podziału, to zgłaszasz propozycję podziału. Czyli koncepcja, w której jeżeli przechodzi Ci do głowy, jak można coś byłoby podzielić, to po prostu mówisz to. Z czego wynika ta propozycja? Wielokrotnie spotykam się z sytuacją, że obserwuję np. podczas procesu superwizji, jak pracuje konkretny zespół. Ktoś zadaje pytanie, pada pytanie, nikt się nie odzywa. Można odnieść wrażenie, że w zespole nie ma odpowiedzi. Kiedy zagłębić się i porozmawiać na spokojnie z pojedynczymi osobami, albo kiedy zastosujemy inną strukturę, która w lepszy sposób aktywizuje osoby dostępne w zespole, okazuje się, że zespół ma całą masę różnych pomysłów, bo tylko z jakichś powodów się tymi pomysłami nie dzieli. Zasada, którą tutaj proponujemy, ma na celu zbudowanie śmiałości w ludziach. Na zasadzie uprościmy sobie życie, jeśli ktoś zobaczy fajny, sensowny sposób podziału, to się w danym momencie odezwie. Brzmi to banalnie, ale wiem z doświadczenia, że czasem pojedynczy sygnał, impuls, komentarz potrafi uruchomić bardzo fajną zmianę w zespole. Zdecydowanie do umówienia się na takie proaktywne działanie rekomendujemy.
Kuba: Trzecia, ostatnia porada w tym wyzwaniu to kształtowanie przez management konieczności dzielenia. To dzielenie musi być oczekiwane, czyli członkowie zespołu. Jeśli wprowadzili tę zasadę Jacka, to powinni być za nią doceniani. Jeśli jej nie wprowadzają albo zasłaniają się, że idzie, jak idzie, albo postępów nie ma, albo ryzyka projektowe się ziściły, bo nie podzieliliśmy, to powinien być wstęp do bardzo poważnej rozmowy o tym, że to jest problem, bo jako management organizacji, czy jako Product manager, czy Project manager, czy jakiś manager strukturalny, hierarchiczny, wszyscy wymagają tego, żeby to dzielenie miało miejsce. Warto postawić dzielenie jako oczekiwanie, dawać feedback, jeśli to dzielenie następuje, dawać feedback, jeśli nie następuje. Też wspierać pomysły na podział, zwłaszcza takie bardziej odważne, wiążące się też z zahaczeniem o aspekty wyższego poziomu biznesowe, czy związane ze zrozumieniem celu. Wszystko to warto propagować. I przez odwrotność też powiem, nie doprowadzać do sytuacji, w której zespół ma poczucie, że ma zablokowaną możliwość dzielenia. Mam na myśli takie jakieś wytyczne czy jakieś stawianie pewnych spraw, że na przykład wszystko musi być wdrożone jako całość, co było przedmiotem innego wyzwania, czy jakieś inne rodzaje blokerów albo komunikatów, które powodują, że zespół nie wierzy w efekty pracy przyrostowej i nie widzi w związku z tym sensu dzielenia.
Jacek: Na koniec kilka myśli, którymi chcemy się podzielić zamiast takiego klasycznego podsumowania. Dzielenie pracy na mniejsze kawałki to zawsze dobry pomysł. Jeszcze nie spotkałem zespołu, który byłby zawiedziony efektami dobrze przeprowadzonego dzielenia.
Kuba: Dzielenie jest superpraktyką. Analogicznie do tego jak o żywności mówi się superfood. Daje masę korzyści na wielu poziomach i jest jednym z fundamentów efektywności zespołów.
Jacek: Warto kreować kulturę pracy wspierającą dzielenie pracy na mniejsze części i aktywnie mierzyć się z ewentualnymi wyzwaniami, z takimi aktywnościami.
Kuba: Jeśli mierzysz się w swojej organizacji z wyzwaniami związanymi z dzieleniem, tymi, które wymieniamy albo innymi, skorzystaj z naszej oferty wsparcia konsultacyjnego. W Twoim konkretnym kontekście pomożemy przemyśleć dany temat albo wskazać konkretne rozwiązania z naszego wieloletniego doświadczenia. Sprawdź całość oferty na 202procent.pl/konsultacje.
Jacek: Ja również polecam się odezwać do nas. Natomiast notatki do tego odcinka, artykuł, transkrypcja oraz zapis wideo znajdziesz na stronie porzadnyagile.pl/139.
Kuba: I to by było wszystko na dzisiaj. Dzięki, Jacek.
Jacek: Dzięki, Kuba. I do usłyszenia wkrótce.
____
To była pełna transkrypcja odcinka podcastu Porządny Agile. Dziękujemy za lekturę!
Ostatnia aktualizacja: 23 stycznia 2026The post Wyzwania w dzieleniu projektów na mniejsze części first appeared on Porządny Agile.