Как бизнес-аналитику организовать эффективный рабочий день | DevsDay.ru

IT-блоги Как бизнес-аналитику организовать эффективный рабочий день

dou.ua 30 октября 2020 г. Kirill Belyavsky


Статья написана в соавторстве с Мэри Ротарь, CEO IAMPM.

Привет, меня зовут Кирилл Белявский, работаю бизнес-аналитиком в компании SoftServe и совмещаю это с должностью сервис-менеджера в офисе бизнес-анализа SoftServe.

Как ВА я работаю на проектах, чтобы клиенты получали лучший сервис в плане бизнес-анализа. А как сервис-менеджер компании делаю так, чтобы нашим аналитикам было комфортно, чтобы у них было все необходимое для работы и развития. Помимо этого, веду лекции на курсах, выступаю на митапах и конференциях, участвую в вебинарах. В свободное время с другом веду подкаст о бизнес-анализе As a User I want to see.

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

Рабочий день бизнес-аналитика

Рабочий день ВА проходит, как минимум, в трех измерениях

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

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

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

Как должны распределяться активности и как распределяются в действительности

Рабочий день ВА на 60% состоит из коммуникации: пообщаться несколько раз со всеми, ответить на письма, вопросы, поговорить с клиентом, командой, менеджерами. По 20% времени остается на документацию и анализ.

Рабочий день ВА — распределение активностей, каким оно должно быть

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

Рабочий день ВА — распределение активностей в реальности

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

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

Правила эффективного рабочего дня

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

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

1. Не обсуждайте требования только с одним членом команды

Когда идет разработка, требования, как правило, разбиваются на кусочки. В скраме это User Story. Над одной стори работают минимум два человека, например, разработчик и тестировщик, который будет проверять эту функциональность. Обычно их даже трое: тестировщик, бэкенд и фронтенд разработчики. Сначала к ВА придет один участник команды с вопросами по текущей story, потом другой будет задавать свои вопросы, а потом придет и третий. Затем участники начнут разбираться между собой, у них не сойдутся показания, они снова придут к ВА — в итоге коммуникация займет массу времени.

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

На удаленке мы создаем под каждую story в спринте отдельный чат в Teams либо в Slack и добавляем людей, которые будут работать над ней. Дальше коммуникация идет в одном канале по одному вопросу. Участники чата видят вопросы и ответы ВА, информация не теряется, а время экономится. В спринте много stories, но специалистов меньше, чем stories, поэтому они группируются — поработали над одной, пошли на другую.

Даже до удаленки, когда все работали в одном помещении и ко мне подходили по поводу story, я говорил: «Приведи остальных, кто работает над этой story, тогда пообщаемся».

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

2. Готовьте повестку с тайм-кодом для совещания

Не просто продумывайте agenda, а записывайте и придерживайтесь запланированной повестки. Это очевидный совет, тем не менее, на практике я часто вижу, что ВА не делают повестку и тайм-код совещания.

Тайм-кодом я называю распределение времени на каждый пункт. Например, при часовом совещании 15 минут пойдет на первый вопрос, 10 минут — на второй, 20 — на третий и так далее в зависимости от сложности вопроса.

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

Предварительная agenda и тайм-код сильно экономят время, но почему-то не все ими пользуются.

3. Избегайте совещаний, которые могли быть email’ом

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

Чтобы понять, нужно ли ваше присутствие, спросите себя:

  1. Создам ли я какую-то ценность для остальных участников встречи?
  2. Создаст ли эта встреча какую-то ценность для меня?

Если на оба вопроса отвечаете «нет», значит, на этот митинг идти не надо.

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

Можно отказываться напрямую: «Понимаю, что это важно, но сейчас нет времени. Пожалуйста, напишите минутки (протокол) совещания в конце встречи, я позже прочитаю».

4. Избегайте мультизадачности

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

Для выполнения задач мне нравится использовать метод pomodoro. Идея в том, чтобы фокусироваться на какой-то задаче 20-30 минут, не отвлекаясь на другие факторы (сообщения, звонки и прочее). 30 минут — небольшой отрезок, и ничего не случится, если моментально не ответить на сообщение в мессенджере.

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

5. Создавайте артефакты, которые можно использовать повторно

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

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

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

На своих проектах я стремлюсь создавать reusable requirements, то есть требования, которые можно применить повторно. Идея похожа на дизайн-системы, которые используют дизайнеры.

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

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

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

