2025/04/04 08:28:18

TAdviser: Заказная разработка ПО 2025


Содержание

19 марта TAdviser провел конференцию «Заказная разработка ПО». Заказчики представили свои подходы к использованию заказных разработок, поделились опытом, в том числе — негативным, дали рекомендации по наиболее рациональным вариантам действий. ИТ-компании рассказали о своей экспертизе в области программных разработок, представили кейсы.

Конференцию посетили представители таких организаций, как «Киришинефтеоргсинтез», «Атомстройэкспорт», «Ашан Тех», «ВТБ-Лизинг», ДИТ города Москвы, «Вкусно — и точка», «Центрлесхоз», «Атмосфера кино». Вел мероприятие Алексей Воронин.

Большинство ИТ-проектов недооценены

Руководитель блока кредитного корпоративного бизнеса «РСХБ-Интех» Станислав Тульчинский выступил с темой «Как управлять рисками и бюджетом при разработке». Он подробно остановился на рисках, возникающих при разработке программного обеспечения. Докладчик выделил основные проблемные области: недооценку затрат, непредвиденные расходы, проблемы с ресурсами и подрядчиками, отсутствие эффективного планирования и прозрачности в проектах.

Станислав Тульчинский, руководитель блока кредитного корпоративного бизнеса, «РСХБ-Интех»

Особое внимание Станислав Тульчинский уделил методам и подходам управления рисками в разработке ПО. Он подчеркнул необходимость борьбы с неопределенностью в проектах и представил стратегии по минимизации рисков при управлении бюджетом программных продуктов.

Спикер сформулировал ключевые рекомендации по эффективному управлению бюджетом в ИТ-проектах, говоря о важности создания резервов, прозрачного планирования и предотвращения конфликта интересов между участниками проекта.

«
Есть вещи, которые на начальной стадии проекта разработки ПО не улавливаются: внезапный скачок курса доллара, неожиданная болезнь главного разработчика и многие другие непредсказуемые события, — перечисляет он. — Смягчить их финансовыми буферами не получится — необходимо вносить изменения в процесс разработки. Например, вместо одного большого MVP, создаваемого в течение года, запланировать несколько небольших, разрабатываемых за месяц-полтора. Вместе с тем, финансовая сторона тоже очень важна. Зная, что мир не идеален, необходимо закладывать больше денег в бюджет.

Большинство ИТ-проектов недооценены на начальной стадии по деньгам вдвое.

»

Алексей Бельченков, старший ИТ-бизнес-партнер, «Юнилевер Русь», представил разработанную в компании PLM-систему «Реферус» для управления жизненным циклом продуктов в сфере FMCG.

Алексей Бельченков, старший ИТ-бизнес-партнер, «Юнилевер Русь»

Спикер напомнил, что до 2022 года компания была частью большого международного бизнеса. ИТ-задачи здесь решались «десантированием» команды ИТ-специалистов, которая приезжала, устанавливала решение и уезжала обратно. В качестве системы управления жизненным циклом использовалась SAP PLM.

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

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

«
В FMCG, в отличие от сборочного производства, действуют «химические процессы» — на выходе меняется масса продукта, и кастомизация одной из систем, представленных на российском рынке, не дала бы необходимого эффекта, — объясняет Алексей Бельченков.
»

Рассматривалось, в числе прочего, и создание системы на базе лоукод-платформы, но и это вариант был отброшен в сторону из-за ограниченности доступных функций, сложности масштабирования и по соображениям безопасности. Спикер признал, что у создания собственной платформы тоже есть минусы: сложность формирования продуктовой команды с опытом промышленных решений, высокие коммерческие риски. Однако в «Юнилевер Русь» пошли именно по этому пути и разработали PLM-систему для FMCG «Реферус», предназначенную для управления полным жизненным циклом производства: от идеи продукта до его снятия с производства.

Антон Сафронов, технический директор, «ДОМ.РФ Технологии», рассказал о мощной платформе разработки ПО, созданной в компании, ее структуре, компонентах, некоторых результатах внедрения и использования.

Антон Сафронов, технический директор, «ДОМ.РФ Технологии»

Спикер прошелся по всему инструментарию для разработчика, входящему в созданную платформу: от старта разработки (модель GitFlow) до системы для оркестрации и запуска по расписанию (Airflow). О назначении и функционале ряда инструментов было рассказано подробнее.

Так, LDAP-каталог FreeIpa позволяет реализовать концепцию единого входа во всех инструментах, обеспечивает доступ к виртуальным машинам и содержит информацию о принадлежности сотрудников к продуктам. Пакетный репозиторий Nexus для разработки содержит зеркала на публичные и внутренние локальные ресурсы для публикации артефактов.

