Я верю в отбрасывание плохих требований. Но я также считаю, что, когда вы приложили все усилия, чтобы объяснить, почему они плохие и они все еще хотят их, тогда вы соглашаетесь и выполняете свою работу.
Например, у меня были люди, которые хотят, чтобы требования были взаимоисключающими к тому, что приложение уже делает. Если я сделаю это, то это, на 100% гарантированный, сломается. Поэтому я отправляю требование обратно и говорю им, что это нарушит другое бизнес-правило, которое у нас уже есть, и они тоже хотят изменить это правило? Часто небольшая группа, которая предъявляет особые требования, не имеет доступа к более полной картине того, что может делать остальная часть приложения. В большинстве случаев, когда я отправлял одно из них назад, заказчик осознавал, что начальное правило было более критичным, и решал, что изменение, которое он хотел, не стоило того. Когда они решили внести изменения, они сделали это после консультации с людьми, которые выдвинули первоначальное требование.
Иногда просто задавая уточняющие вопросы, они видят проблему не так просто, как они думали. Иногда вы хотите спросить, почему они чего-то хотят и приходят к реальной потребности, которая движет изменениями. Как только вы это поймете, часто легче найти альтернативное решение, которое работает для вас как разработчика и отвечает их потребностям. Если вы можете представить это решение с точки зрения того, как оно будет лучше отвечать их потребностям, чем первоначальное предложение, вы значительно повысите свои шансы на принятие вашего изменения.
Иногда, когда изменение приведет к хаосу на базовом уровне в вашем дизайне, достаточно просто дать им новую оценку времени, которое потребуется на изменение, чтобы отключить его. Если вы объедините это с оценкой риска, которая укажет на то, в какую критическую функциональность вы можете вносить новые ошибки, сообщая им, что 3 человека посвятят 6 недель самоотверженным усилиям, и вдруг это уже не так важно.
Но иногда вы говорите им, что это не очень хорошая идея и почему, и они все еще говорят: «Жаль, что нам это нужно». Некоторые выигрывают, а некоторые - проигрывают, а иногда потребности бизнеса действительно меняются, и приложение должно соответствовать этому. После того, как решение будет принято, у вас больше не будет времени задавать вопросы о том, что вы делаете, и настало время продолжать это делать. Если вы задокументировали свои возражения, то лично вам все равно следует быть в хорошем положении, когда он превышает бюджет и вызывает новые и более интересные ошибки. И они могут быть даже более готовы выслушать вас в следующий раз, когда вы создадите послужной список того, что вы правы в подобных вещах.
Ключ к победе во многих из этих дискуссий (никто не выигрывает их все) - это, во-первых, создать послужной список для понимания того, о чем вы говорите. Затем отправьте письменный документ, в котором указано, что вас беспокоит (многие менеджеры подвержены риску, они, скорее всего, не захотят, чтобы у кого-то был документ, доказывающий их неправоту позднее, поэтому они уделяют больше внимания тому, что вы написали в письменной форме) и, наконец, чтобы убедиться, что они понимают все затраты (не только часы, но риски безопасности, внесение новых ошибок, несоблюдение сроков и т. д.) внесения изменений. Изменение не является бесплатным, и они должны это понимать. Следующий ключ - делать это как взрослый, а не как нытье ребенка («но я не хочу использовать ... потому что мне это не нравится»). Сделайте экономическое обоснование того, что вы этого не сделаете, и вы гораздо дальше откажетесь от выполнения плохого требования.