Zwinne zarządzanie projektami – wstęp do Agile – zwinny BIM 8/10

W poprzednich wpisach z cyklu zwinny BIM przedstawiliśmy przyczyny niskiej produktywności w branży budowlanej oraz brytyjskie pomysły na jej przezwyciężenie. Jednym z wielu proponowanych rozwiązań jest wdrożenie metodyki Building Information Modeling (BIM), czyli przede wszystkim usprawnienie komunikacji, gromadzenia, wymiany i dostępu do informacji. W tym wpisie przybliżymy wstęp do Agile BIM, a w kolejnych przetłumaczymy zasady Agile na język BIM.

Ten post jest częścią serii „Zwinny BIM”. Kliknij poniżej, aby sprawdzić inne wpisy.

1. Dlaczego BIM? Geneza nowych rozwiązań – zwinny BIM cz. 1/10
2. Brytyjski pomysł na BIM – normy i protokoły – zwinny BIM cz. 2/10
3. CDE wg ISO 19650 – zwinny BIM cz. 3/10
4. Dlaczego CDE jest takie ważne w BIM? – zwinny BIM cz. 4/10
5. Przykłady platform wymiany danych CDE – zwinny BIM cz. 5/10
6. Co to jest BIM? – Zwinny BIM cz. 6/10
7. BIM a tradycyjnie zarządzany projekt budowlany – Zwinny BIM 7/10
8. Zwinne zarządzanie projektami – wstęp do Agile – Zwinny BIM 8/10
9. Tłumaczenie zasad Agile na język BIM – Zwinny BIM cz. 9/10
10. Co zrobić żeby BIM był Agile? Zwinny BIM 10/10

Historia Agile: Od Branży Wytwórczej do IT – Wstęp do Agile BIM

Mówiąc rozwoju i zastosowaniu Agile najczęściej myśli się o firmach z branży IT,  a jako początek przyjmuje się opublikowany w 2001 roku “Manifest agile”. W rzeczywistości początki i inspiracje należy szukać znacznie wcześniej w branży wytwórczej. W artykule z 1993 roku “The new product development game” [4] przeanalizowano kilka produktów, które przez producentów były uznawane za przełomowe, wnoszące nowoczesne funkcjonalności oraz które odniosły sukces na rynku: Kopiarka Fuji-Xerox FX-3500 z 1978 roku, kopiarka Canon PC-10 z 1982 roku, samochód Honda City z silnikiem 1200cc z 1981 roku, komputer osobisty NEC PC 8000 z 1979 roku, lustrzanka Canon AE-1 z 1976 roku, aparat kompaktowy Canon Auto Boy z 1979 roku. Na podstawie badań wyznaczono 6  charakterystycznych, wspólnych elementów procesu tworzenia nowych produktów, które oddzielnie nie miały znaczenia, a stosowane wspólnie stanowiły receptę na sukces.

Harmonogram prac, źródło: www.businesswire.com

Kluczowe Elementy Agile w Procesie Tworzenia Produktów – Wstęp do Agile

Zostały one określone jako:

• Wbudowana niestabilność:

zespół dostaje ambitny cel oraz swobodę w zakresie wykonania projektu. Pozwala to uwolnić się od schematów i utartych ścieżek, aby zaproponować ambitne rozwiązanie.

• Samoorganizujące się zespoły:

Kadra kierownicza ogranicza swój udział do wskazówek, finansowania i wsparcia. Samoorganizujące się zespoły w krótkim czasie zaczynają działać podobnie do startup’ów. Tworzą własne nowatorskie pomysły, podejmują ryzyko i uczą się na błędach. Przykładowo, Honda postawiła na zespół którego średnia wieku wynosiła 27 lat, ponieważ celem projektu było zaprojektowanie samochodu dla ludzi młodych. Zespół potrafił uwolnić się od przyjętych standardów i utartych wzorców i zaproponować zupełnie nową jakość. Aby takie zespoły mogły sprawnie działać, muszą być złożone z przedstawicieli różnych specjalizacji, dzięki temu pojawiały się i były weryfikowane pomysły z różnych punktów widzenia.

