Zbieranie wymagań: kompletny przewodnik & szablon

Te oczekiwania stają się listą wymagań dla projektu. Stopień realizacji wymagań będzie decydować o tym, czy przedsięwzięcie zostanie uznane za udany projekt. 

Kierownicy projektów korzystają z dokumentów wymagań i narzędzi do zarządzania wymaganiami, aby śledzić następujące rodzaje wymagań przez cały czas trwania projektu:

• Wymagania funkcjonalne
• Wymagania techniczne
• Wymagania niefunkcjonalne
• Wymagania systemowe

Uwaga na marginesie:

Zbieranie wymagań nie ogranicza się do okresu poprzedzającego produkcję. Dokumentacja zmian, dokumentacja gwarancyjna itp. to przydatne formy bieżącej dokumentacji wymagań, które ujawniają nowe wymagania w trakcie realizacji projektu — a nawet po jego zakończeniu!

 

Dopóki współpracujesz z klientem, dokumentacja stale się rozrasta i ewoluuje.

Dlaczego zbieranie wymagań jest ważne?

Zbieranie wymagań jest ważne z następujących powodów (podobnie jak dokumentowanie tych wymagań): 

1. Służy jako punkt odniesienia do dokumentowania rozwoju projektu, jego zmiennych elementów i wdrożenia 
2. Służy jako plan dla interesariuszy projektu, który pozwala im lepiej zrozumieć, czego mogą oczekiwać od projektu (co, gdzie, kiedy i dlaczego w projekcie).
3. Ogranicza możliwość wystąpienia błędów i niejasności, ponieważ wymagania są jasno udokumentowane i uzgodnione przed rozpoczęciem prac.
4. Zapewnia mechanizmy kontroli i równowagi w trakcie realizacji projektu i kontroli jakości, umożliwiając kierownikom projektu oraz członkom zespołu odwołanie się do dokumentacji zawsze, gdy pojawiają się wątpliwości dotyczące dalszego postępowania.

Oprócz określenia tego, czego można oczekiwać, skuteczne planowanie zarządzania wymaganiami powinno również wskazywać, czego nie należy oczekiwać. Uwzględnienie sekcji „Założenia” i/lub „Wykluczenia” to rozsądne podejście, które eliminuje ryzyko związane z budzącą grozę wyobraźnią klienta. 

Przykład specyfikacji wymagań dotyczących oprogramowania

Oto przykładowa specyfikacja wymagań dla projektu handlu elektronicznego:

• Co: Integracja z PayPal
• Gdzie: Płatność
• Kiedy: W 3. z 4 kroków procesu płatności (po formularzu adresu wysyłki, przed potwierdzeniem)
• Dlaczego: W tym przypadku gotowa integracja (np. PayPal) jest lepszym rozwiązaniem niż rozbudowana niestandardowa integracja usługi płatniczej, ponieważ z łatwością spełnia wymagania biznesowe.

• Założenia
  • Stała opłata za całą wysyłkę i obsługę
  • Cała wysyłka odbywa się na terenie Stanów Zjednoczonych (z wyłączeniem Alaski i Hawajów)
  • Podatki nie mają zastosowania
• Wykluczenia 
  • Niestandardowe obliczenia opłat za wysyłkę i obsługę
  • Wysyłka międzynarodowa, na Alaskę lub Hawaje
  • Zasady podatkowe

Pamiętaj: im mniejsza różnica między oczekiwaniami klienta a rzeczywistością dotyczącą jego produktu cyfrowego, tym bardziej klient będzie zadowolony z efektu końcowego. Jakość zarządzania wymaganiami bezpośrednio koreluje z Twoją zdolnością jako kierownika projektu do ograniczania wszelkich szarych stref, jeśli chodzi o oczekiwania klienta. 

