Субъективный взгляд на выгорание: как начать подгорать, но не выгореть

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



Возможно, это мнение покажется непопулярным и даже странным — но с тех пор я не хочу (и не могу) работать по-другому. Мне в кайф, когда разработка идет в сверхбыстром темпе. Я понял, что хочу так кайфовать. Но не хочу больше выгорать. И стал выстраивать защиту от выгорания: давайте расскажу, что получилось и как это помогло мне и команде в карантин, когда нам пришлось работать в формате «спринт за день», чтобы помочь школьникам.

Чтобы выгорание началось, нужно повторить простой цикл несколько раз

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

— Мы делаем ВОТ ЭТО за неделю!

— Это невозможно.

— В следующий понедельник нужно в проде.

— Ок, давай посмотрим, что можно сделать.

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

Так случилось в медицинском стартапе. В какой-то момент мы решили взять курс на b2b. Заказчиками стали частные клиники: на тот момент сайт с экселькой-прайслистом был для большинства верхом диджитала, мы же предлагали «комбайн» с личными кабинетами и сквозными интеграциями. При этом каждая клиника хотела что-то, чего еще не было у других, и это что-то должно было работать и выглядеть «так, как нужно». Ни заказчики, ни мы часто не знали точно, в каком виде все должно быть. Но нам было важно выпускать законченные фичи как можно чаще.


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

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

Идея «ты работаешь не потому что работа, а потому что хочешь» стала кредо. Проблемы начались позже.

Когда приходит осознание, что это в кайф — ты начинаешь работать почти всегда, когда на это есть время и настроение. Это забирает твои силы. В один момент можешь поймать себя на мысли, что не знаешь, как взять и отключить эту часть своей жизни. Если возьмёшь недельку-другую отпуска, не сможешь сделать ничего полезного. Да и вообще, как тут отдыхать, пока все работают на благое дело? В какой-то момент начинаешь думать, что можешь и без отдыха. Но это обман :)

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

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

Я стал заморачиваться, что не приношу результат. И снова стал искать себя.

История о том, как фигачить, но не выгорать дотла

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

Начало мне понравилось: за месяц нужно было запустить проект. Мы успели, но затем всё шло довольно вяло — специфика рынка, да и куча других моментов всплывали наружу. Шел март 2020-го, я решил сходить в отпуск и после завершения учебного года начать искать новый проект, так как начал скучать.

И тут настала пандемия: мой отпуск объявили нерабочей неделей, а школы перевели на «удаленку». На сайт нашего проекта пришла пара сотен тысяч школьников. Помню, как проснулся от звонка из инфры — Skyes не держит нагрузку.

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

Было принято решение о срочной миграции нашего проекта в другой — и так я снова вписался в горячку стартапа.

Давайте расскажу, как и для чего мы работали:

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

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

• Первые недели работали по 12 часов в день. Потом постепенно уменьшали до восьми. В первые недели что-то делали и по субботам. Затем вернулись к пятидневке и ввели «субботник»: просто какой-то день на рабочей неделе, когда мы удаляли код, рефакторили и так далее.
• Каждый день — это спринт с планированием и демо. Каждое утро мы обсуждали новые фичи, днем понимали, какая часть задач дойдёт до прода. Вечером на демо разработка показывала их. У нас был запрет на деплой с 9 до 15 часов, когда на сайт приходила основная масса педагогов и детей, поэтому иногда делали только «ядро» задачи, а иногда засиживались: кажется, когда мы только запускали лидерборды, сидели до полуночи, чтобы завтра всё работало.

Как-то команда исследователей попросила школьников нарисовать, как они видят нашу платформу — было забавно. Фидбек от пользователей мотивировал «фигачить» день за днем.

Два месяца спустя мы последний раз крикнули друг другу на демо: «Молодцы!», — и ушли отдыхать на неделю всей командой. В пятницу все были чертовски рады — корпоратив в Zoom, воспоминания, как это было. А после наступило самое интересное.

Мне трудно с чем-то сравнить выгорание, но, наверное, так бывает у спортсменов: когда долго идешь к цели, после наступает опустошение.

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

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

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

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

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

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

Цели могут быть амбициозными и меняться в большую сторону, но разбейте их достижение на этапы — и просчитайте заранее. В нашем случае, каждая из целей каким-то образом была просчитана аналитиками с точностью практически до даты. А затем разложена по градации: не просто «получить 10М выполненных заданий на платформе через 6 недель», а «сделать 100К через неделю», «сделать 1М через две».

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



Наш дизайнер завел открытый Slack-канал, куда каждый день писал свое настроение в %. Ради интереса, я вывел корреляцию. Вот она:


30 мая — день, когда мы закончили проект.

«Спринт за день» стал хорошим решением в условиях сжатых сроков: бизнесу важно было много экспериментировать и быстро менять продукт под влиянием аудитории, пока на продукт был спрос (а он резко упал с началом каникул). У задач был короткий time to market. Поэтому, чтобы затащить задачу к демо, она должна была быть небольшой и понятной всем.

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

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


Если мы со стороны разработки не могли разложить задачу на понятные и измеримые шаги (создать сущности, миграции, геттер, тест), становилось очевидно — что-то вызовет вопросы.

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

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

Но главное, что я понял: челленджи деструктивны на долгой дистанции

Вызовы нужны для себя. Вызовы объединяют команду. Но чтобы принять вызов и не сгореть, вам потребуются необходимые условия в виде культуры и команды, которая её разделяет. Именно их стоит культивировать на постоянной основе. Потому что «режим стартапа» либо принимается людьми, либо нет.

Но вашей общей задачей будет выйти из этого режима быстро.

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

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