Быстрое внедрение или качество?

«Нельзя обращаться с ИТ как с сервисным отделом — это полноценный партнер», — начал свое выступление Борис Шелекасов, директор по ИТ «ВТБ Лизинг». Он не только открыл конференцию, но и выступил ее модератором. ВТБ имеет опыт заказной разработки в разных форматах, поэтому может поделиться экспертизой по множеству вопросов.

Докладчик сравнил водопадную модель, с которого начиналась заказная разработка, с гибридной моделью, которая практикуется сейчас. «Выяснилось, что когда пользователи смотрят на функциональные требования в текстовом документе, они не понимают, что там написано, и согласовывают не глядя. Потом оказывается, что все, что сделано, не нужно, и надо переделывать», — вспоминает он. Проект-продукты подразумевают, что надо начинать быстро, с MVP, потом запуститься в продакшн и посмотреть, что получилось, уточнить потребности.

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

Факторы, влияющие на долю внутренней разработки

Выступающий предложил поразмышлять, что лучше: самим разрабатывать решения или заказывать продукт на стороне? «ВТБ Лизинг» является довольно крупным заказчиком, однако есть немало факторов, которые влияют на востребованность внутренней разработки.

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

Чтобы избежать проблем, нужно тестировать программы. Но и тут все непросто. Большое количество ручных тестов влечет за собой нехватку времени на регулярное проведение полного регресса. При поддержке старых версий ПО необходимо тестировать новые patch-запросы и сервис-паки. В больших командах нужна уверенность, что новый код не повлияет на работу кода других разработчиков. Из-за человеческого фактора возникает большой процент пропуска ошибок, при этом между внесением ошибки, ее обнаружением и исправлением проходит много времени.

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

«В принципе, это рабочая схема, но она имеет ряд нюансов, — рассуждает докладчик. — Во-первых, у вас две команды, которые занимаются тестированием. При этом у команды автоматизированного тестирования возникает зависимость от работы «ручников». Время тратится на погружение автоматизаторов в контекст продукта. При увеличении ручного регрессионного набора вообще нет времени на полные проверки».

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

Однако может быть и наоборот. Денис Воденеев вспоминает ситуацию на проекте, куда был приглашен в качестве специалиста по тестированию. Автоматизация тестирования не была предусмотрена, и на 20 разработчиков выделили двух специалистов по ручному тестированию. «Заранее релевантной оценки по тестированию не было, и в какой-то момент ручные тестировщики просто захлебнулись, так как работали на трех тестовых стендах (один в контуре заказчика), и проверка требовалась на каждом. В итоге увеличилось все: и сроки разработки (на полгода от изначального плана), и стоимость тестирования, и технический долг по исправлению дефектов. За счет позднего увеличения проектной команды и поздней автоматизации затраты на тестирование выросли в полтора раза по сравнению с первоначальными расчетами», — рассказывает он.

Подходы к тестированию

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

Оценка универсального подхода

При таком подходе в архитектуру тестовой модели изначально заложены критерии для эффективной автоматизации, и время на проведение тестирования сокращается за счет совмещения активностей по ручному и автоматизированному тестированию. Также понадобятся SDET, то есть Software Development Engineer in Test, — разработчики, которые занимаются созданием софта для тестирования: инструментами, фреймворками, автоматизированными тестами. Использование команды из универсальных тестировщиков и SDET-специалистов дает возможность осуществлять контроль качества без увеличения сроков тестирования, уверен спикер.

Как обеспечить безопасность разработки

Когда банк заказывает себе ПО, он имеет дело либо со своей штатной командой, либо с аутсорсером, либо с вендором. Но обеспечивать безопасность заказной разработки придется в любом случае. Валерий Лобанов, ИТ бизнес-партнер МКБ, пояснил, как решается эта проблема в его организации. В МКБ используют и библиотеку паттернов интеграции, и инструкцию от OWASP (Open Web Application Security Project).

Инструкции от OWASP

