Wyślij zapytanie Dołącz do Sii

Zarządzamy projektami, zarządzamy zespołem … A co z wymaganiami? Oczywiście one też podlegają zarządzaniu w kontekście tego, jakie systemy, czy aplikacje obecnie budujemy i tego, jak są one rozwijane. Zarządzanie wymaganiami to więc całokształt czynności, które wykonujemy, aby te wymagania żyły, były aktualne i znane wszystkim interesariuszom.

Przede wszystkim wymagania utrzymujemy. Aktualnie panuje trend do tworzenia minimum dokumentacji, a w zasadzie do jej nie tworzenia, lub tworzenia jedynie ad hoc na potrzebę developmentu i nie przechowywania jej dłużej. W zależności od projektu oraz okoliczności rozwijania systemu nie zawsze tak się jednak da. Minimum dokumentacji jest czasem potrzebne. Ludzie w projektach się zmieniają, a ani kod, ani aplikacja sama w sobie wcale nie są wcale najlepszą dokumentacją. W sytuacji, kiedy więc musimy do pewnych funkcjonalności wrócić, chcąc je rozwijać, modyfikować, czy się na nich wzorować, potrzebujemy chociaż tego minimum dokumentacji. Wszystko jedno w jakiej formie będą zebrane wymagania – model, opis, prototyp. Utrzymanie ma więc kluczowe znaczenie, kiedy do wymagań przynajmniej raz będziemy musieli wrócić. Czy to po to, żeby się dowiedzieć, o co w ogóle chodziło, czy też po to, żeby coś zmienić. Let’s keep them up to date 🙂

Kolejnym aspektem jest ustalanie priorytetów. Priorytetyzowanie było zarówno w projektach tradycyjnych, jak i jest obecnie – w projektach zwinnych – istotne, kiedy musimy wybrać z jakichś względów pomiędzy dwoma wymaganiami. Może to wynikać z wielu czynników. W projektach waterfall’owych mogło to wynikać z konieczności ograniczenia zakresu tak, aby zmieścić się w budżecie i czasie, w projektach typu agile chodzi przede wszystkim o ustalenie funkcjonalności najbliższego przyrostu aplikacji – aplikacja na koniec iteracji musi działać, wybieramy więc taki pod zakres, który jest najbardziej istotny z punktu widzenia wartości biznesowej i który damy radę zaimplementować. Priorytetyzowanie najczęściej należy do interesariuszy biznesowych, np. obecnie do Product Ownera, natomiast rola Analityka jest w tym nieoceniona, to on zazwyczaj wie, że trzeba coś „poukładać w kolejności” i wspiera ten proces np. dostarczając technik.

A teraz pobawmy się w … detektywów 🙂 Tak jest, wymagania śledzimy. Co to oznacza? Dla wymagań utrzymujemy powiązania wertykalne i horyzontalne. Powiązania wertykalne to te między wymaganiami. Ogromnie istotne w kontekście analizy zmian w wymaganiach, ale o tym w najbliższym poście („Zarządzanie zmianą wymagań”). Powiązania horyzontalne to te pomiędzy wymaganiami, ich implementacją i pojedynczym testem, który sprawdza implementację wymagania. Śledzenie tych powiązań w obydwu kierunkach powoduje, że nie umykają nam żadne kwestie i znamy całokształt wysiłku, który nas czeka, aby prawidłowo zaimplementować pewien aspekt odpowiadający na potrzebę biznesową.

Analiza biznesowa wymagania

Wymagania komunikujemy. A mianowicie informujemy, jeśli nie wszystkich, to przynajmniej najbardziej zainteresowanych interesariuszy, że w wymaganiach powstała zmiana, lub, że w ogóle pojawiło się wymaganie. Dla developerów może być bardzo istotna informacja, że jednak inaczej realizujemy pewną funkcjonalność, zwłaszcza jeśli są w trakcje developmentu. A przecież wszyscy dobrze wiemy, jaki to chleb powszedni projektów 🙂 Z kolei w drugą stronę – dla biznesu waży jest przekaz od developerów, że np. pewnych funkcjonalności nie da się zrealizować w oczekiwany sposób. Takich sytuacji może być dużo i mogą być naprawdę różne, istotne jest to, aby zachowywać przeźroczystość obecnej sytuacji dla wszystkich.

Wreszcie – status wymagań, czyli ich cykl życia. Ta kwestia troszkę rozszerza aspekt powiązań horyzontalnych i utrzymania. Wymagań w projektach mamy zazwyczaj ogromne ilości. Pojawia się na szczęście coraz więcej narzędzi, które nas wspierają w zarządzaniu, czy będzie to np. JIRA, czy też dedykowane narzędzie stricte do zarządzania wymaganiami. W takich narzędziach dość łatwe staje się zarządzanie statusami, trzeba po prostu z tego skorzystać. W backlogu dla produktu, który to backlog jest wykorzystywany w projektach prowadzonych według metodyki SCRUM (lub scrum-o podobnej :)), przechowujemy wszystko, co jest do robienia w produkcie. Ważne jest więc, aby wiedzieć dokładnie, co jest do zrobienia, co jest w trakcie realizacji (i na jakim etapie – czy development, czy testy wewnętrzne, czy też testy akceptacyjne), a także co zostało już wcześniej wykonane i jest wymaganiem archiwalnym.  Do tego dochodzą aspekty pewnych statystyk, które możemy prowadzić, np. wydajności zespołu developerów dla pewnej liczby wymagań określonych rozmiarów, porównywania wersji produktu pod kątem rozmiaru, czyli liczby wymagań i inne.

Obszar zarządzania wymaganiami jest obszerny analogicznie jak zarządzanie innymi aspektami. Tak samo jak żyje produkt, powinny żyć wymagania do niego, dla analityka jest więc niezwykle istotne, aby mieć wymagania pod kontrolą. Bądźmy więc „Requirement Managerami” 🙂

Ocena:
Autor
Avatar
Ilona Konitz

Business analyst with experience in conducting analyzes and implementing BI and BPM class systems, as well as tailor-made solutions in the financial, banking and insurance industries. On a daily basis, it acquires and analyzes requirements, recommends solutions, and acts as an intermediary between the business side and the development team in implemented projects. After hours, she is involved in the activities of the Warsaw Poland Chapter of IIBA Association - she takes part in organizing thematic events for business analysts. In her free time, she is an amateur of cinema, good books and recreational sports.

Zostaw komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Może Cię również zainteresować

Pokaż więcej artykułów

Bądź na bieżąco

Zasubskrybuj naszego bloga i otrzymuj informacje o najnowszych wpisach.

Otrzymaj ofertę

Jeśli chcesz dowiedzieć się więcej na temat oferty Sii, skontaktuj się z nami.

Wyślij zapytanie Wyślij zapytanie

Natalia Competency Center Director

Get an offer

Dołącz do Sii

Znajdź idealną pracę – zapoznaj się z naszą ofertą rekrutacyjną i aplikuj.

Aplikuj Aplikuj

Paweł Process Owner

Join Sii

ZATWIERDŹ

This content is available only in one language version.
You will be redirected to home page.

Are you sure you want to leave this page?