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

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

клиент: вы могли бы включить это!

Us: не было в спецификации!

клиент: Здравый Смысл!!

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

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

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

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

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

теперь, что касается вопроса о том, следует ли его выполнять:

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

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

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

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

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

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

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

Адам

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

• обзор прогресса часто с клиентом-чтобы свести к минимуму сюрпризы.

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

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

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

• относитесь к клиенту как к одной команде с ними. Не принимаю, будучи формально расписано как противника.

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

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

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

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

два способа: или сказать им ** off или вы имеете дело с ним.

Если вы решите иметь дело:

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

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

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

Как только вы находитесь в фиксированной ставке рассола, хотя, ваши варианты: 1) Сделать это за дополнительную плату. 2) Сделать это бесплатно. 3) Не делайте этого.

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

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

удачи.

"Как вы реагируете?"

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

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

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

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

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

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

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

2. долгосрочные. Убедись, что они тебя больше не тронут. Обзор рано и часто, используйте гибкие методы. Общайтесь больше, прототип больше, выпускайте больше.

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

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

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

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

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

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

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

одна вещь, я обнаружил, что вы можете сделать, чтобы пользователи согласились в Spec s на время t, но в момент времени t + N в, заставляя их помнить, что они согласились спецификаций С или заставить их признать, что они таки да (с документами было у тебя, я надеюсь!) может быть сложнее, чем должно быть.

говоря с темой и вопросом OP:

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

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

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

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

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

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

однако, если вы выше или являетесь консультантом программиста, то сначала и формост

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

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

спасибо,

-Ричард

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

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

клиент: вы могли бы добавить это!

нас: не было в спецификации!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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