Не забывают в МКБ и про автоматизацию. Без автоматизированного документооборота современный банк неконкурентоспособен. Однако и безопасности без автоматизации никуда. Например, если иметь дело с контейнерами, то в случае ручного труда понадобится выделение и настройка технических ресурсов для проведения проверок, а на сами проверки уйдут дни. Необходимо пересмотреть несколько десятков образов в репозиториях у вендора, передать образцы эксплуатанту, а затем вернуть найденные уязвимости обратно вендору.

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

Также в банке не обходятся без поддержки ИИ, однако во главе угла остаются люди. «Про автоматизацию и искусственный интеллект мы поговорили, но история с взаимодействием между людьми никуда не делась, — говорит Валерий Лобанов. — Если вы хотите, чтобы кастомная, да и вообще любая разработка была безопасна, то нужно будет уделить внимание человеческой экосистеме и работе в ней. Чтобы сотрудники находили поддержку, получали советы и ответы на вопросы».

В МКБ для этого есть три героя: BISO, он же Business Information Security Officer, то есть «деловой» директор по информационной безопасности, ITBP, или бизнес-партнер со стороны ИТ, и DevSecOps. Помимо отдельных героев нужны еще и Security Champions. «Если мы хотим работать качественно и безопасно, нужна история с Shift Left (проверки, сдвинутые в левую часть пайплайна). Безопасность нужно предусматривать с самого начала, — уверен спикер. — Для этого мы обучаем в командах Security Champions. Команды у нас составные: из штатных, вендорских и аутсорсных ребят. Security Champion — это тот человек, которому делегирована часть функций ИБ, поэтому он может принимать решения и рассказывать своей команде, что и почему нужно делать. С другой стороны, он разгружает сотрудников из инфобеза, поэтому решения, связанные с безопасностью, принимаются быстрее».

Информационная безопасность — приоритетное направление, которое всегда в тренде, особенно сейчас, когда нарушения становятся все более дорогостоящими. Любой изъян в системе безопасности стоит дорого, а цена ошибки и количество попыток нарушить работу систем продолжают расти. Снижение киберрисков — главный приоритет 2024 года. Именно поэтому Сергей Грачев, заместитель директора по кибербезопасности IBS, и Артур Галеев, начальник отдела DevOps IBS, решили рассказать о том, как же выстроить безопасный конвейер разработки в таких непростых условиях.

Оценочные затраты организаций на самую масштабную утечку данных за последние 3 года

Мировые приоритеты в сфере информационной безопасности лежат в области модернизации технологий, включая киберинфраструктуру, использования искусственного интеллекта для киберзащиты и создания новой операционной модели, ориентированной на поддержку бизнеса. «При этом 50% опрошенных считают использование облачных технологий главной киберугрозой, — приводит данные отчета PwC Global Digital Trust Insights 2024 Сергей Грачев. — Еще раз обращу ваше внимание, что в этом исследовании принимали участие не только профильные специалисты по ИБ, но и владельцы бизнеса».

С мировым сообществом понятно. А что же влияет на российский рынок кибербезопасности? Сергей Грачев назвал санкции, уход из России ряда крупных вендоров, переход на отечественные сертифицированные решения, импортозамещение. Кроме того, влияет активизация госрегулирования в области информационной безопасности, издание целого ряда новых нормативных документов, ужесточение ответственности за нарушения.

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

В связи с этим, растет спрос на безопасную разработку по таким направлениям, как:

• выстраивание процессов DevSecOps, учет ГОСТа 56939, а также построение безопасной архитектуры и инфраструктуры заказчика;
• учет требований безопасности DevSecOps/ГОСТ 56939 в рамках заказной разработки программных продуктов, адаптации существующих программных решений и платформ заказчика;
• собственные разработки программных решений с учетом требований DevSecOps/ГОСТ 56939.

