Zwinna organizacja pracy w projektach BIM cz. 2 – podstawy Scrum

Wpis ten stanowi kontynuację cyklu pt. „Zwinna organizacja pracy w projektach BIM”. W poprzedniej i zarazem pierwszej części cyklu opisuję zagadnienia związane z podejściem produktowym oraz wartością dodaną. Podejście produktowe stanowi przestrzeń, w której osadzone są zwinne ramy postępowania Scrum. We wpisie tym postanowiłem przybliżyć podstawy tego sposobu organizacji pracy i jego zastosowanie w procesie projektowo-budowlanym.

Wpis ten stanowi kontynuację cyklu pt. „Zwinna organizacja pracy w projektach BIM”. W poprzedniej i zarazem pierwszej części cyklu opisuję zagadnienia związane z podejściem produktowym oraz wartością dodaną. Podejście produktowe stanowi przestrzeń, w której osadzone są zwinne ramy postępowania Scrum. We wpisie tym postanowiłem przybliżyć podstawy tego sposobu organizacji pracy i jego zastosowanie w procesie projektowo-budowlanym.

Michał jest architektem i pracuje w dziale projektowym jednej z wiodących spółek deweloperskich na stołecznym rynku. Firma świadczy usługi zarówno w roli inwestora zastępczego, jak i generalnego wykonawcy realizującego duże inwestycje mieszkaniowe. Michał jest tradycjonalistą. Wierzy, że dobry plan i dogłębne przeanalizowanie ryzyka w fazie przygotowawczej umożliwi realizację projektu w założonym budżecie i czasie. Wszyscy z którymi współpracuje w firmie podążają zgodnie z tym dobrze sprawdzonym schematem. Michał przez wiele lat pracował na samodzielnym stanowisku. Od pewnego czasu jest team-liderem w niedużym zespole projektowym. Bardzo ucieszył się z tego powodu, ale dużym wyzwaniem pozostaje dla niego współpraca zespołowa. Uczestniczy w projekcie, w którym bardzo trudno było zdefiniować wymagania. Na dodatek ciągle są w nich wprowadzone zmiany. Powoduje to, że członkowie jego zespołu popełniają błędy. Michał czuje się sfrustrowany, ponieważ wszystko musi sprawdzać. Niezależnie od tego jak szczegółowo stara się planować nigdy nie udaje mu się osiągnąć oczekiwanego efektu.

Michał ma kolegę – Jacka, z którym znają się z podstawówki. Jacek pasjonuje się informatyką. Dostał się do liceum o profilu matematyczno-fizycznym, potem na studia na Uniwersytecie Warszawskim na wydziale informatyki. Jacek trafił niedawno do nowo utworzonego startupu, który pracuje nad innowacyjnym narzędziem w obszarze finansowo-technologicznym. Produkt ma zaspokajać potrzeby użytkowników w perspektywie kliku lat. Rozwijanie nowego produktu można porównać do robienia eksperymentów, które są realizowane w krótkich cyklach. Jacek jest świadomy tego, że rozpoczynając pracę nad nowym produktem nie da się określić wszystkich wymagań. Większość z nich zostanie przechwycona w trakcie pracy, kiedy możliwe będzie przetestowanie poszczególnych funkcjonalności produktu. Innymi słowy, kolejne funkcjonalności są dostarczana przyrostowo w oparciu o informację zwrotną. Wszyscy dostrzegają cel swoich działań, w końcu tworzą coś co stanowi prawdziwą wartość.

O ile przedstawione postacie są fikcyjne, o tyle sytuacje z którymi stykają się zarówno Jacek jak i Michał są Ci zapewne bliskie. Postanowiłem posłużyć się fragmentami tekstu, żeby nieco lepiej przybliżyć różnicę pomiędzy tradycyjnym podejściem projektowym a zwinną organizacją pracy osadzoną w podejściu produktowym. W dalszej części wpisu przybliżam pojęcie empiryzmu oraz jeden z kluczowych powodów, dla których stanowi on podstawę zwinności. Wszystko to opisują oczywiście w kontekście fazy projektowej w branży architektoniczno-budowlanej.

Michał jest bardzo skupiony na organizacji projektu. Dla Jacka najważniejsze jest natomiast stworzenie produktu, który będzie zaspokajał faktyczne potrzeby użytkowników nie tylko teraz, ale również w przyszłości. Michał i Jacek reprezentują dwie odmienne postawy, w których osadzone są kaskadowa i zwinna organizacja pracy.

Otoczenie, w którym pracuje zarówno Michał i Jacek jest podobne. Jednak to co ich różni to ich reakcja na brak przewidywalności. Michał podąża zgodnie z określonym schematem działania, który zakłada bardzo małą dozę elastyczności. Jacek natomiast odchodzi od utartych schematów i poszukuje alternatywnych rozwiązań. Jacek jest świadomy ryzyka związanego z możliwością wystąpienia zmian i akceptuje ten stan rzeczy.

