Сколько стоит разработка: 5 мифов о затратах на IT-продукт

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

Миф 1. IT-разработка – это всегда сложно, дорого и долго

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

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

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

Другими словами, можно запустить систему, используя 20-30% от общего бюджета. Продажи начнут «отбивать» часть потраченных средств и финансировать следующие этапы разработки. Например, в нашем портфолио есть медицинский проект для сети клиник Великобритании, который мы развиваем более 10 лет. При этом его первый релиз вышел через 8 месяцев после старта. Также был опыт запуска MVP продукта для дистанционного банковского обслуживания крупного сетевого банка за 100 дней. К слову, этот продукт мы продолжаем дорабатывать и дополнять новыми современными фичами.

Миф 2. Можно сэкономить, передав задачи разработки No-Сode-системам

No-Code – это способ реализации IT-продуктов при помощи специальных платформ, без написания кода вручную. Его можно использовать для создания сайта компании, корпоративного портала, интернет-магазина, игрового приложения и других IT-решений. Таким путем родилось немало сервисов и приложений, в основном, зарубежных – Tavalo, Reachr, Look App, Comet и другие.

Чтобы передать задачи разработки No-Code-платформам, нужно серьезное основание. Например, доказанная гипотеза о том, какие бизнес-выгоды принесет такой шаг. На наш взгляд, вместо того, чтобы сокращать ресурсы, стоит задуматься, на что их выделить. Исследуйте возможности No-Code-платформ для решения конкретных бизнес-задач. При этом важно понять, что и насколько изменится в бизнесе, а главное – когда это произойдет.

Проведите эксперимент – сделайте прототип или MVP нового продукта на No-Code-платформе. Потом покажите результат своим клиентам или инвесторам, протестируйте вместе с ними, получите обратную связь. Если все устраивает, можно думать, как это развивать.

Вывод: No-Code-платформы удивляют возможностями и манят простотой освоения. Их действительно стоит изучать, но только вместе с имеющимися инструментами – использовать как возможность диверсифицироваться, усилить команду, расширить кругозор и компетенции разработчиков. Не стоит рубить сплеча и кардинально менять систему работы, если есть слаженная IT-команда.

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

Миф 3. Можно «собрать» IT-систему из доступных продуктов

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

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

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

  • Имеют разные возможности кастомизации и интеграции. Некоторые конструкторы, готовые решения, No-Code-платформы никогда не смогут полноценно взаимодействовать между собой. Например, сайт компании интегрирован с платежной системой X, а вендор учетной системы и не планирует такую интеграцию.
  • Отличаются по качеству технической и клиентской поддержки, графику обновлений и т.п. В частности, для конечного клиента, как правило, не имеет значения, что у поддержки сайтов, созданных на разных платформах, разный SLA, и что сервер был недоступен в момент, когда он оплатил заказ. В следующий раз покупатель просто уйдет и не вернется.

Вывод: как показывает наша практика, чем сложнее планируемый продукт и чем «взрослее» существующий, тем очевиднее нужна индивидуальная разработка или модернизация с архитектурным решением, которое будет:

  • Отвечать текущим и будущим техническим и бизнес-требованиям.
  • Обеспечивать производительность, безопасность и управляемость.
  • Адаптироваться к новым требованиям.

Миф 4. Не нужно переплачивать, соберите команду из джунов

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

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

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

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

  • Требования заказчика: насколько качественно они проработаны, детализированы и сформулированы в окончательной редакции – не планирует ли заказчик их менять.
  • Сложности проекта, его размер и объем задач, помимо кодинга: аналитика, дизайн, различные виды тестирования, CI/CD...
  • Технологический стек.
  • Наличие у специалистов опыта реализации подобных проектов.

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

Миф 5. Нет смысла тратиться на аналитику проекта

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

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

Какие задачи помогает решать Discovery-фаза

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

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

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

3. Стартап-изобретатель – человек из цифровой сферы, который увидел возможность уберизации сложившейся бизнес-модели. В этом случае подрядчик вместе с заказчиком погружается в предметную область, в некоторых случаях – с привлечением научной экспертизы. Далее проводит Customer Development, составляет перечень нужных пользователю функциональностей, определяет приоритеты и описывает наиболее удобные сценарии для пользователей. В итоге, быстро выпускает минимальный жизнеспособный продукт (MVP) для проверки возможности уберизации бизнес-модели в боевых условиях.