Очевидные плюсы — безопасность, снижение затрат. Но есть плюсы и неочевидные, поясняет спикер. Процесс безопасной разработки имеет множество пересечений с подготовкой к сертификации ПО и соответствующим оценочным процедурам по требованиям федеральных регуляторов: ФСТЭК, ФСБ. Чем выше зрелость процесса, степень его оптимизации и автоматизации, тем проще будет подготовиться к оценочным и сертификационным процедурам и пройти их.

Подход IBS на основе ГОСТ Р 56939/58412

Артур Галеев, в свою очередь, представил конкретные инструменты, которые используются в IBS. «Внутри компании есть экспертиза, есть инженеры, которые уже внедряли эти инструменты», — говорит он и поясняет, зачем нужен DevSecOps. В основном, для снижения затрат на устранение уязвимостей.

Артур Галеев рассказал, что когда IBS внедряла этот подход в российской розничной организации, она разработала стандарты безопасности для Kubernetes и Red Hat OpenShift Cloud Platform с учетом рекомендаций вендора и в полном соответствии с CIS (Center for Internet Security), создала инструкции по настройке аудита безопасности систем контейнеризации для Kubernetes и Red Hat OpenShift Cloud Platform. Кроме того, заказчику предоставили документ, включающий лучшие мировые практики, которые обеспечивают безопасность контейнеризированных приложений.

Российская телекоммуникационная компания обратилась в IBS с просьбой организовать мониторинг используемых программных компонентов, чтобы выявлять среди них уязвимые. Также нужно было создать локальные копии общедоступных репозиториев программных компонентов и предоставить ресурс для размещения разрабатываемых компонентов. Для заказчика подготовили прототип системы управления репозиторием исходного кода и различных видов артефактов: Maven, NPM, Nugget, RPM, Deb, Docker. Система позволила сканировать артефакты не только на уязвимости, но и на возможные правовые риски, при этом все вносимые в код изменения имели цифровую подпись.

Микросервисы под микроскопом

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

Контейнеризация же является технологией, которая позволяет упаковать все эти микросервисы в контейнеры. Контейнер легковеснее, чем виртуальная машина, но содержит все необходимое для запуска приложения. Технологии контейнеризации — ключевой компонент в построении микросервисной архитектуры и эффективного DevOps-процесса. Тему контейнеризации, безопасности и всех аспектов, которые с нею связаны, затронул Тимофей Минин, менеджер по развитию продуктов облачной и сетевой безопасности «Лаборатории Касперского».

Контейнерам может угрожать множество вещей. Американский национальный институт стандартов и технологий (NIST) описал все ключевые риски, которые сейчас присутствуют в контейнерных средах. Что с ними делать? Тимофей Минин разделил практики безопасности в процессе разработки на четыре блока.

Основные риски ключевых компонентов контейнерных сред

Первый этап разработки — это исследование и хранение. Нужна проверка образов реестра на актуальность, наличие уязвимостей и вредоносного ПО, регулярное и ручное сканирование, создание чистого реестра. Важно не забыть и про проверку конфигурационных файлов (IaC, Dockerfiles) на наличие ошибок, небезопасных настроек, секретов.

Второй этап — создание и тестирование ПО. Тут необходим контроль целевого качества Dockerfile перед сборкой самого образа, проверка собранного образа на все возможные риски, подпись образа после сборки, то есть присваивание ему цифровой подписи, подтверждающей целостность и подлинность.

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

Создать микросервисное приложение быстро, качественно и с нуля невозможно. С этого тезиса начал доклад Денис Андриевский, и.о. директора департамента «Производство как продукт» «Диасофт». Архитектура не позволяет быстро встраивать новые решения в существующий ИТ-ландшафт, а изменения и обновления имеющихся решений требуют больших трудозатрат и часто приводят к регрессу. Создавая новые продукты, разработчики часто «изобретают велосипед» без поправки на ранее реализованные решения, и каждый раз пишут много однотипного технического кода. При этом срок доставки решения (с момента реализации бизнес-требований до момента использования продукта бизнес-заказчиком) часто не соответствует требованиям постоянно меняющегося рынка.

