Wymagania będą rosły i ulegały zmianie. Nie sądzę, żeby ktokolwiek mógł się z tym kłócić.
Jak zbierać i przetwarzać przychodzące żądania .
Z mojego doświadczenia wynika, że pomaga to w zbieraniu wymagań, jeśli istnieje jedna lub bardzo mała grupa klientów działająca jako filtr dostarczający nowe lub zaktualizowane wymagania małej grupie planistów rozwoju. Każdy z ich strony może je zaproponować lub napisać, ale dostawa powinna odbywać się tylko w bardzo niewielkiej liczbie. Im mniej osób jest zaangażowanych w wymianę z jednej strony na drugą, tym lepiej.
Filtrowanie przez mniejszy zestaw ludzi nie ma na celu odrzucenia lub zmniejszenia wysiłku i informacji włożonych przez innych, nawet jeśli są zduplikowane lub pozornie nieistotne na powierzchni, ale ograniczenie punktów awarii: zagubionych lub źle traktowanych informacji. Wynika z zasady podobnej do celu enkapsulacji i interfejsów: ochrona danych prywatnych i ustanowienie wspólnego protokołu do obsługi podobnych żądań. Powtórzę: przesłanie duplikatów jest w porządku. Jako planista mówi mi, że to, o czym mówią lub które proponuje, jest ważne. Zapisz lub nagraj wszystko.
Jak śledzić i organizować wymagania
W krótkim okresie przejdź do niskiej technologii
Oczywiście istnieją rozwiązania o niskim poziomie zaawansowania technologicznego, które mogą być w dużym stopniu skuteczne w organizowaniu i śledzeniu nadchodzących wymagań: tablice, naklejki, tablice reklamowe, co masz. Mogą być świetne do planowania krótkoterminowego. Są bardzo widoczne, akceptują zapis w dowolnej formie i łatwo je „zmienić”.
W dłuższej perspektywie użyj narzędzia programowalnego z możliwością wyszukiwania, sortowania i łączenia
W przypadku wysiłków na dłuższym dystansie przydatne byłoby jakieś oprogramowanie. Istnieją wyspecjalizowane narzędzia do zarządzania wymaganiami: Drzwi, Clearcase / Clearquest i wiele innych. Te wysoce wyspecjalizowane narzędzia są świetne w tym, co robią, ale często są nadmierne. Czasami nawet zwykły stary arkusz kalkulacyjny jest więcej niż wystarczający. Osobiście uważam, że ogólne systemy śledzenia problemów są dość przydatne, aby to osiągnąć, a teraz moim ulubionym jest Redmine, ale inne, na pewno, też by były w porządku.
Dzięki systemowi śledzenia problemów każdy, na kogo zezwolisz, może utworzyć „nowy problem” lub wymaganie i dodać dowolne szczegóły, które uzna za stosowne. Mogą obserwować problem i przekazywać informacje zwrotne na temat podejmowanych działań. Możesz go skategoryzować, dostosować priorytet, przepisać ciało, dołączyć dodatkowe informacje, powiązać je z innymi „problemami”, promować na wyższym poziomie funkcję lub „przypadek użycia” lub historię lub dowolną terminologię, która pasuje do twojego systemu, na muzeum. Innymi słowy, możesz wiele zrobić, aby utworzyć identyfikowalną, sortowalną, priorytetową, uwzględniającą historię pokrewną listę wymagań za pośrednictwem problemów. Dodatkowo, będąc dość konfigurowalnym od razu po wyjęciu z pudełka, i open-source, jeśli narzędzie nie jest dokładnie tym, czego potrzebuję lub chcę w dowolnym momencie, mogę go dość łatwo zmienić, aby lepiej dostosować się do potrzeb mojego procesu.
Ostatnia uwaga na temat narzędzi, niektóre osoby, z którymi rozmawiałem, odnoszą spore sukcesy, używając zwykłych starych plików tekstowych w systemie zarządzania zmianami i wersjonowania. Oczywiście czerpią korzyści z wersji historycznych. Wykorzystują również podstawowy system operacyjny i dodatkowe narzędzia do wyszukiwania, łączenia i katalogowania wymagań. Nie są w stanie dodać tyle ustrukturyzowanych, powiązanych meta informacji, ale nie czują, że potrzebują ich, a ich wysiłki nie wnoszą wystarczającej wartości. Tak może być lub nie. Zaletą jest to, że potencjalnie jest o kilka mniej oprogramowania na stosie programistycznym do zarządzania i konserwacji.
Wymagania dotyczące udzielenia zamówienia po zakończeniu realizacji zamówienia / opracowania projektu
Ostatnim aspektem pytania jest sposób zarządzania wymaganiami po rozpoczęciu wysiłku. Myślę, że istnieją dwie główne myśli na ten temat, a część tego, jak sobie z nimi poradzisz, zależy od charakteru twoich relacji z klientem: po pierwsze, jeśli na podstawie umowy o stałej wartości, można uwzględnić wymagania, które pojawiają się po udzieleniu zamówienia. Oznacza to, że mogą one zmienić zakres wysiłku, więc stawka lub rachunek będą wyższe, gdy te dodatkowe elementy zostaną dostarczone i zaakceptowane; chyba że równoważna ilość wysiłku zostanie usunięta z zaakceptowanej propozycji. Jeśli zmienią się zakres, musisz upewnić się, że klient rozumie i akceptuje konsekwencje, w przeciwnym razie te spóźnione zgłoszenia będą musiały zostać złożone.
Po drugie, w przypadku nowych wymagań pojawiających się po udzieleniu zamówienia, a umowa jest zorientowana bardziej na czas i wysiłek materialny (wszystko, czego potrzeba, aby ukończyć pracę), możesz i powinieneś być bardziej elastyczny, jeśli klient nalega na uwzględnienie go w tym konkretnym okresie. Otrzymasz zapłatę, niezależnie od tego, czy ją uwzględnisz, czy nie, o ile wszystko, co powiesz, że zrobisz, zostanie wykonane.
Jeśli nie znasz ich, możesz przyjrzeć się podejściu Kanban i metodom zwinnym. Techniki te mogą pomóc skupić się na bezpośrednich problemach, niekoniecznie tracąc z oczu długoterminowe cele rozwojowe.
Przedstaw opcje jako scenariusze „co jeśli” i daj klientowi wybór i decyzję
W obu przypadkach oszacowanie „co jeśli” jest dobrą strategią stosowaną podczas negocjacji z klientem i zespołem. Skonfiguruj porównanie zadań, ich kosztów i harmonogramu zgodnie z planem, z kolumną przedstawiającą te same informacje dla alternatywnych podejść. Microsoft Project jest prawdopodobnie dobrym kandydatem do tego, ponieważ można konstruować różne szacunki w oparciu o w dużej mierze podobny zestaw zadań.
Jednak nawet podstawowy arkusz kalkulacyjny jest często równie skuteczny do wykazania, w jaki sposób określone zmiany lub inkluzje wpłynęłyby na koszty i harmonogram. Lista w tym przypadku jest prawdopodobnie tak samo skuteczna, jak drzewo może wykazać różnice. Narzędzie i metoda, którą wybierzesz do zbudowania tych scenariuszy, w dużej mierze zależy od wielkości projektu i personelu (ale nawet potrójnego Oprogramowanie takie jak MS Project ma swoje własne ograniczenia użyteczności i możliwości).
Rozważ to, co jeśli scenariusze jako wewnętrzne elementy pracy i zapisz je na czas trwania projektu. Były to krytyczne demonstracje w procesie podejmowania decyzji i negocjacji. Być może będziesz musiał je ponownie odwiedzić lub powtórzyć je dla następnej rundy, co jeśli.
Podczas przygotowywania scenariuszy, co jeśli, dodatkowe wyjaśnienie za i przeciw z perspektywy technicznej lub implementacyjnej (w uproszczeniu) może być pomocne w uzasadnieniu, dlaczego jedna alternatywa miałaby tak znaczący wpływ.