На каком этапе чаще всего привлекается сессионный бизнес аналитик

Время на прочтение
7 мин

Количество просмотров 26K

Зачем вообще нужны бизнес аналитики

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

Поскольку и программисты, и заказчики — люди занятые, выяснение деталей проходит в форме раундов «вопрос — ответ», при этом нигде не фиксируется, когда и почему было принято такое решение или как оно изменялось со временем. Но главный минус такой коммуникации — разработчик спрашивает «как?», а заказчик может ответить только на «зачем?», а остальное его уже мало интересует. Более того, обычно, отвечая на «как?», заказчик заводит себя в тупик, потому что не может и не обязан знать, сколько вариантов существует для выполнения его потребности и какой оптимален. Программист же всего лишь делает, что ему сказали. В итоге складывается ситуация, когда недоуменный клиент спрашивает, почему приложение не вписывается в его картину мира, а недоуменный программист отвечает, что так и просили сделать.

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

Аналитик в Agile

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

Привычный всем набор функций аналитика — сбор требований и написание подробной спецификации, как должна работать система. Еще перед запуском проекта требования должны быть собраны, спецификация написана, дизайны нарисованы, и только потом программисты начинают писать код. Эта красивая история написания программы редко соответствует действительности даже в проектах по методологии waterfall, не говоря уже о Scrum.

Проектная документация имеет тенденцию очень быстро устревать— в особенности в сочетании с Agile, где изменения — норма, а не форс-мажор.

В связи с этим в Agile-методологиях всячески советуется минимизировать документацию:

• ­Избегать write-only-документации, т. е. той, которую заведомо никто не прочитает.
• ­Писать лаконично, выделяя главное и опуская излишние детали, ибо детали меняются чаще.
• ­Использовать больше визуальных образов, схем, графических нотаций.

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

• ­­Тяжело вводить новых людей в курс проекта.
• ­Велика вероятность утери общей концепции и видения (проекта в целом и его частей).
• ­Сложно контролировать качество: непонятно, с чем сверять (в особенности это касается полнофункционального регрессионного тестирования, которое полностью автоматизировать очень тяжело).
• ­Сложно сопровождать и развивать старую функциональность: все уже забыли, почему и зачем именно так сделали.

Возможные функции аналитика в Agile

Связующее звено между разработчиками и заказчиками

В отличие от классической интерпретации функций аналитика, в Agile именно обеспечение эффективной связи между заказчиками (пользователями) и командой разработчиков играет, по сути, ключевую роль.

Т. е. аналитик оказывается человеком, которому доверяют и пользователи, и разработчики:

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

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

Контроль качества

Традиционно считается, что качество контролируют специальные люди, которые выполняют приемочные испытания по описанным методикам и программам. Однако кто проверит, что сделали то, что нужно с точки зрения бизнеса, и что пользоваться удобно?

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

Достаточно очевидно, что вместо (или совместно с) владельцем продукта эта почетная обязанность может быть возложена на аналитика

Схемы взаимодействия аналитик – команда

В Agile большое внимание уделяется командной работе, самоорганизации. Как организовать взаимодействие аналитика с командой с учетом возлагаемых на него функций? Есть разные варианты, причем в зависимости от обстоятельств, эффективными оказываются те или иные.

Владелец продукта — аналитик

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

Т. ч. можно решить: функции аналитика исполняет владелец продукта. Или, если угодно, наоборот — аналитик исполняет роль владельца продукта.

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

Недостатки:

• ­Слишком многое зависит от одного человека — большая нагрузка и связанные с этим риски «бутылочного горлышка».
• Экстремальная незаменимость — а если в отпуске, а если заболел.
• Вряд ли получится плотно привлечь такого владельца продукта к сопровождению системы или активному участию в пилотных внедрениях.
• Есть вероятность, что владелец продукта будет откладывать решение каких-то задач не потому что у них низкий приоритет, а потому что он пока еще не успел как следует проработать постановку. Т. е. убивается вся идея приоритизации работ на основании потребностей бизнеса, а не исходя из внутренних или технических обстоятельств.

Аналитик — помощник владельца продукта

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

Однако, и у этой схемы есть недостатки:

• Деятельность аналитика недостаточно прозрачна для команды, поскольку аналитик в нее не входит.
• Велика вероятность, что команда будет воспринимать аналитика как владельца продукта (или даже руководителя), т. е. видеть в нем не помощника и эксперта, а начальника, что почти наверняка убьет критичность восприятия предложений и моделей, предлагаемых аналитиком — их будут воспринимать не как начальное приближение и дополнительную информацию, а как инструкции к действию.
• Опять же, не так-то просто привлечь такого аналитика к сопровождению.

Аналитик внутри команды

Можно пойти еще дальше и поместить аналитика внутрь команды. Что это значит:

• Аналитик сидит вместе со всеми, т. е. в одной комнате с разработчиками.
• Аналитик участвует в Scrum-митингах с остальными (рассказывает, что делал вчера и что собирается делать сегодня).
• Работа аналитика учитывается при планировании итерации.
• Аналитик может привлекаться к нехарактерным для себя работам, чтобы помочь остальной команде в непростую минуту — например, подготовить тестовые данные, прогнать часть ручных тестов.

Звучит здорово. И работает здорово! Однако бывают обстоятельства, при которых схема не подходит:

• Одной предметной областью (или сильно похожими) занимается несколько команд разработчиков, т. ч. держать по аналитику в каждой команде нет смысла.
• В проекте так много технических и технологических тонкостей и сложностей, что команда в основном сконцентрирована на них, а аналитик в такой команде оказывается инородным телом.
• Нехватка квалифицированных аналитиков.

Заключение

Так есть разница между аналитиком в Agile и не-Agile (например, в водопаде или другой тяжеловесной методологии)? Однозначный ответ — есть!

В тяжеловесных методологиях аналитик похож на слабопроницаемую стену между командой разработчиков и представителями заказчика/бизнеса. Чтобы сделать хороший продукт, приходится тратить кучу сил на «ковыряние дырок» в этой стене. Кроме того, ужасно высоки риски, связанные с ошибками аналитика. Команде разработчиков при этом отводится роль второго плана.

В Agile же аналитик играет роль связующего звена между разработчиками и заказчиками — своего рода магнит, который не дает им разбежаться по разным углам и тихо там что-то делать без ведома друг друга. При этом команде разработчиков отводится весьма значимая роль. Благодаря этому снижаются риски, связанные с ошибками аналитика: если что, команда уточнит/поправит (а если не поправит, на демонстрации заказчики поправят).

Аналитик в Agile — золотая середина между крайностями:

Одна крайность	Золотая середина	Другая крайность
Команду не допускают к аналитической работе.	Agile	Разработчикам самим приходится полностью прояснять, что же нужно.
Аналитик мало общается с заказчиком.	Agile	Аналитик всё время проводит у заказчика.
Подробные спецификации перед началом итерации.	Agile	Отсутствие какой-либо проработки требований до постановки их в итерацию.
Команда «с придыханием» относится к установкам аналитика.	Agile	Команда не доверяет результатам работы аналитика (не использует их).
Аналитик не участвует в тестировании (QA).	Agile	Аналитик вынужден постоянно «протыкать» много старых интерфейсов.
Команда воспринимает аналитика как руководителя.	Agile	Аналитик для команды — мальчик/девочка «на побегушках».
Аналитик взаимодействует с командой исключительно при помощи документации и баг-трекера.	Agile	Аналитик взаимодействует с командой исключительно посредством устных коммуникаций.
С заказчиком и пользователями общается только аналитик.	Agile	Все члены команды вынуждены плотно общаться с заказчиками и пользователями.

 

Автор: Ольга Азимбаева, Senior Business Analyst.

Привет, Вы узнаете про agile, Разберем основные ее виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое
agile, бизнес аналитик, agile, scrum, kanban , настоятельно рекомендую прочитать все из категории Управление разработкой программных IT проектов.

Зачем вообще нужны
бизнес аналитик и?

Scrum и Kanban — это гибкие методологии создания продукта. По ним можно работать в любой отрасли, но особенно хорошо они подходят для ИТ. В основе обеих методологий лежат принципы Agile. Сам Agile (agile software development, от англ. agile – проворный) – это семейство «гибких» подходов к разработке программного обеспечения. Такие подходы также иногда называют фреймворками или agile-методологиями.

Смысл Agile сформулирован в Agile-манифесте разработки ПО: «Люди и взаимодействие важнее процессов и инструментов. Работающий продукт важнее исчерпывающей документации. Сотрудничество с заказчиком важнее согласования условий контракта. Готовность к изменениям важнее следования первоначальному плану».

К отдельным agile-подходам относятся scrum и kanban.

Scrum – это «подход структуры». Над каждым проектом работает универсальная команда специалистов, к которой присоединяется еще два человека: владелец продукта и scrum-мастер. Первый соединяет команду с заказчиком и следит за развитием проекта (это не формальный руководитель команды, а скорее куратор). Второй помогает первому организовать бизнес-процесс: проводит общие собрания, решает бытовые проблемы, мотивирует команду и следит за соблюдением scrum-подхода.

