Jak uzyskać wymagania projektu od interesariuszy

Wprowadzenie

Zbieranie wymagań od interesariuszy projektu często przypomina wyrywanie zębów. A jeśli nie włożysz pracy w legalizację, aby spełnić wszystkie wymagania przed rozpoczęciem programowania w projekcie, skończysz z bardzo długą listą problemów podczas testów, które powinny zostać ujęte jako wymagania. Istnieje wiele sposobów prowadzenia rozmowy, aby zapewnić uchwycenie wszystkich wymagań w ramach projektu, takich jak zbieranie historyjek użytkowników, organizowanie sesji burzy mózgów, diagramowanie przepływów procesów i nie tylko. Niezależnie od tego, czy jesteś kierownikiem projektu, czy analitykiem biznesowym, ten artykuł przeprowadzi Cię przez niektóre z bardziej standardowych podejść do zbierania wymagań projektowych, aby upewnić się, że projekt rozpocznie się we właściwy sposób.

Historie użytkowników są często formułowane wokół roli zgłaszającego, czego chcą i dlaczego tego chcą.

Designmodo

Historie użytkownika

Niezależnie od tego, czy tworzysz coś zupełnie nowego, czy aktualizujesz istniejącą aplikację, pierwsza runda wymagań powinna być zawsze zapisywana w historiach użytkowników. Nie ma znaczenia, czy te historie pochodzą od użytkowników końcowych, czy interesariuszy, i możesz je zebrać od każdego. Celem jest uchwycenie ich oczekiwań co do tego, co ma zostać zbudowane, i szczegóły dotyczące tego, jak chcą, aby to działało. Istnieją różne formaty przechwytywania historyjek użytkowników, ale zazwyczaj wszystkie one rejestrują rolę związaną z żądającym, czego chce ta osoba i dlaczego tego chcą. Te historie będą musiały zostać rozwinięte w dalszej części procesu projektowego.

Sesje burzy mózgów

W sesjach burzy mózgów zazwyczaj uczestniczyli wszyscy zidentyfikowani interesariusze i niektórzy potencjalni użytkownicy końcowi, którzy spotykali się w jednym pomieszczeniu i przedstawiali swoje pomysły na temat wymagań projektu. Celem jest podtrzymanie dyskusji i skłonienie ludzi do rozmowy. Jeśli istnieją rozbieżności między wymaganiami, które zostały już omówione, a twoją interpretacją wymagań, przedstaw to grupie, aby się rozegrała. Ponieważ sesje te często przebiegają niezwykle szybko, najlepiej jest nagrywać rozmowę lub mieć oddanego skrybę, abyś mógł skupić się na byciu aktywnym uczestnikiem, zamiast wiązać się, próbując uchwycić wszystko. Jeśli pójdziesz tą drogą, nierzadko zdarza się, że masz więcej niż jedną sesję, aby upewnić się, że wszystko zostanie omówione.

Podczas gdy sesje burzy mózgów są świetne, jeśli chodzi o otwarcie wszystkich wymagań i prowadzenie rozmowy wokół nich, uporządkowanie wszystkiego po jednym z takich spotkań może być bolesne, biorąc pod uwagę ilość informacji.

PM Alliance

Przejrzyj sesje

Kontynuuj przedstawianie wymagań interesariuszom projektu w celu ich przeglądu i nie lekceważ czasu, jaki może zająć grupie osiągnięcie porozumienia co do wszystkich wymagań projektu. Nierzadko rozmowa na temat małego projektu może zająć kilka tygodni. Jednym ze sposobów jest zaczekanie, aż wszyscy ustnie potwierdzą wymagania, a następnie odczekanie kilku dni, zanim wrócą do wszystkich, aby uzyskać ich podpis na formalnym dokumencie, w którym można poprosić ich o ponowne szybkie sprawdzenie - po prostu aby być po bezpiecznej stronie. Innym podejściem jest poproszenie kogoś innego w biznesie o wiedzę na temat tego, co robisz, aby przejrzał wymagania, aby upewnić się, że wszystko wydaje się tak szczelne, jak to tylko możliwe.

Co należy uwzględnić w tygodniowym raporcie o stanie projektu

Diagramowanie procesów

Diagram procesów polega na tym, że gromadzisz cały zespół razem i przechodzisz przez przepływ każdego ze zidentyfikowanych procesów, które będą częścią projektu. Zmusza to interesariuszy do przemyślenia każdego kroku w żądanej aplikacji i często ujawnia nowe wymagania, których nikt wcześniej nie brał pod uwagę. Dane wyjściowe tych sesji służą również jako fantastyczne dane wejściowe do tworzenia szkieletów.

Ciągle pytaj dlaczego

Pytanie, dlaczego jest potężnym kierowcą podczas rozmów o wymaganiach, a konkretne, jasne wymagania nie zostaną rzetelnie przedstawione, dopóki nie będzie już miało sensu zadawać tego pytania. Zmusza interesariuszy do przemyślenia szczegółowych składników ich początkowych wymagań, co może być bolesne i czasochłonne. Ponadto czasami ciągłe pytanie może ostatecznie ujawnić coś, co początkowo uważano za wymaganie, które wcale nie musi być wymaganiem.