• Nachodzące na siebie fazy procesu wytwarzania:

Zauważono, że skutkiem ubocznym zespołów składających się z członków o różnej specjalności było nakładanie się etapów  procesu tworzenia produktu. Specjalizacje i role zostały rozmyte, cały zespół czuł się współodpowiedzialny za wykonanie zadania. Zespół zmniejszył ilości błędów i problemów przy przechodzeniu z jednego etapu do drugiego

• Wielopłaszczyznowe uczenie się:

Aby zespoły mogły szybko reagować na zmieniające się warunki, powinny stale korzystać z zewnętrznych źródeł informacji oraz metodami prób i błędów szybko zlokalizować i ograniczyć liczbę działających rozwiązań

• Subtelna kontrola:

Nadmierna zewnętrzna kontrola zabija spontaniczność i kreatywność, lepszym rozwiązaniem jest połączenie samokontroli zespołu z kontrolą przez presję koleżeńską wynikającą z dążenia do wspólnego celu.

• Transfer wiedzy w organizacji:

Zauważono potrzebę transferu dobrych rozwiązań i pomysłów wewnątrz organizacji. Jeden z pomysłów polegał na przesuwaniu kilku posiadających ponadstandardowe umiejętności pracowników pomiędzy projektami.

Zauważono również potrzebę oduczania się, ponieważ niekiedy wiedza i przekonania mogą ograniczać rozwój. Myślę że to najlepiej wyjaśnia powiedzenie “zrobił to, bo nie wiedział że tak się nie da”

Zastosowanie Agile w IT: Nowe Podejście do Zarządzania Projektami

Powyższe obserwacje i wnioski stanowią dobrą bazę bo zrozumienia założeń Agile i możliwości jego implementacji z BIM.

Mechanizmy Agile, w formie jaka jest znana obecnie, pojawiły się jako odpowiedź na problemy z realizacją projektów w branży IT. Oprogramowanie było dostarczane zbyt późno i ze sporą ilością błędów, pomimo dużego zaangażowania zespołów i pracy pod presją.

Wnioski na Przyszłość: Jak Agile i BIM Mogą Współpracować

Jaki z tego można wyciągnąć wniosek?

Skoro pracownicy mają odpowiednią wiedzę, pracują ciężko i z zaangażowaniem, a projekty nie osiągają wymaganej jakości i terminowości, oznacza to, że problem znajduje się po stronie organizacji pracy i procesów.

Podobne obserwacje poczynił znacznie wcześniej Edwards Deming. Jest on uważany za twórcę sukcesu gospodarczego Japonii po 2 wojnie światowej. Uważał on, że 94% wszystkich błędów w pracy wynika z procesów i systemów, które zależą od kierownictwa, a tylko 6 % od pracownika. Deming był zdecydowanym wrogiem kontroli oraz metod zarządzania przez cele i zarządzania przez wyniki.  Uważał że decyzje w sprawach dotyczących procesów i jakości powinny być podejmowane razem z pracownikami. To oni wykonują pracę i najlepiej znają proces.

Zadania o różnym stopniu ważności źródło: www.asana.com

Manifest Agile – wstęp do Agile BIM

Część dotyczącą zwinnych metod zarządzania zacznę od omówienia opublikowanego w 2001 roku “Manifest Agile”[1]. Co ważne, pozycje z prawej strony tabeli również są istotne, ale większą wartość przypisuje się tym z lewej strony.

Podstawowe zasady Agile – wstęp do Agile BIM

Z manifestem Agile ściśle wiążemy 12 zasad. Opisują one wstęp do Agile. Opiszę je tam gdzie to konieczne, w formie niezwiązanej bezpośrednio z branżą IT. Poniższe punkty są cytatami bezpośrednio z oryginalnych zasad Agile stworzonych na potrzeby branży IT. Używając tych określeń nie należy czytać ich bez tego kontekstu. np Architektura w punkcie 11 oznacza architekturę oprogramowania, a nie architekturą jako projektowanie budynków) [2] [3]:

1. „Najwyższy priorytet ma dla nas zadowolenie klienta dzięki wczesnemu i ciągłemu wdrażaniu wartościowego oprogramowania.” 