Scrum-подход делит рабочий процесс на равные спринты – обычно это периоды от недели до месяца, в зависимости от проекта и команды. Перед спринтом формулируются задачи на данный спринт, в конце – обсуждаются результаты, а команда начинает новый спринт. Спринты очень удобно сравнивать между собой, что позволяет управлять эффективностью работы.

Kanban – это «подход баланса». Его задача – сбалансировать разных специалистов внутри команды и избежать ситуации, когда дизайнеры работают сутками, а разработчики жалуются на отсутствие новых задач.

Вся команда едина – в kanban нет ролей владельца продукта и scrum-мастера. Бизнес-процесс делится не на универсальные спринты, а на стадии выполнения конкретных задач: «Планируется», «Разрабатывается», «Тестируется», «Завершено» и др.

Главный показатель эффективности в kanban – это среднее время прохождения задачи по доске. Задача прошла быстро – команда работала продуктивно и слаженно. Задача затянулась – надо думать, на каком этапе и почему возникли задержки и чью работу надо оптимизировать.

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

В чем разница между Scrum и Kanban?

Или, если хотите проще: Scrum — это автобус, который останавливается лишь на определенных остановках, где люди выходят группами. А Kanban — это маршрутка: захотел пассажир выйти, попросил водителя и вышел там, где ему нужно.

• Избегать write-only-документации, т. е. той, которую заведомо никто не прочитает.
• Писать лаконично, выделяя главное и опуская излишние детали, ибо детали меняются чаще.
• Использовать больше визуальных образов, схем, графических нотаций.

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

• Тяжело вводить новых людей в курс проекта.
• Велика вероятность утери общей концепции и видения (проекта в целом и его частей).
• Сложно контролировать качество: непонятно, с чем сверять (в особенности это касается полнофункционального регрессионного тестирования, которое полностью автоматизировать очень тяжело).
• Сложно сопровождать и развивать старую функциональность: все уже забыли, почему и зачем именно так сделали.

Возможные функции аналитика в Agile

Связующее звено между разработчиками и заказчиками

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

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

Контроль качества

Схемы взаимодействия аналитик – команда

• Слишком многое зависит от одного человека — большая нагрузка и связанные с этим риски «бутылочного горлышка».
• Экстремальная незаменимость — а если в отпуске, а если заболел.
• Вряд ли получится плотно привлечь такого владельца продукта к сопровождению системы или активному участию в пилотных внедрениях.
• Есть вероятность, что владелец продукта будет откладывать решение каких-то задач не потому что у них низкий приоритет, а потому что он пока еще не успел как следует проработать постановку. Т. е. убивается вся идея приоритизации работ на основании потребностей бизнеса, а не исходя из внутренних или технических обстоятельств.

• Деятельность аналитика недостаточно прозрачна для команды, поскольку аналитик в нее не входит.
• Велика вероятность, что команда будет воспринимать аналитика как владельца продукта (или даже руководителя), т. е. видеть в нем не помощника и эксперта, а начальника, что почти наверняка убьет критичность восприятия предложений и моделей, предлагаемых аналитиком — их будут воспринимать не как начальное приближение и дополнительную информацию, а как инструкции к действию.
• Опять же, не так-то просто привлечь такого аналитика к сопровождению.

Аналитик внутри команды

Можно пойти еще дальше и поместить аналитика внутрь команды. Что это значит:

• Аналитик сидит вместе со всеми, т. е. в одной комнате с разработчиками.
• Аналитик участвует в Scrum-митингах с остальными (рассказывает, что делал вчера и что собирается делать сегодня).
• Работа аналитика учитывается при планировании итерации.
• Аналитик может привлекаться к нехарактерным для себя работам, чтобы помочь остальной команде в непростую минуту — например, подготовить тестовые данные, прогнать часть ручных тестов.

Звучит здорово. И работает здорово! Однако бывают обстоятельства, при которых схема не подходит:

• Одной предметной областью (или сильно похожими) занимается несколько команд разработчиков, т. ч. держать по аналитику в каждой команде нет смысла.
• В проекте так много технических и технологических тонкостей и сложностей, что команда в основном сконцентрирована на них, а аналитик в такой команде оказывается инородным телом.
• Нехватка квалифицированных аналитиков.

Аналитик в Agile — золотая середина между крайностями:

Одна крайность	Золотая середина	Другая крайность
Команду не допускают к аналитической работе.	Agile	Разработчикам самим приходится полностью прояснять, что же нужно.
Аналитик мало общается с заказчиком.	Agile	Аналитик все время проводит у заказчика.
Подробные спецификации перед началом итерации.	Agile	Отсутствие какой-либо проработки требований до постановки их в итерацию.
Команда «с придыханием» относится к установкам аналитика.	Agile	Команда не доверяет результатам работы аналитика (не использует их).
Аналитик не участвует в тестировании (QA).	Agile	Аналитик вынужден постоянно «протыкать» много старых интерфейсов.
Команда воспринимает аналитика как руководителя.	Agile	Аналитик для команды — мальчик/девочка «на побегушках».
Аналитик взаимодействует с командой исключительно при помощи документации и баг-трекера.	Agile	Аналитик взаимодействует с командой исключительно посредством устных коммуникаций.
С заказчиком и пользователями общается только аналитик.	Agile	Все члены команды вынуждены плотно общаться с заказчиками и пользователями.

Agile, scrum, kanban: в чем разница и для чего использовать?

Если раньше офисы модно было обустраивать «по фэн-шую», то теперь — исключительно «по эджайлу». Agile – это не только цветные стикеры, на которых удобно отмечать ход работы (стикеры, скорее, стоит относить конкретно к подходу kanban). А ведь есть еще и scrum – он тут при чем?

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

Рубрика «Инновации в корпорациях» выходит при поддержке Spinon.

---

Определение

Agile (agile software development, от англ. agile – проворный) – это семейство «гибких» подходов к разработке программного обеспечения. Такие подходы также иногда называют фреймворками или agile-методологиями.

Agile возник в IT-среде, но затем распространился и в другие сферы – от промышленной инженерии до искусственного интеллекта.

Смысл Agile сформулирован в Agile-манифесте разработки ПО: «Люди и взаимодействие важнее процессов и инструментов. Работающий продукт важнее исчерпывающей документации. Сотрудничество с заказчиком важнее согласования условий контракта. Готовность к изменениям важнее следования первоначальному плану».

Agile-манифест – главный документ всех «гибких» подходов к разработке. Он был создан в 2001 году группой энтузиастов-программистов, которые хотели понять, что именно лежит в основе разработки востребованного и полезного IT-продукта.

Agile предполагает, что при реализации проекта не нужно опираться только на заранее созданные подробные планы. Важно ориентироваться на постоянно меняющиеся условия внешней и внутренней среды и учитывать обратную связь от заказчиков и пользователей. Это поощряет разработчиков и инженеров экспериментировать и искать новые решения, не ограничивая себя жесткими рамками и стандартами.

К отдельным agile-подходам относятся scrum и kanban.

Scrum – это «подход структуры». Над каждым проектом работает универсальная команда специалистов, к которой присоединяется еще два человека: владелец продукта и scrum-мастер. Первый соединяет команду с заказчиком и следит за развитием проекта; это не формальный руководитель команды, а скорее куратор. Второй помогает первому организовать бизнес-процесс: проводит общие собрания, решает бытовые проблемы, мотивирует команду и следит за соблюдением scrum-подхода.

Scrum-подход делит рабочий процесс на равные спринты – обычно это периоды от недели до месяца, в зависимости от проекта и команды. Перед спринтом формулируются задачи на данный спринт, в конце – обсуждаются результаты, а команда начинает новый спринт. Спринты очень удобно сравнивать между собой, что позволяет управлять эффективностью работы.

Kanban – это «подход баланса». Его задача – сбалансировать разных специалистов внутри команды и избежать ситуации, когда дизайнеры работают сутками, а разработчики жалуются на отсутствие новых задач.

Вся команда едина – в kanban нет ролей владельца продукта и scrum-мастера. Бизнес-процесс делится не на универсальные спринты, а на стадии выполнения конкретных задач: «Планируется», «Разрабатывается», «Тестируется», «Завершено» и др.

Главный показатель эффективности в kanban – это среднее время прохождения задачи по доске. Задача прошла быстро – команда работала продуктивно и слаженно. Задача затянулась – надо думать, на каком этапе и почему возникли задержки и чью работу надо оптимизировать.

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

Примеры употребления

Один из принципов Agile стоит на личной ответственности человека, а не на отлаживании внутренних процессов.

(Из статьи на VC.ru)

Когда в работе с профессиональными командами мы используем Scrum, чаще всего мы выбираем цикл длиной в 2–3 недели с ретроспективными собраниями, которые позволяют держать все под контролем.

(Из интервью «Ведомостей» с Фрэнком Сосьером, коучем компании Freestanding Agility)

Главная идея Kanban – визуализация рабочего процесса. Она заключается в создании физической панели, на которой можно наглядно отмечать прогресс.

(Из перевода колонки Forbes на Rusbase)

Если говорить о том, что такое agile, я бы ограничился такой фразой – это набор ценностей, в рамках которых мы строим свою работу с продуктами, с процессами внутри организации.

(Управляющий партнер ScrumTrek Алексей Пименов в статье на Rusbase)

