Analiza biznesowa - wymagania Mngmt

Gromadzenie wymagań dotyczących oprogramowania jest podstawą całego projektu tworzenia oprogramowania. Pozyskiwanie i gromadzenie wymagań biznesowych to krytyczny pierwszy krok dla każdego projektu. Aby wypełnić lukę między wymaganiami biznesowymi i technicznymi, analitycy biznesowi muszą w pełni zrozumieć potrzeby biznesowe w danym kontekście, dostosować te potrzeby do celów biznesowych i odpowiednio komunikować potrzeby zarówno interesariuszom, jak i zespołowi programistycznemu.

Kluczowi interesariusze chcieliby, aby ktoś mógł wyjaśnić wymagania klienta / klienta prostym językiem angielskim. Czy skorzystają na tym, jeśli zrozumieją wartość na wysokim poziomie? Będzie to główny obszar zainteresowania, ponieważ będą starali się zmapować dokumentację z wymaganiami i jak BA może komunikować się w najlepszy możliwy sposób.

Dlaczego projekty zawodzą

Istnieje wiele powodów, dla których projekty kończą się niepowodzeniem, ale niektóre z obszarów wspólnych obejmują:

  • Awaria rynku i strategii
  • Błędy organizacyjne i planistyczne
  • Błędy jakościowe
  • Awarie przywództwa i zarządzania
  • Awarie umiejętności, wiedzy i kompetencji
  • Zaangażowanie, praca zespołowa i niepowodzenia w komunikacji

Istotą problemu jest to, że projekty są coraz bardziej złożone, zachodzą zmiany, a komunikacja jest trudna.

Dlaczego zespoły odnoszące sukcesy zarządzają wymaganiami

Zarządzanie wymaganiami polega na utrzymaniu zespołu in-sync i zapewnianie visibility do tego, co się dzieje w ramach projektu.

Kluczowe znaczenie dla powodzenia projektów ma cały zespół, aby zrozumieć, co tworzysz i dlaczego - tak definiujemy zarządzanie wymaganiami. „Dlaczego” jest ważne, ponieważ zapewnia kontekst dla celów, informacji zwrotnej i decyzji dotyczących wymagań.

Zwiększa to przewidywalność przyszłych sukcesów i potencjalnych problemów, umożliwiając Twojemu zespołowi szybkie rozwiązanie wszelkich problemów i pomyślne zakończenie projektu na czas iw ramach budżetu. Na początek cenne jest, aby wszyscy zaangażowani mieli podstawową wiedzę na temat wymagań i sposobów zarządzania nimi.

Zacznijmy od podstaw

Wymaganie to warunek lub zdolność potrzebna interesariuszowi do rozwiązania problemu lub osiągnięcia celu. Stan lub zdolność, które musi spełniać lub posiadać system lub system. Komponent do spełnienia warunków umowy, normy, specyfikacji lub innych formalnie narzuconych dokumentów.

Wymaganie można wyrazić za pomocą tekstu, szkiców, szczegółowych makiet lub modeli, wszelkich informacji, które najlepiej przekazują inżynierowi, co ma zbudować, a kierownikowi ds. Zapewnienia jakości, co ma przetestować. W zależności od procesu programowania możesz użyć innej terminologii do wychwycenia wymagań.

Wymagania wysokiego poziomu są czasami nazywane po prostu needs lub goals. W praktykach tworzenia oprogramowania wymagania mogą być określane jako „przypadki użycia”, „funkcje” lub „wymagania funkcjonalne”. Jeszcze dokładniej w ramach zwinnych metodologii programowania wymagania są często ujmowane jakoepics i stories.

Bez względu na to, jak nazywa je Twój zespół lub jakiego procesu używasz; wymagania są istotne dla rozwoju wszystkich produktów. Bez jasnego określenia wymagań możesz wyprodukować niekompletny lub wadliwy produkt. W trakcie procesu definiowania wymagań może być zaangażowanych wiele osób.