Существенная часть времени вынужденно уходит не на создание новых продуктов, а на исправление ошибок в ранее созданных решениях. Для обеспечения качества приходится учитывать самые разные требования — одно импортозамещение чего стоит! Что делать в этой ситуации — отвечает сам рынок, предлагая в помощь лоукод. Процент новых промышленных решений, разработанных с помощью этого инструмента, увеличивается. Если в 2020 году меньше 25% ИТ-продукции было сделано с использованием лоукода, то к 2026 году, по ожиданиям Gartner, этот процент вырастет до 75%.

Порог вхождения в лоукод невысок. Приложения легко масштабируются, производительность растет. Чтобы сделать разработку еще более быстрой и дешевой, спикер предложил использовать платформу из экосистемы Digital Q. Тогда на создание работающего прототипа уйдет всего 2 недели, а для генерации типового кода микросервиса понадобится всего одна кнопка. Digital Q как экосистема цифровой трансформации обеспечит единый подход к разработке, единый стек разработки, единые инструменты DevOps, прозрачное управление командами, единые механизмы интеграции и работы с данными.

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

Люди решают все

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

В «Диасофт» наблюдают за успешными командами и ведущими специалистами, а затем стараются вычленить, по каким признакам и на основании каких артефактов можно измерить их успех. Лучшие практики передаются другим командам, а обратная связь внимательно анализируется. «Мы измеряем объем работ, подход внутри команд, правила использования методологии DevOps, качество разработки, сколько используется лоукода при разработке своего кода и осознанность практик участниками команды», — перечисляет докладчица.

Производственный дашборд

Показателей, разумеется, больше, и их количество только растет. С помощью них формируются производственные дашборды, на основе которых руководители на разных уровнях управления производственными командами принимают решения, находят новые точки роста. Для работы в этой парадигме в «Диасофт» разработали платформу Digital Q.Management. Она обеспечивает управляемое сокращение стоимости разработки. Наталия Оржевская остановилась подробнее на двух из шести компонентах платформы: на нормировании задач и на оценке спринтов.

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

Этой платформой пользуются в компании, и предлагают попробовать Digital Q.Management заказчикам на рынке. Кроме непосредственно продукта, «Диасофт» обеспечивает экспресс-обучение по нормированию, так как инструмент — это еще не все. Нужно уметь им правильно пользоваться.

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

Чтобы справиться с выгоранием, можно ротировать людей в проектах, но рано или поздно все сотрудники узнают, что проект длинный, тяжелый и там «болото». Брать новеньких с рынка? Продать проект кандидату становится все сложнее, опытные понимают сразу, что к чему. «Поднимите руку те, у кого нет проблем с наличием разработчиков, у кого их достаточно, — просит докладчик. — О, вот один человек поднял».

Сложные проблемы требуют сложных решений. Softline предпочитает системный подход. Здесь создали выделенный центр разработки (ВЦР). Это структура, которая сама обновляет кадры внутри себя и выдает два результата: кадры для других проектов и стабильный результат целевого портфеля проектов. Если проект на долгие годы, то нужно сразу понять: предстоит многолетний труд.

По заветам Форда, тут строят конвейер, который начинается в университете, проходит через практики и наставничество, изучение навыков коммуникации, выходит на предметную область и формирует новенького мотивированного джуниора на легаси-проекте. Выпускник превращается в него примерно за полгода, и готов работать за 40 тыс. рублей в качестве стажера. «Хорошая команда готова брать 20% стажеров, поэтому можно обновить команду на 30% за год, — считает Роман Смирнов. — Внутренние сотрудники дешевле рынка».

Что хочет заказчик

«Мы небольшая компания, но на рынке разработки уже больше 20 лет, работали со многими секторами экономики, поэтому знаем о заказной разработке почти все. Удивить нас в этой сфере вряд ли возможно», — утверждает Екатерина Шашкова, исполнительный директор, «ИнЭкс». С таким опытом приобретается главное — понимание, а чего же хочет заказчик.