Итоги внедрения платформы таковы. Время на разбор ошибок сократилось до 15 минут. Взамен старого UAT развернуто два новых окружения. Скорость поставки выросла до 40 релизов в месяц, тогда как время поставки сократилось с 3 дней до 15 минут.

«
«Основными проблемами на старте было отсутствие ИТ-команды, большое количество ИТ-проектов, — вспоминает Антон Сафронов. — Мы поняли, что нужна платформа, помогающая быстро пересматривать решения, вносить изменения. Разработанная нами платформа, построенная вокруг Kubernetes, помогла закрыть многие боли. Теперь никто из пользователей даже не замечает, как мы обновляем системы.
»

Спикер отметил, что у платформы есть потенциал коммерческого продукта, поэтому «ДОМ.РФ Технологии» думает над выводом ее на рынок.

Бюджет вырос вдвое, а сроки — в пять раз

Неудачным опытом (а потому особенно интересным и полезным) поделился с участниками конференции Александр Бражников, директор по ИТ, Performance Group. Он сразу сказал, что проект, о котором пойдет речь, реализовывался на одном из предыдущих мест его работы.

Александр Бражников, директор по ИТ, Performance Group

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

В итоге проект вместо трех запланированных месяцев занял девять. В сданных заказчику iOS и Android-сборках мобильного приложения было более ста багов, треть из которых были критическими, но исполнитель отказался их исправлять — этим занималась внутренняя команда еще в течение шести месяцев. Основными причинами неудачи стало, по оценке Александра Бражникова, излишнее доверие к аутсорсеру, с которым у одного из руководителей проекта ранее был удачный опыт сотрудничества, перекладывание ответственности за результат на исполнителя, отсутствие должного контроля за ходом реализации проекта.

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

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

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

На управлении безопасностью и эффективностью при заказной разработке остановился в докладе Ярослав Пономарев, советник генерального директора по информационным технологиям, АЛОР БРОКЕР. Он перечислил проблемы, с которыми сталкивается заказчик ПО. Юридические требования к подрядчику отсутствуют. Доступ в периметр и процессы выпуска релизов нестандартизированы. Актуального исходного кода нет, а проектная архитектура отличается от реальной.

Ярослав Пономарев, советник генерального директора по информационным технологиям, АЛОР БРОКЕР

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

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

«
Рекомендуется осуществлять инвестиции в обучение и развитие сотрудников, а главное — формировать в компании культуру безопасности, — подчеркнул Ярослав Пономарев.
»

Распределим ответственность

О практикуемых в компании подходах к заказной разработке рассказал Станислав Гоц, директор департамента бизнес-приложений и платформ, Lamoda. Несмотря на собственную ИТ-компанию Lamoda Tech, где работают более 900 человек, все-таки возникает потребность и в заказной разработке. Для создания важных продуктов, как правило, практикуется внутренняя разработка, но при этом учитывается наличие свободных ресурсов, компетенций.

Станислав Гоц, директор департамента бизнес-приложений и платформ, Lamoda

Станислав Гоц призвал подумать о следующем, прежде чем идти в заказную разработку:

  • на чьей стороне будущее решение будет размещаться;
  • кто будет его поддерживать;
  • кто будет развивать.

В случае заказной разработки выбирается, как правило, вариант хостинга, поддержки и развития на стороне партнера, отметил он. Но и в этом случае на будущее учитывается вариант, когда потребуется забрать продукт на свою площадку. С этой целью, еще на этапе выработки предварительных требований к будущей системе, закладываются требования по отказоустойчивости, совместимости с облаками (cloud ready), поддержки CI/CD и ряд других.

«
Когда речь идет о важном продукте, критически влияющем на бизнес, и если предстоит длительная разработка, то, как правило, мы идем во внутреннюю разработку, — отметил Станислав Гоц. — Но если продукт нужен здесь и сейчас, заказная разработка может быть предпочтительной.
»

Независимый эксперт Тарас Сорока представил три стандартные модели взаимодействия заказчика с подрядчиком при заказной разработке, закрывающие, по его оценке, 99% потребностей:

  • время и материал — заказчик управляет временем;
  • разработка за фиксированную цену — подрядчик управляет трудозатратами;
  • управляемые сервисы — подрядчик управляет временем.

Тарас Сорока, независимый эксперт

Спикер обозначил два главных параметра любой модели: предмет оплаты (время, трудозатраты) и вопрос — кто ответственен за конечный результат, заказчик или подрядчик.

«
Ответственность за развитие созданного заказного продукта лежит на заказчике, а подрядчик готов предоставлять для этого ресурсы, — полагает Тарас Сорока.
»