Nieprzewidywalność można rozpatrywać w skali naszego najbliższego otoczenia jak i poziomie globalnym. Nie da się np. jednoznacznie przewidzieć zmian klimatu jak i postępu technologicznego z którym przyjdzie się nam zmierzyć w niedalekiej przyszłości. Nieprzewidywalność powoduje, że liniowe metodologie, które skupiają się na standaryzacji zamiast otwartości na innowację przestają mieć współcześnie zastosowanie. Ustępują one miejsca rozwiązaniom, które kryją się pod pojęciem zwinnych ram postępowania (ang. agile framework). Nie stanowią one ścisłych reguł, które są charakterystyczne dla metodyk zarządzania, lecz pozostają rodzajem drogowskazu, który można dostosowywać do własnych potrzeb. Jedną z nich są zwinne ramy postępowania Scrum, na których postanowiłem skupić swoją uwagę. Uważam, że ten sposób organizacji pracy ma bardzo duży potencjał pod kątem zastosowania w procesie projektowo-budowlanym.

  • Scrum nie jest metodologią. Scrum umożliwia zespołom tworzenie własnych adaptacyjnych procesów w empiryczny sposób.
  • Scrum to ramy postępowania osadzone w podejściu produktowym, czyli podejściu, które skupia się na wartości efektu pracy zamiast jej organizacji.
  • Scrum ułatwia planowanie, kiedy nie da się jednoznacznie określić potrzeb.

Scrum to słowo, które w bezpośrednim tłumaczeniu oznacza młyn – metodę wznowienia gry w rugby, polegającą na tym, że gracze grupują się blisko siebie i próbują zdobyć piłkę. Zgodnie z opisem w The Scrum Guide, książce standardów stworzonej przez Kena Schwabera i Jeffa Sutherlanda, Scrum opiera się o empiryczne podejście do problemów oraz sposób myślenia zgodny ze strategią Lean. Empiryzm‎‎ oznacza pracę w sposób oparty na faktach, doświadczeniu i dowodach. Tak samo w inżynierii i procesie projektowo-budowlanym postęp opiera się na obserwacjach rzeczywistości, a nie fikcyjnych planach.

Empiryzm

Przykład nieprzewidywalnych zdarzeń i możliwych reakcji w pracy z wykorzystaniem BIM.

Odnosząc się do fazy projektowej branży architektoniczno-budowlanej produktem może być zarówno dokumentacja projektowa linii kolei dużych prędkości, umożliwiająca skomunikowanie punktu A z B, jak i aplikacja służącej do zarządzania budynkiem, która np. agreguje dane z modelu BIM. Pracując nad produktem, można w dużym uproszczeniu stwierdzić, że pracujesz nad rozwiązaniem określonych problemów, które pojawiają się w trakcie pracy. W zależności od tego jak bardzo są one skomplikowane, niezbędny jest dobór odpowiedniej metody ich rozwiązania. Relację tą można również sformułować w następujący sposób: w zależności od tego na jakim poziomie zostanie sklasyfikowany problem niezbędny jest dobór odpowiedniego modelu zachowania, dzięki, któremu będzie możliwe jego rozwiązanie. Związek ten opisuje model Cynefin opracowany w 1999 r. przez Davea Snowdena, badacza teorii złożoności i zarządzania wiedzą.

Model Cynefin zakłada istnienie czterech podstawowych dziedzin: oczywistą (prostą), skomplikowaną, złożoną, chaotyczną. Dziedziny oczywista i skomplikowana mieszczę się w obszarze uporządkowanym natomiast złożona i chaotyczna w obszarze nieuporządkowanym. Model zachowania, który dotyczy dziedziny oczywistej polega na rozumieniu – kategoryzacji – reakcji. W dużym uproszczeniu odpowiada on systemowi pracy projektowej w klasycznym ujęciu, w sytuacji, w której zakładasz bardzo małe ryzyko wystąpienia problemów, których nie da się jednoznacznie skategoryzować. Co się jednak stanie w sytuacji, gdy problemy, które wystąpią w trakcie realizacji projektu okażą się bardziej złożone? Zgodnie z tym co proponuje Dave Snowden, należy do nich podejść w sposób empiryczny, poprzez doświadczenie. Model zachowania, który dotyczy dziedziny złożonej polega na: sondowaniu – rozumowaniu – reakcji. Problemy mogą dotyczyć:

  • użycia narzędzi i zasobów,
  • oczekiwań klienta,
  • zastosowania nowatorskich rozwiązań.