Celem pracy nie jest zadowolenie biura projektu, generalnego wykonawcy ani spełnienie wszystkich wymagań jakości, ale dostarczenie produktu spełniającego realne oczekiwania klienta. Nie chodzi tu oczywiście o bezrefleksyjne i bez przeprowadzenia odpowiedniej analizy zgadzanie się na wszystko co chce klient, bo to w dłuższej perspektywie doprowadzi do pogorszenia jakości. Warto zwrócić uwagę na łącznik „dzięki”, podkreśla on, że satysfakcja klienta jest konsekwencją dostarczenia wartościowego, spełniającego oczekiwania klienta projektu/produktu i na tym należy się skupić.

W tym miejscu wrócę do przykładu remontu mieszkania z poprzedniego wpisu z cyklu „zwinny BIM” (7/10). Załóżmy że tym razem rzeczywistym celem będzie zadowolenie Zamawiającego, a nie jedynie spełnienie ustalonych parametrów i ustalonej jakości. Aby to osiągnąć generalny wykonawca (mąż) dzieli pracę na mniejsze kawałki, np dwudniowe, na zakończenie których przedstawia Zamawiającemu (Żonie) to co zostało wykonane. Jeśli okazuje się że zamysł Zamawiającego (Żony) był przez nas inaczej zrozumiany, to jest to dobry moment żeby wprowadzić zmiany. Gdyby ten przykład odnieść do doświadczeń Nas samych, jako wykonujących remonty w swoich domach, okazałoby się, że intuicyjnie bez przypisywania nazwy Agile” postępujemy właśnie w taki zwinny sposób.

2. „Bądźcie gotowi na zmiany wymagań, nawet na późnych etapach projektu. Proces Agile wykorzystuje zmianę do osiągnięcia przewagi we współzawodnictwie na korzyść klienta.” 

Zakładamy że lista rzeczy do zrobienia jest płynna i można dodawać do niej nowe wymagania, modyfikować istniejące, usuwać zbędne. Nie potrzeba do tego procesów zarządzania zmianą (np. renegocjacji kontraktu). Zawsze będziemy zajmowali się wymaganiami o najwyższym priorytecie. Gotowość na zmiany nie oznacza pracy w chaosie czy też natychmiastową reakcję na zmiany poprzez gaszenie kolejnych pożarów. Zasada ta oznacza skupienie się na gotowości i implementacji zmian nawet na późnym etapie rozwoju produktu dzięki wprowadzeniu odpowiednich technik zarządczych. Należy przestać być zaskakiwanym zmianami i zwinnie się do nich dopasowywać.

3. Dostarczaj funkcjonujące oprogramowanie często, w odstępach od kilku tygodni do kilku miesięcy, im częściej tym lepiej”  

W tym punkcie przede wszystkim chodzi o pozyskanie wartościowej informacji zwrotnej, więc nie oznacza to, że trzeba dostarczyć cokolwiek, aby sprawiać wrażenie szybkiego postępu prac. Należy dostarczać tylko te fragmenty produktu/projektu, które spełniają założone kryteria ukończenia, aby na podstawie informacji zwrotnej skorygować kolejne działania.

Waterfall vs. Agile źródło: www.techguide.com.au

4. “Zespoły biznesowe i deweloperskie muszą ściśle ze sobą współpracować w codziennej pracy przez cały czas trwania projektu” 

Metody zwinne działają dzięki krótkiej pętli informacji zwrotnej. Informacje są częste, więc najczęściej szkoda nam czasu na zbyt sformalizowane zasady i na komunikacje inna niż bezpośrednia. Główną przyczyną nieporozumień podczas pracy nad projektem jest przepaść komunikacyjna między uczestnikami projektu, w tym również między biznesem, projektantami różnych branż, generalnym wykonawcą, klientem. Jednym ze sposobów na zbliżenie tych dwóch światów jest połączenie ich na co dzień. Współpraca w Agile oznacza sprawną komunikację, negocjacje i tam gdzie to konieczne kompromisy. Nie należy jej jednak rozumieć jako rozmycie zakresu obowiązków i przerzucanie zadań pomiędzy członkami zespołu. Każda rola musi mieć jasno określony zestaw zadań i obowiązków za które jest odpowiedzialna.

