Расчет стоимости и сроков разработки: как это устроено внутри аутсорс-команды и что нужно знать заказчику

Предпроектная подготовка как важнейший этап планирования

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

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

К оценке и планированию подключается целая команда специалистов: менеджеры, дизайнеры, аналитики, ИТ-архитекторы, тестировщики, программисты и тимлиды.

Их работа будет включена в смету, обычно она составляет 5-10% от всех затрат заказчика на разработку. Если вендор проводит этот этап бесплатно, времени на всестороннее изучение проекта может не хватить, поэтому он может просто не понять задачи клиента и начать работать по «додуманным» целям.

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

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

Из чего складывается стоимость ИТ-решения

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

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

Среди основных критериев, которые напрямую сказываются на конечной стоимости, можно выделить:

• количество и сложность реализации необходимых функций — этот пункт составляет основную часть стоимости проекта;
• число сотрудников, задействованных на проекте;
• уровень профессионализма команды — именно от него зависит качество продукта и стоимость часа работы специалиста;
• тип и количество поддерживаемых платформ — это зависит напрямую от типа разрабатываемого ИТ-продукта. Так, например, веб-приложение должно быть совместимо с мобильными и десктопными браузерами, мобильное — с операционными системами мобильных устройств, а настольные приложения — с десктопными ОС ;
• ИТ-инфраструктура — она представляет собой совокупность оборудования и серверов. На стоимость влияет то, по какой модели она будет построена и станет ли подрядчик разворачивать её самостоятельно или арендует;
• платные и бесплатные сервисы для реализации отдельных возможностей и их количество — это могут интеграции различных платежных систем и бонусных программ;
• тестирование и отладка для обеспечения стабильной работы ИТ-решения — оно занимает 20% от всей работы над проектом и требует немалого ресурса команды;
• защита безопасности пользователей, противодействие взломам и утечкам данных — работа с уязвимостями будущего продукта ведется на всех уровнях создания продукта.

Кроме того, в цену конечного продукта включаются и скрытые затраты на создание цифрового решения. Например,

• лицензии,
• платные доступы к SDK,
• API или библиотекам разработки (отдельные технологии можно использовать только при наличии платного доступа).

Эти пункты могут разниться в зависимости от необходимых возможностей продукта и объема данных.

Например, для отдельных проектов необходимы терабайты облачного хранилища, для других же — достаточно и нескольких гигабайт. Требуемый объем памяти в этом случае может зависеть от количества контента и мультимедиа ресурса, массивов Big Data, использования микросервисов, ML-технологий и других решений.

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

Читать по теме: Безопасная разработка для бизнеса: как получить надежное ПО с минимумом затрат

Сколько времени нужно на разработку

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

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

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

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

Наши партнеры не владели нужными технологиями, поэтому чтобы мы могли работать с их кодом, требовалось дополнительно создавать прослойку на backend’е. Без этого мобильные разработчики не могли вовремя приступить к работе, и сроки каждого последующего этапа сдвигались.

Некоторые факторы также невозможно предусмотреть заранее и изначально заложить в план работ. Среди них могут быть:

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

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

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

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

Сроки разработки возможно сократить, если:

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

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

Экономия без потери качества

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

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

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

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

Ещё один метод удешевить проект — разработать на базе CMS. При таком подходе количество работы ИТ-специалистов сокращается, потому как решение строится не «с нуля», а на базе шаблонного конструктора.

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

Однако и здесь есть свои ограничения. Например, сложности при внедрении не предусмотренного в CMS функционала или зависимость продукта от облачного решения — если она перестанет работать, то и платформа заказчика тоже.

После блокировок и ухода зарубежных ИТ-компаний с российского рынка многие компании уже теряли доступ к своим сайтам или были вынуждены переносить их на альтернативные платформы из-за блокировок конструкторов Wix, Ecwid и Weebly.

Читать по теме: Заказная разработка или коробочное решение: о чем важно помнить при выборе

Изменения в процессе разработки — это нормально?

Нововведения при создании цифрового продукта — типичная практика, которая часто встречается на ИТ-проектах. Новая информация и потребности могут появляться как со стороны заказчика, так и из-за внешних факторов.

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

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

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

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

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

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

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

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

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

Читать по теме: AI-инструменты, которые улучшают опыт разработки ПО

Фото на обложке: gorodenkoff / Getty Images