W zdecydowanej większości przypadków klient zaakceptuje ograniczenie rozszerzania zakresu, jeśli oznacza to ochronę jego budżetu; jeśli odpowiednio wyjaśnisz klientowi, dlaczego dana funkcja zostanie zrealizowana (lub nie) i następnie udokumentujesz uzasadnienie takiego podejścia w wymaganiach, klient będzie znacznie bardziej skłonny do współpracy. 

Z większym prawdopodobieństwem udzieli zgody, a później, podczas przeprowadzania testów akceptacji użytkownika (UAT), będzie już lepiej rozumiał „dlaczego” stojące za rozwiązaniem Twojego zespołu.

6-etapowy proces zbierania wymagań

Chociaż zbieranie wymagań powinno rozpocząć się wraz z rozpoczęciem współpracy i trwać przez cały cykl życia projektu, na rozpoczęcie zbierania i dokumentowania wymagań nigdy nie jest za wcześnie. Właściwie zacznij już wczoraj.

Oto kroki dotyczące zbierania wymagań.

1. Rób notatki

Podczas każdego spotkania, w którym uczestniczysz — niezależnie od tego, czy jest to spotkanie wewnętrzne z zespołem projektowym, czy zewnętrzne z klientem — zawsze rób notatki. Nigdy nie zakładaj, że ktoś inny je robi.

W danym momencie łatwo założyć, że wszystko, co jest omawiane, zostanie zapamiętane, ale po 3 miesiącach i 15 spotkaniach Twój zespół oraz klient będą Ci wdzięczni za zachowanie zapisu tych rozmów, do którego można będzie wrócić.

Zapoznaj się tutaj z niektórymi zalecanymi przeze mnie procedurami dotyczącymi sporządzania notatek z wymagań:

• Przed spotkaniem przygotuj dokument z notatkami tak, aby odzwierciedlał agendę, dzięki czemu łatwiej będzie uporządkować zadania i omawiane punkty. W ten sposób zapamiętasz, co jest potrzebne, jednocześnie rejestrując powiązane informacje w uporządkowany sposób. 
• Po każdym spotkaniu zaplanuj dla siebie 15–30 minut na przejrzenie notatek, przyswojenie omówionych kwestii, ustalenie priorytetów zadań oraz identyfikację wyzwań, sygnałów ostrzegawczych lub potrzeby doprecyzowania bądź zorganizowania dodatkowych spotkań.
• Wyślij notatki do wewnętrznego zespołu projektowego. Poproś jego członków o sprawdzenie i potwierdzenie zidentyfikowanych przez Ciebie zadań, sygnałów ostrzegawczych itp. 
• Gdy zespół wyrazi swoją aprobatę, wyślij notatki klientowi. 
• Na koniec wykorzystaj notatki jako punkt odniesienia przy tworzeniu zadań na podstawie poszczególnych elementów wymagających działania. Dodaj wszelkie nowe informacje do dokumentacji wymagań i zaplanuj wszystkie potrzebne spotkania dotyczące dalszego rozpoznania lub dyskusji. 

Stay Ahead of What Deserves Your Attention

Get timely perspective on the shifts, decisions, and trade-offs shaping your role, plus practical resources you can put to work.

Get Free Access

Have an account? Log In

2. Przejrzyj wymagania kreatywne

Nie pozostawiaj decyzji dotyczących projektu i stylizacji poszczególnym członkom zespołu: w miarę możliwości skodyfikuj wymagania kreatywne. Wytyczne kreatywne są nieocenione dla programistów. Przynajmniej upewnij się, że masz pod ręką przewodnik po stylu — nawet jeśli obejmuje on tylko podstawowe informacje, takie jak czcionka i kolory marki.

Zbierz wszystkie zasoby kreatywne, takie jak logotypy marki lub czcionki marki, i prześlij je do współdzielonej przestrzeni (na przykład do oprogramowania do zarządzania zasobami cyfrowymi), aby zapewnić całemu zespołowi dostęp i widoczność.

3. Napisz dokument wymagań

