Как учесть риски до запуска продукта или для чего нужна техническая оценка проекта?
Прежде чем начать проект, любой бизнес хочет узнать, сколько ему придется заплатить, что он получит и в какие сроки. Ответы на эти вопросы дают четкое представление о том, стоит ли игра свеч. Как проводится оценка проекта, из каких складывается критериев и какие гарантии дает заказчику, я расскажу в этой статье.
Оценка проекта — это прогноз затраченных сил, времени и бюджета на разработку решения/продукта (сайта или приложения).
ДЛЯ ЧЕГО ЭТО НУЖНО?
Начнем с того, что анализ продукта — это фундамент или основа, на котором создается и держится весь будущий каркас. От его “прочности” зависит, как быстро проект будет реализован, сколько будет затрачено ресурсов, и совпадут ли в итоге ожидание и реальность. Поэтому преуменьшать важность оценки на каждом отрезке создания продукта нельзя. Она способствует более четкому организационному процессу и скорейшему выходу проекта в свет без сюрпризов. Клиент получает именно то, что запланировано с конкретными сроками и размерами бюджета. А все потому, что оценка проекта дает возможности для:
- прогнозирования и сокращения вероятных рисков;
- определения необходимого объема ресурсов;
- создания сценария потенциального результата.
КОГДА И КАК ПРОВОДИТСЯ ОЦЕНКА ПРОЕКТА?
Проводить анализ проекта следует тогда, когда бизнесу требуется дополнительная информация для планирования. То есть практически на каждом этапе реализации продукта: когда идею только обсудили, а лучше — изложили в техническом задании, ее следует проанализировать и просчитать все возможные риски, оптимистичные и пессимистичные перспективы развития сюжета.
Глобально возможности и сложности проекта оцениваются в два этапа:
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-провайдера, перенос задачи в бэклог, завершение работы с овертаймом).
ИТОГ
Проект без предварительной оценки, как корабль без маяка: плыть может, но как долго продержится среди быстро растущей конкуренции и доплывет ли в итоге до цели — вопрос риторический. Но есть сомнения, что результат такого путешествия порадует клиента.
Новости из мира IT-технологий, о трендах индустрии, бизнес-сервисах и не только — в ТГ-канале или на сайте Fusion Tech.
Читайте также:
Кто хоть раз сталкивался с заказной разработкой, становился перед выбором: по какому договору сотрудничать с IT-подрядчиком. Остановиться на фиксированной оплате или почасовой? Что выгоднее для бизнеса? В этой статье вы найдете ответы на эти и другие вопросы, чтобы реализовать ваш продукт с минимальными затратами.