Всегда относите любой запрос к деньгам. Люди, которые приходят с этими запросами, как правило, больше заботятся о деньгах, поэтому убедитесь, что они знают, что это будет стоить им дороже, потому что:

• это займет больше времени
• , это может привести к большему количеству ошибок
• скорее всего, это замедлит обслуживание
• , но и замедлит разработку связанных с ним новых функций

Я нахожу фраза «мы сделаем это на втором этапе?» творит чудеса,

Ваше предпочтительное оружие должно быть оценкой . Смешная функциональность, как правило, идет с нелепой оценкой. Когда должен иметь функцию X получает оценку в 3 человека в год, он волшебным образом превращается в приятно иметь функцию X .

Если это клиент и технически возможно сделать, и вы можете это сделать, получите техническое задание - и сделайте это.

Если это ваша работа, вы делаете так же, как и все остальное. Вы говорите: «Да, сэр (или мэм), я буду счастлив сделать это. И я совсем не против. Я просто подумал, что вы, возможно, захотите узнать, как это повлияет на наши другие системы или бюджет. Не говоря, что вы не правы, просто говоря, что, может быть, нам следует немного подумать об этом. Это нормально? »

Если они скажут« нет », они подписали это, и вы сделаете это. Если вы действительно обеспокоены, запишите ваш разговор, где ваш совет не был услышан. Помните, что если вы не задокументируете это, этого не произойдет. Если они слушают, то вы выиграли друга. 1275 Это было бы то же самое для любой работы - компьютер, строитель, что угодно.

РЕДАКТИРОВАТЬ:

Я взял это из моего комментария ниже:

Кто-нибудь больше смотрит Star Trek, TNG или TOS? Помните, номер один сообщал бы капитану Пикарду о чем-то не так, и иногда Жан-Люк соглашался, а иногда - нет. Это все, что я говорю

Я бы потратил время, чтобы вежливо выслушать, если есть более одного запроса, попросите их расставить приоритеты и получить запрос в письменном виде, в идеале «подписанный» или любую другую процедуру, которую вы используете. Затем сообщите своему менеджеру / клиенту, что вы рассмотрите запросы и ответите на них с оценками и влиянием, которое это окажет на ваше расписание. Объясните, что для того, чтобы получить эти данные, вам потребуется X часов (или дней), и поэтому ваша другая работа будет отложена ...

Затем вернитесь с оценками - если запрос был нелепым, то ваша оценка вероятна чтобы отразить это: -)

Если ваш менеджер / клиент хочет продолжить и тратить много времени и денег, то, по крайней мере, вы дали понять это заранее и сделали все возможное, чтобы помочь им.

These are all good answers. You need hard data (if it's possible to generate it), "believably ridiculous" estimates, and, most of all, respect.

Johnny's answer was right on in essence, if not in the exact words (I'd comment if I'd built enough rep). In some cases, though, using those exact words might create enough dissonance to get the requestor to take a second look at the content of your objections. And yes, this applies to any project-based endeavor: software, advertising design, even (gasp!) construction. Not that the grunt carrying the mortar will have the grounds or clout to object to flawed design, but the construction lead does have an obligation to tell the architect if his plans are unbuildable.

If all else fails, document the discussion & build it anyway. It's no longer your responsibility.

Когда я отвечаю на них, смешные запросы функций делятся на два лагеря.

1. Функция заставит приложение перестать функционировать, как ожидалось, то есть нарушит его, слишком сильно замедлит, сделает его неработоспособная
2. функция, которая не приведет к тому, что приложение перестает функционировать должным образом, но я не понимаю, зачем вам нужна такая функция

Для типа 1 я проанализирую запрос и отвечу либо неопровержимыми, либо профессиональными данными мнение. Если анализ показывает, что это может быть возможно с дополнительными усилиями над существующим кодом, тогда оцените и оцените высоко!

Для типа 2, сначала я попрошу запрашивающую сторону объяснить функцию более подробно, после того как все они могут работать в область бизнеса, в которой у меня нет четкого понимания за пределами проблемного пространства для оригинальной спецификации приложения. Если я все еще не понимаю и не вижу цели этой функции, тогда я оцениваю ее высоко, чтобы отговорить их. 1216] Если они принимают оценку или я, наконец, получаю ее, тогда я делаю это.

В конце концов, они - клиенты, и если клиент входит в портного и просит брюки с 4 ногами, портной может поспорить некоторое время, но в конце концов, это обычная работа и гораздо более дорогая. Так что, если они видят достаточную ценность в функции, которую они готовы заплатить, будьте готовы взять их деньги; только то, что вы не видите значения, не означает, что они неверны.

они - клиенты, и если клиент входит в портного и просит брюки с 4-мя ногами, портной может поспорить некоторое время, но в конце концов это обычная работа и гораздо более дорогая. Так что, если они видят достаточную ценность в функции, которую они готовы заплатить, будьте готовы взять их деньги; только то, что вы не видите значения, не означает, что они неверны.

они - клиенты, и если клиент входит в портного и просит брюки с 4-мя ногами, портной может поспорить некоторое время, но в конце концов это обычная работа и гораздо более дорогая. Так что, если они видят достаточную ценность в функции, которую они готовы заплатить, будьте готовы взять их деньги; только то, что вы не видите значения, не означает, что они неверны.

Я думаю, что единственное, что вы можете сделать, это очень кратко описать основные проблемы, которые запрос на изменение затронет вовлеченных людей. На моем рабочем месте у нас та же проблема, что и у вас.