Никита Перевозчиков, менеджер проектов направления разработки , Programming Store, рассказал о продуктах компании, уделив внимание и методическим аспектам разработки ПО. Тут возможны различные варианты взаимодействия для разработки ПО: классический аутстаффинг, гибридные команды, бэк-офис разработки, полный аутсорсинг.

Никита Перевозчиков, менеджер проектов направления разработки 1С, Programming Store

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

«
Мы начинаем с небольших задач, а потом, когда показываем клиенту свою экспертизу и клиентоориентированность, заказчик начинать доверять нам более серьезные проекты, — поделился опытом Никита Перевозчиков.
»

Так, в российской дорожно-строительной компании «Автобан» сначала в формате аутстаффинга была осуществлена доработка типовых конфигураций учетных систем от 1С, решены задачи по обмену данными между этими системами и веб-продуктами, внедрена шина данных Datareon. Затем, уже в статусе генерального подрядчика, специалистами Programming Store было внедрено решение для автоматизации учета численности сотрудников на объектах и учета рабочего времени.

По результатам проекта кадровая служба получает достоверные данные о численности сотрудников в режиме реального времени, анализирует динамику численности персонала. Заодно тут снижен ФОТ.

В завершение спикер перечислил факторы, влияющие на формирование доверия между клиентом и подрядчиком:

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

Помощь обойдется дешевле, чем собственные ошибки

Кирилл Дмитриев, продуктовый менеджер, Selectel, посвятил доклад серверной операционной системе SelectOS, созданной специалистами компании на базе Linux. Спикер подчеркнул, что специалисты, разработавшие этот продукт, имеют 15-летний опыт работы с разными ОС. Отметив, что SelectOS создана с учетом бизнес-опыта клиентов компании, он перечислил основные достоинства системы, которая решает ключевые бизнес-задачи, обеспечивает безопасность процессов, оптимизирует затраты на ИТ-инфраструктуру.

Кирилл Дмитриев, продуктовый менеджер, Selectel

SelectOS предлагает две версии: для бизнеса (Enterprise) и для быстрого старта (Community). Кирилл Дмитриев подчеркнул, что репозиторий SelectOS, откуда пользователи берут необходимое ПО, находится на территории РФ, в составе инфраструктуры вендора и полностью им управляется.

«
На облачной инфраструктуре Selectel работает много компаний, имеющих дело с заказной разработкой, — отметил Кирилл Дмитриев. — При этом важным аспектом является обеспечение комплексной безопасности наших клиентов, в том числе — соблюдение требований регуляторов по работе с персональными данными. Главная цель Selectel — предоставление лучшего сервиса своим клиентам и снижение затрат на поддержку инфраструктуры.
»

Спикер привел в пример кейс для бизнеса с экономией затрат на инфраструктуры для провайдеров стриминговых платформ. На сессии вопросов и ответов он отметил, что пока ОС не в Реестре и не сертифицирована ФСТЭК, но работа в этом направлении ведется.

Алексей Годынский, главный архитектор, «Ланит-Би Пи Эм», обозначил три важных составляющих любой современной командной разработки ПО: процессы коммуникации, технологии и искусственный интеллект. Спикер рассмотрел влияние каждого из этих компонентов на результаты командной разработки. Он подчеркнул, что для налаживания эффективной командной работы важны методологии (Kanban и др.), регламенты и метрики, предназначенные для фиксации изменений.

Алексей Годынский, главный архитектор, «Ланит-Би Пи Эм»
«
Коммуникации в команде разработчиков стоят чуть ли не на первом месте. Поэтому здесь очень важны методологии: Scrum, Kanban, а также регламенты, — подчеркнул спикер. — Но работать с методологиями следует аккуратно, не перегружать людей методиками, поскольку это может привести даже к снижению производительности командной работы, а не к ее повышению.

»

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

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

  • распознавание, генерация, обработка устной и письменной речи (NLP);
  • поиск в неструктурированных документах;
  • автоматизация поддержки;
  • генерация тестов.

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

Марат Невмянов, заместитель директора отделения нагрузочного тестирования, IBS, перечислил отрасли, в которых специалисты компании реализуют проекты тестирования: среди них финансовые институты, государственный сектор, ИТ-компании, розница, телекоммуникационные компании, нефтегазовая отрасль, энергетика и промышленность, транспорт.

Марат Невмянов, заместитель директора отделения нагрузочного тестирования, IBS

Докладчик напомнил цели нагрузочного тестирования. Его проводят, чтобы получить представление о работе создаваемой системы в реальных условиях, проверить соответствие выставленным SLA, выявить максимальное количество пользователей, которые смогут одновременно эффективно работать с системой.

«
Разработчикам ПО нагрузочное тестирование позволит быть уверенными в том, что система справится с нагрузками в режиме промышленной эксплуатации, — уверен Марат Невмянов.
»

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

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

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