Мнения экспертов

В зависимости от задач мы применяем разные методы в рамках философии – agile, scrum, kanban.

Scrum позволяет развить в сотрудниках необходимые качества – проактивность, самостоятельность, организованность, коммуникабельность и дальновидность. Основной смысл метода – это выполнение задач в самоорганизующихся командах, где у каждого есть своя роль и каждый несет ответственность за свою часть работы. Используя scrum, мы проводим опросы персонала, составляем графики ожидаемой скорости выполнения задач.

Agile мы используем во внутренних коммуникациях. Недавно провели очередной спринт по ликвидации опозданий сотрудников. Все начальники и специалисты, задействованные в проекте, провели целый день на совещании, обсуждая достижения, проблемы и предстоящие задачи в новом спринте.

Сейчас мы активно внедряем в компании метод kanban. Цель внедрения kanban – повысить гибкость производства, лучше приспосабливаться к изменяющимся требованиям рынка. На практике метод помог нам добиться соответствия между складскими запасами и реально используемыми в производстве продуктами.

Важный момент: agile-методология – это общее направление, а kanban и scrum – уже ее разновидности.

Мы используем связку scrum + waterfall, а также дорабатывали в течение года саму agile-доску. Главная причина использования: прозрачность и простота. По сути ,это получается тот же самый конвейер Генри Форда: переход задачи от статуса к статусу со сменой исполнителя, поэтому основным принципом к самой agile-доске является уже простота.

Мы используем agile как непосредственную часть нашего workflow, поэтому все проекты, от брендинга и разработки сайтов и вплоть до нашего стартапа по AI и нативной рекламе NativeOS, в бюро Chernika ведутся как раз по данному workflow.

Работающий продукт важнее подробно прописанной документации. Это не говорит о том, что мы не ведем никакую документацию, нет. Это скорее взгляд в сторону эффективности с ударом по излишней бюрократии.

Scrum принес в нашу команду ритмичность и понимание — успеваем или не успеваем в срок. Мы видим скорость работы команды, нет ощущения постоянного факапа. Раньше были ситуации, что перед жесткими релизами scrum куда-то пропадал и все начинали просто фигачить — сейчас у нас это пропало, есть постоянное ощущение, что успеваем в срок. Если появляются риски, мы обсуждаем их с PD на ранних этапах, корректируем план или уменьшаем объем задач каким-то образом.

Работа стала прозрачнее, рабочий день стал укладываться в 8-часовую норму и, по ощущениям, мы стали успевать больше. Мы понимаем, что когда у тебя есть ощущение, что ты не успеваешь, чувствуешь, что надо работать больше — это очень плохо влияет на продуктивность, от этого надо избавляться.

Для наглядности и открытости работы отдела разработки мы повесили специальную доску с пометками “to do”, “in progress”, ”review”, ”test”, “done”, где все члены команды наклеивают стикеры с задачами (в колонке “to do”), а по мере их выполнения перемещают в последующие пункты. И счастливый финал – конечный пункт “done”. Это помогает составить общую картину и дает возможность видеть, над чем работает каждый участник.

Очень важный момент метода (и организации рабочего процесса): после утверждения всех задач (“to do”), список блокируется на внесение. Так новые поступающие задачи не отвлекают от процесса и не тормозят работу.

Все участники также оценивают каждую задачу на предмет временных и материальных затрат, которые потребуются на выполнение. И вишенка на торте – еженедельные встречи в определенное время (Daily Scrum), где каждый член команды коротко рассказывает о том, что собирается сделать сегодня, что сделал вчера (и столкнулся ли с какими-то препятствиями). Это важно на пути к долгосрочным задачам – именно так можно вовремя понять, что пора сменить стратегию.

Scrum мы внедрили с двух попыток, потому что всем, от команды до пользователей, хочется иметь более прогнозируемый результат. В этом плюс методологии – четкие ритмы упорядочивают коллектив, повышают общий уровень знаний о проекте. Как следствие, результат становится более прогнозируемым, в том числе для наших «стейкхолдеров» – пользователей.

Командная работа также повышает ответственность: все получают бонус, только если команда выполнила поставленные на определенном этапе задачи.

Scrum и Kanban на практике

В чистом виде отдельные методы встречаются редко. Чаще всего компании сочетают те части гибких систем, которые им больше всего подходят. К примеру, для продуктовой разработки больше подойдет Scrum. Для начальных этапов, таких как исследование или тестирование гипотез, – Kanban. С точки зрения других подразделений, используется облегченный вариант Kanban: для координации ежедневных задач, синхронизации, и уверенного пути вперед!

Scrum является очень удобным инструментом планирования. Он дает некую гибкость в непосредственном улучшении продукта. К примеру, во многих ИТ-компаниях, его используют раз в две недели для планирования самой разработки. Это помогает не тратить два-три месяца на решение проблемы, а запускать MVP (Minimal Viable Product, минимальный жизнеспособный продукт) и оперативно его дорабатывать после получения обратной связи от пользователей. Kanban,в свою очередь, отлично подходит для мониторинга хода выполнения работ. Ведь его ключевая задача — обеспечить процесс и ход разработки.

Что выбрать — Scrum или Kanban

Отметим, что каждая методология решает свою проблему. Поэтому все зависит от целей и ожиданий от проекта. К примеру, вы создаете новый удобный мессенджер. Если вы используете принцип Kanban, вы прописываете детальный план, чтобы создать идеальный продукт, — и через год разработки получаете желаемое. Kanban — строгая последовательность задач, равномерная загруженность, четкость на каждом этапе. А если у вас нет конкретного плана? Тогда, на помощь приходит метод Scrum, с которым мелкими «шажками» (спринтами) можно постоянно разрабатывать и улучшать продукт благодаря быстрой обратной связи. В итоге конечный продукт может быть совершенно другим, чем тот, который планировался в начале, но он будет максимально соответствовать ожиданиям пользователей.

Заключение

Agile – это философия, scrum – структура, waterfall – метод, kanban – система управления. Scrum и kanban – варианты agile, но у них есть некоторые явные различия. Методика scrum требует фиксированных ролей, тогда как у kanban нет необходимых ролей. Scrum основана на итерациях, объединяющих планирование, оптимизацию процессов и выпуск. В kanban это можно делать регулярно или каждый раз, когда вам нужно. Команда scrum требует оценки своей работы, тогда как команде kanban это не нужно.

См. также

• бизнес аналитик
• бизнес-аналитик , менеджер проекта ,
• гибкие методологии разработки по , scrum ,
• гибкая методология разработки , agile-методы ,
• управление проектами ,
• jira ,
• agile scrum ,
• разработка программного обеспечения , водопадная модель ,
• обеспечение качества , качество по ,
• стандарты тестирования , стандарты в тестировании ,
• сравнение методов разработки по , rup ,
• метод разработки динамических систем , dynamic systems development method ,
• методологии разработки , разработка по ,
• scrum , agile ,
• ddd , bdd ,
• виды методологий , разработка программного обеспечения ,
• Библиотека FST
• scaled agile framework , safe ,
• управление зависимостями ,

Надеюсь, эта статья об agile, была вам интересна и не так слона для восприятия как могло показаться, удачи в ваших начинаниях! Надеюсь, что теперь ты понял что такое agile, бизнес аналитик, agile, scrum, kanban
и для чего все это нужно, а если не понял, или есть замечания,
то нестесняся пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории
Управление разработкой программных IT проектов

Ответы на вопросы для самопроверки пишите в комментариях, мы проверим, или же задавайте свой вопрос по данной теме.

Каждому проекту, от самого маленького дома, строящегося на улице, до самой сложной ИТ-системы нужен кто-то, кто может воплотить идеи данных проектов в жизнь. В этом состоит роль бизнес-аналитика, который разбивает идеи, потребности и требования на более мелкие части, которые, впоследствии, объединяются для создания общей картины. Он делает это через определение потребностей организации, а затем собирает, управляет и проверяет информацию, чтобы решать бизнес-проблемы.

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

Быть хорошим бизнес-аналитиком – значит помогать вашей организации принимать более обоснованные решения.

Суть работы бизнес-аналитика

Каждому кораблю нужен капитан и штурман, и мир проектов ничем не отличается от корабля. Без капитана и штурмана корабль бы плыл в никуда. В большинстве организаций капитаном является менеджер проекта, контролирующий ход реализации проекта. Это делает роль штурмана довольно важной, так как корабль должен следовать наилучшему и наиболее разумному пути к месту его назначения. Как бизнес-аналитик, вы выступаете в роли штурмана. И вы должны использовать инструменты и методы, чтобы поддерживать проект в правильном направлении для вашей организации.

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

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

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

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

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

Последняя значимая роль, которую бизнес-аналитик играет в жизненном цикле проекта – это закрытие проекта. Это когда вы подтверждаете, что все критерии для завершения проекта выполнены. Иногда из-за исправлений в последний момент или из-за поспешного включения новых идей в проект, продукт может не полностью соответствовать потребностям организации. Ваша роль как бизнес-аналитика – гарантировать, что этого не произойдет.

Роль бизнес-аналитика в реализации проектов