Некоторые запросы на изменение заставляют разработчиков перепрыгивать через обручи только для того, чтобы это сделать, и в итоге это приводит к уменьшению объема поддерживаемого кода для функции, которую кто-то думал наверху. было бы неплохо.

По моему опыту, вы ничего не можете сделать, чтобы остановить это, и в конечном итоге руководство начнет жаловаться на то, сколько времени занимает разработка и т. д. и т. д. Это ужасный дерьмовый цикл, который либо закончится тем, что сайт будет или ваша команда проводит вечность в адском коде.

Удачи.

Я обнаружил, что большую часть времени люди, просящие невозможного, не понимают, почему то, что они просят, является такой проблемой.

В общем, я просто прошу все больше и больше разъяснений. требования и все больше и больше подробностей до тех пор, пока:

• В моей голове не вспыхивает лампочка, я понимаю, к чему они стремятся, и могу сказать «ах, что вы действительно хотите, это X, а не Y». В этот момент они обычно говорят: «Да, это то, что я говорил все это время».

• Они понимают, насколько они нереалистичны, и отозвали запрос.

• Вы вместе понимаете, что это было бы действительно хорошо, но это невозможно , Обычно, по моему опыту, это происходит потому, что вам нужно внести изменения в большое приложение с закрытым исходным кодом - в этом случае вы просто отправляете запрос функции поставщику, что более приятно для нетехников, чем для техников; Microsoft не вносит изменения в Excel, потому что одна маленькая фирма попросила их об этом!

Созданные заказчиком требования могут быть основной причиной этой проблемы. Проблема в том, что заказчик иногда пытается выполнить работу разработчика программного обеспечения.

У него возникает проблема, а затем он решает, какую функцию он решит. К сожалению, некоторые (большинство) из этих бедных людей не очень хорошо разбираются в разработке программного обеспечения, поэтому в конце вы получаете очень любопытную особенность.

Способ удалить некоторые из этих запаздывающих функций - просто с помощью рекурсии. Почему () функция. Продолжайте спрашивать, почему, пока не найдете их проблему, а затем разработайте эту функцию самостоятельно. Во многих сценариях вы можете изменить дизайн таким простым, недорогим способом, который удовлетворит все стороны. Бывают случаи, когда разработчики программного обеспечения (и я поймал себя на том, что делаю это в прошлом) говорят «нет» достаточно сложной, но очень полезной функции, которая принесет компании большие деньги. Поэтому, когда вы сталкиваетесь с «нелепой» функцией, обязательно просчитайте ее потенциальную ценность для бизнеса, прежде чем немедленно ее отменить.

Существуют разные виды «нелепости».

• Это слишком дорого : я утверждаю, что потребности клиентов должны стоить потраченных денег
• Это просто ненужные вещи : я пытаюсь объяснить, что покупатель не может его использовать. Если они все еще хотят этого, они могут иметь его.
• Это противоречит существующим концепциям : Это на самом деле «слишком дорого», как «недоступно». Они не получат его.

Мне нравится обсуждать требования: -)

Редактировать:

Типичное обсуждение

• Маркетолог: Рядом с этой таблицей нам нужна кнопка для предоставления функции X выбор.
• Разработчик: Но нам нужен дополнительный параметр P для функции X
• M: Параметр P очевиден во многих случаях
• D: Но мы должны охватить все случаи. Нам нужно запросить P
• М: Нет! Пользователи не любят, когда их запрашивают очевидные значения! Они просто хотят «щелкнуть и уйти». 1240 D: В этом случае это невозможно. Нам нужно подсказать.
• М: (любезно) Разве вы не можете угадать это и только подсказать, если это действительно необходимо? 1242 Д: Трудно угадать. На самом деле это занимает недели или даже месяц, и это высокий риск. Что если мы догадаемся неправильно? Для этого нам понадобится искусственный интеллект.
• М: Но это очень просто: всегда, в случае, бла-бла, мы знаем. П
• Д: Да, конечно, но мы не знаем, что знает пользователь.
• М: Хм. Вы, разработчики, всегда такие сложные.
• D: ...
• М: Итак, вы можете это сделать или нет?
• Д: Нет.
• М: Почему?
• Д: (раздраженно) ) Я только что объяснил. После всего, Как вы думаете, пользователю нравится, что система угадывает P, если он действительно хочет принять решение?
• М: Вам просто нужно угадать, что решит пользователь.
• Д: Но откуда я знаю?
• М: Это эта ситуация, бла-бла ...
• Д: Я знаю, но это не так просто.
• М: Хорошо, я иду к руководителю проекта, он даст вам задание.
• Д: .. .

Иногда такие запросы поступают от менеджеров по продуктам.

В одном случае я объяснил, что будут проблемы с производительностью, и старший парень подтвердил, что мы победили.

Следующий время и поднял аналогичную проблему, но старший парень не был доступен, поэтому я просто сделал то, что они хотели, потому что никто не заботился. Я тоже решил не делать этого.

Вы, вероятно, имеете в виду такие вещи, как отправка запроса по нескольким критериям в базу данных, отображение результатов и в то же время показ того, какой из этих критериев имел успех. Догадались?

• Sometimes you can explain why the functionality is ridiculous, and the functionality is dropped.

• Sometimes you can get someone more senior to say "no" for you.

• Sometimes you are senior (or influential) enough to say "no" for yourself.

• Sometime you can say "yes", but give the task a low priority (and never do it).

• Sometimes you just have to get on with it.

In the latter case, you should make sure to do the task very, very well indeed. Why? You will shine, and as you do so, the shadow of the ridiculous will be brought into focus.