Работа с клиентами, которые не знают, чего хотят

19

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

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

Майкл К
источник
1
Это должно быть лучше, чем наоборот, клиенты, которые знают, что они хотят, но не то, что им нужно.
Крейг
2
Знают ли клиенты когда-нибудь, чего они хотят?
Доминик Макдоннелл
6
«Клиент не знает, чего он хочет, пока вы не дадите ему то, о чем он просил»
Бенджол
Давным-давно я начал фантазировать о найме аналитиков из организованной преступности. "Ты собираешься сказать мне, что происходит, когда клиент не находится в базе данных, или я не справился?"
Дэвид Торнли
Пожалуйста, следуйте этому предложению для такого рода вопроса: Организационные аспекты
Maniero

Ответы:

20

Несколько советов:

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

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

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

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

GSto
источник
2
Отличный список, особенно пункт 1. Многие клиенты спрашивают: «Можете ли вы добавить здесь кнопку, которая делает X» ... но если вы спросите, зачем им эта кнопка, вы узнаете ее, потому что они пытаются решить какую-то кнопку. проблема у них с совершенно другой функцией.
GrandmasterB
2
Небольшое дополнение к первому пункту - если им нужна функция для облегчения какой-либо задачи, спросите, можете ли вы посмотреть, как они выполняют задачу сейчас. Это может значительно облегчить понимание реальной проблемы и потенциальных ошибок.
Гленатрон
@glenatron: Это очень хорошая идея, особенно поскольку я не могу выучить всю систему.
Майкл К
@Gsto: На # 2, вы говорите о программисте, пишущем запрос с помощью клиентского ввода, или о клиенте, пишущем его? Одна из моих проблем заключается в том, что письменный запрос клиента является неточным.
Майкл К
Я часто заставляю клиента или заказчика действительно доказать, что функция или изменение необходимы и улучшат ситуацию. Вы можете не иметь такой роскоши, но если вы можете заставить клиента или заявителя показать вам, что они в полной мере понимают, почему они хотят изменения и как это пойдет на пользу другим, вы можете предложить альтернативу для удовлетворения их потребностей вместо их хочу.
Иосиф
5

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

  • Ищите сначала понять, а затем быть понятым

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

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

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

Скотт Уитлок
источник
4

Я чувствую твою боль....

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

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

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

В общем, мой совет таков:

Если такова ваша конкретная отрасль и эти клиенты (это большой ЕСЛИ), то просто привыкните к этому. Думайте об этом как о Agile, ориентированной на обслуживание работе (таков мой нынешний концерт, более или менее). :)

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

Бобби Столы
источник
1
Это на самом деле вполне нормально, но я бы хотел изменить это хотя бы для своих проектов. Я думаю, что многие из этих запросов можно было бы перевернуть гораздо быстрее - простой может занять 3-4 (или более) недели в зависимости.
Майкл К
2

Прежде всего, вы должны принять тот факт, что клиенты на самом деле не знают, что они ищут, пока не увидят это. Они могут прямо сейчас сказать вам, что им нужна функция X. Покажите им функцию X, и они поймут, что им действительно нужна функция Y или другой вариант функции X.

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

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

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

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

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

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

Тим Пост
источник
1

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

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

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

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

Gruffputs
источник