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