Каждому из нас наверняка приходилось слышать один и тот же вопрос от своих родителей или друзей не из «программистской тусовки»: «А что вы там на своей работе вообще делаете?».
Обычно, после попытки ответить следует еще неизменный комментарий: «Эх ты, программист, даже холодильник починить не можешь». Что уж говорить про бизнес-аналитиков, которые и коллегам-то объяснить толком не могут, чем занимаются.
Я и сам часто слышу этот вопрос от своего отца, да все никак не могу найти правильный ответ. И правда, чем мы вообще занимаемся на работе — анализируем!
Специально для этой статьи мне пришлось основательно покопаться в архивах JIRA с трех последних мест работы. За абсолютную точность не ручаюсь (да, мне тоже не нравится расписывать все свои занятия до последней минуты), но общая картина действительно совпадает с собственными ощущениями от выполняемых обязанностей.
Примерное распределение работы можно описать так:
А вот точное количество часов за последние 3 месяца:
Как видите, картина действительно похожая. Небольшие различия – отсутствие командировок и большее время работы с командой – возникают из-за недавней смены места работы и, соответственно, процесса интеграции в новую среду.
Теперь давайте рассмотрим каждый пункт подробнее.
Начнем с самого главного — с того, чего, собственно, и начинается бизнес-анализ — с деловых встреч, куда отнесем и встречи с клиентами, и внутренние собрания с командой.
Прежде всего, это — анализ предметной области и сбор требований. Именно здесь мы узнаем, чего вообще от нас хочет клиент, какие у него есть проблемы, предлагаем первые идеи по реализации и вместе составляем предварительный план проекта.
Другие важные элементы встреч с клиентами — обсуждение выполненных работ, планирование изменений, презентации и тренинги, на которых мы рассказываем, как пользоваться предложенным продуктом.
Пожалуй, именно встречи являются основой нашей работы, именно они обеспечивают аналитиков и их команды дальнейшими заданиями, поэтому именно к ним стоит готовиться наиболее тщательно.
Я бы сказал, что, если аналитик не находится на встрече – значит он сидит и работает с документацией. Не поймите меня неправильно, это совсем не значит, что нужно просто глупо стучать по клавиатуре, наоборот — именно здесь приходится задействовать все возможности нашего интеллекта, именно эта часть является наиболее трудоемкой.
Вот всего лишь несколько примеров того, с чем приходится регулярно сталкиваться:
Для работы с документацией у каждого аналитика есть свой любимый инструментарий — кто-то любит рисовать диаграммы, а кто-то пишет полотно текста в Word. В любом случае я бы советовал вам ознакомиться с основами UML, BPMN, понятиями User Stories и Acceptance Criteria. Они наверняка повстречаются у каждого работодателя.
В большей мере, для команды именно аналитик — голос клиента. В любых непонятных ситуациях, именно к нему придут с вопросами «А что здесь имелось в виду?» и именно с ним будут подтверждать, того ли именно хотел заказчик.
Я всегда говорю, что бизнес-аналитики в ИТ играют роль своеобразного моста между разработчиками и бизнесом, умея одновременно говорить на языках клиентов и программистов. В повседневной работе нам предстоит совместно обсуждать требования, планировать и распределять задания, отвечать на текущие вопросы программистов.
Очень часто получается так, что бизнес-аналитик проводит много времени с каждым членом команды и играет своеобразную роль заместителя руководителя. В моей практике бывали даже такие случаи, когда руководитель приходил ко мне для обсуждения того, кому из коллег стоит давать премию, а кому — нет.
Очевидно, что, лучше всех понимая требования клиента, именно нам придется проверять результаты работы программистов.
От бизнес-аналитика ожидается выполнение так называемых User Acceptance Tests — тестов принятия пользователем. Никто не требует писать автоматизированные скрипты или проверять размеры и цвета кнопочек на сайте. Все, что требуется — представить себя пользователем и воспользоваться готовым продуктом. Проверить, не возникает ли каких-либо неудобств при его использовании, работает ли в общем система так, как хотел пользователь, нету ли явных ошибок или несоответствий требованиям.
Важный момент! Нужно помнить, что аналитики проводият все время с командой, участвуют в обсуждениях, знают о разных «хаках» и узких местах программы. В то же время, выполняя тесты, мы должны понимать, что клиент не обладает этими знаниями, он не знает, куда нужно нажимать, а куда — нет. Необходимо абсолютно непредвзято оценить систему и указать на все ошибки разработчикам — чем раньше удастся их выявить, тем проще будет исправить.
Говорят, чтобы успевать за всеми новыми технологиями в программировании, нужно чуть ли не каждый день изучать новые фреймворки, пробовать новые версии любимых языков и следить за лучшими практиками со всего мира.
К счастью, фундаментальные основы бизнес-анализа не меняются так часто. Однако, как я уже говорил в своей прошлой статье, для того чтобы выделяться из толпы бизнес-аналитиков, вам нужно быть как можно более всесторонне развитым специалистом.
Вам тоже необходимо следить за изменениями в ИТ, вам необходимо развивать свои мягкие навыки, учиться бизнес-управлению, основам финансов, разбираться в предметных областях клиентов и так далее. В общем, получается так, что времени на обучение вам часто будет требоваться еще больше, чем коллегам-программистам.
В заключение дам совет по саморазвитию — примите его необходимость и обсудите со своим руководителем. Для развития бизнеса критически важно не загонять себя в рамки устоявшихся процессов, ведь завтра появится новый клиент и новый проект из абсолютно другой сферы. Бизнес-аналитик должен уметь быстро освоиться в меняющейся среде и приготовиться к работе с новой предметной областью. Именно здесь вам на помощь придет все то время, которое вы провели, расширяя свой кругозор.
Обычно, после попытки ответить следует еще неизменный комментарий: «Эх ты, программист, даже холодильник починить не можешь». Что уж говорить про бизнес-аналитиков, которые и коллегам-то объяснить толком не могут, чем занимаются.
Я и сам часто слышу этот вопрос от своего отца, да все никак не могу найти правильный ответ. И правда, чем мы вообще занимаемся на работе — анализируем!
На что тратит время аналитик в ИТ
Специально для этой статьи мне пришлось основательно покопаться в архивах JIRA с трех последних мест работы. За абсолютную точность не ручаюсь (да, мне тоже не нравится расписывать все свои занятия до последней минуты), но общая картина действительно совпадает с собственными ощущениями от выполняемых обязанностей.
Примерное распределение работы можно описать так:
- Встречи — 20%
- Документация — 30%
- Работа с командой — 25%
- Тестирование — 5%
- Командировки — 5%
- Саморазвитие — 15%
А вот точное количество часов за последние 3 месяца:
Как видите, картина действительно похожая. Небольшие различия – отсутствие командировок и большее время работы с командой – возникают из-за недавней смены места работы и, соответственно, процесса интеграции в новую среду.
Теперь давайте рассмотрим каждый пункт подробнее.
Встречи
Начнем с самого главного — с того, чего, собственно, и начинается бизнес-анализ — с деловых встреч, куда отнесем и встречи с клиентами, и внутренние собрания с командой.
Прежде всего, это — анализ предметной области и сбор требований. Именно здесь мы узнаем, чего вообще от нас хочет клиент, какие у него есть проблемы, предлагаем первые идеи по реализации и вместе составляем предварительный план проекта.
Другие важные элементы встреч с клиентами — обсуждение выполненных работ, планирование изменений, презентации и тренинги, на которых мы рассказываем, как пользоваться предложенным продуктом.
Пожалуй, именно встречи являются основой нашей работы, именно они обеспечивают аналитиков и их команды дальнейшими заданиями, поэтому именно к ним стоит готовиться наиболее тщательно.
Работа с документацией
Я бы сказал, что, если аналитик не находится на встрече – значит он сидит и работает с документацией. Не поймите меня неправильно, это совсем не значит, что нужно просто глупо стучать по клавиатуре, наоборот — именно здесь приходится задействовать все возможности нашего интеллекта, именно эта часть является наиболее трудоемкой.
Вот всего лишь несколько примеров того, с чем приходится регулярно сталкиваться:
- Спецификация требований — превращение вольного полета мысли клиента в структурированный документ, четко описывающий, что необходимо сделать команде. Позже именно этот документ утверждается с клиентом и ложится в основу выполняемого проекта.
- Изменения требований (Change Request) — процесс, инициируемый клиентом в том случае, когда требуются изменения в продукте уже после начала разработки или даже после ее окончания. Документ описывает, какая часть системы и как должна быть модифицирована, содержит оценку выполнения работы по времени и стоимости.
- Инструкция пользователя и другие обучающие материалы — очевидно, что после окончания проекта, необходимо написать документацию для клиента, в которой будет описано, как пользоваться системой, даны советы и ответы на частые вопросы.
Для работы с документацией у каждого аналитика есть свой любимый инструментарий — кто-то любит рисовать диаграммы, а кто-то пишет полотно текста в Word. В любом случае я бы советовал вам ознакомиться с основами UML, BPMN, понятиями User Stories и Acceptance Criteria. Они наверняка повстречаются у каждого работодателя.
Работа с командой
В большей мере, для команды именно аналитик — голос клиента. В любых непонятных ситуациях, именно к нему придут с вопросами «А что здесь имелось в виду?» и именно с ним будут подтверждать, того ли именно хотел заказчик.
Я всегда говорю, что бизнес-аналитики в ИТ играют роль своеобразного моста между разработчиками и бизнесом, умея одновременно говорить на языках клиентов и программистов. В повседневной работе нам предстоит совместно обсуждать требования, планировать и распределять задания, отвечать на текущие вопросы программистов.
Очень часто получается так, что бизнес-аналитик проводит много времени с каждым членом команды и играет своеобразную роль заместителя руководителя. В моей практике бывали даже такие случаи, когда руководитель приходил ко мне для обсуждения того, кому из коллег стоит давать премию, а кому — нет.
Тестирование
Очевидно, что, лучше всех понимая требования клиента, именно нам придется проверять результаты работы программистов.
От бизнес-аналитика ожидается выполнение так называемых User Acceptance Tests — тестов принятия пользователем. Никто не требует писать автоматизированные скрипты или проверять размеры и цвета кнопочек на сайте. Все, что требуется — представить себя пользователем и воспользоваться готовым продуктом. Проверить, не возникает ли каких-либо неудобств при его использовании, работает ли в общем система так, как хотел пользователь, нету ли явных ошибок или несоответствий требованиям.
Важный момент! Нужно помнить, что аналитики проводият все время с командой, участвуют в обсуждениях, знают о разных «хаках» и узких местах программы. В то же время, выполняя тесты, мы должны понимать, что клиент не обладает этими знаниями, он не знает, куда нужно нажимать, а куда — нет. Необходимо абсолютно непредвзято оценить систему и указать на все ошибки разработчикам — чем раньше удастся их выявить, тем проще будет исправить.
Саморазвитие
Говорят, чтобы успевать за всеми новыми технологиями в программировании, нужно чуть ли не каждый день изучать новые фреймворки, пробовать новые версии любимых языков и следить за лучшими практиками со всего мира.
К счастью, фундаментальные основы бизнес-анализа не меняются так часто. Однако, как я уже говорил в своей прошлой статье, для того чтобы выделяться из толпы бизнес-аналитиков, вам нужно быть как можно более всесторонне развитым специалистом.
Вам тоже необходимо следить за изменениями в ИТ, вам необходимо развивать свои мягкие навыки, учиться бизнес-управлению, основам финансов, разбираться в предметных областях клиентов и так далее. В общем, получается так, что времени на обучение вам часто будет требоваться еще больше, чем коллегам-программистам.
В заключение дам совет по саморазвитию — примите его необходимость и обсудите со своим руководителем. Для развития бизнеса критически важно не загонять себя в рамки устоявшихся процессов, ведь завтра появится новый клиент и новый проект из абсолютно другой сферы. Бизнес-аналитик должен уметь быстро освоиться в меняющейся среде и приготовиться к работе с новой предметной областью. Именно здесь вам на помощь придет все то время, которое вы провели, расширяя свой кругозор.