5. “Projekty powierzaj zmotywowanym jednostkom. Dajmy im środowisko i wsparcie którego potrzebują. Zaufaj im że praca zostanie wykonana” 

Głównymi czynnikami blokującymi zwinność projektów jest kontrola i brak zaufania ze strony kierownictwa. W zespołach Agile mamy do czynienia z tzw „mikromanagementem”. Rolą kierownictwa jest ograniczona do wspierania zespołu, zapewnienia wszystkich elementów niezbędnych do wykonania pracy i usuwania przeszkód. Dobrą analogią roli kierownictwa jest praca ogrodnika. Nie ma on bezpośredniego wpływu jak szybko rośnie roślina, ile wyda owoców, jakiej wielkości i jakości, może stworzyć środowisko, nawozić nawadniać i usuwać chwasty aby wspierać niezagrożony wzrost roślin.

Zapewnienie odpowiedniego środowiska nie powinno jednak przybierać formy „matkowania”. Jest to usuwanie każdej możliwej przeszkody, niedopuszczenie do popełnienia błędów, ochronę przed negatywna informacją zwrotną. W obawie, że spowoduje to brak samodzielności i nie uczenie się na błędach. Zamiast tego powinno skupiać się na  dążeniu do samodzielności, samoorganizacji i uczeniu się na błędach. Dla kierownictwa pozbycie się chęci kontrolowania wszystkiego i szukania winnych popełnianych błędów jest niesamowicie trudnym procesem. Warto zrozumieć że popełnianie błędów leży w naturze ludzkiej, skoro ich nie unikniemy to należy je wykorzystać do zdobycia przewagi konkurencyjnej.

6. “Najskuteczniejsza i najwydajniejsza metoda przekazywania informacji zespołowi i  wewnątrz niego jest bezpośrednia rozmowa”.  

Najprościej mówiąc komunikacja to proces przekazywania informacji od nadawcy do odbiorcy. Jest ona efektywna, jeśli odbiorca potwierdził że dostał komunikat i go zrozumiał. Można wyróżnić 3 rodzaje sposobów komunikacji: mowa ciałą, brzmienie głosu i słowa. Wszystkie 3 elementy są obecne podczas bezpośredniej rozmowy lub wideokonferencji. Podczas rozmowy telefonicznej znika mowa ciała, w komunikacji pisemnej również brzmienie głosu. Dodatkowo powszechnie używana komunikacja e-mail to komunikacja jednokierunkowa – nie otrzymujemy od razu informacji zwrotnej, a odpowiedź można często odłożyć na później. Tam gdzie to jest możliwe należy wykorzystać rozmowy bezpośrednie lub wideokonferencje, dbając jednak przy tym, aby nie zamieniły się w długie i nużące spotkania.

7. “Działające oprogramowanie jest podstawową miarą sukcesu” 

Powszechną praktyką tradycyjnie zarządzanych projektów budowlanych jest zdefiniowanie mierzalnych wskaźników postępu projektu, tworzenie różnego rodzaju raportów, arkuszy kalkulacyjnych i prezentacji które dają złudne poczucie kontroli postępu projektu. Często powoduje to podążanie przez zespoły za spełnieniem wymaganego wskaźnika, a nie stojącego za nim celu. Pracując zgodnie z Agile nie jest ważne ile wskaźników osiągnął zespół, tylko jaki jest efekt jego pracy. Przykładowo, nie jest wartością samą w sobie ile błędów i kolizji wykryliśµy w ramach zespołu w modelu 3D. Istotne jest czy w założonym zakresie jest on skończony i ich pozbawiony. Warto zwrócić uwagę na występujące w tej regule słowo “podstawową”. Istnieje wiele miar które można wykorzystać i warto z nich korzystać, jednak nie powinny być celem samym w sobie.

8. “Procesy zwinne umożliwiają zrównoważony rozwój,  wszyscy powinni być w stanie utrzymać równe tempo pracy.” 

