Jak radzić sobie z częstymi zmianami wymagań?

Mam do czynienia z dość stresującą (moim zdaniem) sytuacją w moim obecnym miejscu pracy.

Zaczęliśmy opracowywać nowy projekt, uzyskać pewne wymagania, wdrożyć go, a następnie pokazać komuś, że możesz zadzwonić do „doradcy biznesowego” (osoby, która zna wymagania biznesowe, ale nie będzie korzystać z programu). Ta osoba powinna oceniać aplikację z punktu widzenia klientów, testować ją itp.

Oto jak wygląda „proces”:

1. doradca biznesowy rozmawia wieczorem z moim szefem przez godzinę lub dwie na komunikatorze Windows
2. następnego dnia otrzymuję e-mail z kopią tej rozmowy. Mam z tego wybrać zadania, sprawdzać zgłoszone błędy (które często nie są błędami, po prostu kiepskie testowanie i zapominanie o poprzednich zakładach)
3. Wdrażam zmiany, implementacja zostaje zaakceptowana, a potem za tydzień lub dwa okazuje się, że nie chcą tego chcą (rozmawiali z potencjalnym klientem, który widział oprogramowanie przez 5 minut, a on zaproponował zmiany) - muszę wprowadzić nowe zmiany

Nie zrozum mnie źle, rozumiem, że czasami wymagania się zmieniają. To, co mnie denerwuje, to to, jak często zmiana występuje w moim miejscu pracy i jak łatwo „zarządzać” dwiema nowymi wymaganiami, a czasem fundamentalnymi zmianami w istniejących funkcjach.

Jednocześnie pracujemy nad napiętymi terminami i mam wrażenie, że zamiast iść naprzód z naszym oprogramowaniem, bierzemy koła.

Szukam porady od ciebie, jak poradzić sobie z tą sytuacją? Czy to normalna sytuacja i jestem po prostu nadwrażliwy?

Jeśli to możliwe, weź rozmowę, którą otrzymałeś e-mailem i zamień ją w dokument wymagań. Wymień zadania, które możesz z nich zebrać i uporządkuj według tego, co uważasz za priorytetowe, i przypisz każdemu z nich oszacowanie. Następnie zapytaj, które funkcje chcą w następnej wersji.

Zasadniczo wymuś pętlę zwrotną, w której kierownictwo będzie wiedziało, co zamierzasz zbudować. Napisz własne dokumenty wymagań do czasu otrzymania wiadomości.

Karty opowieści

Myślę, że Twoja sytuacja jest odpowiednia do przedstawiania historii użytkowników . Są naprawdę pomocne w zapewnieniu menedżerowi ciągłego, interaktywnego sposobu ustalania priorytetów, a nawet może je wyrzucić, gdy wróci do pomysłu tydzień później i zda sobie sprawę, że nie jest to wykonalne.

W prawdziwym świecie wymagania zmieniają się rutynowo. Plusem jest to, że dowiesz się o tym, zanim skończysz tworzyć oprogramowanie i je wyślesz - masz ścisły cykl opinii od bezpośredniego użytkownika oprogramowania, co jest naprawdę świetne.

Wydaje się, że największym problemem tutaj jest bardzo doraźny sposób zarządzania zmianą. Masz tego, co zwinny / Scrum uważa za „właściciela produktu”, który udziela informacji zwrotnych, ale proces jest słabo udokumentowany i źle przemyślany.

Prawdopodobnie zechcesz przyjrzeć się modelom w Scrumie i ich poglądowi na temat tego, kim jest skuteczny właściciel produktu , aby pomóc w podjęciu dalszych kroków.

Zamiast więc przeprowadzać ten proces ad-hoc, staraj się przenieść do świata, w którym masz bliższą i bardziej przydatną relację z „doradcą biznesowym” i gdzie wszyscy są na tej samej stronie na temat wyników omawianych zmian .

