Agenda spotkania koordynacyjnego na 60 minut, notatka, rejestr decyzji i checklista RFI. Spotkanie koordynacyjne: agenda, notatka i rejestr decyzji Spotkanie koordynacyjne po dwóch miesiącach projektu wygląda zwykle podobnie. Cztery osoby pamiętają cztery różne […]
Spotkanie koordynacyjne po dwóch miesiącach projektu wygląda zwykle podobnie. Cztery osoby pamiętają cztery różne ustalenia, agenda jest w głowie prowadzącego, a decyzja z zeszłego tygodnia istnieje tylko w mailu, którego nikt nie potrafi znaleźć. Model się zmienia, notatki nie.
Nie chodzi o to, że zespół jest niestaranny. Chodzi o to, że spotkanie bez struktury produkuje ustalenia, których nie da się później odtworzyć. Dlatego przygotowałem cztery pliki, których używam na własnych spotkaniach: agendę na 60 minut, notatkę, rejestr decyzji i checklistę RFI. Wszystkie są w paczce na końcu wpisu.
W tym wpisie pokażę:
- jak rozłożyć 60 minut, żeby wystarczyło na model, kolizje, RFI i decyzje,
- jakie pola musi mieć notatka, żeby dała się przeczytać po miesiącu,
- po co numerować decyzje i jak prowadzić rejestr,
- kiedy sprawa jest RFI, a kiedy zwykłym zadaniem,
- jak zamknąć obieg kolizji, żeby nie wracać do tej samej uwagi trzeci raz,
- jak prowadzić spotkanie, żeby notatka powstawała w trakcie, a nie po nim.
Agenda na 60 minut
Agenda dzieli spotkanie na siedem bloków. Każdy blok ma jedno zadanie i efekt, który musi istnieć na jego końcu. Jeśli efektu nie ma, blok się nie udał, nawet jeśli rozmowa była długa i merytoryczna. To jedyne kryterium, które warto stosować.
| Czas | Blok | Co robimy | Efekt na koniec bloku |
|---|---|---|---|
| 0-5 | Otwarcie | Cel spotkania, lista obecnych, model i rewizja na ekranie | Wszyscy patrzą na tę samą wersję modelu |
| 5-15 | Przegląd modelu | Co się zmieniło od ostatniego spotkania, nowe rewizje, zmiany w zakresie | Lista zmian do sprawdzenia |
| 15-30 | Kolizje krytyczne | Otwarte kolizje o priorytecie 1 i 2, sortowanie po strefie i fachu | Każda kolizja ma właściciela i termin |
| 30-38 | RFI | Otwarte zapytania, odpowiedzi, które przyszły, terminy odpowiedzi | Zamknięte RFI i nowe zapytania z terminem |
| 38-50 | Decyzje | Punkty wymagające decyzji, warianty, osoba decydująca | Decyzje zapisane z numerem |
| 50-57 | Działania i terminy | Co wynika z decyzji, kto robi, do kiedy | Lista działań z odpowiedzialnymi |
| 57-60 | Zamknięcie | Odczytanie decyzji i działań na głos, potwierdzenie przez uczestników | Wspólny zapis, bez niedomówień |
Kolejność nie jest przypadkowa. Najpierw wszyscy patrzą na tę samą wersję modelu, bo bez tego spieramy się o różne budynki. Potem kolizje, bo one generują większość decyzji. RFI idą przed decyzjami, ponieważ odpowiedź na zapytanie często zmienia wariant, który dopiero mielibyśmy wybrać. Gdyby RFI były na końcu, decyzje zapadałyby na podstawie brakujących informacji.
Piętnaście minut na kolizje krytyczne brzmi krótko i jest krótkie. To celowe. Przy dwudziestu otwartych kolizjach nie przejrzymy wszystkich, ale przejrzymy te, które blokują projekt. Pozostałe mają priorytet i właściciela, więc nie znikają, tylko czekają na swoją kolej.
Ostatnie trzy minuty to nie formalność. Czytamy na głos decyzje i działania, a uczestnicy potwierdzają albo zgłaszają sprzeciw. W praktyce właśnie tam wychodzą nieporozumienia, które inaczej wybuchłyby przy modelu dwa tygodnie później, kiedy nikt już nie pamięta, kto co powiedział.
Czego agenda nie przewiduje: rozwiązywania szczegółów jednej kolizji na forum i omawiania tematów spoza zakresu. Pierwsze kończy się wyznaczeniem osoby i terminu, drugie trafia do kolejnej agendy. Bez tego jedno spotkanie zjada trzy kolejne. Sam widziałem spotkania, które przez dwie godziny omawiały jedną kolizję, a pozostałe piętnaście uwag nie zostało nawet otwartych.
Agendę wysyłamy dzień wcześniej, z wypełnionymi danymi i godzinami dopasowanymi do startu. Uczestnik, który wie, że o 15:00 rozmawiamy o jego kolizji, przychodzi przygotowany. Uczestnik, który dostaje agendę pięć minut przed spotkaniem, przychodzi z pytaniem, o czym właściwie mówimy.
Szablon notatki ze spotkania
Notatkę wypełniamy w trakcie, nie po. Różnica jest widoczna po tygodniu: notatka pisana na bieżąco ma krótkie, konkretne zdania, a rekonstrukcja z pamięci ma ogólniki i brak terminów. Nikt nie pamięta po trzech dniach, czy zdecydowano wariant A, czy tylko go rozważano.
Szablon zaczyna się od danych spotkania: projekt, data, prowadzący, notujący, model i rewizja. Model i rewizja to numer i data, nie słowo „aktualny”. Bez tego po dwóch tygodniach notatka przestaje być jednoznaczna, bo nie wiadomo, o której wersji modelu rozmawialiśmy i czy decyzja nie dotyczyła geometrii, która już się zmieniła.
Dalej lista uczestników z firmą i rolą. Nie po to, żeby wiedzieć, kto był, ale żeby przy każdej decyzji wiedzieć, kogo dotyczy. Jeśli w notatce nie ma architekta, a decyzja zmienia układ ścian, to nie jest decyzja, tylko propozycja do sprawdzenia.
Potem omówione punkty, decyzje i działania. Decyzja ma numer, właściciela i termin wdrożenia. Działanie to czasownik i osoba, nigdy temat. Zamiast wpisu „kolizja wentylacji” w notatce powinno stać „przesunąć kanał na poziomie 2, Marek, do 5.11”. Pierwszy zapis nie mówi nic o tym, co ma się wydarzyć. Drugi można sprawdzić i rozliczyć.
Status działań uzupełniamy na początku następnego spotkania, w bloku otwarcia. To jedyny moment, w którym ktoś jeszcze pamięta, dlaczego dany termin był realny, a nie wpisany na wyczucie. Pięć minut na przegląd statusów oszczędza pół godziny dyskusji o tym, czy temat był omawiany.
Osobna sekcja to sprawy otwarte i ryzyka. Wrzucamy tam wszystko, co nie jest jeszcze decyzją, ale może nią zostać: brakującą odpowiedź, niejasny zakres, zależność od innego fachu. Na końcu zostaje data następnego spotkania i termin wysłania notatki. Notatka, która nie ma daty wysyłki, zwykle nie zostaje wysłana wcale.
Rejestr decyzji
Rejestr decyzji to jedna zakładka arkusza i jeden wiersz na decyzję. Kolumny: numer, data, spotkanie, opis, wpływ na model, zgłasza, decyduje, status, termin wdrożenia, powiązane RFI i uwagi. Rejestr prowadzimy dla całego projektu, nie dla jednego spotkania.
| Nr | Decyzja | Wpływ na model | Decyduje | Status |
|---|---|---|---|---|
| D-001 | Kanały wentylacji na poziomie 2 pod strop, 40 cm poniżej belki | Zmiana trasy wentylacji w strefie B | A. Wiśniewska | W toku |
| D-002 | Kanalizacja w szachcie przy osi 7, bez przejścia przez ścianę ogniową | Zmiana w instalacjach, architektura bez zmian | A. Wiśniewska | Wdrożona |
Po co numer, jeśli wszyscy wiedzą. Wszyscy wiedzą do momentu, w którym ktoś dołącza do projektu albo wraca po urlopie. Numer jest adresem. Na spotkaniu mówimy „wracamy do D-014” i każdy może sprawdzić, co dokładnie ustalono, kto decydował i czy termin został dowieziony. Bez numeru zostaje opowieść o tym, że „kiedyś ustaliliśmy, że wentylacja idzie inaczej”.
Osobne pliki u każdego fachu to najczęstsza przyczyna rozjechanych ustaleń. Dwie osoby aktualizują swoje kopie, potem nikt nie wie, która jest aktualna, a na spotkaniu okazuje się, że jedna wersja ma decyzję, której druga nie ma. Jeden rejestr dla projektu rozwiązuje problem taniej niż jakiekolwiek uzgadnianie wersji.
Status ma trzy wartości: otwarta, w toku, wdrożona. Nie dopisujemy nowych bez ustalenia ich znaczenia, bo po miesiącu nikt nie odróżni „w realizacji” od „do sprawdzenia”. Jeśli zespół potrzebuje czwartego statusu, to znak, że brakuje kolumny z terminem, a nie statusu.
Decyzja wdrożona nie znaczy sprawdzona. Jeśli decyzja zmienia model, na następnym spotkaniu trzeba zobaczyć efekt w modelu. Rejestr ma kolumnę terminu, ale prawda jest w widoku kolizji. Dlatego w bloku otwarcia wracamy do decyzji z ostatnich dwóch tygodni i sprawdzamy je w modelu, a nie tylko w arkuszu.
Checklista RFI
RFI to pytanie, na które nie znamy odpowiedzi, a bez niej nie da się poprawnie zaprojektować. Nie jest RFI sytuacja, w której trzeba coś przerobić, bo ktoś nie sprawdził modelu przed spotkaniem. Rozróżnienie jest ważne, bo pierwsze wymaga odpowiedzi drugiej strony, a drugie wymaga pracy wewnątrz zespołu.
Dobrze zapisane RFI ma cztery elementy: pytanie, kontekst, adresata i termin odpowiedzi. Kontekst to model, strefa, poziom i element, którego dotyczy. Pytanie powinno dać się odpowiedzieć jednym zdaniem i zawierać warianty, jeśli są potrzebne do decyzji.
Przykład pytania, które nadaje się do wysłania: „Czy dopuszczalne jest przejście kanału 800×400 przez ścianę REI 120 bez klapy ppoż. w strefie B na poziomie 2”. Przykład zapisu, który nie nadaje się do wysłania: „problem z wentylacją”. Drugi zapis wróci do nas z prośbą o doprecyzowanie i stracimy tydzień.
Termin odpowiedzi ustalamy przy zgłoszeniu, nie po tygodniu. Jeśli adresat nie odpowie, sprawa wraca na spotkanie jako punkt otwarty z nowym terminem albo decyzją o obejściu. Zamknięcie RFI wymaga zapisanej odpowiedzi w arkuszu, nie ustnej na korytarzu. Odpowiedź ustna nie istnieje dla osoby, która dołączy do projektu za miesiąc.
Checklista ma kolumny: numer, data zgłoszenia, temat, pytanie, czego dotyczy, priorytet, zgłasza, adresat, termin odpowiedzi, status, odpowiedź i data zamknięcia. Numeracja jest wspólna z rejestrem decyzji, więc przy decyzji widzimy, na jakim RFI się opiera.
Obieg kolizji
Kolizje mają priorytety i zasada jest prosta: priorytet 1 blokuje projekt, priorytet 2 wymaga decyzji na najbliższym spotkaniu, priorytet 3 trafia do kolejki, a priorytet 4 to uwagi porządkowe. Bez priorytetu lista kolizji rośnie szybciej niż możliwość jej przejrzenia, a spotkanie zamienia się w czytanie kilkudziesięciu uwag po kolei.
Każda kolizja ma właściciela i zasadę zamykania. Zamyka ten, kto zgłosił, po sprawdzeniu w nowej rewizji modelu. Nie ten, kto miał czas, i nie prowadzący spotkanie. Dzięki temu uwaga nie wraca trzeci raz z tym samym opisem, a liczba otwartych kolizji faktycznie spada.
W pracy z BCF eksportujemy uwagi z widokami i komentarzami, a po rozwiązaniu wracamy do modelu i zamykamy temat w tym samym miejscu. Link do widoku jest wart więcej niż akapit w mailu, bo pokazuje geometrię, a nie opis geometrii. Osoba, która otwiera widok, widzi problem w dwie sekundy, a nie po przeczytaniu akapitu i wyobrażeniu sobie, o co chodziło.
Na spotkaniu przeglądamy kolizje z otwartego rejestru, nie z pamięci. Ekran z filtrem po priorytecie i fachu jest szybszy niż opowieść o tym, co się ostatnio działo. Jeśli rejestr i model się różnią, w pierwszej kolejności naprawiamy rejestr, bo inaczej kolejne spotkanie zacznie się od wyjaśniania rozbieżności.
Jak prowadzić spotkanie, żeby decyzje zapisywały się same
Dwie role: prowadzący pilnuje czasu i kolejności, notujący zapisuje. Nikt nie robi obu rzeczy naraz. Prowadzący, który sam notuje, przestaje pilnować czasu, a notatka i tak powstaje po spotkaniu, czyli z pamięci.
Każdy punkt kończy się jednym zdaniem: decyzja, działanie albo odłożenie z datą. Zdanie „omówiliśmy i wrócimy do tego” nie jest wynikiem punktu. Wrócimy kiedy, kto i przy jakiej okazji. Jeśli nie umiemy odpowiedzieć, to znaczy, że punkt nie jest skończony.
Nie wracamy do zamkniętych decyzji bez nowych danych. Nowe dane to nowy numer decyzji, która zastępuje poprzednią. Inaczej po trzech spotkaniach rejestr przestaje być wiarygodny, bo każda decyzja ma trzy wersje, a nikt nie wie, która obowiązuje.
Prowadzący nie musi być najlepszym specjalistą w pokoju. Musi być osobą, która pilnuje, żeby każdy punkt miał wynik i żeby nikt nie wyszedł ze spotkania z wrażeniem, że ustalono coś innego niż zapisano. To cała rola.
Paczka do pobrania
Wszystkie pliki są w jednej paczce ZIP: agenda w wersji do edycji i do druku, notatka ze spotkania, rejestr decyzji z checklistą RFI oraz jednostronicowa instrukcja użycia. Pliki otwierają się w Wordzie i Excelu, nie wymagają makr ani dodatkowych narzędzi.
- Paczka ZIP: agendy, notatka, rejestr decyzji i instrukcja
- Agenda spotkania koordynacyjnego na 60 minut (docx)
- Notatka ze spotkania (docx)
- Rejestr decyzji i checklista RFI (xlsx)
Kolejność pracy jest zawsze taka sama: dzień wcześniej agenda, w trakcie spotkania notatka, do 24 godzin rejestr decyzji, na bieżąco checklista RFI. Instrukcja w paczce opisuje to w czterech krokach, z informacją, co robimy i kiedy.
Czego szablony nie robią: nie zastąpią modelu, CDE ani wspólnego widoku kolizji. Porządkują ustalenia, ale nie sprawdzają, czy ktoś faktycznie przesunął kanał. Dlatego każda decyzja ma termin wdrożenia i osobę, a status wracamy sprawdzić na następnym spotkaniu.
Podsumowanie
Spotkanie koordynacyjne nie wygrywa się liczbą slajdów. Wygrywa się tym, że po godzinie każdy wie, co ustalono, kto to robi i do kiedy. Agenda, notatka i rejestr to trzy narzędzia, które sprawiają, że te trzy pytania mają odpowiedź, a nie tylko poczucie, że rozmawialiśmy.
Pobierz paczkę, wypełnij agendę na najbliższe spotkanie i sprawdź po tygodniu, czy notatka nadal jest zrozumiała. Jeśli tak, masz działający proces. Jeśli nie, popraw szablon, nie zespół.
Sprawdź również:
- Dane nieszablonowe w budownictwie: jak wyciągnąć dane z maili, notatek i PDF-ów
- Jaki komputer do Revita/BIM w 2026: CPU/GPU/RAM/SSD
- Case Study: jak uporządkować wiele skrzynek mailowych w jednym systemie (Thunderbird + AI)
- Chińskie modele AI: co dzieje się z danymi, które do nich wysyłasz
- Jak zwiększyć komfort pracy przy komputerze? Ergonomiczne stanowisko krok po kroku
Treść tego artykułu została stworzona z pomocą sztucznej inteligencji.
