Wiele razy w fazie licytacji projektu otrzymuję od naszych potencjalnych klientów wymagania dotyczące oprogramowania w bardzo nieuporządkowanym formacie z różnych źródeł [e-mail, dokumenty słowne, excel]. Zazwyczaj jest to grupa „rozwoju produktu” ze strony klienta, którzy wymyślają te „proponowane rozwiązania” problemów biznesowych, które mają. Choć są ekspertami w dziedzinie biznesu, często nie mają odpowiednich rozwiązań.
To skutkuje
- wiele wersji tego samego wymagania
- pomieszanie dwóch wymagań w jednym
- kilka wersji tego wymagania później, wymagania, które zostały połączone, zostały ponownie rozdzielone, z których każda zawiera niektóre nowe dodatki
Jak pracujesz z takimi wymaganiami i sortujesz je we właściwych przypadkach użycia przed rozpoczęciem prac rozwojowych? Jakich narzędzi możemy użyć do śledzenia historii konkretnego wymagania, od pierwszego jego powstania do momentu, gdy skrystalizuje się we właściwym przypadku użycia? Szacowanie pracy w stosunku do wymagań otrzymanych w taki sposób jest koszmarem, który kończy się popełnianiem błędów w prawidłowym zrozumieniu wymagania i prawidłowym oszacowaniem wysiłku w stosunku do niego.
Gdy wygramy projekt, klienci zastanowili się jeszcze nad swoimi wymaganiami i byli w stanie odpowiednio go wyrazić. To, co dzieje się w tym przypadku, polega na tym, że niektóre funkcje zostają upuszczone, niektóre ulepszone, inne zmieniają się całkowicie. Zasadniczo może to zniweczyć niektóre szacunki elementu pracy, które zostały dokonane przed zwycięstwem projektu. Chciałbym wiedzieć, czy istnieje system, za pomocą którego możemy zbudować drzewo określonego wymagania i jak każda gałąź daje inne oszacowanie.
Wszelkie wskazówki, narzędzia i triki, które ułatwią zarządzanie tą działalnością? Próbuję tylko uzyskać wgląd od kogoś bardziej doświadczonego niż ja w zarządzaniu wymaganiami i szacowaniu nakładu pracy.
źródło
Odpowiedzi:
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.
źródło
Patrzyłbym na to jako proces iteracyjny. Krok 1 polega na zebraniu wymagań. Krok 2 polega na ich posortowaniu. Krok 3 to nadanie im priorytetu. Krok 4 to rozbicie każdego na wystarczająco małe kawałki, aby oszacować wysiłek. Krok 5 polega na połączeniu tych bitów w globalny koszyk nakładu (powiedzmy 84 osobodni). Krok 6 polega na przyporządkowaniu nakładu do zasobów (84 osobodni / 2 dev = 42 dni).
Więc teraz utkniesz między krokiem 1 a krokiem 2. Masz wymagania, ale nie masz ich w takiej formie, jakiej potrzebujesz.
Załóżmy, że masz wiele wersji tego samego wymagania. Czy są one zasadniczo takie same? Jeśli tak, wybierz to, co wydaje się najczystsze i użyj go. Jeśli różnią się szczegółami, wybierz to, co wydaje się najbardziej logiczne i użyj tego. Następnie wyślij wiadomość do klienta z prośbą o zweryfikowanie wymagania. Być może będziesz musiał iść w tę iz powrotem i wiele razy, aby poprawnie spełnić wymagania. Nie poddawaj się i nie zniechęcaj się. Wiele projektów zakończyło się niepowodzeniem z powodu złych wymagań.
Użyj projektu Microsoft, aby synchronizować pracę i harmonogram ze zmieniającymi się wymaganiami. Jeśli klient zażąda zmiany, określ dodatkowe prace, podłącz je do swojego modelu i powiedz mu o nowej dacie. Nie daj się wciągnąć w przekonanie, że możesz po prostu sprowadzać nowych deweloperów w przypadkowych odstępach czasu, aby podnieść luz. Twój harmonogram musi uwzględniać czas rozruchu przy każdym dodaniu nowego zasobu. Będziesz w stanie odpowiednio to wymodelować, jeśli zwrócisz uwagę na każdy projekt i wyciągniesz z niego wnioski. Załóżmy, że przywiozłeś Boba na pokład projektu X po 4 miesiącach pracy. Jak produktywny był w pierwszym miesiącu? Trzeci?
Powinieneś ponownie odwiedzać model projektu co tydzień, wprowadzając aktualizacje tam, gdzie jest to wymagane. Prowadź historyczny zapis zmian. Pomoże to zapewnić lepsze prognozy w przyszłości.
doug
źródło