Twój obecny proces sprawia, że ​​zbyt łatwo jest po prostu burzy mózgów pomysłów, bez względu na zasoby i pieniądze, które zużyją. Jeśli chcą mieć wszystkie te funkcje, muszą uzyskać „skórkę w grze”.

Weź ten e-mail z konwersacją i umieść go w aplikacji do śledzenia funkcji / błędów, nawet jeśli jest to tylko arkusz kalkulacyjny. Wyślij nowe uzupełnienia z powrotem do doradcy biznesowego i poproś go o podpisanie się na każdym elemencie lub wprowadzenie poprawek. Wraz z wypisywaniem się powinni ustalić priorytety (Których chcesz najpierw?).

Po ich zatwierdzeniu odeślij je do harmonogramu, kiedy elementy zostaną ukończone do testowania, i poproś o poświęcenie czasu na wykonanie testów / zatwierdzenie ukończenia.

Wiem, że tworzenie tego typu dokumentacji nie jest powodem, dla którego zostałeś programistą, ale możesz albo zrzucić te listy, albo dalej wyrzucać ciężko zarobiony kod.

Odepchnąć się. Osoby odpowiedzialne muszą zobaczyć, ile kosztują te żądania.

Zmiany wymagań nie zawsze są złe. Kluczową sprawą jest zapamiętanie klienta. Prawdopodobnie twój szef jest twoim klientem w tym przypadku. Musisz powiadomić swojego szefa, że ​​uważasz, że te ciągłe zmiany wymagań ograniczają twoją zdolność do produkowania produktu, który jest dla niego najbardziej użyteczny. Jest całkiem możliwe, że firma czerpie korzyści z ciągłego reagowania na zmiany. Jeśli tak, to jest to ich model biznesowy, a ty nie robisz nic złego, choć w takim razie polecam bieganie po wzgórzach!

Ludzie sfrustrowani zmianami wymagań są często doceniani za to, jak dobrze zarządzają każdą zmianą. Ta miara „liczby dostatecznie obsłużonych zmian” jest prawdopodobnie źródłem twoich prawdziwych problemów. Zastanów się nad omówieniem lepszych wskaźników z szefem. W obliczu ciągle zmieniających się wymagań staram się pisać treści, które pozwalają mi dostosowywać się do stale zmieniających się wymagań. Zamiast przeprowadzać symulację i analizować dane każdego dnia, napiszę narzędzia, dzięki którym proces przeprowadzania symulacji i analizy danych będzie tańszy, i z czasem będę czerpać korzyści. Jeśli to nadal jest zbyt szalone, mógłbym nawet napisać narzędzie do pisania narzędzi!

Twój proces może korzystać z niektórych zwinnych zasad, takich jak zamknięte iteracje. Myślę, że tydzień jest rozsądny przy tak szybkich zmianach, które opisujesz. 2 tygodnie mogą w końcu działać lepiej.

Po zidentyfikowaniu wystarczająco ważnych wymagań poproś osobę, która jest w Project Ownerroli, o podpisanie się na nich i zablokowanie ich na okres tygodnia podczas ich tworzenia. Przydziel wystarczającą ilość pracy dla siebie, gdzie będziesz zajęty, i daj władzom znać swój przydział. tzn. jeśli tygodniowo możesz wyprodukować 16 punktów pracy i masz 16 punktów pracy, to jesteś w pełni wykorzystany na ten tydzień. (Koncepcja punktów pochodzi ze zwinnego strumienia pracy)

Jeśli zmiany pojawią się w środku tygodnia, wypowiedz te magiczne słowa:

Mogę zrobić [tę nową funkcję], [tę nową zmianę], [itd.], Ale czego nie chcesz robić ?

