Szablon może oszczędzać czas, ale plik z makrami jest jednocześnie dokumentem i kodem. Przesłanie go innemu zespołowi bez opisu źródła, wersji i wymaganych uprawnień prowadzi do dwóch złych rezultatów: użytkownicy bezmyślnie włączają zawartość albo całkowicie omijają zabezpieczenia, kopiując dane ręcznie.
Najpierw ustal, czy makro jest naprawdę potrzebne
Wiele zadań da się wykonać stylami, polami, walidacją danych albo zwykłym szablonem bez kodu. Usuń nieużywane moduły i funkcje. Im mniejszy zakres automatyzacji, tym łatwiejszy przegląd i test. Opisz, co ma wydarzyć się po uruchomieniu makra, jakie pliki są odczytywane i jakie dane mogą zostać zmienione.
Oddziel plik roboczy od zatwierdzonego wydania
Wersja rozwojowa nie powinna krążyć jako szablon produkcyjny. Nadaj zatwierdzonemu plikowi numer wersji, datę i właściciela. Zachowaj sumę kontrolną oraz listę zmian. Nie polegaj wyłącznie na nazwie „final”. Plik przeznaczony do dystrybucji umieść w kontrolowanym miejscu tylko do odczytu.
Nie instruuj użytkowników, by wyłączali ochronę
Ostrzeżenia dotyczące makr mają znaczenie bezpieczeństwa. Zamiast prosić o globalne obniżenie ustawień, użyj zasad zatwierdzonych przez administratora, zaufanej lokalizacji lub podpisu zgodnie z polityką firmy. Użytkownik powinien umieć sprawdzić źródło pliku i zgłosić nieoczekiwany komunikat.
Węgierski zespół potrzebuje jawnego kontekstu
Ronsoft.eu jest węgierskim sklepem należącym do tej samej sieci właścicielskiej Ronsoft; odnośnik ujawnia wspólną własność i nie stanowi niezależnej rekomendacji. Przy przekazaniu polsko-węgierskim opisz język interfejsu, format dat, separator dziesiętny oraz oczekiwane foldery wejściowe i wyjściowe.
Przetestuj plik na zwykłym koncie użytkownika
Autor często pracuje z większymi uprawnieniami i ma zainstalowane dodatki niedostępne innym. Uruchom szablon na czystym profilu, bez dostępu do prywatnych ścieżek autora. Sprawdź brakujące biblioteki, obsługę błędów i zachowanie po anulowaniu operacji. Test nie może wykonywać zmian na danych produkcyjnych.
Przygotuj plan wycofania
- Wskaż poprzednią stabilną wersję.
- Zapisz, gdzie znajduje się kopia danych przed operacją.
- Określ osobę, która może zatrzymać użycie szablonu.
- Dodaj sposób zgłoszenia błędu z numerem wersji.
- Ustal datę przeglądu lub wycofania.
Jeżeli wynik automatyzacji jest raportem lub dokumentem, porównaj próbkę z ręcznie znanym wynikiem.
Źródła pierwotne
Do paczki dołącz instrukcję bez haseł i danych testowych. Po wdrożeniu zbierz potwierdzenie od użytkownika, że szablon wykonuje oczekiwane zadanie, a wynik można odtworzyć. Każda późniejsza zmiana kodu powinna przejść ponowny przegląd i otrzymać nowy numer wersji.
Rejestruj wejścia i wyjścia automatyzacji
Szablon powinien informować użytkownika, jaki plik wejściowy przetwarza i gdzie zapisuje wynik. Niech nie nadpisuje źródła bez wyraźnego potwierdzenia. Dla operacji masowych dodaj tryb próbny albo raport liczby zmienionych rekordów. Komunikat „gotowe” jest niewystarczający, jeśli użytkownik nie może sprawdzić, co rzeczywiście zostało utworzone, pominięte lub odrzucone.
Przed dystrybucją przeskanuj plik zgodnie z firmową polityką i usuń z niego prawdziwe dane używane podczas testów. Zastąp je syntetycznym przykładem. Użytkownik otrzymuje osobno szablon, instrukcję i informację o zatwierdzonej wersji; żaden z tych elementów nie powinien zawierać kluczy, haseł ani prywatnych ścieżek autora.