От начала проекта и до его завершения бизнес-аналитики играют решающую роль в успехе проектов и достижении результатов. Ваша первая роль – подтвердить цели организации. Проекты используются для реализации изменений. Эти изменения могут значительно улучшить возможности и эффективность бизнеса компании.

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

Вторая роль бизнес-аналитика – управлять процессом требований к проекту. Для этого вы работаете с командой сотрудников организации и получаете представление того, что бизнес делает сегодня и что сделает его более эффективным. Затем вы фиксируете эту информацию с помощью нескольких из следующих инструментов:

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

Мы будем говорить подробнее об этих инструментах чуть позже. Ваша третья роль как бизнес-аналитика – управлять соответствующими изменениями в ходе проекта, и это включает в себя проверку любых изменений, предложенных в ходе проекта, и продвижение изменений, которые организация считает важными для выполнения своей миссии. Также, вы будете следить за тем, чтобы любые происходящие изменения внутри организации были должным образом отражены в продуктах проекта.

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

Последняя роль бизнес-аналитика в жизненном цикле проекта – обеспечить выполнение всех критериев завершения проекта. Все проекты нужно начинать с учетом конечной цели. Затем проект должен включать критерии завершения, которые подробно описывают, что необходимо сделать, прежде чем проект будет считаться завершенным.

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

Какие навыки необходимы бизнес-аналитику?

Есть определенные характеристики и навыки, которые помогут вам стать отличным бизнес-аналитиком. В первую очередь – это любопытство. Очень важно понимать, в каких сферах бизнеса вы работаете и как они сочетаются друг с другом. Именно с помощью любопытства, к вам приходит детальное понимание того, как это все вписывается в контекст организации, чтобы вы могли раскрыть все свои возможности. 

Второй навык после любопытства – это умение задавать вопросы и слушать. Наблюдение за выполняемой работой – очень эффективный способ получить информацию о том, как работает организация. Однако вы не поймете всего, просто наблюдая. Именно задавая вопросы и внимательно слушая, что говорится, имеет решающее значение для понимания того, что на самом деле происходит в организации.

Учитывая, что подход, основанный на наблюдении, вопросах и ответах, для получения информации может занять время, еще одним фундаментальным навыком бизнес-аналитиков является терпение. Чтобы потратить необходимое количество времени на сбор, анализ и проверку информации и выводов, потребуется терпение.

Два других фундаментальных навыка бизнес-аналитика, которые идут нога в ногу – это коммуникативные навыки и дипломатия. Каждый аспект бизнес-анализа включает в себя ту или иную форму коммуникации. Обычно вы либо поглощаете информацию с помощью коммуникационных подходов, либо собираете и делитесь этой информацией с помощью ваших собственных средств коммуникации. Тактичная дипломатия – это навык, который вам нужно будет часто использовать, поскольку вы будете оценивать подходы и предлагать улучшения.

Проекты могут длиться от нескольких недель, до нескольких лет. Следовательно, еще один навык, который вам необходим – это энтузиазм. Вы понимаете все улучшения, которые сулит проект, вы полностью преданы им и мотивируете других в достижении цели проекта. Энтузиазм – важная деталь достижения изменений, особенно когда вам нужно время, чтобы претворить их в жизнь.

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

Направления мышления бизнес-аналитика

Всякий раз, когда вы пытаетесь сделать что-то в организации, желание знать «Почему?» лежит в основе мышления хорошего бизнес-аналитика. Рассмотрение причины помогает понять уровень желания, приверженности и потребности в изменении, а также то как это изменение влияет как на процессы, так и на другие области организации. Понимание контекста также помогает в обосновании необходимости изменения.

Чтобы добиться успеха в своей деятельности, вы должны часто задавать себе вопрос «Почему?». Он даст вам образ мышления, который включает постоянное убеждение в существовании неэффективности. Темпы изменений в современном деловом мире достаточно значительны. Меняется все: клиенты, руководство, приоритеты и сам рынок. Изначально хорошо продуманные процессы работы со временем просто устаревают.

Вот почему неэффективность присутствует практически в каждом бизнесе и каждом бизнес-процессе. Как эффективный бизнес-аналитик, вы это осознаете и испытываете желание найти и исправить эти недостатки.

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

Следующее важное направление мышления – это стремление к пониманию деталей и знание всей картины в целом. Изучение и документирование бизнес-процессов может оказаться очень детальной работой. Требуется терпение и способность задавать вопросы об исключениях и других нюансах процессов. Эффективные бизнес-аналитики стремятся понять и оптимизировать взаимодействие процессов друг с другом.

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

Наконец, точка зрения бизнес-аналитика должна служить мостом между бизнесом и техническим персоналом. Это касается проблемы понимания и ожиданий этих двух групп. Техническая группа говорит о потоках данных, ошибках последовательности, технических характеристиках и т.д. Бизнес-персонал говорит о сроках выполнения работ, предпочтениях клиентов и управлении возможностями.

Диалог между этими двумя группами может быть почти бесполезным. Здесь бизнес-аналитик выступает в роли координатора и переводчика между заинтересованными сторонами, которые запрашивают изменение, и теми, кто его осуществляет.

Чтобы продолжить чтение, переходите в статью «Этапы подготовки проекта в бизнес-анализе. Часть 2».

Аналитик-стажер (trainee data analyst)

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

Академическая база

Аналитик работает со статистическими данными. У стажера может не быть практического опыта, но за время стажировки он разберется, зачем же у него был этот курс в университете. Если курса не было — объём обучения стажера становится слишком большим. Мы в Яндексе, скорее всего, не возьмем такого человека в команду.

Способ мышления

Это сложно формализуемая штука, но мы пытаемся придумать тесты на входе, которые не зависят от рабочего опыта кандидата. Например, взять процесс, с которым сталкивается каждый житель города ежедневно и формализовать его в виде продуктовых метрик. Таким образом мы проверяем способность человека поставить себя на место потребителя и выделить самое главное в его потребительском опыте.

Опыт программирования

Речь не о промышленном программировании. В работе аналитика данных нужно уметь читать документацию, быстро разбираться и использовать инструменты работы с данными, а также автоматизировать свою рутину. Это SQL разных реализаций, python, библиотеки pandas, библиотеки визуализации, умение использовать API.

Софт-скиллы

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

Постановка задач

Аналитик-стажер работает на уровне четко сформулированных и хорошо формализованных задач. Задачи стажеру ставит исключительно старший товарищ-аналитик (наставник или руководитель). Он же проверяет результаты выполнения этих задач перед тем, как отдать эти данные куда-либо еще.

Младший аналитик (junior data analyst)

Обработка данных

Младший аналитик – это стажер, который освоил инструменты обработки данных. Для него уже не существует ограничений в задачах по трансформации имеющихся данных к необходимой форме. Он всё ещё может делать что-то неоптимально: излишне греть вычислительный кластер неэффективными расчетами, тратить на простые задачи много времени, — но задачу он решит.

Недоверие к данным / валидация данных

Опыта младшего аналитика уже хватает, чтобы не доверять данным. Когда младший аналитик начинает работать с какими-то данными, он узнаёт природу этих данных и делает проверки: убеждается, что в данных именно то, что ожидается. Например, что показатели в нужной размерности, распределение величин выглядит разумно, нет странных выбросов, данные отражают реальную картину изучаемого явления и т. д.

Постановка задач

Младшему аналитику не хватает опыта в реальном продукте и бизнесе, поэтому он склонен решать задачи так, как они поступают:

Как правило при постановке задачи на младшего аналитика обсуждается детальный алгоритм с описанием данных, которые нужно использовать, способом трансформации этих данных (фильтрации, группировки, join’ы) и буквальным описанием, как должен выглядеть результат (если это график, то какие должны быть оси, нормировки, подписи, способ визуализации).

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

Внедрение и применение результатов работы

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

Аналитик 1 (Middle data analyst 1 step)

Аналитик 1 обладает всеми навыками младшего аналитика данных с точки зрения технической работы с данными и критического мышления, но при этом продвигается дальше в следующих аспектах своей работы и влияния на бизнес.

Постановка задач

Это первый уровень самостоятельного аналитика. Почти все его задачи возникают в прямом взаимодействии с командой или бизнес-заказчиком. Младший аналитик перебирается на этот уровень после появления желания больше влиять на бизнес или продукт. Понятно, что одного желания недостаточно.

Нужно подкопить опыта и кармы, чтобы желание трансформировалось в возможность. Аналитик 1 всё чаще и чаще докапывается до сути идей и вопросов, с которыми к нему пришли. Думает про задачи в терминах решений, которые будут приняты, а не в терминах работы с данными.

Сложность решаемых задач и глубина решения

Аналитик на этом уровне справляется с большинством простых задач самостоятельно. Однако с учетом небольшого опыта решения задач именно в бизнесовой постановке (с обработкой данных, как мы помним, всё нормально уже с уровня джуниора), аналитику на этом грейде может не хватать глубины мышления или ширины контекста, чтобы лучше понимать природу сложных задач и подбирать лучший способ решения. Как правило трудности вызывают:

В этих ситуациях аналитику 1 требуется помощь старшего товарища для понимания задачи, её декомпозиции или презентации результатов (чтобы они были применены).

Софт-скиллз 

