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