100+ клиентов рекомендуют нас

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

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

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

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

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

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

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

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

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

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

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-провайдера, перенос задачи в бэклог, завершение работы с овертаймом).

ИТОГ

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