Как научиться ставить сроки, которые приведут продукт к релизу? Рассказывает Дарья Осипова, менеджер проектов команды разработчиков сервиса для безопасного информационного пространства для детей MembranaKids.
Сколько бы менеджер проектов ни пытался предугадать, какие подводные камни ждут команду на пути к выпуску продукта, ему всё равно придётся корректировать курс по ходу дела. Лично у меня, например, не было ни одного проекта, в котором бы всё шло строго по плану, без отклонений от дедлайнов. Это данность — мы разрабатываем технически сложное решение. Изменение сроков неизбежно.
Вся правда о дедлайнах: магический треугольник
В идеальном мире дедлайн — это срок, к которому должна быть завершена отдельно взятая задача или проект в целом. На деле же реализация редко идёт по плану — особенно в ИТ, где каждый день происходит что-то новое.
Сдвиги сроков неизбежны. Нужно научиться правильно и эффективно работать с рисками, которые могут на них влиять, чтобы заранее предусмотреть возможные изменения и выстроить стратегию реагирования, которая поможет эффективно балансировать между основными составляющими проекта.
Для этого можно использовать проектный треугольник. Он позволяет наглядно объяснить заказчику, почему увеличение объёма работ, например, влечёт за собой увеличение стоимости и сроков проекта, и наоборот.
Суть проектного треугольника: качество любого проекта определяют три взаимосвязанных элемента — объём работы, отведённое на неё время и заложенные ресурсы.
Если представить эти составляющие в виде сторон одного треугольника, то любое изменение в их соотношении нарушит баланс фигуры и повлияет на конечный результат.
Это значит, что для балансировки проектного треугольника вслед за увеличением или уменьшением одной из сторон необходимо корректировать другие.
Если заказчику надо точно в срок: что делать?
На сдвиги влияют как приоритеты заказчика, так и общие риски ИТ-разработки.
В ИТ-сфере всё меняется каждый день, у нас довольно высокая степень неопределённости, возникают непредвиденные обстоятельства, которые непосредственно влияют на сроки выполнения работ. Но как поступить, если заказчик не хочет сдвигать дедлайн?
Для некоторых клиентов крайне важны сроки реализации, которые указаны в ТЗ или договоре, потому что они связаны с оформлением отчётности и бухгалтерской документации на этапе завершения проекта (актов приёмки, закрывающих документов и т. д.). Чтобы успеть в срок, можно привлечь к работе более квалифицированных специалистов (но при этом стоимость разработки, конечно же, повысится).
Случай № 1. Если качество важнее сроков
Иногда хороший результат клиенту важнее, чем соблюдение сроков. Ради качества он даже готов дать больше времени, чем было заложено изначально. В таких случаях менеджеры проектов могут выдохнуть и распределить задачи так, чтобы команда вела работу в комфортном для неё режиме: сдвинуть дедлайн на более позднюю дату.
Случай № 2. Обсуждали одно, а на деле оказалось другое
В ИТ-разработке нередки случаи, когда объём работ, который обсуждался на старте, внезапно увеличивается по ходу дела. Или сам продукт не имеет аналогов, поэтому разработчикам приходится тестировать гипотезы без возможности опереться на похожие проекты. Если ваша команда понимает, что не успевает к обозначенному сроку, лучше предупредить заказчика и сдвинуть дедлайн.
Случай № 3. Задерживают заказчики или партнёры
Бывает, заказчики или коллеги затягивают сроки и не предоставляют нужную информацию, документы или доступ вовремя. Например, с получением доступа в систему клиента такое происходит чуть ли не постоянно: чтобы внедрить продукт, нужно оформить допуски для сотрудников, а потом дождаться согласования со стороны руководства — на это тоже уходит время. Подобные задержки стоит учитывать при прогнозировании.
Когда меняются дедлайны?
Переоценка дедлайнов может произойти на любом этапе, например при переходе от пресейла к реализации проекта. Часто бывает так, что в предпродаже участвует команда, которая занимается исключительно оценкой трудозатрат. Потом проект передают другой команде, со своими исполнителями и, главное, техлидом, у которого может быть совершенно иное видение того, как выполнять работу и распределять обязанности.
Дедлайны могут сдвинуться на любом этапе разработки.
Определить загрузку команды на старте довольно сложно. Оценивая проект, мы можем предположить, что проблемы возникнут в одном процессе, а на деле окажется, что в совершенно другом. В итоге работа займёт гораздо больше времени, чем мы думали.
Как решают проблемы с дедлайнами во Future Crew
Мы — команда Центра инноваций МТС Future Crew, занимающаяся разработкой сервиса безопасного информационного пространства для детей Membrana Kids, с помощью которого родители могут контролировать активность своего ребёнка в интернете и ограничивать ему доступ к нежелательному контенту. Наш проект — технически сложный, над ним работает команда из 20 человек. В августе 2024-го наша разработка дошла до релиза — примерно за год.
Расскажем, что делать, чтобы всё успеть и не сорвать выпуск продукта. Две вещи:
1. Правильно планировать дедлайны.
2. Грамотно управлять рисками.
Главная задача — понять, что может пойти не так, и продумать, как сдвинуть сроки, не поступаясь качеством работы.
Планирование дедлайнов
Перед тем как поставить команде дедлайн, мы учитываем следующие факторы:
- Физические возможности сотрудников — оцениваем, насколько загружены члены команды на других проектах.
- Ожидания руководства — согласуем сроки и планы работ.
- Требования внутренних регламентов и процедур — учитываем время, которое должно уйти, например, на экспертизу качества, обязательную в МТС.
Управление рисками
…А чтобы подстраховаться и минимизировать риски, которые не получилось предвидеть на этапе планирования, мы используем два лайфхака.
Назначаем два дедлайна — один для заказчика, другой для команды
Неважно, кто занят на проекте: штатные сотрудники или подрядчики со стороны. Люфт между сроками помогает выиграть время в случае форс-мажора и закладывается в зависимости от типа задачи: например, две недели на завершение проекта, пять дней на согласование документации и наладочные работы.
Выносим часть задач на аутсорс
Некоторые участники команды могут работать на нескольких проектах параллельно. Конечно, успеть всё и сразу не получится, поэтому задачи нужно приоритизировать по степени срочности и важности. А для этого — оценить, чем сейчас занимаются исполнители, что потеряло свою актуальность, а что, наоборот, требует немедленного выполнения.
Если у участника команды высокая загрузка и он не успевает выполнить свою часть работы в срок, мы можем вынести её на аутсорс. Привлекая дополнительных специалистов, мы значительно ускоряем выполнение задачи. Но внимание: нужно учесть, что новому человеку понадобится некоторое время на погружение в процессы, — это раз, бюджет проекта должен такой фокус позволять, — это два.
Если дедлайны ставят, значит, это кому-нибудь нужно
Выходит, что ставить дедлайны, особенно в ИТ-разработке, бесполезно? Ведь их всё равно придётся пересматривать и подстраивать под внешние обстоятельства.
Ничего подобного: конкретные сроки помогают, хотя бы приблизительно, оценить время, через которое стоит ожидать результата, а ещё дают систему координат для команды и заказчика. Просто не нужно принимать их за непреложную величину, которая выбрана раз и навсегда.
А что делаете вы, когда приближается дедлайн, а проект ещё не готов? Принимаете неизбежность судьбы или изобретаете хитрую методику, которая поможет успеть в срок? Делитесь в комментариях.