Oznacza to, że jesteś ograniczonym zasobem, możesz wziąć tylko tyle pracy. Jeśli pojawi się nowy element pracy, możesz być ograniczonym zasobem, którym jesteś i przypisywać punkty do nowego elementu oraz upuszczać / zmieniać inne elementy zamiast tej nowej zmiany. Ponownie ustal priorytet swojej listy iteracji razem z właścicielem projektu i powinieneś lepiej radzić sobie ze zmianami.

Jeśli wymagania zmieniają się częściej, być może trzeba będzie wynegocjować większą stabilność w swoim środowisku.

Fraza „Zmiana wymagań” jest czasem nadużywana przez informatyków. To, co opisujesz, to rzeczywiście zmiana wymagań, ale może to wynikać z jednego lub więcej z poniższych (nie wiem wystarczająco dużo o twoim przypadku, więc poniższe mogą lub nie mogą mieć zastosowania):

1. Ambicja kierownictwa, aby jak najszybciej uszczęśliwić użytkownika końcowego i pokazać szybki postęp.

2. Brak szczegółowej analizy. Pamiętaj, że analitycy muszą zadawać pytania, dlaczego nie tylko co. Analitycy muszą „pomyśleć” z użytkownikiem końcowym o „rozwiązaniu” nie tylko przyjmującym zamówienia.

3. Brak formalnego procesu weryfikacji i potwierdzenia wymagań, a następnie zatwierdzenia.

4. Poproszenie niepoprawnej osoby o wykonanie jednej lub większej liczby ról, które niekoniecznie są przeszkolone, takie jak role Business Analyst lub Systems Analyst.

5. Ograniczone prototypowanie.

6. Założenie / obawa, że ​​należy to zrobić szybko, a jeśli nie to, że winien jest IT.

O ile jeden z powyższych nie rozwiązuje poprawnie, związek między IT a firmą / użytkownikiem końcowym będzie stresujący. Należy pamiętać, że nie oznacza to, że powyższy punkt jest rozstrzygający. Są inne czynniki, które prowadzą do stresujących sytuacji podobnych do twojej sytuacji, ale myślę, że ta lista powinna cię zachęcić.

Myślę, że powinieneś podejść do tego z kilku kierunków:

1. Poproś wszystkich interesariuszy (w tym cały zespół programistów) o spotkanie (offline / online) z doradcą biznesowym i spróbuj wspólnie zrozumieć domenę, wizję, a następnie wymagania dotyczące burzy mózgów.

2. Wymagania sformalizować / historie użytkowników, klasyfikowania każdy to:
   a. Priorytet (pilność / znaczenie)
   b. Termin zapadalności (jak dobrze jest zdefiniowany - zrozumiany i uzgodniony przez większość zainteresowanych stron *)
   c. Złożoność (przybliżone oszacowanie)
   
   Wybierając wymagania / historię użytkowników, nad którymi należy pracować, należy wziąć pod uwagę wszystkie trzy czynniki. Jeśli wymaganie ma niski termin zapadalności, dodaj przed nim misję badawczą, w której skontaktujesz się ze wszystkimi zainteresowanymi stronami, zbadaj uzasadnienie wymagania i lepiej zdefiniuj wymaganie (napisz przypadki użycia i / lub utwórz ramy i przedstaw je) przed podjęciem działania na nim.

3. Staraj się myśleć o kilku krokach do przodu podczas projektowania przed każdym wdrożeniem - zaprojektuj elastyczną architekturę, która ma miejsce na zmiany.

4. Spróbuj dostosować sprawny proces programowania, np. SCRUM lub Kanban - zapewni to zestaw narzędzi do opracowania produktu o zmieniających się wymaganiach.

Powinieneś także rozważyć poproszenie moderatorów o przeniesienie tego pytania na stronę PM.stackexchange.com (poprzez oznaczenie go), ponieważ nawet jeśli pytanie to pasuje tutaj, pasowałoby tam lepiej.

(*) Udziałowcy w porozumieniach: biznes, marketing, zarządzanie projektami, rozwój i kontrola jakości.