Умение говорить нет в разработке Михаил Буча называет навыком важнее модного фреймворка и еще одного сертификата. В колонке для Habr / Карьера главный эксперт OTP Банка по Java/Kotlin разбирает простую, но болезненную для отрасли вещь: разработчики слишком часто соглашаются на все подряд, а потом платят за это сроками, качеством и выгоранием.
Поводом для разговора стала не абстрактная теория про личные границы, а вполне рабочая реальность. Автор описывает типичный конфликт приоритетов: у разработчика горит критичный баг, но параллельно прилетает просьба помочь тестировщику с частным вопросом. Формально можно броситься спасать всех сразу, но на практике это почти всегда означает одно из двух: либо критичная задача уедет вправо, либо помощь окажется поверхностной. Логика Михаила предельно приземленная: отказ в такой ситуации не делает человека плохим коллегой, а показывает, что он умеет различать срочное и важное. Для команд, где каждый хватается за любую входящую просьбу, это звучит почти как контркультурный манифест.
Главная мысль текста в том, что слово «нет» в разработке часто путают с саботажем, хотя по смыслу оно ближе к честной оценке ресурсов. Автор прямо пишет: проблема начинается еще на старте карьеры, когда разработчик боится испортить отношения, показаться слабым или, в худшем сценарии, попасть под увольнение. Из-за этого люди соглашаются на задачи, сроки и переработки, которые изначально не бьются с реальностью. В отрасли это старая болезнь: инженер берется за невозможное не потому, что верит в чудо, а потому, что не хочет выглядеть неудобным. В результате неудобно становится всем.
Самый жесткий фрагмент материала касается нереалистичных дедлайнов. Михаил приводит узнаваемую сцену: задачу оценили в пять дней, но сверху просят сделать за один-два, потому что «заказчик ждет». Здесь автор советует не искать вежливых эвфемизмов и не прятаться за размытым «попробую». Его позиция проста: если работа требует пяти дней, надо так и говорить. Иначе разработчик сначала молча принимает чужую фантазию за план, а потом сам же оказывается виноватым, когда этот план рассыпается. Важный акцент: проблема может быть вовсе не в скорости команды, а в том, что срок уже кому-то пообещали без согласования с исполнителями. В таком раскладе отказ перестает быть личным капризом и становится способом вернуть разговор в реальность.
Отдельно автор проходится по фразе «я попытаюсь» и делает это не из любви к придиркам. Для него это опасная формулировка, потому что она оставляет собеседнику пространство для ложных ожиданий. Если разработчик говорит, что «попытается» ускориться, менеджмент легко считывает это как намек на скрытый резерв: будто раньше команда работала не в полную силу, а теперь, если надавить, внезапно поедет быстрее. Михаил ссылается на идею из книги Роберта Мартина «Идеальный программист»: профессионал не торгуется туманом, а дает ясный ответ. В переводе на язык ежедневной работы это означает меньше «может быть» и «наверное» и больше четких оценок, даже если хочется подстраховаться словесным дымом.
При этом колонка не скатывается в проповедь о тотальном отрицании. Автор специально подчеркивает: умение говорить нет не равно привычке отказывать всем подряд. Сначала нужно взвесить контекст, понять приоритеты и только потом резать лишнее. В тексте есть показательный пример с сервисом авторизации для демо. Когда звучит запрос «нужно завтра выкатить весь сервис», правильный ответ — не героическое «сделаем», а уточнение границ задачи. После первого «нет» выясняется, что для встречи нужен не весь сервис, а только вход и выход из системы. И тут уже появляется рабочее «да»: конкретный кусок можно закончить к сроку, остальное — позже. Это, пожалуй, самый полезный тезис всей заметки: отказ часто нужен не для конфликта, а для переговоров о реальном объеме работы.
Для русскоязычной IT-аудитории здесь нет сенсации, но есть неприятно точное зеркало. Последние годы рынок то остывает, то нервничает, команды живут под давлением сроков и оптимизаций, а лозунг «мы же команда» нередко оказывается удобной упаковкой для бесплатных переработок. На этом фоне умение говорить нет становится уже не просто soft skills из презентации HR, а рабочим инструментом управления риском. Для разработчика это защита от выгорания и репутационных ловушек. Для тимлида — способ не превращать оценку в гадание. Для бизнеса — шанс раньше услышать правду о сроках, а не позже оплачивать последствия плохого планирования.
В сухом остатке тезис Михаила звучит сильнее, чем многие карьерные советы из серии «учитесь новому каждый день». Умение говорить нет в разработке не делает инженера жестким или неудобным; оно делает его предсказуемым для команды и полезным для продукта. Вопрос теперь не в том, нужно ли этому учиться, а в том, сколько еще команд будут считать зрелостью молчаливое согласие на заведомо невыполнимые обещания.