В целом, о его желаниях догадаться несложно. Он хочет, чтобы было как можно дешевле, а лучше — бесплатно, вовремя и четко по ТЗ из 38 страниц. «Но на самом деле он хочет, чтобы мы с помощью автоматизации решили проблемы. Чтобы он мог вовремя отчитаться контролирующим органам, увеличить объем продаж, упростить оказание услуги своим клиентам. Когда мы поняли, чего он и правда хочет, то выработали для себя четыре основные практики, которые используем в работе», — делится наблюдениями Екатерина Шашкова.

Звучит все просто. Нужна совместная работа, когда и заказчик, и разработчик вместе планируют задачи, формулируют требования, принимают продукт и решают проблемы. Кстати, разработчику стоит помочь заказчику выявить его реальную проблему, и исходя из нее уже выбирать решение. «Аналитикам у нас запрещено приходить в команду разработки со словами «заказчик хочет, чтобы вы сделали так». Аналитик должен пояснить, какая у заказчика проблема, после чего разработчики предлагают несколько вариантов ее решения, озвучивают плюсы и минусы, а заказчик выбирает из предложенного», — рассказывает Екатерина Шашкова.

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

В «ИнЭксе» практикуют регулярный, поэтапный и скорейший ввод ПО в эксплуатацию, чтобы перейти от режима «все готово, но через два года» к «первая полезная функция через две недели». Среди полезных практик оказалось и целеполагание, потому что методичная работа с ним на всех уровнях позволяет закрывать задачи быстрее и качественнее.

Вторая хорошая практика — это декомпозиция. Она позволяет бизнесу быстрее получить практический, в том числе финансовый, результат от ИТ. Так, например, декомпозиция пользовательских историй выглядит так. Каждая история разбивается на подзадачи с конкретным результатом: будет готов тест, приложение, таблица, страница и проч. Дата готовности истории проставляется после декомпозиции. Если итоговая дата больше 10 дней — история вновь разбивается, декомпозиция повторяется.

«Мы, заказчики и разработчики, на самом деле живем в одной экосистеме, — говорит Евгений Тетенькин, директор по продажам и развитию Effective Technologies. — Проблемы у разработчика приводят к продукту низкого качества, который, в свою очередь, обеспечивает проблемы заказчику».

Дело в том, что заказчик и разработчик часто не могут «встретиться» вовремя. Когда заказчику надо, у разработчика оказываются другие дела, а когда разработчик готов что-то разработать, заказов для него не находится. Выручка непредсказуема. Чтобы в такой ситуации сэкономить, компания-разработчик затягивает пояс потуже и оптимизирует состав своей команды. «Когда команда переоптимизирована, и продолжается история с непредсказуемостью выручки, возникает эффект липких затрат. Он характерен для любого бизнеса, у которого доля ФОТ в структуре готового продукта значительнее, чем другие затраты», — рассказывает выступающий.

Эффект липких затрат возникает так. Пока выручка, сформированная на стандартных заказах, перекрывает затраты и ФОТ, все нормально. Но вот приходит заказчик с крупным проектом, и такой проект надо одолеть. Компания нанимает новых сотрудников, ФОТ растет, и это прилипшая трата. Выручка еще не выросла, а затраты уже на месте.

Наступает период убытка, который компания покрывает за счет накопленной ранее выручки или кредита. Чтобы с этим справляться, пытаются нанимать временных сотрудников или пользоваться аутстаффом. «В этом случае наш продукт начинают писать люди, которые просто проходили мимо. Им не так важно, кто же потом этот продукт будет поддерживать и развивать», — комментирует Евгений Тетенькин. Еще один способ ужаться — это «забыть» про технический долг и документацию.

Дальше начинается «тушение пожаров». Автоматизация CI/CD-процессов вылетает, все начинают делать руками, чтобы побыстрее и подешевле. Профессиональное развитие команды уходит на второй план — кто успел, тот и обучился. Технический долг прячут под ковер, равно как и разработку, поддержку документации.

