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

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

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

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

1. Получаем вводные данные A.
2. Если данные соответствуют условию B, переходим на последовательность действий C;
3. Если данные соответствуют условию D, выполняем действия E.
4. Полученный результат передается на выход.

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

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

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

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

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

1. Ошибки при оценке задач
2. Ошибки при управлении изменениями
3. Проблемы в коммуникации и ожиданиях
4. Ошибки при подготовке к проекту
5. Недостаточная компетенция исполнителя
6. Демотивация команды

1. Ошибки при оценке задач

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

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

1. Ожидание, что на проекте не будет проблем. Все пойдет по плану.
2. Пренебрежение оценкой на выполнение аналогичных задач.
3. Не учитывает ограничения проекта.
4. Ожидание, что этот проект будет проще.

Как давать реалистичную оценку

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

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

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

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

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

Итоговая оценка = ((O + (3 × R) + P)) / 6

где,

О — оптимистичная оценка, если все идет по плану.

P — пессимистичная оценка, если все идет не по плану.

R — реалистичная оценка, среднее значение.

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

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

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

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

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

Резервы = P х I, где

P — вероятность в процентах,

I — влияние в часах или в деньгах

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

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

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

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

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

2. Ошибки при управлении изменениями

Управление изменениями — это методология, которая помогает управлять запросами на изменение проекта.

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

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

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

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

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

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

3. Проблемы в коммуникации и ожиданиях

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

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

Как правильно сообщить об ожиданиях

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

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

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

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

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

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

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

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

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

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

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

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

1. Напомните сотрудникам о дедлайне.
2. Дополнительная обратной связь

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

4. Ошибки при подготовке к проекту

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

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

1. Человеческие ресурсы. Убедитесь, что у членов вашей команды достаточно знаний, навыков и опыта для выполнения своих задач. Также сотрудники могут заболеть, уйти в отпуск или даже покинуть команду.
2. Финансовые ресурсы. Оцените и распределите их на самом раннем этапе разработки. Для контроля пользуйтесь инструментом, который будет отслеживать затраты с использованием почасовых ставок.
3. Материальные ресурсы. Включают в себя сервера, программное обеспечение. документацию. Задача менеджера — получить их в нужном количестве и в нужное время.
4. Время. Постройте график проекта. Отслеживайте время для анализа производительности команды, контрольных точек и планирования работ.

5. Недостаточная компетенция исполнителей

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

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

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

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

1. Заложите больше часов на задачу. Во многих случаях, задача решаема, если выделить на нее больше времени.
2. Возьмите консультацию у senior-специалиста. Как показывает практика при поддержке опытного наставник junior-специалист выполняет задачу на уровне «middle».
3. Проведите обучение. Если сотрудник не обладает технологией, а заменить исполнителя уже нельзя. В этом случае разработайте программу обучения и внедрите ее в регулярный план работ. В короткой перспективе это замедлит проект, но к середине проекта вы заметите рост производительности

6. Демотивация команды

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

Персональная демотивация

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

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

— Мне хотелось бы попробовать новые технологии на этом проекте. Я считаю, что мы слишком долго используем 1С-Битрикс, пора переходить на node.js.

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

— Скучно, я уже такое делал. Знаю точно, что справлюсь. Хочется чего-то другого.

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

— Все хорошо, мне все нравится. Важно, чтобы не было срывов сроков. И не приходилось задерживаться.

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

Командная демотивация

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

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

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

1. Поделите вашу работу на спринты.
2. Планируйте объем работ на каждый спринт
3. Подводите итоги спринта,
4. Следите за тем успеваете ли вы в срок

Итог кратко

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

1. Ошибки при оценке задач
2. Ошибки при управлении изменениями
3. Проблемы в коммуникации и ожиданиях
4. Ошибки при подготовке к проекту
5. Недостаточная компетенция исполнителя
6. Демотивация команды

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

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

1. Наш канал в telegram.
2. Кейсы команды Alto