Checklisty analityka biznesowego

Te checklisty służą do przeglądu materiału przed ważnym przekazaniem: rozpoczęciem analizy, warsztatem, realizacją wymagania, akceptacją diagramu lub użyciem AI. Odpowiedź „nie” nie oznacza automatycznie błędu — wskazuje punkt wymagający świadomej decyzji.

1. Checklista rozpoczęcia analizy

• ☐ Problem jest opisany za pomocą faktów lub obserwowalnych skutków, a nie tylko propozycji funkcji.
• ☐ Wiadomo, kto jest właścicielem potrzeby i kto może podejmować decyzje zakresowe.
• ☐ Zapisano oczekiwany rezultat biznesowy oraz sposób jego pomiaru.
• ☐ Określono użytkowników, klientów i inne grupy dotknięte zmianą.
• ☐ Znany jest proces lub moment, w którym pojawia się problem.
• ☐ Zebrano istniejące dane, regulacje, instrukcje, incydenty i wcześniejsze decyzje.
• ☐ Zakres wstępny ma jawne granice oraz listę elementów poza zakresem.
• ☐ Założenia są odróżnione od faktów i mają sposób weryfikacji.
• ☐ Ryzyka krytyczne, zależności i ograniczenia mają właścicieli.
• ☐ Ustalono, jaki artefakt i jaka decyzja zakończą etap analizy.

Jeśli pierwszym zdaniem jest „trzeba wdrożyć moduł”, wróć do poradnika jak opisać potrzebę biznesową.

2. Checklista jakości wymagania

• ☐ Wymaganie ma stabilny identyfikator i jednoznaczną nazwę.
• ☐ Jest powiązane z celem, potrzebą lub elementem procesu.
• ☐ Wskazuje aktora albo system odpowiedzialny za zachowanie.
• ☐ Opisuje wyzwalacz, oczekiwane zachowanie i rezultat.
• ☐ Nie ukrywa kilku niezależnych wymagań w jednym zdaniu.
• ☐ Pojęcia domenowe są zgodne ze słownikiem i używane konsekwentnie.
• ☐ Reguły biznesowe mają źródło oraz właściciela.
• ☐ Dane wejściowe, wynikowe i wymagane walidacje są nazwane.
• ☐ Scenariusze alternatywne, błędy i warunki brzegowe są rozpoznane.
• ☐ Zależności od innych wymagań, decyzji i integracji są widoczne.
• ☐ Ograniczenia niefunkcjonalne mają miarę, warunki pomiaru i próg.
• ☐ Kryteria akceptacji pozwalają rozstrzygnąć, czy realizacja jest poprawna.
• ☐ Biznes, realizacja i testy rozumieją treść w ten sam sposób.
• ☐ Wiadomo, kto zaakceptował wymaganie i która wersja obowiązuje.

Przy poważnym przeglądzie użyj również pytań z artykułu jak sprawdzać jakość wymagania.

3. Checklista kryteriów akceptacji

• ☐ Każde kryterium dotyczy jednego obserwowalnego rezultatu.
• ☐ Warunki początkowe i potrzebne dane są jednoznaczne.
• ☐ Akcja lub zdarzenie uruchamiające zachowanie jest wskazane.
• ☐ Wynik można sprawdzić bez interpretowania słów „szybko”, „łatwo” lub „poprawnie”.
• ☐ Uwzględniono co najmniej najważniejszy scenariusz negatywny.
• ☐ Progi liczbowe mają jednostkę i warunki pomiaru.
• ☐ Kryteria nie narzucają nieuzgodnionego sposobu implementacji.
• ☐ Zestaw kryteriów nie przeczy regułom biznesowym ani diagramowi procesu.
• ☐ Tester potrafi na ich podstawie przygotować przypadki testowe.
• ☐ Właściciel biznesowy potrafi na ich podstawie zaakceptować rezultat.

Zobacz też przykłady w materiale jak opisać kryteria akceptacji.

4. Checklista przed warsztatem analitycznym

• ☐ Cel mówi, co ma być ustalone lub wytworzone po spotkaniu.
• ☐ Zakres da się omówić w dostępnym czasie.
• ☐ Lista uczestników obejmuje wiedzę wykonawczą, decyzyjność i perspektywę odbiorcy.
• ☐ Każdy uczestnik wie, po co jest zaproszony i czego się od niego oczekuje.
• ☐ Materiały wejściowe wysłano z terminem pozwalającym na przygotowanie.
• ☐ Agenda wskazuje technikę, czas i rezultat każdego bloku.
• ☐ Wiadomo, kto facylituje, kto zapisuje i kto podejmuje decyzje.
• ☐ Przygotowano wspólną przestrzeń roboczą oraz parking tematów.
• ☐ Prowadzący zna główne konflikty, ograniczenia i pytania otwarte.
• ☐ Zaplanowano sposób podsumowania, akceptacji i follow-upu.

