Pierwszy kontakt z Dynamo często zaczyna się od efektownego filmu. Kilka połączonych węzłów tworzy geometrię albo zmienia setki elementów. Łatwo wtedy zadać pytanie: co mogę zrobić w Dynamo? Problem polega na tym, że odpowiedzi jest bardzo dużo, a większość nie dotyczy Twojego codziennego projektu. Lepszy początek brzmi: która czynność zabiera mi dużo czasu i regularnie ją powtarzam? Takie pytanie prowadzi do zadania, którego wartość można później zmierzyć.
W tym artykule nie budujemy uniwersalnego skryptu. Przygotowujemy sposób myślenia, który pomaga wybrać dobry pierwszy projekt automatyzacji. Przykładem będzie sprawdzanie i uzupełnianie kodów elementów na podstawie uzgodnionej tabeli. Wszystkie opisywane wyniki są scenariuszami edukacyjnymi, a nie deklaracjami oszczędności osiągniętych u konkretnego klienta. Podejście można zastosować również do arkuszy, widoków oraz kontroli danych.
1. Znajdź powtarzalne zadanie
Przez kilka dni zapisuj czynności, które wykonujesz wielokrotnie. Zanotuj częstotliwość, czas pojedynczego wykonania i to, co wywołuje potrzebę pracy. Nie wystarczy wpis „uzupełnianie modelu”. Lepszy opis to „po otrzymaniu nowej tabeli producenta sprawdzam kod produktu w dwustu elementach”. Wtedy wiadomo, jakie dane uruchamiają proces i gdzie może pojawić się powtarzalność.
Wybierz zadanie o jasnym początku oraz końcu. Dobrym kandydatem jest raport pustych parametrów. Trudniejszym pierwszym projektem będzie automatyczna ocena jakości całego modelu, bo takie pojęcie obejmuje wiele reguł oraz decyzji projektowych. Wąski zakres pozwala szybko wykryć pomyłki i pokazać użytkownikowi wynik, który rozumie. Mały działający proces daje więcej informacji niż duża demonstracja bez kryteriów odbioru.
2. Opisz proces ręczny
Zapisz kroki tak, jakby miał je wykonać nowy pracownik. Otwórz model, wybierz kategorię, odczytaj nazwę typu, znajdź odpowiadający jej kod w tabeli i sprawdź aktualną wartość. Jeżeli kod jest pusty, przygotuj zmianę. Jeżeli różni się od tabeli, zgłoś rozbieżność. Już ten opis pokazuje, że pusty parametr i istniejąca inna wartość nie muszą być traktowane identycznie.
Zapytaj, które decyzje wynikają z zasad, a które z doświadczenia projektanta. „Wpisz właściwy kod” nie jest kompletną regułą. Trzeba ustalić, która tabela jest obowiązująca i jak rozpoznać właściwy rekord. Jeśli dwie pozycje mają tę samą nazwę, ale różne kody, automatyzacja nie powinna zgadywać. Oznacza to potrzebę lepszego identyfikatora albo osobnej listy wyjątków do ręcznego rozstrzygnięcia.
3. Zdefiniuj dane wejściowe
Przygotuj małą tabelę z jednoznacznym kluczem i kodem produktu. Określ, czy kluczem jest parametr, identyfikator zewnętrzny, czy uzgodniona kombinacja pól. Sama nazwa widoczna w interfejsie bywa niewystarczająca, ponieważ użytkownik może ją zmienić. Zapisz, jak traktujesz spacje, wielkość liter, puste komórki i duplikaty. Te decyzje powinny być świadome, ponieważ normalizacja danych może zmienić znaczenie kodu.
Po stronie modelu ustal kategorię oraz zakres: wszystkie elementy, aktywny widok czy zaznaczenie. Sprawdź, czy parametr jest przypisany do typu, czy instancji. Zmiana parametru typu wpłynie na wszystkie wystąpienia tego typu, również poza zaznaczeniem. Przy danych liczbowych sprawdź jednostki. Tekst wyglądający jak liczba i rzeczywista wartość liczbowa nie zawsze będą obsługiwane w ten sam sposób.
4. Określ oczekiwany wynik
Dobry wynik nie ogranicza się do komunikatu „gotowe”. Przygotuj listę elementów rozpatrzonych, zmienionych, pominiętych i wymagających decyzji. W przykładzie kodów raport powinien podawać identyfikator elementu, wartość starą, proponowaną i powód pominięcia. Użytkownik musi móc odnaleźć konkretny przypadek w modelu. Dzięki temu automatyzacja staje się procesem możliwym do sprawdzenia, a nie nieprzejrzystą operacją masową.
Ustal kryterium odbioru przed budową. Na przykład: wszystkie elementy z jednoznacznym dopasowaniem i pustym kodem otrzymują proponowaną wartość, natomiast brak dopasowania nie powoduje zapisu. Powtórne uruchomienie na tych samych danych nie powinno tworzyć kolejnych zmian. To szczególnie istotne przy numerowaniu i tworzeniu arkuszy. Bez takiej zasady użytkownik może bać się ponownie otworzyć narzędzie.
5. Zbuduj najpierw odczyt
Uruchom Dynamo w uzgodnionej wersji Revit i rozpocznij od trybu ręcznego. Pierwsza wersja powinna tylko pobierać dane oraz pokazywać planowane działania. Rozdziel pobieranie elementów, odczyt parametrów, dopasowanie rekordów i raport. Nie włączaj zapisu do modelu, dopóki lista proponowanych zmian nie zgadza się z ręcznie sprawdzoną próbką. To prosty sposób ograniczenia skutków błędnej reguły.
Wizualny graf uporządkuj od wejścia do wyniku. Używaj nazw grup, które opisują zadanie, a nie tylko numer etapu. „Kontrola pustych kodów” mówi więcej niż „Grupa 3”. Dodaj notatki o założeniach i wersjach. Dokumentacja Dynamo opisuje grupowanie i czytelność grafów; w praktyce najważniejsze jest, by druga osoba mogła wskazać miejsce pobierania danych oraz miejsce ich modyfikacji bez zgadywania.
6. Kontroluj listy i powiązania danych
W Dynamo wiele problemów wynika z kształtu list. Lista elementów i lista kodów muszą nadal opisywać te same pary. Jeśli usuniesz puste wartości tylko z jednej listy, pozostałe pozycje mogą przesunąć się względem siebie. Wynik będzie technicznie poprawnym tekstem zapisanym w niewłaściwym elemencie. Taka pomyłka bywa trudniejsza do zauważenia niż czerwony komunikat błędu.
Na małej próbce sprawdź liczby pozycji i relacje między rekordami. Zachowuj identyfikator razem z danymi opisującymi element. Testuj przypadki bez wyniku oraz z kilkoma dopasowaniami. Nie spłaszczaj zagnieżdżonych list tylko po to, aby zniknął problem węzła. Najpierw ustal, co oznacza każdy poziom: kategorię, typ, instancję czy zestaw wyników. Struktura danych jest częścią rozwiązania.
7. Dodaj zapis i obsługę wyjątków
Dopiero po sprawdzeniu odczytu przygotuj modyfikację. Pracuj na kopii modelu testowego. Osobno sprawdzaj parametry tylko do odczytu, brak parametru, elementy z modeli podłączonych i ograniczenia środowiska współdzielonego. Nie każdy element widoczny na ekranie jest bezpośrednio edytowalny. Skrypt powinien jasno zgłaszać pominięcie, a nie udawać, że cały zakres zakończył się sukcesem.
Nie obiecuj, że dowolny skrypt da się zawsze wycofać jednym kliknięciem. Ustal sposób zabezpieczenia i odtworzenia danych odpowiedni do zadania. Przy prostej zmianie parametrów przydatny jest zapis poprzednich wartości. Przy tworzeniu wielu elementów potrzebny będzie także sposób rozpoznania tego, co utworzyło narzędzie. Procedura powrotu do poprzedniego stanu powinna być częścią testu, a nie dopiskiem po pierwszym błędzie.
8. Sprawdź narzędzie z przyszłym użytkownikiem
Przygotuj zestaw przypadków: poprawny rekord, pusty klucz, duplikat, nieznany kod, brak parametru i ponowne uruchomienie. Poproś użytkownika, aby przeprowadził zadanie na podstawie krótkiej instrukcji. Obserwuj, gdzie musi dopytywać. Jeżeli nie wie, jaką kategorię wybrać albo gdzie znaleźć raport, to jest problem wdrożenia, nawet gdy sam graf działa zgodnie z założeniami.
Zapisz wersję Revit, Dynamo i dodatkowych pakietów. Ogranicz liczbę zależności tam, gdzie nie przynoszą wyraźnej korzyści. Po aktualizacji środowiska powtórz testy na próbce. Skrypt nie staje się bezobsługowy tylko dlatego, że raz się uruchomił. Ustal osobę odpowiedzialną za utrzymanie i miejsce przechowywania aktualnej wersji, aby w zespole nie krążyły różne pliki o podobnych nazwach.
9. Zmierz rzeczywistą zmianę
Porównaj pełny czas zadania przed i po wdrożeniu. Uwzględnij przygotowanie danych, uruchomienie, kontrolę wyniku i obsługę wyjątków. Sam czas pracy grafu nie jest całym czasem użytkownika. Jeżeli ręcznie pracujesz trzydzieści minut, a skrypt działa minutę i wymaga dziesięciu minut kontroli, oszczędność wynosi dziewiętnaście minut, nie dwadzieścia dziewięć. Taki wynik nadal może uzasadniać wdrożenie.
Zacznij od jednego procesu, opisz jego granice i sprawdź, czy ludzie faktycznie z niego korzystają. Dopiero później dodawaj kolejne funkcje. Automatyzacja jest wartościowa wtedy, gdy usuwa regularny problem, zachowuje kontrolę nad danymi i daje wynik możliwy do zweryfikowania. Liczba węzłów oraz efektowny wygląd grafu nie są miarą jakości. Najlepszym pierwszym krokiem pozostaje dobrze opisane zadanie.
Dalsza lektura: Dynamo Primer — Graph Strategies.
Przygotuj krótką kartę zadania
Przed rozmową o wdrożeniu zbierz pięć informacji w jednym dokumencie. Opisz obecne kroki, częstotliwość zadania, źródło danych, oczekiwany rezultat i znane wyjątki. Dołącz małą próbkę z poprawnym wynikiem wykonanym ręcznie. Taki materiał pozwala porównać propozycje rozwiązań bez dyskusji o przypadkowych funkcjach. Zapisz też, czego pierwsza wersja nie obejmuje: innych kategorii, nietypowych parametrów albo dodatkowych formatów tabel. Jasne granice ułatwiają ocenę, czy błąd dotyczy narzędzia, czy zadania wykraczającego poza uzgodniony zakres. Po pilotażu wróć do tej karty i uzupełnij rzeczywiste czasy oraz uwagi użytkowników. Dopiero wtedy zdecyduj, które kolejne funkcje przyniosą największą wartość. Nie rozszerzaj automatyzacji wyłącznie dlatego, że technicznie można połączyć jeszcze kilka węzłów. Zachowaj prosty sposób uruchamiania i wynik, który da się sprawdzić.
