Ответ
Исходя из моего опыта взаимодействия, менеджеры чаще всего раздражаются не на сложность задач как таковых, а на ситуации, которые создают непредсказуемость и срывают планирование.
Основные триггеры:
-
«Тихий» срыв дедлайна. Когда разработчик понимает, что не уложится в срок, но молчит до последнего момента. Менеджеру критически важно знать о рисках заранее, чтобы скорректировать планы или поставить в известность заказчика.
- Что я делаю: Как только вижу риск срыва оценки, сразу же сообщаю: «Есть проблема X, из-за которой задача Y может занять на 2 дня больше. Предлагаю варианты A или B».
-
Нечеткие или постоянно меняющиеся требования со стороны команды. Когда разработчик приходит с вопросом «Как делать?» без собственного анализа или предлагает кардинально менять реализацию на поздних этапах без веских причин.
- Что я делаю: Прежде чем идти к менеджеру, я готовлю конкретные варианты с плюсами/минусами. Вместо «Тут сложно» — «Для реализации фичи есть два подхода: использовать библиотеку X (быстро, но мало контроля) или написать свой модуль (+2 недели, но полная гибкость). Рекомендую первый, так как сроки tight».
-
Игнорирование установленных процессов. Пропуск code review, коммиты прямо в основную ветку, отсутствие тестов для критичного функционала. Это создает риск для стабильности продукта и увеличивает технический долг, которым потом придется управлять.
- Что я делаю: Я строго следую процессам сам и мягко напоминаю о них коллегам, особенно новым. Для менеджера это сигнал, что команда дисциплинирована и риски качества контролируются.
По сути, раздражение вызывает не работа, а неопределенность. Задача разработчика — максимально ее снижать через прозрачную коммуникацию, следование соглашениям и проактивное управление рисками.
Ответ 18+ 🔞
Давай я тебе на пальцах объясню, почему менеджер иногда смотрит на тебя так, будто ты ему в суп насрал. Дело не в том, что задача сложная — с этим все давно смирились. Дело в том, что ты создаёшь ему хуй с горы, то есть полную непредсказуемость, из-за которой его планы накрываются медным тазом.
Вот на что они орут чаще всего:
-
Тихий пиздец с дедлайном. Это когда ты уже неделю как понял, что не успеешь, но молчишь, как партизан. А потом, за день до сдачи, выходишь и такой: «Ну, тут, блядь, всё сложно». Менеджеру в этот момент хочется ебануть тебя клавиатурой по башке. Ему нужно знать о проблеме заранее, чтобы что-то предпринять, а не в последний момент охуевать вместе с ним.
- Как делать надо: Увидел, что начинаешь тонуть — сразу орёшь. «Слушай, тут вылезла проблема X, из-за неё задача Y упрётся не в пятницу, а во вторник. Варианты: либо режем фичу Z, либо добавляем два дня. Давай решим».
-
Требования, которые пляшут хуй знает как. Когда ты приходишь к нему с глазами, как у оленя, и вопросом «А как это делать?», хотя сам нихуя не думал. Или когда на середине пути предлагаешь переписать всё на другом фреймворке, потому что «так круче». Это, блядь, пиздопроебибна история.
- Как делать надо: Прежде чем открывать рот, сам подумай. Приходи не с вопросом, а с выбором. «Для этой хуйни есть два пути: взять готовую библиотеку (сделаем быстро, но потом можем быть в жопе) или пилить своё (долго, но надёжно). Я за первый вариант, потому что сроки горят».
-
Игнорирование правил, как будто ты один тут такой хитрожопый. Не делаешь ревью, пушишь сразу в мастер, пишешь код без тестов. Ты думаешь, «да похуй, сработает». А потом в два часа ночи всё падает, и менеджеру звонят. Его терпения ноль ебать в такие моменты.
- Как делать надо: Просто делай, как договорились. Следуй процессам. Если видишь, что новичок косячит, вежливо, без заёба, напомни. Для менеджера это знак, что в команде порядок и можно не бздеть по каждому поводу.
Короче, весь гнев — от неопределённости. Твоя работа — эту неопределённость впендюрить в землю. Будь прозрачным, следуй договорённостям и предупреждай о проблемах заранее. Тогда и менеджер будет спокоен, и тебя не будут посылать на хуй каждые пять минут.