Pełna agenda i dobór technik znajdują się na stronie warsztat analityczny.

5. Checklista po warsztacie

• ☐ Decyzje są zapisane osobno od komentarzy i luźnych propozycji.
• ☐ Każda decyzja ma właściciela, datę, kontekst i konsekwencje.
• ☐ Pytania otwarte mają osobę odpowiedzialną oraz termin.
• ☐ Ryzyka i założenia nie zostały przedstawione jako fakty.
• ☐ Artefakty robocze są czytelne dla osoby nieobecnej na spotkaniu.
• ☐ Zmiany przeniesiono do wymagań, procesu, backlogu lub rejestru decyzji.
• ☐ Uczestnicy otrzymali podsumowanie i termin na zgłoszenie korekt.
• ☐ Sprzeczne uwagi mają wskazaną ścieżkę rozstrzygnięcia.
• ☐ Następny krok ma właściciela i termin.
• ☐ Obowiązuje jedno miejsce przechowywania finalnych ustaleń.

6. Checklista diagramu BPMN

• ☐ Model ma opisany cel, zakres i odbiorców.
• ☐ Początek wskazuje konkretne zdarzenie uruchamiające proces.
• ☐ Zakończenia nazywają rezultat biznesowy, a nie tylko „koniec”.
• ☐ Każde zadanie ma wykonawcę i nazwę czasownikową.
• ☐ Pule, tory, przepływy sekwencji i komunikaty są użyte zgodnie ze znaczeniem.
• ☐ Bramki mają właściwy typ, warunki wyjścia i poprawne połączenie ścieżek.
• ☐ Pokazano istotne wyjątki, powroty, oczekiwanie oraz przekroczenia czasu.
• ☐ Poziom szczegółowości jest spójny na całym diagramie.
• ☐ Model AS-IS odzwierciedla realną pracę, nie tylko procedurę.
• ☐ Model TO-BE wskazuje zmiany odpowiedzialności i nowych reguł.
• ☐ Zadania systemowe, dane i decyzje mają powiązane wymagania.
• ☐ Model został przejrzany z wykonawcami procesu i zespołem realizacyjnym.

Znaczenie elementów i pełny przykład omawia filar BPMN i procesy.

7. Checklista dokumentacji przed publikacją

• ☐ Dokument wskazuje cel, zakres, odbiorców i aktualny status.
• ☐ Tytuł, wersja, data i właściciel są widoczne.
• ☐ Obowiązujące ustalenia da się odróżnić od propozycji oraz treści historycznej.
• ☐ Linki i identyfikatory prowadzą do właściwych wersji artefaktów.
• ☐ Terminy domenowe są rozwinięte lub prowadzą do słownika.
• ☐ Tabele, diagramy i przykłady mają podpis oraz kontekst.
• ☐ Dane osobowe, poufne i przykładowe są oznaczone oraz właściwie chronione.
• ☐ Powtórzenia nie tworzą dwóch źródeł prawdy.
• ☐ Historia zmian opisuje zmianę znaczenia, nie tylko datę edycji.
• ☐ Odbiorca wie, jak zgłosić błąd lub zaproponować zmianę.

8. Checklista użycia AI w analizie

• ☐ Narzędzie jest zatwierdzone do klasy przetwarzanych informacji.
• ☐ Materiał ograniczono do niezbędnego zakresu i zanonimizowano, gdy to możliwe.
• ☐ Cel, format wyniku i zakaz dopowiadania są zapisane w poleceniu.
• ☐ Model ma wskazywać dowód lub identyfikator źródła dla obserwacji.
• ☐ Brak danych ma być oznaczony, a nie uzupełniony prawdopodobnym założeniem.
• ☐ Wynik jest sprawdzany z materiałem źródłowym pozycja po pozycji.
• ☐ Reguły i decyzje zatwierdza właściwy właściciel, nie model.
• ☐ Zapisano zakres pomocy AI i osobę odpowiedzialną za finalną wersję.
• ☐ Mierzymy czas kontroli oraz poprawek, a nie tylko czas generowania.
• ☐ Istnieje bezpieczny wariant wykonania zadania bez AI.

Zasady, ryzyka i przykład polecenia są opisane w przewodniku AI w analizie biznesowej.

Rejestr wyników przeglądu

Punkt	Status	Dowód lub uwaga	Działanie	Właściciel	Termin
Wyjątki wymagania	Do wyjaśnienia	Brak zachowania po timeout API	Uzgodnić ponowienie i komunikat	Architekt + biznes	14 sierpnia