Статья. Это слишком дорого! От чего зависит цена разработки и как её снизить
Неправильные приоритеты и заоблачные ожидания могут поднять стоимость IT-проекта до небес. Спокойно! Мы расскажем, как этого избежать. В этой статье – всё об оценке стоимости на разных этапах жизни проекта, способах её снизить и разработать ПО без напрасных потерь времени, денег и нервов.
Оценку стоимости IT-проекта можно и нужно делать на разных этапах жизненного цикла проекта.
Оценка стоимости на разных этапах проекта
Инициация проекта. Когда есть только концепция будущего программного обеспечения, оценка стоимости поможет понять, реально ли реализовать проект за имеющиеся деньги и время, и заложить их в бюджет следующего года. Оценка здесь не может быть точной, поскольку до конца не ясны требования. Но опытная команда разработки предоставит вилку стоимости “от Х до Y”. Как правило, на этом этапе коммерческое предложение не готовят, а цену озвучивают в формате консультации. Нередко оценка стоимости на этапе инициации становится проверкой проекта на жизнеспособность. Изучая концепцию программного обеспечения, разработчики сразу анализируют, можно ли его создать с учётом нынешнего уровня развития технологий.
Заказчик пришёл с задачей – генерировать G-код для станков с ЧПУ по 2D-чертежам изделий. Подключили аналитиков, разработчиков. Пришли к выводу, что идея революционная, но пока что технически не реализуемая. И начинать надо даже не с подготовки ТЗ, а с длительного и дорогого R&D.
Из практики Rubius
Проектный офис
Планирование проекта. На этом этапе будущее программное обеспечение обретает форму: примерно понятны бизнес- и функциональные требования, потребности в техническом и информационном обеспечении. Уже можно сделать наброски технического решения, продумать его архитектуру, выбрать стек и более точно посчитать стоимость разработки. Эта оценка – ещё не окончательная, но на её основе, например, можно запустить процедуру закупки.
Выбор подрядчика. Перед началом исполнения проекта требования к ПО уже оформлены окончательно. Информации достаточно, чтобы декомпозировать проект на отдельные задачи, определить этапы работы, необходимые роли в команде и рассчитать трудоёмкость. На этом этапе оценка стоимости уже точная и обычно презентуется в виде технико-коммерческого предложения (ТКП). Но и этот документ – не финальная цена, а основа для переговоров между заказчиком и исполнителем.
Как оценивают стоимость проектов
Способов подсчитать стоимость разработки – множество.
Как оценивают стоимость IT-проектов: оценка по аналогиям, экспертная оценка, оценка по трём точкам, оценка по метрикам (например, по количеству строк кода), оценка от частного к общему и от общего к частному
Часто IT-компании используют комбинации нескольких методов или разрабатывают собственные. Мы расскажем о трёх самых распространённых способах оценки стоимости проекта.
Оценка по трём точкам
Оценка по трём точкам – один из самых популярных способов рассчитать стоимость IT-проекта. Его суть в проработке трёх вариантов оценки:
оптимистичной: сколько ресурсов потребуется на проект, если не будет вообще никаких проблем,
пессимистичной: какие проблемы могут возникнуть в проекте, и сколько ресурсов потребуется на реализацию в таком случае,
наиболее вероятной: сколько потребуется ресурсов в обычной ситуации.
Например, при хорошем раскладе проект можно сделать за месяц, при плохом – за 2, наиболее вероятный сценарий – управиться за 1,5 месяца.
Оценки формируются в процессе обсуждения внутри команды. На их основе получают усреднённую оценку по формуле:
Стоимость проекта = (O + 4M + P) / 6
О – оптимистичная оценка
Р – пессимистичная оценка
М – наиболее вероятная оценка
Эту оценку и получает заказчик программного обеспечения. Её неоспоримый плюс в том, что она одинаково учитывает позитивный и негативный сценарий развитий событий и позволяет проработать риски на ранних этапах проекта.
От частного к общему, или декомпозиция задач
От частного к общему – один из самых точных методов оценки стоимости. Оценка здесь собирается по частям: проект разбивают на отдельные задачи, считают затраты на каждую и суммируют. Например, аналитик обдумывает, сколько времени нужно на исследование и проектирование конкретной системы, разработчик – на код, QA – на тестирование, и так со всеми ролями в проекте. Менеджер суммирует их оценки, анализирует возможные риски и формирует итоговую оценку.
По аналогиям
Это один из самых быстрых методов оценки. Его суть очевидна из названия: стоимость проекта оценивают по фактической стоимости разработки аналогичных решений. За основу берётся опыт конкретной IT-компании или средняя цена на рынке.
Если аналогичных решений нет, проект разбивается на отдельные задачи. Их сравнивают с предыдущим опытом по длительности, сложности, необходимым ресурсам, примерно оценивают стоимость каждой и суммируют.
Оценка стоимости проектов в Rubius
Оценкой проектов в Rubius занимаются presale-команды. У нас их 5, каждая отвечает за своё направление: корпоративные системы, искусственный интеллект, AR и VR, BIM, CAD и CAM. Благодаря узкой специализации команды быстро находят подходящее техническое решение для проблемы клиента и точно оценивают его трудоёмкость. А опыт реализации подобных проектов позволяет им предусмотреть возможные риски.
В presale-команду входят:
sale-менеджер – держит контакт с заказчиком и выясняет детали проекта,
аналитик из предметной области – изучает ТЗ и вместе с sale-менеджером проводит предпроектное обследование,
техлид – оценивает реализуемость и предлагает техническое решение,
проектный менеджер – отвечает за детализацию работ и проработку рисков.
Если необходимо, к оценке подключается архитектора систем, DevOps-инженер, специалист по информационной безопасности и дизайнер.
Команда изучает запрос на разработку и приступает к аналитике: выясняет проблему, потребности и требования. Это обязательный этап, даже если заказчик пришёл с готовым ТЗ.
В проекте в списке требований к ПО была функция, которая съедала половину бюджета проекта. Начали выяснять, кому именно в компании заказчика она нужна и почему в таком виде. Оказалось, что человек, который внёс предложение в проект, давно уволился, и никому кроме него эта функция не нужна. Функцию из требований убрали, а вместе с этим сохранили половину бюджета.
Часто техническое задание описывает только требования к проекту. Способов их выполнить может быть бесконечно много. Прежде чем приступать к оценке такого проекта, нужно сформировать видение решения, согласовать его с заказчиком и выяснить его ограничения. Например, компания может быть не готова к облачным решениям, или у неё нет подходящей для проекта инфраструктуры.
Не всегда то, что описано в ТЗ, решает проблему заказчика оптимальным способом. Случается, что не решает её вообще. Мы не разрабатываем бесполезное ПО, только потому что нас об этом попросили. Мы разбираемся в проблеме и предлагаем лучший способ её решить.
Заказчик пришёл в Rubius с запросом на кастомизацию стороннего платного ПО. Стоимость реализации и сроки были огромными. Когда начали выяснять, какие именно функции нужны в этом продукте, оказалось, что заказчику требуется конвертер файлов. А остальные 90% функциональности ему ни к чему. Мы предложили разработать отдельный конвертер файлов и не переплачивать. Бюджет и сроки сократились в десятки раз.
Из практики Rubius
Проектный офис
Потребности заказчика мы выясняем в личном общении. Где-то достаточно телефонного разговора или переписки. Чаще нужна встреча: личная или онлайн. В некоторых случаях требуется полноценный аудит процесса.
Когда собрана вся информация, приступаем к проработке решения и оценке. Продумываем технические детали, этапность, команду. Чтобы понять стоимость проекта, разбиваем его на отдельные задачи и считаем затраты в часах на каждую – здесь опираемся на аналогичный опыт в прошлом. После умножаем требуемое количество часов на стоимость часа каждого специалиста в проекте и суммируем результаты.
Стоимость проекта = V1*C1 + V2*C2 + V3*C3
V1, V2, V3 – количество часов на задачу
C1, C2, C3 – стоимость 1 часа специалиста, выполняющего эту задачу
Получившаяся оценка стоимости проходит ревью. На этом этапе мы подключаем к проекту ещё одного техлида и менеджера. Они анализируют техническое решение и повторно оценивают его трудоёмкость.
Готовую оценку проекта оформляем в виде технико-коммерческого предложения (ТКП) и на встрече презентуем заказчику. Как правило, мы готовим несколько вариантов реализации проекта с разной стоимостью, чтобы заказчик мог выбрать для себя подходящий вариант.
Оценки стоимости на разработку от Rubius – прозрачные: мы открыто сообщаем заказчикам почасовые ставки специалистов и сколько часов требуется на каждую задачу в их проекте.
Из чего состоит технико-коммерческое предложение Rubius
ТКП – не контракт и не финальная цена, а начало предметных переговоров. Вместе с заказчиком мы ищем оптимальный способ реализовать проект и снизить его стоимость, если это необходимо.
Заказчик обратился в Rubius за разработкой 3D-конфигуратора оборудования. Мы подготовили 2 технических решения с разной стоимостью. В первом конфигуратор по заданным параметрам предлагал пользователю одну из 15 готовых сборок оборудования. Во втором, подороже, собирал подходящий комплект оборудования из отдельных элементов. Заказчику понравилось второе решение, но его стоимость превышала бюджет. Чтобы не жертвовать функциональностью, мы предложили разбить проект на отдельные этапы и изменить модель оплаты на T&M. В итоге стоимость разработки разделилась на несколько приемлемых по размеру платежей, а заказчик получил возможность в любой момент вносить изменения в проект.
Из практики Rubius
Проектный офис
Как добиться точной оценки проекта
Как вы уже поняли, в основе всех методов расчёта стоимости разработки лежит анализ её трудоёмкости. Если, изучая проект, можно однозначно подсчитать затраты на его реализацию, оценка стоимости будет точной. Если же в проекте высок процент неопределённости – то есть нет понимания что делать, как и почему – оценка будет примерной, и команда разработки будет вынуждена перестраховаться. Чем больше в проекте неясностей и переменных, тем больше денег закладывается на возможные риски. И тут цена может взлететь до небес.
Как снизить процент неопределённости в проекте:
Сделать предпроектное обследование. Его задача – ответить на вопрос: “Почему компания нуждается в разработке?”. На этом этапе аналитики выясняют, какую проблему заказчик пытается решить с помощью программного обеспечения. Изучают предприятие, бизнес-процессы, выявляют стейкхолдеров и их потребности. Результатом предпроектного обследования становится документ с описанием целей, задач и ограничений проекта, ожидаемых результатов от внедрения, концепцией разрабатываемой системы и её ключевых функций.
Заказчик хотел перенести функционал "Google Таблиц" в корпоративную систему. Первоначальная стоимость проекта превысила десятки миллионов. В предпроектном обследовании выяснили, что задачи работать с таблицами внутри системы вообще нет. Вместо этого нужна возможность загружать готовые файлы с данными в систему. Проблему решили импортом-экспортом файлов XLS, без многомиллионных затрат и года ожидания.
Из практики Rubius
Проектный офис
Написать техническое задание. Оно помогает ответить на вопрос: “Что необходимо разработать?”. В этом документе аналитики фиксируют требования к программному обеспечению: его функциям, архитектуре, производительности, интерфейсу и т.д. Для команды разработки ТЗ – инструкция, для заказчика – образ будущей системы и список критериев для проверки её качества.
По данным The Chaos Report 2020, 50% IT-проектов заканчиваются с превышением бюджета, сроков или без части изначально запланированных функций. Основные причины – нереалистичные ожидания, плохо проработанные требования и отсутствие эффективной коммуникации.
Спроектировать систему. То есть ответить на вопрос: “Как реализовать требования к ПО?”. Способов выполнить требования из ТЗ может быть много. Спроектировать систему значит выбрать конкретное техническое решение: определить его архитектуру, технологический и технический стек, зафиксировать процессы и пользовательские сценарии, спроектировать интерфейс.
Если в штате компании есть аналитики, все 3 этапа можно сделать самостоятельно. Но без соответствующего опыта и компетенций в разработке ПО здесь не обойтись. Самый простой и проверенный способ – заказать предпроектное обследование, ТЗ и проект системы отдельным договором у команды разработки.
Готовый проект программного обеспечения – лучшая основа для точной оценки его стоимости. Вы всегда будете знать, за что платите, а если цена или подход подрядчика вас не устроит, сможете обратиться к другому.
Как снизить стоимость проекта
Бывает, что после детальной проработки проекта его стоимость всё ещё не устраивает. Можно ли дешевле? Скорее всего, да. Есть несколько способов, как снизить стоимость IT-проекта. Мы не рекомендуем использовать их все разом. Выбирая, помните про баланс цены и качества и постоянно задавайте себе контрольный вопрос: “Такой способ реализации проекта решит задачу, стоящую перед бизнесом?”.
Разделить проект на части и отказаться от второстепенного
Любой проект можно раздробить на части и реализовывать по мере появления денег. Сначала сделать предпроектную аналитику, заказать техническое задание, потом спроектировать систему и отрисовать интерфейсы, а после разрабатывать ПО по функциональным модулям, начиная с самых важных. От вспомогательных этапов – обучения пользователей, документирования, поддержки – при необходимости можно отказаться.
Начать с MVP
MVP (minimum viable product) – это продукт с минимальным набором функций, достаточным, чтобы удовлетворить первых потребителей. Начиная разработку с MVP, можно запустить проект без лишних затрат, быстро протестировать гипотезы, собрать обратную связь от пользователей и определить вектор развития продукта. Если же идея себя не оправдает, потери времени и денег будут минимальными.
Заказчик обратился за разработкой корпоративного портала. Бюджет и сроки сильно ограничены, а проблема – горящая. Первоначальная оценка стоимости в 3 раза превышала допустимый бюджет заказчика. Жертвовать функциональностью или увеличивать сроки клиент был не готов. Мы предложили разбить проект на этапы (и отдельные договоры) и начать разработку с MVP, чтобы максимально быстро закрыть базовую потребность.
Из практики Rubius
Проектный офис
Выбрать подходящую проекту модель оплаты
Существует 3 модели оплаты: T&M, Fixed Price и гибрид.
В T&M (Time and Material) цена основывается на почасовых ставках специалистов и отражает, сколько по факту часов и ресурсов потратила команда разработки. Модель подходит для длительных и сложных проектов, без жёсткого графика, с меняющимися или не до конца проработанными требованиями. Выбрав T&M, можно гибко реагировать на ситуацию в компании и мире и учитывать возникающие риски.
В Fixed Price стоимость работ фиксирована и прописывается в договоре. Если требования к проекту меняются, то контракт и его стоимость пересматриваются. Модель Fixed Price больше подходит для коротких проектов, с чётким техническим заданием и ограниченным бюджетом.
В гибридной модели Fixed Price и T&M используются на разных этапах одного проекта. Например, аналитику, ТЗ и обучение оформляют по фиксированной цене, а разработку ведут по T&M. Гибридная модель подходит для проектов, где чётко определены этапы, но возможны изменения или дополнения.
Использовать open-source решения
Open-source – это программное обеспечение с открытым исходным кодом. Его можно использовать в разработке, менять и дополнять, не нарушая при этом авторских прав создателя. Большинство open-source решений распространяются бесплатно. При этом вокруг них целое сообщество энтузиастов, которые постоянно улучшают функциональность софта, тестируют его и исправляют ошибки. Среди open-source решений операционная система Linux, система управления базами данных MySQL и Chromium, браузер, на основе которого работают “Яндекс Браузер”, Google Chrome и Microsoft Edge.
В проекте нужно было работать с облаками точек. В первоначальной версии ТЗ заказчик настаивал на платном 3D-движке. Мы предложили открытый Potree. Разработанная система справляется с задачами ничуть не хуже, но обошлись без дополнительных трат.
Из практики Rubius
Проектный офис
Подключать готовые библиотеки
Библиотеки – это наборы функций для решения определённых задач в программировании. Благодаря им разработчикам не приходится каждый раз изобретать велосипед – они просто подключают к своему коду уже написанное и протестированное другими людьми решение. Как результат, проект идёт быстрее, а стоимость реализации снижается.
Есть библиотеки для работы с файлами, сетью, графикой, выполнения математических операций и т.д. Например, с помощью Three.JS можно создавать 3D-графику в браузере, Almanac Converter нужен для работы с датами и временем, System.IO – для чтения и записи файлов, а Requests помогает отправлять запросы к серверу.
Используя библиотеки, можно экономить и на дизайне интерфейсов. Например, в Material Design от Google огромная коллекция UI-компонентов, в том числе иконок, кнопок, шрифтов, панелей навигации, вариантов анимации и переходов.
Оптимизировать команду
Чем сложнее проект, тем выше должна быть квалификация разработчиков и наоборот. Например, чтобы сделать систему кадрового документооборота для небольшой компании, достаточно рядовых специалистов. А для системы контроля производства на основе искусственного интеллекта потребуются разработчики уровня senior. Формируя команду проекта, оцените его реальную сложность и не гонитесь за специалистами мирового уровня – большой процент задач под силу middle-разработчикам.
Помимо программистов в проектах участвуют менеджеры, аналитики, тестировщики, дизайнеры, DevOps-инженеры, scrum-мастера и маркетологи. И здесь важно не “растягивать” команду, перегружая её избыточными специалистами. Хорошо, когда проект большой, и каждый сотрудник в нём обоснован. Плохо, когда в разработке участвуют 15 человек, а код пишет один разработчик.
Ещё одна причина оптимизировать команду – снижение затрат на менеджмент и взаимодействия. Чем меньше в проекте людей, тем меньше времени уходит на координацию задач, обсуждения и согласования. Если есть возможность подождать, можно сократить команду до минимума, но увеличить срок проекта. Одно и тоже ПО могут разработать 2 человека за 5 месяцев либо 4 человека за 3,5 месяца.
Есть несколько способов снизить стоимость IT-проекта. Выбирая, помните про баланс цены и качества и постоянно задавайте себе контрольный вопрос: “Такой способ реализации проекта решит задачу, стоящую перед бизнесом?”
Заключение
Стоимость IT-проекта неминуемо меняется по мере его детализации – это естественный ход процесса планирования. Не пугайтесь больших сумм при первой оценке и помните: это лишь начало переговоров с командой разработки. Смело озвучивайте свои пожелания и сомнения, вместе с подрядчиком прорабатывайте требования к ПО и обсуждайте возможные форматы сотрудничества. В итоге вы найдёте оптимальный способ реализовать ваш IT-проект.
А пока вы в начале пути, держите наш чек-лист с советами, как заказчику ПО подготовиться к оценке стоимости проекта.
