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

Как происходит оценка проекта

Детальная оценка – это трудозатратный процесс, в котором участвуют эксперты из разных направлений. Например, в нашей практике это группа из 5 специалистов – разработчиков, аналитика, дизайнера. Возглавляет группу модератор, который следит за тем, чтобы оценка была корректной и соответствовала потребностям заказчика. Задачи модератора:

  • созваниваться с клиентом для уточнения требований, согласования вариантов решения и стека технологий;

  • курировать процесс оценки;

  • предлагать варианты реализации;

  • оценивать и закладывать риски;

  • определять состав команды разработки;

  • составлять предварительный роадмап проекта. 

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

  • требования клиента изменились, например, он подготовил более детальное ТЗ и макеты;

  • была выявлена необходимость реализовать продукт поэтапно, начиная с MVP, с учетом бюджета или дедлайнов;

  • иногда нужно изменить технологический стек, если клиент сообщает новые бизнес-задачи или особенности инфраструктуры.

Риски и трудозатраты на управление

При оценке нужно учитывать трудозатраты на управление проектом (Project Management – или PM), в том числе:

  • распределение и контроль выполнения задач

  • проведение митингов; 

  • коммуникации с заказчиком продукта и устранение препятствий;

  • ретроспективы с командой;

  • демо с заказчиком;

  • работа с метриками и оценка рисков.

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

  • команда часто перерабатывает, причем больше, чем на 10-15%;

  • ТЗ постоянно меняется, а тестовая документация при этом не обновляется;

  • фактическое время выполнения задачи сильно превышает планируемое.

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

Оценка трудозатрат

При разработке тех или иных новых модулей команде предстоит выполнить различные виды работ, в зависимости от типа проекта:

  1. Приемка приложения

  2. Аналитика и дизайн

  3. Непосредственная разработка и интеграция с другими IT-системами

  4. Тестирование и обеспечение качества (QA) 

Мы поставили перед собой задачу выяснить, как в среднем распределяются трудозатраты по фазам разработки. Для этого мы проанализировали выборку веб- и мобильных MVP-проектов, разработанных в 2020 году. Трудозатраты на их реализацию составили от 2000 до 4500 часов.

Веб-приложение

Мы посчитали, в каком соотношении в этих проектах распределялись трудозатраты по разным видам работ (в процентах):

  • Аналитика – 7%

  • Backend – 30%

  • Frontend – 24,6%

  • Тестирование – 15%

  • Управление – 22%

Как показывает практика, разработка занимает около 50-60% от общих сроков реализации веб-приложения. 

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

Мобильная разработка

Немного другая картина складывается в том случае, если ваш продукт предназначен для смартфонов и других переносных устройств. Для анализа трудозатрат мы взяли выборку мобильных проектов, в которых мы выполняли разработку под Android и iOS. При этом мы исходили из допущения, что административная панель во всех проектах была основана на стандартных компонентах фреймворка разработки.

В веб-проектах трудозатраты распределились так:

  • Аналитика – 3,8%

  • Backend – 18,9%

  • iOS – 16,1%

  • Android – 25,8%

  • Тестирование – 25,1%

  • Управление – 10,3% 

По нашим оценкам, Backend- и мобильная разработка в среднем составили около 60% трудозатрат. 

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

Особенности расчетов 

Рассчитать сроки разработки можно с помощью разных инструментов, в том числе вручную в Excel. Для нас наиболее удобным методом стала автоматизация расчетов, для этого мы разработали собственный сервис Estimate, о котором ранее уже рассказывали на Хабре. Этот сервис позволяет подключать шаблоны и учитывать особенности каждого вида проектов. С помощью сервиса можно рассчитать, сколько часов необходимо на каждую фазу или этап разработки, на реализацию отдельных фич.

Пример оценки в Estimate
Пример оценки в Estimate

Заключение

В этой статье мы рассчитали особенности распределения трудозатрат в разных видах продуктов. В наших веб-проектах разработка составила в среднем 50% от общих трудозатрат, а в мобильных проектах – около 60%. 

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

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