Как сделать предварительную оценку ИТ-проекта эффективной

В начале работы над ИТ-проектом, как правило, проводят оценку. Её отсутствие или неточность может сформировать неправильные ожидания по срокам и бюджету проекта.

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

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

Актуальные методы оценки ИТ-проекта

Выбор метода оценки будет зависеть от того, нужно ли реально оценить трудозатраты по проекту или просто определить потенциал клиента и соотнести с предполагаемыми затратами.

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

Для более детальной оценки трудозатрат в большинстве ИТ-проектов подходит метод по фичам. Мы чаще всего используем именно его. При таком способе проект декомпозируется, разбивается на фичи. Затем они описываются и оцениваются отдельно пресейлом каждого направления. Это позволяет увидеть, сколько времени на конкретную фичу потратит аналитик, дизайнер, фронт, бэк, QA и т.д. Далее вся информация сводится в единый список.

По нашему мнению, такой подход позволяет учесть все необходимые работы и подобрать оптимальный состав команды специалистов. Сроки выполнения предварительной оценки методом по фичам зависят от особенностей проекта: для стандартного приложения – до 8 часов при условии одновременного проведения оценки всеми экспертами сразу. Но в этом процессе могут участвовать специалисты нескольких направлений, поэтому в среднем предварительная оценка занимает 3-5 дней.

Есть два общепринятых варианта подсчета трудозатрат:

1. диапазонный метод (от X до Y часов), когда оценщик на основании своего опыта дает пессимистические и оптимистические данные по трудозатратам на фичу,
2. метод PERT – расчет выполняется по трем точкам:

где t_o – оптимистическое время – минимально возможная длительность выполнения задачи,
t_p – пессимистическое время – максимально возможная длительность выполнения задачи,
t_m – наиболее вероятное время – наиболее вероятная длительность выполнения задачи,
t_e – ожидаемое время – оценка длительности выполнения задачи на основе оценок оптимистического, пессимистического и наиболее вероятного времени.

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

Как проходит предварительная оценка

Отправляя заявку в ИТ-компанию, заказчик обычно преследует одну из целей:

1. Просит оценить проект «под ключ». У него может быть определен объем задач и разработано техническое задание (ТЗ) или только объем задач без ТЗ.
2. Хочет узнать, что можно сделать в рамках определенного бюджета или в конкретные сроки.

Рассмотрим, как проходит процесс предварительной оценки ИТ-проекта. Расскажем на примере нашей компании.

Этап № 1 – обсуждение проекта и потребностей клиента

Чтобы выяснить все детали по проекту, специалист компании (обычно сотрудник отдела продаж) организует созвон с клиентом. Один из способов получить необходимые для предварительной оценки данные – вместе с клиентом заполнить бриф и ответить на ключевые вопросы о будущем ИТ-продукте. Основными из них мы поделимся в чек-листе в конце статьи. Но обычно беседа с клиентом проходит в свободной форме. Это позволяет выявить действительно важные для него и его бизнеса аспекты.

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

На этом этапе формируются ответы на ключевые вопросы:

• Границы разработки – какие этапы работы нам нужно оценить (и в перспективе выполнить), а какие клиент берет на себя?
• Какие направления разработки стоит подключить к оценке?
• Какой стек будет предпочтителен?
• Что еще нужно заложить в оценку? Например, клиент решает, что дизайн будет разрабатывать сам. Значит, в оценку нужно включить время на приемку дизайна заказчика – проверить, соответствует ли дизайн функционалу системы.

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

Бывают случаи, когда у клиента есть просто идея, и данных для формирования технической концепции недостаточно. В таких ситуациях мы предлагаем заказчику начать проект с мини-аналитики, т.е. провести «дискавери-фазу».

Этап № 2 – presale

Далее к работе подключаются пресейлы направлений – специалисты, которые будут делать оценку ИТ-проекта по своей части. Модератор создает чат, куда подключаются все необходимые эксперты. В крупных компаниях этот подход позволяет специалистам провести оценку в удобное время, но в рамках четко установленных сроков. Поскольку все пресейлы – высококвалифицированные специалисты, и они постоянно задействованы на коммерческих проектах.

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

• Например, если мы видим, что на конкретном проекте важен UX, добавляем работы по исследованию юзабилити, проверке гипотез на фокус-группах и т.п. А если есть требования к производительности, принимаем решение о необходимости выполнения нагрузочного тестирования.

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

• Например: оценка разработки одной фичи не должна превышать 8 (в крайнем случае - 16) часов, а диапазон разброса минимальных и максимальных значений не должен превышать 40%. В ином случае возможен высокий уровень неопределенности в реализации фичи, что может привести к увеличению рисков проекта. Также есть обязательное требование, чтобы оценщик зафиксировал в комментариях, как он видит реализацию задачи за указанное время.

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

Чтобы ускорить процесс оценки и сделать его более точным и прозрачным, мы в SimbirSoft используем свои наработки. И поскольку в работе стараемся выделять как можно более конкретные задачи, это позволяет анализировать «предстоящий фронт работ» точнее. Платформа Estimate, о которой мы упоминали в начале, – это облачный аналог разработанного нами алгоритма предварительной оценки ИТ-проекта. Сервис дает возможность пользователям оценить трудозатраты на любые виды работ по проекту. С помощью встроенных в него шаблонов можно автоматизировать оценку и ускорить срок ее проведения. Причем им можно воспользоваться как бесплатно, так и приобрести расширенную корпоративную версию.

Этап № 3 – подготовка коммерческого предложения

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

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

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

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

Выбор – за клиентом

Оценка трудозатрат – важный и ответственный этап при разработке ИТ-продукта. Она позволяет построить путь к достижению конечной цели заказчика – готовому решению. Поэтому требует внимательного подхода от ИТ-компании и клиента. И если экспресс-оценка «по аналогии» дает приблизительный результат, то детальная «по фичам» – более точный. Этот метод позволяет команде уделить оценке больше времени, задать заказчику дополнительные вопросы и погрузиться в проект еще до его старта.

Чек-лист: что подготовить к брифингу для оценки по фичам

Рассказываем, какие особенности будущей ИТ-системы владельцу продукта важно обсудить с подрядчиком перед началом оценки проекта по фичам. Для наибольшей объективности мы рекомендуем клиентам обсудить ответы вместе со своей командой. Еще раз подчеркнем, что это базовый набор вопросов, но в зависимости от особенностей проекта он может изменяться и дополняться.

Блок 1. Общее описание будущей ИТ-системы:
* Какие задачи она должна решать?
* Кто ей будет пользоваться, на каких устройствах и что можно будет делать с помощью этой ИТ-системы?
* Требования к производительности и нагрузке системы. Интеграция с какими внешними и внутренними сервисами предполагается и т.п.
* Есть ли у нее аналоги? Что в них нравится, а что нет?

Блок 2. Варианты сотрудничества:
* Предполагаемые зоны ответственности и формат работы над системой
* Будет ли команда заказчика принимать участие в разработке?
* Были ли уже какие-то наработки?
* Какие требования к code style, стандартам и сертификации предъявляются?

Блок 3. Реализация будущей ИТ-системы:
* Ожидания по срокам и бюджету.
* Предпочтения по архитектуре, стеку, фреймворкам, системе управления базами данных и т.п.
* Есть ли брендбук для разработки дизайна?
* Какую статистику/аналитику предполагается собирать? Планируется ли подключение внешних систем аналитики?
* Требуется ли нагрузочное и автоматизированное тестирование?

Если у вас остались вопросы, напишите нам на электронную почту