Утро понедельника. Разработчик: «задачу закончу сегодня». Вторник: «нужно ещё два дня». Итого вместо одного дня — три. Или: «на эту задачу нужна минимум неделя». Проходит неделя и оказывается, что реальной работы там было дня на полтора, а остальное время ушло непонятно куда.
Почему так происходит: И как с этим работать? Пересказываем техтолк с Михаилом Колосовым (старший технический директор МСБ Газпромбанка) на ноябрьской TeamLead Conf 2025.
Когда человек перезакладывается
Когда разработчик называет срок с большим запасом, есть вероятность, что он просто не понимает объём задачи и страхуется. За эту неделю у него «много чего случится», и далеко не всё из этого будет продуктивной работой над задачей.
Что делать: остаться после дейлика и разобрать задачу по частям. Из чего именно складывается срок? Почти наверняка там найдётся возможность разбить работу на куски поменьше. Декомпозиция — лучший друг реалистичных оценок.
А ещё перезакладываются обычно те, кого раньше депремировали за сорванные сроки или публично ругали за ошибки. Человек защищается, и его можно понять. Если в команде за честную оценку прилетает по голове, люди склонны завышать сроки. Поэтому надо создать атмосферу, где честность безопаснее обмана. Человек должен чувствовать поддержку команды, а не угрозу и тогда ему будет просто незачем страховаться.
Срок, который озвучивает специалист — это его коммитмент перед командой. Если он команду ценит, то постарается своё обещание сдержать. А если видит, что срывает срок, то должен сказать об этом заранее. Это гораздо важнее, чем любой ценой уложиться в первоначальную оценку.
А команда — это место, где можно признать проблему и получить помощь. Не место, где тебя будут распекать за ошибки. Если дейлик превращается в судилище, люди начнут скрывать проблемы до последнего. А потом будет поздно что-то исправлять.
Вчера — сегодня, сегодня — завтра
Все как мы любим: срок с каждым днём уезжает все дальше и дальше.
Что случилось? Варианты:
- Изначально недооценил задачу;
- Наткнулся на подводные камни и не знает, как их обойти;
- Забил.
Как выяснить? Разобрать ситуацию прямо на дейлике. Но, опять же, не для публичной порки. А чтобы понять причину и помочь. Даже если это косяк самого человека, он не должен получить порицание. Он должен почувствовать понимание и поддержку.
Поменялось ТЗ
ТЗ меняется и будет меняться. Аналитики, например, склонны «вылизывать» документацию бесконечно, доводить до идеала. Это нормальная часть процесса. Но когда разработчик говорит: «Я не могу закончить, потому что ТЗ опять поменялось», — нужно выяснить, что именно изменилось.
Может оказаться, что изменения незначительные и вообще не влияют на его работу. А может, что правки аннулировали всё, что он делал последние две недели. Это разные ситуации, и реагировать на них нужно по-разному. Нужен анализ сразу после дейлика, по горячим следам.
Жду зависимость
«Я не могу закончить задачу, потому что Поликарп не сделал свою».
За этим может стоять цепочка проблем. Зависимости между задачами нужно было учесть заранее: на груминге, на планировании спринта. И вовлечены в это должны были быть не только исполнители, но и продакт, тимлид, аналитики.
Если такое происходит, то ошиблась вся команда, а не один человек. И если не лечить, это может стать хронической болезнью: зависимости будут систематически не учитываться, а задержки повторяться.
Поэтому на этапе планирования надо явно проговаривать зависимости и закладывать их в сроки. Очевидно, но почему-то регулярно забывается.
«Я такого не говорил»
Команда берёт задачи на спринт, а в конце говорит «мы не обещали это сделать». Протоколов совещаний нет, доказать ничего нельзя.
Тут дело в том, как люди воспринимают свой коммитмент. Когда команда берет задачи на планировании — она обещает честно заниматься этим всё отведённое время. Но не гарантирует результат. Это важное различие.
Что помогает: на дейликах регулярно уточнять — планирует ли человек довести историю до конца? Не «работаешь ли ты над задачей», а «закончишь ли к сроку». Дейлик должен протаскивать каждую историю вперёд, а не просто фиксировать статус.
Волки и кредит доверия
«Волки» — люди, которые работают на нескольких работах одновременно. Удалёнка это позволяет. Опытные, технически подкованные, с хорошо подвешенным языком. На одном дейлике такого не распознаешь.
Но есть инструмент — кредит доверия. Это шкала, которая растёт или падает со временем. Зависит от того, выполняет ли человек свои коммитменты. Раз сорвал срок — бывает. Два — настораживает. Три — явно что-то не так.
При этом если человек делает работу и не подводит команду, какая разница, волк он или нет? Главное — результат. Проблема не в том, что кто-то работает на двух работах. Проблема когда из-за этого страдает команда.
Разный язык
На дейли собираются люди с разными компетенциями. Продакты, аналитики, разработчики, тестировщики. То, что говорит продакт, разработчику может быть непонятно. И наоборот — технические детали для продакта звучат как птичий язык.
Если на дейлике не хватило времени синхронизироваться по терминам и пониманию, нужно остаться после него. Ведущий должен бронировать себе слот на такие случаи, желательно часовой. Для дип-дайвов в темы, которые прозвучали подозрительно или где люди явно не нашли общий язык.
Разработчик не обязан иметь подвешенный язык. Он должен хорошо знать инженерную часть. Иногда нужен медиатор, который переведет с технического на человеческий.
Как вести дейлики
Несколько практических рекомендаций:
- Вести чётко и структурированно. Дейли — не место для долгих обсуждений. Статус, блокеры, нужна ли помощь. И уже потом всё остальное.
- Не снижать эффективность команды. Дейлик должен помогать работе, а не мешать ей. Если после каждого дейлика людям нужно полчаса, чтобы вернуться в контекст — что-то идёт не так.
- Задавать наводящие вопросы. Особенно тем, кто ведёт себя неуверенно или отвечает расплывчато. Не чтобы подловить, а чтобы помочь сформулировать проблему.
- Не углубляться в детали. Их можно будет обсудить потом, а на самой встрече — только то, что важно команде.
- Добиваться коммитментов. Чем чаще люди дают конкретные обещания, тем больше их будет выполнено, и тем проще работать.
Главное
Дейли — не отчёт перед начальством. Это синхронизация команды. Место, где люди получают помощь, а не порицание.
Если шаблонные ответы стали нормой, проблема в атмосфере. Люди закрываются и начинают «заливать», когда им небезопасно говорить правду. Создайте среду, где признать проблему выгоднее, чем её скрывать, где команда поддерживает, а не наказывает. Тогда будут проходить эффективно и без замалчивания проблем.
Комментарии