Одна из самых больших перемен в моей карьере произошла, когда я перестал считать каждый новый внезапный запрос личной проблемой, которую надо решить, и начал видеть в нём компромисс, который надо объяснить.
В начале, когда PM подкидывал новую задачу или «срочный» баг посреди спринта, моя реакция была одна: «Как это впихнуть?» Я работал допоздна, пропускал перерывы, метался между контекстами и просто давил сильнее. Невысказанное предположение было в том, что если я достаточно хороший инженер, я должен справиться.
Но реальности всё равно на вашу мотивацию. Если в среду приходит новое требование, а вы пытаетесь вместить его силой стресса, лишь бы сохранить исходный дедлайн в пятницу, вы ничего не чините. Вы просто делаете отсутствие планирования невидимым. И всё равно будете чувствовать вину, когда в пятницу срок всё-таки сорвётся.
Теперь я смотрю на это иначе. Я не пытаюсь это впихнуть. Я спрашиваю: «Что выпадет из плана из-за этого?»
Это не сопротивление и не драма. Это просто базовая прозрачность. Если мы добавляем объём, сроки сдвигаются. Если вы затаскиваете меня на три дополнительные встречи по согласованию, у меня остаётся меньше времени на написание кода. Это не мнения, это последствия.
Много разработчиков думают, что установить границы значит постоянно говорить менеджменту «нет». Обычно всё проще: вы не отказываетесь от работы, вы просто объясняете её реальную цену. Когда эта цена озвучена, пусть бизнес решит, готов ли он её платить.
Парадоксально, но конфликтов от этого становится гораздо меньше. Вы больше не воюете за приоритеты. Вы просто показываете, как устроены ресурсы. Проекты редко проваливаются из-за плохих намерений. Они проваливаются, потому что все делали вид, что ограничений не существует, пока не упал прод.