Высокая степень самостоятельности означает, что сотрудник на этом уровне обладает навыками тайм-менеджмента, формирования ожиданий, прогнозирования сроков. Аналитик 1 несёт ответственность за результат.

Данные

Аналитик 1 начинает договариваться со смежниками о логировании или поставках данных, если ему их не хватает для решения задач. Не факт, что он это делает оптимально с точки зрения развития аналитического хранилища, но свои локальные проблемы он уже может решать. В полной мере это умение развивается к следующему грейду.

Аналитик 2 (Middle data analyst – 2 step)

Аналитик 2 – автономный аналитический юнит. Наносит пользу бизнесу. Это более опытная версия предыдущего грейда, но есть и отличия, которые являются качественными, существенными: это понимание контекста и выросший уровень рефлексии. Ниже о том, почему это важно и как меняется характер взаимодействия и пользы от этого аналитического юнита.

Контекст и проактивность

Аналитик 2 находится в глубоком контексте того, что происходит в его продукте или кусочке бизнеса. Это позволяет ему проявлять проактивность, приходить с идеями и предложениями, помогать тогда, когда не спрашивали. Это радикально повышает пользу от такого сотрудника.

Рефлексия

Важное отличие Аналитика 2 от Аналитика 1 заключается в возросшем уровне рефлексии. Чтобы быть хорошим аналитиком, нужно во всем сомневаться и критически переосмысливать. К слову, на этом базируется наука и успешные аналитики, как и успешные ученые, обладают этим качеством.

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

Сложность решаемых задач и глубина решения

Другое важное отличие — более высокий доступный уровень абстракции при мышлении о бизнесе. Аналитик 2 должен уметь за рутинными операционными задачами видеть какие-то системные направления развития доверенной ему части бизнеса и понимать, как задачи связаны с целями, куда и зачем глобально движется продукт/компания.

Аналитик 2 отлично погружен в предметную область, что позволяет ему копать глубоко. Он умеет сводить задачи бизнеса к задачам оптимизации метрик. В вопросах, с которыми к нему приходят, он умеет докапываться до сути и оцифровывать эту суть. Аналитик 2 решает задачи в бизнесовой постановке и результат его работы сформулирован обычно в таком же виде.

Результатам Аналитика 2 доверяют. Это характеристика как накопленного опыта и кармы, так и того, как аналитик на этом уровне оформляет и доносит результаты своей работы. Обычно в его задачах понятно описана методология, приложены скрипты и код, описаны допущения и область применимости результата, есть блок с выводами, и они написаны понятным языком.

Если результату аналитика не доверяют, этот результат не будет приводить к действиям, а значит, работа этого аналитика бесполезна. Большая часть результатов аналитика 2 должна быть actionable. Аналитик 2 – опытный профессионал, которого мы вырастили или наняли, чтобы он приносил пользу компании.

Данные

Аналитик 2 может быть самостоятельным заказчиком для команды аналитического хранилища (DWH) — описывать витрины, которые ему необходимы для работы.

Наставничество

Часто к Аналитикам 2 приставляют стажеров или младших аналитиков. Аналитик 2 должен уметь контролировать и обучать младших товарищей, в том числе должен уметь делегировать им какие-то простые задачи, растить их экспертизу и степень самостоятельности.

Старший аналитик (Senior data analyst)

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

Сложность решаемых задач и глубина решения

Старший аналитик способен решать проблемы, у которых нет «решения в лоб» – и его результат вызывает доверие. Он умеет коммуницировать результат так, чтобы его поняли и приняли. Типичный пример такой задачи – оценить какой-нибудь запуск без А/Б теста, когда невооруженным глазом ничего непонятно (программа лояльности, влияние Драйва на Такси, каннибализации в перформанс-маркетинге и т.д.)

Старший аналитик обладает опытом и контекстом, который позволяет ему предугадывать, какие задачи могут возникнуть в перспективе. Старший аналитик – ценный ресурс. С точки зрения компании важно стремиться к тому, чтобы каждый результат старшего аналитика приводил к позитивным изменениям.

Если старший аналитик раскопал что-то ценное – он обязан сделать так, чтобы об этом узнали все причастные, пролоббировать нужное изменение в продукте или бизнесе. У старшего аналитика развиты коммуникативные навыки, он умеет находить подход к разным людям в компании, уметь выбирать способ коммуникации, подходящий под решаемую задачу, умеет простым языком объяснять сложные концепции.

Данные

Опыт старшего аналитика позволяет ему быть квалифицированным заказчиком для команды DWH (аналитического хранилища). Он отлично формирует требования к данным и логированию, позволяющие решать на этих данных как текущие задачи, так и те, которые могут возникнуть в будущем.

Наставничество

Как правило, задачи и проекты старшего аналитика достаточно большие – он может декомпозировать их и раздавать части аналитикам помладше. В условиях растущей компании у старшего аналитика почти непрерывно есть стажер или младший аналитик, которого он обучает.

Менеджмент

Как правило старший аналитик управляется целями («сейчас мы в точке А, хотим попасть в точку Б»), большую часть из которых он определяет сам и согласует с руководителем. Чаще всего регулярное общение старшего аналитика с руководителем проходит в формате обсуждения стратегии, психотерапии, hr-вопросов.

Алгоритм «печатный станок»

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

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

Вот пример скрипта на языке Zorro для подобной системы:

// вспомогательная функция, которая проверяет наличие условий для совершения сделки 
bool isFree(var Price,var Grid,bool IsShort)
{
  for(open_trades) {
    if(TradeIsShort == IsShort
      && between(TradeEntryLimit,Price-Grid/2,Price Grid/2))
        return false;
  }
  return true;
}

// основная функция для торговой стратегии по паре EUR/CHF 
int run() 
{
  BarPeriod = 60;
  Hedge = 5; // activate virtual hedging

  var Grid = 20*PIP; // set grid distance to 20 pips
  var Close = priceClose();
 
// place pending trades at 5 grid lines above and below the Close
  int i;
  for(i = Close/Grid - 5; i < Close/Grid   5; i  )
  {
    var Price = i*Grid;
// place short trades with profit target below the current price
    if(Price < Close && isFree(Price,Grid,true))
      enterShort(1,Price,0,Grid); 
// place long trades with profit target above the current price
    else if(Price > Close && isFree(Price,Grid,false))
      enterLong(1,Price,0,Grid);
  }
}

Сетка – типичная модель-ориентированная система. Она подразумевает, что некие условия рынка удерживают цену в определенном интервале. Например, ограничение не позволяет паре EUR/CHF опуститься ниже 1,20. Но и подняться слишком высоко цена также не может, учитывая факт, что Национальный банк Швейцарии должен будет в конечном итоге выкупить назад все франки, которые они продали ради поддержки определенного значения.

Вот пример применения метода для пары EUR/CHF от компании P&L в 2021 году:

На графике можно наблюдать значительные колебания цены с существенными снижениями в январе и мае. Но по причине имеющегося предела, мы можем предсказать максимальные потери и просто держать достаточно средств на счету. В данном случае годовая выручка составила 130%, коэффициент Шарпа – 1,7. Практически никакого риска до того момента, пока не отменено ограничение цены.

Новости о данной стратегии распространялись весь 2021 год. Неудивительно, что многие участники рынка, частные инвесторы захотели запрыгнуть в уходящий поезд. Через три года после решения банка Швейцарии на рынке действовали уже тысячи подобных систем. В результате волатильность цены EUR/CHF неуклонно снижалась.

Волатильность – ключевое условие для метода Сетки. Чем ее меньше, тем меньше доход. Для того чтобы компенсировать его снижение, нужно вкладывать больше средств и сжимать сетку. Но у нас есть естественный предел. Размер сетки не может быть меньше выплат по сделке.

К осени 2021 волатильность упала фактически до нуля. Это сопровождалось существенным падением цены, как будто кто-то из крупных игроков (скорее всего, сам Национальный банк Швейцарии) настойчиво продает евро и скупает франки в ожидании крупного события.

За пару минут цена EUR/CHF скатилась до значений существенно ниже 1,20. В отличие от ситуации, имевшей место четыре года назад, рынок отреагировал мгновенно. Многие пострадали. Самое интересное, что «реальное» соотношение пары, основанное на относительной покупательной способности каждой из валют, все это время держалось на уровне 1,50.

Кейс швейцарского франка

В сентябре 2021 года Национальный банк Швейцарии установил ценовое ограничение для швейцарского франка. Идея была в том, чтобы защитить туристическую индустрию и экспорт на фоне переоцененного курса. Лимит был установлен на уровне 1,20 для пары EUR/CHF (евро/франк).

Вообще, ценовое ограничение – очень редкий шаг и весьма показательный пример неэффективности рынка. Все это можно немедленно перевести в крайне выгодную, почти безрисковую трейдинговую систему. В нормальной ситуации можно ожидать решительную реакцию рынка, когда пара EUR/CHF приближается к значению 1,20. Но на практике реакция была сильно растянута во времени.

Безусловно, Швейцария – странное место на карте Европы. Большинство трейдинговых компаний США знают лишь, что здесь делают качественные сыр. Или они не заметили решения Национального банка, или европейские офисы этих компаний забыли об этом доложить.

