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

Question

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

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

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

Answer 1

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

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

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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

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

Answer 4

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