6. Добивайтесь фидбэка

Часто возникает ситуация, когда люди что-то не поняли и сделали не так, и ВА говорит: «Но я же написал email/в чат/в confluence» или «Я же указал информацию в требованиях».

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

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

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

Итог

Если коротко подытожить правила одним списком:

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

Источник: dou.ua


Читайте также


User Acceptance Testing: как менеджеру организовать процесс

Разработка dou.ua 12 мая 2020 г. 13:00
Представим себе, что вы ведете проект по разработке программного продукта и уже подошли к этапу, когда минимальный скоуп завершен, релиз-кандидат стабилизирован и настало время релиза. На этом этапе необходим дополнительный шаг, на котором вы еще раз...... читать далее

Эпизод #4. Роли и задачи в IT проекте. А зачем все эти роли (TeamLead, Project manager, Product Owner, etc.)?

Разработка Блог компании ITQuick 28 апреля 2020 г. 17:23
Роли и задачи в IT проекте. А зачем все эти роли (TeamLead, Project Manager, Product Owner, etc.)? Бывает, что Заказчик боится большого количества ролей. Возникает вопрос, действительно ли нужны все эти роли, которые мы описываем на этапе обсуждения...... читать далее
IT software Videoblog Блог IT бизнес

Разработка dou.ua 16 апреля 2020 г. 13:04

Дистанционная работа — тренд последнего месяца (и, скорее всего, следующего тоже). Теперь не только IT, но и другие бизнесы имеют дело с распределенными командами — сотрудниками, каждый из которых работает из своего дома/локации. Я же начала работать...... читать далее

Разработка dou.ua 24 января 2020 г. 10:00

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

Разработка techrocks.ru 21 января 2020 г. 18:00

Виктор Ведмич, System Engineering Team Leader, EPAM, в своей статье на tproger.ru рассказал о принципах и подходах, которыми руководствуется он и его коллеги в процессе разработки. До сих пор бытует представление, что DevOps — это такой продвинутый с...... читать далее

Работа primary

DevOps OpenNET 28 ноября 2020 г. 23:58

Опубликован релиз Proxmox Virtual Environment 6.3, специализированного Linux-дистрибутива на базе Debian GNU/Linux, нацеленного на развертывание и обслуживание виртуальных серверов с использованием LXC и KVM, и способного выступить в роли замены таки...... читать далее

DevOps OpenNET 28 ноября 2020 г. 20:41

Хуан Ромеро Пардинес (Juan Romero Pardines), основатель Void Linux, который в апреле со скандалом покинул проект и изменил лицензию на своё ответвление пакетного менеджера XBPS, отменил прежние ограничения и вернул коду в своём репозитории изначальну...... читать далее

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

ux (318) новости (302) design (278) новость (198) web dev (181) javascript (179) devops (176) ux-design (176) ubuntu (175) security (172) python (151) headline (144) seo (126) tutorial (120) ui (113) статьи (106) user-experience (99) testing roundup (85) programming (83) software testing (82) игровые проекты (77) java (76) api5 (76) product-design (75) дизайн (75) дайджесты вакансий от new.hr (73) design-thinking (70) google (68) primary (67) laravel (65) ui-design (64) working in tech (63) прочее (60) технологии (60) windows 10 (59) hardware (54) uncategorized (53) español (51) бизнес (50) мероприятия (50) движки и конструкторы игр (49) css (48) обучение (48) турбо-страницы (47) technology (47) работа (46) web design and applications (45) covid-19 (45) docker (44) android (44) case-study (44) навыки алисы (43) debian (42) publication (41) инструкции (40) cloud (39) angular (39) inspiration (38) machine learning (38) home page stories (38) chrome (38) wp (38) networking (37) ux-research (37) art (37) тестирование (36) kali linux (36) полезное (36) aspnet (36) web (36) vue.js (36) кейсы (35) обзоры (35) events (35) .net (35) arch linux (34) powershell (34) google ads (34) data (34) tutorials (33) навыки (33) wordpress (33) dotnet (32) linux mint (31) kubernetes (31) события (31) api (31) windows (31) marketing (31) apple (31) алиса (31) автоматизация (31) job hunting (30) bash programming (30) интервью с экспертами (30) creativity (29) ios (29) user-research (28) без рубрики (28) разработчики (28)