Gdy zagłębiasz się w dokumentację, pamiętaj: pierwsze podejście do dokumentowania wymagań będzie najtrudniejsze. Dlaczego? Ponieważ nie masz wcześniejszego dokumentu, który można wykorzystać (czyli KOPIUJ-WKLEJ). Na szczęście ten artykuł zawiera szablon dokumentacji wymagań, który może posłużyć Ci jako podstawa.

Jak pokazano w tym szablonie, dzielę dokumentację wymagań na cztery części:

1. Adnotacja: Zawiera numery z opatrzonego adnotacjami projektu. Jeśli projekt strony zawiera 8 elementów, będziesz mieć 8 adnotacji, a kolumna adnotacji będzie zawierać 8 wierszy
2. Element: Zawiera tytuły elementów odpowiadające poszczególnym adnotacjom
3. Wymaganie funkcjonalne: Zawiera definicję (szczegółowo opisane wymagania) dla każdego elementu
4. Funkcjonalność administracyjna/CMS: Zdefiniuj wszelkie funkcjonalności administracyjne i/lub CMS związane z odpowiednim elementem

4. Przeprowadź wewnętrzny przegląd

Na tym etapie procesu zbierania wymagań zaplanuj kolejne wewnętrzne spotkanie z zespołem projektowym, aby przejrzeć dokumentację wymagań. Jest to końcowa wewnętrzna kontrola mająca na celu upewnienie się, że prawidłowo rozumiesz sposób realizacji projektu.

Jeśli to możliwe, poproś zespół o przejrzenie dokumentacji wymagań przed spotkaniem, aby jego członkowie mogli przyjść przygotowani z pytaniami i/lub opiniami. Wykorzystaj spotkanie do omówienia wszelkich pytań lub opinii dotyczących wymagań.

Wprowadź wszelkie niezbędne poprawki do dokumentacji na podstawie wewnętrznej dyskusji. Na koniec ponownie wyślij poprawioną dokumentację wymagań zespołowi, aby uzyskać jego ostateczną akceptację. Po uzyskaniu ostatecznej zgody zespołu projektowego na dokumentację wymagań zapisz dokument w formacie PDF, aby zachować go w ostatecznej wersji na potrzeby kolejnego etapu: opracowania zadań. 

5. Opracuj zadania

Przekaż zespołowi programistycznemu wersję PDF dokumentacji wymagań. Najlepiej, jeśli programiści lub lider zespołu programistycznego opracują zadania związane z realizacją projektu. 

Niektóre organizacje mogą działać zgodnie z procesem, w ramach którego kierownicy projektów opracowują wszystkie zadania, jednak wolę, aby programiści opracowywali własne zadania; poświęcenie przez nich tych kilku godzin jest tego warte.

Nadal możesz przekazać zespołowi przydatne wytyczne dotyczące opracowywania zadań programistycznych i materiałów do dostarczenia. Po opracowaniu zadań będziesz w stanie uzyskać ostateczny szacunkowy nakład godzinowy.

Porównaj tę prognozę z harmonogramem projektu, który został wcześniej przekazany klientowi, i w razie potrzeby odpowiednio nim zarządzaj. Więcej informacji na temat szacowania projektów znajdziesz w tym kompletnym przewodniku po szacowaniu projektów.

6. Przeprowadź zewnętrzny przegląd

Nadszedł czas, aby przedstawić dokumentację wymagań klientowi. Przekaż ją w formacie PDF, aby uniemożliwić wprowadzanie zmian. Po pierwsze, pokazuje to Twoje zaangażowanie w zapewnienie klientowi zrozumienia rozwiązania cyfrowego, a po drugie, stanowi dla Ciebie zabezpieczenie, dzięki któremu będziesz mógł powiedzieć „a nie mówiłem” (choć znacznie bardziej elokwentnie), gdy nieuniknione rozszerzanie zakresu projektu da o sobie znać.

