BA GIRL | Бизнес-аналитик в IT

2021-03-03 11:19:26 ​​Стандартный день бизнес-аналитика. Как выжить в митингах nonstops?
(43 секунды)

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

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

Значит пришло время начать работать со своим календарем и учиться time-management.

Несколько правил, которые использую я:

1. Строю свой календарь на две недели вперед:

• определяю регулярные общекомандные митинги и проверяю, что они на месте

• бронирую ежедневные два (N) часа для работы в рабочем графике и обед (помните, ни одна работа не стоит будущих болезней)

• определяю обязательные митинги с клиентом и создаю их заранее

• перед каждым обязательным митингом оставляю себе полчаса на подготовку и «сделать кофе»

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

• проверяю, что нет пересечений в обязательных митингах

• раскрашиваю свой календарь разными цветами в зависимости от категории митингов и задач

2. Очень важно, что время, которое я бронирую для работы — «тихое».

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

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

3. Все оставшееся время — оставляю для быстрых созвонов, неожиданных митингов, ответов на вопросы, письма и т.д.

Что делать, если вам поставили митинг на время, которое вы забронировали для работы?

• Во-первых, я стараюсь ставить все митинги сама, чтобы избегать таких случаев.

• Во-вторых, ориентируюсь на митинг, его срочность и приоритетность.

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


Какие вы правила используете, чтобы успевать работать? Буду рада услышать ваши идеи! Открыть/Комментировать

2021-02-24 11:54:23 ​​Гибкие методологии разработки и вовлеченность клиента. Почему иногда так хочется обратно в водопадную модель?
(25 секунд)

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

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

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

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

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

Хорошо ли это? Безусловно.

Есть лишь одна проблема: готов ли клиент с вами непрерывно коммуницировать? И ладно непрерывно, хотя бы достаточно часто?

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

Что тогда?

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

У вас есть лишь достаточно высокоуровневые User Story, большой список вопросов и надежда, что вы достаточно заложили в риски, чтобы не убить проект окончательно.

Что остается делать бизнес-аналитику в таком случае?

Полагаться на свою экспертность, искать аналоги, «ловить» заказчика, пробовать другие каналы коммуникации, детально прорабатывать подход к change requests, не смотря на гибкую разработку, и надеяться, что «в этот раз не промахнемся». И как говорят в аналитических кругах: «Тренировать спокойствие, смирение и принятие.»

Сталкивались с недоступностью стекхолдеров при гибких методологиях? Что делали в таких случаях? Открыть/Комментировать

2021-02-17 10:17:09 ​​Повторное использование требований. Правда или миф?
(23 секунды)

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

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

Я же хотела с Вами поделиться практической стороной медали.

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

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

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

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

Что думаете? Переиспользовали ли вы требования когда-нибудь? Открыть/Комментировать

2021-02-10 10:22:55 ​​Взаимодействие бизнес-аналитика и архитектора на проекте. В чем заключаются точки контакта?
(29 секунд)

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

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

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

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

Взаимодействие бизнес-аналитика с архитектором заключается не только в объяснении требований, но и в попытке понять, какие именно требования для заказчика наиболее приоритетны.

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

Бизнес-аналитик закладывает первый краеугольный камень в виде требований и скоупа.

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

Так должно быть в идеальном мире . На практике, конечно, бывает по-другому. Открыть/Комментировать

2021-02-01 12:28:14 ​​WBS. Как с ним связан бизнес-аналитик?
(28 секунд)

WBS (Work Breakdown Structure) — это разбиение проекта на конкретные результаты/работы, которые должны быть достигнуты/выполнены для достижения целей проекта.

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

Интересным фактом можно отметить то, что в зависимости от источника вы найдете разные определения того, что именно отражается в этом документе.

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

Но как же связан с документом, который составляет проектный менеджер, бизнес-аналитик?

Во-первых, при определенной опытности последнего, составление WBS может лечь и на плечи бизнес-аналитика.

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

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

Сталкивались ли вы с WBS на своих проектах? Открыть/Комментировать

2021-02-01 12:25:31 ​​Alarm!

На курс осталось всего 3 места для брони! И всё!

Кто не успел — тот потерял новые знания, навыки и возможность совершенствоваться

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

Успеть забронировать себе место можно здесь: Ссылка Открыть/Комментировать

2021-01-27 10:57:53 ​​Что такое пользовательская документация и зачем она нужна?
(38 секунд)

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

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

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

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

