Возьмем среднестатистический IT проект, на котором есть несколько разработчиков, QA-инженер, менеджер проектов и аналитик. Разработчики пишут код. QA-инженер обеспечивает качество. Менеджер контролирует работы по проекту. А аналитик. что-то анализирует?
Ну, примерно. Мы попросили аналитиков CSSSR рассказать о своей профессии и задачах, чтобы всё, наконец, встало на свои места.
Зачем нужен аналитик в IT
Аналитик занимается переводом с языка бизнеса на технический и наоборот. Проще говоря, это человек, превращающий «хотелку» в конкретную задачу. Так, если бизнес хочет поэкспериментировать с анализом моделей причинно-следственных связей, аналитик сформулирует это желание в функциональные требования, т.е. задачи на разработку таблиц для хранения элементов, методов редактирования и форм просмотра.
В целом процесс выглядит следующим образом:
Аналитик собирает бизнес-требования заказчика. Если это бизнес-требования, то они потребуют согласования через тернистый путь правок. После того, как требования собраны, аналитик переводит бизнес-требования в функциональные, т.е. набор конкретных изменений в системе, отвечает на возникающие вопросы разработчиков и QA-инженеров.
5 примеров рабочих задач бизнес-аналитика
После реализации он может подключаться к бизнес-тестированию и сдачи системы заказчику. Аналитик также может анализировать последствия введения нового функционала. Наконец, аналитик помогает менеджеру проекта и продакт оунеру вести бэклог продукта: расставлять приоритеты и управлять рисками.
Виды аналитики
Системный аналитик
Задача системного аналитика — анализ предметной области и формулирование требований к системам. Требования, которые чаще всего звучат довольно размыто, тщательно анализируются, переводятся на технический язык и на выходе превращаются в конкретные задачи для команды разработки.
Пример: заказчик просит добавить два дополнительных поля в отчет. На первый взгляд кажется, что задача готова к передаче в разработку, однако таких полей нет в базе данных. Системный аналитик должен выяснить, откуда брать данные для новых полей и в каком формате они должны будут выводиться, и описать все необходимые доработки в системе.
Постановка задач требует технических знаний и понимания процессов. Неудивительно, что в эту профессию чаще всего приходят люди с бэкграундом разработки, техподдержки или тестирования.
Бизнес-аналитик
Бизнес-аналитик работает в связке с заказчиком и занимается улучшением бизнеса, используя IT-методы (но не ограничиваясь ими). Основная деятельность: анализ предметной области и перевод размытых целей бизнеса в формализованные бизнес-требования.
Бизнес-аналитик решает задачи на более высоком уровне абстракции, нежели системный аналитик. Он конвертирует в задачи на разработку глобальные цели бизнеса, а не «хотелки» отдельных заказчиков.
Пример: процесс производства изделия — от поставки сырья до конечного продукта — контролируется программным обеспечением. Главный технолог хотел бы получать детальную информацию о потерях сырья в ходе производства. Бизнес-аналитик может предложить маркировать каждое изделие штрих-кодом, взвешивать готовый продукт и передавать данные в систему.
Алексей — Бизнес-аналитик (+ пример разбора проблемы) #интервью со спецом
На эту роль чаще всего приходят люди с пониманием того, как работает бизнес.
Продуктовый аналитик
Продуктовый аналитик (он же ПА) занимается анализом использования продукта его пользователями. Он работает с пользовательскими метриками, выявляет причины различных явлений — оттока, возврата, эффекта от внедрения фич. А также придумывает А/Б тесты, воронки, ставит эксперименты и собирает предпосылки для формирования новых требований к системе, при этом не принимая участия в их разработке.
Продуктовые аналитики часто сталкиваются с анализом big data. Иногда data scientist и ПА — один и тот же человек, работающий с массивом данных компании, выгруженном в отдельное хранилище. Так или иначе, он находится на стыке бизнес-анализа и разработки, потому как хорошо понимает предметную область и разбирается в методах анализа данных.
Пример: владелец интернет-магазина хочет увеличить количество заказов. Продуктовый аналитик выясняет, что покупатели часто бросают оформление покупки на полпути. Почему? Потому что, чтобы сделать заказ, нужно заполнить множество полей в форме и подтвердить согласие с политикой конфиденциальности.
Возможно, форма заказа должна быть упрощена, или стоит добавить покупку «в один клик», как у конкурентов. Аналитик проверяет гипотезы, готовит требования к доработкам и анализирует влияние нововведений на количество заказов в магазине.
Наш опыт
Необходимость в аналитике и аналитиках назревает, когда компания достигает определенного уровня зрелости: стартуют долгоиграющие проекты, либо начинается работа в сложной предметной области. В какой-то момент у CSSSR появилось желание и возможность браться за большие проекты с бэкендом.
Раньше мы работали с аналитиками со стороны клиента, и это сказывалось на скорости разработки: результаты анализа, которые были нужны здесь и сейчас, иногда задерживались, замедляя весь процесс работы. CSSSR решила нарастить мощность, наняв в штат собственных аналитиков — это позволило команде разработки получать ответы практически мгновенно, что значительно ускорило процесс принятия решений и разработки. Стало проще и заказчикам — теперь в команде есть человек, который все объяснит на понятном бизнесу языке. Стало легче тестировать и поддерживать уже готовые решения, так как они были задокументированы не только со стороны разработки, но и со стороны бизнес-целей и задач продукта.
Советы о документации для начинающих руководителей проекта
Когда документация не нужна
Редкие случаи, когда документация не нужна:
- вы планируете закончить проект за месяц;
- команда проекта состоит из одного разработчика, с которым вы находитесь в тесном контакте.
Во всех остальных случаях документация нужна на каждом проекте.
Для заказчика это вопрос финансов. Продукт с документацией легче и дешевле поддерживать, продавать, отдавать на доработку или поддержку другому подрядчику.
Менеджеру проекта документация обеспечивает душевное спокойствие: при смене разработчика или целой команды возникает куда меньше проблем.
Разработчика документация освобождает от необходимости объяснять клиенту и менеджеру, что он делает и почему.
QA-инженерам документация необходима для подготовки тест-кейсов и понимания бизнес-требований, помогая обеспечивать более качественный подход к тестированию.
Наконец, самому аналитику документация позволяет быстро найти ответ на вопрос клиента, разработчика или другого члена команды, особенно когда проектов много. Нет смысла держать всё в голове.
Как составить документацию
Пишите так, словно вы объясняете сложные вещи пятилетнему ребенку
Учтите, что этот ребенок будет задавать по три уточняющих вопроса на каждое утверждение, при этом он не знает матчасти.
Выбирайте самый простой язык повествования
Без деепричастных оборотов и сложноподчиненных предложений. Никто не даст вам гарантии, что через месяц вам не придется вспоминать, что вы хотели сказать этой красивой словесной конструкцией. Пишите лаконично и по делу.
Используйте сокращения с умом
Если человек впервые на проекте, или еще интереснее — впервые в предметной области, то ему сложно понять что таится за этими короткими словами. Место сэкономлено, а смысл не понятен. Если используете сокращения, то не забывайте добавлять их в глоссарий (-справочник проекта).
Используйте ссылки на требования
При написании кода мы стараемся переиспользовать уже реализованные на функции — функция перевода времени пишется один раз и повторно используется в остальных участках кода. То же самое и в документации: если требование зафиксировано в одном месте, то во всей остальной документации нужно дать на него ссылку. Это избавляет от необходимости вносить правки в каждую страницу при малейшем изменении требований.
Задавайте вопросы
Ответ на вопрос «зачем вам это нужно» может изменить весь подход к реализации требований. Например, заказчик считает, что ему нужно выгружать отчеты в Excel. После вопроса «зачем вам это нужно», оказывается что заказчик хочет ежедневно сравнивать показатели. Выходит, что Excel — это не главное, ведь на самом деле заказчику нужен удобный инструмент для сверки данных, который в реализации может оказаться проще и изящнее, чем обычная выгрузка отчетов в Excel.
Как управлять изменениями и правками
Придется принять тот факт, что изменения в проект будут вноситься постоянно, поэтому вам заранее стоит обдумать процессы управления изменениями. Самый простой вариант укладывается в четыре шага:
- зафиксировать изменения в реестре (или в Jira, или в книге учета изменений), указав автора предлагаемого изменения и дату получения изменения;
- провести предварительный анализ изменений и назначить им приоритет;
- принять решение — правим, не правим, или правим, но позже;
- запланировать работу по изменениям по стандартным процессам: проектируем, реализуем, тестируем, выкатываем.
Чаще всего изменения на проектах начинаются с четвертого пункта — это вводит некоторый беспорядок в проект. В менее запущенных случаях всё-таки заводится таска в Jira.
Реестр изменений позволяет не только избавиться от необходимости держать в голове хотелки, правки и планы на будущее, но и находить слабые места в процессе разработки.
Бывает, что колоссальное количество правок по уже реализованному функционалу приходит от человека, который не был обозначен как главный контакт со стороны заказчика в части проработки требований. Скорее всего, вы пропустили еще одно заинтересованное лицо, мнение которого обязательно стоит учитывать при написании и согласовании требований. Поговорите с заказчиком: возможно, стоит подключать этого человека как можно раньше — например, на этапе проработки требований.
Реестр изменений позволяет контролировать поток правок и запросов на дополнительный функционал со стороны заказчика — он наглядно показывает, сколько времени (а значит, и денег) потребуется на реализацию всех идей. А также позволяет приоритезировать доработки.
Ежемесячная рассылка CSSSR
Новости, свежие статьи и многое другое
Источник: blog.csssr.com
Как попасть в IT – пример бизнес-аналитика
В предыдущих статьях я уже начал рассказывать о нюансах работы бизнес-аналитика. Сейчас же хочу поделиться мыслями о том, как стать BA — какие навыки важны, где учиться и как сменить специализацию. Данная статья будет полезна людям, которые хотят получить позицию Business analyst / Product owner, будь то новички в мире ИТ или же специалисты других направлений, такие как разработка или тестирование.
Есть ли смысл идти на платные курсы?
Ко мне обратился один из знакомых с просьбой помочь ему с подготовкой к собеседованию на позицию бизнес-аналитик. Конечно же, я ему помог, чем смог, и в то же время немного углубился в образовательную сферу на рынке Украины и пришел к выводу, что нет бесплатной базы для того, чтобы стать бизнес-аналитиком. Если проанализируете нынешний рынок, поймете, о чем я говорю: много курсов от «специалистов», которые никогда не проходили на практике то, чему они учат.
Основной вывод: каждый трактует работу, как он хочет, оперирует высокоуровневыми терминами и понятиями. Те, кто хоть немного понимает в IT, продают знания от $300/курс и выше. Вот вам один из примеров. Стоимость за 3 дня — 1000 евро с тренером, который никогда не работал как БА/PО.
Да, эти люди могут быть классными спикерами, тренерами, но зачастую не специалисты в своих сферах. Потому что они не делают эту работу изо дня в день! Их задача — учить и рассказывать, а не внедрять, разрабатывать, вести переговоры. Решать вам, куда потратить эти деньги 😉
С чего начать и что делать?
У вас должна быть цель, к которой вы будете идти. У кого-то это всеобщее признание и $1000 на счету или покупка квартиры. Если нет цели, вы не будете знать, куда идти, соответственно, не сможете составить план действий, чтобы достичь ее.
Изучайте английский. Если вы хотите расти как личность и профессионал, то без языка вам будет очень тяжело, я бы сказал практически нереально. Вы всегда будете отставать от тех, кто его знает.
Может быть, он не пригодится вам в рабочем процессе, в чем я сомневаюсь, но развиваться без знания языка будет очень трудно. Сейчас большая часть качественной литературы именно на английском, потому что за рубежом ребята чуть проактивней и продвинутей, чем на просторах СНГ.
Много работайте. Если будете тратить на работу и развитие 8 часов в день, то вы станете крутым специалистом через 5 лет (если станете)! А те, кто будут тратить по ~12 часов в сутки, станут таким же за 3 года. Главное — быть увлеченным тем, что делаешь! Старайтесь углубляться как можно больше в каждый вопрос, на который вы ищите ответ.
Может, не самый главный, но очень важный совет — найти поддержку. В идеале — близкий человек, друг, родственник. В моем случае это были мотивационные ролики и один очень близкий друг. Банально, но 1 видео с утра как-то придавало мне больше сил и заряжало на успех (вот пример). Тут можете найти больше.
Кто есть кто?
Как я уже говорил, на украинском рынке понятия очень смазанные. Давайте посмотрим на официальные описания ролей в проекте и сравним их с реальностью.
Дата-аналитик — это человек, который работает с большим объемом информации. Основная обязанность заключается в том, чтобы извлечь нужные данные и проанализировать их для дальнейших решений. То есть этот специалист решает 3 основные задачи: сбор и анализ данных, а также разработка бизнес-решений на основе полученной информации. (wiki)
Бизнес-аналитик в принципе может не иметь отношения к IT-индустрии. Этот человек анализирует организацию или бизнес-домен (реальный или гипотетический) и описывает бизнес или процессы, системы, оценивая бизнес-модель или ее интеграцию с технологиями. (wiki)
То есть классический бизнес-анализ — это реинжиниринг процессов. Например, если компания хочет изменить организационную структуру: из 1 департамента сделать 5.
Системный аналитик — является мостом между бизнес-проблемами и технологическими решениями. Это человек, который специализируется на анализе, разработке и внедрении информационных систем.
Requirements manager — вы также можете встретить на украинском рынке эту позицию, нечасто, но все же. Определения такой профессии в принципе нет, но есть понятие Requirements management. Это процесс того, как должен документироваться бэклог, анализироваться, отслеживаться и т. д.
Имеем процесс, но не имеем как таковой позиции. Это то, что было придумано исключительно на нашем рынке. Зачастую это означает смесь системного аналитика и product owner.
Product owner — связующее звено между заказчиком и командой. Главная его задача — создать и контролировать backlog. (источник)
Product manager — специалист, который работает с продуктом, исследует рынок, анализирует финансовую часть. Фактически этот человек выступает CEO продукта. (wiki)
Наша главная проблема — симбиоз, когда на 1 специалиста вешают задачи совсем других направлений. Но невозможно быть профи сразу в 10 областях.
Однако неопределенность — это реалии украинского рынка в мире IT. Здесь нет четких различий между специалистами. Границы очень размыты. В одной компании от вас требуют одни скиллы, в другой — совершенно иные. Если вы планируете работать на украинском рынке, то будьте готовы к тому, что ваши задачи не ограничатся только обязанностями бизнес-аналитика.
Как начать?
Используйте разные информационные ресурсы для изучения. Для начала важно получить базу и узнать основные понятия IT. Вот несколько источников, которые мне помогли:
- Modern.analyst.com
- Artofba.com
- Telegram chat: Business Analysis Magazine_chat
- Telegram chat: UA BA Community Chat
- Telegram chat: Анализ Систем
- Facebook group: IT Network — Business Analysis http://gs-studio.com/news-about-it/32828—-it—-» target=»_blank»]gs-studio.com[/mask_link]