«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. Пишите в комментариях, с какими утверждениями сталкивались вы, а мы постараемся дать им экспертную оценку с точки зрения практики.
Читайте также: