Срыв сроков в команде: почему происходит, что с этим делать и как предупредить

Причины срывов можно условно делить на контролируемые и неконтролируемые. К последним относятся разного рода форс-мажорные обстоятельства, например, природные катаклизмы, забастовки и т. д. Они должны учитываться в реестре рисков. Это документ, в котором фиксируют возможные проблемы, оценивают вероятность их возникновения и планируют действия на случай, если что-то пойдет не так.

У крупного бизнеса, особенно в финтехе, своя специфика. Например, банки могут внезапно получить срочные задачи и запросы от регулятора. Из-за этого приходится перераспределять ресурсы в соответствии с новыми целями.

Срыв дедлайна почти всегда связан не с нехваткой времени, а с тем, что человек не умеет работать с самим собой. Он не прогнозирует нагрузку, например, делает в первую очередь интересные задачи, а не важные. Переоценивает себя, думает, что успеет «на таланте» и банально проседает по дисциплине.

В момент, когда надо напрячься, он не напрягается — потому что не хочется, устал или решил, что «и так норм». В итоге дедлайн срывается не внезапно, а постепенно — каждый день понемногу.

Еще одна группа причин, почему сотрудник не соблюдает сроки — он не умеет работать в команде. Это проявляется в том, что работник не синхронизируется с коллегами, не проясняет ожидания и не уточняет детали. А также не предупреждает заранее, что не успевает, и не договаривается о помощи или переносе задачи. Команда узнает о проблеме, когда уже поздно что-то исправить.

К причинам срыва дедлайнов я бы отнес: 

• Недостатки менеджмента. Плохой контроль сроков, плохое планирование, отсутствие управления проектами и сроками в целом, оценка сроков «на глаз». 
• Отсутствие нормальной ретроспективы. Если срывы происходят из проекта в проект, значит участники команды не учатся на прошлых ошибках.
• Неукомплектованность команды. Отсюда две проблемы: дефицит ресурсов и блокеры в задачах. Например, если в команде не хватает системных аналитиков, разработчики могут простаивать, потому что аналитики не успевают передавать техзадания на разработку.
• Неумение сокращать объем работ. Иногда команда не осознает, что в проекте запланировано слишком много задач. Нужно отказаться от выполнения той части, которая глобально не влияет на качество продукта — в IT мы называем это фичекат. Когда соблюдение дедлайна ставится выше полноценной идеальной реализации, и команда выкатывает не полный, но достаточный функционал.

Я очень люблю Agile и стараюсь применять его даже в своих задачах. Гибкие методологии дают нам эффективные инструменты оценки сроков (например, Poker planning), управления проектами (те же спринты), контроля состояния проекта (daily-митинги). 

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

Ранее упомянутые фичекаты я тоже часто вижу на практике, и это помогает эффективно справляться со срывами дедлайнов.

Также многое зависит от мотивации команды менеджером и атмосферы. Если сотрудники не ладят друг с другом, никакие технические меры не спасут. Мораль команды превыше всего.

Предварительный срок должен быть всегда с запасом. Я ставлю команде внутренний дедлайн раньше финальной даты сдачи. Это дает пространство для маневра: можно переделать результат, подключиться самому или в экстренном режиме заменить исполнителя. Когда запаса нет — любой сбой может сорвать проект.

Я использую регулярные короткие пинги по проекту. Каждый в команде отвечает на четыре вопроса:

• что уже сделано;
• какой результат есть сейчас;
• где возник затык;
• какая помощь нужна.

Это моментально показывает, кто работает, а кто откладывает все на последний день и надеется, что «как-нибудь рассосется». Обычно провожу такие встречи 1–2 раза в неделю на 5–15 минут.

Обязательна фиксация задач в системе, а не в голове.

Подойдет любая с карточками, где указаны задачи, сроки, ответственные, статус. Сейчас мы используем Яндекс Трекер, раньше был Trello.

Инструментов — сотни, суть одна: задачи должны быть на виду, зафиксированные и актуальные.

Поделюсь неожиданным советом, который сильно помогает мне в работе: даже если задача поставлена правильно, по SMART, и кажется, что ты все объяснил идеально — этого недостаточно. Самый полезный вопрос: «Что планируешь сделать?»

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

В Agile есть еще довольно прикольная вещь, которая называется kaizen — регулярное внедрение изменений. Это значит, что после каждого отрезка проекта мы проводим оценку и на ее основе внедряем ОДНО изменение в работу, которое сочтем наиболее важным. Таким образом команда из раза в раз совершенствует свою работу.

Стоит избавляться от перфекционизма и неадекватных оценок возможностей команды. В большинстве случаев нужно сделать не идеально, а достаточно хорошо. 

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

Классическая управленческая логика: учить, лечить, мочить. Этот подход сформулировал Максим Батырев в книге «45 татуировок менеджера». Схема работает и для себя, и для команды.

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

Дальше — понять, на какой стадии человек находится.

Учить. Это этап осознания. Через вопросы нужно выяснить:

• понимает ли человек, что дедлайн сорван;
• осознает ли причины;
• что он сам собирается с этим делать.

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

Лечить. Если осознание есть, но все по-прежнему, человек сам не справляется — включается «лечение». К сотруднику приставляют менеджера, который временно контролирует процесс и дедлайны. Ключевое слово — «временно». 

Это всегда ограниченный период с понятными правилами:

• бонусы за соблюдение сроков;
• санкции за факапы (например, без амбициозных проектов).

Цель лечения — не контроль ради контроля, а выработка устойчивого навыка. Мы «переставляем человеку ноги», пока он не поймет сам, как это делается и не начнет работать с контролем сроков самостоятельно.

Мочить. Когда человек не умеет договориться ни с собой, ни с командой, результат критичен для бизнеса или системы и микроменеджмент не помог — остается радикальный шаг. Увольнение, отказ от сотрудничества, выход из партнерства. Иллюзия, что «само наладится», почти всегда обходится дороже.

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

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

Лучше заранее организовать правильное планирование, управление командой, ее комплектацию, чем потом «тушить пожары».

По моему опыту не работают:

1. Мотивационные речи и разговоры «по душам». Попытки вдохновлять, объяснять важность проекта, апеллировать к ответственности и «ну ты же взрослый человек» — почти никогда не работают. Если человек системно срывает дедлайны, проблема не в мотивации, а в навыках, дисциплине или умении договариваться с собой и решать это следует так же — системно. Менять человека или его круг задач.
2. «Закручивания гаек» и жесткие сроки. Без промежуточных срезов и постановки задач по SMART сжатые дедлайны приведут к срыву проекта.
3. Надежда, что IT-инструменты помогут решить все проблемы. Инструменты усиливают систему и контроль, но не меняют голову. Приучать к современным средствам надо, но если нет дисциплины или IT-решение не нравится — надо менять или человека, или инструмент. Должно быть все легко и по кайфу, в мучении рождаются только муки.