Подходы к разработке пользовательской документации:

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

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

3. Организация документации в виде алфавитного справочника.

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

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

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

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

Приходилось ли вам писать пользовательскую документацию? С какими сложностями сталкивались? Открыть/Комментировать

2021-01-21 09:01:00 ​​Старт первого потока: 15.02.2021

Дни и время занятий:

Понедельник: 19:30 — 21:30
Пятница: 19:30 — 21:30

Преподаватель на первый поток (я ):

• Практикующий Senior BA крупной международной компании

• С профильным высшим образованием (бакалавриат и магистратура) в бизнес-информатике крупнейшего технического ВУЗа России

• С опытом преподавания дисциплин бизнес-информатики в крупнейшем техническом ВУЗе России

• Точно знающий (и еще не забывший на собственном опыте), какие именно навыки нужны junior BA, чтобы победить в конкурентном мире в IT

Цена курса: 28 000₽
ТОЛЬКО ДЛЯ 1-ГО ПОТОКА СО СКИДКОЙ 25%: 21 000₽

Запись на курс: https://forms.gle/YaZsHVHmkaRUJQwv5

Буду рада помочь Вам сделать первые шаги на длинном карьерном пути бизнес-аналитика! Открыть/Комментировать

2021-01-21 09:00:30 ​​Онлайн-курс «Junior Business Analyst. Старт в профессии».

Сегодня я открываю набор на первый поток моего онлайн-курса для начинающих бизнес-аналитиков с нуля!

Всего 10 мест!

Кому подойдет:

• Тем, кто хочет сменить деятельность и начать карьеру бизнес-аналитика в IT.

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

Длительность курса: 2,5 месяца

• Лекционные и практические занятия ~24 часа (12 лекций).

• Онлайн QA сессии ~ 10 часов (5 сессий).

• Активное взаимодействие в рамках работы над домашними заданиями.

• Персональный игровой семинар «Интервью на работу мечты» в конце курса с полной эмитацией прохождения интервью в крупные международные IT компании ~1,5 часа.

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

Программа курса:

1. Основы процесса разработки ПО. Введение в IT: виды IT компаний и виды аналитиков. Жизненный цикл проекта. Принципы и виды моделей, методологий и фреймворков разработки ПО.

2. Основы бизнес-анализа. Взаимодействие на проекте, роли и зоны ответственности. Обязанности бизнес-аналитика на разных фазах проекта.

3. Работа бизнес-аналитика: Требование к ПО и классификации требований; Выявление и анализ требований; Валидация, верификация и приоритизация требований. Подходы к управлению требованиями.

4. Документирование требований: Use case, User Story, User Scenarios. Основные способы документирования требований: Спецификации, ТЗ и User Story. Моделирование: основные нотации и инструменты(BPMN, UML).

5. Техническая база (high-level overview): архитектура систем, базы данных (+ overview основ SQL), дата-модели (ERD, IDEF1X), back и front разработка, интеграция данных и приложений.

6. Прототипирование: основные понятия, цели и инструменты. Виды прототипов и их зоны применимости. Service Design.

7. Scrum и почему важно быть знатоком. Кто такой заказчик и все остальные?

8. Jira, Confluence и Outlook: демонстрация инструментов, цели использования, лайфхаки.

9. Soft Skills: самостоятельность, коммуникация в работе с заказчиком и девелопмент командой; решение конфликтных ситуаций.

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

Почему вам стоит выбрать этот курс?

• База для курса была разработанна с учетом необходимых ПРАКТИЧЕСКИХ знаний именно Junior BA без воды и «дополнительной» информации, которую вы забудете через 3 дня.

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

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

Правила курса:

1. «Не знать - не страшно; Страшно не хотеть знать и не спросить.» Я всегда буду рада вам помочь, но ваше желание и готовность интенсивно работать – основа всего.

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

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

3. Участие в имитации проектной деятельности — добровольное. Если у вас недостаточно времени, вы можете сразу отказаться от участия в проектной деятельности.

ВАЖНО: если вы согласились, но в дальнейшем не принимаете активное участие и не выполняете свою часть заданий, вы полностью исключаетесь с курса (с закрытием доступа к будущим урокам и всем материалам), так как подвели свою команду и не выполнили свои обязанности, а значит к ответственной роли BA — не готовы. Открыть/Комментировать

2021-01-19 10:23:55 BA GIRL | Бизнес-аналитик в IT pinned an audio file Открыть/Комментировать