Как Вы управляете клиентами относительно изменяющихся требований? [закрытый]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Или поместите энергозависимые требования в начало проекта так, чтобы некоторая разработка прототипа или технико-экономическое обоснование, вероятно, разъяснили их или запланировали изменение поздно в проект.

• Монитор, что требования все еще релевантны.

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

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

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

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