Аналитик — арбитр между бизнесом, проектированием и разработкой, который периодически смещается в ту или иную сторону, но при этом удерживает процесс создания мобильного продукта в поле здравого смысла. Он обеспечивает коммуникацию между всеми участниками процесса, транслируя знания от одной группы в другую, чтобы выдвинутые гипотезы и принятые впоследствии решения были обеспечены достаточным количеством информации.
Бизнес — всегда думает о достижении своих KPI, но редко понимает сложность разрабатываемой системы и удобство для пользователей.
UX-проектировщик — всегда думает о пользователе, иногда в ущерб бизнесу. Не всегда явно понимает цель бизнеса и пытается навязывать свои идеи.
Разработчик — думает, как сделать все классно с точки зрения архитектуры системы и программного кода. Пытается примерять пользовательские сценарии на себя, но является технически подкованным человеком, что не свойственно для большинства пользователей.
Если про передачу требований от уровня бизнеса к системному уровню сказано немало и выработался определенный инструментарий, то вот какие артефакты использовать для взаимодействия и передачи знаний между бизнесом, аналитиком и UX-проектированием — вопрос открытый. Этой темой я продолжаю цикл статей по бизнес-анализу в мобильной разработке.
Аналитик — арбитр между бизнесом, проектированием и разработкой, который периодически смещается в ту или иную сторону, но при этом удерживает процесс создания мобильного продукта в поле здравого смысла. Он обеспечивает коммуникацию между всеми участниками процесса, транслируя знания от одной группы в другую, чтобы выдвинутые гипотезы и принятые впоследствии решения были обеспечены достаточным количеством информации.
Бизнес — всегда думает о достижении своих KPI, но редко понимает сложность разрабатываемой системы и удобство для пользователей.
UX-проектировщик — всегда думает о пользователе, иногда в ущерб бизнесу. Не всегда явно понимает цель бизнеса и пытается навязывать свои идеи.
Разработчик — думает, как сделать все классно с точки зрения архитектуры системы и программного кода. Пытается примерять пользовательские сценарии на себя, но является технически подкованным человеком, что не свойственно для большинства пользователей.
Если про передачу требований от уровня бизнеса к системному уровню сказано немало и выработался определенный инструментарий, то вот какие артефакты использовать для взаимодействия и передачи знаний между бизнесом, аналитиком и UX-проектированием — вопрос открытый. Этой темой я продолжаю цикл статей по бизнес-анализу в мобильной разработке.
«Мобильное приложение должно быть «живым», пользователь должен видеть, что проект развивается»
Мы в Redmadrobot работаем по гибким методологиям Agile и Scrum. Как известно, они предполагают значительную свободу в том, как организуются спринты по проектам, — каждая компания подбирает удобную для себя модель. Кейсов — информации о том, как организуются команды во время выполнения спиринтов — во внешних источниках крайне мало. Раскрываем свою “кухню”.
«Мобильное приложение должно быть «живым», пользователь должен видеть, что проект развивается»
Мы в Redmadrobot работаем по гибким методологиям Agile и Scrum. Как известно, они предполагают значительную свободу в том, как организуются спринты по проектам, — каждая компания подбирает удобную для себя модель. Кейсов — информации о том, как организуются команды во время выполнения спиринтов — во внешних источниках крайне мало. Раскрываем свою “кухню”.
Аналитик — арбитр между бизнесом, проектированием и разработкой, который периодически смещается в ту или иную сторону, но при этом удерживает процесс создания мобильного продукта в поле здравого смысла. Он обеспечивает коммуникацию между всеми участниками процесса, транслируя знания от одной группы в другую, чтобы выдвинутые гипотезы и принятые впоследствии решения были обеспечены достаточным количеством информации.