4. Крупное предприятие понимает, что можно что-то улучшить в своей деятельности – оптимизировать затраты или увеличить прибыль. Для этого с помощью IT нужно оптимизировать и автоматизировать существующие процессы. Здесь сначала проводится интервью со всеми заинтересованными сторонами, исследуется комплекс имеющихся на предприятии IT-систем и их взаимодействий, описываются существующие бизнес-процессы. В итоге становится понятно, какие процессы можно оптимизировать. Далее исследуются большие данные клиента – выявляются паттерны – для этого рекомендуем информативные дашборды. В итоге получаем концепцию комплексного решения и предварительную информацию о бюджете и сроках реализации проекта.

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

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

Читайте также:

Расскажите коллегам:
Комментарии
Генеральный директор, Москва

Эта статья о продукте, проекте или разработке?
Об оптимизации процессов средствами IT?
О деталях обучения не слишком опытных программистов на рабочем месте?
О борьбе с отдельными недостатками?

Кто поможет понять?

Руководитель, Москва

Можно сэкономить, передав задачи разработки No-Сode-системам

То есть нельзя сэкономить? 

Можно «собрать» IT-систему из доступных продуктов

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

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

По мере реализации требования будут меняться в любом случае.

 

Аналитик, Москва
Евгений Равич пишет:

Эта статья о продукте, проекте или разработке?
Об оптимизации процессов средствами IT?
О деталях обучения не слишком опытных программистов на рабочем месте?
О борьбе с отдельными недостатками?

Кто поможет понять?

Я так понял, что автор раскрывает мифы в среде фирм-разработчиков. Сужу по:

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

Но на некоторых мифах, в этом случае, можно остановится подробнее.

Миф 1. IT-разработка – это всегда сложно, дорого и долго - ну да, это так - сложно, дорого и долго. Сейчас, на мой взгляд, редко в разработку запускают какие-то продукты, которые решают локальные задачи. Тем более, что автор пишет о разработке не коробочных продуктов, а ИТ-систем. 
И этот же "миф" очень тесно связан с 
Миф 3. Можно «собрать» IT-систему из доступных продуктов.
Да, можно, не всю, но очень часто в вашу систему интегрируются чужие продукты и это номально. Это дешевле, быстрее и проще. 

А я бы, если это разработка ИТ-системы, добавил следующие заблуждения бизнес-руководителей разработки ИТ-систем:
1. Сэкономим на тестировании. Мы, к сожалению, так и не привыкли ответственно относится к этой стадии разработки: "Посадим Ленку с ресепшена, пусть она кнопочками поиграется".

2. Сэкономим на описании и документировании. Ну это беда огромного количества разработчиков. Был свидетелем и соучастником, когда проект просто рушился из-за отсутствия описания и ухода ключевого разработчика, сеньора. 

3. Не нужен финрезерв. Главное - начать, сделать базовый функционал, а там как-нибудь выедем. Отвечаю - не выедем. Вдруг на оплату разработки в самый трудный момент заканчиваются деньги на зарплату разработчикам. Команду  за пару дней исчезает. Поднять новую команду чрезвычайно сложно.

"Как же это вышло? Все было так весело, мы заготовляли рога и копыта, жизнь была упоительна, земной шар вертелся специально для нас - и вдруг... Понимаю! Накладные расходы! Аппарат съел все деньги."

Генеральный директор, Москва
Анатолий Курочкин пишет:
3. Не нужен финрезерв. Главное - начать, сделать базовый функционал, а там как-нибудь выедем. Отвечаю - не выедем. Вдруг на оплату разработки в самый трудный момент заканчиваются деньги на зарплату разработчикам. Команду  за пару дней исчезает. Поднять новую команду чрезвычайно сложно.

Совершенно верно. 

Вопрос обычный, но он о главном. Зачем мы всё это делаем?

Заказчик хочет сделать новый продукт и выйти с ним на рынок? У этого занятия свои законы, как у любого нового бизнеса. 

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

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

Руководитель управления, Ульяновск
Максим Часовиков пишет:
То есть нельзя сэкономить? 

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

