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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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