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

Question

Мудрость Стива Йегге тем не менее, большинство разработчиков сталкиваются с требованиями, полученными от нетехнических заказчиков.Иногда есть менеджеры проектов, которые работают с клиентами и переводят их требования, а иногда нет.В любом случае, то, что требования изменятся, — это неизбежность.

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

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

Этот вопрос о том, как управлять клиентом дать им возможность изменять свои требования так, как им нужно, не допуская при этом произвольных или необоснованных изменений.Как ты делаешь это?

• Есть ли у вас менеджеры проектов, которые изолируют разработчиков от заказчика?
• Есть ли у вас формальный процесс управления изменениями?Менять менеджеров?
• Насколько сложно клиенту получить сдачу, когда она ему действительно нужна?
• И наоборот, насколько легко покупателю получить сдачу, если она «легкомысленная»?
• Насколько подробно вы сообщаете клиенту стоимость изменения?
• Как быстро вы сможете предоставить клиенту эту информацию после получения запроса на изменение?
• Какие факторы могут торпедировать процесс (например, Премьер-министр, который не может отказать клиенту?)
• Что работает для вас?

Answer 1

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

Вот как я управляю своей командой:

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

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

3) В рамках этих этапов мы проводим двухнедельные итерации.Клиент участвует в установке критериев одобрения и определения того, была ли история одобрена.Простая диаграмма сгорания показывает клиенту, насколько мы близки к достижению цели запуска.

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

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

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

Answer 2

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

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

Answer 3

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

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

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

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

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

Answer 4

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

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

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

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

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

Answer 5

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

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

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

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

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

Answer 6

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

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

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

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

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

• Следите за тем, чтобы требования оставались актуальными.

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

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

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

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

Answer 7

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

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