Большинство
людей считают, что для разработки какой-то программы нужны только программисты,
ведь именно они пишут код и воплощают мечту заказчика в реальность. Но между
тем, что говорит заказчик и тем, что в итоге сделает программист, — целая
пропасть. Не потому что они — плохие люди или не хотят общаться и понимать друг
друга, а потому что заказчик мыслит в масштабе цели, думает, что должна делать
программа, для чего он хочет ее использовать. А программист обязан думать, как
программа должна работать, откуда брать данные, как назвать новую колонку в
таблице данных и т. д., проще говоря, думать о деталях реализации.
На
самом деле, существует очень мало людей, способных гибко настраиваться на
различные виды задач – от анализа бизнеса, до построения архитектуры будущего
«решения» существующей «проблемы». Большинство бизнес-аналитиков имеют узкую
«специализацию», которая зависит от «направления» будущего проекта, ожидаемых
бизнес-целей организации или заказчика, своего опыта в «исследуемой области», и
т.д.
Выделим
роли (названия), которые обычно ассоцируются с бизнес-анализом:
• Бизнес-аналитик
• Аналитик бизнес-процессов
• IT бизнес-аналитик
• Системный аналитик
• Аналитик данных
• Инженер пользовательских интерфейсов и удобства
использования
Ниже
представлены еще несколько названий, которые часто используются во многих
компаниях и как они соотносятся с вышеупомянутыми ролями:
В любом
случае, большинство организаций просто дает БА любое название, которое им
удобно, в то время как фактические роли БА могут отличаться, в зависимости от
типов/целей проектов и естественно от роли БА в команде.
Бизнес-аналитик
• имеет дело с анализом бизнеса
• имеет опыт и знания в предметной области
• решает оперативные задачи
• решает проблемы бизнес-процессов
• совершенствует существующую бизнес-модель
Мы
описали конкретную роль, а не общий термин «бизнес-аналитик». Это - аналитик,
который специализируется в заданной бизнес-области или исследуемом рынке.
Основная роль этого аналитика – провести анализ бизнес-процессов, процедур,
организационную структуру и т.д., чтобы выявить «проблемы» и определить
«варианты» их решения.
«Решения»,
созданные этим аналитиком, направлены на внедрение новых или изменение
существующих бизнес-процессов, внедрение новых или изменение существующих
процедур, и т.д.
Аналитик бизнес-процессов
• Описывает модели бизнес-процессов
• Моделирует бизнес-процессы
• Исследует технологический процесс и работу
существующих процессов
• Сравнивает «что есть» и «что необходимо»
Аналитик
бизнес-процессов является скорее специализацией роли «Бизнес аналитик».
Он
использует программное обеспечение для моделирования исследуемых
бизнес-процессов. Модели впоследствии смогут быть проанализированы и
использованы непосредственно в «решениях» для бизнеса.
Аналитики
бизнес-процессов помогают топ-менеджменту в принятии дальнейших решений
(моделируя или имитируя сценарии типа «что – если»).
Другие,
похожие названия этой роли: инженер бизнес-процессов, инженер технологического
процесса, модельер бизнес-процессов, бизнес-аналитик (общее название или
термин), и т.д.
IT бизнес-аналитик
• Сосредоточен на сборе требований и требованиях,
как таковых для IT-систем.
• Решает проблемы с IT-решениями
• Связывает «бизнес» и IT-решения
• Определяет функциональные границы будущей
IT-системы
IT
бизнес-аналитик - специалист, основной обязанностью которого является сбор
информации и «требований» с последующим их анализом и решением «проблем» с
использованием информационных технологий. Эта роль – связующее звено между
бизнесом и областью IT .
Другие
похожие названия этой роли: инженер требований, аналитик требований, прикладной
консультант, прикладной аналитик, бизес-аналитик (общее название), и т.д.
Инженер требований
• Работает непосредственно с заинтересованными
лицами
• Выявляет требования
• Анализирует требования
• Документирует требования
• Может создавать функциональные спецификации
Инженер
требований - термин, который часто используется вместе с IT бизнес-аналитиком,
хотя многие люди видят эту роль, занятую только сбором требований и их
документированием. На самом деле, нет никакого четкого определения области
работы для данной роли.
Из
существующего опыта, этот термин больше относится к роли, которая находится
где-то между IT бизнес-аналитиком и системным аналитиком.
Зона
ответственности инженера требований – работа с заинтересованными лицами и
конечными пользователями, с целью выявления, понятия, анализа и
документирования требований к будущей системе, которая поможет решить
существующую проблему .
Аналитик бизнес-систем
Аналитик
бизнес-систем - специалист, обязанности которого начинаются со сбора требований
и заканчиваются документированием функциональных/технических спецификаций. В
основном «Аналитик Бизнес-систем» это «IT бизнес-аналитик» + «Системный
аналитик».
Опытные
аналитики бизнес-систем - это не только
специалисты в бизнесе, но и в области системного анализа и архитектуры систем.
Системный аналитик
• Основывается на требованиях в качестве входных
данных
• Описывает функциональные требования
• Определяет, как система будет себя вести в той
или иной ситуации
• Взаимодействует непосредственно с
разработчиками
Системный
аналитик это IT бизнес-аналитик, который сосредоточен на системных и
технических требованиях к поставленной задаче или «решению».
Основная
роль системного аналитика – описание системных требований (они вообще не
участвует в конечном сборе требований), которые используются для создания
функциональных и технических спецификаций-требований к будущей системе.
Системный
аналитик - специалист, который определяет «четкие» границы требований,
определяет функциональные решения и работает с командой разработчиков (архитекторы
СУБД и непосредственные разработчики), кроме того он создает документы,
описывающие технические требования и решения дизайна.
Аналитик данных
• Моделирует логическую структуру данных
• Определяет логическую и физическую структуру
записываемых данных
• Проектирует отчетную информацию для
заинтересованных лиц
Аналитик
данных – специалист, который занят анализом и решением задач, связанных с
данными, типами данных, и отношений между элементами данных в бизнес-системе
или IT системе.
Функциональный архитектор
Функционального
архитектора можно представить, как среднее между бизнес-аналитиком, менеджером
продукта и инженером пользовательских интерфейсов и удобства использования
(Usability/UX). На многих проектах ФА работает как технический архитектор для разработки
функционального поведения системы.
Эта
роль очень похожа на менеджера продукта за исключением того, что функциональный
архитектор не занят задачами, которые связаны с управлением
разрабатываемым/выпускаемым продуктом: управление выпуском версий, временем
выхода на рынок, и т.д.
Эта
роль очень похожа на бизнес-аналитика, кроме того, даже на больших проектах,
есть только один ФА, который обладает знаниями об общей концепции продукта, его
функциях и особенностях его применения.
Инженер пользовательских интерфейсов и
удобства использования
• Имеет навыки проектирования графических
элементов интерфейса
• Сосредоточен на легкости и простоте пользования
продуктом
• Понимает поведение конечных пользователей
• Проектирует «эффективные» интерфейсы
Они создают
макеты, прототипы или модели, которые отражают не только интерфейс будущего
приложениявебсайта, но и то, как конечный пользователь будет взаимодействовать
с интерфейсом.
Бизнес-аналитика
Анализ бизнес-процессов
предприятия посредством создания их моделей позволяет решать широкий круг задач
совершенствования деятельности этого предприятия и повышения его
конкурентоспособности.
Можно выделить четыре основные группы
требований:
1)
требования бизнеса;
2)
требования заинтересованных сторон;
3)
требования решения;
4)
переходные требования.
Целями аналитического моделирования бизнес-процессов могут быть многие аспекты деятельности компании, включая
оптимизацию организационной структуры, функций подразделений и сотрудников,
перераспределение прав и обязанностей руководителей и исполнителей,
совершенствование документооборота и систем информационного обеспечения
управления.
Бизнес-аналитик — это
специалист, который исследует проблему заказчика, ищет решение и оформляет его
концепцию в форме требований, на которые в дальнейшем будут ориентироваться
разработчики при создании продукта.
Главная задача бизнес-аналитика — выявить проблемы бизнеса заказчика и найти максимально
эффективное решение. Для этого он должен обладать знаниями в предметной
области. Бизнес-аналитик работает с требованиями на всех этапах жизненного цикла
разработки ПО и постоянно выступает посредником между заказчиком и командой
программистов.
Роль бизнес-аналитика может
различаться в разных отраслях и организациях, но главный фактор, объединяющий
данную профессию, - оценка изменений на предприятии как проекта, использующего
много ресурсов для действий, направленных на максимизацию выгод организационной
цели. Умелый бизнес-аналитик должен разрабатывать средства для поддержки
доверия и уважения со стороны отдела информационных технологий и коммерческого
отдела организации. Это подразумевает полный набор навыков, включающий в себя
понимание цели организации и роли конкретного проекта в выполнении данной цели.
Чтобы достичь этого, бизнес-аналитик должен понимать, что заинтересованные
лица, работники и руководство являются внутренними клиентами (IC), которых
нужно обслуживать. Поэтому с IC нужно советоваться и расспрашивать их о
влиянии, которое конкретный проект может оказать на различные отделы. Можно
применять различные методологии, такие как шесть сигм, имеющие более
комплексный и структурированный подход к решению проблем. Бизнес-аналитик
должен решать проблемы, а не просто устанавливать факты.
В больших
проектах иногда разделяют роли Бизнес-аналитика
и Системного аналитика. В обязанности
Бизнес-аналитика входит выявление бизнес-целей заказчика, продумывание
концепций решения и формирование требования. В обязанности Системного аналитика
— формализация и спецификация требований, написание технического задания на
уровне функциональных требований и программной реализации.
Работа бизнес-аналитика включает такие
этапы
1.
Выявить потребности заказчика, понять проблему, которую он хочет решить.
2.
Самостоятельно или с помощью команды сформулировать концепцию решения.
3.
Оформить концепцию в техническое задание с конкретными требованиями к будущему
продукту. Для этого используются различные техники бизнес-анализа — постронение
моделей процессов и структур, прототипы пользовательского интерфейса, сценарии
использования. В это же время делается точная оценка трудозатрат и длительности
работ.
4.
Детализировать каждое требование в виде спецификаций.
5.
Консультировать программистов и тестировщиков во время разработки продукта,
спорные моменты обговаривать с заказчиком.
Шаблон разработки
бизнес-аналитиком программного обеспечения жизненного цикла
1. Встретиться с заинтересованными лицами (руководители, поставщики и конечные пользователи), чтобы выявить ориентировочные вопросы, относящиеся к проблеме. Цель – получить разные мнения о макро- и микросостоянии проблемы.
2. Выработать точное описание основной проблемы, согласованное с заинтересованными лицами. Таким образом, все стороны поймут суть проблемы в одном-двух кратких предложениях.
3. Создать имя проекта. Утвердить заданные средства связи по телефону, через папки с документами, с помощью электронной почты или доски объявлений в локальной сети.
4. Выбрать определенных заинтересованных лиц в качестве бета-тестировщиков нового ПО.
5. Встретиться с группой разработчиков ИТ (ITDT), чтобы подробно описать крупномасштабную проблему, с согласованной датой встречи, чтобы передать больше информации. Хороший BA также устанавливает, что с ним можно связаться в любое время на протяжении всего проекта для получения более подробной информации о проекте.
6. BA должен начать анализ осуществимости, включающий в себя опросы руководителей, конечных пользователей и глав отделов касательно системы, технических деталей, коммуникаций, процесса и функциональных требований. Вопросы опроса должны проверять существенные элементы проекта, чтобы предотвратить сбор не важной информации.
7. Собранную информацию нужно проанализировать на предмет бюджета и расходов и представить заинтересованным лицам на утверждение. В некоторых организациях могут требоваться финансовые аналитики для проверки бюджетных требований.
8. После утверждения BA должен предъявить ITDT полную схему проекта. Подробная блок-схема с использованием UML, SAP или Visio должна показывать ожидаемый результат. BA должен подробно сообщить ITDT, что требуется на стороне компании, отвечая без подготовки на любые вопросы или опасения.
9. BA должен начать тщательно документировать предлагаемые изменения в существующей системе, чтобы создать справочник для обучения и поддержки конечных пользователей к концу проекта. Наиболее эффективный способ для экономии ресурсов и времени – разработать сайт в локальной сети компании, предназначенный для поддержки и обучения, с использованием модели ITIL Foundation. Также разработать доску объявлений для отзывов об улучшениях.
10. Оставаться доступным для заинтересованных лиц и ITDT, чтобы они передавали заявки на модификацию и другие сведения, способные повлиять на проект.
11. Встретиться с заинтересованными лицами, чтобы оценить предварительные результаты по первой версии программного обеспечения. Передать плюсы и минусы и рекомендации от бета-тестировщиков ITDT касательно изменений.
12. Проверить улучшения, сделанные для утверждения пользователем. Убедиться, что все ошибки и проблемы документально зафиксированы на будущее.
13. После утверждения окончательного варианта ПО сжато выразить информацию, имеющуюся в документации, в виде краткого полноценного документа Word или PDF для инструкции.
14. Проверять новую систему после полной реализации на наличие ошибок, конфликтов или неполадок. Измерять улучшения по сравнению с модификациями системы.
15. Начать новый цикл улучшений тогда, когда оговорено в пункте 1.
1. Встретиться с заинтересованными лицами (руководители, поставщики и конечные пользователи), чтобы выявить ориентировочные вопросы, относящиеся к проблеме. Цель – получить разные мнения о макро- и микросостоянии проблемы.
2. Выработать точное описание основной проблемы, согласованное с заинтересованными лицами. Таким образом, все стороны поймут суть проблемы в одном-двух кратких предложениях.
3. Создать имя проекта. Утвердить заданные средства связи по телефону, через папки с документами, с помощью электронной почты или доски объявлений в локальной сети.
4. Выбрать определенных заинтересованных лиц в качестве бета-тестировщиков нового ПО.
5. Встретиться с группой разработчиков ИТ (ITDT), чтобы подробно описать крупномасштабную проблему, с согласованной датой встречи, чтобы передать больше информации. Хороший BA также устанавливает, что с ним можно связаться в любое время на протяжении всего проекта для получения более подробной информации о проекте.
6. BA должен начать анализ осуществимости, включающий в себя опросы руководителей, конечных пользователей и глав отделов касательно системы, технических деталей, коммуникаций, процесса и функциональных требований. Вопросы опроса должны проверять существенные элементы проекта, чтобы предотвратить сбор не важной информации.
7. Собранную информацию нужно проанализировать на предмет бюджета и расходов и представить заинтересованным лицам на утверждение. В некоторых организациях могут требоваться финансовые аналитики для проверки бюджетных требований.
8. После утверждения BA должен предъявить ITDT полную схему проекта. Подробная блок-схема с использованием UML, SAP или Visio должна показывать ожидаемый результат. BA должен подробно сообщить ITDT, что требуется на стороне компании, отвечая без подготовки на любые вопросы или опасения.
9. BA должен начать тщательно документировать предлагаемые изменения в существующей системе, чтобы создать справочник для обучения и поддержки конечных пользователей к концу проекта. Наиболее эффективный способ для экономии ресурсов и времени – разработать сайт в локальной сети компании, предназначенный для поддержки и обучения, с использованием модели ITIL Foundation. Также разработать доску объявлений для отзывов об улучшениях.
10. Оставаться доступным для заинтересованных лиц и ITDT, чтобы они передавали заявки на модификацию и другие сведения, способные повлиять на проект.
11. Встретиться с заинтересованными лицами, чтобы оценить предварительные результаты по первой версии программного обеспечения. Передать плюсы и минусы и рекомендации от бета-тестировщиков ITDT касательно изменений.
12. Проверить улучшения, сделанные для утверждения пользователем. Убедиться, что все ошибки и проблемы документально зафиксированы на будущее.
13. После утверждения окончательного варианта ПО сжато выразить информацию, имеющуюся в документации, в виде краткого полноценного документа Word или PDF для инструкции.
14. Проверять новую систему после полной реализации на наличие ошибок, конфликтов или неполадок. Измерять улучшения по сравнению с модификациями системы.
15. Начать новый цикл улучшений тогда, когда оговорено в пункте 1.
Цель данного
краткого шаблона – дать краткое описание процесса с участием бизнес-аналитика.
Приведенные шаги и процедуры могут различаться в разных компаниях или отраслях,
но должность бизнес-аналитика никогда не кончается.
Типичный рабочий день бизнес-аналитика
—
Митинги с проектной командой и с заказчиком;
—
Проработка концептуальных решений;
—
Работа с инструментами анализа: схемами, диаграммами, моделями, прототипами;
—
Работа с требованиями: сбор, написание ТЗ и спецификаций;
—
Консультации разработчиков и тестировщиков;
— Изучение
стандартов.
Достоинства и недостатки
Главное преимущество
профессии бизнес-аналитика — возможность проникать в суть: разбираться, что как
устроено, из каких частей состоит, как они между собой связаны и
взаимодействуют, и затем описывать сложные вещи с помощью простых, но полезных
моделей.
Бизнес-аналитики
помогают разным сторонам понимать друг друга, и в результате получают
реализацию, которая удовлетворит всех.
Еще один плюс
— важность и значимость деятельности, так как именно результаты работы
бизнес-аналитика определяет ход проекта.
Среди недостатков выделяют сложности в
общении с заказчиком, когда не удается донести хорошие идеи или же мешают
ограничения в сроках и бюджете.
Другая жалоба
— необходимость изучать большие объемы информации в краткие сроки. Кроме
изучения непосредственно своего проекта, бизнес-аналитик обязан постоянно
держать руку на пульсе новых методологий, подходов, изучать базовые принципы
новых платформ.
Как стать бизнес-аналитиком и куда идти
дальше?
Можно выделить 2 пути становления:
1.
IT-специалист, которому ближе общение, чем написание кода. Такой аналитик будет
понимать процесс разработки, знает возможности ПО и понимает, что нужно знать
разработчику для качественной работы. Однако ему необходимо отдельно
приобретать бизнес-знания в области, которая автоматизируется.
2. Специалист
без IT-образования, который является профессионалом в определенной предметной
области. Такой аналитик понимает все нюансы бизнеса и разговаривает с
заказчиком на одном языке. Но ему придется разбираться, что именно подлежит
автоматизации и какие данные нужны разработчикам для работы.
Для работы бизнес-аналитика важно
— знать
методологии сбора, анализа и формализации;
— знать
предметную область, которую нужно анализировать;
—
понимать жизненный цикл ПО в соответствии с различными методологиями;
— знать
основы программирования, тестирования, алгоритмов, экономики.
Что касается личных качеств, необходимо
—
обладать аналитическим мышлением;
— легко
разбираться в неизвестной области;
— уметь
анализировать текущую ситуацию в сравнении с прошлой;
— уметь
принимать решения;
—
любить и уметь учиться;
— иметь
отличные коммуникативные способности;
— быть
внимательным к деталям;
— четко и
ясно выражать свои мысли.
Инструменты
бизнес-аналитики
Power BI — это набор
средств бизнес-аналитики для получения важных данных в организации.
Подключайтесь к сотням источников информации, упростите ее обработку и
динамический анализ. Создавайте великолепные отчеты и публикуйте их для
пользователей своей организации, которые смогут работать с ними в браузере и на
мобильных устройствах. Персонализированные панели мониторинга с уникальным
полным обзором ситуации в компании теперь доступны каждому. Вы сможете легко
масштабировать решение со встроенными средствами управления и безопасности на
всю организацию.
Zoho
Reports is a BI and analytics solution that allows you to create insightful
reports and dashboards. It assists you to visually analyze your business data,
and to take informed decisions.
TIBCO Spotfire®
Desktop
позволяет пользователям легко создавать и обновлять аналитические приложения и
информационные панели. Пользователи могут интерактивно запрашивать,
визуализировать, агрегировать, фильтровать данные практически любого размера.
Он также позволяет пользователям создавать, редактировать и обновлять
аналитические файлы.
Вспомогательные
инструменты
Wunderlist. Выбор
программы обусловлен ее относительной простотой не в ущерб функциональности.
Как приятное дополнение — ее можно использовать на Mac и Android одновременно.
При помощи Wunderlist можно вести контроль сроков выполнения задач не только
мелких и повседневных, но и задач из JIRA (позволяет планировать и отслеживать
agile-проекты и разработку ПО). Лучше иметь один общий источник информации,
который позволит получить полную картину текущих активностей. Все задачи падают
в папку “Входящие” и могут не иметь четкого описания. По окончании рабочего дня
я перебираю данный список, уточняю описания, устанавливаю сроки выполнения и
раскладываю все по папкам в Wunderlist и ярлыкам в Evernote, которые отчасти
пересекаются.
По результатам
обсуждений получается список ясных и понятных пользовательских историй, которые
я фиксирую в Confluence. Все важные письма, протоколы встреч отправляются в
Evernote.
Так, фиксируя
бизнес-уровень на каждому шаге, я получаю наиболее полную картину, которая
хранится в моей личной базе знаний.
Evernote. Использую его
для агрегации всей полученной информации. Важное письмо? Отправляем в Evernote.
Записал что-то важное в тетрадь? Фотографирую — и загружаю туда же. Такой
подход меня неоднократно спасал. Хлам — вся не разобранная информация —
сливается в общий блокнот. Там я держу записи в течение недели. Затем все, что
не прошло подтверждение и не стало актуальным, удаляю. Актуализированные записи
снабжаю нужным тегом и отправляю в нужный блокнот с названием проекта. Для
удобного и быстрого поиска или поиска использую теги.
Pomodoro.
Контролировать ритм выполнения персональных проектных задач помогает таймер
Pomodoro — 11 Pomodoro за рабочий день.
Заключение
На мой взгляд,
особенность в том, что к этой специальности при поиске невозможно адекватно
сформулировать требования, крайне сложно предугадать потенциал «новичка» именно
для этой сферы, только через год в лучшем случае активной работы о наличие
потенциала можно будет судить. Выпускники кафедр вузов с названиями вида
«Бизнес аналитика» (даже если такие существуют, и по терминологии это
соответствует практике) не внушают доверяя, так как даже невозможно
представить, чему надо учить. Да и вообще — какое должно быть базовое
образование бизнес-аналитика? Техническое, экономическое, гуманитарное?
Встречал качественных представителей с образованием всех трех видов.
Литература
EmoticonEmoticon