Разрыв в общении:Пользователь против аналитика-дизайнера
-
01-07-2019 - |
Вопрос
Обычной практикой является использование тематических исследований, построение рабочих потоков и потоков данных и т. д.Но это не обязательно приводит к созданию общего словаря между пользователем/спонсором и аналитиком-дизайнером:одному или другому, как правило, обоим придется усваивать термины и взгляды на «внутреннее устройство» области знаний другого, и это обычно приводит к недоразумениям и встречам для разъяснений (введите RAD-методы, такие как эволюционное прототипирование) и т. д. .
Пользователь/спонсор сосредоточен на своих потребностях/окружении и не хочет и не должен быть вынужден приобретать, с его точки зрения, несвязанную с ним «терминологию программирования».Ответственность за изучение новой среды лежит на аналитике/дизайнере (/программисте).
Как преодолеть кривую обучения?Что вам подходит, когда вы сталкиваетесь с пользователем, которому нужно программное решение?
Решение
Постарайтесь устранить как можно больше промежуточные шаги между пользователем и конечным разработчиком, насколько это возможно.Каждый такой шаг затемняет и теряет информацию.Самыми ценными членами вашей команды могут быть люди, которые умеют носить оба костюма - «взаимодействовать» с пользователями и фактически реализовывать вещь.
Если нет, убедитесь, что у вас есть быстрые итерации и реализовывать вещи итеративно.Его легко спутать с инкрементальным.Разница в том, что при итеративном подходе у вас есть широкий спектр функций, реализованных в небольшой, но однородной степени.При поэтапном подходе вы реализуете большие фрагменты функциональности один за другим.
При итеративном подходе у вас есть преимущество: ловкость. Пользователь передумал, или произошло какое-то недопонимание?Ничего страшного, еще есть куда меняться.Надеюсь, что было потрачено не так много усилий.
Другие советы
Я использую комментарии
«Если вы не можете объяснить свою физику барменше, это не очень хорошая физика» и «Вы ничего не поймете по-настоящему, если не сможете объяснить это своей бабушке» (приписывается Резерфорду и Эйнштейну)
как мантры, когда я говорю о требованиях с клиентами.
Возьмите двухсторонний подход: презентацию высокого уровня, Powerpoint или доску, и, если вы можете, позвольте пользователям свободно работать с POC или макетом.
Затем выполните подробные построчные требования.Дьявол кроется в деталях.Попросите их подписать эти данные.Пометьте и пронумеруйте их, чтобы они могли выполнить построчный анализ.
Если вы выполняете подробные требования до установки высокого уровня, пользователи никогда не поймут какие-либо концепции дизайна и не увязнут в мельчайших деталях спецификации.Без каких-либо рамок или концепций пользователи будут вращаться вокруг количества ангелов на булавочной головке.
Гибкость и итерации хороши, если клиент и команда разработчиков могут говорить на одном языке.Убедитесь, что ожидания установлены и оправдываются.
Хороший дизайнер взаимодействия должен уметь описать работу программного обеспечения простым языком.Если нет, то ему не стоит заниматься фронтендами, ИМХО.
Для этого требуется целый ряд техник, и обеим сторонам необходимо научиться в некоторой степени понимать бизнес друг друга:то естьаналитики должны получить представление о предметной области пользователя, а пользователь должен ознакомиться с некоторыми методами аналитики.
Я считаю, что процессные потоки — хороший способ начать, договориться на высоком уровне о том, как работает бизнес.Некоторые пользователи хорошо разбираются в моделях данных (например, ERD), но в целом я бы сказал, что это не так:они часто реагируют лучше, когда правила изложены в тексте, например.
- Ордер может состоять из одной или нескольких строк ордера.
- Каждый заказ имеет уникальный 10-значный ссылочный номер.
Им гораздо легче прочитать и отметить их, чем проверить качество ERD.
Кроме того, ничто не сравнится с эскизами экранов ввода и отчетами, которые помогают пользователям сосредоточиться на деталях того, что они хотят.