Должен ли разработчик программного обеспечения понять, что имел в виду клиент под своим запросом?

Отчасти вопрос да / нет и почему?

Является ли разработчик программного обеспечения обязанностью понять, что имел в виду клиент под своим запросом, или клиент обязан правильно объяснить свой запрос разработчику?

Ситуация на работе в настоящее время такова: «клиент уже объяснил нам, что он хочет. Это ваша ответственность - понять запрос, а не задавать больше вопросов».

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

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

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

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

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

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

Но, в конце концов, должен быть НЕКОТОРЫЙ вид общения. Если они это отрицают (а предоставление некоторых документов, которые вы не понимаете, фактически запрещает общение), вам следует поступить так, как это делали ваши предшественники: быстро убежать.

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

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

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

По моему мнению, и клиент, и разработчик должны понимать проблему и ее решение одинаково .

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

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

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

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

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

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

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

ИМО причина 2 маловероятна. Чтобы устранить причину 1, попробуйте объяснить ему альтернативы и попросите его сделать явный выбор между ними - предложите объяснить проблему клиенту, чтобы уменьшить раздражение. Чтобы устранить причину 3, сделайте это в письменной форме, чтобы доказать, что вы знали о потенциальных проблемах на ранних этапах и пытались их устранить. Но, честно говоря, если вы подозреваете, что это необходимо, вам, вероятно, следует как можно быстрее добраться туда.

Я думаю, что поставщик услуг всегда должен убедиться, что он понял намерения клиентов.

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

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

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

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

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

Это основано на некоторой новой информации в комментариях к исходному вопросу.

Утверждение, что

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

исходит от руководителя проекта; заявленное обоснование

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

То, что вам конкретно говорят избегать, так это беспокоит клиента вопросами .

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

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

что хотят эти люди ???

спроси что-то вроде

В пункте 17 документа с требованиями говорится, что foobar должен сморщить морду; К какому из этих трёх случаев относится это?

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

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

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

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

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

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

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

• Размер команды
• Стандарты компании
• Как босс используется для работы
• Различный опыт среди членов команды

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

РЕДАКТИРОВАТЬ: Самое главное, клиент может не знать, что он выдвинул такие плохие требования, и процесс сбора требований часто является длительным и утомительным, но это важный процесс, и если он падает на вас, потому что никто больше не делает, то вы должны сделай это с ними.