Так что можно предпринять, зная о ценовом ограничении? Лишь к январю 2021 года у крупных игроков на рынке появилась идея. И она заключалась не в разработке торговой системы, в том, чтобы просто скупать франки для оказания давления на соотношение валютной пары EUR/CHF.

Изменения цены пары EUR/CHF в сентябре 2021 – августе 2021

Смысл был в том, что, когда цена достигает своего предельного значения, выгоду можно получить, пробив его. На кон была поставлена куча денег, терпения и сил. Начиная с мая 2021, цена EUR/CHF держалась предельно близко к значению 1,20. Но крушения ценового ограничения так и не произошло.

Изменения цены пары EUR/CHF в сентябре 2021 – мае 2021

Ретировались, освободив путь для работы алгоритмических систем. В течение битвы 2021 года они вынуждены были оставаться в стороне. У частных трейдеров не было столько средств, чтобы вступить в игру. В январе 2021 первые умельцы начали использовать неэффективность рынка в свою пользу.

Кто умнее: трейдер против рынка

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

Вот три основные гипотезы, касающиеся неэффективности рынка, о которых вы, наверное, уже слышали:

• Гипотеза A: рынки работают эффективно. Цены зависят от реальных событий (например, от публикации годовых отчетов компаний) и отражают реальную стоимость активов. Все трейдеры обладают полнотой информации, действуют оперативно и рационально. Скачки цен отсутствуют, изменения не несут в себе данных для прогнозирования. Техническая система трейдинга бесполезна. В ее основе будет лежать принцип удачи.
• Гипотеза B: рынки неэффективны, но их неэффективность не дает преимущество частным трейдерам. Только крупные фирмы и хедж-фонды могут эксплуатировать такую неэффективность, обладая большим капиталом, быстрым и дорогим железом, опытными аналитиками и экспертами-математиками. Начать играть на их поле означает превратиться в легкую добычу для таких компаний.
• Гипотеза C: Неэффективности рынков достаточно, чтобы хватило всем. В данной ситуации размеры компаний – это уже не преимущество, а недостаток. Крупные фирмы и хедж-фонды слишком неповоротливы. Все эти ресурсы, включая переоцененных аналитиков и гениев со слишком большими зарплатами, не способны вас опередить, если вы хорошо усвоили правила игры.

Мало кто сегодня все еще верит в первую гипотезу. Рынки не ведут себя рационально и эффективно. Примеров можно привести сколько угодно. Чаще всего стоимость компаний далека от их «реальной» стоимости. Но даже в такой ситуации можно разглядеть некоторые паттерны.

На вкус и цвет

По сути, есть два основных метода построения стратегий онлайн-трейдинга. Первый ориентирован на определенную модель, второй – на интеллектуальный анализ данных. В первом случае мы имеем дело с понятием неэффективного рынка. Метод включает работу с психологией трейдеров, экономикой, микроструктурой рынков, а также любыми внешними явлениями, которые могут оказывать влияние на цены акций.

Неэффективность ведет к аномалиям кривой цен или возникновению определенных паттернов колебаний цены, которые можно попытаться предсказать и использовать в торговом алгоритме. Среди стратегий, основанных на определенной модели, можно вспомнить стратегию следования тренду, mean reversion (возвращение к среднему значению), ценовые циклы и кластеры, статистический арбитраж и сезонность.

Здесь есть проблема – эта модель не реалистична. Это упрощенный образ реальности. Данная модель не может быть доказана или опровергнута. Ее надежность может быть обоснована только чрез влияние на кривую цен. Применимость такой модели зависит от определенной долгосрочной стабильности действий предсказанных с ее помощью аномалий. Проверить ее можно лишь посредством качественного алгоритма тестирования.

Интеллектуальный анализ данных в чистом виде работает иначе. Он используется для исследования паттернов ценовых изменений и построения по ним определенного алгоритма. Какие причины вызвали изменения на рынке здесь не так важно. Важно, чтобы они продолжали действовать и в будущем.

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

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

Позиции канала в цепочке

Данные варианты считаются наиболее простыми, они доступны пользователям бесплатной версии Google Analytics, а также Яндекс.Метрики и других систем. Рассмотрим 6 позиций канала в цепочке.

First Click (FCM)

В цепочке из четырех касаний ценность уходит первому каналу.

Преимущества:

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

Недостатки:

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

Кому подходит:

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

Last Click (LCM)

Одноканальная модель, где ценность конверсии передается последнему каналу, с которым покупатель соприкасается непосредственно перед конверсией. Снова вклад предыдущих каналов полностью игнорируется.

Преимущества:

Используется многими маркетологами. Позволяет оценить кампании, цель которых — быстро спровоцировать покупки, допустим, во время определенного сезона.

Недостатки:

Не демонстрирует всей картины, заставляя исключить прочие каналы цепочки.

Кому подходит:

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

Last Non-Direct Click (LN-DC)

Одноканальная модель, которая представлена в Google Analytics, применяется там по умолчанию. При этом ценность конверсии атрибутируется, как и в предыдущем варианте, по последнему каналу.

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

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

Преимущества:

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

Может применяться в качестве базы для сравнения.

Недостатки:

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

Кому подходит:

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

Position Based (PB)

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

Преимущества:

Ценность передается каналам, которые привлекают и мотивируют покупателей — т.е. играют важнейшую роль.

Недостатки:

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

Кому подходит:

Этот вариант подойдет бизнесам, которые рассчитывают привлекать новых пользователей и подталкивать уже заинтересованных к совершению покупок.

Time Decay (TD)

В этом случае ценность конверсии будет распределена между каналами, которые заняты в цепочке, по принципу нарастания. Первый источник получает наименьшую ценность, последний — наибольшую.

Преимущества:

Рассматриваются все каналы. Наибольшая ценность отдается тому, который все же сумеет подтолкнуть к покупке.

Недостатки:

Недооценивается вклад отдельных каналов, которые могли повлиять на решение покупателя.

Кому подходит:

Подходит тем, кто желает оценить эффективность рекламных кампаний, ограниченных по времени — например, распродаж.

Linear model (LM)

Применяя данную модель, ценность конверсии принято разделять между всеми каналами цепочки.

Преимущества:

Более продвинутая, чем одноканальные модели. Позволяет учесть все каналы в цепочке, которые были задействованы перед покупкой.

Недостатки:

Не помогает перераспределять бюджет. Разделение его между всеми каналами поровну может оказаться неэффективным.

Кому подходит:

Подойдёт бизнесам с длительным циклом продаж. В этом случае важно поддержание контакта с покупателем на всех этапах прохождения воронки. Пример — B2B-компании.

На сегодняшний день имеется ряд исследований, которые доказывают, что маркетологи в Европе, США или СНГ чаще всего обращаются к модели LCM. LCM кажется наиболее понятной, хотя и обесценивает влияние всех каналов в цепочке, кроме последнего.

Причинами, почему наблюдается такая ситуация, можно считать следующее:

• Непонимание потенциального эффекта от моделей атрибуции, использующих более сложный расчет. Если прямо объяснить, что алгоритмические модели могут принести увеличение прибыли на определенный процент, вряд ли маркетологи откажутся от этого.

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

• Слишком разрозненная информация. Google Analytics позволяет использовать стандартные отчеты, в которых, к сожалению, нет места офлайн-данным, ROPO-эффекту и т. д.

Если эти причины устранить, то проблема атрибуции будет решаться намного проще.

Сквозная аналитика как жизненная необходимость

Не более 30% клиентов делают заказ при первом же посещении сайта. Конкретное количество зависит от теплоты рынка и цикла принятия сделки, которая обычно невелика. Прежде чем что-то купить (совершить конверсию), человек, привлечённый разными рекламными источниками, заходит на сайт несколько раз.

Правильнее будет учитывать все касания (заходы) посетителя и использовать более продвинутые модели атрибуции.

Проблема 1:

Посетитель заходит на сайт из разных источников. Конверсия зачастую мультиканальна. Нужно применять некие модели атрибуции.

Проблема 2:

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

Проблема 3:

Каналы общения. Нужно отслеживать все каналы. В противном случае мы получим аналитику, не точно отражающую реальность, с необоснованными выводами, писанными вилами по воде.

Нельзя при этом считать заявки только через сайт или даже заявки звонки. Вот поэтому необходимо выстраивать сквозную аналитику.

Сквозная аналитика в маркетинге — метод анализа эффективности маркетинговых инвестиций (ROMI) на основе данных, отслеживающих полный путь клиента, начиная от просмотра рекламного объявления, посещения сайта и заканчивая продажей и повторными заказами (LTV).

Для реальной оценки эффективности маркетинга стоит поставить конкретную задачу:

Сквозной принцип в аналитике

При использовании обычной управленческой отчётности, в которой зафиксированы расходы на рекламу и продажи за тот или иной период, более-менее корректно ROMI посчитать можно только при определенных условиях:

В остальных случаях подсчёт будет некорректен. И главное, с такими данными мы можем посчитать только общий ROMI, но мы не узнаем ROMI отдельных рекламных каналов. Причина проста: мы знаем, сколько денег потратили на каждый рекламный канал, но не знаем, с каких именно пришли клиенты.

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

Логическая ошибка высокого ROMI

