Вам готовое решение или закажете разработку? Что думают ИТ-компании
Иллюстрация создана нейросетью
Каким бизнес-заказчикам больше подойдут программные продукты, разработанные на заказ, а кому – созданное заранее решение со стандартным набором функций, и почему? О своем опыте в этом вопросе, обширном и разнообразном, о новых тенденциях в рамках круглого стола IT News делятся ИТ-компании, интеграторы и заказчики.
Обгоняя рынок – с заказной разработкой
Клиентов, отдающих предпочтение созданным на заказ ИТ-решениям, как и самостоятельным разработкам, можно разделить на два больших блока, - делится опытом Олег ЕЛМАНОВ, директор Fusion.
Прежде всего, заказную разработку внедряют, как правило, крупные корпоративные клиенты. Но размер бизнеса здесь не определяющий, хотя и важный фактор. В таких компаниях, как правило, имеются в наличии сильные ИТ-отделы с накопленным серьезным опытом работы, обладающие сильной внутренней ИТ-экспертизой, либо специально на эти цели они выделяют обширные бюджеты.
Кстати говоря, самостоятельно разрабатывать решения для цифровизации своего бизнеса предпочитают и сами ИТ-компании.
Предпочтения «коробкам» отдают, в своем большинстве, заказчики из категории среднего бизнеса. Как правило, готовое проектное решение рассматривают, когда нужно закрыть какую-то насущную потребность бизнеса, реализовать какой-либо проект, и сделать это как можно быстрее.
По пути индивидуально разработанных ИТ-решений идут топовые компании, да и целые отрасли бизнеса, которые исторически находятся в авангардных рядах цифровизации – это кредитно-финансовая сфера (банки), сегмент финансовых технологий, телекоммуникационная отрасль, - говорит Алексей СИНИЦА, президент IW Group. Вторая группа из этой категории – динамично развивающиеся сегодня отрасли: e-com, маркетплейсы, логистика и все, что с этим связано. В этих сегментах, именно по причине их стремительного развития, готовых коробочных решений попросту еще нет, и решение ориентироваться на собственную либо заказную ИТ-разработку в какой-то мере вынужденное, но необходимое для того, чтобы идти в ногу с бурно развивающимся рынком. И к третьей группе, отдающей предпочтение заказанным у вендоров решениям, можно отнести компании-флагманы из всех отраслей экономики. Они отдают себе ясный отчет в том, что оставаться на лидирующих позициях, поддерживать их и развивать смогут до тех пор, пока их клиенты будут получать передовые, новаторские, более качественные продукты, решения и сервисы. А это всегда индивидуальное решение.
Не только флагманские, но и крупные корпорации и компании неизбежно сталкиваются с ситуацией, когда текущие ИТ-решения не просто вышли из категории инновационных, но и перестали отражать в полной мере бизнес-потребности заказчика, - поддерживает дискуссию Илья МАРЧУК, директор по инфраструктуре компании Proscom. И здесь речь идет не только об инновационных в той или иной отрасли бизнесах, но и о масштабе самого бизнеса. Существующие на рынке «коробочные» решения для таких бизнес-заказчиков также, по большей части, не подходят.
«У нас в компании микс решений из собственных разработок, заказного ПО и готовых, купленных на рынке решений. В каждом из вариантов есть свои преимущества и недостатки, - делится мнением с точки зрения заказчика Юлия БОЛАНД, исполнительный директор Avosend. - Покупая и внедряя имеющиеся на рынке ИТ-решения, заказчик, по сути, попадает в достаточно долгосрочную зависимость от интегратора. Некоторых ИТ-решений, которые нужны нашей компании, на рынке в принципе пока еще нет. Часть из них разрабатывает собственная in-house команда Avosend, и еще часть являются заказной разработкой, выполненной подрядчиком. И здесь основной страх и вечная «головная боль» любого бизнеса – то, что у него может не хватить собственных компетенций внутри компании. А новый разработчик, как правило, не может разобраться в накопленном в компании за несколько лет работы legacy-коде, на который «завязаны» многие важные вещи в программе, и предлагает провести refactoring. Поэтому, если компании нужно какое-то быстрое решение, например, вывести продукт на рынок в короткие сроки, то в этом случае оптимальнее приобрести готовую «коробку». Если от сроков зависимость не столь высока, лучше всего предпочесть разработку in-house» с последующей кастомизацией и снижением этой зависимости от интегратора.
«Коробка» или заказ: смещение фокуса
Многие заказчики, заказывая разработку ИТ-решения у вендора, сталкиваются с одними и теми же проблемами. И самая частая из них - риск несоблюдения сроков.
Юлия БОЛАНД (Avosend):
«Ни один проект в нашей компании не вышел в заранее обговоренный с вендором срок без каких-либо функциональных жертв. К тому же компетенция специалистов, которые принимают участие в проекте, часто нас расстраивает.
С другой стороны, у заказной разработки есть и безусловные базовые плюсы. Один из них – это отсутствие всех рисков и сложностей работы с людьми – того, с чем приходится сталкиваться с командой in-house разработчиков».
Не могу сказать, что часто приходится слышать о срывах сроков ИТ-проекта, - возражает Илья МАРЧУК (Proscom). Все зависит от приоритетов. Обычно все проходит в гибком контролируемом режиме. И если разработчики понимают, что не успевают реализовать в срок весь функционал, потому что столкнулись, к примеру, с какой-то технически сложной проблемой, то просто договаривается с заказчиком по поводу того, что конкретно нужно внести в MVP продукт. Стартовавшая несколько лет назад программа цифровой оптимизации и диджитал-трансформации бизнеса подразумевает появление в компаниях новых должностей. И если раньше компетенции были на стороне ИТ-подрядчика, который предоставлял услугу заказной разработки, то сейчас эти компетенции мигрируют на сторону заказчика.
Сергей КОСТИН (CEO BSL и 1С-БСЛ):
«Опыт показывает, что бизнес-заказчикам все чаще требуется не готовый продукт, а outstaffing. И при взаимодействии с ИТ-интеграторами крупные бизнес-заказчики сегодня смещают свой фокус как в сторону in-house-разработки и собственных компетенций, так и в сторону готовых крупных end-to-end решений с возможностью кастомизации под свои нужды».
Безопасность: достижим ли идеал?
Влияют вопросы безопасности выбор между коробочным решением и заказной разработкой, и если да, то в какой степени? Проблема безопасности актуальна и в том, и в другом случае, считает Максим ПЕТУХОВ, технический директор «Перфоманс Лаб», и никогда не решается полностью. К примеру, готовое ИТ-решение содержит свои уязвимости, либо неизвестные до определенного момента, либо пока еще неустраненные. Самая распространенная из них –0-day. Пользуясь тем, что готовые ИТ-продукты широко распространены, злоумышленники могут пользоваться этими уязвимостями до того момента, пока они не будут закрыты.
С другой стороны, заказная разработка может создать новую уязвимость. Те же самые уязвимости могут быть заложены и в open-source коде, особенно если его использовать бездумно. Но при внедрении проектов на базе открытого исходного кода есть возможность его проверить. Если соблюдать правильный подход, все принципы, риски нарушения безопасности можно минимизировать, уверен спикер.
Максим ПЕТУХОВ («Перфоманс Лаб»):
«Возвращаясь к вопросу, что выбирают заказчики – готовое решение или разработку – и почему, тут все зависит не только от размера бизнеса компании, но и от ее целей и процессов. И перед принятием решения все эти факторы нужно тщательно проанализировать. Почти всегда самым рациональным вариантом будет микс из решений. Крупные или развивающиеся компании действительно активно используют заказную разработку, но не отказываются от готовых, проверенных временем решений. Так, основные типовые бизнес-процессы проще закрыть готовым решением, а все остальное – что-то специфическое, нетиповое, индивидуальное, инновационное – заказной разработкой».
Вариант закрытия доступа к open-source библиотекам для разработчиков из России спикеры сочли маловероятным. Но бездумно применять open-source решения, не просканировав код на предмет безопасности, не стоит.
После 2022 года open source решения в России используются особым образом, добавляет Илья МАРЧУК (Proscom). Чаще всего, сначала оно закачивается в какое-то внутреннее хранилище компании, проверяется там всевозможными методами, и уже после этого кастомизируется и используется. Необходимо также заметить, что после 2022 года в нашей стране безопасности готовых ИТ-решений уделяется очень большое внимание. Основными заказчиками готовых решений стали выступать либо государство, либо крупный бизнес, и они готовы инвестировать в обеспечение безопасности. Новые отечественные ИТ-продукты, которые находятся сейчас либо на стадии доработки, либо уже на стадии эксплуатации, проходят все возможные серьезные проверки и сертификации, к примеру, ФСТЭК, включены в реестры отечественного ПО и так далее.
Алексей ЕГОРОВ, руководитель отдела web-разработки ICL Services:
«Тем не менее, риск того, что в решениях, даже сертифицированных и включенных в реестр отечественного ПО, были использованы какие-то фрагменты open-source кода, в которых есть закладки, существует. И здесь очень важно, как выстроен подход к безопасности ПО, и на стороне исполнителя - разработчика, так и на стороне заказчика. Необходимо, чтобы обе стороны понимали важность безопасности, контролируя, по большому счету, друг друга. Важно и то, как выстроены процессы у исполнителя, в какой мере он сам следит за соблюдением правил безопасной разработки на своей стороне».
Встали и ушли. Как смена команды отразится на разработке
Что будет с ИТ-решением, если команда разработчиков, которая его внедрила, вдруг по каким-то причинам полностью сменяется – неважно идет ли речь о внутренней in-house команде или команде внешнего подрядчика. Сможет ли новая команда разобраться в ИТ-разработке, или ей это будет не по силам? Спикеры уверены, что если правильно организовать работу, учесть преемственность кода, учесть все best practice, то в этом случае полная смена команды проблемой уже не станет.
Зачастую смена команды происходит в случае смены провайдера или компании, поддерживающей решение. И здесь наличие legacy кода, который может даже и не сопровождаться документацией или эта документация будет неполной – ситуация довольно распространенная, уверяет Алексей ЕГОРОВ (ICL Services). При должном подходе вполне реально сделать передачу разработки безболезненной и даже незаметной для пользователей. И если новая команда будет настаивать на рефакторинге кода, к этому стоит подойти взвешенно, понять, какую выгоду от этого получит бизнес-заказчик и так далее.
«В каждой компании всегда есть knowledge base, и есть сотрудники, которые могут передать ее друг другу. Ну и, конечно же, нужно следовать best practice по документированию кода, - считает Петр САПАРКИН (ICL Services). - И в этом случае, даже если команда сменится полностью, она сможет продолжить работу над тем же ИТ-решением с небольшой поддержкой».
Трудности интеграции
Проблема совместимости разных ИТ-решений очень актуальна, и, наверное, нет сегодня ни одной компании, говорят спикеры, в которой она бы не возникала. При этом интеграционные задачи - самые сложные, требующие постоянного контроля и отслеживания.
Очень распространенная причина неисполнения сроков ИТ-проекта – это невозможность интеграции с другими ИТ-системами внутри разработки, с решениями других вендоров. И заказчики, зачастую, полагают, что разработчики, которых он нанял, должны сами решить этот вопрос между собой. Но это так не работает, уверен Алексей СИНИЦА (IW Group). Спикер уверен в необходимости того, чтобы кто-то выполнял роль Project Manager со стороны заказчика, курируя и координируя, в том числе, и все вопросы интеграции решений разных вендоров друг с другом. Еще один достойный вариант – если функции Project Manager на уровне заказчика готов взять на себя один из подрядчиков.
Риск срыва сроков проекта гораздо проще митигировать, если заказчик точно знает, чего он хочет, и все подробно описано в полноценном, хорошо проработанном ТЗ. Но очень часто сам заказчик может лишь обрисовать направление разработки в целом. Поминание того, что ему конкретно хотелось бы, приходит «во время пути», - продолжает дискуссию Максим ПЕТУХОВ («Перфоманс Лаб»).
Артем САЛЮТИН, директор по развитию Work Solutions, руководитель ИТ-кластера Ассоциации развития Digital-агентств ARDA:
«Разработка ПО, мне кажется, похожа на ведение сада. Все решения друг с другом переплетается, нужно постоянно за этим процессом следить, как-то облагораживать его, и так далее. Чтобы облегчить нагрузку по задачам, которые связаны с интеграциями, стоит проводить их с поставщиками, у которых надежны API, которые обеспечивают Nocturne Support и вносят изменения каждый день».
Методология разработки: step-by-step
Вопрос о том, какую методологию разработки выбрать, вызывает вечные споры. К примеру, уверены спикеры, методология Waterfall хорошо работает тогда, когда проекты, над которыми ведется работа, небольшие, или очень хорошо описаны, и заказчик четко понимает, что он хотел бы видеть.
А вот в случае, когда у заказчика есть только общее видение проекта, но нет понимания, какие конкретно будут функции, мы идем по пути итераций, осторожно. И каждую итерацию - конкретные ее сроки, функции, конкретная стоимость этой итерации - сверяем с заказчиком, - делится опытом Алексей ЕГОРОВ (ICL Services). В любом случае, и при выборе коробочного, и при выборе заказного решения придется проводить анализ, насколько функциональность решения соответствует тому, что хочет бизнес. Можно реализовать все процессы, которые уже сейчас существуют у заказчика. Возможно, они ему чем-то дороги, или «отполированы» годами, или любое организационное изменение, по причине размера компании заказчика, обернется для него адом. Реализовать процесс таким, как он есть, будет выгоднее. Или же компания-заказчик способна подстроить свои процессы под то, что предлагает коробочное решение, максимально используя ее возможности.
«Какой-то бизнесовый продукт сложно разрабатывать по методике Waterfall. К примеру, потому, что через какое-то короткое время с точки зрения клиента все может полностью поменяться. Готовым коробочным решением оптимальнее всего «закрывать» те процессы, которые не меняются, или меняются очень медленно. Для разработки же кастомного продуктового решения, изменения в котором неизбежны, потребуется даже не заказная разработка, а, скорее, аутстаффинг ИТ-специалистов», - комментирует Юлия БОЛАНД (Avosend).
Подход, подразумевающий составление функциональных технических требований (ТЗ), не показал себя эффективным, - поддерживает спикеров Сергей КОСТИН (BSL и 1С-БСЛ). - Мы тратим очень много времени на составление ТЗ, получаем за это отплату от заказчика. Но, как только начинаем «стартовать», выясняется, что заказчику все не нравится, чего-то уже не нужно, и так далее. Поэтому совместно с заказчиком и индивидуально под каждый конкретный проект мы составляем мини-документы, некий Vision and Scope, где зафиксированы основные задачи, исходя из нужд заказчика.
Сегодня стал заметным интересный тренд на изменение продуктовой разработки коробочных решений, - замечает Илья МАРЧУК (Proscom). - Если раньше заказное решение делалось под конкретного индивидуального пользователя или заказчика, то сейчас это, скорее, ориентация на потребности группы заказчиков. К примеру, если какую-то определенную кастомизацию продукта провели уже 10 заказчиков, то, разумеется, в какой-то момент это изменение просто становится частью продукта, входит в коробочное решение.
Когда диктуют финансы
В какой момент, при прочих равных, заказное решение становится выгоднее, чем кастомизированное коробочное? В первую очередь, здесь все зависит от масштабов самого решения, - считает Олег ЕЛМАНОВ (Fusion). Во вторую – от его повторяемости. Очень часто случается, что у разработчика (вендора) есть уже готовый, похожий кейс. Не исключено, что даже из другой отрасли. Но если разработчик готов повторить его для текущего клиента с определенными изменениями, такой вариант обойдется клиенту достаточно недорого – по цене, сопоставимой с коробочными решениями и кастомизацией. Разработка решения «с нуля» может обойтись дороже в несколько раз.
Алексей СИНИЦА (IW Group) замечает один очень важный и серьезный для заказчиков из числа лидеров рынка, для компаний, которые стремятся вырваться вперед, момент. Как правило, все новые идеи, предложенные заказчиком в процессе разработки ИТ-решения, все полезные особенности, функции и дополнения к продукту, которые придумывает и финансирует заказчик, интегратор сразу же вносит в коробочное решение, которым могут воспользоваться конкуренты заказчика.
По опыту Артема САЛЮТИНА (Work Solutions), заказчики действительно устали от бизнес-модели Vendor lock-in, в которой устанавливается зависимость от продуктов и услуг одного поставщика, и порой эта зависимость становится для бизнеса критичной. Несомненно, коробочное решение – это всегда гарантия быстрого старта проекта. Но бизнесу при этом необходимо параллельно запускать какие-то треки по разработке своего индивидуального ИТ-решения, что даст возможность «слезть с иглы» стандартной разработки. Ведь те, кто изначально сделал ставку на свой ИТ-продукт, впоследствии определенно выигрывает.
В качестве примера спикер привел целую серию недавних слияний и поглощений, которые произошли в целевом сегменте его компании - тревел-индустрии и бизнес-туризме. Заметный на рынке тренд на консолидацию задают те игроки, у которых есть свое ИТ-решение – они начинают скупать и поглощать компании, у которых собственного ИТ-решения не было.
Посмотреть полную запись Круглого стола IT News «Заказная разработка или готовое решение» можно здесь:
Опубликовано 19.06.2024
Петр САПАРКИН, руководитель направления бизнес-услуг и услуг по приложениям ICL Services:
«В сегменте ретейла, с которым мы работаем, и крупные игроки с масштабным бизнесом, и лидирующие компании принимают абсолютно разные решения. Для части компаний ИТ-решения разрабатываются in-house собственной командой разработчиков. Другие участники рынка выбирают уже готовые ИТ-решения, и совместно с вендором развивают их. Получаемое в итоге решение, в которое можно включить различные нововведения и know-how, получается ничуть не хуже, чем собственные ИТ-разработки конкурентов».