Praktyka pokazuje, że członkowie zespołów pracujący w nadgodzinach popełniają więcej błędów wskutek przemęczenia. Brak czasu na odpoczynek i odreagowanie stresu źle wpływa na atmosferę w pracy oraz na kreatywność zespołu. Wspólna praca zespołu daje możliwość rozwoju i satysfakcji,  ale należy dbać o zachowanie równowagi.

9. “Ciągła koncentracja na technicznej doskonałości i dobrym projekcie poprawia zwinność” 

Projekt tworzony w pośpiechu i bez przemyślenia będzie generował wiele problemów na późniejszych etapach. Na początku jest pokusa pójścia na skróty aby wykazać się szybkimi postępami prac. Wraz  z zaawansowaniem projektu, wszystkie braki i pobieżnie łatane dziury powodują, że problemy zaczynają się nawarstwiać. Skupienie się na technicznej doskonałości nie oznacza dążenia do perfekcji. Oznacza przygotowanie projektu/produktu tak, aby umożliwiał łatwe i szybkie wprowadzanie zmian w przyszłości.

10. “Prostota – sztuka zwiększania ilości pracy niewykonanej – jest niezbędna” 

Oznacza to, że projektant osiągnął optymalne rozwiązanie kiedy nie ma potrzeby niczego nowego dodawać, ale jednocześnie, nic nie może być usunięte.

11. “Najlepsze rozwiązania architektoniczne, wymagania i projekty pochodzą od samoorganizujących się zespołów.”  

W tym punkcie chodzi przede wszystkim o uwolnienie kreatywności zespołów i szybkie reagowanie na pojawiające się problemy, szanse i zagrożenia. W tradycyjnym, hierarchicznym modelu zarządzania decyzje są podejmowane na wyższych poziomach w hierarchii, często przechodząc przez cały łańcuch akceptacji. Powoduje to, że decyzje nie podejmuje osoba która najlepiej zna problem (szanse) i ma największą wiedzę jak sobie z nim poradzić (wykorzystać), ale osoba, która otrzymała niepełne, przefiltrowane przez poszczególne szczeble hierarchii informacje.  Dodatkowo dochodzimy do problemu wydłużenia czasu potrzebnego na podjęcie decyzji. Może to spowodować że decyzja, którą podejmiemy będzie odnosić się już dla aktualnej sytuacji.

Odpowiednio zmotywowany zespół, potrafi we własnym gronie skutecznie rozdzielić zadania oraz twórczo podejść do rozwiązania problemów lub wykorzystania szans. Oczywiście samoorganizacja nie oznacza przyzwolenia na anarchię. Oznacza zespół z doskonałą wewnętrzną dyscypliną. Rolą lidera jest pielęgnowanie odpowiedniego środowiska pracy i powstrzymanie się od narzucania swoich rozwiązań i nadmiernej kontroli.

12. “W regularnych odstępach czasu zespół zastanawia się jak zwiększyć wydajność, a następnie odpowiednio dopasowuje swoje działania do wyciągniętych wniosków” 

Podobna zasada zalecająca wyciągania wniosków na przyszłość pojawia się w wielu podejściach do zarządzania projektami. Dla ukończonego projektu takie wnioski są już bezużyteczne. Ozywiście mogą i powinniśmy wykorzystać w przyszłych projektach. Jednak kto dokładnie pamięta na końcu projektu co wydarzyło się np rok wcześniej? Dużo lepszą praktyką jest wyciąganie wniosków częściej w trakcie trwania projektu. Kiedy zajmujemy się jakimś zadaniem, nie dostrzegamy pełnego otoczenia i wszystkich związanych z nim detali. Właśnie dlatego warto abyśmy cyklicznie przeprowadzali przegląd projektu i możliwości poprawy wydajności. Istotne jest, aby szukanie możliwości poprawy nie było mylone z szukaniem winnych i wytykaniem ich palcami. To spowoduje że zespoły milkną, próbując przetrwać nie “wkopując” innych. Ciągłe wyciąganie wniosków jest jednym z ważniejszych elementów zwinności. Szczera rozmowa jest w tym niezwykle ważnym punktem wyjścia do samodoskonalenia, a milczenie oznacza pozbawienie się tej możliwości.