Преобразование кривой дохода в растущую прямую легко нарисовать на картинке. А можно ли так сделать в жизни? Ответ в переходе на модель работы по абонентским платежам. «Можно подумать, кто на это согласится, кому это надо? Однако через год после того, как мы всех заказчиков переконтрактовали на такую схему, я попросил обратную связь. Все написали нам радостное благодарственное письмо. — делится опытом Евгений Тетенькин и показывает скриншоты этих писем. — Это потому, что теперь все важные и срочные проблемы заказчика мы решаем по первому же свистку. Где мы берем людей? Мы не приглашаем новых, у нас настоящий, а не ложный Agile. Пока работали по заказам, мы не могли ничего изменить из-за того, что объем работ фиксирован. А когда появились абонентские платежи, у нас не стало юридических ограничений, и мы можем важное, но несрочное выполнять на регулярной основе. Простоев у команды не бывает вообще».

Преобразование кривой дохода в растущую прямую

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

Нам не нужны велосипеды

Три лучшие практики разработки программно-аппаратных комплексов представил собравшимся Руслан Шафигуллин, директор департамента заказной и продуктовой разработки ICL Soft. Первое, к чему он призвал, — не изобретать велосипед. «Часто вижу, что коллеги, которые только-только начали прорабатывать ПАКи, кидаются делать какие-то устройства, прототипировать их, хотя это не всегда целесообразно, так как на рынке уже есть огромное количество решений, которые можно переиспользовать. Это будет экономически выгодно. Прежде, чем окунаться в разработку программной части, стоит посмотреть вокруг: а нет ли чего-то уже готового», — говорит он.

Докладчик привел конкретный пример. Заказчик — ведущий автопроизводитель — попросил сделать систему трекинга поддонов, которая в реальном времени показывала бы, где находятся погрузчики и как перемещаются поддоны в течение дня. Чтобы решить эту задачу, ICL Soft, несмотря на имеющийся опыт работы с радиомодулями, не стал изобретать велосипед, а сделал ПАК на основе промышленного считывателя RFID с ПО для отправки меток. Была разработана серверная часть, реализована интеграция со складской системой для учета привязки комплектующих с поддонами. «Здесь не было нужды пытаться разработать какое-то свое устройство, так как речь шла о небольшой партии погрузчиков. Мы использовали то, что уже существует», — комментирует Руслан Шафигуллин.

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

В ICL начинают с проверки концепта и методологии прототипирования, используя мультискилл-специалистов. Программно-аппаратный прототип стараются подготовить в кратчайшие сроки, а затем в дело вступает единая команды с методологиями командной разработки — так делают небольшой проект. На большом проекте работает уже множество команд, используются масштабируемые методологии, причем методологии постоянно меняются в зависимости от востребованности и масштабности самого ПАК.

«Мы не изобретали ничего нового, но в этом проекте получили очень хорошие результаты, не имея на входе четкого технического задания. Были предположения, тезисы, а на выходе у нас не просто продукт, а целая экосистема. Вы видите, что проект живой, мы не рассказываем о том, что было когда-то давно», — говорит Евгений Атаманов, генеральный директор «КСК Информационные технологии».

Группа компаний «Ключевые Системы и Компоненты» — это ведущий разработчик и производитель оборудования и комплектующих для транспортного машиностроения. Каким образом тут разрабатывалось ПО, объяснил Юрий Авилкин, директор по разработке и эксплуатации информационных систем, «КСК Групп». В качестве примера был взят проект безбумажного производства. «У нас не банк, не услуги. Тут цеха, брызгает и плавится жидкий металл. Бумаги, накладные, задания — лично меня трясет, когда я все это вижу в цехах. Задачку перед нами поставили так: а вам слабо эту бумагу убрать?», — вспоминает он

