В начале 2023 года сегмент заказной разработки ПО показал устойчивую динамику роста: количество обращений за подобными услугами увеличилось почти в два раза. Это говорит о том, что российский бизнес вновь готов инвестировать в развитие своей ИТ-инфраструктуры, хоть и в краткосрочной перспективе. Рассмотрим, какие преимущества дает заказная разработка ПО отечественным компаниям.
Динамика развития сегмента в 2021-2022 годы
Последствия ковида, дефицит кадров, спецоперация стимулировали рост российского рынка заказной разработки. В позапрошлом году он, по данным Tadviser, продемонстрировал положительный результат — общий доход отечественных софтверных разработчиков составил более 1,5 трлн. руб. — на 19% больше, чем в
2022 год можно разделить на два больших этапа. За период с января по июнь российский рынок покинули крупнейшие мировые вендоры ПО, в связи с чем большинство клиентов поставили на паузу реализацию своих стратегий по масштабированию ИТ-инфраструктуры. Другие при этом нарастили количество проектов, и, благодаря импортозамещению, это стало драйвером 35%-ного роста сегмента заказной разработки ПО. С июня и до конца 2022 года произошла адаптация российского бизнеса к сложившейся ситуации, и практически все проекты были разморожены.
Важным моментом является общее согласие, что потребность в автоматизации бизнес-процессов любой компании никуда не делась. Бизнес продолжает свою работу, развитие, и ИТ-составляющая, системы автоматизации и управления процессами, продолжают оказывать значительное влияние почти в любом бизнесе.
Драйверы развития сегмента
Предпосылками роста объемов рынка заказной разработки стали такие ее преимущества, как возможность создания собственного продукта, максимально учитывающего все возможные бизнес-задачи и обеспечивающего эффективность автоматизации уже существующих бизнес-процессов без необходимости перестраивать их под процессы, которые могут быть в «коробочных» программных решениях. В большинстве случаев (вне зависимости от того, насколько точно и детально были сформулированы бизнес-функциональные требования (БФТ) к программному обеспечению до начала его разработки) в процессе разработки или внедрения, которые могут занимать достаточно продолжительное время, возникает необходимость в изменениях, которые в очень короткие сроки могут быть учтены при заказной разработке, тогда как получить аналогичное от уже готового ПО, не адаптированного под требования конкретного клиента — мало реально. Трансформация и цифровизация устоявшихся бизнес-процессов, особенно на крупных предприятиях, начались не вчера, остановить их невозможно, поэтому в той или иной парадигме компании вынуждены продолжать развитие, чтобы достичь поставленных внутри целей и быть готовыми к изменениям. Заказная разработка, соответственно, позволяет достичь этого с большей скоростью и эффективностью.
Этапы проведения работ и подходы к реализации
В абсолютном большинстве случаев, обращаясь к заказной разработке, бизнес уже имеет внутреннее понимание того, к чему необходимо прийти. Часто это может быть в виде БФТ, которые буквально на нескольких листах на очень высоком уровне могут перечислять существующие процессы в компании и необходимые действия с ними. В процессе консультаций, на предпродажной стадии, БФТ могут уточняться, наполняясь новыми подробностями.
Следующим шагом является разработка технического задания (ТЗ), где от абстрактных идей необходимо перейти к конкретике. Разрабатывается документ, отвечающий на вопрос «Что?», который создается в результате работы бизнес-аналитиков, изучающих процессы заказчика и требования к ним. Они проводят серии интервью с ответственными лицами компаний, представляющими различные бизнес-функции. Подобный документ преследует очень важную цель — описание границ и способов их достижения для того, чтобы проект по разработке имел свое завершение. Техническое задание должно предусматривать конкретику, которая позволит провести приемо-сдаточные испытания, тем самым завершив процесс разработки и передачи продукту заказчику. Как уже было сказано выше, нередко в процессе работы, возникает понимание необходимости внесения изменений в уже утвержденное ТЗ. Это, скорее, норма, чем исключение, и обеим сторонам стоит относится к этому с должным пониманием.
Крупные заказчики зачастую имеют свои пожелания к реализации проекта, которые должны быть разработаны, обсуждены и утверждены еще до этапа начала фактического написания программного обеспечения. В этой связи, в дополнение к ТЗ, создается другой документ — «Частное техническое задание (ЧТЗ)», — цель которого — ответить на вопрос «Как?». Этот документ содержит детали, часто описание алгоритмов и структур данных, которые во многих случаях архитекторы и разработчики бы разработали и реализовали при написании ПО без дополнительного документирования, но в ряде требований ГОСТ, для некоторых областей, например, государственного программного обеспечения, наличие этой фазы проработки может быть обусловлено условиями государственного контракта. После создания, согласования и утверждения подобного документа начинается процесс разработки программного кода.
Нередко в процессе создания ЧЗ или ЧТЗ выполняется и прототипирование интерфейсов. Это большая работа, в которую вовлечены дизайнеры, аналитики, эксперты по интерфейсам, разработчики и, конечно же, конечные пользователи, для работы которых и разрабатывается система. Все вместе они преследуют общую цель — создание максимально эффективных интерфейсов, которые будут удобны конечному пользователю и позволят ему наилучшим образом выполнять свою ежедневную работу. Данный шаг может занимать продолжительное время, но оно с лихвой окупается его экономией на этапе разработки.
Очень часто при разработке заказчик просит сформировать некую «пилотную» версию в кратчайшие сроки, которая может дать понимание направления, в котором движется программный продукт. ТЗ хоть и может содержать много деталей, но в любом случае не дает такого же представления, как живой продукт. Часто на этом этапе и приходит понимание того факта, что какие-то нюансы не были учтены при согласовании разработанных документов или интерфейсов, равно как и того, что процесс мог быть достаточно продолжительным и бизнес-требования за прошедшее время эволюционировали. Обратная связь пользователей и инженеров по тестированию позволяет собрать новые отзывы и, в конечном счете, разработать продукт, отвечающий ожиданиям и достигающий целей.
После завершения разработки первой версии продукта в дело вступают инженеры внедрения, которые помогают заказчику начать использование нового продукта, проводят обучение пользователей, убеждаясь, что бизнес-цели достигнуты.
В любом программном обеспечении встречаются ошибки — вне зависимости от того, насколько профессиональной была команда разработчиков и как хорошо были созданы документы, проведено тестирование. Ни одно тестирование не способно воспроизвести все возможные ситуации, с которыми могут столкнуться реальные пользователи в своих повседневных задачах. Служба технической поддержки разработчика должна всегда оставаться на связи, быть готова помочь советом, если возникшая ситуация требует дополнительного обучения пользователя, либо оперативно устранить проблемы в кратчайшие сроки путем исправления программной ошибки, если того требует ситуация. Поэтому важно уделить внимание доступности подобной службы поддержки, а не надеждам на то, что ошибок не будет и поддержка не понадобится.
Разумеется, не стоит забывать и про развитие продукта. Новые функции расширяют возможности, внедрение которых позволит достигать новых высот благодаря автоматизации и тем плюсам, которые современные технологии дают бизнесу любого масштаба.
Состояние рынка заказной разработки в 2023 году и прогнозы на будущее
Если до прошлого года за услугами заказной разработки чаще обращались крупные холдинги, то в текущем году рынок расширяется — спрос растет независимо от масштаба бизнеса. При этом многие большие организации пока продолжают использовать зарубежные платформы по причине того, что полная трансформация ИТ-архитектуры нуждается в крупных расходах. Однако это — вопрос времени, так как долго продолжать эксплуатацию решений западных вендоров при отсутствии обновлений и техподдержки невозможно. Это позволяет прогнозировать дальнейший рост спроса на заказную разработку ПО у отечественных компаний.
