Как учесть риски до запуска продукта или для чего нужна техническая оценка проекта?

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

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

ДЛЯ ЧЕГО ЭТО НУЖНО?

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

• прогнозирования и сокращения вероятных рисков;
• определения необходимого объема ресурсов;
• создания сценария потенциального результата.

КОГДА И КАК ПРОВОДИТСЯ ОЦЕНКА ПРОЕКТА?

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

Глобально возможности и сложности проекта оцениваются в два этапа:

1) До старта разработки команда приступает к сбору подробной информации у клиента о пожеланиях и планах: BRD (документ бизнес-требований), TRD (метод управления доступом), мокапы (макет продукта), дизайны:

• как должен выглядеть финальный продукт;
• какие цели он преследует;
• на кого ориентирован.

Зачем нам эти данные? С их помощью команда определяет объем работы, возможности и изменения, которые следует иметь в виду еще до старта проекта. Когда весь пакет документов собран, менеджеры внутри компании (с опытом разработки) переходят к следующему этапу. Специалисты создают высокоуровневый документ* с описанием задач и прогнозируемого времени на их выполнение.

2) В процессе разработки применяется более низкоуровневый подход* к оцениванию. Чаще всего метод встречается в гибкой разработке при работе со спринтами. Что из себя представляет этот анализ? По сути, это оценка тасок (задач) для заполнения бэклога (перечень задач, размещенных в порядке важности). Этим вопросом занимается разработчик перед началом работ. Если есть необходимость, к оценке подключаются другие разработчики и менеджеры для обсуждения нюансов.

* Подробнее про высокоуровневый и низкоуровневый подходы расскажу ниже.

ИЗ КАКИХ КРИТЕРИЕВ СКЛАДЫВАЕТСЯ УСПЕШНАЯ ОЦЕНКА ПРОЕКТА?

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

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

Технологии: передовые решения предлагаются как нашей командой, так и стороной клиента для поиска лучшего варианта.

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

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

КАКИЕ МЕТОДЫ И ИНСТРУМЕНТЫ ИСПОЛЬЗУЮТСЯ ПРИ ОЦЕНКЕ ПРОЕКТА?

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

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

Низкоуровневая оценка (анализ тасок — задач): вариантов методик и инструментов анализа проекта на этом этапе больше, чем на предыдущем. Это может быть как Planning Poker*, оценка сложности по Story Points*, так и экспертиза с привлечением нужного специалиста.

* Planning Poker — методика коллективного решения задач при разработке программного продукта.

* Story Points — единица измерения для оценки сложности задачи и общих усилий для ее закрытия.

МОЖЕТ ЛИ МЕНЯТЬСЯ ОЦЕНКА В ПРОЦЕССЕ РЕАЛИЗАЦИИ ПРОЕКТА?

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

К примеру: клиент создает магазин для продажи автозапчастей. Но спустя 3 месяца понимает, что его конкуренты, ко всему прочему, имеют еще и маркетплейс услуг по починке авто. И для создания приложения, которое вместе с продажей автозапчастей закроет еще и аналогичные потребности клиентов по ремонту машин, потребуется больше времени. То есть, если ранее на разработку продукта ушло бы X часов, то с новыми функциями уже 1.5 X.

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

1) Если разработка идет по Waterfall (модель каскадной разработки продукта) с твердыми BRD (документ бизнес-требований) и TRD (метод управления доступом) и фиксированной стоимостью, то внесение изменений в проект будет происходить после сдачи основной части продукта.

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

ЕСТЬ ЛИ ГАРАНТИИ ТОЧНОСТИ ОЦЕНКИ И ПРЕДОСТАВЛЯЕМ ЛИ МЫ ИХ?

Ответить однозначно тут вряд ли возможно. Все зависит от конкретного проекта и требований к нему. Но:

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

! Мы также не берем дополнительную оплату, если задача решается быстрее, чем было оценено в начале (актуально, если контракт заключен по типу Time & Material — почасовая модель оплаты).

К примеру: клиент попросил при разработке использовать определенный сервис для email-рассылки. На другом проекте команда решила аналогичную задачу за 8 часов. Поэтому оценка новой была установлена с таким же таймингом — ни больше ни меньше, а 8 часов. Однако при разработке оказалось, что новый сервис намного сложнее и не предоставляет удобных инструментов для интеграции. Решение в такой ситуации одно: доложить клиенту о сдвигах во времени и обсудить следующие возможные действия (смена email-провайдера, перенос задачи в бэклог, завершение работы с овертаймом).

ИТОГ

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