Почему ваша команда срывает сроки проекта? 6 методов решить проблему

В этой статье расскажем как команда Alto справляется со срывами сроков. Материал будет полезен руководителям, менеджерам проектов и всем, кто испытывает трудности с соблюдением дедлайнов.

Согласно исследованию компании Hewlett-Packard 96% IT-проектов в России завершаются не вовремя. Это одни из самых низких показателей в Европе. В то время как в Швеции этот показатель равен 64%. Когда такое количество проектов срываются по срокам, вы начинаете искать решение этой проблемы.

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

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

Здесь сотрудник следует четко определенному алгоритму. За него уже предусмотрены основные варианты и способы их решения..

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

Мы в Alto еще не нашли волшебную таблетку для решения этой проблемы. Скорее всего её и не существует. Как и нет в мире такой компании, где все проекты заканчивают вовремя. Проектная работа — это хаос. Поэтому все что нужно — это понять, как работать среди этого.

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

Причины по которым команды срывает сроки:

Человеку свойственно быть оптимистичным при оценке задач. Даже если эта оценка основана на прошлом опыте. Например, если последняя задача заняла 24 часа. Сотрудник подумает, что в этот раз сможет сделать аналогичную задачу за 22 часа. Опираясь на идею, что теперь у него больше знаний и опыта. На практике этот оптимизм часто приводит к срыву срока.

Причины оптимистичны оптимистичной оценки включают:

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

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

Метод 1. Оценка по трем точкам

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

Для оценки по трем точкам есть формула:

Метод 2. Декомпозиция.

Этот подход требует, чтобы вы оценивали каждую отдельную задачу, а затем объединяли в общую оценку. Главное преимущество декомпозиции в том, что она укрепляет уверенность сотрудника в сроках.

Метод 3. Создание резервов.

Есть два вида резервов: деньги и время. Постарайтесь создать резервы для всех известных рисков. . Так вы учтете возможные проблемы на проекте и повысите вероятность выполнения проекта в срок.

Есть несложная формула, как рассчитать резервы.

Рассмотрим на примере. Представьте, что у вас на проекте есть риск того, что заказчик затянет согласование дизайна. Вы анализируете, какое влияние имеет этот риск. Допустим, на согласование уходит 3 дня. Вероятность, что заказчик затянет согласование – 30%. Это ваша экспертная оценка, которая опирается на ваш опыт. Если это случится, тогда повышается вероятность сорвать сроки. Используя формулу, получаем:

Резерв = 30% х 72 часа = 21,6 часа

Получается, что на этот риск можно заложить 22 часа.

Допустим, что риск сработал, заказчик задержал согласование на неделю, а мы отложили только 22 часа. Для этой ситуации у нас есть другие резервы. Все риски сразу никогда не сработают. Сработает только часть, а другая останется. Заложенные на них резервы останутся. Поэтому берем резервы с тех рисков, которые не сработали.

Именно поэтому рисков должно быть много — хотя бы 20. Если у вас будет 2-3 риска, то резервов не хватит, чтобы все компенсировать.

Каждый кто работал с digital-проектами сталкивался с ситуацией, когда клиент просит внести незапланированные правки. При этом аргументируя это тем, что здесь работы на 10 минут. В итоге таких правок за время проекта может быть сотни. Как результат этого — просроченный дедлайн.

Решение проблемы:

Проговорите какой объем изменений на проекте возможен. Например, определите количество итераций дизайна или допустимое отклонение по часам без изменения срока.

Убедитесь, что клиент понимает, как это будет выглядеть на практике. Для этого объясняйте на примерах, а также фиксируйте все в договоре. А именно пропишите количество дополнительных правок, которые доступны клиенту. Обычно хватает 2-3 итерации правок.

Это значит, что клиент должен собрать как можно больше правок при каждой итерации. Например, в первом письме попросил изменить цвет кнопок, а через 4 дня прислал еще письмо с правками для карточки товара. В этом случае это будут две разные итерации правок.

Все что клиенту нужно сделать, так это собрать все эти правки в одном письме. Только тогда это считается одним циклом правок. Поэтому объясните клиенту, что их письма с правками должны быть как можно более объемными..

Представьте себе следующий разговор с программистом:

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

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

Вот три способа как можно проверить, что ваша команда понимает свои сроки.

Способ 1. Используйте сервисы для управления проектами

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

Именно поэтому рекомендуем вести все задачи в сервисе для управления проектами.

Мы в Alto используем Trello. Она интуитивно понятная и при определенных настройках позволяет фиксировать время на задачу, показывать отчеты.

Способ 2. Получите обратную связь

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

Давайте пересмотрим приведенном выше диалог с учетом этого способа.

В итоге вы бы сразу узнали об этом до того, как сроки будут сорваны.

Способ 3. Внедрите периодические проверки

Добавьте периодические проверки в свой график. Так вы достигнете двух целей:

Это поможет вам выявить потенциально слабые места и не прибегать к микро-управлению вашей командой.

Любой проект требует ресурсов. В каскадных проекта их необходимо планировать и распределять до начала проекта. В Agile-проектах управление ресурсами происходит на каждом цикле разработки: Независимо от проекта задача руководителя будет одна — определить, какие ресурсы потребуются и какого качества они должны быть.

Давайте рассмотрим, какие могут быть ресурсы проекта.

По данным отчета The Boston Consulting Group (BCG) почти 45% сотрудников в России не соответствуют занимаемой ими должности. В США этот показатель равен 33,5%, а в Германии — 37,2%.

Задача руководителя в этой ситуации — подбирать специалистов соразмерно задаче или наоборот. То есть менеджер должен сопоставить сложность проекта и возможности исполнителя.

Что делать если сотруднику не хватает компетенций:

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

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

Давай разберем несколько ситуаций

Здесь можно найти решение если рассмотреть несколько смысловых слоев. На первом человек говорит про Битрикс и Node.js. На втором смысловом слое — хочет попробовать новое. Поэтому если хотите замотивировать этого сотрудника — дайте возможность сделать что-нибудь новое. Если такой возможности нет — создайте. Придумайте небольшой проект, где такая возможность появится

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

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

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

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

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

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

Если вы научитесь их предсказывать — это 95% успеха. Остальные 5% — это внешние обстоятельства, на которые мы не всегда можем повлиять.

Напоследок оставим несколько полезных ссылок:

Последние публикации: