Wierzę w odsuwanie złych wymagań. Ale wierzę również, że kiedy postarałeś się jak najlepiej wyjaśnić, dlaczego są źli i nadal ich chcą, to zgadzasz się i wykonujesz swoją pracę.
Na przykład miałem ludzi, którzy chcą wymagań, które wykluczają się z czegoś, co aplikacja już robi. Jeśli to zrobię, będzie to, w 100% gwarantowane, przerwa. Odsyłam więc wymaganie z powrotem i mówię, że to złamie tę inną regułę biznesową, którą już mamy i czy oni też chcą zmienić tę regułę? Często mała grupa, która spełnia określone wymagania, nie ma dostępu do większego obrazu tego, co może zrobić reszta aplikacji. Przez większość czasu, gdy odesłałem jedną z nich, klient zdał sobie sprawę, że zasada intialna była bardziej krytyczna i zdecydował, że pożądana zmiana nie była tego warta. Kiedy zdecydowali się dokonać zmiany, zrobili to po konsultacji z ludźmi, którzy wprowadzili początkowy wymóg.
Czasami samo zadawanie pytań wyjaśniających sprawi, że zauważy, że problem nie jest tak prosty, jak im się wydawało. Czasami chcesz zapytać, dlaczego czegoś chcą i dojść do prawdziwej potrzeby, która napędza zmianę. Kiedy to zrozumiesz, często łatwiej jest znaleźć alternatywne rozwiązanie, które działa jako programista i spełnia ich potrzeby. Jeśli potrafisz przedstawić to rozwiązanie pod kątem tego, w jaki sposób lepiej zaspokoi ich potrzebę niż pierwotna sugestia, znacznie zwiększyłeś swoje szanse na zaakceptowanie zmiany.
Czasami, gdy zmiana spowoduje spustoszenie na podstawowym poziomie w twoim projekcie, wystarczy podać im nowy szacunkowy czas potrzebny na zmianę, aby ją wyłączyć. Jeśli połączysz to z oceną ryzyka, która wskazuje, na jaką krytyczną funkcjonalność możesz wprowadzać nowe błędy, mówiąc im, że zajmie to 6 tygodni poświęconego wysiłku przez 3 osoby, nagle nie jest to już tak ważne.
Ale czasami mówisz im, że to nie jest dobry pomysł i dlaczego, a oni wciąż mówią: „Szkoda, że tego potrzebujemy”. Niektóre wygrywasz, a niektóre tracisz, a czasem potrzeby biznesowe naprawdę się zmieniły i aplikacja musi to uwzględnić. Po sfinalizowaniu decyzji nie ma już czasu, aby zadawać pytania o to, co robisz, i czas na zrobienie tego. Jeśli udokumentowałeś swoje zastrzeżenia, to osobiście powinieneś być w dobrym miejscu, gdy przekroczy budżet i spowoduje nowe i bardziej ekscytujące błędy. I mogą być nawet bardziej skłonni cię wysłuchać następnym razem, gdy osiągniesz dobre wyniki w tego rodzaju sprawach.
Kluczem do wygrania wielu z tych dyskusji (nikt ich nie wygra) jest przede wszystkim zdobycie doświadczenia w zakresie wiedzy o tym, o czym mówisz. Następnie wyślij pisemny dokument z informacją o swoich obawach (wielu menedżerów jest ryzykownych, częściej nie chcą, aby ktoś miał dokument potwierdzający ich późniejszy błąd, więc zwracają większą uwagę na to, co napisałeś) aby upewnić się, że rozumieją wszystkie koszty (nie tylko godziny, ale także zagrożenia bezpieczeństwa, wprowadzanie nowych błędów, niedotrzymywanie terminów itp.) wprowadzenia zmiany. Zmiana nie jest darmowa i muszą to zrozumieć. Następnym kluczem jest zrobienie tego jak dorosły, a nie jak jęczące dziecko („ale nie chcę używać ... bo mi się nie podoba”). Zrób uzasadnienie biznesowe, że tego nie zrobisz, a dostaniesz znacznie więcej, odpychając złe wymagania.