Что такое bus фактор
Bus Factor или как понять, что проект в опасности
Тут с удивлением узнала, что не всем знакомо понятие бас-фактора в области управления проектами, хотя это один из самых базовых элементов проверки «здоровья» проекта.
Задайте себе простой вопрос – если завтра кого-то из участников проекта или заинтересованных лиц собьет автобус – проект пострадает? Насколько сильно? Есть ли хоть один человек, который, попав под автобус, обеспечит провал проекта? Если под автобус попадет ведущий разработчик – проект встанет? А если спонсор – проект закроют?
Это простой и примитивный тест за пару секунд позволяет понять, есть ли у вас в команде «незаменимые» люди. Если есть – поздравляю, у вас проблемы. Самое время подумать о бэкапе, передаче знаний, документировании и прочих методах снижения риска того, что завтра с этим человеком что-нибудь случится (возможно, даже позитивное, типа приглашения на работу в Гугл), и вам, как руководителю проекта, придется расписаться в профессиональном провале.
Пример из моей практики – позвонила ведущий бизнес-аналитик (очень симпатичная девушка), на которой были завязаны все процессы взаимодействия с бизнесом и разработчиками, и сообщила, что парень позвал ее жить к себе на Бали, и через 3 дня она улетает. Подрядчик, у которого мы покупали ее услуги, разводил руками, грустил и обещал даже не брать денег за передачу знаний (еще бы). Успеху проекта это явно не поспособствовало.
А еще давайте вернемся к любимому примеру с ремонтом (в этот раз это даже не фантазия, а очень конкретный пример из ремонта в моей квартире пару лет назад). Во время ремонта я поленилась вникать в некоторые мелочи, доверив их хорошо знакомому прорабу. Прораб сделал все отлично, денег взял немного (знакомый же), работу сдал. А потом уехал обратно в свою солнечную Молдавию, купил там 2 автобуса, сделал свой маленький туристический бизнес, выбросил российский телефон и удалил аккаунт почты. А еще через 2 года на заложенном плиткой стояке канализации в ванной комнате произошла разгерметизация (прораб все еще молодец, вина исключительно на управляющей компании). И так как с единственным человеком, знавшим, как в стене установлены металлические направляющие, произошел bus factor в прямом смысле (пусть даже не в ходе проекта, а в ходе использования его результатов), а никакой документации или кого-то, кто мог его заменить, не осталось – мы вместе с сантехником задумчиво разбили половину плитки в ванной, уничтожив половину ремонта, пока сделали достаточное окно для доступа к стояку. А могли двумя разбитыми плитками обойтись… Тут даже морали не надо, все и так понятно.
Кросс-функциональность, Т-люди и Автобусный фактор
За последние полгода мне удалось побывать на двух стартап-конкурсах — DOU Mixer и Garage48. В первом команда формировалась “на лету”, что внесло определенную избыточность и путаницу ролей. Поэтому, во втором мы решили участвовать укомплектованным еще до его начала составом.
Скажу сразу, работать с командами клиентов и собирать свою команду — не одно и тоже. Есть свои преимущества и недостатки, но так же, есть общие практики, которые будут полезны как аджайл-коучам, так и технологическим предпринимателям.
Хочу поделиться парой инструментов, которые помогут быстро понять кто есть кто в команде и сэкономить время некоторых командо-образующих процессов.
Итак, предположим, что у нас есть группа людей (5-7 человек), которой предстоит работать вместе над проектом. С чего начать сборку? Начнем со знакомства…
Шаг 2. Представление
Предлагаем каждому члену команды (по кругу) представиться, если они еще не знакомы, озвучить свои сильные стороны и свои интересы в профессиональном росте. Это может занять по 1-3 минуты на человека, в целом на команду — до получаса.
Следующей командной активностью я бы предложила сделать формирование матрицы навыков. Его целью так же будет исследование навыков и знаний, но не для общего знакомства, а уже для анализа состава и уровня кросс-функциональности команды. Небольшое отступление на тему кросс-функциональности.
Часто она понимается неверно, как будто предлагается использовать фронт-энд девелопера для проектирования архитектуры базы данных, а дизайнера для написания тест-кейсов.
На самом деле речь идет о командной кросс-функциональности, а не об индивидуальной. То есть, под кросс-функциональностью мы понимаем способность целой команды выполнить все функции, необходимые для реализации проекта.
Олдскульный командный коуч во мне всегда предлагает максимально сконцентрировать навыки и знания команды в одной точке, буквально — в одной комнате. В мире распределенных проектов, это все менее возможно, но если бы я строила сейчас свою команду, я бы пренебрегла экономией офисных и зарплатных расходов в пользу высокой продуктивности, которую могут развить люди, работающие вместе, в общей временной зоне, стране, культуре и физическом пространстве.
Другой важный аспект высокой продуктивности — наличие, или даже подавляющее большинство Т-людей в команде. Здесь речь идет уже об индивидуальной кросс-функциональности, и вот что я под ней понимаю.
Специалист Т-формы получил такое название потому, что имеет глубокое (как основание буквы T) понимание одной дисциплины/домена и широкие (как шапка буквы T) интересы в других смежных областях.
Нам нужна команда-звезда, а не команда звезд, поэтому, полезно растить Т-людей и соблюдать баланс командной и индивидуальной кросс-функциональности.
Первым шагом на этом пути может стать воркшоп по созданию матрицы навыков.
Руководствуясь питчем и спецификацией, выпишите навыки и технологии, которыми должна обладать команда. Вы можете их писать вначале на стикерах, или сразу — на флипчарте, в зависимости от того, насколько вы свободны в обсуждении и выборе технологий.
Флипчартный лист мы расчерчиваем матрицей, в колонках которой будут технологии и навыки, а в строках — имена людей.
Коллеги из олдскульного проджект менеджмента, предлагаю сразу перестать называть людей ресурсами. Люди это люди. В строках у нас будут имена, фамилии либо никнеймы — как пожелает сама команда.
Постарайтесь, пожалуйста, не забыть никого “в шкафу”, как это часто в моей практике происходило с дизайнерами: после недели тренингов и коучинга с запуском проекта, на этапе заполнения матрицы, руководство «вспоминало», что забыли пригласить UX-а.
Итак, в строках у нас получился список членов команды. Шаблон матрицы готов, начинаем заполнять. Лучше если кто-то один нарисует заготовки кружков для всей матрицы, на пересечении строк и столбцов. Ниже — пример того, что должно получиться.
Каждый член команды заполняет матрицу одним из 4-х типов “солнышка”. Под солнышком понимается кружок, разделенный на 4 сегмента.
Теперь давайте посмотрим, что же все это значит для нас.
Паттерн: пустые колонки — первое, на что мы можем обратить внимание. Это значит, что команда еще не укомплектована, нужно открывать вакансию или искать кого-то из “family, fools, friends” в случае стартапа.
Если навык редкий и редко-используемый, существует соблазн найти кого-то part-time или воспользоваться подрядными услугами. Очень не советую: зависимость команды от внешних людей может привести к ожиданиям, разделению на “мы” и “они” и мячу на чьей-то стороне.
Если вы действительно ограничены в ресурсах или никак не можете найти постоянного члена команды, то, как минимум, придерживайтесь правила: внешний специалист никогда не должен работать один. Попробуйте найти Т-человека в вашей команде, который захочет освоить эту область, хотя бы на уровне “полу-солнышко”, и предложите ему работать в паре с привлеченным специалистом.
Готова ответить возражениями по поводу двойной стоимости парной работы, но чуть позже, поскольку ниже еще буду говорить о проектных рисках.
Паттерн: одинокие “солнышки”, заполненные больше, чем наполовину. Они создают обманчивую уверенность наличия настоящей “звезды” у нас в команде. Поэтому, полезно проверять таких людей на “автобусный фактор”.
Автобусный фактор (Bus Factor) это забавная проектная «метрика», которая показывает, как много специалистов в вашем проекте может сбить автобус, и проект все еще останется жив.
Одинокие солнце-звезды (как и внешние специалисты, о которых я писала выше) — потенциальные “клиенты” автобусного фактора. Несмотря на всю их квалификацию, достаточно умелого хедхантинга, отпуска или рождения ребенка, что бы проект оказался в опасности.
Что делать? Определить, кто хотел бы освоить этот навык или сферу проекта, предложить работу в паре или переключение между задачами, растить Т-людей.
Паттерн: Ни одного закрашенного солнышка рядом с закрашенными наполовину. Вывод очевиден: у нас есть средние специалисты, возможно, с желанием учиться, но отсутствием внутренних менторов. Чем чревато? Сомнительным качеством или недостаточной скоростью работы. Решение: обучение внутри компании, внешний или корпоративный тренинг, найм более крутого “солнышка” — на выбор.
Любым бумажным артефактам полезно повисеть какое-то время на стене в комнате команды — они, вместе с дискуссиями в ходе упражнений, создают групповую социальную память, которая очень важна в процессе командообразования.
О последнем, планирую собрать идеи и инструменты для следующей публикации. Разумеется, речь не о совместных вылазках на природу и корпоративных вечеринках. У меня есть сильное убеждение, что командообразование, созданное на пикниках и вечеринках, к сожалению, там же и заканчивается.
Спасибо за внимание, буду рада ответить на вопросы и комментарии ниже.
Bus-фактор в работе аналитика. Как экстренно погрузиться в проект и не перегореть от объема задач
Привет, Хабр! Меня зовут Екатерина Герт. Вот уже больше 10 лет я работаю системным аналитиком в проектах по заказной разработке ПО для компаний из разных отраслей и госсектора. Это всегда работа над большими проектами.
Однажды я оказалась в непростой ситуации, когда мне одной нужно было параллельно работать над четырьмя масштабными проектами. Со мной такое случилось впервые, потому что сработал Bus-фактор. Это когда на проекте много героев, в руках которых сосредоточена информация о работе ключевых функций, в которой на проекте больше никто не разбирается.
Для меня это были непростые месяцы в моей карьере. Я хочу поделиться с вами своим опытом — как пережить такие ситуации, не перегореть и завершить работу в срок. Моя история может быть полезна тем, кто переживает аврал на работе и ищет способы выйти из него без потерь.
В тексте будут только мои иллюстрации. В работе я часто использую визуализацию, когда погружаюсь в новую предметную область, проектирую решение или презентую команде идеи. Это дает вдохновение мне и помогает команде лучше запоминать информацию. А еще помогает снять напряжение и заряжает положительными эмоциями.
Предыстория
Три года я работала в команде, которая параллельно делала несколько проектов по развитию системы электронного документооборота для одного заказчика.
Точнее сначала эта команда разработала систему на базе documentum. Дальше Система развивалась и дополнялась под запросы заказчика. Постепенно в нее добавляли автоматизацию новых бизнес-процессов, интеграции со смежными системами и даже сделали мобильное приложение для удаленной работы.
Команда аналитиков, когда я в нее попала, состояла из четырех человек:
Ведущего аналитика проекта;
Двух ведущих аналитиков на разработке требований. Один из двух — это я;
Одного младшего аналитика, которая работала в паре с ведущим аналитиком над тремя проектами.
Чтобы влиться в работу команды аналитиков, новичку надо было изучить несколько десятков документов, освоить работу в этой системе, поработать на третьей линии технической поддержки. Только после этого аналитик мог качественно прорабатывать требования к новым блокам функциональности. Для новичка погружение в проект могло занимать 2-3 месяца.
Началось. Bus-фактор сработал
Однажды на проекте сработал Bus-фактор или «фактор автобуса».
Bus-фактор — то количество людей в команде проекта, внезапное исчезновение которых приведет к закрытию проекта. Этих людей можно еще назвать «герои» проекта. В их руках сосредоточена информация о работе ключевых функций, в которой на проекте больше никто не разбирается. Эти герои могут хорошо разбираться в запутанном и сложном коде, владеть знаниями о предметной области, в которых сложно разобраться другим или это потребует больших затрат времени. Чем больше таких героев в проекте, тем выше bus-фактор и тем ниже устойчивость проектной команды.
Сначала команду покинула младший аналитик. Она переезжала в другую страну. Меньше чем через месяц после этого из команды решил уйти мой коллега, ведущий аналитик, который работал с ней в паре. Он решил перейти в продуктовую разработку и получил интересное предложение. Да, это был Bus-фактор в команде аналитиков во всей красе.
Так вышло, что в этот момент команда была на пике нагрузки. Мы работали над 4 проектами. В каждом создавался новый функциональный модуль для развития существующей системы электронного документооборота. Другой ведущий аналитик проекта в это время был занят на пресейлах и смежных активностях по работе с заказчиком. По всем проектам приемочные испытания должны были пройти через два-три месяца — они шли последовательно с интервалом в две-три недели.
Хорошая новость заключалась в том, что основная часть работ по аналитике была закрыта — требования описаны и согласованы с заказчиком. Но была и плохая новость — это были далеко не все работы, которые обычно делает аналитик в команде.
При активной фазе разработки и тестирования аналитику нужно быть на связи и отвечать на вопросы коллег. Кроме того, для подготовки к приемочным испытаниям нужно провести «бизнес-тестирование»: аналитик должен проверить, соответствует ли, с точки зрения обычного пользователя, реализованная функциональность той, что описана в требованиях. Аналитик также отвечает за подготовку целого комплекта документов — руководство пользователя, краткие инструкции для работы пользователей с разными функциональными ролями в системе — и описывает детали реализации требований для команды.
В итоге встал большой вопрос: кто примет на себя все эти активности?
Кто примет на себя новые проекты? Сложное решение и борьба с выгоранием
Не знаю, что чувствовал в тот момент менеджер нашего проекта. Наверняка ему было нелегко, и это было сложное решение о том, кто примет на себя проекты ушедшего коллеги. Я могу рассмотреть ситуацию только со своей позиции.
Вариантов было не так много:
Привлечь нового человека взамен тех, что покинули команду;
Привлечь ведущего аналитика проекта;
В этой сложной ситуации наш менеджер сделал все, чтобы ее можно было преодолеть. Конечно же, мы сразу начали поиск нового аналитика. На первое время взяли нового младшего аналитика, до выхода нового ведущего аналитика. Младшему аналитику можно было передать работу над рутинными и простыми задачами. Это немного разгрузило меня и дало больше драгоценного времени.
Менеджер договорился с уходящим аналитиком, что тот поддержит нас в этот переходный период и будет отвечать на вопросы команды. Осталось только выбрать того, кто подхватит проекты.
Можно было привлечь ведущего аналитика проекта, но она в то время была больше занята на пресейловой активности. Ей также потребовалось бы время на погружение в детали, хотя конечно гораздо меньшее, чем новому аналитику, к тому же груз проектных задач на ней и так был достаточно большим.
Идеальным вариантом было бы привлечь меня. Небольшую часть функциональных требований мы разрабатывали вместе с коллегой, который уходил — я была больше остальных погружена в тему. Но это не значит, что я знала ее досконально.
Но со мной тоже был нюанс. К тому моменту я работала на проектах для этого заказчика уже три года и тоже решила, что хочу развиваться дальше, а в этой команде своего потолка достигла. Мы обсудили все с менеджерами, ресурсным менеджером и ведущим аналитиком проекта, стартовали мой процесс постепенного выхода из проектной команды — и в этот момент, когда я практически стояла у «выхода», как раз сработал bus-фактор.
Наверняка вы уже догадались, кому предложили подхватить проекты? Да, это была я. Но я не согласилась. сразу.
Почему я не согласилась сразу?
Лично для меня это значило отложить свой выход из проекта еще как минимум на год. Объем работы и уровень ответственности просто зашкаливали. Мне действительно было страшно взять все на себя и подвести команду. Взять на себя такой объем, казалось, означало согласиться на постоянные переработки (кстати, спойлер, перерабатывать не пришлось).
Но были в этой задаче и привлекательные моменты. Это определенно сложная задача, на которой можно себя проявить. Это профессиональный рост и плюс в копилку опыта работы в сложных ситуациях. В случае успеха этот кейс повысит мою репутацию среди менеджеров, с которыми мне предстояло работать, и возможно, на проектах для других заказчиков.
Ну и не могла я оставить команду, людей, с которыми проработала несколько лет, в такой сложной ситуации. Голос ответственности внутри меня громко кричал, что я должна соглашаться!
А я все никак не могла согласиться. Было много разных факторов как «за», так и «против». Тут я вспомнила про квадрат Декарта, о котором недавно узнала на курсе по тим-лидерству, и решила его применить для решения этой непростой задачи.
Квадрат Декарта позволяет оценить плюсы и минусы какой-то идеи по четырем направлениям:
Что я получу, если сделаю «это»;
Что я получу, если НЕ сделаю «это»;
Что НЕ получу, если сделаю «это»;
Что я НЕ получу, если НЕ сделаю «это».
Получается четыре сектора. В каждый нужно вписать то, что произойдет, если реализовать или не реализовать какую-то задачу, решение или идею. Дальше для каждого пункта в каждом секторе нужно проставить веса — насколько этот пункт лично для вас значим. Например, по пятибалльной шкале. В области «получу», эти балы с «+», а в области «Не получу» с «-». Складываем цифры в каждой половине «Сделаю» и «Не сделаю», получаем вес — «за» и «против» решения.
Кстати, тут еще можно подумать, какие факторы могут усилить позицию «за». Очень важную роль сыграла поддержка команды, менеджера проекта и ресурсного менеджера. Они не давили и были готовы помочь.
Взвесив все плюсы и минусы, стало понятно. Решаюсь!
От лирики к практике: как пережить шторм и сдать все проекты вовремя
Дальше я хочу поделиться с вами несколькими практиками, которые применяла в этот непростой период. Они позволили мне сдать все задачи в срок и с высоким качеством, обойтись без переработок и пережить стресс от нависших дедлайнов.
Пока я работала над этими проектами, я пробовала все известные мне практики, которые могли меня выручить. Некоторые из них хороши именно в кризис, когда важно держать высокий темп, следить за малейшими отклонениями от графика, обрабатывать огромный поток задач. Другие пригодятся и в ситуациях поспокойнее, чтобы зарядиться энергией, найти решение и разложить все по полочкам.
Все зависит от вас, вашей ситуации и условий, в которых вам надо работать.
Как быстро погрузиться в новые активности?
Чем плановое погружение в проект отличается от экстренного, когда надо быстро разобраться в теме и подхватить проект от коллеги?
Получи максимум информации о проекте
Времени очень мало. Работа уже идет, задачи копятся. Но хуже всего, что у аналитика в такой ситуации нет контекста, в котором его коллега разрабатывал требования. Этот контекст создают встречи с заказчиком, переписка, нормативные документы и регламенты, которые аналитик изучает, работа с замечаниями от заказчика.
При экстренном погружении в проект нет возможности восстановить этот контекст полностью. Но кое-что все таки можно сделать, чтобы вытащить главное:
Встретиться с коллегой, от которого нужно принять проект и вытащить из него максимум информации о статусе проекта, задачах, договоренностях и сложностях.
Изучить артефакты, которые есть в проекте: документы с требованиями, задачи в работе у аналитика, список заинтересованных лиц и все, что найдется.
Визуализируй для быстрого погружения
Если проектов, на которых требуется «экстренное погружение» больше одного, то можно захлебнуться, пытаясь впихнуть весь объем требований, задач, плановых сроков себе в голову за один присест. В сложившейся ситуации меня выручила визуализация. В этом проекте я использовала визуальные заметки на флипчарте. Для этого нужны стикеры, маркеры и сам флипчарт.
Вместе с моим коллегой, от которого нужно было принять проект, мы таким образом расписали основные задачи и активности, которые были на нем, отметили сроки и записали договоренности с заказчиком. Оказалось, что кроме проектов в активной фазе, у него есть несколько проектов, по которым он отвечает на вопросы внедрения в рамках гарантийной поддержки. В общем, когда он посмотрел на нашу визуализацию и увидел картину целиком, то сказал, что на самом деле не осознавал до конца, какой объем задач на нем лежал.
Это важный момент в контексте работы с несколькими проектами одновременно. Если обсуждать их по очереди, единой картины не будет. Мозг старательно будет все упрощать. Важно любым удобным для вас способом свести все кусочки в одном пространстве. Для меня это была визуализация на флипчарте. Для вас это может быть mind-map, доска в miro, или что-то еще.
Когда сложилось общее представление о задачах, сроках и договоренностях, нужно обсудить с менеджером план. В такой ситуации менеджер становится главным помощником — он заинтересован в том, чтобы проект был сдан в срок.
Так вместе с менеджером мы наметили план работы, сроки и ресурсы. Тут тоже пригодился мой флипчарт. Он дал нам основу для планирования. Ну а дальше началось самое интересное — быстрое погружение в требования.
Я попробовала новый для меня подход — визуализация требований. Не всех конечно, но самых важных. При помощи коротких заметок на стикерах с рисунками к ним, получилось создать систему образов и легче ориентироваться в этом объеме. Могла ли я, к примеру, точно рассказать алгоритм обработки данных? Конечно нет. Но я знала основные шаги, из которых он состоял и знала, где найти подробности.
Так как я впервые пробовала визуализацию требований, то мне было интересно, сколько времени займет такое погружение. Выборка конечно небольшая, всего три проекта, но у меня ушло от трех до шести часов на документы объемом 100-150 страниц.
Меньше времени потребовалось на документ, в котором мы совместно с коллегой прорабатывали требования к использованию доверенностей. Больше времени потребовалось на новые для меня бизнес-процессы с финансовыми документами и многосторонними договорами.
Плюсы в использовании визуализации:
Требует немного времени;
Хорошо запоминается благодаря связи текста с визуальным образом;
Можно обсуждать с коллегами на встречах;
Визуальные заметки не являются самостоятельным рабочим артефактом. Их нельзя переслать коллеге для самостоятельного изучения.
На этом важный этап погружения в проект можно считать условно законченным. У вас на руках или в голове уже есть:
План работы с ключевыми задачами и датами;
Представление об ожиданиях заказчика и требованиях, которые это ожидание должны реализовать.
По ходу работы эта картина все время будет дополняться. Вы узнаете что-то новое, или случится еще что-нибудь неожиданное, или у заказчика что-то изменится в работе — главное у вас есть, от чего оттолкнуться.
Теперь начинается следующий не менее интересный этап — «работа над задачами по плану».
Как сохранить work-life balance в водовороте проектных задач?
После погружения в предметную область как из рога изобилия начинают сыпаться задачи: «срочно», «очень срочно» и «надо было еще вчера». В них можно утонуть. Мозг в панике начинает хвататься за первое, что прилетело, и пытаться что-то лихорадочно придумать.
Вот тут мне очень вовремя попала в руки книга Максима Дорофеева «Джедайские техники». Я решила, что настал лучший момент начать вести списки задач.
Составляй списки
Не сразу, но в итоге я пришла к доске в Trello из четырех колонок:
«Надо сделать» — для общего списка задач. Туда я записываю все задачи, какие у меня есть, потом сортирую их в том порядке, в котором планирую их сделать относительно друг друга.
«На контроле» — список для делегированных задач, по которым мне нужно проверять исполнение.
«Сделать сегодня» — это мой план работы на день.
«Сделано» — сделанные за день задачи. Приятно смотреть на то, как этот список растет. Видно, что день прошел не зря.
Фильтруй задачи
Перед тем, как записывать задачи в Trello в списки, я мысленно пропускаю их через три фильтра в своей голове:
Фильтр №1. «Это можно сделать за 5 минут?»
Если вопрос или задача займут не больше 5 минут, то беру и делаю тут же, никуда не записываю. Чтобы ответить на вопрос или выполнить задачу нужно больше 5 минут? Записываю в список «Надо сделать».
Фильтр №2. «Это можно делегировать?»
Фильтр №3. «Это можно не делать?»
Иногда можно что-то не делать прямо сейчас, а достаточно запланировать и сделать к определенной дате. Если автор не указал дату, к которой задачу надо сделать, то предлагаю ему свой вариант. Если у меня и у автора задачи разные представления о срочности задачи, то обсуждаем, почему она срочная. Что будет, если ее не сделать прямо сейчас?
В итоге получается список задач для работы на день — «Сделать сегодня».
Записывай все дела
Конечно, в течении дня мне прилетали звонки и письма, но прежде чем что-то с ними делать я их обязательно записывала.
В начале краткое обозначение проекта, т.к. их у меня в работе было несколько. Например, «ЭП» — для проекта с электронной подписью.
Дальше краткая формулировка задачи в стиле «Что надо сделать». Например, «Дополнить раздел 7 ТЗ списком кратких инструкций». В 7 разделе были требования к документированию.
Дальше дополнительная информация, чтобы из задачи сразу перейти к исполнению. Например, ссылки на документ, который надо исправить или реквизиты письма, чтобы быстро его найти и ответить.
Давай себе время выдохнуть
Мой рабочий день строился так. Утром я просматривала почту и заносила задачи в списки. Дальше двигалась по списку задач «Сделать сегодня». В конце дня я сверялась с планом и выполненными к концу дня задачами, все ли успеваю. Пару раз в неделю я обязательно делала что-то для себя, чтобы отдохнуть и переключиться с динамичной работы на отдых.
Да, в этот непростой период очень-очень важно зарезервировать в своем расписании время для себя: спортом заняться, или порисовать что-то. В общем это должно быть занятие, которое поможет переключить мозг с работы на другую активность, которая вам нравится и заряжает вас энергией.
Будет очень непросто, когда много задач и горят дедлайны, оставить в своем графике время на себя. Будет огромное желание вычеркнуть все личные дела на время, пока шторм не пройдет. Если вы так сделаете, то это с высокой вероятностью приведет вас к выгоранию.
Я в это время начала заниматься фитнесом с тренером, чтобы отказаться было нельзя, занятия ведь оплачены и идут по расписанию. Еще стала больше рисовать, ходила на мастер-классы. Вся эта активность создавала приятное ощущение, когда после тяжелого дня, где многое шло не по плану, происходило что-то хорошее так, как я и планировала.
Проекты сдали — делаем выводы
Это было трудное время. Не смотря на это, мы успешно сдали все проекты в срок без потери качества. К нам в проект уже на последнем этапе — подготовка к приемо-сдаточным испытаниям — подключилась Татьяна, ведущий аналитик с огромным опытом. Таня подхватила работу с документацией и даже поучаствовала в испытаниях. Она сняла с меня большой груз по этим проектам и помогла довести эту работу до конца.
Мы сделали выводы и внесли изменения в работу:
Проводили перекрестное ревью работ друг друга, чтобы знания о какой-то части системы не концентрировались у кого-то одного.
Больше общались и обсуждали наши планы: проектные и на личное развитие, чтобы дать больше возможностей развиваться внутри команды.
Укрепили команду аналитиков новыми аналитиками.
Какое-то время нам потребовалось, чтобы привести внутренние артефакты в порядок. Эти рутинные задачи мы обычно делали до приемо-сдаточных испытаний, но из-за большой нагрузки их пришлось отложить. И это был тоже своеобразный отдых — работа в размеренном ритме.
Конечно, отдых и отпуск также были нужны. Отпуск у моря помог восстановиться.
И новый проект я тоже получила, как хотела. Продолжаю двигаться дальше к своим целям.
С авралами может столкнуться каждый. Главное, чтобы они не становились нормой. Если у вас был опыт работы в аврале, поделитесь в комментариях, что вам помогало или может быть помогает прямо сейчас справиться с ним.