Как реагировать, когда ответ клиента отрицателен по доставке? [закрытый]

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

У меня было это однажды. И к счастью это не был я, который создал дизайн, потому что это оказалось проблемой.

Это имеет огромное значение, что communcation между Вашей компанией и клиентом максимально прекрасен. Убедитесь, что Вы понимаете друг друга. Задайте вопросы и позвольте им задать вопросы. Не позволяйте ничему открыться в дизайне. Это будет проблемной точкой при доставке. И имейте регулярные встречи во время проекта (предпочтительно с предварительным выпуском).

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

Необходимо запустить его вначале; скажите клиенту, рано и часто, что spec/use-cases/user-stories являются контрактом, которые определяют то, что будет поставлено. в гибкой среде существует много возможностей для клиента наблюдать некоторую "разумную" функцию, которую они хотят и просят ее, который является одним из преимуществ гибкого подхода, но если Вы начинаете принимать "разумные" дополнения в конце, Вы готовитесь к бесконечным расширениям, вероятно, за Ваш счет.

Некоторые клиенты ожидают это; чем больше и лучше Вы говорите им, что они не могут, тем легче возможные аргументы будут.

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

Поэтому команды I/the, с которыми я работал всегда используемый подход опытного стиля, который означает:

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

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

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

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

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

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

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

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

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

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

С точки зрения Вашего литерального вопроса, как реагировать, лучший способ состоит в том, чтобы проигнорировать Ваше эго ("что?! После того, как я упорно работал так на этом и встретил спецификацию?!"), и вместо этого фокусируются на некотором активном слушании и работе к согласию.

Клиент: Вы, возможно, включали это!

Нас: не Был в спецификации!

Клиент: здравый смысл!!

Нас: Я понимаю, что Вы не рады, что мы не пошли вне границ спецификации. Наблюдение, что Вы думаете об этом, как мы можем сделать Вас счастливыми? Давайте посмотрим, существует ли процесс, который мы можем создать вместе, который поможет всем.

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

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

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

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

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

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

Разговор с предметом и вопросом OP:

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

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

Теперь, если бы они "подвешивают Вас для сушки", затем я рекомендовал бы следующие вопросы:

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

b) "Ну, я уверен, что мы могли включать это в следующий выпуск. Я оставлю его до XXX (боссы) для прибытия во взаимоприемлемый подход" (т.е. не говорите стоимость или бесплатные наборы с присутствующими боссами. КОГДА-ЛИБО.)

Снова, это предполагает, что Вы - программист, РАБОТАЮЩИЙ на компанию, которая поставила продукт. Теперь, если больше, чем тот - т.е. Вы - одни из более высоких взлетов, затем многие предложения здесь превосходны.

Однако, если Вы - большая шишка или являетесь программистом консультанта, затем сначала и formost

a) Принесите извинения за процесс, который не поймал это требование. Обещайте работать с клиентом, чтобы препятствовать тому, чтобы это повторилось.

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

Удачи,

- Richard

"как Вы реагируете?"

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

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

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

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

Если Вы хотите отношения, Ваша реакция имеет две части.

1. Краткосрочный. Получите что-то, чем они довольны. Они должны определить определенные изменения. Необходимо выиграть каждое изменение со "стоимостью, чтобы сделать" и "соответствие со спецификацией".

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

2. Долгосрочный. Удостоверьтесь они, Вы не PA'd снова. Рассмотрите рано и часто, используйте Гибкие методы. Свяжитесь больше, прототип больше, выпустите больше.

ZiG, я должен был несколько раз иметь дело с этой проблемой в моем текущем месте Занятости. Моя группа (3 разработчика) пытается приблизиться к вещам Гибким способом. Мы привыкли получать середину реки и даже запросы в последнюю секунду (который мы затем рассматриваем в зависимости от конкретного случая).

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

Одна вещь, которую я нашел, состоит в том, что можно заставить пользователей соглашаться на Спецификацию S в Time T. However в Time T + N, заставив их помнить, что они согласились на Спецификацию S или то, чтобы заставлять их подтвердить, что они сделали так (с документацией, которую Вы сохраняли, я надеюсь!) может быть более хитрым, чем это должно быть.

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

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

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

После того как Вы находитесь в фиксированном рассоле предложения, тем не менее, Ваши опции: 1) Делаете это по дополнительной стоимости. 2) Делаете это свободный. 3) Не делаете этого.

Опция 3 хуже, и Опция 1 является лучшей. Если у Вас есть хорошие доверчивые отношения и достойная связь с клиентом, обычно легко прибыть в Опцию 1. Если отношения плохи, то у Вас есть большие проблемы. В той точке просто старайтесь избегать laywers.

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

Удачи.

Классический случай...

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

Наверняка, Вы не можете восстановить все это бесплатно.

Два пути: Или сказать им ** прочь или Вы имеете дело с ним.

Если Вы принимаете решение иметь дело:

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

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

Используйте ТОЛПУ как подходы для предотвращения этого гиблого места: вовлеките клиент в процесс dev рано, часто и в неофициальные, ограниченные комитеты-> снижение риска и улучшенная гибкость.

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

• Ожидайте последние изменения объема - они всегда происходят, так быть готовы.

• Обзор часто делает успехи с клиентом - для уменьшения неожиданностей.

• Контракт: Функциональная Спецификация, плюс Время и Материалы с начальным ограничением (таким образом, клиент чувствует управление). Затем, когда изменения приходят, пересматривают ограничение при необходимости.

• Никогда не говорите, что они не могут иметь то, что они хотят. Они могут получить тот ответ бесплатно!

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

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

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

Клиент: Вы, возможно, включали это!

Нас: не Был в спецификации!

Клиент: здравый смысл!!

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

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

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

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

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

Теперь, относительно вопроса того, необходимо ли реализовать его:

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

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

Если это - проблема UI, то Вы находитесь в более темной воде.

Спецификация соответственно описывает UI? Это имеет макеты? Я не дал бы сбой клиент для этой жалобы на UI, если бы спецификация очень тесно не описала расположение, использование, и включала макеты.

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

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

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

- Adam