Поделиться
Как организовать процесс разработки ПО
Заказная разработка — один из трендов последнего времени. С ее помощью компании решают проблему импортозамещения и создают уникальные цифровые продукты, способные повысить конкурентоспособность бизнеса. Об особенностях процесса заказной разработки говорили участники организованной CNews Conferences конференции «Заказная разработка ПО 2025».
Как разрабатывать ПО
В «Русале» занимаются инхаус разработкой решений на базе искусственного интеллекта (ИИ) и при необходимости привлекают подрядчиков. «Скоро ИИ станет повседневностью», — уверен Михаил Граденко, директор департамента технологий искусственного интеллекта «Русал». Но бизнесу нужны не отдельные технологии, а реально работающие, приносящие прибыль решения.
Для создания таких решений к компании создали собственную DSML/PIP платформу. Она объединяет инфраструктуру, среду для разработки и эксплуатации, технические руководства и процессы разработки, административные регламенты и процессы менеджмента. Благодаря платформе «Русал» получил возможность быстро разрабатывать и внедрять созданные на собственном технологическом стэке решения на базе ИИ, а не приобретать их у вендоров.
Михаил Граденко поделился своим видением того, какой должна быть Digital Intelligent платформа для крупной компании. Она должна обеспечивать возможность автономной работы on-premise c масштабированием в любое облако, отчуждаемость DI артефактов, воспроизводимость DI пайплайнов, инфраструктурную нейтральность, опираться на Open Source стандарты, иметь интерактивные инструменты разработки DI пайплайнов и управления DI стеком и средами разработки, встроенный end-to-end Big Data Analysis.
Системный подход к цифровой трансформации
Для сохранения лояльности клиента при разработке ПО необходимы стабильно качественный результат, способность исполнителя выполнять задачи значительно лучше конкурентов и вовлеченность в решение проблем заказчика, уверен Владислав Юров, член координационного совета консорциума Rudoo.ru. Между тем, при заказной разработке на базе Open Source возникает целый ряд проблем. Во-первых, они связаны с защитой интеллектуальной собственности. Во-вторых, с техническим аудитом: обосновать при открытом коде стоимость внедрения, соизмеримую с проприетарными решениями, непросто.
Существуют и технические сложности разработки — нет гарантий исправления багов используемых технологий силами сообщества, документация на решения часто неполная, а поддержка разработчиков весьма ограничена, многое требует шлифовки или серьезной доработки, без доступа к облаку поставщика функциональность решения снижена, могут быть сложности с масштабированием объема хранимых данных и скорости их обработки. Существуют также риски безопасности и бизнес-риски, такие как неожиданное изменение лицензии проекта, слабая предсказуемость развития используемых технологий и сложность найма специалистов.
Как управлять процессом разработки
Александр Афанасьев, ИТ-директор Leomax Group, предложил обсудить два проекта. Первый — внедрение CRM в «Спортмастере». В компании решили заменить системы лояльности. Готового решения на рынке не нашлось, поэтому пришлось разрабатывать продукт с нуля самостоятельно. За 8 мес было разработано новое решение, силами 7 сотрудников было сконвертировано 2 Тб данных и за одну ночь все магазины сети были переведены на новое ПО.
В ходе второго проекта в компании, у которой уже был интернет-магазин на базе Imshop.io, решили создать мобильное приложение. Провели тендер, выбрали подрядчика, но проект оказался неуспешным. Решение разрабатывали более 2 лет, бюджет проекта вырос почти в три раза, а рабочая версия так и не появилась. Сейчас компания продолжает работать на Imshop.io, а заказчики мобильного приложения дано уволились.
Михаил Граденко, директор департамента технологий искусственного интеллекта «Русал»: Скоро ИИ станет повседневностью
Владислав Юров, член координационного совета консорциума Rudoo.ru: При заказной разработке на базе Open Source возникает целый ряд проблем
Александр Афанасьев, ИТ-директор Leomax Group: Причиной успеха проекта стала согласованная работа заказчика и исполнителя, их компетентность и системный подход к решению задачи
Евгений Мандрыка, владелец продукта «СберМобайл»: Бизнес хотел быстро масштабировать продукт, но на тот момент команда состояла всего из семи человек, и наши возможности были ограничены
Вера Осолодкина, аккаунт-директор «СберМобайл»: Главное — доказать команде, что она делает самый лучший проект
Иван Крутько, бизнес-практик в b2b продажах и цифровой трансформации: 70% проектов заканчиваются ничем, и главные причины — сопротивление людей и неправильно выстроенные процессы
Валентин Каськов, директор по информационным технологиям холдинга «Специальные системы и технологии»: Бизнес-заказчик не является экспертом в области искусственного интеллекта, поэтому ему сложно оценить качество внедренной нейросети
Артем Евсеев, советник практики интеллектуальной собственности юридической компании ЭБР: Чем четче и проще вы сформулируете техническое задание, тем проще будет взаимодействовать с подрядчиком, в том числе и при необходимости судебного разбирательства
Александр Афанасьев уверен, что причиной успеха проекта в «Спортмастере» была согласованная работа заказчика и исполнителя, их компетентность и системный подход к решению задачи. Провал инициативы во второй компании во многом обусловлен тем, что за время проекта у него сменилось 4 заказчика, исполнителей взяли недорогих, а не компетентных, ТЗ было написано плохо и постоянно менялось.
«СберМобайл» существует с 2017 г. Сначала компания заявила о себе с помощью лендинга, потом у нее появился сайт, а в период пандемии начала формироваться цифровая витрина. «Бизнес хотел быстро масштабировать продукт, но на тот момент команда состояла всего из семи человек, и наши возможности были ограничены», — вспоминает Евгений Мандрыка, владелец продукта «СберМобайл».
Вера Осолодкина, аккаунт-директор «СберМобайл», рассказала, как компания организовала эту работу. 60% времени сотрудников было определено на разработку продукта, а 40% — на его поддержку. В компании ввели строгую приоритезацию задач, научились отказываться от второстепенных проектов. «Мы сознательно отказались от части дизайна и сконцентрировались на функционале», — говорит она. Когда стало очевидно, что команда разработки перегружена, внедрили greylog, первичные запросы поддержки на QA-специалистов, создали библиотеку готовых компонентов, подключили к работе системных аналитиков. Со временем удалось организовать непрерывный релизный цикл и наладить прозрачную коммуникацию.
Евгений Мандрыка поделился кейсом запуска eSIM и посоветовал в процессе разработки четко выстраивать приоритеты задач, использовать бережливые методы, максимально упростить коммуникацию и согласования и дать команде понимание, что и зачем она делает. «Главное — доказать команде, что она делает самый лучший проект!», — говорит Вера Осолодкина.
Кейс eSIM
Иван Крутько, бизнес-практик в b2b продажах и цифровой трансформации, ex-директор по цифровому развитию «Комус», «М-Видео», поделился опытом выстраивания клиентского пути в b2b. Сначала клиентский путь (онлайн и офлайн) нарисовали в виде процесса, потом описали, как он будет выглядеть во внутренних системах компании, затем изучили, какие проблемы возникают у заказчика в b2b ритейле и, наконец, предложили способы их решения.
«70% проектов заканчиваются ничем, и главные причины — сопротивление людей и неправильно выстроенные процессы», — говорит Иван Крутько. Он поделился своим опытом организации работы эффективной команды.
Валентин Каськов, директор по информационным технологиям холдинга «Специальные системы и технологии», затронул в своем выступлении актуальную тему внедрения решений на базе искусственного интеллекта. «Бизнес-заказчик не является экспертом в области искусственного интеллекта, поэтому ему сложно оценить качество внедренной нейросети», — говорит он.
Он предложил для этого метод каскадного тестирования LLM с использованием мультиагентного кластера. Ответы тестируемой LLM и тестовые данные проверяют несколько LLM первого каскада тестирования, верификацию их ответов проводят LLM второго каскада тестирования. На финальной стадии подключается LLM — главный арбитр, на основании сделанных ею выводов происходит дообучение тестируемой модели.
Юридические тонкости разработки
Артем Евсеев, советник практики интеллектуальной собственности юридической компании ЭБР, рассказал о юридических аспектах ИТ-разработки. Процесс разработки ПО состоит из нескольких стадий: идея, техническое задание, реализация и, наконец, появление готового продукта. С точки зрения закона, ПО — это исходный код, объектный код, интерфейс и библиотеки. Поэтому в договоре на разработку ПО должна быть прописана передача заказчику всех его составляющих.
Очень важно правильно оформить техническое задание — прописать в нем, что требуется разработать, конкретный функционал, технические параметры, интерфейс, совместимость, пользовательские сценарии. «Чем четче и проще вы сформулируете техническое задание, тем проще будет взаимодействовать с подрядчиком, в том числе и при необходимости судебного разбирательства», — говорит Артем Евсеев. Он также посоветовал обязательно прописать SLA и чистоту кода — в нем не должно быть блоков с обременением от третьих лиц. Если используется открытый код, надо понимать, на каких условиях он распространяется.
Артем Евсеев рекомендовал обратить пристальное внимание на п.3 ст.1260 ГК РФ. «Даже если вы добропорядочный приобретатель ПО, можно получить иск от третьих лиц — правообладателей продуктов по причине его создания, даже если это право незапатентовано», — предупредил он. Артем Евсеев предложил предусмотреть механизм компенсации потерь, которые могут возникнуть в таком случае.
Поделиться
Короткая ссылка
