Как управлять IT-проектом: сроки, бюджет и скоуп

Эту статью мы написали вместе с Полиной Скалуновой, marketing project manager.

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

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

Сложность: легкая

Время на чтение: 15 минут

Что такое проектный треугольник

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

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

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

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

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

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

Скоуп

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

Для приложения с подборкой капсульного гардероба UX/UI-дизайнеры отрисовывают экраны с коллекциями одежды и личным кабинетом пользователя. Разработчики должны реализовать фичи с возможностью добавить товар в корзину и оформить заказ, заполнив анкету.

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

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

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

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

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

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

Проджект может столкнуться с разными ситуациями, в которых скоуп придется менять. Вот три примера.

Рассмотрим эти примеры подробнее.

Заказчик пришел с новой идеей. Если заказчик решает усложнить проект и добавить новую фичу, это увеличит скоуп.

Вы понимаете, что столкнулись с этой ситуацией. Но теперь вы знаете, что нельзя просто так добавить в спринт работу над новой фичей — 3D-примеркой.

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

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

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

Елена Горопека, бизнес-аналитик, продукт-менеджер и автор телеграм-канала О бизнес-анализе и не только, поделилась советами по управлению скоупом. 1. Сначала задайте вопрос «Зачем?» Любое обсуждение изменений скоупа должно начаться с определения целей. Зачем мы хотим добавить новую фичу? Улучшения какой метрики ожидаем? Как эта фича поможет в достижении бизнес-цели проекта? Эти моменты уточняются у заказчика. Еще до старта проекта нужно выяснить его бизнес-требования. Часто заказчики сами о них забывают в процессе проектной работы. Из-за этого могут попросить добавить фичи, которые не увеличат ценность проекта, а только «раздуют» скоуп. Поэтому проджект поможет и команде, и заказчику, если вовремя проверит, точно ли новая фича соотносится с бизнес-целью. 2. Не жалейте времени на поиск оптимальной реализации Если фича действительно важна, проджекту следует донести до команды, почему это так. Этот шаг не следует пропускать, он поможет в брейншторме вариантов реализации фичи. Ни проджект, ни заказчик не придумают решение лучше, чем кросс-функциональная команда. Через обсуждение и отметание разных идей вы придете к оптимальному решению — тому, которое соответствует бизнес-цели и легко реализуется.

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

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

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

Бюджет

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

Порядок оплаты прописывается в договоре с заказчиком. Договора бывают трех типов: Fixed price, Time and Material и Dedicated team.

При договорах Fixed price и Dedicated team бюджет зафиксирован на старте проекта. Проджекту нужно контролировать, чтобы расходы не вышли за его рамки.

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

Вы прервали чтение заметок Оливии и задумались. Команда работает над приложением по договору Fixed price. Проект близится к завершению, поэтому бюджет расписан. Скорее всего, работа над новой фичей потребует дополнительных затрат.

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

Время

В задачи проджекта входит следить за сроками проекта, оценивать их и при необходимости сокращать.

Отслеживать сроки можно двумя методами: burndown chart и методом критического пути. 

Burndown chart подходит для отслеживания сроков. Это диаграмма, через которую можно увидеть, сколько стори поинтов команда выполняет в каждом спринте и как это число меняется от спринта к спринту. С помощью диаграммы можно прогнозировать срок завершения проекта.

Диаграмму можно построить самостоятельно в Excel или воспользоваться встроенными виджетами в таск-менеджерах, например, в ClickUp.

Burndown chart следует обновлять после каждого спринта. Тогда будет видно, на каком этапе находится проект, сколько задач сделано и сколько времени нужно до релиза. 

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

Для расчета критического пути сначала нужно создать сетевой график и определить последовательность задач. Потом решить, что нужно выполнять последовательно, а чем можно заниматься параллельно. Например, пока разработчики делают первую фичу, UI-дизайнер работает над второй. Когда разработчики приступают ко второй фиче, команда QA начинает тестировать первую.

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

Артем Летюшев, менеджер-аналитик Юмани и автор телеграм-канала Junior PM, рассказал о других способах управлять сроками проекта: Метод контрольных точек. Из скоупа проекта выделяются ожидаемые результаты работ на фиксированные даты и контролируется их достижение. Здесь помогут правила 20/80 и любые другие, например, 10/40/50. Fever chart. Способ относится к теории ограничений систем. В начале проекта необходимо заложить буфер. Можно сделать это, например, с помощью метода критической цепи. Критическая цепь, скорее всего, будет построена по одному из критических путей, но при этом предполагает более точное и продолжительное планирование. Далее строится график расхода буфера и отслеживается прогресс по нему — это просто и эффективно. Визуальный анализ. Ход проекта визуализируется, например, с помощью диаграммы Ганта. Это помогает наглядно оценивать, сколько времени осталось до завершения работы. Метод освоенного объема. Для оценки эффективности работы над проектом рассчитывается ряд показателей таких, как: PV — плановый объем, AC — фактическая стоимость выполненных работ, EV — освоенный объем и другие. По этим показателям строятся графики, отслеживается и сравнивается с первоначальным планом точка завершения проекта. Чтобы пользоваться методом, нужно научиться анализировать значения показателей. Например, почему SP > 0 — это значит, что проект обгоняет расписание.

Вы прочитали конспекты Оливии и узнали о вершинах проектного треугольника.

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

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

Вы гуглите материалы о проектной звезде.

Что такое проектная звезда

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

Риски 

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

Риски могут быть внешними и внутренними.

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

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

Подробнее о том, как выявлять и оценивать риски и какие стратегии управления эффективны для этого, вы найдете в статье о рисках проекта.

Качество

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

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

Упростить фичу и отказаться от части требований. Заказчик хотел, чтобы в 3D-примерке пользователь смог посмотреть, как одежда выглядит на нем в разных ракурсах. Один из вариантов упростить фичу — отказаться от трекинга 3D-объекта. То есть пользователь сможет примерить одежду, только находясь в неподвижном положении. Разработка упрощенной фичи займет меньше времени и команда сможет сдать проект в срок.

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

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

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

Ресурсы

Ресурсы проекта — это материалы, оборудование и люди. Распределять нагрузку команды можно с помощью диаграммы Ганта. Есть специальные плагины Jira для создания диаграмм Ганта, например, BigGantt. Подобные плагины позволяют эстимировать задачи, назначать исполнителей и следить за количеством рабочих часов.

Сократить сроки работы над проектом через ресурсы можно двумя способами.

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

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

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

Резюмируем

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

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