Interesariusz może zażądać funkcji opisującej, w jaki sposób produkt zapewni wartość w rozwiązaniu problemu. Projektant może zdefiniować wymaganie w oparciu o to, jak produkt końcowy powinien wyglądać lub działać z punktu widzenia użyteczności lub interfejsu użytkownika.

Analityk biznesowy może stworzyć wymaganie systemowe, które jest zgodne z określonymi ograniczeniami technicznymi lub organizacyjnymi. W przypadku dzisiejszych zaawansowanych produktów i tworzonych aplikacji często potrzeba setek lub tysięcy wymagań, aby wystarczająco zdefiniować zakres projektu lub wydania. Dlatego konieczne jest, aby zespół był w stanie uzyskać dostęp, współpracować, aktualizować i testować każde wymaganie aż do zakończenia, ponieważ wymagania naturalnie zmieniają się i ewoluują w czasie w trakcie procesu tworzenia.

Teraz, gdy zdefiniowaliśmy wartość zarządzania wymaganiami na wysokim poziomie, przejdźmy głębiej do czterech podstaw, które każdy członek zespołu i interesariusz może zyskać na zrozumieniu -

  • Planowanie dobrych wymagań: „Co u diabła budujemy?”
  • Współpraca i wpisowe: „Po prostu zaakceptuj specyfikację, już!”
  • Identyfikowalność i zarządzanie zmianą: „Czekaj, czy programiści wiedzą, że to się zmieniło?”
  • Zapewnienie jakości: „Witaj, czy ktoś to przetestował?”

Czy wszyscy wiedzą, co budujemy i dlaczego? Taka jest wartość zarządzania wymaganiami.

Współpraca i zaangażowanie ze strony interesariuszy

Czy wszyscy są na bieżąco? Czy mamy aprobatę co do wymagań, aby przejść dalej? Te pytania pojawiają się podczas cykli rozwojowych. Byłoby wspaniale, gdyby każdy mógł uzgodnić wymagania, ale w przypadku dużych projektów z wieloma interesariuszami zwykle tak się nie dzieje. Próba uzyskania zgody wszystkich może spowodować opóźnienie decyzji lub, co gorsza, jej brak w ogóle. Uzyskanie konsensusu w każdej decyzji nie zawsze jest łatwe.

W praktyce niekoniecznie chcesz „konsensusu”, chcesz „poparcia” ze strony grupy i zgody kontrolujących, aby móc posunąć projekt do przodu. W drodze konsensusu starasz się, aby wszyscy poszli na kompromis i zgodzili się na decyzję. Dzięki akceptacji próbujesz skłonić ludzi do poparcia najlepszego rozwiązania, podjęcia mądrej decyzji i zrobienia tego, co konieczne, aby iść naprzód.

Nie musisz wszyscy zgodzić się, że decyzja jest najlepsza. Potrzebujesz, aby wszyscy poparli tę decyzję. Współpraca zespołowa może pomóc w uzyskaniu wsparcia przy podejmowaniu decyzji i planowaniu dobrych wymagań.

Zespoły współpracujące ciężko pracują, aby upewnić się, że każdy ma udział w projektach i przekazuje informacje zwrotne. Zespoły współpracujące nieustannie dzielą się pomysłami, zazwyczaj mają lepszą komunikację i mają tendencję do wspierania podejmowanych decyzji, ponieważ istnieje wspólne poczucie zaangażowania i zrozumienia celów projektu.

Gdy programiści, testerzy lub inni interesariusze czują się „poza pętlą”, pojawiają się problemy z komunikacją, ludzie są sfrustrowani, a projekty są opóźnione. Gdy wszyscy już zaakceptowali zakres prac, konieczne jest, aby wymagania były jasne i dobrze udokumentowane. Śledzenie wszystkich wymagań staje się trudne.

Wyobraź sobie, że masz listę rzeczy do zrobienia o długości mili, która wymaga współpracy z wieloma osobami. Jak byś utrzymał wszystkie te elementy prosto? Jak można śledzić, jak jedna zmiana w elemencie wpłynie na pozostałą część projektu? W tym przypadku identyfikowalność i zarządzanie zmianami dodają wartości.