Основная логическая ошибка, которую сознательно, либо неосознанно, допускают многие маркетологи, это стремление к высокому ROMI. Кажется, что чем выше возврат инвестиций, тем лучше. Так ли это?

С одной стороны — да, высокий ROMI является прекрасным достижением.

С другой, следует учитывать 2 вещи:

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

• Сам по себе высокий ROMI — это не конечная цель, а лишь промежуточная. Поэтому кейсы маркетологов, где они гордятся высокими показателями ROMI, вызывают вопросы, если не описано, что дальше с этим делать.

Как считать? Пример:

Зеленым выделены лучше показатели, рыжим — худшие.

Как видим, при небольшом количестве трафика у нас максимальный ROMI, но минимальная выручка. Далее, при увеличении бюджета ROMI падает, стоимость привлечений 1 клиента растёт. До какого-то момента растёт общая прибыль, потом она начинает также падать. И наоборот, при большом трафике максимизируется ROMI уменьшается и становится отрицательным.

Зато валовая прибыль растёт и максимизируется лишь при ROI ~200%. Если же учитывать повторные заказы (LTV), картина меняется. Допустим, число повторных заказов равное 50% от числа новых заказов. Тогда прибыль максимизируется при ROI равном ~140%. Если же повторных заказов больше, выгодней удерживать еще меньший ROI.

А если повторных заказов больше? Тогда вполне возможно, что ROI ниже 100% даст максимальную долгосрочную прибыль. Понятно, что в реальных условиях даже максимизация прибыли не всегда является приоритетом: часто бывают риски, проблемы роста и многое другое. Но она явно намного важнее, чем максимизация ROI, которая является ложной целью.

Сравнение событийной (mixpanel) и сессионной (analytics) аналитики

	Mixpanel	Google Analytics
Просмотр страниц сайта	События появляются вручную, что затруднительно и порой допускаются ошибки.	Автоматически, через слежение за кодом.
Отслеживание воронок	Легко настраиваемые воронки	Настраивать воронки сложно, через пользовательские события
Отслеживание в реальном времени	Живой просмотр событий  в реальном времени	События не прослеживаются в реальном времени
Постановка задач	Легкая постановка задач, основанная на параметрах	Довольно сложная настройка, через customs reports.
A/B тестирование	Сбор данных о действиях пользователей с дополнительными свойствами для отслеживания показателей A/B тестов	A/B тестовый фрэймворк автоматизирован, но сложен в использовании.
Отслеживание нажатия на ссылки	Сложно делать это в автоматическом режиме, когда страницы меняются.	Автоматизированно, основано на URL
Цена	Зависит от data point, поэтому надо быть аккуратней и не тратить квоту.	Бесплатно до 10М data points/месяц
Поддержка	Быстрая поддержка от инженера в короткий период времени	Официальная документация — лучший источник.
Пользователи	Собирает данные о действии каждого пользователя и оставленных контактах	Агрегированные данные по всем пользователям

Событийная аналитика выглядит интереснее. Кроме того, она может дать не только аналитику, но и другие дополнительные возможности работы с вашими пользователями.

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

Уровни руководителей аналитиков данных

Задача руководителя аналитиков – масштабировать пользу от себя через свою команду. Например, если Вася – старший аналитик, то в роли менеджера Вася будет молодцом, если его команда из пяти аналитиков (и его самого) принесёт пользу хотя бы как три Васи.

Грейд руководителя обычно соответствует максимальному грейду сотрудника 1. Триггер для роста грейда руководителя – наличие трекшена по выращиванию людей до своего текущего уровня и их результативному менеджменту. Хорошо, когда руководителями становятся старшие аналитики, но жизнь сложна и иногда в порыве роста компании менеджерскую функцию приходится брать и специалистам среднего уровня.

Руководитель аналитики 0

На самом деле такого грейда не существует, но я завел данную категорию, чтобы подчеркнуть, что наставничество не является менеджментом, как могут подумать некоторые начинающие наставники =)

Руководитель аналитики 1 (Analyst team lead)

Структура команды

Начинающий руководитель. Несколько аналитиков в прямом горизонтальном подчинении. Оптимально – до 5, но бывает и больше.

Наставничество

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

Мотивация

Руководитель аналитики 1 занимается мотивацией сотрудников на ежедневной основе в рамках регулярных встреч с командой и отдельными сотрудниками. Формулирует вдохновляющие цели и помогает их достигать, делает так, чтобы команда чувствовала себя командой и возникала синергия от взаимодействия разных аналитиков, даже если они занимаются разными вопросами.

Экспертиза

Руководитель аналитики 1 обладает экспертизой в той части бизнеса, за которую отвечает, и является ключевым лицом, формирующим требования к данным по своему кусочку домена (например, перформанс маркетинг или клиентский продукт). Эти данные впоследствии будут переиспользоваться другими командами. Важно, чтобы они были корректны, удобно спроектированы и задокументированы. Это позволяет снижать порог входа для коллег.

Процессы

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

С другой стороны – команда аналитиков должна находиться в одном контексте с бизнесом, они должны понимать друг друга с полуслова. Обычно это означает, что есть принятые ритуалы взаимодействия. В разных командах и компаниях они могут быть разными. Примеры: стендапы команды аналитики, регулярные встречи про приоритеты с бизнесом, семинары для обмена опытом, регулярные встречи один на один с руководителем, отчетные выступления о результатах работы аналитиков за сезон, правила работы над задачами (тикеты, код под контролем версий, нейминг метрик в отчетах и т. д.)

Подчеркну, что всё перечисленное – это артефакты деятельности руководителя, главное же – это смысл: аналитики должны приносить максимальную пользу, работать эффективно.

Руководитель аналитики 2 (Head of some analytics)

Существенное отличие от предыдущего уровня – в структуре команды и выросшей зоне ответственности.

Структура команды

У руководителя 2 существенно больше команда, поэтому в ней появляются промежуточные руководители. Обычно их 3-4. С точки зрения ответственности – всё то же самое, но в большем масштабе.

Процессы

Руководитель этого уровня занимается системными вопросами, которые помогают его команде и компании работать эффективнее. Это может касаться:

Как правило, руководитель такого уровня – опытный аналитик. Он хорошо знает, какие задачи бывают у аналитиков, с какими сложностями в процессе они сталкиваются. Одна из зон ответственности руководителя аналитики 2 уровня – удобная аналитическая инфраструктура и среда: виртуалки, jupyter hub’ы, библиотеки, облегчающие рутину, удобные витрины данных и т. д.

Является квалифицированным заказчиком для команды аналитического хранилища (DWH). Руководитель аналитики может не являться профессионалом в машинном обучении, но, безусловно, с предметной областью знаком и может говорить с data scientist на одном языке.

Хорошо понимает, когда задачу стоит решать методами машинного обучения. Это позволяет ему быть квалифицированным заказчиком для команды ML.Если компания маленькая, то руководителю аналитики на данном грейде могут быть подчинены команды DWH и Data Science.

Наставничество

Руководит руководителями 1 уровня. А значит, умеет воздействовать на команды и процессы в них без непосредственного вмешательства, а через промежуточного руководителя. Является наставником для начинающих руководителей.

Руководитель аналитики 3 (Директор по аналитике – Chief Data Officer / Chief Analytics Officer)C-level*.

Является частью топ менеджмента. Обладает отличным знанием и пониманием контекста (в том числе непубличного), в котором живет компания и рынок, цели и проблемы компании. В широком смысле отвечает за эффективность компании, помогая улучшать её с помощью аналитики и работы с данными.

Чтобы быть успешным директором по аналитике, нужно безусловно быть профессионалом в аналитике. Но описание роли директора больше похоже на описание роли любого другого директора в компании, если не учитывать предметную область.* Большие корпорации имеют сложные и разветвленные структуры.

Структура команды

Десятки или даже пара сотен человек (в зависимости от размера компании) разных специальностей:

Лидерство

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

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

Прикладные задачи

Директор по аналитике занимается прикладными аналитическими задачами очень ограничено – как правило это важные исследования, на основании которых принимает решения топ-менеджмент. Что такое важные вопросы, в которых директор по аналитике участвует непосредственно, но которые при этом не являются частью построения системы? Приведу примеры:

• построение системы kpi для всей компании и выставления целей по ним,
• оценки профита от проектов и их ранжирование в рамках регулярного планирования,
• построение прогнозных моделей компании и рынка,
• исследования, которые могут поменять стратегию компании,
• оценка потенциальных сделок M&A,
• интеграционные проекты по результатам M&A,
• проекты про данные, несущие большие регуляторные риски, например, на соответствие GDPR, SOX и другим дорогим аббревиатурам.

Процессы

В больших компаниях директор по аналитике (как и любой другой директор) не может контролировать каждый вопрос или задачу, которые возникают в его направлении, но при этом его функция – сделать так, чтобы результатам аналитики, на основе которых принимаются решения в локальных командах, можно было доверять, аналитика была actionable и приносила измеримую пользу бизнесу.

Директор добивается этого через найм правильных людей, их развитие и мотивацию, выстраивание процессов внутри компании (в широком смысле, не только аналитических), улучшение аналитической инфраструктуры, определение фокусов и целей команд. Чтобы нанимать лучших людей с рынка, директору приходится заниматься hr-брендом своего направления.

