Bus-фактор в работе аналитика. Как экстренно погрузиться в проект и не перегореть от объема задач

Привет! Меня зовут Екатерина Герт. Вот уже больше 10 лет я работаю системным аналитиком в проектах по заказной разработке ПО для компаний из разных отраслей и госсектора. Это всегда работа над большими проектами. 

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

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

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

Поехали! 

---

Предыстория

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

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

Команда аналитиков, когда я в нее попала, состояла из четырех человек:

1. Ведущего аналитика проекта;

2. Двух ведущих аналитиков на разработке требований. Один из двух — это я;

3. Одного младшего аналитика, которая работала в паре с ведущим аналитиком над тремя проектами.

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

Началось. Bus-фактор сработал

Однажды на проекте сработал Bus-фактор или «фактор автобуса».

Bus-фактор — то количество людей в команде проекта, внезапное исчезновение которых приведет к закрытию проекта. Этих людей можно еще назвать «герои» проекта. В их руках сосредоточена информация о работе ключевых функций, в которой на проекте больше никто не разбирается. Эти герои могут хорошо разбираться в запутанном и сложном коде, владеть знаниями о предметной области, в которых сложно разобраться другим или это потребует больших затрат времени. Чем больше таких героев в проекте, тем выше bus-фактор и тем ниже устойчивость проектной команды.

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

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

Хорошая новость заключалась в том, что основная часть работ по аналитике была закрыта — требования описаны и согласованы с заказчиком. Но была и плохая новость — это были далеко не все работы, которые обычно делает аналитик в команде. 

При активной фазе разработки и тестирования аналитику нужно быть на связи и отвечать на вопросы коллег. Кроме того, для подготовки к приемочным испытаниям нужно провести «бизнес-тестирование»: аналитик должен проверить, соответствует ли, с точки зрения обычного пользователя,  реализованная функциональность той, что описана в требованиях. Аналитик также отвечает за подготовку целого комплекта документов — руководство пользователя, краткие инструкции для работы пользователей с разными функциональными ролями в системе — и описывает детали реализации требований для команды.

В итоге встал большой вопрос: кто примет на себя все эти активности?

Кто примет на себя новые проекты? Сложное решение и борьба с выгоранием

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

Вариантов было не так много:

1. Привлечь нового человека взамен тех, что покинули команду;

2. Привлечь ведущего аналитика проекта;

3. Привлечь меня.

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

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

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

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

Но со мной тоже был нюанс. К тому моменту я работала на проектах для этого заказчика уже три года и тоже решила, что хочу развиваться дальше, а в этой команде своего потолка достигла. Мы обсудили все с менеджерами, ресурсным менеджером и ведущим аналитиком проекта, стартовали мой процесс постепенного выхода из проектной команды — и в этот момент, когда я практически стояла у «выхода», как раз сработал bus-фактор. 

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

Почему я не согласилась сразу?

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

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

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

А я все никак не могла согласиться. Было много разных факторов как «за», так и «против». Тут я вспомнила про квадрат Декарта, о котором недавно узнала на курсе по тим-лидерству, и решила его применить для решения этой непростой задачи.

Квадрат Декарта позволяет оценить плюсы и минусы какой-то идеи по четырем направлениям:

1. Что я получу, если сделаю «это»;

2. Что я получу, если НЕ сделаю «это»;

3. Что НЕ получу, если сделаю «это»;

4. Что я НЕ получу, если НЕ сделаю «это».

Получается четыре сектора. В каждый нужно вписать то, что произойдет, если реализовать или не реализовать какую-то задачу, решение или идею. Дальше для каждого пункта в каждом секторе нужно проставить веса — насколько этот пункт лично для вас значим. Например, по пятибалльной шкале. В области «получу», эти балы с «+», а в области «Не получу» с «-». Складываем цифры в каждой половине «Сделаю» и «Не сделаю», получаем вес — «за» и «против» решения.

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

