Должен ли программист «думать» за клиента?

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

В среде типа «водопад» (требования - сначала почти готовый продукт, затем -) все может стать ужасным. Такая среда привела меня к постоянному сомнению в требованиях. Например, клиент хочет «автоматически преобразовать ввод в число 1» (имея в виду кол-во в заказе). Но о чем они не думают, так это о том, что «ввод» может быть простым вводом. «X» в текстовом поле может быть «woops», а я не хочу 1 из этих «зубных паст» продуктов. Но в воздухе так много требований, которые я мог часами стоять и исправлять, выбивая то, что они хотят. Это просто не здорово.

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

Как справиться с проблемой «мышления для клиента», не отвлекая их слишком большим количеством вопросов?

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

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

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

Я настоятельно рекомендую работать кусками. При встрече с клиентом предъявляют ряд требований, которые связаны друг с другом, а затем объясняют, как вы собираетесь делать то, что они хотят. Также объясните, почему вы сделали свой выбор. Затем клиент может посмотреть, что вы предоставили, и точно настроить его. Если вы получите ответ типа «Я никогда не думал об этом, но это действительно помогло бы», вы знаете, что у вас есть импульс на то, как думает клиент. ПРИМЕЧАНИЕ: это не фуритурит, это выбор правильных функций, которые наилучшим образом соответствуют бизнес- задачам клиента.

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

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

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

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

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

Прочитайте это для получения дополнительной информации: http://www.joelonsoftware.com/articles/fog0000000356.html

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

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

Если вы собираете требования, тогда ваша задача - задавать эти вопросы.

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

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

Это относится независимо от того, занимаетесь ли вы Big Design Up Front или Agile.

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

У меня были оба возможных результата:

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

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

Быстрая разработка приложений (RAD) решает эту проблему наилучшим образом .

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

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

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

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

Работа клиента - передать вам то, что ему нужно. Ваша задача - понять, что им нужно, достаточно хорошо, чтобы иметь возможность программировать то, что им нужно. Очевидный вопрос к вопросу об изменении всех входных данных на один состоит в том, чтобы сказать: «Почему вы хотите изменить все входные данные на 1?» Затем клиент может объяснить причину, стоящую за этим, чтобы вы поняли необходимость, а затем смогли предоставить не обязательно то, что они просят, а то, что им нужно. Если вы уверены, что знаете, что им нужно, то я не думаю, что вам обязательно нужно «исправлять» их мышление. Они будут использовать продукт и вещь "О! Это прекрасно". Но если вы не уверены, что знаете, что им нужно, вам нужно будет объяснить, что вы думаете, и решить это с клиентом. К сожалению Невозможно выполнить эту часть процесса без большого количества общения, которое включает в себя реальное прослушивание обеих частей. Будьте осторожны, чтобы не раздражаться из-за сложившейся ситуации и говорить то, что вы можете или не хотите говорить.

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