Odnosząc się do fazy projektowe w branży architektoniczno-budowlanej, czynnością, w trakcie której niezbędne będzie rozwiązanie oczywistych problemów, jest np. przygotowanie dokumentacji projektowej domu jednorodzinnego. Projekty takie oparte są o sekwencję następujących po sobie zdarzeń, które są przewidywalne i można je ułożyć w sposób kaskadowy (ang. Waterfall). Może się jednak okazać, że podobny budynek ma być realizowany na stromym zboczu, jego komponenty będą wytwarzana w innowacyjnej technologii druku 3d a poza dokumentacją projektową niezbędne będzie np. przygotowanie modelu BIM zawierającego dane umożliwiające prefabrykację. Wyzwania, z którymi zmierzy się w takim wypadku projektant są trudne do przewidzenia a jedynym słusznym rozwiązaniem może się dla niego okazać tworzenie komponentów modelu BIM i ich testowanie w następujących po sobie, krótkich cyklach. Czynność tą można porównać do tworzenia przyrostu. Kolejne fragmenty są dostarczane dzięki informacji zwrotnej – sondowanie oraz jej analizie – rozumowanie. Dzięki analizie możliwe jest natomiast wytworzenie kolejnej niedużej partii – reakcja. Innymi słowy w fazie projektowej tworzone są prototypy, które może przetestować odbiorca. Praca w krótkich cyklach umożliwia minimalizowanie ryzyka związanego z popełnieniem błędu. Wytwarzanie przyrostu dzięki empirycznemu doświadczeniu stanowi podstawę zwinnych ram występowania Scrum.

Przechwytywanie wymagań

Zamiast tworzyć obszerną dokumentację zawierającą wszystkie niezbędne informacje, lepiej skupić się na sposobach umożliwiających ich przechwytywanie w trakcie pracy.

Zadając klientowi pytanie czego naprawdę potrzebuje nigdy nie uzyskasz właściwej odpowiedzi. W wielu przypadkach klient nie jest świadomy własnych potrzeb. Dopiero kiedy zapozna się z próbną wersją produktu możesz stwierdzić, które z potrzeb zostały błędnie zdiagnozowane, a które poprawnie. Potrzeby zmieniają się również w czasie. Wpływ na to ma szereg różnych czynników zewnętrznych. można na tej podstawie stwierdzić, że potrzeby są zmienne i trudne do opisania na początkowym etapie.

Jeśli zaakceptujesz niepewność jako normalny stan rzeczy, szczegółowe dokumentowanie wszystkich wymagań przed przystąpieniem do pracy, nie ma głębszego uzasadnienia. Zamiast dokumentowania można je przechwytywać w trakcie pracy. Pomijam tu oczywiście wymagania wynikające z przepisów prawa, innych regulacji wewnętrznych lub danych wyjściowych na tyle, na ile można je traktować jako stałe. W praktyce oznacza to zbieranie informacji zwrotnej od użytkownika na podstawie jego interakcji z kolejnymi prototypami produktu. Najprostszym przykładem prototypu w fazie projektowej branży architektoniczno-budowlanej może być makieta zarówno w wersji analogowej jak i wirtualnej. Funkcjonalności produktu są dostarczane kawałek po kawałku do momentu zaspokojenia potrzeb mających dla klienta najwyższy priorytet. Każde z wydań umożliwia przechwycenie nowych wymagań lub zmianę już istniejących.

Jeśli w czynność związaną z przechwytywaniem wymagań zaangażowana jest większa ilość osób, tym bardziej ich definicja odpowiada faktycznym potrzebom użytkownika. Synteza różnych punktów widzenia ujęta w określonych ramach postępowania ułatwia bardziej precyzyjną diagnozę problemu.

Chcąc zwiększyć efektywność procesu projektowego warto przeanalizować dostępne metody organizacji pracy, które są stosowane w innych branżach. Poziom skomplikowania realizowanych współcześnie inwestycji budowlanych wymusza potrzebę zaangażowania ekspertów wyspecjalizowanych w różnych obszarach wiedzy, wykorzystanie innowacyjnych rozwiązań i narzędzi. Są to jedne z warunków, dla których zwinna organizacja pracy staje się niejednokrotnie jedynym rozwiązaniem, które niestety jest bardzo rzadko stosowane. O ile proces realizacji inwestycji jako całość, jeszcze przez długi czas będzie zorganizowany kaskadowo, o tyle wyodrębniając z niego poszczególne fazy sytuacja nie jest już tak jednoznaczna.

  • Zastanów się jak są zorganizowane projekty, w które jesteś zaangażowany?
  • Czy problemy, z którymi się stykasz można zakwalifikować, jako oczywiste czy też bardziej złożone a może całkowicie chaotyczne?
  • Niezależnie od sposobu organizacji spróbuj zacząć przechwytywać wymagania w trakcie pracy. Potrzeby klienta cały czas się zmieniają. Wystarczy, że na początku zbierzesz tylko te informacje, które są Ci niezbędne w krótkiej perspektywie. Dziel się z klientem tym co zrobisz po zakończeniu każdego cyklu nawet jeśli nie jest to skończone. Zbieraj i archiwizuj wszystkie niezbędne informacje i zapisuj je na liście, do której wgląd powinien mieć również klient.

Jeśli uważasz treść za wartościową podziel się nią w mediach społecznościowych. Zachęcam Cię również do przeczytania kolejnej części cyklu, w której opisuję role w zwinnym zespole projektowym oraz jak można je zaadoptować do istniejącej struktury organizacyjnej.

Komentarze

Subscribe
Powiadom o
0 komentarzy
najstarszy
najnowszy oceniany
Inline Feedbacks
View all comments