Расходы на чистые листы растут, принтеры ломаются, а подписанные документы слишком долго не поступают в бухгалтерию и учетную систему. Было принято решение отказаться от бумажных носителей. В процессе разработки выяснилось— «водопад» на производстве не работает. Нужен Scrum, Agile и продуктовый подход, а роль владельца продукта сложно переоценить. Он знает все о потребностях и болях пользователя, о возможностях команды, видит их точки соприкосновения и использует свои наблюдения на благо всего проекта. Владелец видит, каким должен быть результат, и знает, как именно команда будет добиваться этого результата. Контролируя каждый этап, он корректирует курс и говорит, что делать дальше.

В рамках отказа от бумаги в компании не только перешли на электронные документы, но и обеспечили оперативный прием ТМЦ и подписание документа перемещения без стационарного рабочего места — с помощью QR-кодов. Доработали и виртуального ассистента в Telegram, и мобильное приложение, а затем попробовали очки дополненной реальности.

Разумеется, были и проблемы — очки дорогие и нелюбимые, возрастные сотрудники их не жалуют. Для работы в мобильном приложении нужно использовать гаджеты. Нести личные? Кто-то жалуется, что у него старый смартфон, дайте новый. Есть и негатив от работы в Telegram.

Проблемы решаются постепенно, а между тем, проект переходит на четвертый этап. Разработан MVP мобильного приложения, проведены необходимые интеграции с бизнес-системами для прослеживаемости готового изделия в рамках жизненного цикла (от сырья до обслуживания и эксплуатации на подвижном составе). В конструктив готовых изделий планируют вводить NFC-метки и продавать сервис по подписке. Портал BI-отчетности теперь доступен всем сотрудникам. Данные в режиме онлайн обновляются на мониторах и инфопанелях производственных площадок. Результаты работы и свой вклад в нее видят руководители, работники предприятий и ИТ-специалисты. «КСК Групп» получила целую экосистему продуктов.

Свободы не будет

Хотя прошло уже больше 30 лет с того момента, как основатель и евангелист свободного ПО Ричард Столман лично прибыл в Москву, чтобы разъяснить публике разницу между «бесплатный, как пиво» и «свободный, как ветер», заказчики и даже судьи до сих пор путаются в определениях. О том, как программист может не получить свой гонорар только потому, что воспользовался open source кодом, рассказал Ярослав Шицле, руководитель направления «Разрешение ИТ и IP-споров» компании «Рустам Курмаев и партнеры».

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

Громкое дело программиста Дмитрия Мамичева было не единственным. Безусловно, у любого произведения есть автор, а у автора — права. Как их защитить? Суды ориентируются на правоприменение из сферы литературных произведений, а заказчики стараются держаться подальше и не уверены, стоит ли им вообще платить за заказ, внутри которого есть что-то ничейное.

Статья Гражданского кодекса 1286, которая регулирует этот вопрос, появилась не так давно — в 2014 году. «Понятно, что за десять лет значимой судебной практики накопить еще не успели, — комментирует Ярослав Шицле. — Зато есть ряд кейсов, в которых суды демонстрируют непонимание того, что такое open source. Они реагируют так: позаимствовали чужую разработку, значит, не можете претендовать на оплату вашего труда заказчиком».

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

Правовое регулирование Open Source в России

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

Докладчик пояснил, как избежать этих проблем. Но всегда надо помнить — в любом деле можно найти юридический нюанс. Поэтому лучше говорить не об устранении рисков, а об их минимизации. Ярослав Шицле рекомендовал фиксировать период использования открытого ПО (скриншот, нотариальное удостоверение), собирать документы о передаче прав, вести каталог используемого кода, его авторов, применимых лицензий, применимого права. Стоит заранее поинтересоваться, совместимы ли лицензии и получится ли потом использовать ПО без одной из лицензий. И главное — прописывайте условия в договоре! «На практике, когда разбираешься с делами как заказчиков, так и разработчиков, видишь, что в большинстве случаев в договоре ничего не сказано о том, имеет ли право разработчик применять опенсорс, а я ведь в 98% случаев фрагменты открытого кода используются в работе», — говорит спикер.