За время моей карьеры разработчика я дважды оказывался на грани выгорания. Это не было связано с какими-то жесткими дедлайнами или сверхурочной работой.
Оба раза я работал над масштабными рефакторингами, и сейчас вижу чёткую закономерность, которая приводит к такому состоянию. К счастью, мне удалось справиться с обеими проблемами, но я думаю, что стоит изучить причинно-следственные связи, чтобы в будущем избежать подобных ситуаций.
Надеюсь, если вы окажетесь в подобной ситуации, то сможете справиться с ней лучше, чем я.
Отслеживайте свой прогресс и не теряйте темпа
Как и во многих жизненных ситуациях, наше восприятие застоя оказывается более негативным, чем есть на самом деле. Если вы стараетесь его избегать и делаете регулярные перерывы, то значительно снижаете риск выгореть.
В этой статье мы подробно обсудим, как отслеживать свой прогресс и не терять темп. Однако прежде чем перейти к этой теме, давайте вспомним несколько случаев, когда я был близок к тому, чтобы выгореть.
Описание обоих случаев, когда я чуть не выгорел
В первый раз я делал миграцию с Memcached на Redis. Короче говоря, в приложении имелась некоторая специфическая для Memcached функциональность, которой не было в Redis, а библиотека Memcached не находилась за оберткой, поэтому было много мест, которые нужно было изменить. В проекте не было тестов, что означало дорогостоящее и медленное тестирование.
Всё пошло наперекосяк, когда я перешел к переносу специфической функциональности memcached. Она использовалась для управления параллелизмом в кластере и была довольно сложной как для понимания, так и для реализации. Прогресс остановился примерно на 2 недели.
Мой менеджер поддерживал меня, но я был очень недоволен собой. Я не был продуктивен, я почти не продвигался вперед. Еще хуже было то, что было выпущено несколько крупных функций, которые открыли дополнительные возможности для работы над переносом старого клиента.
Прогресс не только остановился, но и был потерян!
Я провел целые выходные, пытаясь решить эту проблему, и... она была решена!
Или я так думал. На самом деле было много крайних случаев, которые были упущены. Я обнаружил это во время тестирования в понедельник и почувствовал себя раздавленным.
Я чувствовал себя подавленным, ведь уже несколько месяцев я работал над этой простой задачей, которая не принесла пользы бизнесу!
Я взял пару дней отпуска, чтобы устроить длинные выходные, и не притрагивался к рабочему ноутбуку.
Я пришел на работу, и ещё через неделю все побочные эффекты были устранены, и функция смогла пройти всестороннее тестирование. Больше никаких проблем не возникало.
Во второй раз я чуть не выгорел - когда переносил очень сложную часть унаследованной платформы на новую платформу. Часть, которую я генерировал, состояла примерно из 10-15 тысяч строк кода. Это не могла быть миграция 1:1, так как было много внутренних библиотек, написанных не для новой системы.
Здесь сразу начались проблемы. Задача была огромной, и на тот момент я не мог понять, как её разделить. Я попытался применить некоторые уроки, извлеченные из миграции Redis, чтобы не работать через раз, а также обратился к своему менеджеру, чтобы сказать, что мне нужна помощь.
Меня поставили в пару с другим разработчиком, и мы оба пару раз в неделю работали над кодом вместе. Работать не в одиночку очень помогло. Темп был всё ещё низким.
Но то, что я не чувствовал себя одиноким, очень помогло.
Не было никакой серебряной пули. Просто огромный проект, в который мы вносили изменения понемногу.
В конце концов мы перенесли всю систему. Это был марафон, а не спринт. К счастью, у нас было достаточно времени и понимание со стороны нашего менеджера.
Поддержание темпа
Как уже говорилось в начале статьи, поддержание темпа очень важно, но на самом деле это очень сложно сделать.
Чтобы поддерживать темп, нужно разбить большой проект на небольшие части, а затем часто поставлять небольшие, протестированные части проекта. Звучит просто и похоже на хороший цикл разработки. Это верно - темп довольно легко описать на высоком уровне.
Почему это не сработало в данном случае? Потому что мы занимаемся рефакторингом, а не создаем что-то с нуля. И потому что у нас не было тестов. Это хороший анекдотический пример того, почему вы должны иметь тесты - стоимость рефакторинга значительно снижается.
При рефакторинге вы наследуете сцепление, контракты и многие другие вещи. Это затрудняет инкрементную разработку и развертывание. В примере с Redis более инкрементный способ - использовать и Redis, и memcached некоторое время, пока не будет выполнен рефакторинг. Это, конечно, увеличит затраты на инфраструктуру и усложнит развертывание, так как в нем будет больше подвижных частей, поэтому это только решение для конкретного случая.
Общим решением будет найти способ инкрементной разработки проекта. В конце концов, большинство вещей можно разделить на части. Я думаю, что обычно этим пренебрегают, потому что на самом деле понимание деталей и зависимостей, разделение всего на части и упорядочивание их в дорожную карту может занять несколько дней для больших проектов, и некоторые люди не считают это «настоящей работой».
Я считаю, что это настоящая работа, фактически одна из самых важных частей, которую вы можете сделать как разработчик, когда перед вами очень большой проект. Конечно, будут отклонения, и вы не сможете уловить все, но если вы сумели разбить «большую, чем жизнь» задачу на несколько этапов, то будете чувствовать себя не так напряженно.
Поговорим о профилактике
Оба раза меня тормозило отсутствие подробного автоматизированного набора тестов. Если бы в организации существовала культура поддержки такого набора тестов, все было бы значительно проще.
Ещё одним моментом, добавляющим сложности, был технический долг проекта - не было должного слоя абстракции между memcached и бизнес-логикой. Расходование ресурсов на поддержание технического долга на приемлемом уровне напрямую повлияет на сложность - а значит, сделает все гораздо более управляемым. Как бороться с техническим долгом, не входит в рамки статьи, однако хочу обратить внимание на усугубляющий эффект. Наличие постоянного бюджета на исправление технического долга, пусть даже несколько скромного, будет накапливать положительные изменения с течением времени.
Правильная культура также помогает предотвратить выгорание. Несмотря на то, что над этим нужно работать, существует множество хороших инструментов, таких как эмоциональные проверки, 1:1 и тому подобное, которые позволяют руководителям заметить это как можно раньше. Чем ближе человек к выгоранию, тем сложнее вернуть его на правильный путь.
Ещё одна вещь, которая может помочь, - это привлечение технических менеджеров проектов к разделению задач. По сути, большая часть управления проектами заключается именно в этом - в разделении задач и построении графиков. Хотя масштабы и детализация задач, над которыми работают менеджеры проектов, различны, обращение к ним за помощью может существенно помочь. Чем раньше вы их привлечете, тем больше они смогут помочь. Я рекомендую не усложнять процесс. Достаточно документа с запросом на комментарии или встречи.
Что можно сделать
В настоящее время я руководитель и трачу значительные усилия на то, чтобы люди не выгорали. Я провожу проверки, убеждаюсь, что задачу можно разделить, и договариваюсь с продуктовой командой о достаточном количестве ресурсов, чтобы разработчикам не приходилось выбиваться из сил ради таких проектов.
Кроме того, если я вижу, что кто-то начинает выгорать, я часто работаю с ним в паре. Хотя это может показаться непродуктивным - тратить 2-3 часа на парный кодинг, когда мой календарь на 60 % заполнен встречами, это действительно поднимает моральный дух, поскольку показывает, что человек не одинок и что я готов помочь.
Если люди находятся в состоянии застоя, переключите их на небольшую задачу, которую они могут выполнить за 1-2 дня, и они почувствуют удовлетворение от выполнения и завершения чего-то, пусть даже небольшого, это зарядит их энергией и поднимет настроение.
Подведение итогов
В статье мы рассмотрели два проекта, которые пошли не так, как ожидалось, и чуть не вывели меня из строя. Мы поговорили о важности темпа разработки и рассмотрели различные способы его поддержания. При рефакторинге возникают дополнительные ограничения, такие как уже определенные контракты, и такие вещи, как автоматизированный набор тестов и адекватный объем технического долга, могут значительно снизить стресс от больших и сложных проектов.
Если у вас есть похожие истории, поделитесь ими. Если будете откровенны и расскажете о моментах, когда испытывали затруднения, это может помочь кому-то пройти через нечто подобное.