Wpis ten stanowi kontynuację cyklu pt. „Zwinna organizacja pracy w projektach BIM”. W poprzednim wpisie opisuję założenia przyrostowego systemu pracy. Ten system pracy stanowi podstawę zwinnych ram postepowania Scrum i jest zgodna z założeniami normy BS EN ISO 19650, która definiuje m.in. metodę opisywania nazw plików, ich przechowywania i wymiany z wykorzystaniem narzędzi do projektowania BIM. Dostarczanie przyrostu, który w praktyce oznacza kolejne, przetestowane komponenty dokumentacji projektowej lub poziom uszczegółowienia LOD jest możliwe dzięki informacji zwrotnej, którą możesz uzyskać dzięki zaangażowaniu klienta w proces projektowo-budowlany. Innymi słowy informacja zwrotna ułatwia przechwytywanie wymagań w trakcie pracy, dzięki którym projekt może stać się nośnikiem wartości dodanej w wymiarze jakościowym.
Rozpoczynając pracę nad nowym projektem dążysz do zebranie jak największej ilości informacji na temat potrzeb klienta. Co jednak zrobić, jeśli nie jest to możliwe albo zebrane informacje są niepełne i nie da się na ich podstawie zdefiniować wymagań? Potrzeby mogą się również zmieniać i trudno jest przewidzieć to co nastąpi w określonej perspektywie czasu. Rozwiązaniem pozostaje w takiej sytuacji przechwytywanie wymagań w trakcie pracy. Poza wymaganiami należy również pamiętać o pomysłach, które mogą usprawnić pracę lub problemach, z którymi zetknąłeś się na wcześniejszym etapie. W celu rejestracji wszystkich tych elementów i możliwości ich dalszego wykorzystania warto posłużyć się specjalnie w tym celu przygotowaną listą – rejestrem produktu (ang. Product Backlog). Rejestr produktu jest stosowany m.in. w rozwijaniu produktów informatycznych, ale może się również okazać niezwykle przydatny w procesie projektowo-budowlanym. We wpisie tym postanowiłem opisać jego specyfikę a także sposób w jaki można przechwytywać wymagania i sprawdzać ich użyteczność w fazie projektowej branży architektoniczno-budowlanej.
Rejestr produktu
Zawartość rejestru produktu podlega ciągłej transformacji i obejmuje niezbędne informacje dotyczące produktu rozumianego np. w kategoriach usługi jak i efektu podjętych działań, które są przechwytywane w trakcie pracy.
Planując cykl pracy (sprint) wybrane pozycje rejestru produktu mogą służyć jako podstawa do opisania realnych zadań do wykonania przez członków zespołu projektowego oraz ich osadzenia w czasie. Jego elementy (ang. PBI – Product Backlog Items) powinny z założenia skupiać się na wartości dodanej, której nośnikiem jest produkt. W branży informatycznej rejestr produktu można porównać do listy zadań właściciela produktu, który zna i rozumie potrzeby klienta.
Priorytetyzacja elementów rejestru produktu
Słuchając kiedyś wywiadu z psychologiem i trenerem personalnym Miłoszem Brzezińskim spotkałem się z określeniem, które bardzo przypadło mi do gustu, które polega na przypisywaniu ocen projektom, w które chcemy się zaangażować. Projekt może być na trójkę lub czwórkę, ale warto jest angażować się tylko w te projekty, które są na szóstkę. Dysponując ograniczonymi zasobami nie da się zrobić wszystkiego na raz. Trzeba dokonywać wyboru. Tak samo jest w przypadku rejestru produktu. Jego poszczególne elementy (PBI) są ułożone w kolejności od najwyższego do najniższego priorytetu. System priorytetyzacji może np. wynikać z zależności między ryzykiem i wartością. Można przyjąć, że należy skupiać się w pierwszej kolejności na elementach, których realizacja jest najbardziej ryzykowna, ale przy tym przekłada się, na najwyższą korzyść dla klienta. Na samym końcu są natomiast realizowane pozycje odznaczające się niskim ryzkiem i niską wartością. Zgodnie z poniższym diagramem pozycje odznaczające się wysokim ryzykiem i niską wartością należy w ogóle pominąć.
Innym sposobem priorytetyzacji jest dosyć powszechnie znana metoda związana z użyciem matrycy lub macierzy Eisenhowera. Jej założeniem jest podział zadań na cztery kategorie: pilne/niepilne i ważne/nieważne. Po sklasyfikowaniu zadań należy dążyć do poświęcenia największej uwagi temu co jest ważne a nie jest pilne. W kontekście rejestru produktu odpowiednia kategoria zostanie przypisana do jego elementów.
Elementy rejestru produktu (PBI) można również ułożyć stosując metodę MoSCoW. Nazwa metody to tzw. mnemonik, który oznacza: M – Must have, S – Should have, C – Could have, W – Won’t have. Metoda ta zakłada, że każdy z elementów rejestru produktu powinien mieć przypisaną kategorię. Kategorię M powinno stanowić nie więcej jak 60% zadań, S i C odpowiednio po 20%, zadania oznaczone jako W należy odrzucić.
PBI czyli zawartość rejestru produktu
Poniżej przedstawiłem możliwą zawartość rejestru produktu w fazie projektowej branży architektoniczno-budowlanej. Rejestr ten odnosi się bezpośrednio do efektu pracy projektanta w postaci modelu BIM i powiązanej z nim dokumentacji projektowej, którego odbiorcą nie jest użytkownik końcowy (np. klient indywidualny) a inne działy w większej strukturze organizacyjnej, która występuję w roli pośrednika.
- Żądania dotyczące zawartości modelu BIM i powiązanej z nim dokumentacji projektowej.
- Wymagania dotyczące niezbędnych uzgodnień.
- Żądania dotyczące poziomu LOD (w tym w zakresie LOG i LOI) dla poszczególnych komponentów modelu BIM i powiązanej z nim dokumentacji.
- Propozycje rozwiązań umożliwiających np. automatyzację powtarzalnych czynności.
- Wymagania w zakresie usunięcia powstałych usterek ( uaktualnienie pliku template).
- Przypadki użycia danych zawartych w modelu BIM (opisane w formie historii użytkownika) z wykorzystaniem dedykowanej aplikacji do ich dalszej edycji.
Rejestr produktu w wersji analogowej może przybierać formę tablicy lub wydzielonej w jej obrębie przestrzeni, na której przyczepione są kartki typu post-it zawierającące krótki opis. Zawartość tablicy należy aktualizować co najmniej podczas spotkań estymacyjnych związanych z przeglądem i planowaniem kolejnego cyklu pracy (sprintu). Osoba, która wspiera zespół od strony organizacyjnej powinna dysponować wersją cyfrową rejestru, która jest aktualizowana po każdej sesji estymacyjnej i jest udostępniona wszystkim interesariuszom w tym klientowi i członkom zespołu projektowego przez cały okres trwania projektu. Gdy analogowa tablica jest poza twoim zasięgiem łatwo przypomnieć sobie treść kart i ich priorytety. To samo zalecam, jeśli korzystasz z dedykowanego komunikatora za pomocą, którego komunikujesz się z innymi przedstawicielami spółek lub/i tzw. klientem wewnętrznym. Transparentność w tym wypadku wpływa na większe poczucie sensu tego co wykonujesz. Chcąc utworzyć rejestr w wersji cyfrowej możesz sformułować go, w formie dokumentu udostępnionego w chmurze lub listy zadań w aplikacji do zarządzania projektami takiej jak np. ClickUp lub Monday. Kontrolę nad dostępem do zawartości oraz uaktualnieniem rejestru powinna sprawować wyznaczona do tego celu osoba, której zakres obowiązków odpowiada roli właściciela produktu w Scrum. Każda zmiana dotycząca zawartości rejestru produktu powinna być konsultowana z członkami zespołu projektowego.
Historie użytkownika
Rozwiązaniem, które ułatwia opisywanie przechwytywanych wymagań i wszystkich innych niezbędnych informacji w trakcie pracy są historie użytkownika. Historie użytkownika wywodzą się z tzw. przypadków użycia, które w branży informatycznej opisują różne scenariusze użytkowania danej funkcji. Przypadki użycia mogą przybierać formę schematu zbudowanego za pomocą języka obiektowego UML. Podobne rozwiązania stosuje się w branży architektoniczno-budowlanej. Jako przykład można podać np. analizę scenariuszy ewakuacji z budynku, która odnosi się m.in. do sposobu komunikacji pomiędzy różnymi pomieszczeniami. W efekcie możliwy jest wybór optymalnego rozwiązania dostostosowanego do określonych warunków brzegowych. Historia użytkownika ma natomiast dużo bardziej zwięzłą formę i opisuje określony przypadek użycia danej funkcji lub rozwiązania. Historie użytkownika umożliwiają:
- usystematyzowanie wymagań pochodzących od różnych osób,
- doprecyzowanie wymagań, w tym niefunkcjonalnych, które nie są jasno zwerbalizowane,
- usystematyzowanie sposobu komunikacji.
Z mojego punktu widzenia największą zaletą historii użytkownika jest ich prostota. Historia użytkownika jest oparta o schemat logiczny, który może przybierać formy przedstawione w poniższej tabeli.
- Rola – odnosi się do wskazania osoby lub opisu klienta, który nie koniecznie musi być odbiorcą końcowym, ale również tzw. klientem wewnętrznym. Ich poziom zaangażowania może zostać określony w umowie lub innym dokumencie potwierdzającym wzajemne ustalenia. W projektach BIM informacja na temat ról poszczególnych osób zaangażowanych w projekt jest określona w planie projektu BIM (ang. BEP – Bim Execution Plan).
- Działanie – związane jest z określoną potrzebą ze strony klienta (po co?), która umożliwia zdefiniowanie wartości (co zyskam?).
- Aby/bo – to spójnik, dzięki któremu możliwe jest opisanie powodu określonego żądania. Powód odzwierciedla wartość jaką przynosi ono klientowi.
Poniżej przedstawiłem przykład w jaki sposób możesz opisać (w formie historii użytkownika) przechwycone w trakcie pracy żądanie w fazie przedprojektowej a następnie wykorzystać je do opisania kolejnego żądania w fazie projektowej.
Faza przedprojektowa
„Potrzebuję (przedstawiciel działu inwestycyjnego firmy ABC) szczegółowo określić potrzeby odbiorcy końcowego żeby móc oszacować koszt dodatkowego wyposażenia wychodzącej poza zakres standardu X.”
Na podstawie powyższego stwierdzenia można w skrócie założyć, że w fazie przedprojektowej niezbędne jest zaplanowanie zadań w celu przygotowania raportu określającego potrzeby użytkowników planowanej inwestycji.
Faza projektowa
Załóżmy, że z przeprowadzonej analizy w fazie przedprojektowej wynika, że jedną z kluczowych potrzeb jest możliwość wpływania na komfort użytkowania mieszkań. Informacja ta zostaje opisana w materiałach wyjściowych, które otrzymuje projektant. W takiej sytuacji, w fazie projektowej można sformułować następujące żądanie:
„Jako użytkownik mieszkania potrzebuję wpływać na panującą w nim temperaturę, ilość świeżego powietrza i jego wilgotności by czuć się komfortowo.”
Żądanie to może przekładać się np. na zwiększenie zakresu, który obejmuje projekt techniczny. Załóżmy, że rozszerzenie zakresu będzie dotyczyło przygotowania projektu instalacji BMS obejmującego system sterujący roletami zewnętrznymi. W przypadku, jeśli głównym projektantem jest architekt, który pełni również rolę koordynatora żądanie to może zostać wykorzystane w celu zdefiniowania listy obejmującej następujące zadania:
- Zlecenie projektu BMS
- Przekazanie modelu BIM zawierającego jedynie elementy konstrukcyjne, fasadę oraz stolarkę okienno-drzwiową.
- Przetestowanie przyjętych rozwiązań – skoordynowanie modelu instalacji BMS z innymi branżami.
- Sprawdzenie poprawności klasyfikacji poszczególnych komponentów modelu instalacji BMS oraz zawartych w nich informacji.
- Wgranie plików do repozytorium danych i odbiór dokumentacji powiązanej z modelem BIM.
- Rozliczenie z projektantem instalacji BMS.
DoR
Co łączy chirurgię i pilotów samolotów? umiejętność podejmowania decyzji, racjonalny sposób myślenia, opanowanie i listy kontrolne. Zarówno chirurdzy jak i piloci są członkami zespołów, które tylko dzięki sprawnej współpracy potrafią przywrócić nam zdrowie i w bezpieczny sposób przetransportować z jednego kontynentu na drugi. Zarówno podczas startu jak i w trakcie trwania operacji niezbędne jest właściwe przygotowanie. Żeby nie popełnić błędu musisz być pewny czy pacjent oddycha we właściwy sposób i czy w trakcie operacji istnieje ryzyko odstępstwa od zaplanowanego scenariusza. Jeśli ktokolwiek ma wątpliwość trzeba się zatrzymać i przenalizować ryzyko niezależnie od tego czy wątpliwość tą zgłasza pielęgniarka, anestezjolog czy kapitan. Listy kontrolne są podzielone na sekcje, które uzupełnia się na poszczególnych etapach operacji chirurgicznej lub lotu. Są to fizyczne listy zadań do wykonania zawierającą pola wyboru. Zaznaczenie pola oznacza właściwe przygotowanie do realizacji zadania lub ukończenie zadania. Poniżej zamieściłem linki umożliwiające zapoznanie się z ich treścią.
Lista kontrolna służy właściwej organizacji i podniesieniu poziomu bezpieczeństwa. Podobne rozwiązanie jest również stosowane w Scrum. Lista kontrolna umożliwia sprawdzenie czy dany element rejestru produktu może zostać wykorzystany do dalszej pracy i stać się następnie podstawą do zaplanowania zadań w cyklu pracy lub sprincie. Lista ta może przybierać postać definicji gotowości (ang. Definition of Ready – DoR). W projektach BIM, które są zarządzane z wykorzystaniem elementów Scrum tak samo jak w przypadku pracy nad nową aplikacją w branży IT, definicja gotowości „DoR” może być opisana w formie listy pytań lub checklisty. Poniżej podałem kilka przykładów. Nie ma tu żadnej uniwersalnej reguły, która mówiłaby, jak sformułować zawartość definicji gotowości. Tak jak Scrum pozostaje tyko ogólnymi ramami tak samo definicja gotowości powinna być zawsze dostosowana do uwarunkowań struktury organizacyjnej i samego projektu. Pytania te powinni zadać sobie wszyscy członkowie zespołu przed przystąpieniem do dalszej pracy. Zaletą stosowania definicji gotowości jest również możliwość podziału zbyt ogólnikowo opisanych lub zbyt złożonych elementów rejestru produktu na mniejsze części. Gotowy element rejestru produktu (PBI) powinien być w skrócie przejrzysty, wykonalny i testowalny. Zanim przystąpicie razem z pozostałymi członkami zespołu projektowego do dalszej pracy postarajcie się wspólnie odpowiedzieć:
- Czy dysponujecie wszystkimi niezbędnymi informacjami niezbędnymi do właściwego opisania danego elementu rejestru produktu (PBI)?
- Czy element rejestru produktu (PBI) jest zrozumiały dla wszystkich członków zespołu projektowego i odnosi się do określonych potrzeb klienta?
- Czy element rejestru produktu (PBI) da się zrealizować podczas jednego cyklu (sprintu)?
Jeśli uważasz treść za wartościową podziel się nią w mediach społecznościowych. Empiryczna postawa, czyli opieranie się na dowodach stanowi podstawę zwinnej organizacji pracy. Tymi dowodami są wymagania, które przechwycisz w trakcie pracy. Zachęcam Cię również do przeczytania kolejnej części cyklu, w której opisuję, jak można szacować pracochłonność elementów rejestru produktu i jak planować pracę, jeśli musisz dostarczyć model BIM i powiązaną z nim dokumentację projektową w określonym terminie lub określonym zakresie.
Komentarze