Цифровизация бизнеса

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

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

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

Компании тратят деньги на рекламу, привлекают клиентов, получают прибыль с продаж своих товаров и услуг. Логично будет применить к интернет-маркетингу показатель возврата инвестиций ROI, а точнее, ROMI.

Return on Marketing Investment или сокращенно ROMI — это показатель рентабельности рекламных кампаний и в целом инвестиций в маркетинговую деятельность. Рентабельность оперирует такими метриками, как окупаемость, прибыль, возврат вложений.

Посчитать ROMI не так просто, как кажется. Посмотрим на простом примере.

ROMI равен 75%. Коэффициент выше 0, т.е. вроде бы всё хорошо. Но всё ли правильно мы посчитали?

Представим, что застройщик построил новый ЖК, создал для него сайт и запустил рекламную кампанию. Вот статистика за первые полгода:

Иллюстрация: Оля Ежак для Skillbox Media

Онлайн-журнал для тех, кто влюблён в код и информационные технологии. Пишем для айтишников и об айтишниках.

Эксперт департамента аналитических решений ГК «КОРУС Консалтинг». В IT с 2000 года. Автор Telegram-канала Analytics Now и подкастов по теме искусственного интеллекта и анализа данных.

Если вы интересовались IT или искали работу, то наверняка встречали в интернете вакансии бизнес-аналитиков. В них обещают интересную работу, карьерный рост и достойный доход. Давайте разберёмся, кто такие бизнес-аналитики, чем они занимаются и что необходимо для успешного старта в этой профессии.

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

Допустим, коммерческому отделу розничной сети хочется оперативно видеть недельные результаты продаж с детализацией по отдельным магазинам и целым регионам. Они приходят к бизнес-аналитику и рассказывают, что должно быть в финальных отчётах. А задача бизнес-аналитика — «переложить» их слова на язык, понятный разработчикам аналитической системы, то есть составить техническое задание с чёткой логикой: какие показатели собираются, из каких источников берутся данные, в каком виде они выводятся и на каких экранах или дашбордах их надо разместить.

Бизнес-аналитик собирает и структурирует данные. Обычно данные представляются в специализированных IT-системах (ERP, CRM, BI и так далее) — поэтому работа аналитика чаще всего связана с внедрением этих систем, а точнее, с подготовкой к их внедрению и с расширением их функциональности.

В ходе предпроектного анализа аналитик изучает текущее состояние компании и требования бизнес-заказчика, определяет границы будущего решения. Это как раз то, что мы описывали выше: бизнес-аналитик «снимает показания» пользователей, анализирует источники данных и описывает их на языке, понятном будущим разработчикам.

На этапе анализа в рамках проекта бизнес-аналитик работает с конкретными требованиями. Его задача — выявить, описать и согласовать их. В случае каких-либо изменений бизнес-аналитик будет управлять и запросами на изменения. Этот процесс связан с задачами первого этапа: о собранных на нём требованиях должны договориться и пользователи, и технические специалисты.

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

Обычно бизнес-аналитик не работает в одиночку — он член команды. Совместно с топ-менеджерами организации он участвует в работе над стратегией компании и проекта. А вместе с разработчиками, консультантами, дизайнерами, инженерами он создаёт прототипы и готовит документацию.

Результат работы бизнес-аналитика — это описание верхнеуровневых бизнес-требований, создание технического задания с описанием сценариев в форматах use cases и user stories. Таким образом он перекладывает язык бизнеса на язык технологий.

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

Одним компаниям необходимо увеличить выручку, другим — привлечь новых клиентов, третьим — улучшить взаимодействие с текущими заказчиками или понять причины постоянных перебоев с поставками. Главные для решения этих задач ответы могут дать как раз бизнес-аналитики.

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

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

Количество задач в области анализа данных растёт пропорционально росту самих данных. На первое место в последние годы выходит отдельное направление — анализ больших данных, то есть неструктурированной информации из многочисленных источников.

Согласно прогнозу консалтинговой фирмы Frost & Sullivan, рынок анализа Big Data к 2025 году достигнет почти 70 миллиардов долларов США, в то время как ещё в 2019 году он составлял всего 15 миллиардов. Это означает, что спрос на специалистов в этой сфере со временем лишь увеличится.

Чтобы оперативно и точно собирать информацию, а также представлять результаты анализа в удобном виде, бизнес-аналитики пользуются рядом программных продуктов. Список конкретных инструментов может разниться от задачи к задаче и от компании к компании, но в целом набор примерно одинаковый.

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

• MS Excel — незаменим для базовых расчётов, составления таблиц и простых диаграмм. Продвинутые пользователи Excel могут использовать надстройку VBA, которая помогает писать макросы для автоматизации действий в Excel.
• Средства для представления результатов анализа. Понадобятся для того, чтобы отчитаться о завершённой задаче. Таким средством может быть стандартный MS PowerPoint, может быть Keynote или что-то более сложное — например, Prezi.
• Решения для управления задачами. Таск-трекеры помогают структурировать работу над проектом, отслеживать сроки и ресурсы, синхронизировать задачи, отслеживать дедлайны, а также хранить документацию и переписку по проекту. Примеры: Trello, Asana, Jira, Wrike — выбор довольно большой даже с учётом санкций.
• BI-системы — главный инструмент комплексной визуализации результатов анализа данных. На рынке есть сотни систем бизнес-анализа: от простых и квазибесплатных до сложных и требующих серьёзных инвестиций. Есть решения с расширенной функциональностью, такие как международные QlikView, Qlik Sense, Microsoft Power BI, Tableau. Однако в последние годы на рынке появилось и много российских систем, которые активно работают над тем, чтобы догнать западных конкурентов: Luxms BI, «Форсайт», Superset и другие. В любом случае BI-система может заменить Excel и ПО для визуализации результатов и готовить инсайты оперативно — иногда даже в режиме реального времени.

Если вы владеете языками программирования и умеете строить модели данных, то ваши шансы на успех в роли бизнес-аналитика велики. Однако даже без этих знаний есть все возможности для карьеры в этой области.

Тем не менее несколько софт-скиллов делают бизнес-аналитика успешным.

Умение анализировать информацию. Вы должны уметь обрабатывать и интерпретировать данные, чтобы делать правильные выводы. Чёткая структура — это половина успеха в решении бизнес-задачи, поставленной перед вами. Тщательно анализируя информацию, укладывая её в структуру, вы можете формулировать новые гипотезы, проверять их, выбирать корректные решения, а также оценивать возможные риски и находить способы их минимизировать.

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

Английский язык. Даже если бизнес-аналитик работает в компании, которая не ведёт деятельность за пределами России, английский язык — важный элемент его работы. Огромное количество англоязычных материалов в интернете аккумулируют лучшие мировые практики — например, как правильно построить процесс достижения цели, которую ставит перед собой организация.

Что касается хард-скиллов, то их набор сильно зависят от отрасли и компании. Но в целом потребуются следующие навыки:

• опыт работы с базами данных и BI системами, а также опыт их внедрения;
• владение перечисленными выше инструментами: Excel, BI-системами, программами для создания презентаций, таск-трекерами;
• знание SQL и/или Python, иногда — ML;
• визуальный вкус, навыки общения с пользователями BI-систем, умение составлять симпатичные презентации, отчёты и визуализации;
• знание основ матанализа и статистики;
• знание методологии разработки программных продуктов и различных способов описания требований (use cases, UML-диаграммы, user stories).

В зависимости от того, в какой компании и в каком городе России работает бизнес-аналитик, его карьерный путь может выглядеть по-разному. Но в общем случае ступени карьерной лестницы выглядят так:

• Младший бизнес-аналитик: начинающий специалист, отвечает за сбор и структуризацию части данных в проекте. Новички получают от 30 до 70 тысяч рублей.
• Бизнес-аналитик: помогает консультантам с анализом данных и подготовкой инсайтов. Такие специалисты могут ожидать доход в среднем от 70 до 150 тысяч рублей.
• Старший бизнес-аналитик: решает более сложные задачи, отвечает за определённую область данных. Такие специалисты с опытом 3–5 лет зарабатывают от 120 до 250 тысяч рублей.
• Ведущий бизнес-аналитик: имеет комплексный взгляд на данные, которые использует компания, может руководить группой бизнес-аналитиков.
• Эксперт, тимлид: руководит группой бизнес-аналитиков, отвечает за определённую область (отраслевую, технологическую), участвует в работе над стратегией компании.

Но этот линейный путь очень условен. С позиции старшего бизнес-аналитика специалист может уйти на менеджерскую должностт. Обычно это хороший выбор, потому что за счёт специфики своей работы и участия в кросс-функциональных командах бизнес-аналитик понимает особенности развития продуктов и проектов, а также то, как протекают процессы в разных департаментах. Поэтому бизнес-аналитик может перейти на позицию владельца продукта (product owner), менеджера продукта, коуча по Scrum- или Agile-методологиям, менеджера проектов.

В любом случае работа бизнес-аналитика — это отличный старт для карьеры в IT и прекрасный способ познакомиться на практике не только с различными областями знания и отраслевой спецификой, но и со многими ролями внутри отрасли.

Научитесь: Профессия Бизнес-аналитик
Узнать больше