Как бороться с плохо информированным выбором клиентов

Question

Вот сценарий, с которым, я уверен, вы все знакомы.

1. У вас довольно «невнятный» клиент, который действительно не хочет слишком увлекаться принятием решений, несмотря на все ваши усилия.

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

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

4. Несмотря на объяснения, клиент не заинтересован, он просто хочет, чтобы это изменилось.

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

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

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

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

Кто-нибудь знает, как вы справляетесь с этим?

РЕДАКТИРОВАТЬ: Упс - кстати, я не говорю о каких-либо текущих или недавних клиентов в этом. Это чисто гипотетически ...

Answer 1

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

Чем больше работаешь, тем больше получаешь. Заказчик должен будет заплатить за свои ошибки.

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

Answer 2

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

Четкое определение воздействия (большая стоимость, меньшая надежность, более длительное время доставки и т. Д.) Очень важно, чтобы помочь клиенту принять решение. Очень важно описать воздействия на проект или их бизнес на фактической основе и оценить, насколько вероятно, что это воздействие произойдет. «Maybes» и «я чувствую» очень невежественны.

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

Answer 3

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

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

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

Answer 4

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

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

На самом деле, использование прототипа, вероятно, было бы наиболее полезным инструментом для использования. Подумайте об эффекте айсберга. Секрет в том, что люди, которые не являются программистами, не понимают этого. http://img134.imageshack.us/my.php?image=icebergbelowwater.jpg

"Вы знаете, как айсберг находится на 90% под водой? Ну, большинство программного обеспечения тоже такое - есть симпатичный пользовательский интерфейс, который занимает около 10% работы, а затем 90% работы по программированию находится под прикрытием .... "- Джоэл Спольски

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

Второй выпуск:

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

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

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

Проблема:

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

Альтернативные решения:

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

2) Наденьте пару Nike. Основные ботинки для бега. Попробуйте новейшие стили.

Реализованное решение:

Черные замшевые туфли были лучшим выбором, потому что ... хорошо, потому что горячие мамочки рыли черные замшевые туфли.

Answer 5

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

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

Этот подход не дает хороших решений (что неудивительно), но позволяет клиенту понять, что это не "внутреннее чувство", дикий удар в темном вопросе.

И если этого не сделать, они обычно перестают просить вас изменить его!

Answer 6

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

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