Когда вы дуете свист ползучий прицел?

Question

Большинство людей были здесь в тот или иной момент - в вашем проекте вы получаете действительно маленькие запросы по пути, о которых вы с удовольствием позаботитесь, но в какой-то момент мелочи складываются. Иногда для реализации чего-либо требуется меньше времени, чем для пересмотра плана проекта.

При условии, что план спецификаций / требований является приличным, и это не обреченный проект для начала, в какой момент вы фактически даете сигнал и начинаете пересмотр? На любой запрос? Когда этот запрос требует дополнительных страниц / форм? Или просто почувствовать это? Хотелось бы услышать, как вы делаете звонок.

Answer 1

Бюджет N часов специальных запросов в плане вашего проекта. (Вы знаете, что это произойдет, так почему же его там нет?) Затем отследите ваши специальные запросы и проведите повторные переговоры, когда бюджет уйдет.

Answer 2

В любой запрос?

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

Отредактировано, чтобы добавить: Покупательский взнос означает, что они знают, что вы работаете над новой функцией вместо того, что вы будете делать, и что они согласны. Когда вы просмотрели свой график и бюджет и все еще не сделали этого, они были там с вами весь путь и знают, почему. Не большой сюрприз "Что? Ты не СДЕЛАНО?!"

Answer 3

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

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

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

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

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

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

Answer 4

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

Как только вы один раз опустите ногу, вы обнаружите, что запросы высыхают!

Answer 5

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

Answer 6

Предполагаемая дата завершения - это скорее кривая вероятности, чем одна дата.

Любая дополнительная функция уменьшает вероятность встречи с определенной датой.

Вы должны «свистеть», если и когда уменьшение вероятности становится «значительным» или стоит упомянуть.