Разрыв в общении:Пользователь против аналитика-дизайнера

Question

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

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

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

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

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

Answer 3

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

Answer 4

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

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

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

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

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