Максим Часовиков пишет:
Нужно собирать из недоступных продуктов?

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

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

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

Да, у большинства клиентов, с которыми мы работаем, есть и вендорные продукты (в том числе, и майкрософт), и набор самописных решений.

Руководитель, Москва
Анна Шведова пишет:
Сэкономить можно. Возможно, мы не поняли Ваш вопрос, опишите его более подробно или перефразируйте иначе, если мы не дали достаточного ответа.

ВЫ пишите: 

Миф 2. Можно сэкономить, передав задачи разработки No-Сode-системам

То есть мифом является возможность сэкономить... 

Анна Шведова пишет:
Сэкономить можно.

Так что является мифом? 

Миф 3. Можно «собрать» IT-систему из доступных продуктов

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

Так что является мифом? 

 

Анна Шведова пишет:
Да, у большинства клиентов, с которыми мы работаем, есть и вендорные продукты (в том числе, и майкрософт), и набор самописных решений.

то есть - Миф 3. Можно «собрать» IT-систему из доступных продуктов   - не миф?

 

Системный аналитик, Екатеринбург
Максим Часовиков пишет:
то есть - Миф 3. Можно «собрать» IT-систему из доступных продуктов   - не миф?  

Собрать то можно, но на определённом этапе сложности и нагруженности - этот набор начинает уносить ветром, как маленький мопед, который на трассе оказался за фурой... то есть этот мопед может ехать из пункта А в пункт Б, но лишь 50 км/ч, а больше не потянет, сколько бы бензина вы не залили - потому приходиться мигрировать на более серьёзные Enterprise решения, и чем раньше, тем проще... иначе мопед становиться франкенштейном с кучей костылей и этого мутанта крайне сложно обработать, чтоб извлечь из него всё нужное и перенести в новую систему

Руководитель, Москва
Никита Гуцал пишет:
Собрать то можно, но на определённом этапе сложности и нагруженности - этот набор начинает уносить ветром, как маленький мопед, который на трассе оказался за фурой... то есть этот мопед может ехать из пункта А в пункт Б, но лишь 50 км/ч, а больше не потянет, сколько бы бензина вы не залили - потому приходиться мигрировать на более серьёзные Enterprise решения, и чем раньше, тем проще... иначе мопед становиться франкенштейном с кучей костылей и этого мутанта крайне сложно обработать, чтоб извлечь из него всё нужное и перенести в новую систему

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

Системный аналитик, Екатеринбург
Максим Часовиков пишет:
Не, ну ситуации бывают разные.. зоопарк - этонесколько большая гибкость, но тяжелее поддерживать.. Если процессы стабильные и отстроенные - то да, лучше что бы и ит решение было бы сквозное.. 

Ну для старта, в формате MVP некого - можно использовать несколько решений для разных подразделений, направлений деятельности. Но на определённом этапе стоит потратиться на переход. Хотя не у каждого бизнеса этот этап может настать и кто-то может 15 лет жить на самописной CRM + 1С + ещё что-нибудь и прекрасно себя чувствовать)

Партнер, Москва
Евгений Равич пишет: Эта статья о продукте, проекте или разработке? Об оптимизации процессов средствами IT? О деталях обучения не слишком опытных программистов на рабочем месте? О борьбе с отдельными недостатками? Кто поможет понять?

Здесь понять - это не главное :)

Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
3
Евгений Равич
Конечно. Иначе просто не могло быть. После появления книгопечатания очень многое изменилось. Но ...
Все дискуссии
HR-новости
Cпрос на сотрудников в гостинично-ресторанном бизнесе вырос на 60%

Зарплатные предложения для новых кадров выросли на 23% по сравнению с зимой прошлого года.

«Вкусвилл» запустил роботов для перевозки товаров в распределительных центрах

До конца 2024 года компания планирует роботизировать 30% операций, связанных с перемещением грузов из зоны приемки в зону хранения.

«Яндекс Еда» начала работать в Бишкеке

Киргизия стала шестой страной СНГ, где доступен сервис — после России, Казахстана, Беларуси, Армении и Узбекистана.

Более 40% наемных сотрудников не могут позволить себе больничный на работе

Свыше трети опрошенных отметили, что из-за проблем со здоровьем им отказывали в повышении.