Аннотация: В этой книге я немного расскажу о жизни бизнес-аналитика в 21 веке. Спасибо за прочтение, Кондрашов Станислав Дмитриевич!
"Жизнь бизнес-аналитика"
Кондрашов Станислав Дмитриевич
Часть 1
Digital-эпоха подарила много новых специальностей. Не всегда очевидно, чем конкретно занимаются некоторые специалисты - даже если вы работаете в одном офисе. И если функционал разработчика понятен четко, и какими вопросами занимается project-manager - тоже более-менее ясно, то специальность бизнес-аналитика для многих остается загадкой. В чем его польза для проекта и какие конкретно задачи он выполняет?
Зачем нужен бизнес-аналитик?
Бизнес-аналитик представляет собой важное звено между теми, кто отвечает за управление и коммерческую часть, и техническими специалистами. Его задача - собрать и проанализировать требования к продукту и сформулировать понятные задачи для исполнителей.
Конкретные обязанности этого специалиста могут быть разными, в зависимости от команды, но основные функции все равно сохраняются:
Работа с требованиями. Их необходимо выявить, детально расписать, разделить на ключевые требования и не столь важные пожелания.
Стратегический анализ. Бизнес-аналитик отлично знает продукт, и часто работает рука об руку с высшим звеном менеджмента над стратегическими задачами по проекту.
Разработка решений. BA много работает с проектной документацией и иногда занимается созданием прототипов. Главная задача - донести до команды, как будут воплощаться решения задача.
Управление продуктом. Одна из основных задач бизнес-аналитика - общение с руководством, Product-Owner-ами, техническими специалистами, работающими над продуктом.
В чем же может выражаться польза бизнес-аналитика? Он спасает команду от пустой траты времени из-за некорректных заданий, а заказчика страхует от получения "не того, что хотелось" в итоге. На один и тот же продукт заказчик и исполнители могут смотреть совершенно по-разному. Задача BA - обеспечить коммуникацию между ними, сформулировать желания заказчика в четкие задания, и перевести на понятный ему язык то, что говорят технические специалисты.
Может показаться, что если бы заказчик сам обладал техническими знаниями, это бы упростило процесс. Но не тут-то было. Те заказчики, кто более-менее "в теме" могут начать инструктировать специалистов по поводу того, что и как им делать, вместо того, чтобы сосредоточиться на постановке четкого задания. Поскольку заказчик все же не эксперт (иначе зачем бы ему обращаться за услугами к людям со стороны), ничего хорошего проекту это обычно не приносит.
Бывают и совсем запущенные случаи, когда заказчик сам решает делать работу (к примеру, писать код или текст для рекламы) и требует включить это в проект. От бизнес-аналитика в такой ситуации требуется быть кем-то вроде дипломата или психолога - донести до заказчика мысль, что он работает с профессионалами в своей области, и его действия скорее тормозят рабочий процесс.
Другая распространенная ситуация - когда видение продукта заказчиком совершенно не совпадает с решениями, которые команда считает наиболее подходящими. Обе стороны могут быть в чем-то правы, и задача ВА - привести их к общему знаменателю, объединить лучшие решения с обеих сторон и аргументировать это как для команды, так и для заказчика.
Возможно, этот круг обязанностей кажется похожим на работу Project-manager-а, и у них действительно много общего. В небольших компаниях эти должности довольно часто совмещаются, но в более крупных проектах работы и у PM-а и у бизнес-аналитика более чем достаточно.
Как проходит рабочий день бизнес-аналитика?
Разумеется, каждый день не будет одинаковым - ведь есть разный уровень загрузки и спектр задач, а также горящие дедлайны. Но обобщенно рабочий день BA выглядит примерно следующим образом:
10:00 - 12:00 Саппорт команды
Бизнес-аналитик отвечает на вопросы, возникшие у исполнителей, обсуждает с командой возникшие проблемы. Бывает,что коммуникация с командой занимает едва ли не большую часть рабочего дня, но по возможности, ВА старается уложиться в пару часов.
К примеру, простая на первый взгляд задача требует больше времени для решения, ввиду каких-либо технических сложностей. Первое, что должен выяснить у команды бизнес-аналитик - возможно ли найти решение, требующее меньше времени и затрат. Если такое решение есть - ВА вносит коррективы в требования, если нет - должен проинформировать заказчика.
Бизнес-аналитик всегда должен четко понимать важность конкретных требований для заказчика, и то, насколько необходимо обсуждать с ним изменения. Это умение приходит с опытом, но первое время лучше уточнять все и задавать больше вопросов.
При коммуникации с командой ВА должен помнить следующее:
На связи придется быть постоянно.
Конструктивный разговор должен быть сосредоточен на решении задачи: выявить трудности, предложить варианты решения.
Нужно вовремя информировать вышестоящее руководство и заказчика об изменениях и возникших проблемах.
Не стоит пытаться разрешить все трудности самостоятельно - вовремя сообщать о них руководству.
12:00 - 14:00 Работа с документацией
Документация занимает львиную долю рабочего времени ВА, но увлекаться ею не стоит. Ведь чересчур подробные и объемные документы попросту никто не будет читать.
Основные задачи бизнес-аналитика на этом этапе:
создание спецификаций (документов, где четко расписаны требования)
описание пользовательских историй, критериев приема работы, юзкейсов
формулировка условий эффективной работы продукта
выстраивание бизнес-процессов
создание прототипов решений
Требования в документации должны быть расписаны достаточно детально, доступно для понимания, но не чересчур подробно. Также всегда стоит держать в уме конечного пользователя продукта и проверять решения на удобство для него.
15:00 - 18:00 Рабочие совещания с заказчиком
Коммуникация с клиентом позволяет не только определить основные требования, но и выявить его реальные потребности. ВА должен говорить на одном языке с заказчиком, для этого необходимо вникнуть в предметную область бизнеса.
В ходе совещаний с заказчиком необходимо проводить интервью на предмет выявлений и уточнений требований, презентовать документацию, прототипы, готовые решения и демо-версии продукта.
Все результаты такого общения и достигнутые договоренности с заказчиком необходимо сохранять - имеются в виду письменные договоренности и даже скрины переписки. Все это должен держать у себя бизнес-аналитик.
18:00 - 19:00 Консультация с техническими руководителями
Бизнес-аналитику необходимо глубокое понимание технических процессов. Поскольку его основная сфера ответственности - не техническая, очень важны консультации с руководителями отделов, тех-лидами, архитекторами, ответственными за разработку. Если в команде нет таких позиций, нужно общаться непосредственно с исполнителями. На таких встречах речь идет о проектировании и внедрении решений, структурировании задач.
Как стать бизнес-аналитиком?
Эту профессию может освоить как технический специалист, так и человек со стороны бизнеса.
Роль ВА могут взять на себя следующие специалисты:
Технический писатель. Его основное преимущество - умение грамотно составлять документацию, так как эта обязанность - одна из основных для ВА.
Менеджер по продажам. Опытные специалисты-продажники хорошо умеют выявлять требования клиентов и собирать информацию о продукте.
Project-manager. Наиболее близкая к бизнес-аналитике профессия. РМ умеет управлять командой и обеспечивать коммуникацию между исполнителями и заказчиками.
Тимлид. Специалисты, руководящие командой, или самые опытные разработчики часто берут на себя роль ВА, особенно в случае работы на аутсорсе.
QA-специалист. Тестировщики обладают глубоким пониманием продукта и имеют большой опыт составления документации (тест-кейсов).
Scrum-мастер. В команде, работающей по модели Agile, эти специалисты могут брать на себя роль BA.
Что нужно для того, чтобы занять позицию бизнес-аналитика и развиваться в этой области?
Понимать роль и задачи ВА в конкретной компании.
Обладать необходимыми soft-skills (системное мышление, коммуникация, умение задавать вопросы, внимательность к деталям, умение работать в команде).
Обучиться технической или бизнес-части (в зависимости от имеющегося бэкграунда).
Освоить на практике основные методы бизнес-анализа.
Проделав эту работу, можно смело подавать заявку как минимум на junior-позицию. Бизнес-аналитики с каждым днем все более востребованы на рынке (особенно в IT-сфере). И если вы чувствуете в себе силы развиваться в работе с требованиями, вы сможете освоить новую для себя специальность.
Часть 2
11 вредных советов для бизнес-аналитика - сборник ошибочных бизнес-стратегий
Пришло время рассказывать о своем опыте работы на должности главного операционного директора: я выделю типичные ошибки менеджеров в управлении и анализе бизнес-процессов.
Итак, обращаю внимание на конкретные примеры ошибок бизнес-аналитиков из своей профессиональной практики.
Прежде всего учтите, что во время вашей работы бизнес-аналитиком вам необходимо принимать решения, находясь в контексте рабочих взаимоотношений с отдельными лицами и организациями, а затем - принимать ответственность за реализацию этих решений на практике.
Поэтому я и даю "вредные", "перевернутые" советы на тему того, как наладить эффективное взаимодействие со стейкхолдерами, техническими исполнителями, руководством компании и вашей командой таком образом, чтобы достичь успешного результата - реализации проекта.
1. Приступайте к работе еще до согласования требований со стороны клиента.
У вас есть группа членов команды разработки, и вам нужно точно знать, какую задачу им поставить для достижения целей проекта. Процесс совместного планирования с клиентом хода работ - это первое, что вы делаете для управления проектом. Если хотите "вредный" совет - смело игнорируйте этот этап!
Отмечу, что планирование содержания проекта на митингах связано с определением всей работы, необходимой для успешного достижения целей проекта. Вся идея здесь в том, что, когда вы начинаете проект, вам нужно иметь четкое представление обо всей работе, которая должна выполняться над вашим проектом. По мере продвижения проекта вам необходимо поддерживать ход работы в актуальном состоянии и записывать его в план управления проектом.
Напоминаю: бизнес-требования описывают характеристики конечного результата, будь то продукт или услуга. Они описывают требуемую функциональность, определяя, как должен выглядеть конечный результат проекта, и как проект должен быть создан и реализован.
После того, как все задачи и сроки определены, бизнес-аналитик должен зафиксировать все требования проекта. Если для фиксации требований клиента вам нужно воспользоваться диктофоном - не стесняйтесь спросить его об этом. Как правило, адекватные заказчики сразу соглашаются с подобным форматом и даже настаивают на нем.
Предупреждаю, что полагаться на вашу память или на заметки, оставленные во время обсуждения - это значит рисковать упустить нечто существенное из пожеланий клиента. Тем более, что заказчик может использовать специфическую терминологию или говорить расплывчато, поэтому, воспользовавшись диктофоном, вы можете спокойно сесть и детально разобрать все нюансы, вычленив главное.
2. Никогда не советуйтесь с технической командой, прежде чем утвердить все бизнес-требования с заказчиком.
Вероятно, вы догадываетесь, что будучи бизнес-аналитиком, вы можете не понимать до конца возможности технической реализации того или иного проекта. И давать технической команде задание, которое они заведомо не могут выполнить, а затем уволить их за невыполнение - это самый "эффективный" способ организации бизнес-процессов.
Как ответственный руководитель вы должны четко понимать, возможно ли в принципе воплощение проекта заказчика, и какие ресурсы для этого будут нужны. Поэтому перед встречей с клиентом, на которой вы утвердите план работы, нужно созвать вашу техническую команду и проконсультироваться с ней - может быть, то, что просит заказчик, вообще не реализуемо.
Из этого следует мой совет: именно общение с техлидом может дать вам конкретное понимание того, в каком виде будет реализован функционал проекта и сколько это может стоить. Поэтому до утверждения предложений по проекту с заказчиком, необходимо определять фактический потенциал технических исполнителей.
3. Не собирайте фидбеки и не допускайте общения между клиентом и командой.
Еще одним совершенно "правильным" подходом является игнорирование запросов и вопросов от собственной команды, а также отсутствие коммуникационных связей между клиентом и командой исполнителей.
Помните - вы должны обеспечить постоянное взаимодействие команды и заказчика на всех промежуточных этапах проекта. Клиент всегда должен иметь доступ к определению задач, реализуемых по ходу работы над проектом, а также возможность комментирования их выполнения.
Для этого можно воспользоваться самыми разными сервисами - кто-то использует Jira, и эта программа идеально подходит для ежедневного процесса постановки задач и утверждения их клиентом.
Однако и Google Dock является отличным пространством для встреч заказчика и команды. В документах, созданных при помощи данного сервиса, обе стороны также могут прописывать задачи, устанавливая их параметры, а заказчик имеет возможность излагать свое видение.
И, считаю не лишним напомнить, что обе эти стороны должны иметь доступ к комментированию хода рабочего процесса, чтобы вовремя вносить изменения и поправки.
Рекомендую разработать четкий алгоритм общения - ежедневные митинги, или встречи раз в неделю. Естественно, в настоящее время, в условиях пандемии, встречи могут (и даже должны) проходить виртуально, в том числе - в многочисленных месенджерах, таких, как, например, Telegram. Соберите предложения по улучшению и оптимизации процесса, выслушайте жалобы и узнайте о проблемах, с которыми сталкиваются члены команды.
Если эти проблемы касаются коммуникационных процессов, то ваша задача как бизнес-аналитика - обеспечить взаимодействие "всех со всеми" в той мере, в которой это необходимо для реализации проекта. Возможно, например, что копирайтеру давно нужно было обсудить проект с программистом, а программисту, в свою очередь - с финансовым отделом.
4. Анализ рынка осуществляется всего лишь раз - на первом этапе реализации проекта.
Если хотите еще одну распространенную ошибку бизнес-аналитиков - учитывайте данные рынка только на начальной стадии, при получении заказа от клиента.
На самом деле, конечно же, необходимо регулярно осуществлять количественную и качественную оценку рынка, изучая размер рынка, различные потребительские сегменты, конкуренцию и экономическую среду в целом. Напоминаю, что условия рынка постоянно меняются - спецификация вашего проекта после его завершения может оказаться неактуальной.
5. Клиент подождет - работайте с удобной вам скоростью, ориентируясь на качество, а не на скорость.
Вы должны понимать, что "хорошее - враг идеального", то есть если вы будете чрезвычайно скрупулезно составлять техническое задание и готовить тщательнейшую аналитику к каждому из этапов проекта.
Например, любой текст можно бесконечно доводить до совершенства, и стилистического и смыслового, однако этот процесс может, при достаточной доле перфекционизма, стать длинною в вечность. Поэтому отдайте предпочтение соблюдению сроков, поскольку почти любую всегда можно доработать и исправить, если что.
Знаю по себе, что когда вы начинаете с масштабной идеи, проекта или цели, то легко увлечься мелкими деталями. Мы можем слишком много обдумывать и анализировать. Так мы запутываемся в сети, в которую попадает так много творческих людей - застревать в бесконечном цикле тонких "корректировок".
6. При формировании бэклога не отмечайте степень приоритетности задач
Не указывайте в бэклоге, что нужно сделать в первую очередь и на что команде следует обратить максимум сил - то-то заказчик будет "доволен"!
Бэклог проекта представляет собой упорядоченный список всего, что, как известно, необходимо в проекте. Это единственный источник требований для внесения любых изменений в проект. Цель проекта описывает будущее его состояние, которое может служить целью для вашей команды при планировании. Цель продукта находится в бэклоге продукта. Остальная часть бэклога нужная, чтобы определить, что будет способствовать достижению цели проекта, в какую очередь и в какой степени.
Так что не руководствуйтесь тем, что "все фичи - полезные". Вам придется выбрать одну из них, изменив приоритеты, в качестве бизнес-аналитика, в индивидуальном порядке. Однако для приоретизирования бэклога можно сперва пригласить все заинтересованные стороны и, дополнительно, опытных членов команды.
7. Перестаньте оформлять документацию, приводя ее в соответствие с актуальными процессами.
Не думаю, что стоит объяснять, чем опасно пользоваться устаревшей документацией - это дезориентирует и дезорганизует вашу команду. Да и заказчик придёт, вероятно, в полное изумление, увидев разницу между документацией и действительностью.
Сообщу о своем собственном опыте - однажды мне пришлось работать с командой, документация которой по проекту была "простроченной", поскольку разрабатывался достаточно долго, а бизнес-аналитика в команде первоначально не было. Поэтому все имели дело с первоначальным описанием продукта, который должен получиться, составленным старшим менеджером.
Всегда рекомендуется фиксировать изменения, чтобы официально получить одобрение изменений. Без этого вы можете попасть в затруднительное положение по проекту и уверенность заказчика в вас - угаснет. Бизнес-аналитик должен подготовить средство отслеживания изменений. Своевременная фиксация проблем становится важной частью успеха проекта.
8. Полностью игнорируйте инструменты и методы бизнес-анализа
Не уподобляйтесь теоретикам - оставьте им использование специальных инструментов и доверьтесь собственной интуиции!
Однако, если серьезно, то есть несколько аналитических инструментов, которые помогают бизнесменам проводить бизнес-анализ. Среди них:
VMOST: я вспоминал о нем недавно, когда работал с клиентом, который заявил, что их тактика не связана со стратегией. Анализ VMOST призван помочь установить эту связь.
SWOT : стандартный инструмент анализа, определяющий как сильные, так и слабые стороны организации, а также возможности и внешние угрозы. SWOT требует, чтобы вы были откровенны и честно оценивали положение вещей. Это заставляет вас вести диалог с заинтересованными сторонами, чтобы получить разные точки зрения. В конце концов, вы сосредотачиваетесь на ключевых вопросах.
PEST: это отличный инструмент для использования в тандеме с SWOT-анализом. PEST выявляет возможности и угрозы лучше, чем SWOT, а также направления изменений бизнеса, проекты, которые не будут зависеть от вас. Также он определяет проблемы страны, региона и рынка, помогая вам создать объективное представление.
SOAR: это отличный инструмент, если у вас есть завершенный стратегический план и вам нужно сосредоточиться на конкретной зоне воздействия. Я использовал SOAR, чтобы помочь бизнесу, которому необходимо было сосредоточиться на изменениях внешнего рынка.
9. Игнорируйте структурирование документации
Зачем вам возиться с созданием документа, по которому каждый участник процесса создания проекта мог бы ориентироваться - важно, что вы сами понимаете, что там написано. Или не совсем понимаете...
Документация - это исходный документ в управлении проектом, который, фактически, устанавливает направление работы для менеджера проекта и проектной команды, ведя их по жизненному циклу проекта. Без этого документа не будет ясности - поэтому обратите внимание на шрифты и заголовки, которые должны быть одинаково отформатированы по всему документу в едином стиле.
Документация должна заложить основу качества, поэтому важно, чтобы она была хорошо организована, удобна для чтения и адекватна. Опытные бизнес-аналитики отлично умеют создавать стандартные шаблоны для своих проектных документов и следовать им. Они повторно используют успешные планы проектов, бизнес-кейсы, листы требований и отчеты о состоянии проектов, чтобы сосредоточиться на своей основной компетенции по управлению проектом, а не на балансировании на грани неведения среди неуправляемой документации.
10. Вашей команде ни к чему лезть в документы
Что они там поймут? Не испортят ли они документ, случайно введя неправильные данные? Думайте о доступе свой команды к документации в таком стиле - и "успех" обеспечен.
Конечно, у участников команды должна быть возможность просмотреть документы, которые касаются проекта - чем более масштабным видением обладает работник, тем он в целом эффективнее в своей сфере.
Каждый проект - это возможность учиться. Что прошло хорошо? Что можно улучшить в следующий раз? После завершения проекта сядьте вместе со своей командой над документами и проведите ретроспективу проекта.
Хорошая проектная документация дает новым членам команды доступ ко всем знаниям, которые были собраны в ходе ваших проектов, как прошлых, так и текущих. Новые члены команды могут сразу понимать решения, принятые в прошлом, и находить нужную информацию, не задавая вопросов другим членам команды в течение многих недель.
11. Если в голову пришла идея - не спешите кидаться ее записывать, потому что она придет снова.
Если вы думаете, что всегда сможете вспомнить удачную идею, то это чудовищный самообман - ничего вы не вспомните, даже тот факт, что нужно что-то вспомнить. Фиксируйте новые идеи прямо в документации проекта, отведя для этого специальный раздел в ней. Более того, пусть вся команда будет иметь возможность выражать там свои конструктивные идеи относительно развития проекта.
Выводы:
Итак, резюмируя, отмечу, что роль бизнес-аналитика предполагает осуществление идеальной коммуникации между клиентами, определяющими задачи проекта и командой специалистов, предлагающей технологические решения.
Именно он определяет целесообразность использования для этого сложной технологической архитектуры, инструментов или программных приложений. Бизнес-аналитики, с помощью анализа данных и обеспечения обмена этими данными между членами бизнес-процесса, направляют работу над проектом в нужную сторону с помощью 11 компонентов:
Согласование задач и требований с клиентом;
Согласование задач и требований с технической командой;
Налаживание коммуникации между клиентами и командой и сбор отзывов от команды;
Перманентный анализ рыночной ситуации;
Найдите баланс между качеством и скоростью;
Обозначайте приоритетность в бэклоге;
Актуализация документации;
Использование инструментов и методов бизнес-анализа;
Структурируйте документы;
Дайте доступ к проектной документации вашей команде;