Przeszkol klienta. Przeprowadź go przez tę cenną dokumentację, którą tak pieczołowicie dla niego przygotowałeś. Pamiętaj: to klient jest ekspertem w swojej branży. Ty jesteś ekspertem w zakresie oferowanego mu rozwiązania cyfrowego. Klient płaci Ci za to rozwiązanie. Przeszkol go i daj mu poczucie sprawczości. 

Po potwierdzeniu przez klienta zrozumienia dokumentacji wymagań nadszedł czas na uzyskanie formalnej akceptacji. Wyślij podpisaną i zatwierdzoną dokumentację wymagań swojemu zespołowi i zapisz ją we wspólnej przestrzeni za pomocą oprogramowania do zarządzania dokumentami, aby formalnie potwierdzić, że można rozpocząć prace programistyczne.

Techniki zbierania wymagań

Oto kilka technik, które pomogą Ci jak najlepiej wykonać ważną pracę związaną ze zbieraniem wymagań:

1. Zacznij od razu

Dokumentowanie wymagań powinno rozpocząć się, gdy tylko rozpoczną się rozmowy — zanim dokładnie określisz plan projektu lub jego cele. Zapisuj wszystko, co możliwe, a następnie ogranicz zakres informacji do najważniejszych kwestii. Oto kilka strategii, które możesz wypróbować z klientem:

• Wyślij mu kwestionariusz dotyczący tego, co chciałby zobaczyć w projekcie
• Przeprowadź sesję burzy mózgów
• Zorganizuj grupę fokusową

Zamiast usuwać informacje z dokumentu, podziel je na kategorie: uwzględnione i nieuwzględnione — pozwoli to uniknąć późniejszych nieporozumień po stronie klienta.

Będzie można wyodrębnić dokumentację wymagań WIP (work in progress), wskazać, gdzie te informacje zostały zapisane, dlaczego mogą nie być uwzględnione, jaka logika stoi za tą decyzją oraz kiedy zostały zapisane, dzięki czemu będzie można prześledzić ich pochodzenie.

2. Korzystaj z szablonów

Gdy będziesz mieć już na koncie kilka dokumentów wymagań, zacznij je wykorzystywać i tworzyć na ich podstawie szablony do przyszłego użycia w innych projektach. Zwłaszcza jeśli koncentrujesz się na projektach e-commerce lub aplikacjach edukacyjnych, zaczniesz dostrzegać powtarzające się wzorce funkcjonalności. Zidentyfikuj elementy, które możesz ponownie wykorzystać. 

3. Współpraca zespołowa prowadzi do sukcesu

Jeśli w projekcie uczestniczą różne typy członków zespołu, wymagania dotyczące poszczególnych obszarów specjalizacji mogą być opracowywane przez odpowiednich ekspertów.

W wielu przypadkach rozmowa na temat wymagań to kręta ścieżka rozmów telefonicznych, różnych oddzielnych spotkań i rozmów itd. Dlatego tak ważne jest, aby w miarę prowadzenia procesu pozyskiwania i kompilowania wymagań przydzielać dokumentowanie wymagań odpowiednim członkom zespołu.

4. Nie tylko zapisuj wymagania — ucz się

Rób więcej niż tylko notatki. Oczekuj czegoś więcej niż wiadomości e-mail od osób dostarczających materiały, zawierających ścianę tekstu dotyczącą ich części wymagań. Poświęć czas na spotkanie z zespołem programistów i poznanie rozwiązań, które zespół planuje zastosować. Omów, dlaczego i w jaki sposób. Zadawaj pytania.

Zanim powiesz: „Ale przecież mamy tylko określoną ilość czasu w ciągu dnia — a co z budżetem?”, zrozum to: jeśli rozwiązanie, nad którym pracujesz, ma zastosowanie w więcej niż jednym projekcie, ten dodatkowy czas poświęcony na jego zrozumienie niekoniecznie musi być rozliczany. Rozwijasz swoją wiedzę dziedzinową, która bezpośrednio usprawnia Twoją codzienną pracę. 

