Вступление
В этой статье я хочу поделиться наблюдениями о переработках в IT-компаниях: как они появляются, почему быстро становятся нормой, чем заканчиваются и что с этим можно делать.
Сразу оговорюсь: текст не про то, что нужно в 18:00 ронять ноутбук на пол и исчезать в закат. В инженерной работе бывают аварии. Бывают критичные баги, релизы, инциденты, миграции, production is down, деньги горят, пользователи страдают, бизнес нервно смотрит в мониторинг.
Иногда действительно нужно помочь.
Проблема начинается там, где “иногда” превращается в “каждую неделю”, аварийный режим становится обычным способом управления, а личное время сотрудников — скрытым резервом компании.
Потому что переработки редко начинаются с прямой фразы: “Мы планируем использовать вас как бесплатный ресурс после рабочего дня”. Обычно всё выглядит гораздо приличнее.
“Нужно чуть-чуть дожать”.
“Там просто релиз”.
“Проверим одну сборку”.
“Сейчас разберёмся и всё”.
“Ну ты же понимаешь ситуацию”.
И человек, конечно, понимает. А потом внезапно обнаруживает себя в 23:17, с холодным ужином, тредом на триста сообщений и ощущением, что если он сейчас уйдёт, то лично предаст продукт, команду и, возможно, всю цифровую экономику.
На собеседовании переработок нет
Если на собеседовании спросить тимлида: “А у вас бывают переработки?”, почти всегда ответ будет примерно одинаковым:
Нет, мы вообще против переработок. Ну, иногда бывает, конечно, если важный релиз или что-то критичное. Но это редко.
Звучит нормально. Даже честно звучит. Потому что действительно: кто в здравом уме скажет кандидату в лицо:
У нас тут постоянные пожары, дедлайны горят, процессы хромают, бизнес хочет всё вчера, команда устала, но мы держимся на героизме отдельных людей. Приходите, будет весело.
Так не говорят. Потому что это спугнёт кандидата. А если кандидат уже опытный, он ещё и начнёт задавать неприятные вопросы: как планируются релизы, есть ли on-call, оплачиваются ли переработки, как устроен rollback, кто принимает решение о переносе релиза, что происходит после инцидентов.
Поэтому на входе всё выглядит аккуратно. “Мы за work-life balance”. “Мы не приветствуем переработки”. “Мы взрослые люди”. “Главное — результат”.
Но реальность проверяется не словами, а поведением компании в момент стресса.
Когда релиз начал трещать.
Когда баг воспроизводится только на двух устройствах.
Когда сборка локально работает, а в CI падает.
Когда бизнес уже ждёт демо.
Когда менеджер спрашивает: “А мы точно не успеем сегодня?”
Вот в этот момент и становится понятно, что именно компания имела в виду под “мы против переработок”.
Иногда это значит: “Мы правда стараемся их не допускать”.
А иногда: “Мы против переработок как явления, но если они случились, то ничего не поделаешь, сами понимаете”.
Переработки часто начинаются не снизу, а сверху
Есть удобный миф: если человек перерабатывает, значит, он сам плохо планирует время. Не умеет оценивать задачи. Медленно работает. Недостаточно компетентен. Не может сказать “нет”.
Иногда это правда. Но далеко не всегда.
Очень часто переработка рождается не на уровне отдельного инженера, а на уровне системы. Бизнес хочет быстрее. Менеджмент обещает больше. Сроки ставятся агрессивнее, чем позволяет реальность. Риски не закладываются. Технический долг игнорируется. Тестирование ужимается. А когда всё начинает ломаться, команда героически “спасает ситуацию”.
Например, на нормальную реализацию фичи нужно: неделя на аналитику, две недели на разработку, неделя на тестирование, время на фиксы, регресс, выкладку и наблюдение после релиза. Но бизнес смотрит на это и говорит: “У нас есть две недели”.
Дальше происходит магия.
Аналитика превращается в “ну там вроде понятно”.
Разработка превращается в “пока сделаем так, потом поправим”. Код обрастает TODO, временными решениями и заглушками.
Тестирование превращается в happy path, потому что на остальное времени нет.
Релиз превращается в лотерею.
А вечер после релиза — в инженерный спиритический сеанс: “Давайте попробуем откатить вот это”, “А если выключить флаг?”, “А может, это аналитика?”, “А может, кеш?”, “А может, старая ОС?”, “А может, просто не повезло?”.
И вроде бы все работают. Все вовлечены. Все молодцы. Только почему-то система каждый раз едет на людях, а не на процессе.
Компания не всегда заставляет. Иногда она просто создаёт условия
Самая эффективная переработка — та, на которую сотрудник соглашается сам.
Не потому что ему приказали. А потому что он уже эмоционально внутри. Он переживает за продукт. Не хочет подвести команду. Хочет быть полезным. Хочет доказать, что на него можно положиться. Понимает, что без него сейчас будет хуже.
И вот это очень тонкий момент. Потому что со стороны всё выглядит добровольно. Никто не сказал: “Сиди до ночи”.
Просто в чате продолжают писать. Просто тебя пингуют. Просто ты единственный, у кого воспроизводится баг. Просто релиз важный. Просто все ждут. Просто если ты сейчас уйдёшь, остальные будут разбираться дольше.
Формально ты свободен. Фактически — нет.
Это и есть один из самых неприятных механизмов переработок: компания может ничего не требовать напрямую, но выстроить такую среду, где отказ выглядит как личная слабость или предательство команды.
Как появляется зависимость от переработок
Регулярные переработки опасны не только усталостью. Они постепенно меняют самоощущение человека. Сначала ты просто задержался на важный релиз. Потом помог команде в сложный момент. Потом ещё раз. Потом начал проверять рабочий чат вечером, “просто на всякий случай”. Потом в выходной ответил на вопрос, потому что “там быстро”. Потом поймал себя на том, что провал продукта воспринимается как личный провал. И вот ты уже не просто работаешь в компании. Ты эмоционально сросся с её проблемами.
Самое неприятное, что это не происходит за один день. Нельзя проснуться утром и сказать: “Так, кажется, сегодня я стал зависим от переработок”. Нет. Всё происходит мягко, постепенно и почти незаметно.
Это как ванна, в которой температуру поднимают на один градус каждые полчаса. В какой-то момент уже горячо, но ты не помнишь, когда именно стало некомфортно.
Через год-два регулярных переработок человек может настолько привыкнуть к этому режиму, что отдых начинает вызывать тревогу. Сидеть без работы сложно. Кажется, что ты что-то упускаешь. Что где-то горит. Что без тебя сейчас принимают важное решение. Что надо хотя бы посмотреть чат. И это уже не вовлечённость. Это нездоровая привязанность.
“Но тебе же платят зарплату”
Здесь обычно появляется логичный аргумент:
Подожди. Тебе платят зарплату. Если ты не успеваешь делать задачи в рабочее время, может, проблема в тебе?
И этот аргумент нельзя просто отмахнуть. В нём есть рациональное зерно.
Действительно, бывает ситуация, когда человек технически не дотягивает. Не знает инструментов. Долго разбирается в базовых вещах. Делает задачу три дня, хотя опытный специалист сделал бы за три часа.
В таком случае дополнительное время может быть инвестицией в себя. Человек учится, набирает скорость, закрывает пробелы, растёт. Это не всегда приятно, но это понятно: ты вкладываешь время в собственную компетентность.
Но есть другой сценарий. Ты компетентен. Ты умеешь делать свою работу. Ты нормально оцениваешь задачи. Ты не саботируешь процесс.
Но компания регулярно приносит тебе горящие дедлайны, сырые требования, хаотичные приоритеты, недоделанную инфраструктуру, технический долг и релизы, которые нельзя переносить.
Вот здесь переработка перестаёт быть инвестицией в себя. Она становится инвестицией в чужой бизнес. Причём часто бесплатной.
Вы отдаёте своё время, внимание, здоровье, вечер, выходные и нервную систему не для того, чтобы стать сильнее как специалист. А для того, чтобы компания закрыла дыру в планировании, выпустила фичу, не признала ошибку, не перенесла релиз и красиво отчиталась наверх.
И зарплата не всегда это компенсирует. Потому что зарплата обычно платится за работу в рамках договорённого рабочего времени и зоны ответственности. А когда компания системно использует ваше личное время как буфер для своих ошибок, это уже другая сделка.
Только её почему-то никто отдельно с вами не согласовывал.
Оплачиваемые переработки: хорошо, но не панацея
Оплачиваемые переработки — это лучше, чем неоплачиваемые. Тут даже спорить странно.
Если компания хотя бы признаёт, что дополнительное время сотрудника имеет стоимость, это уже здоровее, чем культура “мы же команда, ну что ты как не родной”.
Но оплачиваемые переработки тоже не решают проблему автоматически.
Во-первых, потому что деньги не отменяют усталость. Можно оплатить вечер. Нельзя полностью оплатить восстановление после месяцев жизни в аварийном режиме.
Во-вторых, потому что у оплачиваемых переработок тоже может появиться своя зависимость.
Человек начинает привыкать к дополнительному доходу. Компания привыкает, что люди готовы задерживаться. Менеджмент привыкает закладывать не реальную производительность команды, а производительность команды плюс вечер, плюс суббота, плюс “ну ребята же обычно помогают”.
Получается странная схема: формально всё честно, но по факту система начинает жить на повышенных оборотах. Как двигатель, который постоянно крутят в красной зоне и удивляются, почему он однажды сказал “я всё” и замолчал.
Особенно опасно, когда переработки нужно обосновывать пользой для бизнеса.
Закрыл критичный баг? Молодец.
Дожал релиз? Молодец.
Потушил пожар? Молодец.
А что получает команда в итоге? Сигнал: чем больше пожаров, тем больше поводов для героизма. А если после пожара нет разбора причин, изменений в процессе и ограничений на повторение ситуации, то переработка становится не лекарством, а обезболивающим.
Боль ушла. Болезнь осталась.
Технический долг оплачивается вечерами
Технический долг — удобная метафора, потому что он похож на кредит.
Когда компания делает быстрое временное решение, она как будто берёт деньги в долг у будущего. Сегодня фича выходит быстрее. Завтра её сложнее поддерживать.
Проблема начинается, когда компания платит только проценты.
Хотфикс.
Ещё один хотфикс.
Ручная проверка.
Временный флаг.
Ещё один костыль.
“Потом нормально перепишем”.
“После релиза разберёмся”.
“Сейчас не до этого”.
Так проходит месяц. Потом квартал. Потом год.
И однажды оказывается, что каждый новый шаг требует всё больше усилий, а результат всё меньше. Команда вроде бы работает больше, но двигается медленнее. Любая новая фича ломает что-то рядом. Любой релиз превращается в нервный квест. Любой баг может оказаться не багом, а симптомом того, что никто уже до конца не понимает, как система работает.
История IT и бизнеса полна компаний, которые летели к звёздам на самолётах из палок. Какое-то время это даже работает. Особенно если рынок горячий, деньги есть, конкуренты рядом, а пользователи растут.
Но у такой скорости есть цена. И очень часто эту цену сначала платят не акционеры, не топ-менеджмент и не стратегия на красивых слайдах. Её платят инженеры, QA, аналитики, devops, support и все те, кто вечером сидит в чате и пытается понять, почему “вчера работало, сегодня падает, локально не воспроизводится, а в сборке воспроизводится”.
Самое страшное — когда нельзя сказать “мы не готовы”
Зрелость компании хорошо проверяется одним вопросом:
Можно ли здесь честно сказать, что релиз нужно перенести?
Не теоретически. Не в презентации про культуру. А по-настоящему.
Можно ли сказать бизнесу: “Мы не готовы”?
Можно ли сказать топ-менеджменту: “Риск слишком высокий”?
Можно ли остановить выкладку, если команда не понимает причину критичного бага?
Можно ли признать: “Мы ошиблись с оценкой”?
Если ответ “да”, компания имеет шанс на здоровый процесс. Если ответ “нет”, начинается театр.
Все понимают, что релиз рискованный, но никто не хочет быть человеком, который принёс плохую новость. Все видят, что команда не успевает, но продолжают говорить “давайте попробуем”. Все знают, что проблема системная, но обсуждают только конкретный баг. Все устали, но в календаре уже следующий релиз.
Культура страха делает плохие новости опаснее самих проблем. И это очень опасно. Потому что баг можно починить. Срок можно пересмотреть. Фичу можно отложить. Но если в компании нельзя честно говорить о реальности, она начинает принимать решения на основе выдуманной картины мира.
А потом удивляется, почему инженеры сидят до ночи.
Что с этим делать сотруднику
Самый бесполезный совет в этой теме — “просто не перерабатывайте”.
Спасибо, очень помогло. Примерно как “просто не нервничайте” во время продакшн инцидента.
В реальности всё сложнее. Есть команда, контекст, репутация, деньги, ипотека, визы, грейды, performance review, человеческие отношения и желание делать работу хорошо. Поэтому речь не о том, чтобы стать каменной стеной и всегда говорить “нет”. Речь о том, чтобы не отдавать компании своё личное время молча и бесплатно, как будто так и должно быть.
Что можно делать:
Отделять редкую аварию от системы. Если пожар случился один раз — это одно. Если пожар каждую неделю — это уже не пожар, а отопление.
Фиксировать переработки. Не в голове, а письменно. Когда, сколько, из-за чего. Память потом красиво всё сгладит, а факты — нет.
Спрашивать про приоритеты. Если вам вечером прилетает срочная задача, нормальный вопрос: “Что мы переносим ради этого?” Срочность не должна появляться из воздуха.
Не превращать личное время в инфраструктуру компании. Если бизнесу нужна поддержка после рабочего дня, это должен быть процесс: дежурства, компенсация, правила, зона ответственности.
Не спасать процесс молча. Если вы переработали, должно быть понятно почему. И после этого должен быть разговор: как сделать так, чтобы это не повторялось.
Не путать ответственность с самопожертвованием. Быть профессионалом — не значит бежать на амбразуру и закрывать собой любую дыру.
Смотреть на повторяемость. Один сложный релиз ничего не доказывает. Десять сложных релизов подряд уже говорят о системе.
Задавать вопрос о компенсации. Деньгами, временем, выходным, официальным учётом — как угодно. Но если переработка нужна бизнесу, она должна быть признана бизнесом.
Самый важный навык здесь — научиться видеть момент, когда ваша вовлечённость начинает использоваться против вас.
Бизнес компании — не ваш бизнес
Здесь важно проговорить одну неприятную, но очень освобождающую мысль.
Бизнес компании — не ваш бизнес.
Вы можете любить продукт. Можете быть вовлечённым. Можете хотеть делать качественно. Можете переживать за пользователей. Всё это нормально и даже хорошо. Но вы не владелец компании. Вы не получаете долю от каждого успешного релиза. Вы не участвуете в стратегических бонусах топ-менеджмента. Вы не обязаны оплачивать своим здоровьем решения, которые принимали не вы.
Если бизнес осознанно ставит агрессивные сроки, принимает высокий риск, экономит на фундаменте и годами откладывает инженерные проблемы, это бизнес-решение. И странно, когда цена этого решения внезапно оказывается в вашем личном календаре после 19:00.
Можно быть ответственным сотрудником и при этом не превращаться в расходный материал.
Можно помогать команде и при этом иметь границы.
Можно переживать за продукт и при этом помнить, что ваша жизнь не является частью релизного пайплайна.
Заключение
Переработки опасны не только тем, что отнимают время. Они меняют норму.
Сначала вы задерживаетесь, потому что “сегодня правда надо”. Потом потому что “так получилось”. Потом потому что “все понимают ситуацию”. А потом оказывается, что ситуация длится уже год.
Компании редко используют людей грубо. Чаще это происходит аккуратно: через ответственность, срочность, командный дух, страх подвести, желание быть полезным и привычку спасать то, что должно было быть нормально спланировано.
Поэтому главный вопрос не в том, готовы ли вы иногда помочь.
Вопрос в другом:
Не стала ли ваша готовность помогать частью бизнес-модели?
Если стала — это уже не командная работа. Это эксплуатация, просто в красивой корпоративной упаковке.