Как вы управляете клиентами в отношении изменения требований?

Я работаю в качестве разработчика indpenedent и поэтому напрямую контактирую с клиентами. Это нормально, что большую часть времени они понятия не имеют, чего на самом деле хотят. Поэтому мы начинаем медленно, и я даю им прототип на ранней стадии, чтобы играть, а затем изменения будут постепенно сделаны. Если я думаю, что клиенты хотят "легкомысленных" изменений, я говорю им, что эти изменения не работают или не нужны. Если это 5 мин работы, то я мог бы даже сделать это в любом случае.

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

управление заказчику тяжело, и это то, что очень легко может пойти не так.

Я считаю, что как можно раньше нужно завоевать доверие клиента. Для меня, я думаю, вы можете сделать это:

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

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

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

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

Это для "внутренних" клиентов.

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

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

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

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

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

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

делаем ли мы легкомысленные изменения? Да. Что вы должны помнить, что когда вы выставляете счет часам большую часть времени 5 минутная смена оплачивается в течение полного часа, так что это довольно прибыльно. Мы объясняем все это раньше, как мы делаем с любой просьбой об изменении, чтобы они знали об этом, но это, как правило, помогает препятствовать такому поведению, если это действительно не важно. Дело в том, что мы относимся ко всем изменениям одинаково. Мы не предполагаем, что мы знаем, что считается легкомысленным для них, независимо от того, насколько абсурдным мы думаем, что это может быть. У нас есть формальный процесс изменения, когда клиент просит что-то записываем и заставить их подписать от того, что мы оцениваем его и представляем оценку стоимости работы. Они либо соглашаются, в этом случае они формально подписывают документ, дающий нам знать, что можно начинать, либо они отменяют запрос. Мы стараемся быть прилежными, но даем им знать, что нам потребуется несколько дней, чтобы получить ответ на их просьбу.

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

Я бы предпочел термин развивающихся требований к "изменяющимся требованиям". Профессор М. М. Леман (http://www.doc.ic.ac.uk / ~mml/ и http://en.wikipedia.org/wiki/Meir_Manny_Lehman) внес значительный вклад в исследования по эволюции программного обеспечения; его работы также предполагают, что не все типы требований эволюционируют. Можно считать, что им повезло, если они работают на одной из этих систем, где требования остаются неизменными (т. е. математические библиотеки п.)

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

некоторые практические советы по управлению эволюцией требований:

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

• либо поставить изменчивые требования в начале проекта, так что какой-то прототип или технико-экономическое обоснование, вероятно, прояснить их или планировать изменения в конце проекта.

• монитор, что требования по-прежнему актуальны.

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

• продолжайте управлять ожиданиями клиентов о том, как долго все будет продолжаться; это также помогает сосредоточиться.

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

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

клиент приходит к вам, чтобы сделать что-то, потому что у них либо нет времени, чтобы сделать это, или они не знают, что делать (и хочу заплатить вам, чтобы сделать это за них). Если у вас есть изменяющиеся требования, это из-за последнего. Другими словами, они платят вам, чтобы выяснить подробности! Они знают, что им нравится, а что нет, но не знают, как это работает.

признать это и все, что решение должно быть падает на место.