Шаблонные ответы на дейли: как распознать и что с этим делать

Утро понедельника. Разработчик: «задачу закончу сегодня». Вторник: «нужно еще два дня». Итого вместо одного дня — три. Или: «на эту задачу нужна минимум неделя». Проходит неделя и оказывается, что реальной работы там было дня на полтора, а остальное время ушло непонятно куда.

Почему так происходит: И как с этим работать? Пересказываем техтолк с Михаилом Колосовым (старший технический директор МСБ Газпромбанка) на ноябрьской TeamLead Conf 2025.

Когда разработчик называет срок с большим запасом, есть вероятность, что он просто не понимает объем задачи и страхуется. За эту неделю у него «много чего случится», и далеко не все из этого будет продуктивной работой над задачей.

Что делать: остаться после дейлика и разобрать задачу по частям. Из чего именно складывается срок? Почти наверняка там найдется возможность разбить работу на куски поменьше. Декомпозиция — лучший друг реалистичных оценок.

А еще перезакладываются обычно те, кого раньше депремировали за сорванные сроки или публично ругали за ошибки. Человек защищается, и его можно понять. Если в команде за честную оценку прилетает по голове, люди склонны завышать сроки. Поэтому надо создать атмосферу, где честность безопаснее обмана. Человек должен чувствовать поддержку команды, а не угрозу и тогда ему будет просто незачем страховаться.

Срок, который озвучивает специалист — это его коммитмент перед командой. Если он команду ценит, то постарается свое обещание сдержать. А если видит, что срывает срок, то должен сказать об этом заранее. Это гораздо важнее, чем любой ценой уложиться в первоначальную оценку.

А команда — это место, где можно признать проблему и получить помощь. Не место, где тебя будут распекать за ошибки. Если дейлик превращается в судилище, люди начнут скрывать проблемы до последнего. А потом будет поздно что-то исправлять.

Все как мы любим: срок с каждым днем уезжает все дальше и дальше.

Что случилось? Варианты:

Как выяснить? Разобрать ситуацию прямо на дейлике. Но, опять же, не для публичной порки. А чтобы понять причину и помочь. Даже если это косяк самого человека, он не должен получить порицание. Он должен почувствовать понимание и поддержку.

ТЗ меняется и будет меняться. Аналитики, например, склонны “вылизывать” документацию бесконечно, доводить до идеала. Это нормальная часть процесса. Но когда разработчик говорит: «Я не могу закончить, потому что ТЗ опять поменялось», — нужно выяснить, что именно изменилось.

Может оказаться, что изменения незначительные и вообще не влияют на его работу. А может, что правки аннулировали все, что он делал последние две недели. Это разные ситуации, и реагировать на них нужно по-разному. Нужен анализ сразу после дейлика, по горячим следам.

«Я не могу закончить задачу, потому что Поликарп не сделал свою».

За этим может стоять цепочка проблем. Зависимости между задачами нужно было учесть заранее: на груминге, на планировании спринта. И вовлечены в это должны были быть не только исполнители, но и продакт, тимлид, аналитики.

Если такое происходит, то ошиблась вся команда, а не один человек. И если не лечить, это может стать хронической болезнью: зависимости будут систематически не учитываться, а задержки повторяться.

Поэтому на этапе планирования надо явно проговаривать зависимости и закладывать их в сроки. Очевидно, но почему-то регулярно забывается.

Команда берет задачи на спринт, а в конце говорит «мы не обещали это сделать». Протоколов совещаний нет, доказать ничего нельзя.

Тут дело в том, как люди воспринимают свой коммитмент. Когда команда берет задачи на планировании — она обещает честно заниматься этим все отведенное время. Но не гарантирует результат. Это важное различие.

Что помогает: на дейликах регулярно уточнять — планирует ли человек довести историю до конца? Не «работаешь ли ты над задачей», а «закончишь ли к сроку». Дейлик должен протаскивать каждую историю вперед, а не просто фиксировать статус.

«Волки» — люди, которые работают на нескольких работах одновременно. Удаленка это позволяет. Опытные, технически подкованные, с хорошо подвешенным языком. На одном дейлике такого не распознаешь.

Но есть инструмент — кредит доверия. Это шкала, которая растет или падает со временем. Зависит от того, выполняет ли человек свои коммитменты. Раз сорвал срок — бывает. Два — настораживает. Три — явно что-то не так.

При этом если человек делает работу и не подводит команду, какая разница, волк он или нет? Главное — результат. Проблема не в том, что кто-то работает на двух работах. Проблема когда из-за этого страдает команда.

На дейли собираются люди с разными компетенциями. Продакты, аналитики, разработчики, тестировщики. То, что говорит продакт, разработчику может быть непонятно. И наоборот — технические детали для продакта звучат как птичий язык.

Если на дейлике не хватило времени синхронизироваться по терминам и пониманию, нужно остаться после него. Ведущий должен бронировать себе слот на такие случаи, желательно часовой. Для дип-дайвов в темы, которые прозвучали подозрительно или где люди явно не нашли общий язык.

Разработчик не обязан иметь подвешенный язык. Он должен хорошо знать инженерную часть. Иногда нужен медиатор, который переведет с технического на человеческий.

Несколько практических рекомендаций:

Вести четко и структурированно. Дейли — не место для долгих обсуждений. Статус, блокеры, нужна ли помощь. И уже потом все остальное.

Не снижать эффективность команды. Дейлик должен помогать работе, а не мешать ей. Если после каждого дейлика людям нужно полчаса, чтобы вернуться в контекст — что-то идет не так.

Задавать наводящие вопросы. Особенно тем, кто ведет себя неуверенно или отвечает расплывчато. Не чтобы подловить, а чтобы помочь сформулировать проблему.

Не углубляться в детали. Их можно будет обсудить потом, а на самой встрече — только то, что важно команде.

Добиваться коммитментов. Чем чаще люди дают конкретные обещания, тем больше их будет выполнено, и тем проще работать.

Дейли — не отчет перед начальством. Это синхронизация команды. Место, где люди получают помощь, а не порицание.

Если шаблонные ответы стали нормой, проблема в атмосфере. Люди закрываются и начинают «заливать», когда им небезопасно говорить правду. Создайте среду, где признать проблему выгоднее, чем ее скрывать, где команда поддерживает, а не наказывает. Тогда будут проходить эффективно и без замалчивания проблем.