Коммуникационный разрыв: Пользователь против аналитика-дизайнера

Question

Нормальная практика заключается в использовании тематических исследований, построении потоков данных и данных и т. Д. Но это не обязательно создает общий словарь между пользователем/спонсором и аналитиком-дизайнером: один или другой, как обычно, придется приобретать термины и взгляды на «внутренности» других областей знаний, и это обычно приводит к недоразумениям и встречам для уточнения (вводить RAD-методы, такие как эволюционное прототипирование) и т. д.

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

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

Answer 1

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

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

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

Answer 2

Хороший дизайнер взаимодействия должен иметь возможность описать работу программного обеспечения в условиях неспециалиста. Если нет, он не должен делать интерфейсы, ИМХО.

Answer 3

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

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

• Заказ может состоять из одного или нескольких Order Lines
• Каждый Орден имеет уникальный 10-значный идентификационный номер

Они могут прочитать и тик или пересечь те гораздо легче, чем они может проверить качество ERD.

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

Answer 4

Я использую комментарии

«Если вы не можете объяснить свою физику буфетчицы, это не очень хорошая физика» и «Вы действительно не понимаете что-то, если вы не можете объяснить это свою бабушку» (Приписываются Резерфорд и Эйнштейн)

как мантры, когда я говорю с требованиями клиентов.

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

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

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

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