Scope IT-проекта. Управление и приоритизация

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

Scope проекта. Что это и почему важно

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

Как определить scope работ

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

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

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

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

Что это означает на практике 

Обратимся к нашему примеру из прошлой статьи цикла. Система управления заявками на услуги компании. 

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

В рамках проработки каналов взаимодействия продукта и пользователей мы определяем три канала:

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

При этом обращаем внимание на факторы:

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

Задача, которая стоит перед нами. Разработать функциональность для двух каналов: web и mobile.

Стоимость и срок (все значения условные). Стоимость web-разработки — 1 000 рублей, стоимость mobile-разработки — 700 рублей * 2 операционные системы (iOS, Android) = 1400 рублей.

Срок разработки — 1 месяц.

Наши варианты. Оцениваем несколько решений для уравновешивания проектного треугольника:

1. Увеличить срок разработки при сохранении стоимости и функциональности.
2. Упростить или сократить функции.
3. Увеличить количество ресурсов на выполнение задачи, а значит увеличить стоимость.

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

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

Следующим этапом определяем приоритеты в разработке мобильного приложения и web-продукта.  

Как мы приоритизируем. Изучаем тех, кто будет пользоваться продуктом. В основном это офисные сотрудники, которые находятся за рабочим компьютером 8 часов в день. Принимаем решение убрать мобильное приложение на этом этапе, потому что web-версия полностью удовлетворяет потребностям целевой аудитории (если бы это были полевые сотрудники, например, менеджеры по продажам, то было бы правильнее выбрать мобильное приложение). В результате грамотной приоритизации мы снизили стоимость разработки в два раза, а сотрудники получили необходимую функциональность. Также появилась возможность развивать систему на основе разработанных характеристик.

Итог

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

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