Comments 15
То, что вы описали — это функции бизнес-аналитика (именно так называется эта должность, есть свод знаний по бизнес-анализу — BABOK).
Аналитик на проекте:
— хорошо общается с клиентом
— выясняет функциональные ( и нефункциональные) требования
— создаёт структуру разделов будущего проекта (и документацию вообще)
— разбирается в предметной области заказчика
— обладает набором знаний по психологии
— осведомлён об этапах разработки, способен оценивать их
— рисует мокапы, диаграммы последовательностей, прецедентов,
— анализирует требования на полноту, непротиворечивость и т.п.
— управляет требованиями и изменениями в них на протяжении всего проекта
— общается с ПМ, архитектором, тестировщиками, разработчиками
Курсы по этому есть, книги тоже. Просто, эта должность не очень распространена в маленьких ИТ компаниях, и функции бизнес-аналитика выполняют менеджеры проектов и программисты (у которых нет всех знаний и навыков нужных для BA). Вот например нашла описание на русском системного анализа — это часть бизнес-анализа — функции у системного (и бизнес) аналитика те, что вы описали.
В вашем перечне нет пункта про создание прототипа. То есть, ему нужно будет ставить задачу ux- и ui- дизайнерам. Но вот читаю ваш комментарий и вижу, что в моей статье термины «продавец» и «аккаунт» совершенно неуместны. Там, наверное, и должен стоять бизнес-аналитик.
По вашему списку: разбираться в предметной области заказчика — это что-то фантастическое. Со всем остальным согласен — сбор требований и формирование их в задачи. Проходил через это, работая с леноблгосэкспертизой. Только там ругались на термин «бизнес-процесс». Так как организация некоммерческая, они предпочитали называть это производственными процессами:)
Полноценный прототип аналитик не создаст, так как он не программист. Но делать мокапы входит в его обязанности — чтобы согласовывать их с заказчиком и добавлять их в документацию, чтобы по ним велась разработка.
Я в целом к тому, что в больших проектах для того, что вы хотите — есть отдельный человек, называется он бизнес-аналитик или системный аналитик, это совершенно отдельный человек, с отдельным набором знаний и умений — он не менеджер проектов и не программист. Это отдельная область знаний )
Полноценный прототип аналитик не создаст, так как он не программист

Я говорил об интерактивных прототипах, для создания которых не нужно быть программистом (хотя, конечно, желательно разбираться и в программировании тоже, о чём я и написал в рамках осведомлённости о дальнейших этапах разработки). Лидирующим софтом по созданию таких прототипов сейчас является Axure. Но альтернатив различной степени «узкоспециализированности» тоже довольно много.
Согласованный с заказчиком прототип выигрывает у мокапов на сложных проектах. А ведь мы начинаем говорить именно о сложных проектах, если упоминаем бизнес-аналитика.
И суть моей статьи и заключается в том, что сейчас на рынке очень много специалистов, хорошо разбирающихся в чём-то одном: аналитике, интерфейсах, пользовательских процессах. И практически нет универсалов.
В рамках работы отдельной студии, у которой поток не самых сложных проектов, требования к таким универсалам не так и высоки, а вот пользы они приносят очень много.
Ваше описание, как мне кажется, все-таки более широко, чем роль бизнес-аналитика. Скорее оно соответствует роли Менеджера по управлению продуктом (Product Manager) в контексте методологии NPD, например.

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

А на английском языке много хороших статей есть здесь — www.svpg.com. Это блог группы Марти Кагана, автора замечательной книги «Inspired: How To Create Products Customers Love». Эта книга как раз для тех, кого вы описали в своем посте.
Я не могу в маленьком комментарии описать полностью функции и обязанности бизнес-аналитика, но я не далее как 2 месяца назад закончила вот этот курс ba-space.org/2013/11/15/kurs-osnovy-biznes-analiza-ot-kateriny-makarenko-nabor-3/ — посмотрите в таблицу «содержание курса» — в ней описано, чему учат бизнес-аналитиков. В посте я вижу, что от «проектировщика» хотят именно это — общаться с заказчиком, создавать структуру проекта, делать прототип в виде мокапов, обладать знаниями в бизнес-области заказчика, и знать суть процессов разработки.
Проектировщик немного больше должен знать о проектировании, чем то что можно рассказать за 2 семинара, как в курсе на который вы ссылаетесь.

PS мокапы и прототипы это совершенно разные вещи. Мокап это набросок, а прототип это более поздняя стадия проработки интерфейса.
Согласен, что мокап и прототип — это разные вещи. Но мокап — это средне или высоко детализированное статичное представление дизайна. Очень часто мокап — это черновик дизайна или даже фактический дизайн-макет.

Мокапы часто путают с вайрфреймами из-за названий таких программ как Mockingbird, Mockup Builder, Balsamiq Mockups.

Из переводной статьи Wireframing, Prototyping, Mockuping — What’s the Difference.
Да, все верно, роли бизнес-аналитика и Product Manager сильно пересекаются. Разница лишь в том, что Product Manager еще и отвечает за выполнение разработки при заданных ограничениях ресурсов и стратегию развития продукта (мне показалось, что для автора поста это также важно). Вот, украду сюда хорошую картинку для иллюстрации роли Product Manager.

image

На самом деле, все эти определения ролей довольно условны. Понятно, что хороший программист должен быть еще и немного бизнес-аналитиком, а хороший бизнес-аналитик немного программистом — то есть один человек должен сочетать в себе несколько ролей. Просто концепция роли Product Manager хорошо подходит для компании, которая разрабатывает свой продукт. А роль бизнес-аналитика в широком понимании востребована в компании аутсорсере или интеграторе. А по факту это может быть один и тот же человек, конечно.
Распространением информации о роли менеджера (ИТ-)продукта в СНГ занимаются баркэмпы Product Camp Russia & Eastern Europe: productcamp.ru/

То, что написала Елена — это именно работа по исследованиям, анализу и концептуальному проектированию в ЗАКАЗНЫХ и ВНУТРЕННИХ проектах. Тут ключевая компетенция — правильно понять проблемы конкретного клиента, поставить цель, сформулировать свойства целевой системы и донести их до команды. Эта компетенция традиционно называется бизне-анализ, разработка требований и системный анализ, хотя по факту проектирования в работе тоже хватает.

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

Если интересно посмотреть глубже, смотрите профстандарты «Системный аналитик» и «Менеджер ИТ-продукта», в их создании кстати принимал участие Дмитрий: www.apkit.ru/committees/education/meetings/standarts.php
Можно было не писать столько текста, а просто сказать — если нет бюджета отдельно на solution architector-а и аналитика, всю работу делает PM.
Only those users with full accounts are able to leave comments. Log in, please.