5. Informuj klienta na bieżąco

Posiadaj zarówno wewnętrzny dokument wymagań, jak i przeznaczony dla klienta dokument wymagań WIP. W dokumencie wewnętrznym możesz mniej przejmować się dodawaniem bardziej przejrzystych notatek.

Jeśli nie masz do czynienia z poufnymi informacjami, możesz utworzyć tę wspólną przestrzeń w Dokumentach Google, włączając klientowi uprawnienia do dodawania komentarzy. Jeśli masz do czynienia z poufnymi informacjami, co tydzień udostępniaj wersję dokumentu wymagań, aby zapewnić klientowi obraz tego, co zostało zapisane.

6. Zakładaj, że klient zawsze chce wiedzieć więcej

Zamiast ryzykować założenie, że klient wie więcej, niż rzeczywiście wie — a później ponosić tego konsekwencje — zakładaj, że klient zawsze chce wiedzieć więcej. Przy każdej adnotacji zadaj sobie pięć razy pytanie „Dlaczego?”, aby zapewnić kompletność każdego wymagania. 

Zadawanie sobie pięć razy pytania „Dlaczego?” w odniesieniu do każdego wymagania zmusza Cię do rzeczywistego rozważenia logiki stojącej za każdym elementem i funkcjonalnością każdego typu strony. Możesz być zaskoczony tym, jak wiele się uczysz (lub uświadamiasz sobie, że musisz się nauczyć).

3 eksperckie wskazówki dotyczące tworzenia dokumentu wymagań projektu

1. Twórz wymagania dotyczące elementów globalnych oddzielnie

Aby wyeliminować powtórzenia, uwzględnij wszystkie elementy globalne w sekcji „Elementy globalne” dokumentacji wymagań. Dotyczy to takich elementów globalnych jak pozycje głównego menu nawigacyjnego, wszystkie elementy globalnego nagłówka oraz wszystkie elementy stopki. 

Po zapisaniu wymagań dotyczących tych elementów globalnych nie musisz dodawać do nich adnotacji na pozostałych stronach; dodawaj adnotacje wyłącznie do elementów charakterystycznych dla tych stron.

More Articles

• Wskazówki dotyczące budowania profilu na Slacku
• Jak opanować zarządzanie zasobami w zarządzaniu projektami

2. Kopiuj i wklejaj identyczne funkcjonalności, aby zapewnić spójność

To po prostu wskazówka, o której warto pamiętać dla zachowania zdrowia psychicznego Twojego i klienta. Najczęściej dotyczy to typowych elementów stron, takich jak obrazy główne lub banery, nagłówki albo ikony „wstecz” — wśród wielu powtarzających się funkcjonalności występujących w różnych typach stron (nie myl ich z elementami globalnymi). 

3. Uwzględnij panel administracyjny i system CMS (lub ich brak)

Gdy jesteśmy tak skupieni na funkcjonalności każdego elementu strony, łatwo pominąć funkcje administracyjne i/lub funkcje systemu CMS. Jeśli wdrażasz rozwiązanie oferujące funkcje administracyjne i/lub funkcje systemu CMS, pamiętaj, aby uwzględnić je jako osobną kolumnę w wymaganiach. Przykład poniżej:

Szablon dokumentu wymagań [Pobierz]

Szczegóły definicji wymagań będą zależeć od relacji z klientem, doświadczenia Twojego zespołu i innych czynników.

Nadal będziesz jednak potrzebować podstawowych elementów dokumentu wymagań projektowych, które określają funkcjonalność, lokalizację, wygląd i inne aspekty funkcji. Oto nasz szablon dokumentu wymagań (aby uzyskać do niego dostęp, musisz być członkiem):

Przyspiesz pracę dzięki ponad 100 szablonom premium

Zostań członkiem DPM i uzyskaj dostęp do niezliczonych szablonów stworzonych przez ekspertów, które pomogą Ci pracować szybciej i efektywniej.