Взвесив все плюсы и минусы, стало понятно. Решаюсь!

От лирики к практике: как пережить шторм и сдать все проекты вовремя

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

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

Все зависит от вас, вашей ситуации и условий, в которых вам надо работать.

Как быстро погрузиться в новые активности?

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

Получи максимум информации о проекте

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

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

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

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

Визуализируй для быстрого погружения

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

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

Это важный момент в контексте работы с несколькими проектами одновременно. Если обсуждать их по очереди, единой картины не будет. Мозг старательно будет все упрощать. Важно любым удобным для вас способом свести все кусочки в одном пространстве. Для меня это была визуализация на флипчарте. Для вас это может быть mind-map, доска в miro, или что-то еще.

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

Так вместе с менеджером мы наметили план работы, сроки и ресурсы. Тут тоже пригодился мой флипчарт. Он дал нам основу для планирования. Ну а дальше началось самое интересное — быстрое погружение в требования.

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

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

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

Плюсы в использовании визуализации:

1. Требует немного времени;

2. Хорошо запоминается благодаря связи текста с визуальным образом;

3. Можно обсуждать с коллегами на встречах;

4. Снимает стресс.

Есть и минус:

1. Визуальные заметки не являются самостоятельным рабочим артефактом. Их нельзя переслать коллеге для самостоятельного изучения.

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

1. План работы с ключевыми задачами и датами;

2. Представление об ожиданиях заказчика и требованиях, которые это ожидание должны реализовать.

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

Теперь начинается следующий не менее интересный этап — «работа над задачами по плану».

Как сохранить work-life balance в водовороте проектных задач?

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

Вот тут мне очень вовремя попала в руки книга Максима Дорофеева «Джедайские техники». Я решила, что настал лучший момент начать вести списки задач.

Составляй списки

Не сразу, но в итоге я пришла к доске в Trello из четырех колонок:

1. «Надо сделать» — для общего списка задач. Туда я записываю все задачи, какие у меня есть, потом сортирую их в том порядке, в котором планирую их сделать относительно друг друга.

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

3. «Сделать сегодня» — это мой план работы на день.

4. «Сделано» — сделанные за день задачи. Приятно смотреть на то, как этот список растет. Видно, что день прошел не зря.

Фильтруй задачи

Перед тем, как записывать задачи в Trello в списки, я мысленно пропускаю их через три фильтра в своей голове: 

Фильтр №1. «Это можно сделать за 5 минут?»

Если вопрос или задача займут не больше 5 минут, то беру и делаю тут же, никуда не записываю. Чтобы ответить на вопрос или выполнить задачу нужно больше 5 минут? Записываю в список «Надо сделать».

Фильтр №2. «Это можно делегировать?»

Если выполнение задачи можно делегировать кому-то еще, то записываю ее в список «Сделать сегодня»: поставить задачу <какую> <кому>. После постановки задачи, я создаю еще одну в списке «На контроле», чтобы проверить исполнение.

Фильтр №3. «Это можно не делать?»

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

В итоге получается список задач для работы на день — «Сделать сегодня». 

Записывай все дела

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

Записывала так:

1. В начале краткое обозначение проекта, т.к. их у меня в работе было несколько. Например, «ЭП» — для проекта с электронной подписью.

2. Дальше краткая формулировка задачи в стиле «Что надо сделать». Например, «Дополнить раздел 7 ТЗ списком кратких инструкций». В 7 разделе были требования к документированию.

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

Давай себе время выдохнуть

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

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

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

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

Проекты сдали — делаем выводы

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

Мы сделали выводы и внесли изменения в работу:

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

2. Больше общались и обсуждали наши планы: проектные и на личное развитие, чтобы дать больше возможностей развиваться внутри команды.

3. Укрепили команду аналитиков новыми аналитиками.

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

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

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

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

Автор: Екатерина Герт

Источник