Техническая оценка проекта: зачем проводится и как влияет на конечную стоимость продукта?
Как избежать существенных рисков и не выйти за рамки бюджета? Над этим ломает голову каждый владелец бизнеса перед запуском нового продукта. Решение есть, и оно довольно стандартное — заблаговременно провести анализ. В этой статье я расскажу, как осуществляется оценка проекта технической командой, и что это дает бизнесу.
ЧТО ПОНИМАЕТСЯ ПОД “ОЦЕНКОЙ ПРОЕКТА”?
Оценка проекта равносильна прогнозу, который проводится на разных этапах от начала до конца, чтобы учесть все подводные камни, встречающиеся на пути создания продукта.
ЗАЧЕМ ПРОВОДИТЬ ОЦЕНКУ?
Оценка проекта измеряет потенциальную успешность/провал — результативность идеи. Помогает понять, когда нужно применять дополнительные инструменты и какие функции для этого необходимо предусмотреть. Дает представление о масштабах затраченных сил, часах и финансовых вложениях, которые потребуются при создании цифрового продукта: приложения, сайта или решения для автоматизации бизнес-процессов. Все ради того, чтобы конечный продукт полностью соответствовал ожиданиям заказчика и не разочаровал будущих пользователей.
Предварительное прогнозирование, прежде всего, закрывает три основных проблемы на проекте:
- сокращает возможные риски;
- определяет объем необходимого бюджета и иных ресурсов;
- создает наглядные сценарии ожидаемого результата.
ИЗ КАКИХ ЭТАПОВ СОСТОИТ ОЦЕНКА ПРОЕКТА?
Проводить оценку проекта полезно на каждом этапе разработки. Это будет держать команду в тонусе, а клиента в курсе процессов. По-хорошему, от задумки о необходимости реализации продукта до воплощения ее в жизнь нужно проводить мониторинг на постоянной основе.
Во Fusion Tech мы разделяем оценку проекта на две фазы:
1) Перед началом разработки собираем обратную связь от клиента: что он хочет видеть, каким он представляет себе конечный продукт, какие боли этот продукт должен закрывать у пользователей, кто его целевая аудитория. Чем больше сведений, тем более подробным и ясным выглядит техническое задание, что дает возможность команде определиться с объемом планируемых работ/потенциалом, спрогнозировать возможные риски и учесть предварительные изменения. На основе этого специалисты уже создают детально описанный документ с развернутым описанием задач и точным временем на их решение.
2) Когда данные получены и изучены всеми членами команды, приступаем к следующему этапу оценивания. Это аналитика в рамках работы со спринтами. Каждая задача оценивается и размещается в порядке важности. Кто проводит такой мозговой штурм? Непосредственную оценку задач осуществляет разработчик, который является главным действующим лицом на проекте. К процессу также могут подключаться другие программисты или менеджеры, чтобы общими усилиями учесть все мельчайшие нюансы.
КРИТЕРИИ УСПЕШНОЙ ОЦЕНКИ ПРОЕКТА:
- команда;
- продукт;
- технологии;
- доступная информация.
Команда: компетентные сотрудники решат задачу быстрее и качественнее — неоспоримый факт.
Продукт: стандартная задача, знакомая команде по предыдущим проектам, будет оценена быстрее.
Технологии: технические решения инициируются стороной заказчика и могут корректироваться командой исполнителя для лучшего результата.
Доступная информация: если заказчик не предоставляет никаких предварительных данных (описание бизнес-процессов, формул и алгоритмов) провести оценку будет затруднительно.
МЕТОДЫ И ИНСТРУМЕНТЫ ОЦЕНКИ ПРОЕКТА
Методик оценки проекта придумано немало. В зависимости от подхода используется та или иная техника. Но сразу оговорюсь, что идеального подхода, чтобы учесть все и вся, пожалуй, нет. Во Fusion Tech мы стараемся проводить анализ по двум параметрам:
- высокоуровневая оценка;
- низкоуровневая оценка.
При высокоуровневой оценке команда применяет трехточечную технику. На этом этапе мы анализируем проект по экранам и функциональностям, сравниваем его с аналогичными продуктами, над созданием которых трудились ранее. Конечным итогом становится разработка внушительного документа, где оценен каждый компонент и каждая отдельно взятая функция (API эндпоинт, email-письмо, форма). Глубокий анализ дает представление о том, что следует реализовать в первую очередь, что после, а от чего можно отказаться совсем. Более точно планируется и время, которое будет затрачено на разработку.
При низкоуровневой оценке количество инструментов и методик на порядок выше, чем на предыдущем этапе. На этой стадии уже производится анализ задач. Как провести эту оценку, чтобы получить более точный результат? Мы прибегаем к таким техникам, как Planning Poker или оценка сложности по Story Points. Planning Poker — это инструмент для коллективного решения задач при создании цифрового продукта. В то время как Story Points представляет собой величину измерения для анализа сложности задач и определения количества усилий, необходимых для их решения.
ИЗМЕНЕНИЕ ОЦЕНКИ ПРОЕКТА В ХОДЕ РАЗРАБОТКИ
Неправильно думать, что предварительный анализ, как и последующие, дадут стопроцентный результат без малейших отклонений в ту или иную сторону. Как показывает практика, в ходе реализации проекта оценка неизбежно будет корректироваться. Создание абсолютно нового продукта, даже в сравнении с аналогичным, имеет свои особенности (двух одинаковых решений практически не бывает). По мере разработки продукт также может приобретать и дополнительные функции, о которых ранее не шел разговор.
Например: заказчик пришел с пожеланием разработать сайт, предоставляющий услуги грумера. Команда приступила к выполнению задачи. Но через время условия технического задания поменялись. Как выяснил заказчик, конкуренты, кроме грумерских услуг, развернули на своем ресурсе полноценный интернет-магазин по продаже товаров для ухода за шерстью животных. Чтобы воплотить то же самое на сайте заказчика, необходимо увеличить сроки реализации проекта. И получается, что предварительная оценка окажется неверной, так как не учтены пожелания, которые родились уже в процессе.
Какое решение можно предложить в этом случае? Все зависит от того, по какому пути изначально шла разработка:
- Путь 1: создание продукта по Waterfall (модель каскадной разработки) с устойчивыми BRD (документ бизнес-требований) и TRD (метод управления доступом), а также фиксированной оплатой. Тогда все корректировки будут возможны после согласования основной части проекта.
- Путь 2: создание продукта по Agile (гибкий сценарий) дает шанс внести изменения еще в процессе разработки, до финальной сдачи продукта. Недостатком для клиента является невозможность заранее узнать конечную стоимость проекта.
Примеры показывают, что точность оценки проекта зависит от отдельно взятого продукта и персональных требований к нему. Тем не менее подрядчик, который дорожит своей репутацией и клиентами:
- Даст гарантии, что бюджет не будет увеличен без предварительного согласования с клиентом.
Не будет брать дополнительную оплату, если проект реализуется быстрее, чем было оговорено на старте (применимо только к контрактам с почасовой оплатой).
Например: заказчик хочет интегрировать в продукт конкретный сервис для рассылки сообщений пользователям. Команда уже сталкивалась с похожей задачей на предыдущем проекте. Работа по интеграции заняла тогда n-ое количество времени. Значит, столько же часов потребуется для решения этой задачи на новом проекте. Они закладываются в оценку. Но на деле оказывается, что не все так просто. В ходе работы выяснилось, что предложенный сервис сложнее и не имеет гибких инструментов для свободной интеграции. Что делать в этой ситуации?
- Путь 1: обозначить проблему перед клиентом, уведомить о возможных сдвигах в сроках и предложить варианты решения проблемы (поменять сервис на более гибкий, перенести задачи в бэклог (список задач), чтобы вернуться к ней позже, завершить работу с овертаймом).
ФИНАЛЬНАЯ ЧАСТЬ
Преуменьшать значение предварительного анализа нельзя. В оценку могут не войти отдельные элементы, которые генерируются в процессе воплощения задумки. Но общее представление, вектор, куда движется проект, и какой получится на выходе продукт, можно получить только путем предварительных прогнозов и мониторинга первичных идей.
Новости из мира IT-технологий, о трендах индустрии, бизнес-сервисах и не только — в ТГ-канале или на сайте Fusion Tech.
Читайте также:
По какой модели сотрудничать с IT-подрядчиком? Перед любым заказчиком неизбежно встает этот вопрос и дилемма: как не потерять деньги, уложиться в сроки и презентовать потребителям качественный продукт. В этой статье я расскажу о популярных методах сотрудничества в сфере IT, какому бизнесу подойдет тот или иной контракт и почему именно он.