Как вы управляете клиентами в отношении меняющихся требований? - PullRequest
8 голосов
/ 26 января 2009

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

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

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

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

  • У вас есть менеджеры проектов, чтобы изолировать разработчиков от клиента?
  • Есть ли у вас официальный процесс управления изменениями? Менеджеры по смене?
  • Насколько сложно клиенту получить изменение, когда оно ему действительно нужно?
  • И наоборот, насколько легко клиенту получить сдачу, если она "несерьезна"?
  • Сколько деталей вы предоставляете клиенту при объяснении стоимости изменения?
  • Как быстро вы сможете предоставить клиенту эту информацию после получения запроса на изменение?
  • Какие факторы могут ускорить процесс (например, PM, которые не могут сказать клиенту нет? )
  • Что у вас работает?

Ответы [ 7 ]

9 голосов
/ 26 января 2009

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

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

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

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

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

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

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

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

3 голосов
/ 26 января 2009

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

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

2 голосов
/ 26 января 2009

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

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

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

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

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

1 голос
/ 27 января 2009

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

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

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

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

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

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

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

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

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

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

1 голос
/ 26 января 2009

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

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

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

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

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

1 голос
/ 26 января 2009

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

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

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

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

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

0 голосов
/ 27 января 2009

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...