Что делать, если разработчики срывают сроки
И вы сидите и думаете: «Что я делаю не так?»
1. Почему срываются сроки
Причин много. Вот самые частые:
1.1. Нет чёткого ТЗ
Разработчики не знают, что именно нужно сделать. Они додумывают. Додумки оказываются не теми. Они переделывают. Сроки срываются.
Решение: ТЗ должно быть написано до начала разработки. И оно должно быть детальным.
1.2. Разработчики оценивают время сами
Разработчик говорит: «Сделаю за 3 дня». Вы верите. Через 3 дня ничего не готово. Почему? Потому что разработчик не умеет оценивать время. Это отдельный навык, которому нужно учиться.
Решение: Оценки должны давать люди с опытом. Или, как минимум, оценки должны быть коллективными (не один человек, а вся команда).
1.3. Задачи не разбиты на мелкие части
«Сделать личный кабинет» — это задача на месяц. Её нельзя оценить. Ею нельзя управлять. Она висит как «чёрный ящик», и вы не знаете, что внутри происходит.
Решение: Декомпозиция. Крупная задача разбивается на мелкие. Каждая мелкая задача — 1–3 дня. Тогда вы видите прогресс каждый день.
1.4. Изменения в процессе
Вы решили добавить «небольшую фичу». Разработчик сказал «ок, сделаем». Но он не пересчитал сроки. Или пересчитал, но не сказал вам. В итоге срок сдвинулся, а вы узнали об этом только в день сдачи.
Решение: Любое изменение — это пересмотр сроков. И это должно быть зафиксировано.
1.5. Разработчики не говорят о проблемах
Разработчик столкнулся с трудностью. Он думает: «Сейчас разберусь». Не разбирается. Думает: «Ещё немного». Проходит день. Два. Неделя. Он молчит. Вы узнаёте о проблеме, когда срок уже прошёл.
Решение: Контроль через трекер задач. Не через ежедневные отчёты.
2. Контроль через трекер, а не через отчёты
Ежедневные отчёты — это зло. Они убивают большинство разработчиков.
- Они отвлекают от работы.
- Они создают ощущение, что разработчика контролируют, а не доверяют.
- Они превращаются в «я сделал, я пишу отчёт, я ничего не сделал, потому что писал отчёт».
Альтернатива есть. И она работает лучше.
2.1. Трекер задач — это система контроля
В трекере есть всё, что нужно для контроля:
- Задача.
- Исполнитель.
- Статус.
- Время.
- Комментарии.
Вам не нужно спрашивать: «Что ты делаешь?». Вы просто открываете трекер и видите статус каждой задачи.
2.2. Правило для разработчиков
Одно правило, которое решает 90% проблем с контролем:
Взял задачу в работу → сделал → написал комментарий с указанием коммита в системе контроля версий → перевёл задачу в «выполнено».
Всё. Никаких ежедневных отчётов. Никаких созвонов «а что там у тебя». Только трекер.
2.3. Что это даёт
- Прозрачность. Вы видите статус каждой задачи в реальном времени.
- Историю. Все комментарии и коммиты привязаны к задаче. Через год вы сможете посмотреть, кто, что и когда делал.
- Дисциплину. Разработчик знает, что его работа видна. Это мотивирует не «висеть» в задаче неделями.
- Экономию времени. Никто не тратит время на отчёты.
3. Что делать до начала разработки
3.1. Написать ТЗ
Без ТЗ вы не имеете права требовать соблюдения сроков. Потому что разработчики не знают, что должны делать. ТЗ — это основание для оценки сроков.
3.2. Сделать декомпозицию
Разбить большую задачу на маленькие. Каждая задача — не более 3 дней. Это позволит вам видеть прогресс каждый день и вовремя замечать проблемы.
3.3. Утвердить сроки
Сроки должны быть согласованы до начала работы. И они должны быть реалистичными. Если разработчик говорит «3 дня», а вы знаете, что это 2 недели — не соглашайтесь. Спросите, почему он так думает. Попросите разбить на задачи.
4. Что делать во время разработки
4.1. Смотреть в трекер
Раз в день (или раз в два дня) открываете трекер и смотрите:
- Какие задачи в работе.
- Какие задачи застряли в одном статусе.
- Какие задачи уже выполнены.
Это занимает 5–10 минут. Не час. Не полдня. Именно столько, сколько нужно для контроля.
4.2. Сравнение с планом
Сравниваете реальность с планом. Если видите отставание — выясняете причину. Не через «а что там у тебя», а через трекер.
4.3. Фиксация изменений
Если в процессе появляются новые задачи — фиксируйте их в трекере. Оценивайте. Пересматривайте сроки. И утверждайте изменения.
5. Что делать, если сроки уже сорваны
Если срок уже сорван — не паникуйте. Но и не закрывайте глаза.
5.1. Понять причину
Почему сорвался срок? Нет ТЗ? Плохая оценка? Изменения в процессе? Разработчик молчал о проблемах? Без понимания причины вы не сможете исправить ситуацию.
5.2. Пересмотреть сроки
Новые сроки — новые задачи. Пересмотрите оставшийся объём работы и назовите новую дату.
5.3. Сделать выводы
Если проблема повторяется — значит, система управления не работает. Меняйте подход.
6. Моя роль в этом процессе
Я не пишу код. Но я делаю то, что позволяет контролировать сроки:
- Пишу ТЗ. Чёткое, детальное, по которому разработчики работают без переспросов.
- Делаю декомпозицию. Разбиваю большую задачу на маленькие, каждая — 1–3 дня.
- Описываю задачи для трекера. Разработчик открывает задачу и знает, что делать.
- Корректирую сроки. Разработчик утверждает или меняет срок. Если я вижу, что силы переоценены и времени взято мало, либо наоборот — на простую задачу выставлен неадекватный срок, я самостоятельно выхожу на связь и обсуждаю этот вопрос.
Когда есть ТЗ, декомпозиция и задачи в трекере — управлять сроками становится просто.
7. Итог
Срывы сроков — это не «злой умысел» разработчиков. Это проблема управления.
- Без чёткого ТЗ, без декомпозиции, без правил работы с трекером — сроки будут срываться всегда.
- С ТЗ, декомпозицией и трекером — сроки становятся реальными.
Ежедневные отчёты не нужны. Нужен трекер задач и дисциплина.
Если у вас срываются сроки и вы не знаете, что делать
Напишите. Я помогу навести порядок.