> ## Content Index > Fetch the complete content index at: https://admin.kod.ru/llms.txt > Use this file to discover other available public pages before exploring further. # Шаблонные ответы на дейли: как распознать и что с этим делать - URL: https://admin.kod.ru/shablonnye-otvety-na-daily/ - Published: 2025-11-27T13:05:56.000Z - Updated: 2025-11-27T13:05:56.000Z - Description: Что делать, когда разработчик перезакладывается, срок переносится, поменялось ТЗ, появляется зависимость от других? Как вести дейлики? - Author: Газпромбанк - Tags: Блоги Утро понедельника. Разработчик: «задачу закончу сегодня». Вторник: «нужно ещё два дня». Итого вместо одного дня — три. Или: «на эту задачу нужна минимум неделя». Проходит неделя и оказывается, что реальной работы там было дня на полтора, а остальное время ушло непонятно куда. Почему так происходит: И как с этим работать? Пересказываем [техтолк с Михаилом Колосовым ](https://rutube.ru/video/4674cb3897cfd61d447f9dae7d38db37/?ref=admin.kod.ru)(старший технический директор МСБ Газпромбанка) на ноябрьской TeamLead Conf 2025. ## Когда человек перезакладывается Когда разработчик называет срок с большим запасом, есть вероятность, что он просто не понимает объём задачи и страхуется. За эту неделю у него «много чего случится», и далеко не всё из этого будет продуктивной работой над задачей. > **Что делать:** остаться после дейлика и разобрать задачу по частям. Из чего именно складывается срок? Почти наверняка там найдётся возможность разбить работу на куски поменьше. Декомпозиция — лучший друг реалистичных оценок. А ещё перезакладываются обычно те, кого раньше депремировали за сорванные сроки или публично ругали за ошибки. Человек защищается, и его можно понять. Если в команде за честную оценку прилетает по голове, люди склонны завышать сроки. Поэтому надо создать атмосферу, где честность безопаснее обмана. Человек должен чувствовать поддержку команды, а не угрозу и тогда ему будет просто незачем страховаться. Срок, который озвучивает специалист — это его коммитмент перед командой. Если он команду ценит, то постарается своё обещание сдержать. А если видит, что срывает срок, то должен сказать об этом заранее. Это гораздо важнее, чем любой ценой уложиться в первоначальную оценку. А команда — это место, где можно признать проблему и получить помощь. Не место, где тебя будут распекать за ошибки. Если дейлик превращается в судилище, люди начнут скрывать проблемы до последнего. А потом будет поздно что-то исправлять. ## Вчера — сегодня, сегодня — завтра Все как мы любим: срок с каждым днём уезжает все дальше и дальше. **Что случилось? Варианты:** - Изначально недооценил задачу; - Наткнулся на подводные камни и не знает, как их обойти; - Забил. > **Как выяснить?** Разобрать ситуацию прямо на дейлике. Но, опять же, не для публичной порки. А чтобы понять причину и помочь. Даже если это косяк самого человека, он не должен получить порицание. Он должен почувствовать понимание и поддержку. ## Поменялось ТЗ ТЗ меняется и будет меняться. Аналитики, например, склонны «вылизывать» документацию бесконечно, доводить до идеала. Это нормальная часть процесса. Но когда разработчик говорит: *«Я не могу закончить, потому что ТЗ опять поменялось»*, — нужно выяснить, что именно изменилось. Может оказаться, что изменения незначительные и вообще не влияют на его работу. А может, что правки аннулировали всё, что он делал последние две недели. Это разные ситуации, и реагировать на них нужно по-разному. Нужен анализ сразу после дейлика, по горячим следам. ## Жду зависимость *«Я не могу закончить задачу, потому что Поликарп не сделал свою».* За этим может стоять цепочка проблем. Зависимости между задачами нужно было учесть заранее: на груминге, на планировании спринта. И вовлечены в это должны были быть не только исполнители, но и продакт, тимлид, аналитики. Если такое происходит, то ошиблась вся команда, а не один человек. И если не лечить, это может стать хронической болезнью: зависимости будут систематически не учитываться, а задержки повторяться. > Поэтому на этапе планирования надо явно проговаривать зависимости и закладывать их в сроки. Очевидно, но почему-то регулярно забывается. ## «Я такого не говорил» Команда берёт задачи на спринт, а в конце говорит *«мы не обещали это сделать»*. Протоколов совещаний нет, доказать ничего нельзя. Тут дело в том, как люди воспринимают свой коммитмент. Когда команда берет задачи на планировании — она обещает честно заниматься этим всё отведённое время. Но не гарантирует результат. Это важное различие. > **Что помогает:** на дейликах регулярно уточнять — планирует ли человек довести историю до конца? Не «работаешь ли ты над задачей», а «закончишь ли к сроку». Дейлик должен протаскивать каждую историю вперёд, а не просто фиксировать статус. ## Волки и кредит доверия «Волки» — люди, которые работают на нескольких работах одновременно. Удалёнка это позволяет. Опытные, технически подкованные, с хорошо подвешенным языком. На одном дейлике такого не распознаешь. Но есть инструмент — кредит доверия. Это шкала, которая растёт или падает со временем. Зависит от того, выполняет ли человек свои коммитменты. Раз сорвал срок — бывает. Два — настораживает. Три — явно что-то не так. При этом если человек делает работу и не подводит команду, какая разница, волк он или нет? Главное — результат. Проблема не в том, что кто-то работает на двух работах. Проблема когда из-за этого страдает команда. ## Разный язык На дейли собираются люди с разными компетенциями. Продакты, аналитики, разработчики, тестировщики. То, что говорит продакт, разработчику может быть непонятно. И наоборот — технические детали для продакта звучат как птичий язык. Если на дейлике не хватило времени синхронизироваться по терминам и пониманию, нужно остаться после него. Ведущий должен бронировать себе слот на такие случаи, желательно часовой. Для дип-дайвов в темы, которые прозвучали подозрительно или где люди явно не нашли общий язык. Разработчик не обязан иметь подвешенный язык. Он должен хорошо знать инженерную часть. Иногда нужен медиатор, который переведет с технического на человеческий. ## Как вести дейлики **Несколько практических рекомендаций:** - **Вести чётко и структурированно.** Дейли — не место для долгих обсуждений. Статус, блокеры, нужна ли помощь. И уже потом всё остальное. - **Не снижать эффективность команды.** Дейлик должен помогать работе, а не мешать ей. Если после каждого дейлика людям нужно полчаса, чтобы вернуться в контекст — что-то идёт не так. - **Задавать наводящие вопросы.** Особенно тем, кто ведёт себя неуверенно или отвечает расплывчато. Не чтобы подловить, а чтобы помочь сформулировать проблему. - **Не углубляться в детали.** Их можно будет обсудить потом, а на самой встрече — только то, что важно команде. - **Добиваться коммитментов.** Чем чаще люди дают конкретные обещания, тем больше их будет выполнено, и тем проще работать. ## Главное Дейли — не отчёт перед начальством. Это синхронизация команды. Место, где люди получают помощь, а не порицание. Если шаблонные ответы стали нормой, проблема в атмосфере. Люди закрываются и начинают «заливать», когда им небезопасно говорить правду. Создайте среду, где признать проблему выгоднее, чем её скрывать, где команда поддерживает, а не наказывает. Тогда будут проходить эффективно и без замалчивания проблем.