Как выбрать цифровую платформу для ведения ИТ-проектов и по каким критериям оценивать системы? На какие решения стоит обратить внимание в 2026 году? В статье разберем функциональность 5 популярных ИСУП и подсветим плюсы и минусы каждого ПО.

В чем особенность ИТ-проектов

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

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

И все же ряд особенностей у ИТ-проектов есть:

1. В основе реализации лежат Agile-подходы. Классические методы задают рамку (сроки, бюджет, контроль), но реальная работа строится через гибкие практики: внутри почти всегда используются спринты, бэклог, инкременты.

2. Итерационная поставка ценности. Управление строится не только вокруг соблюдения плана: результат создается не в конце проекта, а через регулярные релизы.

3. Работа в цифровой среде. Команда (разработчики, аналитики, тестировщики) используют информационные системы: таск-трекеры, репозитории, CI/CD. Проект «живет» в инструментах, а не в отчетах.

4. Критично иметь единое информационное пространство. Сроки, требования и метрики должны быть связаны в одной системе. Иначе возникает разрыв между управлением и фактическим исполнением.

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

Какой должна быть система для управления ИТ-проектами

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

1. Поддержка гибридных подходов (Agile + Waterfall). Руководитель работает с этапами, сроками, бюджетом, исполнители — с досками, бэклогами и спринтами.

2. Управление бэклогом и задачами в реальном времени. Нужны декомпозиция, приоритизация, статусы, прозрачность выполнения, возможность быстро перестраивать план без потери контроля.

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

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

5. Аналитика исполнения и состояния проекта. Вместе со сроками и бюджетом важно отслеживать реальный прогресс: отклонения, узкие места, проблемы, риски.

Из технологических критериев стоит обратить внимание на:

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

• возможности разработки без кода или с низким его содержанием — чтобы иметь возможность настроить процессы самостоятельно;

• масштабируемость — чтобы система могла расширяться вместе с ростом количества проектов или их сложности;

• безопасность — чтобы защитить данные и управлять правами доступа пользователей;

• микросервисную архитектуру — чтобы получить гибкое распределение нагрузки и стабильность ПО.

Обзор популярных российских сервисов для управления ИТ-проектами

Directum Projects — платформенное решение для управления проектами, бизнес-процессами, командами, документами, задачами и знаниями

Система полностью импортонезависима и безопасна: разработана в России и включена в реестр отечественного ПО (№4499), доступно размещение в «облаке» и на сервере предприятия.

Поддерживает все виды методологий проектного управления. Вся функциональность доступна «из коробки» и работает в едином контуре:

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

• бэклоги и задачи: приоритизация, декомпозиция задач, гибкие доски, свимлайны, WIP-ограничения. Команда получает понятные инструменты для работы и коммуницирует в системе, а не в сторонних сервисах;

• управление ресурсами: система учитывает доступность и компетенции сотрудников, помогает распределять задачи и контролировать загрузку. Благодаря чему видно, где специалисты действительно перегружены, а где ресурсы используются неэффективно;

• аналитика и контроль исполнения: есть возможность анализировать проекты в разных разрезах: по срокам, загрузке, прогрессу задач, отклонениям. Руководитель отслеживает не только план, но и реальное состояние проекта;

• база знаний и проектные артефакты: во встроенном редакторе фиксируются опыт, требования и решения. Все знания связаны с задачами и проектами, что обеспечивает прозрачность и переиспользование.

Система совместима с отечественным и свободно распространяемым ПО. Благодаря сервисам интеграции можно объединить любые инструменты, используемые в компании, в единую экосистему. Настроить Directum Projects под требования бизнеса поможет разработка без кода или с низким его содержанием (no-low-code).

Из плюсов пользователи отмечают удобную интеграцию, быстродействие системы, понятную логику процессов, легкую доработку под процессы компании, «закрытие» всех задач проектной деятельности. Из минусов — ограниченное количество информационных панелей (дашбордов).

Цена: от 8190 рублей в год за человека.

SimpleOne SDLC — специализированная система для управления полным циклом разработки ПО: от идеи до выпуска продукта

Включена в реестр отечественного программного обеспечения, развернуть систему можно в «облаке» или на инфраструктуре компании.

Доступны:

• управление разработкой: диаграмма Ганта, гибкие методологии, ИИ-анализ кода;

• связь с поддержкой: приоритизация заданий, формирование технического долга продукта;

• планирование и учет трудозатрат;

• библиотека документации: связь файлов с задачами и услугами;

• аналитика: кастомные формы отчетов, Agile-метрики;

• управление продуктом: иерархия, построение любой структуры.

Система совместима с Gitlab, имеет открытый интерфейс обмена данными (API) и возможности для гибкой кастомизации без привлечения вендора.

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

Из минусов — отсутствие сквозного поиска данных, перегруженный интерфейс и сложность координации.

Цена: по запросу.

EvaProject — отечественная система управления проектами и командами

Аналог Jira, включен в реестр российского программного обеспечения. Доступна облачная и локальная поставка.

Система дает возможность управлять:

• жизненным циклом разработки и задачами от постановки до релиза;

• бэклогом и спринтами: есть приоритизация и контроль выполнения;

• релизами и дорожной картой: можно спланировать этапы поставки и развития продукта;

• изменениями: фиксируются и контролируются все корректировки;

• импортом данных из зарубежных решений;

• прогрессом: в систему «заведены» информационные панели для мониторинга задач, загрузки и выполнения проекта.

Интегрировать EvaProject в корпоративную среду можно при помощи открытого интерфейса данных (API), также доступна кастомизация интерфейса, полей и процессов.

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

Цена: от 450 рублей в месяц за человека.

Яндекс Трекер — облачный сервис для управления проектами

Сервис входит в экосистему Яндекс 360: можно «подтягивать» почту, синхронизировать встречи с календарем и ставить задачи из писем. Включен в реестр отечественного ПО.

Ключевые возможности:

• организация совместной работы: можно объединять разные команды в одном проекте;

• учет ресурсов: у пользователей есть возможность заранее спрогнозировать трудоемкость;

• классика и гибкость: доступны доски и диаграмма Ганта;

• шаблоны проектов и автоматизация рутинных действий: создание чек-листов, рассылка сообщений и пр.;

• отдельные рабочие пространства для участников проектов.

Возможность интеграции со сторонними сервисами, соответствует методологии OKR. Есть мобильное приложение, но с ограниченной функциональностью.

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

Цена: от 399 рублей в месяц за человека.

Timetta — отечественная ИСУП, ориентированная на контроль ресурсов и экономику проектов

Программа подходит для компаний с проектной моделью бизнеса (интеграторы, консалтинг, ИТ-подразделения). Доступна в облаке и локальной поставке (on-premise).

Функциональность и особенности:

• фокус на экономике проектов, учет трудозатрат, расчет себестоимости и маржинальности;

• контроль загрузки команды, благодаря чему видно, кто перегружен, а кто только делает вид, что работает;

• связка плана и факта: есть возможность сравнить запланированные и реальные трудозатраты;

• управление портфелем через ресурсы и деньги, приоритизация с учетом загрузки и финансового эффекта;

• понятная аналитика, отчеты по эффективности проектов и использованию ресурсов в разных разрезах.

Можно адаптировать систему под потребности компании.

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

Цена: от 1105 рублей в месяц за лицензию.

Основные функциональные критерии отечественных ИСУП

Итог

Какую систему управления ИТ-проектами выбрать, решать вам. Оцените уже сформировавшиеся в компании бизнес-процессы, проанализируйте рынок и функциональность представленных ИТ-решений, посчитайте пользователей, примерьте инструменты к своим задачам, проведите пилотный проект и проанализируйте, куда и в каких масштабах будет расти бизнес в ближайшие 5 лет. Так вы получите ИСУП, которая будет максимально соответствовать вашим запросам.

На связи команда облачного провайдера Beget – сегодня мы расскажем, как можно сэкономить на хранении данных, когда их становится всё больше.

Мы с вами живем в цифровую эпоху, где ежедневно создается приблизительно 402,74 млн терабайт информации, а данные – один из ключевых ресурсов каждого бизнеса.

Изображения, видео, документы, пользовательские файлы, резервные копии – их объем постоянно растет: по статистике, неструктурированные наборы данных составляют 90% всей информации, генерируемой предприятиями, а ее размеры зачастую достигают терабайтов или петабайтов.

И вместе с этим, соответственно, увеличиваются требования к инфраструктуре и расходы на ее содержание.

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

В этих реалиях возникает задача – как сократить расходы на хранение данных и не потерять к ним доступ.

Расскажем о решении, которое может в этом помочь.

Когда серверу становится тесно

Зачастую это происходит внезапно: сначала серверу хватает места, а через несколько месяцев – уже нет: добавляются новые файлы, а вместе с ними растут и затраты на инфраструктуру.

Однако не всей информации нужны ресурсы основного сервера – вот примеры данных, которые так хранить необязательно:

· резервные копии;

· архивы и старые версии файлов;

· логи и истории событий;

· изображения, видео и другой медиаконтент;

· документы, которые редко используются;

· выгрузки и результаты обработки данных;

· дистрибутивы, установочные файлы и образы;

· данные для долгосрочного хранения и аудита.

Ко многим из этих данных обращаются редко, а хранить их нужно постоянно.

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

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

Что дает объектное хранилище

· Моментальное масштабирование – облачное хранилище S3 расширяется автоматически, загружайте столько данных, сколько потребуется.

· Надежность и доступность – при аренде S3-хранилища данные хранятся в 3 копиях и размещаются на независимых серверах в разных стойках для абсолютной сохранности.

· Гибкое управление – версионирование, настройка доступа и классы хранения позволяют контролировать, где и как хранятся данные.

· Доступ к данным 24/7 из любой точки мира и из любого браузера.

· Удобная модель оплаты Pay as you go – оплачивайте только тот объем, который используете.

В настоящее время S3 хранит сотни эксабайт данных в сотнях триллионов объектов, обрабатывая в среднем более 200 миллионов запросов в секунду.

Разберем конкретнее, какую пользу объектное хранилище может принести бизнесу.

S3 на практике: кто и как использует

Итак, объектное хранилище может пригодиться для:

· хранения бэкапов, отчетов, медиафайлов и другого контента отдельно от серверов – чтобы сэкономить и снизить риск потери данных при сбоях;

· архивирования – сохраняйте редко используемые документы, логи и старые версии файлов без нагрузки на основные диски;

· обмена данными между сервисами – можно организовать единое хранилище для микросервисов и упростить передачу файлов между ними;

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

S3 используют более 398 тысяч компаний – и вот лишь несколько примеров результатов:

· производитель шин Apollo Tyres – на 90% снизил затраты на резервное копирование за 2 года на трех из семи своих заводов;

· платформа EZJobs – снизила затраты на 50% благодаря интеллектуальному многоуровневому хранению;

· маркетплейс Ozon – благодаря дедупликации в среднем сэкономил на обработке данных около 13% по всем бакетам;

· технологическая компания Bynder – сэкономила 65% затрат на хранение данных о клиентах благодаря системам интеллектуального многоуровневого хранения S3;

· финансовый маркетплейс “Сравни” – уменьшил затраты на инфраструктуру БД в 1,5 раза.

На примере этих и других компаний заметно, что объектное хранилище S3 помогает решать сразу несколько бизнес-задач – сокращать расходы на хранение, разгружать серверную инфраструктуру и масштабировать объем данных без сложных перестроек.

Если у вашего проекта большое количество данных и вы хотите оптимизировать расходы на их хранение, то создать объектное хранилище S3 в Beget буквально в один клик можно уже сейчас.

Заключение

Примерно 90% из генерируемых пользователями данных являются неструктурированными.

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

При этом экономия на хранении данных – далеко не единственная задача, которую могут помочь решить продукты Beget, например, вы также можете:

· развернуть производительный VPS с готовностью за 10 секунд и готовыми решениями для ваших задач;

· подключить мощные облачные базы данных для разработки сложных веб-сервисов и приложений;

· настроить сеть доставки контента для снижения нагрузки на сервер и увеличения скорости загрузки сайта;

· удобно управлять инфраструктурой – с Kubernetes;

· обеспечить контроль и прозрачность изменений – с Terraform.

А еще облако Beget – это:

· глобальный охват – выбирайте локацию серверов в России или Казахстане и будьте ближе к вашей аудитории;

· новейшее железо – мощные серверные решения на базе Amd Epyc с NVMe-дисками;

· надежность и стабильность – благодаря uptime 99,98% и дата-центрам Tier III (стандарт с защитой от аварийных ситуаций);

· бесплатные автоматические бэкапы – копии создаются раз в 2–5 дней и хранятся на двух независимых серверах в разных дата-центрах;

· универсальный интерфейс – единая панель для управления всеми облачными решениями;

· комфортный мониторинг с возможностью кастомизировать правила для отслеживания состояния серверов;

· защита от атак – серверы защищены на сетевом и транспортном уровне (L3/L4), а наша собственная разработка Syncookied обеспечивает защиту от SYN/ACK/DATA-флуда;

· функциональный API – управляйте серверами и доменами без необходимости заходить в панель управления.

Если у вас остались вопросы, вы хотите обсудить эту статью или просто пообщаться с коллегами по цеху и сотрудниками Beget, будем рады видеть вас в нашем уютном Telegram-чате – с удовольствием на всё ответим и пообщаемся.

Также сейчас для новых пользователей мы начисляем 10% кешбэка за первое пополнение баланса – чтобы вы могли начать хранить данные еще выгоднее с самого первого дня.

Реклама. ООО «Бегет», ИНН 7801451618, erid: 2W5zFJqF2Y9

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

Учет — это всегда про прошлое

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

Учет отвечает на вопросы в прошедшем времени: что есть, где лежит, сколько осталось. Это снимок состояния на момент последней сверки. Необходимый для бухгалтерии, но практически бесполезный для вас.

Управление — это взгляд в будущее: у какого железа через полгода заканчивается жизненный цикл? Что нужно докупить до того, как это станет проблемой? На каком оборудовании пора планировать замену, чтобы оно не умерло под нагрузкой?

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

Чем оборачивается такой подход:

• Внезапными поломками. Не потому что железо плохое, а потому что плановое обслуживание никто не отслеживал.
• Хищениями и потерями, которые обнаруживаются через полгода, когда уже никто не помнит, кто последним брал пропавший монитор.
• Закупками вслепую. Бизнес заказывает новую партию техники, а на складе пылятся нераспакованные коробки. Или наоборот — все уверены в наличии запаса, а его нет.
• Лицензионными сюрпризами. Приходит проверка и выясняется, что количество лицензий меньше числа инсталляций.

Отдельная боль — инструменты

Некоторые вендоры продают под видом ITAM-систем по сути те же таблицы, только с веб-интерфейсом.

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

Если ваш ITAM требует, чтобы вы руками поддерживали его актуальность, — это не ITAM, а еще одна задача в вашем бэклоге.

Как выглядит нормальный подход

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

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

Когда данные начинают работать

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

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

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

Если у какого-то актива истекает гарантия, вы получаете уведомление и успеваете загнать железо в ремонт по гарантии, а не через 3 дня после ее окончания.

Кроме того, система с заданной периодичностью сама опрашивает сеть. Частоту выставляете вы — под то, насколько динамично живет ваш парк.

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

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

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

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

Почему покупка инструмента ничего не даёт

Логичный ход в этой ситуации: купить ИИ и успокоиться. Так и сделали почти все, результат известен. По опросу McKinsey, регулярно применяют ИИ хотя бы в одной функции почти девять компаний из десяти, но прирост операционной прибыли от пяти процентов и выше связывают с ним около шести процентов. Предварительный отчёт MIT по корпоративным пилотам даёт картину ещё резче, хотя выборка там небольшая и рецензирования он не проходил.

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

Шесть мест, где прежнее управление даёт сбой

Если разложить обычный день руководителя по слоям, сбои видно поимённо.

Встречи. Половину планёрки съедает пересказ статусов: работу памяти делают живые люди в самое дорогое время команды.

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

Память. Через полгода никто не помнит, почему выбрали именно это, и спор «мы договаривались иначе» решается не фактом, а тем, у кого увереннее интонация.

Делегирование. Задача уходит строчкой в трекере, картина остаётся у постановщика, дальше недели переписки «я не то имел в виду».

Команды. Что происходит внутри, руководитель узнаёт раз в месяц на отчётке, а люди на грани ухода отчётки не ждут.

Развитие. Честную обратную связь про себя руководитель получает раз в полгода, поэтому слепые зоны живут годами.

Ни один из этих сбоев не новый. Новое то, что в прежнем темпе они были терпимы, а в нынешнем перестали, и первым это чувствует самый загруженный.

Глория Марк из Калифорнийского университета в Ирвайне меряла, что происходит с человеком, которого постоянно дёргают: прерванную работу люди дописывают не медленнее, но платят за это стрессом, спешкой и заметно большим усилием на тот же объём. Возврат к прерванной задаче она оценивала примерно в 23 минуты, и это не выброшенное время, а время, в течение которого голова тащит несколько контекстов сразу. У руководителя таких переключений десятки в день. Дело не в собранности: человеческий мозг просто не рассчитан на тот объём, который на него грузят.

Три операции, которые стали дефицитом

Здесь стоит сказать прямо, кого это касается в первую очередь. Войти в контекст, принять решение и передать его дальше вместе со смыслом это не работа тех, кто пишет код. Это работа руководителя команды, проектного менеджера и продакта, то есть ровно тех ролей, которым последние годы приходилось объяснять бизнесу, зачем они нужны, если продукт делают инженеры.

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

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

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

Кто такой руководитель нового типа

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

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

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

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

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

Что это дало в цифрах

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

Заметнее всего поменялись планёрки. Раньше около получаса из часа уходило на пересказ статусов, сейчас на это не уходит ничего: статусы собраны заранее и разосланы обеим сторонам до встречи, разговор начинается сразу с развилок. Час такой встречи закрывает порядка семи вопросов, большая часть мелкие, но раньше они расходились по переписке на неделю. Цикл «вопрос появился, решение принято» сжался с месяца до дня.

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

Есть и внешний замер. Доля положительных ответов по опроснику Gallup Q12 в направлении выросла до 86,7%, плюс 6,6 процентных пункта, и сильнее всего вырос пункт «получал признание за последние семь дней», плюс 16,6. Отнести это целиком на свою систему я не могу, в тот же период менялось многое. Но выросло сильнее всего ровно то, чем она занимается.

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

Делегировать надо контекст, а не строчку

Обычное делегирование устроено так. Руководитель формулирует задачу в две строки и отдаёт человеку, а вся картина остаётся у него в голове: зачем это делаем, что уже пробовали, чего боимся, кого ещё касается. Дальше человек восстанавливает её вопросами или, что хуже, не восстанавливает и делает не то. Мы годами считали это нормой, хотя это чистые потери. Теперь задача уходит вместе с контекстом: агент собирает историю темы, роль человека, связанные решения и ограничения, и всё это идёт частью постановки.

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

Здесь важна граница, и я её держу. Сам беру только то, чего иначе просто не появилось бы: черновики и прототипы, на которые никто не планировал время. Приоритеты команды я этим не двигаю и в чужой спринт не лезу.

С чего начинать

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

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

Что происходит с рутиной и с самим руководителем

Всё сказанное выше звучит как реклама, поэтому дальше вторая половина.

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

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

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

Потолок поднимается не покупкой. Инструмент можно купить в любой момент, а память можно только накопить, и эта фора набирается каждый день, пока вы решаете, начинать или нет.

• Учетная запись имела многофакторную аутентификацию (что после компрометации сессии значения не имеет).
• SIEM собирал события, но расследование затруднялось тем, что в разных источниках один и тот же пользователь имел разные идентификаторы.
• Доступ сотрудника был вовремя отозван в Active Directory, но остался в одном из SaaS-сервисов.
• Резервное копирование выполнялось ежедневно, но восстановить критичный сервис в установленный RTO невозможно.

Значит ли это, что мы должны отказываться от формальностей? Нет, конечно. Соответствие требованиям необходимо. Без него невозможно выстроить управление ИБ, тем более в регулируемых отраслях.

Но здесь легко попасть в ловушку формального контроля,

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

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

№1. Управление доступом

Классическая проверка часто выглядит довольно просто: открыл карточку пользователя — посмотрел назначенные роли. Но современные корпоративные инфраструктуры редко устроены настолько просто:

• права могут наследоваться через группы;
• группы могут быть вложенными;
• доступ может назначаться через роли приложений;
• часть полномочий приходит из Active Directory, часть — из локальных каталогов приложений, часть — через облачные сервисы.

В результате пользователь может не иметь ни одной явно назначенной привилегированной роли, но при этом обладать весьма серьезными полномочиями. Условно: пользователь — группа А — группа Б — роль — ресурс.

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

• Отдельно у него есть доступ к справочнику контрагентов.
• Отдельно — возможность изменять определенные реквизиты

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

Как исправить?

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

Особенно внимательно стоит смотреть на привилегированные и конфликтующие полномочия.

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

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

Главный результат такой проверки для меня не количество найденных нарушений. Важнее понять, можем ли мы для каждого критичного доступа ответить на три вопроса:

• кто им обладает
• зачем он ему нужен
• что произойдет, если этот доступ будет скомпрометирован

№2. SIEM

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

Представим, что мы хотим понять, что делал пользователь за два часа до подозрительной операции.

• В Active Directory он имеет один идентификатор.
• В VPN используется логин в другом формате.
• В EDR устройство связано с третьим идентификатором.
• В бизнес-приложении пользователь представлен внутренним UUID.
• Часть сетевых событий вообще содержит только IP-адрес.
• При этом DHCP уже выдал этот адрес другому устройству.

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

Как исправить?

При проектировании мониторинга я бы оценивал не только количество подключенных источников. Эффективнее взять один реальный сценарий атаки и пройти его от начала до конца: какое событие появится первым, где оно окажется, с чем будет связано, кто и как его увидит, какие дополнительные данные сможет получить аналитик и сможет ли он восстановить всю цепочку действий. Если на каком-то этапе приходится вручную искать информацию в пяти разных системах, это уже часть проблемы.

№3. MFA

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

Допустим, сотрудник действительно проходит MFA. Что это дает? Снижается вероятность успешного использования украденного пароля. Но после успешной аутентификации возникает другая сущность — сессия.

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

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

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

Как исправить?

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

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

Кроме того, MFA не должна существовать изолированно. Ее эффективность существенно повышается, если события аутентификации связаны с данными IAM, EDR, VPN и SIEM.

Тогда вместо простого события «пользователь успешно прошел MFA» мы можем увидеть контекст:

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

Каждый признак отдельно может быть допустимым. Вместе они уже требуют внимания.

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

Это гораздо ближе к реальной модели угроз, чем простая галочка «MFA включена».

№4. Исключения

Это категория, которую часто недооценивают. Как часто вы слышали эти фразы:

• «У нас так принято».
• «Эта система всегда была доступна из этой сети».
• «Эти учетные записи давно никто не трогает».
• «Это временно, потом исправим».

Практически в любой крупной инфраструктуре есть системы, которые нельзя сразу перевести на стандартные политики:

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

Создаётся исключение. Изначально оно абсолютно рационально, но позже появляется проблема.

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

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

Как исправить?

Сделать исключения управляемыми.

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

На практике, я бы вел отдельный реестр исключений с такими полями:

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

Последний пункт особенно важен.

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

То есть исключение должно иметь цену. Если мы не можем применить основной контроль, мы должны понимать, чем компенсируем этот недостаток.

Еще одна практика, которую я считаю полезной, это автоматический пересмотр исключений. У исключения должна быть дата, когда его снова необходимо рассмотреть. Иначе временное решение очень быстро становится частью архитектуры.

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

№5. DLP

Еще одна интересная история происходит с защитой от утечек. Представим, что пользователь выгрузил 5 ГБ документов. На первый взгляд это серьезный повод для блокировки. Но теперь добавим контекст:

• Пользователь работает в подразделении, которое регулярно формирует архивы.
• Выгрузка выполняется в рабочее время.
• Получатель — внутренний корпоративный ресурс.

Такая операция может быть абсолютно нормальной.

Теперь другой сценарий. Пользователь обычно работает с несколькими десятками мегабайт в день. Сегодня в 02:00 он впервые подключился с нового устройства, скачал несколько ГБ архивов, после чего попытался передать их во внешний сервис. Объем тот же и с точки зрения простой сигнатурной логики — просто 5 ГБ, но по контексту совершенно другая история.

Поэтому эффективный контроль утечек данных давно не ограничивается вопросом: «Сколько данных передано?», а гораздо интереснее: кто, что, откуда, куда, когда, каким способом и насколько это соответствует его обычному поведению?

И именно здесь становится особенно важной интеграция DLP, IAM, UEBA, сетевой телеметрии и данных о бизнес-контексте. Отдельный продукт может увидеть только часть картины, а инцидент возникает на пересечении этих данных.

Как исправить?

Добавлять контекст к событиям DLP.

При настройке DLP я бы отдельно проверял не только политики блокировки, но и качество классификации данных, корректность исключений и интеграцию с IAM, SIEM и UEBA.

Очень важно также не пытаться блокировать все подозрительное автоматически.

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

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

№6. Время

Представим, что на одном сервере время отличается на три минуты. На другом используется другой часовой пояс. Ещё одна система пишет время в UTC.

Часть событий приходит в SIEM с задержкой и для обычной эксплуатации это может быть незаметно. Во время расследования трехминутная разница способна полностью изменить последовательность событий. А последовательность для расследования критична. Что было первым?

• Компрометация учетной записи?
• Создание нового процесса?
• Подключение к серверу?
• Выгрузка данных?
• Изменение прав?

Если временная шкала построена неправильно, то и аналитик может сделать неверный вывод даже при наличии всех необходимых событий. Поэтому качество телеметрии это не только вопрос того, собираются ли логи, это еще и вопрос, насколько этим логам можно доверять?

Как исправить?

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

Но одной синхронизации недостаточно.

Для SIEM важно привести события к единому формату времени и явно понимать, какое время записано в каждом событии: время возникновения события на источнике, время его обработки или время поступления в SIEM. Это три разных значения, и смешивать их при расследовании нельзя.

Отдельно я бы проверял задержку доставки событий. Например, сервер может корректно зафиксировать событие в 02:13, но SIEM получить его только в 02:16. Если аналитик строит временную шкалу только по времени поступления, последовательность действий уже будет искажена.

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

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

Если после такого теста невозможно уверенно сказать, какое событие произошло первым, значит проблема уже не в NTP. У нас проблема с доказательной базой для расследования.

№7. Автоматическое реагирование

Чем больше СЗИ появляется, тем сильнее желание автоматизировать реакцию.

• Обнаружили подозрительную активность — заблокировали пользователя.
• Нашли подозрительный процесс — остановили.
• Увидели аномальное подключение — заблокировали IP.

С технической точки зрения все логично. Но автоматизация сама становится источником риска.

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

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

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

Как исправить?

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

Условно, все реакции можно разделить на несколько уровней.

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

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

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

И обязательно должен существовать механизм отката. Если система автоматически заблокировала пользователя или изолировала сервер, должно быть понятно, кто, на основании чего и за какое время может вернуть его в рабочее состояние.

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

Как я бы проверял зрелость ИБ

Вообще, если посмотреть на большинство зрелых инфраструктур, можно заметить одну закономерность.

Проблема редко находится внутри одного средства защиты. Она возникает на стыке:

• IAM знает, кто пользователь.
• EDR знает, что происходило на его АРМе.
• SIEM видит последовательность событий.
• DLP знает, какие данные передавались.
• Сетевая инфраструктура знает, куда устанавливалось соединение.
• PAM записал сессию.

Но если эти данные не связываются, каждый продукт видит только свою часть атаки.

Например, EDR фиксирует запуск PowerShell, прокси видит соединение с внешним ресурсом, DLP видит обращение к чувствительному файлу, а IAM знает, что пользователь недавно получил повышенные права.

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

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

• Как получен доступ?
• Что видит IAM?
• Что видит EDR?
• Какие события попадают в SIEM?
• Как обнаруживается аномалия?
• Что происходит с сессией?
• Кто принимает решение?
• Какие действия будут предприняты?

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

Отдельно затронем метрики

Есть ещё одна проблема зрелой ИБ — неправильные метрики. Например, можно гордиться тем, что SOC обработал 50 000 алертов за месяц, но само число ничего не говорит, потому что можно сократить количество алертов в 10 раз и одновременно ухудшить безопасность, если просто отключить некоторое количество правил, а можно увеличить количество обнаруженных инцидентов и решить, что ситуация стала хуже, хотя по факту обнаружение улучшилось.

Поэтому метрика должна быть связана с конкретным результатом:

• Не «SIEM подключила 500 источников». А «Для X% критичных сценариев атаки SOC получает достаточный набор телеметрии для расследования».
• Не «Резервное копирование выполняется ежедневно». А «Критичная система восстанавливается за X часов при заданном сценарии отказа».
• Не «Права пользователей пересматриваются ежеквартально». А «X% привилегированных доступов имеют подтвержденного владельца, бизнес-обоснование и актуальную дату пересмотра».

Заключение

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

• MFA есть, но остается риск компрометации сессии
• PAM есть, но существуют обходные пути
• SIEM есть, но телеметрия не позволяет восстановить цепочку событий
• и т.д. и т.п.

Именно поэтому я бы не задавал вопрос: «Соответствует ли наша система требованиям ИБ?», правильнее задавать несколько более неприятных вопросов:

• Что конкретно произойдет при компрометации привилегированной учетной записи?
• Что мы увидим в первые пять минут?
• Какие данные позволят восстановить цепочку атаки?
• Какие защитные механизмы атакующий сможет обойти?
• Что произойдет, если один из них откажет?

И самое главное:

• Можем ли мы доказать на практике, что наша защита работает именно в том сценарии, от которого она должна нас защищать?

Но здесь не нужно противопоставлять compliance и техническую безопасность. Требования нужны. Аудиты нужны. Регламенты нужны. Но их правильнее воспринимать как нижний уровень системы управления.

После того как требование выполнено, мы должны понимать, а какой реальный риск мы этим контролем снижаем? Как мы проверим, что риск действительно снизился?

Если «понимание» заключается только в наличии документа, отчета или установленного класса решений, контроль, скорее всего, оценивается слишком формально. Если же можно показать реальный сценарий, измерить результат и воспроизвести его повторно, ситуация уже совсем другая.

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

Несмотря на турбулентную реальность, надо сказать, что мир всё равно открыт для тех, кто стремится найти работу мечты. Российские IT-специалисты до сих пор востребованы, но есть одно «но» — это документы.

Если говорить прямо, то виз, которые реально подходят IT-специалистам, не так уж и много: O-1 (та самая «виза талантов»), H-1B, L-1 и иногда J-1 для стажировок.

Начнём с визы L-1. Она подходит тем, кто уже работает в компании за пределами США и переводится в американский офис. Виза L-1 даёт возможность иностранным компаниям переводить сотрудников со специализированными знаниями или управленческими должностями в свои дочерние структуры в США. Очень часто ей пользуются владельцы бизнеса за рубежом, которые хотят открыть филиал или запустить новый бизнес в Америке. При этом важно, чтобы зарубежная компания была реально действующей: оцениваются её обороты, прибыльность, наличие офиса, сотрудники, объём продаж, клиенты и контракты.

H-1B — одна из самых известных рабочих виз. Она позволяет американскому работодателю привезти иностранного специалиста, на позиции, требующие высшего образования. Все заявки участвуют в ежегодной лотерее, которая проходит в марте, и только отобранные кейсы идут дальше на рассмотрение. Виза выдаётся на три года с возможностью продления ещё на три. Её плюс в том, что не нужно доказывать выдающиеся достижения — достаточно профильного образования или релевантного опыта. Но важно понимать: подать на H-1B самостоятельно нельзя, петицию подаёт только работодатель. Участвовать в лотерее можно несколько раз. После выигрыша работодатель платит государственную пошлину за своего сотрудника в размере $100 000 за подачу петиции в USCIS.

И наконец, O-1 — виза талантов, то есть виза для людей с выдающимися способностями. Эта виза предоставляет максимальную профессиональную свободу: можно работать с несколькими компаниями и выстраивать более гибкую карьеру. Для IT речь идет о категории O-1 в области науки (Computer Science), и требования здесь выше, чем, например, для креативных профессий.

Для O-1 важно показать реальные достижения. Это может быть опыт работы в известных компаниях — Google, Amazon, Uber, Яндекс — и, да, такие бренды в резюме дают дополнительные очки, но это не единственный путь. У IT-специалистов часто бывают патенты на разработки, и здесь важно, чтобы имя было указано в самом патенте. Также учитывается участие в создании продуктов, которые затем патентуются, публикации в профессиональных или научных изданиях, участие в жюри конкурсов и в целом вклад в развитие индустрие индустрии инновационных продуктов.

Отдельный плюс визы талантов O-1 в том, что она не ограничена квотами и не привязана к лотерее — подаваться можно в любое время. Она выдаётся до трёх лет и может продлеваться неограниченно. При этом не требуется обязательное высшее образование. Есть возможность работать с несколькими работодателями одновременно или, например, развивать собственный стартап. Каждый кейс рассматривается индивидуально — на основе достижений. За последние годы отношение к этой визе сильно изменилось: если раньше работодатели относились к ней осторожно, то сегодня это уже нормальная практика — нанимать специалистов по O-1.

Если говорить о том, какие специалисты сейчас наиболее востребованы, то в первую очередь это AI/ML-направление — разработчики и исследователи, которые создают технологии в области искусственного интеллекта и машинного обучения. У них часто есть научные публикации, патенты и реальные внедрения.

Но это не значит, что нужно «подгонять себя» под тренд. Если у вас нет опыта в AI/ML, это не закрывает возможность получить визу талантов O-1. Если вы сильный специалист в своей нише и можете это доказать, шансы остаются высокими.

Помимо этого, достаточно много кейсов у специалистов в software development и systems engineering. Хорошо подходят product managers и особенно кандидаты на высоких позициях, таких как Chief Technology Officer. Сложнее — специалистам в области quality assurance, но и это не исключает возможность получения визы.

Если говорить о том, что стоит делать уже сейчас, то это работа на перспективу: участие в хакатонах, получение наград, судейство конкурсов, научные публикации, экспертные интервью в СМИ, работа над патентами — всё это формирует сильный профиль.

Стандартный путь от начала до получения визы занимает в среднем от четырёх до шести месяцев. Из возможных сложностей — административная проверка. IT-специалисты с российским гражданством с ней сталкиваются. Сейчас чаще, чем раньше. Это дополнительная проверка в посольстве, связанная с вопросами национальной безопасности, например проверкой на предмет работы с чувствительными технологиями или государственными структурами. Она может увеличить сроки рассмотрения.

Почему визуал считывается быстрее текста

Фирменный стиль — это система визуальных элементов и графических приёмов, которая помогает пользователю быстро считать бренд и понять контекст, в котором он существует. Люди сегодня выбирают «своё» среди огромного количества похожих продуктов и услуг не только по критерию «нравится/не нравится», но и через считывание категории: люкс, эконом, эко, спорт, детское направление.

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

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

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

Дизайн-система: баланс между «узнаваемо» и «не скучно»

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

Единообразие, которое даёт дизайн-система, — не то же самое, что «одинаковость». Здесь работают два противоположных критерия:

• Прочность — консистентность, повторение паттернов, строгое следование гайдам.
• Гибкость — вариативность, динамичность, способность обновляться.

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

Как собрать работающую дизайн-систему

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

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

Как понять, что дизайн-система работает

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

• NPS (индекс потребительской лояльности) — отслеживает удовлетворённость через анкетирование и опросы.
• BHT («здоровье бренда») — отражает позиции на рынке, уровень узнаваемости и лояльности.
• Эффективность рекламных кампаний — оценивает отклик аудитории на конкретные креативы.

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

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

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

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

Ниже рассмотрим два кейса: распознавание паспорта в видеопотоке и распознавание свидетельства о рождении по фотографии.

Оценка качества изображения

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

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

Законодательство РФ (включая 115-ФЗ) устанавливает конкретные требования к идентификации личности. Поэтому в случае с распознаванием недостаточно извлечь отдельные поля документа – нужно убедиться, что в кадре присутствуют все данные и элементы, необходимые для проверки. Контроль качества изображения в процессе распознавания документов решает эту задачу вместе с ещё одной: защищает от мошеннических атак.

При этом документы, используемые для подтверждения личности, отличаются форматом, шаблоном и набором защитных элементов, поэтому оценка качества должна учитывать особенности конкретного типа. К этому добавляется разница во входных данных: происходит ли распознавание в видеопотоке или по одному изображению. Дальше разберём два сценария, где эти различия проявляются особенно наглядно – распознавание паспорта в видеопотоке и распознавание свидетельства о рождении по фотографии.

Распознавание в браузере с помощью WebAssembly

Smart ID Engine может работать в браузере в виде WebAssembly-модуля. Это позволяет выполнять распознавание непосредственно на стороне клиента, не отправляя изображение документа на сервер.

Браузеры предоставляют следующие фичи в зависимости от возможностей устройства:

• Single Instruction Multiple Data (SIMD) – использование векторных инструкций процессора, которые позволяют значительно увеличить скорость вычислений.
• Threads – выполнение вычислений параллельно.

Проверить поддержку SIMD-инструкций и многопоточности в браузере можно с помощью библиотеки wasm-feature-detect.

Smart Engines предоставляет набор библиотек для всех комбинаций этих фич:

• nosimd.nothreads – базовая сборка, поддерживаемая везде.
• simd.nothreads – самая быстрая однопоточная сборка, поддерживается почти на всех современных устройствах (Safari 17.1+, Chrome 91+, Firefox 89+); часто является оптимальным выбором.
• simd.threads – сборка с поддержкой многопоточности; требует дополнительных настроек на сервере, но позволяет добиться максимальной производительности.
• nosimd.threads – редкая комбинация, она здесь на всякий случай.

Настройка веб-сервера

До подключения библиотеки к веб-приложению необходимо подготовить сервер, с которого браузер будет получать WASM-модули.

Первые два пункта являются строго обязательными для нормального функционирования библиотеки в браузере.

• Content-Type. Веб-сервер должен возвращать Content-Type: application/wasm для файлов с расширением *.wasm.
• Сжатие. Веб-сервер должен поддерживать компрессию файлов c расширением .wasm. WASM-файлы хорошо сжимаются и это значительно позволит сократить время доставки файлов до клиента. Убедитесь в наличии заголовка content-encoding у файла *.wasm при отдаче сервером. Рекомендуется отдавать wasm-файлы уже сжатыми, чтобы не нагружать сервер сжатием файлов на лету на каждый запрос.
• Поддержка CSP. Если у вас настроена строгая политика безопасности контента (CSP), она заблокирует JIT-компиляцию WebAssembly для защиты от XSS-атак. Для того, чтобы ее включить, необходимо добавить директиву wasm-unsafe-eval. Она разрешает выполнение только WebAssembly и в отличие от unsafe-eval по-прежнему блокирует вызовы JavaScript eval() и new Function(). Без этой директивы загрузка или инстанцирование (создание экземпляра) WASM-модуля будет невозможно.
• Многопоточность. Для использования многопоточной сборки браузеру дополнительно требуется обеспечить изоляцию контекста (Cross-Origin Isolation), настроив на сервере заголовки Cross-Origin-Opener-Policy и Cross-Origin-Embedder-Policy.

Например, в nginx это можно сделать, дописав в конфигурацию:

Камера

Широкоугольная камера

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

При этом на Android широкоугольные камеры могут давать изображение очень низкого качества, поэтому для Android-устройств наиболее универсальным решением будет использовать главный модуль камеры.

Разрешение

Существует распространенное представление о том, что для качественного распознавания изображение необходимо подавать в максимально возможном разрешении. Этот подход был оправдан для алгоритмов предыдущего поколения. Современные системы распознавания зависят от исходного разрешения гораздо меньше. По возможности лучше всегда избегать работы с большим объемом данных, поскольку это так или иначе добавляет накладные расходы на пересылку UI-> Worker->VM WASM.

Оценим необходимое разрешение для случая оценки качества. Для уверенного распознавания и проверки подлинности документа необходимо обеспечить не менее 120 DPI. Физический размер страницы паспорта составляет 88 × 125 мм. Будем считать, что разворот паспорта предъявляется наиболее естественным образом – вертикально. Это означает, что изображение паспорта должно иметь разрешение не менее 591 на 832 пикселей. Паспорт занимает не весь кадр; если он занимает 0.8 по ширине и высоте (около 65% от площади кадра), то необходимое разрешение получится 739 на 1040. Разумеется, лучше обеспечить некоторый запас по DPI и предусмотреть погрешности предъявления. При этом для съемки паспорта РФ лучше подходит формат кадра с соотношением сторон 4:3.

У свидетельства о рождении в формате А4 физический размер 210 × 297 мм или 8,27 × 11,69 дюйма. Если считать, что оно занимает по 0.9 кадра по каждой из сторон, необходимо разрешение 1102 на 1559. Тут также лучше подходит формат кадра 4:3.

В результате, оптимальным будет разрешение кадра 1600 на 1200 в вертикальной ориентации.

Отметим, что как правило у веб-камер даже сравнительно современных ноутбуков разрешение ограничено 720 на 1280 px, что ограничивает распознавание документов А4, таких как свидетельство о рождении. Дополнительно ситуацию может ухудшить отсутствие автофокуса.

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

Пример работы с камерой

Открываем камеру для съемки видео:

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

Базовые понятия библиотеки распознавания

После настройки веб-сервера можно переходить к интеграции распознавания. Ниже приведены базовые понятия библиотеки распознавания Smart Engines.

• Движок распознавания: создается один раз при старте приложения. От него создаются следующие элементы интерфейса:
• Сессия распознавания: процесс распознавания конкретного документа (паспорта РФ, ВУ, СТС и других – всего библиотека поддерживает более 3000 типов). В сессию можно передать одно изображение или серию кадров из видеопотока: с каждым новым кадром результат уточняется; система автоматически определяет оптимальный момент остановки сессии распознавания.
• Настройки сессии: хранят список доступных для распознавания типов документов (определяется конфигурационным бандлом), дополнительную информацию о каждом документе, а также позволяют настроить процесс распознавания: задать список ожидаемых типов документов для сессии распознавания, включить\выключить проверки признаков подлинности, задать таймаут для сессии распознавания и пр. Настройки создаются перед созданием самой сессии и не могут редактироваться в процессе распознавания.
• Результат распознавания: объект со структурированными текстовыми полями, изображениями (например, фото владельца), координатами документа на кадре и данными проверок подлинности.

Общая логика работы одинакова для любой платформы и любого продукта линейки Smart Engines: движок → настройки сессии → создание сессии → передача изображения / последовательности изображений → разбор результата.

Инициализация движка распознавания

Необходимо создать и инициализировать один экземпляр движка распознавания. Инициализация является достаточно «тяжелой» операцией, поэтому ее следует выполнять вне потока пользовательского интерфейса. Для этого используется Web Worker.

При распознавании в браузере полезно учитывать следующую опцию инициализации:

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

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

Конфигурирование сессии распознавания

Маска и режим

Сессия должна быть сконфигурирована для обнаружения конкретного типа документа или группы документов. Это осуществляется благодаря двум параметрам: маска (docTypes) и режим (mode):

Возможные значения маски и режима можно посмотреть в README конкретного WASM-модуля. Для примера с паспортом и свидетельством о рождении выберем режим anyrus (все российские документы) и любой тип (*).

Индивидуальная подпись (signature) привязана к конкретной сборке и необходима для инициализации сессии распознавания. Подпись представляет собой строку в 256 символов. activationUrl – адрес сервера активации, про который речь пойдет в следующем разделе.

Терминальность

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

• Stoppers. Когда все поля уверенно распознались, движок выставляет результату флаг "терминальности". В этом случае подача дополнительных кадров не улучшит результаты.
• Timeout. Когда истек заданный таймаут, чтобы ограничить возможное ожидание пользователя. Для режима Quality Gate характерное значение таймаута составляет около 15 секунд, чтобы пользователь успел скорректировать найденные проблемы.

Для такой настройки сессии необходимо поставить опции:

Quality Gate

Для включения Quality Gate необходимо указать следующие опции:

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

Активация сессии распознавания

Поскольку WASM-модуль загружается с сервера на устройство пользователя, его достаточно легко скопировать. Для защиты от несанкционированного использования Smart ID Engine предусматривает привязку к инфраструктуре заказчика с помощью механизма активаций.

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

Рассмотрим пример. Создадим сессию:

Активируем сессию:

Теперь сессию можно использовать для распознавания.

Изображение и процесс распознавания

Создание объекта изображения документа Image

В браузере библиотека Smart Engines работает только с сырыми пикселями RGBA/RGB/YUV. Работа со сжатыми форматами jpg/gif/png/heic переложена на canvas браузера. Это позволяет читать изображения как с камеры, так и получить поддержку всех нативных форматов платформы и даже работу с PDF.

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

Процесс распознавания

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

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

Разбор результата распознавания с оценкой качества

В качестве результата система Smart Engines возвращает набор распознанных полей с текстом или изображениями (например, поле фотографии). При включении проверки качества в результат добавляется поле image_quality_score, которое содержит численную оценку качества изображения от 0 до 1, а также атрибут reason, который содержит список проблем изображения. Возможные проблемы:

• finger_is_found (Найден палец)
• zone_is_invalid (Зона обрезана)
• hlt_is_found (Найден блик)
• optic_is_found (Найдена голограмма)
• «low DPI» (Низкое разрешение)
• focus (Кадр не в фокусе)
• luminosity (Слишком темно / слишком ярко)

При включении опции common.extractRectifiedDocumentImage добавляется поле-изображение rectified_document_image, содержащее проективно исправленное изображение.

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

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

Интеграция распознавания в веб-приложение

Рассмотрим интеграцию распознавания паспорта РФ в видеопотоке в веб-приложение. Чтобы распознавать изображения с камеры в реальном времени, понадобятся элементы video и canvas для вывода изображения с камеры.

Кнопка для начала распознавания изображения:

Блок для вывода результатов распознавания:

Клиентский JavaScript-код

Работа с камерой

В JavaScript-файле запрашиваем видеопоток с камеры:

И направляем его в элемент video на странице:

Теперь на странице отображается видео с камеры.

Передаём видео в canvas.

Чтобы захватывать и передавать кадры на распознавание, необходимо предварительно отрисовать их на canvas.

Подключение движка

В процессе подключения движка определяются возможности среды исполнения (поддержка SIMD и многопоточности), и подключается соответствующий Wasm-модуль.

Подключение веб-воркера

Подключим веб-воркер и передадим ему тип документа, который собираемся распознать:

По нажатию на кнопку, отправляем воркеру кадр из видео на распознавание:

Результат распознавания содержит текст и изображения отдельных элементов документа, выведем их:

Выведем результаты оценки качества:

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

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

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

Управление памятью

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

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

Пример освобождения памяти в finally, после получения данных о распознанном кадре:

Заключение

Распознавание документов в браузере требует не только переноса OCR на веб-страницу, но и построения полноценного пользовательского сценария предъявления документа. Контроль качества изображения играет в нем определяющую роль, позволяя одновременно решать две задачи:

• оценивать читаемость данных и при необходимости помогать пользователю;
• защищаться от атак на предъявление в случае намеренного перекрытия реквизитов или значимых признаков подлинности документов.

Такой механизм позволяет минимизировать число неудачных попыток и сделать процесс идентификации прозрачным и максимально удобным для пользователя. А выполнение обработки непосредственно в браузере с помощью WebAssembly дает возможность реализовать этот сценарий непосредственно на пользовательском устройстве – без передачи изображений документов на внешний сервер.

Браузерное распознавание документов – не единственный вариант интеграции SDK Smart Engines. Та же библиотека может работать и на сервере, как часть десктоп-приложения (например, для работы с планшетными сканерами и веб-камерами) или мобильные приложения. Выбор конкретного варианта зависит от того, какие документы нужно распознавать и откуда поступает изображение – подробнее об этом можно прочитать на сайте Smart Engines.

Реклама. Рекламодатель: ООО «Смарт Энджинс Сервис» ИНН 7728328449, erid: 2W5zFK8Vyh3

Timetta — российская PPM-платформа с финансовым учётом, портфелями и on-premise для крупных компаний.

GanttPRO — специализированный онлайн-инструмент для диаграмм Ганта с импортом MS Project и простым интерфейсом.

Kaiten — российский сервис для гибридного управления: Kanban, Scrum, Гант и модульная тарификация.

Redmine — бесплатное open-source решение для команд, готовых самостоятельно разворачивать и дорабатывать систему.

Как мы выбирали

Критерии отбора были простыми и близкими к реальным задачам проектных офисов: полноценная диаграмма Ганта с зависимостями, управление ресурсами и загрузкой, возможность учитывать трудозатраты и бюджеты, поддержка импорта из MS Project или Excel, а также российская доступность — оплата, поддержка, документы и размещение данных.

Все участники проверены по официальным источникам. Цены и условия указаны по данным сайтов на лето 2026 года и могут меняться, поэтому перед покупкой стоит свериться с актуальным прайс-листом.

1. Timetta — портфели и финансы

Timetta — российская корпоративная система для управления проектами, ресурсами, трудозатратами и финансами. Она ориентирована на проектные офисы, ИТ-интеграторов, консалтинговые и инжиниринговые компании, которым нужно вести сроки, людей и деньги в одном пространстве.

Кейсы клиентов и кому подойдёт

• Проектный офис крупной ИТ-компании. В Газпром ЦПС Timetta используется как единое пространство для управления портфелем из 180+ проектов.
• Руководители проектов и финансисты. Комита ЦТ собирает трудозатраты через таймшиты и контролирует рентабельность проектов.
• Ресурсные менеджеры. В GMCS система помогла сделать прозрачной загрузку сотрудников и снизить конфликты за ресурсы между направлениями.

Что можно развернуть

Платформа покрывает полный цикл проектного бизнеса:

• проекты, программы и портфели
• диаграммы Ганта с вехами, зависимостями и критическим путём
  
• таск-трекер с бэклогом и спринтами
  
• бронирование ресурсов и загрузка сотрудников
  
• таймшиты и учёт отсутствий
• заявки на затраты, платёжные календари и процесс почасового биллинга,
• P&L-отчёты, клиенты и сделки
  
• корпоративная вики и ИИ-ассистент
  

Инфраструктура и экосистема

Timetta работает в облаке (SaaS) и в виде on-premise-развёртывания в инфраструктуре заказчика. Данные хранятся на защищённых российских серверах, система соответствует 152-ФЗ и включена в реестр российского ПО (запись № 18250 от 05.07.2023). Доступен OData API с авторизацией OAuth 2.0, готовые интеграции с 1С:УХ и 1С:ЗУП, обработчики и сценарии автоматизации.

Отзывы и репутация

Среди публичных клиентов — Газпром ЦПС, Комита ЦТ, GMCS. Вендор публикует кейсы внедрений на сайте, но агрегированных рейтингов на независимых площадках мало, поэтому сравнивать по звёздам затруднительно.

Поддержка и каналы связи

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

Тарифы, ограничения и условия

Стоимость зависит от выбранных приложений, числа пользователей и срока лицензии. По данным прайс-листа, лицензии на отдельные приложения начинаются от 350 ₽ за пользователя в месяц (например, Timetta Expenses), до 3500 ₽ за Timetta Corp.

Для небольших команд есть отдельная бесплатная сборка Timetta Lite: тариф Free доступен без ограничения по сроку для 10 активных пользователей и теперь включает таймшиты, а для команд на 11–50 человек действует платный тариф Team — 1 490 ₽ за пользователя в месяц (подробнее — в блоге Timetta). On-premise доступен для корпоративных клиентов, стоимость рассчитывается индивидуально. Работа с юрлицами ведётся по договору с закрывающими документами.

Официальный сайт: timetta.com

2. GanttPRO — специализация на Гантах

GanttPRO — онлайн-инструмент для управления проектами, построенный вокруг интерактивной диаграммы Ганта. Он подходит командам, которым нужна быстрая визуализация сроков, зависимостей и ресурсов без сложного внедрения.

Кейсы клиентов и кому подойдёт

• Менеджеры проектов среднего звена. Интерфейс заточен под планирование сроков и контроль дедлайнов без IT-отдела.
• Маркетинговые и event-команды. Удобно строить таймлайны кампаний, делиться планами с заказчиками по публичной ссылке.
• Команды, мигрирующие с MS Project. Поддерживается импорт из MS Project, что упрощает перенос существующих планов.

Что можно развернуть

GanttPRO предлагает диаграмму Ганта с зависимостями, автопланированием и критическим путём; иерархию задач и WBS; представления доски, списка, календаря, дашборда, портфеля и загрузки ресурсов; учёт рабочей нагрузки, бюджетирование и тайм-трекинг на старших тарифах; комментарии к задачам, вложения, упоминания и публичные ссылки для демонстрации планов; экспорт в PDF, PNG и Excel.

Инфраструктура и экосистема

Решение работает полностью в браузере, без установки десктопного клиента. Данные хранятся в дата-центрах Microsoft Azure в ЕС. Поддерживаются основные платежные методы, включая карты и PayPal; для компаний доступна оплата по счёту. API есть, но собственная экосистема интеграций у GanttPRO уже, чем у крупных платформ вроде monday.com или Wrike.

Отзывы и репутация

По данным GanttPRO, инструментом пользуются более 1 млн проектных менеджеров. На Capterra сервис получает высокие оценки за удобство диаграмм Ганта (около 4,8/5). Часто отмечают чистый интерфейс и быстрый старт; среди ограничений — узкая экосистема интеграций и менее глубокие отчёты по сравнению с enterprise-PPM.

Поддержка и каналы связи

Поддержка доступна через email и базу знаний. На тарифе Enterprise предусмотрен приоритетный канал поддержки и enterprise onboarding. Документация и обучающие материалы публикуются на сайте.

Тарифы, ограничения и условия

GanttPRO работает по подписке. Тариф Core стоит от $7 за пользователя в месяц при годовой оплате, Advanced — $10, Business — $17, Enterprise — $25. Бесплатного тарифа нет, но доступен 14-дневный пробный период без привязки карты. Некоторые функции, например workload management и портфели, открываются только на тарифах Business и выше.

Официальный сайт: ganttpro.com

3. Kaiten — Agile и Гант

Kaiten — российская платформа для управления задачами, проектами и командами. Изначально позиционировалась как альтернатива Jira, Trello и Asana, но сегодня покрывает и классическое планирование через диаграмму Ганта, и гибкие методологии.

Кейсы клиентов и кому подойдёт

• IT-команды и продуктовые подразделения. X5 Tech использовала Kaiten при миграции из Jira, сохранив привычный подход к задачам.
• Ритейл и производство. Сервис работает в компаниях ВкусВилл, Мегафон, Додо Пицца, технопарке «Сколково».
• Команды, которым нужен единый инструмент. В Kaiten совмещены Kanban, Scrum, Гант, документы, базы знаний и служба поддержки.

Что можно развернуть

Доступны канбан-доски с WIP-лимитами и дорожками, скрам-доски со спринтами, burndown-диаграммами и velocity; диаграмма Ганта, ресурсное планирование и зависимости между задачами; документы и базы знаний; автоматизации через конструктор правил и триггеров; AI-транскрибатор встреч и AI-помощник для оформления задач; отчёты по загрузке, lead time, block time и cumulative flow; мобильные приложения для iOS и Android.

Инфраструктура и экосистема

Kaiten работает в облаке и предлагает серверную версию на Docker для тарифа «Корпорация» (от 300 пользователей). Продукт включён в реестр российского ПО, данные хранятся в России, оплата производится в рублях. Интеграции включают Jira, Trello, Notion, Asana, ClickUp, GitHub, GitLab, Slack, Telegram, Google Календарь и Яндекс Календарь.

Отзывы и репутация

По данным сайта, сервисом пользуются более 200 тысяч компаний. Публикуются именные кейсы клиентов: Buzzolls, «Сколково», X5 Tech, «Продман», «Авиационный Консалтинг-ТЕХНО». В независимых обзорах отмечают удобный интерфейс и рублёвую оплату; ограничения — функционал для портфельного управления и глубокого финансового учёта уступает специализированным PPM-системам.

Поддержка и каналы связи

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

Тарифы, ограничения и условия

Бесплатный тариф — до 5 пользователей с базовыми функциями. Платные тарифы: «Старт» от 185 ₽ за пользователя в месяц (при оплате на 36 месяцев), до 15 пользователей, включены модули Scrum и Kanban; «Стандарт» от 430 ₽ за пользователя в месяц, до 250 пользователей, два модуля на выбор; «Бизнес» от 580 ₽ за пользователя, до 250 пользователей, шесть модулей; «Корпорация» — индивидуальная цена, on-premise, от 300 пользователей. Каждый дополнительный модуль — от 80 ₽ за пользователя. Пробный период — 14 дней со всеми модулями.

Официальный сайт: kaiten.ru

4. Redmine — open source

Redmine — бесплатная open-source система управления проектами на Ruby on Rails. Это выбор для команд, у которых есть технические ресурсы для развёртывания и настройки, и которые не хотят зависеть от вендора и регулярных лицензионных платежей.

Кейсы клиентов и кому подойдёт

• Разработческие и IT-команды. Встроенная интеграция с Git, SVN, Mercurial, CVS и гибкая система трекинга задач.
• Компании с жёсткими требованиями к данным. Можно развернуть полностью в собственной инфраструктуре и контролировать доступ.
• Бюджетные проекты. Подходит стартапам, образовательным учреждениям и НКО, готовым потратить время на настройку вместо денег на лицензии.

Что можно развернуть

Redmine поддерживает управление несколькими проектами, гибкую ролевую модель доступа, трекинг задач с кастомными полями и workflows, диаграмму Ганта и календарь, wiki и форумы для каждого проекта, учёт времени, документы и файлы, email-уведомления, интеграцию с LDAP и SCM, создание задач по email. Функциональность расширяется сотнями плагинов сообщества.

Инфраструктура и экосистема

Решение распространяется под лицензией GNU GPL v2 и разворачивается на собственных серверах или в облаке. Поддерживаются разные СУБД (PostgreSQL, MySQL, SQLite) и ОС. API доступен для интеграций, но большинство интеграций реализуется через плагины или собственную разработку.

Отзывы и репутация

Redmine существует с 2006 года и имеет активное международное сообщество. Среди известных пользователей — множество open-source проектов, компаний в сфере IT, инжиниринга и консалтинга. В обзорах отмечают гибкость и отсутствие лицензионных платежей; к недостаткам относят устаревший интерфейс и необходимость в администрировании.

Поддержка и каналы связи

Официальная поддержка сообщества: форумы Redmine, IRC-канал #redmine в сети libera.chat, неофициальный Slack. Документация включает User's Guide, Developer's Guide, FAQ и HowTos. Коммерческую поддержку и хостинг предоставляют сторонние провайдеры, цены зависят от поставщика.

Тарифы, ограничения и условия

Сам Redmine бесплатен: нет лицензионных платежей и ограничений по числу пользователей или проектов. Реальные затраты — на собственное железо или облачный хостинг, администрирование и нужные плагины. Готовые хостинговые версии от сторонних провайдеров стоят от $10–25 за пользователя в месяц, но это цена провайдера, а не вендора.

Официальный сайт: redmine.org

Сравнение по ключевым критериям

Диаграмма Ганта и зависимости. Timetta и GanttPRO предлагают наиболее зрелый Гант с критическим путём и автопланированием. У Kaiten Гант доступен как подключаемый модуль, у Redmine — базовый, но функциональный.

Управление ресурсами. Timetta выделяется ресурсным планированием, бронированием и портфельной загрузкой. GanttPRO и Kaiten дают workload-вид, Redmine требует плагинов для глубокого ресурсного учёта.

Финансы и бюджеты. Timetta — единственный из четырёх с полноценным P&L, себестоимостью и взаиморасчётами. GanttPRO и Kaiten закрывают базовое бюджетирование, Redmine — через плагины.

Гибкие методологии. Kaiten лидирует по Kanban и Scrum из коробки. Timetta поддерживает гибридные схемы, GanttPRO ориентирован на классику, Redmine гибок через настройку workflows.

Размещение данных. Timetta и Kaiten предлагают российское облако и on-premise. GanttPRO хранит данные в Azure ЕС. Redmine разворачивается где угодно, включая собственный сервер.

Стоимость. Redmine бесплатен по лицензии, но требует ресурсов на поддержку. Kaiten стартует с бесплатного тарифа и далее от 185 ₽. GanttPRO — от $7. Timetta — индивидуально, с бесплатным тарифом Timetta Lite (Free) для команд до 10 пользователей.

Выводы

Прямого универсального заменителя MS Project не существует: каждый инструмент делает ставку на свои сценарии. Для крупного проектного офиса с финансовым контролем и портфелями логичнее смотреть на Timetta. Если главное — удобная диаграмма Ганта с быстрым стартом и импортом из MS Project, выбор GanttPRO выглядит естественным. Командам, которые живут в Kanban/Scrum, но иногда нужен Гант, подойдёт Kaiten. А Redmine остаётся рабочей лошадкой для технических команд, готовых взять на себя развёртывание и поддержку.

Я никогда так не ошибалась.

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

При этом ТЗ всё ещё не было.

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

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

Хочешь сделать лотерею — думай «как лотерея»

На старте мы знали только одну вещь: клиент должен получить возможность покупать лотерейные билеты внутри мобильного банка. Всё остальное было как в тумане.

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

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

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

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

В лотерее главное — ожидание

Именно тогда в проекте появился эмоциональный CJM. Если обычный клиентский путь отвечает на вопрос «что делает клиент», то эмоциональный пытается ответить на вопрос «что он чувствует». Для лотереи эта разница оказалась принципиальной. Человек покупает не набор цифр и даже не шанс на выигрыш. Он покупает надежду, ожидание и эмоциональный опыт.

Когда мы нанесли эмоции на клиентский путь, начали появляться требования, которые никогда бы не возникли в обычном CJM. Например, сразу после покупки эмоция клиента была скорее позитивной: билет куплен, комбинация выбрана, появляется предвкушение.

Но дальше начинался длинный период ожидания.

Чем ближе был тираж, тем сильнее рос интерес, а вместе с ним количество вопросов: когда розыгрыш, где его посмотреть, как я узнаю результат? После тиража возникала уже другая потребность: как можно быстрее снять неопределенность и понять, выиграл я или нет?

Мы буквально наносили эти эмоциональные состояния на каждый этап CJM и смотрели, где продукт оставляет клиента один на один с ожиданием.

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

Все остальное время клиент ждет: ждет тираж, ждет результаты, ждет уведомление, ждет выигрыш. Получалось, что основная часть клиентского опыта строится вокруг ожидания(?)

Именно поэтому в какой-то момент команда начала обсуждать трансляцию розыгрыша как полноценную продуктовую фичу, а не как дополнительный “бантик”. С точки зрения разработки она выглядела второстепенной. А с точки зрения эмоций клиента являлась кульминацией всего сценария!

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

Закон — это база для требований

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

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

Одним из основных источников требований стал Федеральный закон 138-ФЗ «О лотереях». Например, именно из законодательства и условий проведения конкретной лотереи мы выясняли, что покупатель становится участником лотереи сразу после оплаты и оформления лотерейного билета, какие обязанности возникают у распространителя: от условий участия и онлайн-распространения билетов до правил выплаты выигрышей и работы с данными участников.

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

И тут выяснилось неожиданное: привычного нам сценария «отменить покупку» здесь просто нет.

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

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

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

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

• Нужно ли идентифицировать клиента?
• Какая у него налоговая ставка?
• Является ли он налоговым резидентом?
• Какой доход он уже получил с начала года?
• Кто выступает налоговым агентом?
• Какие данные необходимо получить из внутренних систем банка?
• Какие документы нужно сформировать?
• Какие данные передать партнеру?
• В какой момент считать выплату завершенной?

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

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

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

В результате обсуждение требований 54-ФЗ стало занимать в календаре не меньше места, чем обсуждение мобильных интерфейсов.

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

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

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

Это была статья про Discovery

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

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

Хорошие требования появляются не тогда, когда открывается шаблон BRD. Они появляются тогда, когда команда настолько глубоко погружается в проблему, что начинает понимать предметную область почти так же хорошо, как эксперты рынка. Именно тогда несколько простых экранов мобильного приложения перестают быть просто экранами. За ними начинают стоять месяцы исследований, десятки интеграций, сотни решений и огромное количество вопросов, которые в начале проекта мы даже не знали, что нужно задать.

А лучший способ проверить, что получилось из пяти месяцев Discovery, сотен требований и десятков интеграций, — пройти этот клиентский путь самостоятельно. Так что заходите в Альфа-Манию, покупайте билетик и, конечно, удачи в тираже :)

И, если получится, про то, как финтех сделал свою лотерею, я расскажу в следующей статье. Не переключайтесь.

Реклама. Рекламодатель: АО "АЛЬФА-БАНК" ИНН 7728168971, erid: 2W5zFGzLAg1

Timetta — российская платформа с таймшитами и управлением экономикой проектов; подходит компаниям, где зарплаты — основная статья расходов.

Clockify — щедрый бесплатный план и низкий порог входа в платные тарифы для небольших команд.

Toggl Track — минималистичный трекер с сильными отчётами, удобен фрилансерам и агентствам.

TimeCamp — акцент на автоматический учёт по ключевым словам и контроль бюджетов проектов.

Everhour — встраивает таймер прямо в задачи Asana, Jira, ClickUp и других таск-трекеров.

Как мы выбирали

Отбирали решения по критериям, важным для проектного бизнеса:

• возможность вести учёт времени по проектам и задачам
• биллинг
• отчётность
• интеграции
• мобильный доступ
• наличие бесплатного тарифа
• прозрачное ценообразование

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

1. Timetta — учёт через таймшиты

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

Кейсы клиентов и кому подойдёт

Решение в первую очередь выбирают компании с долей ФОТ свыше 60%:

• консалтинг
• аудит
• ИТ-интеграция
• разработка ПО
• дизайн и так далее

Распространённый сценарий — регулярное заполнение таймшитов сотрудниками с разбивкой по коммерческим проектам и внутренним активностям, например, совещаниям, наставничеству, обучению или административным задачам.

Что можно развернуть

Платформа покрывает полный цикл проектного бизнеса:

• проекты, программы и портфели
• диаграммы Ганта с вехами, зависимостями и критическим путём
• таск-трекер с бэклогом и спринтами
• бронирование ресурсов и загрузка сотрудников
• таймшиты и учёт отсутствий, заявки на затраты, платёжные календари и процесс почасового биллинга, P&L-отчёты, клиенты и сделки
• корпоративная вики и ИИ-ассистент

В рамках Timetta доступны приложения: Timetta Projects, Timetta Finance, Timetta Resources, Timetta Timesheets, Timetta Clients, Timetta Tasks, Timetta Expenses и Timetta Wiki.

Все данные учёта времени связаны с финансами проекта через ставки себестоимости и биллинга.

Инфраструктура и экосистема

Система поставляется по модели SaaS или on-premise для установки на собственные серверы. Предусмотрены готовые интеграции с «1С:Зарплата и управление персоналом» и «1С:Управление холдингом», открытый API, а также авторизация через корпоративные каталоги (SSO/AD). Данные хранятся в дата-центрах Yandex Cloud на территории России, резервные копии сохраняются 30 дней.

Отзывы и репутация

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

Поддержка и каналы связи

Техническая поддержка работает по электронной почте support@timetta.com с регламентированным временем ответа в течение часа. Документация размещена на сайте в разделе timetta.com/ru/docs. При внедрении возможна помощь инженеров вендора, включая миграцию данных из других систем.

Тарифы, ограничения и условия

Функции учёта рабочего времени вынесены в отдельное приложение Timetta Timesheets. Лицензии на него начинаются от 524 ₽ за пользователя в месяц с регрессионными скидками.

Недавно компания выпустила новую сборку Timetta Lite: она доступна бесплатно для команд до 10 активных пользователей без ограничения срока и теперь включает таймшиты. Для 11–50 пользователей предусмотрен платный тариф Team — 1 490 ₽ за пользователя в месяц. Подробности о релизе — в блоге Timetta. Мобильное приложение находится в разработке, а пока доступна адаптированная мобильная версия в браузере.

Официальный сайт: timetta.com

2. Clockify — бесплатный старт

Clockify — облачный тайм-трекер от CAKE.com с акцентом на простоту и щедрый бесплатный план. Подходит командам, которым нужно быстро начать учёт часов без сложного внедрения.

Кейсы клиентов и кому подойдёт

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

Что можно развернуть

• веб-приложение, десктопные клиенты (Windows, macOS, Linux), мобильные приложения iOS/Android и расширения для браузеров
• таймер, ручной ввод, таймшиты, календарь, автотрекер, Pomodoro, обнаружение простоя, интеграции с внешними сервисами
• в платных тарифах — киоск, биллинговые ставки, инвойсы, утверждение таймшитов, отпуска, бюджеты, GPS и скриншоты

Инфраструктура и экосистема

Clockify работает в облаке AWS, сертифицирован по ISO/IEC 27001, соответствует SOC 2 Type II и GDPR. В Pro-плане доступен выбор региона хранения данных. Интеграции охватывают более 80 приложений; есть публичный API и вебхуки.

Отзывы и репутация

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

Поддержка и каналы связи

Поддержка доступна через справочный центр Clockify Help и форму обратной связи на сайте. Время ответа в официальных источниках не регламентировано.

Тарифы, ограничения и условия

Бесплатный план включает неограниченный трекинг, проекты и клиентов, но ограничен пятью пользователями. Платные тарифы при годовой оплате: Basic — $3,99, Standard — $5,49, Pro — $7,99, Enterprise — $11,99 за пользователя в месяц. Все платные планы можно протестировать в течение семи дней.

Официальный сайт: clockify.me

3. Toggl Track — минималистичный трекер

Toggl Track делает ставку на простоту: один клик для старта таймера, чистые отчёты и работу на любых устройствах. Это выбор для тех, кто хочет считать время без избыточного контроля и сложных настроек.

Кейсы клиентов и кому подойдёт

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

Что можно развернуть

• веб, десктоп (Windows, macOS, Linux), мобильные приложения iOS/Android и браузерные расширения
• таймер, ручной ввод, офлайн-трекинг, автоматическое обнаружение простоя, Pomodoro, личные и командные цели, более 100 интеграций, API и вебхуки
• встроенного инвойсинга нет — данные выгружаются или передаются через интеграции

Инфраструктура и экосистема

Toggl Track сертифицирован по ISO/IEC 27001, поддерживает 2FA и SSO, заявлено соответствие GDPR. Производитель декларирует доступность 99,9%, однако SLA в публичных источниках не публикуется.

Отзывы и репутация

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

Поддержка и каналы связи

Доступны база знаний, community-форум и email-поддержка. Приоритетная поддержка по email открывается на Premium, персональный менеджер — на Enterprise. Телефонной поддержки нет.

Тарифы, ограничения и условия

Бесплатный план рассчитан на команды до пяти пользователей и включает неограниченные проекты и клиентов. Платные планы: Starter — от $9, Premium — от $18 за лицензию в месяц, Enterprise — индивидуальные условия. Есть 30-дневная пробная версия.

Официальный сайт: toggl.com/track

4. TimeCamp — автоматический контроль

TimeCamp выделяется автоматическим учётом времени: десктопный агент распознаёт приложения и сайты по ключевым словам и предлагает записать время в нужный проект. Это снижает нагрузку на сотрудников и помогает собирать данные для расчёта себестоимости.

Кейсы клиентов и кому подойдёт

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

Что можно развернуть

• веб-приложение, десктопный агент, мобильные приложения и расширения
• таймер, таймшиты, keyword-based автоучёт, attendance и overtime, отпуска, бюджеты и сметы, биллинговые ставки, инвойсинг, утверждение таймшитов и ролевая модель
• интеграции с Asana, Trello, Jira, Monday, ClickUp, Wrike и другими инструментами

Инфраструктура и экосистема

Штаб-квартира компании находится в ЕС (Польша), обработка данных ведётся в соответствии с GDPR. Для бизнес-клиентов доступно соглашение DPA. Для организаций от 50 пользователей предлагаются on-premise и private SaaS на основе годового Ultimate-тарифа.

Отзывы и репутация

Публичная агрегированная оценка или число клиентов в официальных источниках не раскрыты.

Поддержка и каналы связи

Поддержка доступна по email help@timecamp.com и через базу знаний на сайте. На Enterprise плане заявлен приоритетный support с SLA.

Тарифы, ограничения и условия

Бесплатный план доступен для неограниченного числа пользователей и включает проекты, таймшиты и приложения. Платные тарифы при годовой оплате: Starter — $3,99, Premium — $6,99, Ultimate — $9,99 за пользователя в месяц, Enterprise — по запросу. Все платные планы можно протестировать 14 дней.

Официальный сайт: timecamp.com

5. Everhour — бюджеты проектов

Everhour встраивает учёт времени непосредственно в популярные таск-трекеры: кнопка таймера появляется рядом с задачей в Asana, Trello, Jira, ClickUp и других инструментах. Это снижает переключение контекста и упрощает контроль бюджетов.

Кейсы клиентов и кому подойдёт

Решение подходит агентствам, продуктовым командам и консалтинговым компаниям, которые уже ведут задачи в Asana, Jira, Monday или ClickUp. Минимальное отвлечение сотрудников — основное преимущество для команд, привыкших работать внутри одного инструмента.

Что можно развернуть

• работа через веб-приложение и расширение для Chrome, которое добавляет элементы управления в интерфейс таск-трекера
• таймер, ручной ввод, бюджеты проектов в часах и деньгах, счета на оплату, отслеживание расходов, планирование ресурсов, отчёты с экспортом CSV/PDF, SSO и гибкие права доступа

Инфраструктура и экосистема

Everhour — облачный SaaS. Нативные интеграции охватывают Asana, Trello, Jira, ClickUp, Monday, Basecamp, GitHub, Notion, Linear, а также Slack, Google Calendar, QuickBooks, FreshBooks, Xero и другие сервисы. Мобильных и десктопных приложений нет, офлайн-режим не поддерживается.

Отзывы и репутация

На официальном сайте указан рейтинг 4,7 из 5 на платформе G2. Детальная методология или число отзывов не раскрыты.

Поддержка и каналы связи

Поддержка через email и базу знаний. На тарифе Custom доступен персональный менеджер и приоритетная поддержка с ускоренным ответом.

Тарифы, ограничения и условия

Бесплатный план рассчитан на команды до пяти мест. Платный Team — $8,50 за место в месяц при годовой оплате, минимум пять мест. Тариф Custom для крупных организаций рассчитывается индивидуально. Пробный период — 14 дней.

Официальный сайт: everhour.com

Сравнение по ключевым критериям

Бесплатный тариф: у Timetta — Timetta Lite до 10 активных пользователей, теперь с таймшитами; Clockify и Toggl Track ограничивают 5 пользователями; TimeCamp позволяет неограниченное число пользователей; Everhour — до 5 мест.

Минимальная цена: Timetta — от 524 ₽ за модуль Timesheets; Clockify и TimeCamp — от $3,99; Everhour — $8,50; Toggl Track — $9.

Автоматический трекинг: реализован в TimeCamp по ключевым словам и в Clockify/Toggl Track через десктопные агенты; Timetta и Everhour ориентированы на ручные таймшиты и таймеры.

Биллинг и инвойсы: встроены в Timetta, Clockify (с Standard), TimeCamp (Ultimate+) и Everhour; Toggl Track предлагает только отчёты с возможностью экспорта.

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

Вывод

Для российских проектных компаний с жёсткими требованиями к учёту экономики и локализации данных логичнее смотреть на Timetta. Если приоритет — минимальная цена или бесплатный старт, стоит протестировать Clockify или TimeCamp. Toggl Track удобен для быстрого учёта без лишних настроек, а Everhour — для команд, которые уже работают в Asana, Jira или ClickUp. Перед выбором стоит проверить, какой формат трекинга привычен команде: ручные таймшиты, автоматический контроль или встроенные кнопки в задачи.

Обычно в этой ситуации причину ищут в компании: не тот отдел, не тот руководитель, не та отрасль. Логичный вывод — ждать, пока начальство само создаст условия для новых идей, или менять работу и надеяться, что в следующем месте будет иначе. Ждать можно очень долго, а в следующем месте всё чаще устроено ровно так же.

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

Внутреннее предпринимательство: что это такое

Это когда сотрудник ведёт свой проект внутри компании примерно так, как вёл бы собственный стартап: сам находит проблему, сам предлагает решение, сам берёт на себя ответственность за результат. Разница с обычным стартапом одна: ресурсы, команда и площадка — компании, а не ваши личные. Такой подход помогает компаниям удерживать сильных людей и не стоять на месте.

Дальше — почему такие люди встречаются редко, кто всё же решается, и что делать, если вы узнали в этом описании себя.

Почему сотруднику выгоднее молчать

Всё просто: если вы ничего не делали и ничего не предлагали — вас точно не накажут. Если вы что-то предложили и ошиблись — накажут почти наверняка. При такой арифметике самый разумный выбор для сотрудника — молчать и не высовываться.

Хороший пример: несколько российских компаний решили перенять принципы Toyota — в том числе подход к контролю качества на конвейере. У японцев за найденный брак сотрудника поощряли: нашёл проблему — молодец, помог компании. При переносе в Россию всё поменялось: за найденный брак стали наказывать. Результат предсказуем — искать проблемы стало невыгодно, и желающих находить их сильно поубавилось.

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

Две истории тех, кто всё-таки рискнул

И всё же иногда находится человек, который двигает идею вперёд несмотря на риски. Таких людей называют «внутренними чемпионами» — это человек, который верит в свою идею, двигает её сам и помогает поверить в неё другим.

Проект №1: сервис для учителей.

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

Проект №2: курс русского языка как иностранного.

Здесь всё было сложнее. Автор идеи запустила MVP образовательной программы по обучению русскому языку как иностранному — и сразу столкнулась с сопротивлением собственной команды. Логика коллег была простой: зачем что-то менять, если можно спокойно зарабатывать на том, что уже работает? Пришлось доказывать нужность продукта на каждом шаге: спорить, объяснять, показывать цифры. Продукт всё же запустили — но только потому, что автор идеи занимала достаточно высокую позицию, чтобы её услышали и дали добро. Будь она на пару ступеней ниже, идея, скорее всего, застряла бы на этапе обсуждения.

У этих двух историй общий паттерн: успех держался на одном конкретном человеке, который решил рискнуть вопреки обстоятельствам. Уберите этого человека — и всё осталось бы на уровне идеи, которую никто не стал бы проверять.

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

Какие условия должны быть в компании для вашего продукта

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

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

1. Ловушка лояльности. Это когда в компании ценится не тот, кто предлагает новое и берёт на себя риск, а тот, кто удобен, не создаёт лишних вопросов и во всём соглашается с руководством. Звучит безобидно, но на деле это значит, что человек, который спорит и настаивает на своей идее, автоматически выглядит менее лояльным — даже если он прав. Со временем сотрудники считывают этот сигнал и просто перестают предлагать что-то новое, чтобы не выглядеть неудобными.
2. Ловушка зрелости. Это ситуация, когда компания слишком долго держится за то, что уже работает, даже если это решение давно устарело. Логика простая: зачем менять то, что приносит деньги прямо сейчас? Проблема в том, что рынок не стоит на месте, и решение, которое было отличным пять лет назад, может уже не подходить сегодня. Но менять его начинают обычно только тогда, когда оно окончательно перестаёт работать — а не тогда, когда для этого ещё есть время и ресурсы.
3. Ловушка близости. Это когда компания выбирает то, что доступно и понятно прямо сейчас, вместо того, что могло бы принести больше пользы в будущем, но требует времени и вложений. Знакомое решение всегда кажется более надёжным, чем новое и непроверенное, даже если по факту это не так. В результате перспективные идеи откладываются, потому что требуют выйти за пределы привычного.

Все три ловушки объединяет одно: они делают ставку на то, что уже есть, и наказывают за попытку что-то изменить.

Чтобы внутреннее предпринимательство работало не как исключение, а как часть нормальной жизни компании, нужны как минимум два условия:

1. Зарезервированные ресурсы. Для проверки идеи нужны время и деньги. Если сотруднику разрешают заниматься проектом, но не дают бюджета хотя бы на прототип и проверку гипотезы, инициатива, скорее всего, останется на стадии обсуждения.
2. Право на ошибку без последствий для карьеры. Возможность попробовать, не получить результата с первого раза и попробовать снова, а не остаться в статусе лузера без новой возможности.

Что делать, если в вашей компании этого нет

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

Но что делать, если у вас есть идея, а компания пока не готова ее поддержать? Для начала стоит научиться смотреть на нее как предприниматель: понять, какую проблему она решает, кто внутри компании может стать заказчиком и как превратить замысел в понятный план с конкретным результатом.

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

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

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

Набор 2026 года уже открыт. Подробности — на techpredonline.ru, вопросы можно задать ведущему специалисту и преподавателю кафедры ТехПреда: https://t.me/BelousovaYV.

Главное

Место для предпринимателя внутри компании почти всегда есть. Вопрос в том, есть ли человек, готовый его занять, и создаёт ли компания условия, при которых это не требует героизма. Пока система наказывает за ошибку сильнее, чем за бездействие, инициативных людей будет мало, а те, кто всё же решается, будут действовать на свой страх и риск. Изменить это может либо компания, пересмотрев подход к риску и ошибкам, либо сам человек — найдя среду, где можно потренироваться, прежде чем нести идею компании.

Задумайтесь, если не вы — то кто? Идея, которая сейчас кажется сырой, через два года может оказаться тем самым проектом, который вывел бизнес на новый уровень. Разница между теми, у кого получилось, и теми, кто так и не начал, — это просто первый шаг, который кто-то один раз всё-таки сделал.

Реклама. Рекламодатель: МФТИ, Физтех ИНН 5008006213, erid: 2W5zFJD74wB

Между тем, как просто написать код и выкатить продукт, есть длинный путь, который вы должны пройти: собрать, прогнать тесты, внести правки, выкатить, а потом возможно ещё раз внести правки. Дисциплина, которая учит видеть этот путь заранее и закладывать его в работу, называется системным мышлением. И, что важно, ей можно научиться. Особенно, если у вас в планах запустить свой стартап, где ошибка планирования стоит всего бизнеса.

Тикет закрыт, а фича не работает

Разработчик встречается с этим каждый день: тикет закрыт, а фича не работает; правка влита, но не собрана и не выкачена; ТЗ согласовано, а в проде всё по-старому. Владимир Бодров проработал в аэрокосмической отрасли 20 лет, а сейчас преподаёт на кафедре технологического предпринимательства МФТИ. Он рассказывает, что на большом производстве происходит ровно то же самое:

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

Разница простая, есть описание: ТЗ, план, код в репозитории, стратегия, презентация для инвестора. И есть реализация: работающий сервис на проде, построенная производственная линия, проданный продукт.

Описание можно изменить за минуту, но для реализации нужна работа, и эту работу кто-то должен сделать. Результат работы не появится от того, что описание стало подробнее, но коммит станет частью продукта, когда пройдёт сборку и выкатится на прод, а стратегия изменит компанию, когда по ней начнут работать.

Отсюда следствие, которое понимают все, но мало кто применяет: цена не у идеи, цена у результата. Именно поэтому две команды с одной и той же идеей приходят к разным результатам. Идея была общая — работа оказалась разной: разные ресурсы, разные методы, разные исполнители. Результат считается по реализации, а не по описанию.

Сначала — зачем, потом — из чего

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

Системное мышление предлагает сначала определить функцию, то есть что изменится в мире, когда система заработает, и только потом конструкцию, из чего эта система будет собрана. Разберём на примере: человек идёт в магазин за дрелью, хотя нужно ему отверстие в стене. Отверстие — это функция, то есть результат, ради которого всё затевается. Дрель — это конструкция, то есть один из способов такой результат получить. Сначала определяют результат, потом подбирают под него инструмент. Идея определяет инструмент, а вот как описывает обратный порядок Бодров:

Мы классную дрель сделали, она может дырки делать. Теперь пойдём везде дырки делать. Можем дырки такие, дырки сякие.

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

Порядок «функция → конструкция» работает как способ снизить риск. Обратный ход тоже встречается: смартфон и большие языковые модели появились как конструкции с размытым назначением, а функцию к ним подбирали уже потом, итерациями. Такой путь называют technology push, когда на рынок выводят готовый результат исследований. Риск здесь выше, потому что деньги и время вкладывают до того, как понятно, кому эта штука нужна и за что человек заплатит. Применение может найтись, а может и нет. Системное мышление такой путь разрешает, но просит называть вещи своими именами: пока функция не найдена, рынка у продукта нет, есть только предположение о нём, и планировать нужно исходя из этого.

Агентом может быть и модель

В системном мышлении того, кто выполняет роль, называют агентом. Человек тут частный случай: агентом бывает и ИИ, и целая организация, а методы работы с ними одинаковые.

Программисты сейчас переизобрели менеджмент. Оказалось, что если правильно поставить агенту задачу и потом проконтролировать результат — всё работает.

Получилось, что учебник по управлению командой внезапно стал руководством по работе с ИИ-агентами. Постановка задачи и проверка результата остались теми же самыми действиями, поменялся только исполнитель. Отсюда сделаем вывод: от нового инструмента сильнее всего выигрывает тот, кто уже умеет ставить задачу и доводить до понятного и ожидаемого результата.

Системное мышление работает как полка

Всё описанное выше выглядит очевидным, пока дело не доходит до применения. Разница здесь примерно как между «умею ездить на велосипеде» и «умею научить ездить».

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

С навыком, который вырос сам, есть одна проблема: его не получается передать. Человек годами крутит педали и не может объяснить, как именно он это делает. Обучение как раз и раскладывает интуицию на метод, который можно объяснить другому: сотруднику, студенту или языковой модели.

Главное, что даёт системное мышление, по наблюдению Бодрова, это структура. Слушатели с опытом MBA часто говорят, что поняли смысл прежнего обучения только после курса, когда знания встали на места. Отсюда и сравнение с книжной полкой: любое новое знание, инженерное, управленческое или финансовое, начинает быть полезным только тогда, когда вы из-за правильного системного мышления научились правильно применять знания.

На кафедре технологического предпринимательства МФТИ системное мышление вы будете изучать сразу: сначала рациональная работа и моделирование, потом системное мышление и методология, потом практики системной инженерии и менеджмента. Материал построен на курсах Мастерской инженеров-менеджеров и опирается на стандарты системной инженерии ISO 15288, ISO 42010 и документы INCOSE. Читают его практики: люди из аэрокосмической отрасли, лазерной индустрии, энергетических проектов, — те, кто на своём опыте знает, где мышление ломается о физический мир. Приём заявлений в магистратуру идёт до 15 августа, старт обучения — уже 1 сентября, для поступления нужно пройти вступительное испытание в форме собеседования. Программа по семестрам и условия — на techpredonline.ru

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

Одной статьёй мыслить системно не научишься

Бодров цитирует ответ Евклида царю Птолемею, который просил упростить и ускорить изучение науки: «В геометрии нет царского пути». Коротких дорог не появилось и сегодня. Но три вывода можно забрать уже сейчас:

1. Описание — это ещё не результат. Тикет закрыт, коммит влит, ТЗ согласовано — это пока записи. Прежде чем радоваться, проверьте, что из них уже стало работающим продуктом.
2. Сначала функция, потом конструкция. До того как выбирать стек, ответьте, что и для кого изменится в мире. Технология без функции — это риск, а не продукт; иногда даже оправданный.
3. Системному мышлению учатся. Это не врождённый талант, а навык и каркас, на который потом встаёт всё остальное — инженерия, менеджмент, работа с ИИ-агентами.

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

Реклама. Рекламодатель: МФТИ, Физтех ИНН 5008006213, erid: 2W5zFKAZY97

Работодателям всё меньше нужны люди, которые просто пишут код по спецификации, и всё больше нужны те, кто может спроектировать процесс, объяснить решение и взять на себя ответственность за результат, то есть думать как бизнес.

Заполнять таблицы или составлять их

В любом проекте есть две разные роли: одна — выполнять работу по заданным правилам, другая — эти правила придумывать.

Пример: тимлид настраивает трекер задач, определяет статусы и поля для заполнения, задаёт порядок перехода тикета между этапами. Разработчик берёт тикет, делает работу, отмечает прогресс и переходит к следующей задаче. Один человек составил таблицу с правилами, второй её заполняет. Обе роли нужны команде, но они разные по тому, на что человек влияет и чему в итоге учится сам.

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

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

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

Результат без узнаваемости — не результат

Есть исследователь по имени Альберт-Ласло Барабаши, специалист по теории сетей. Он много лет изучал успех как научную категорию — начал с науки, потом расширил модель на спорт, музыку и бизнес. И пришёл к выводу, что результативность работает вместе с сетевым эффектом. Человеку нужно хорошо выполнить свою работу и сделать её заметной для подходящей аудитории.

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

Отсюда формула: успех складывается из результативности и сетевого эффекта.

• Результативность — это то, что сделано на самом деле: открытие, продукт, код, статья.
• Сетевой эффект — то, узнали ли об этом достаточно людей, чтобы результат на что-то повлиял.

Из этих двух факторов складываются четыре ситуации.

1. Хороший результат плюс широкая известность — это ChatGPT от OpenAI и DeepSeek: оба продукта были качественными сами по себе, и оба стали настолько заметны, что DeepSeek на время уронил стоимость акций других AI-компаний.
2. Хороший результат без известности — судьба пенициллина, который открыли, но начали массово использовать в медицине только спустя десятилетия: результат был, а сетевого эффекта долго не было.
3. Слабый результат без известности проходит незамеченным, и в этом нет большой трагедии, просто вас никто не заметил.
4. Слабый результат с раздутой известностью на первый взгляд выглядит успехом, но долго на нём не продержаться — рано или поздно разница между шумом и содержанием становится видна.

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

Дальние знакомые полезнее близких друзей

Рид Хоффман, один из основателей LinkedIn, вывел на своих данных не самую очевидную закономерность про нетворкинг.

Близких друзей и постоянных коллег обычно и так хорошо знаешь: чем они занимаются, к каким ресурсам у них есть доступ, кто входит в их окружение. Если бы эти ресурсы понадобились, к ним уже давно обратились бы. Другое дело — дальние знакомые: друзья друзей, бывшие однокурсники, с которыми давно не общался, дальние коллеги по прошлым проектам. У них тоже есть доступ к ресурсам и связям, просто об этом никто не задумывается, потому что контакт кажется несущественным.

Здесь и пригодится идея Хоффмана. В какой-то момент именно дальний знакомый через одного-двух человек может свести с тем, кто нужен для проекта, или сам окажется полезен неожиданным ресурсом. Для поддержания таких связей не нужно встречаться каждые выходные в пабе, достаточно периодически вспомнить друг о друге в профессиональном инфополе. Например, если знакомый занимается конкретной областью и попадается статья или новость по теме, можно просто переслать её со словами «подумал, тебе пригодится». Со временем это работает на взаимность: человек вспоминает об этом и присылает что-то в ответ, зовёт на мероприятие или знакомит с кем-то нужным.

Большая система вырастает из маленькой рабочей

Закон Галла звучит просто: любая крупная работающая система выросла из системы поменьше, которая тоже работала. Идея настолько очевидна, что кажется банальной, но именно её обычно игнорируют, когда запускают крупные проекты с нуля. МТС в своё время запустила собственный сервис для видео как конкурента YouTube — и закрыла его примерно через полтора года. Причин там, скорее всего, было несколько, но нарушение этого принципа точно было одной из них: систему попытались построить сразу большой без этапа небольшой рабочей версии, чтобы протестировать спрос.

Если компания или продукт уже работают в небольшом масштабе, вырасти можно двумя путями:

1. Развивать то, что уже работает;
2. Объединиться с другой системой, которая тоже работает.

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

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

Учишься быстрее, когда учишь сам

Расселл Акофф, один из основоположников системного подхода в менеджменте, много занимался не только бизнесом, но и образованием. У него есть интересное наблюдение: название системы редко совпадает с тем, что она на самом деле делает.

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

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

Если нужно разобраться в чём-то по-настоящему, стоит попробовать роль ментора, а не ученика. Разработчику, который хочет закрепить новую технологию, полезно не просто пройти курс, а объяснить её кому-то другому: провести внутренний доклад для команды, написать статью с разбором, взять на менторство джуна и разбирать с ним конкретные задачи. Чтобы объяснение получилось, сначала приходится разложить материал по полочкам для себя — знание закрепляется гораздо прочнее, чем после самостоятельного изучения документации.

Если нечего предложить сейчас — предлагай будущее

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

Логичный первый шаг — пойти к тем, у кого этот ресурс есть, и попросить. Проблема в том, что в моменте предложить обычно нечего: то, что делает проект, начнёт приносить пользу и деньги позже, а не сейчас. Банк в такой ситуации спросит про залог, а у только что созданного стартапа заложить особо нечего — банку это неинтересно.

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

DevOps — это не только про IT

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

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

Дальше эта идея масштабируется шире IT. Когда запускается что угодно новое — продукт, компания, направление внутри бизнеса — сначала кто-то доводит это до рабочего состояния, а потом это состояние нужно стабильно поддерживать. И почти всегда за эти два этапа отвечают разные люди: одни хорошо придумывают и запускают, другие хорошо удерживают систему в рабочем режиме, и это разные склады ума, разные интересы, разные навыки.

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

Куда идти, если хочется собрать это в систему

Все 7 моделей выше так или иначе про одно и то же: способность смотреть на свою работу как на систему с ресурсами, ролями и стадиями роста, а не только как на код, который нужно сдать к спринту. Этому обычно не учат ни на курсах по фреймворкам, ни на внутренних вебинарах в компании.

Как раз на этом строится онлайн-магистратура МФТИ+Сколково «Технологическое предпринимательство» при кафедре технологического предпринимательства: вебинары с преподавателями, персональный ментор и около 1000 часов практики над собственным проектом — своим или корпоративным. Средний возраст студентов — 34 года: продакты, CEO стартапов, руководители R&D. На выходе — диплом магистра МФТИ государственного образца, плюс отсрочка от армии и выход на сообщество Физтеха.

Приём заявлений идёт до конца августа, старт обучения — 1 сентября, для поступления нужно пройти собеседование и вступительное испытание, но его можно обойти: если пройти онлайн-школу «Предпринимательское планирование» — она даёт минимальные проходные баллы в магистратуру без экзаменов. Программа по семестрам и условия — на techpredonline.ru, общая страница кафедры со всеми программами — на сайте МФТИ.

Реклама. Рекламодатель: МФТИ, Физтех ИНН 5008006213, erid: 2W5zFJmj8K3

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

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

Сейчас я экономлю, в среднем, 2–3 часа в день. Для мобильного банкира это много (плотность встреч большая) — посередине рабочего дня я могу заземлиться и просто погулять в парке с чашкой кофе.

Если ваша голова тоже пухнет от ежедневного информационного штурма, и вам нужен хотя бы (не)лишний час в день — этот материал для вас

Где ИИ мне действительно помогает: четыре самых частых кейса

1. Подготовке черновиков ответов клиентам

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

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

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

Ответ ИИ

Официальный вариант:

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

Простой вариант:

«Если объяснить проще: накопительный счет удобен, когда вы хотите иметь доступ к деньгам и при этом получать доход. Вклад чаще открывают на определенный срок, чтобы сохранить деньги и получить проценты по условиям продукта».

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

2. Подготовка вариантов ответов

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

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

Чтобы подготовиться к консультации, я обратился к ИИ и описал ситуацию клиента. После этого попросил подготовить понятное объяснение различий между обслуживанием ИП и ООО.

Ответ ИИ

«ИП и ООО могут использовать разные условия обслуживания в зависимости от особенностей бизнеса. При выборе тарифа важно учитывать не только организационно-правовую форму, но и реальные потребности клиента: количество операций, объем платежей, необходимость дополнительных сервисов и другие параметры.

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

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

Такой вариант ответа помог структурировать информацию и подготовить понятное объяснение для клиента. После этого я проверил условия по актуальным материалам банка и адаптировал ответ под конкретную ситуацию.

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

3. Структурирование информации

Если подытожить, то при работе с большим объёмом информации ИИ помогает быстрее разобраться в материалах и привести их к удобному для восприятия виду. Он способен:

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

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

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

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

Где я ИИ не использую

1. Юридически значимые формулировки

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

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

Например, если возникает вопрос, связанный с блокировкой счета в соответствии с требованиями 115-ФЗ, юридическими последствиями или трактовкой нормативных документов, надежнее обращаться к специализированным правовым системам, например к КонсультантПлюс, и внутренним материалам банка. Это связано с тем, что ИИ не всегда корректно работает с большими объемами нормативной информации: он может не учитывать последние изменения законодательства (что я неоднократно проверял), не иметь доступа к актуальной редакции документов или неверно интерпретировать отдельные положения договоров и правил.

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

2. Финальные ответы клиентам

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

Основные риски при использовании готовых ответов ИИ:

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

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

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

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

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

3. Работа с персональными данными

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

Я не передаю:

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

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

В данной статье подобные примеры не приводятся, так как при работе с ИИ персональные данные клиентов и конфиденциальная информация не использовались. Ответственный подход к работе с информацией позволяет использовать возможности ИИ эффективно, соблюдая требования безопасности.

Основной вывод

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

Он полезен, когда нужно:

• быстрее подготовить черновик;
• упростить сложный текст;
• структурировать информацию;
• найти варианты коммуникации.

Но он не должен заменять профессиональные знания, опыт и ответственность сотрудника.

Главный принцип прост: ИИ помогает подготовить решение, но окончательное решение всегда остаётся за человеком.

Дальше в тексте мы разделяем две стороны. Внешняя команда — это разработчики и менеджер подрядчика. Внутренняя команда — сотрудники заказчика, включая владельца продукта.

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

Сначала формулируют задачу бизнеса

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

На старте заказчик и подрядчик договариваются:

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

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

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

Настроить порядок работы с изменениями

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

Поэтому изменения проходят через последовательный процесс, и на каждом шаге видно, кто за него отвечает:

1. Внутренняя команда заказчика описывает, что изменилось и зачем это нужно продукту.
2. Внешняя команда оценивает, какие задачи придётся сдвинуть и как запрос повлияет на загрузку, технический долг и сроки.
3. Менеджер подрядчика собирает варианты действий и показывает последствия каждого.
4. Владелец продукта со стороны заказчика выбирает вариант и утверждает приоритет.
5. После этого задача попадает в бэклог или в текущий спринт.

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

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

Включить внешнюю команду в процессы проекта

Выдать внешним разработчикам доступ к репозиторию и добавить задачи в трекер недостаточно: команде нужен тот же контекст, с которым работает внутренняя команда заказчика. Для этого внешнюю команду подключают к основным процессам проекта: добавляют в рабочие чаты и на встречи; зовут на ретроспективы и обсуждения задач; проводят код-ревью по общим правилам; назначают наставника на время онбординга.

Внутренняя команда объясняет, как устроен продукт, какие решения уже приняты и от каких систем зависит текущая задача. Внешние разработчики учитывают эти связи в работе и заранее обсуждают изменения, которые могут затронуть соседние команды.

Подготовить проект к ротации специалистов

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

1. найти специалиста под требования заказчика;
2. передать ему текущие задачи и контекст проекта;
3. подключить к встречам и рабочим каналам;
4. оформить доступы и нужные документы.

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

Сообщать о рисках вместе с решением

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

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

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

Понять, когда исполнитель стал партнёром

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

Обычно заказчик:

• заранее обсуждает с подрядчиком планы проекта;
• советуется по организации работы;
• подключает внешнюю команду к сложным кросс-функциональным задачам;
• учитывает её при планировании ресурсов и бюджета.

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

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

По такому принципу в Centicore Group выстраивается работа выделенных команд: погружение специалистов в контекст проекта, подключение их к процессам заказчика и предварительное согласование порядка взаимодействия. Подробнее о компании и проектах можно узнать на centicore.ru.

Что в итоге

Работа с выделенной командой держится на предсказуемом процессе. Заказчик должен понимать, что произойдёт при смене приоритетов, появлении риска или ротации специалиста. Подрядчик должен быстро оценить последствия, предложить варианты и обновить план.

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

Без маркетинга и успешного успеха. Только боль, костыли и суровый прод! Мой пет-проект - бот «Щёлк-ГДЗ». Это ИИ-помощник, который решает школьные задачки по фоткам, видео, гс, тг-кружкам и PDF. Под капотом Python 3.12.3, aiogram 3, aiosqlite, апи OpenRouter (модель Gemini 3.0 Flash) и Робокасса. Крутится всё это на дешёвом VPS в Нидерландах. Держит 2500+ пользователей и не падает.

В этой статье расскажу, как за 9 месяцев построил логичную архитектуру, победил ошибку FloodWait при стриминге ответа ИИ и почему в условиях 1 гига RAM обычная SQLite - отличное решение.

Нейронка вместо джуна и Уроборос багов

Сразу признаюсь... С нуля я это не писал :) Синтаксис мне генерили LLM-ки. Начинал с Gemini 2.5 Pro, затем перешел на 3.0 Pro, а сейчас использую 3.1 Pro.

Многие думают, что нейронка сама напишет проект "под ключ", но это миф. Я никогда не доверял ИИ проектирование архитектуры и использовал его как продвинутый StackOverflow (скармливал конкретную задачу (например, написать SQL-миграцию) и получал кусок кода).

ИИ — это не архитектор, а джун на спидах.

Как только логика усложнялась - гемини ловил «Уроборос багов». Кидаешь баг А - он его фиксит, но появляется ошибка Б. Скармливаешь и её - фиксит, но возвращается баг А. Цикл замкнулся. Лечилось только созданием новых чатов, в которые я кидал код и писал запросы типа "Найди критические ошибки, логические дыры и баги".

Про продуктовую логику нейронка вообще не слышала. В первой версии рефералки был баг, где любой(если его аккаунта ещё нет в БД) мог написать в конце ссылки что любые 9 цифр (?start=1234567890) и получить бонусы.

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

Немного про архитектуру.

Чтобы код не превратился в нечитаемую лапшу на 5000 строк, я жестко разбил всё на модули. Архитектура бота выглядит так:

main.py - это точка входа с настройкой логгеров, коннетами aiohttp и запуском APScheduler

database.py - вся работа с БД

neiro.py - логика общения с апи OpenRouter (стриминг, сжатие фоток через Pillow, JSON-контекст)

states.py - классы состояний aiogram.fsm.state (например, PaymentProcess, GdzMode)

utils.py - легковесные утилиты. Например лок пользователей (защита от спама запросами):

Хэндлеры вынесены в отдельную папку handlers/:

handlers/common_handlers.py - главное меню с обработкой /start (рефералки, utm-метки).

handlers/gdz_handlers.py - сам процесс ИИ-решения (вход в GdzMode, прием фото, видео, кружочков).

handlers/pay_handlers.py - это логика платежей (Robokassa) и "Умная корзина".

handlers/tasks_handlers.py - квесты (выдача премиума за подписку на каналы спонсоров).

Сборку интерфейсов вынес в all_def.py. Не люблю, когда в хэндлерах генерится полотно текста с кнопками. Там же лежат функции склонения слов (1 запрос, 2 запроса, 5 запросов). А в settings.py лежат списки с рандомными ответами бота, чтоб казался живым.

Так же в settings.py я сделал кэширование картинок, тоесть при первом запуске бот грузит фото меню как BufferedInputFile, сохраняет file_id от Телеграма и дальше шлет картинки моментально по ID. Сервак говорит спасибо за сэкономленный трафик)

В handlers/common_handlers.py находится первичная маршрутизация. Вот так обрабатываются рефералки, переходы с сайта, с рекламы и другое при старте:

Диета по токенам

Хранить бесконечную историю диалогов дорого и бессмысленно. В бесплатной версии храню 10 последних сообщений (5 пар вопрос-ответ), а в преме — 30.

Но фотки весят большое кол-во токенов. Если премиум-юзер закинет 30 фоток, OpenRouter выставит мне огромный счет. В итоге я прикрутил ограничение: Из 30 сообщений ИИ видит только 10 последних картинок.

Старые фотки тупо вырезаю из JSON. Подменяю на системный промпт:

С довольно неплохой моделью (gemini 3.0 flash) это работает как часы (она честно признается, что забыла картинку, а не выдумывает что-то из воздуха).

Стриминг, FloodWait и защита баланса

Чтобы бот не выглядел тормозом, я сделал стриминг ответа от ИИ в neiro.py. Я обновляю сообщение в Телеграме чанками по мере получения их от ОпенРоутера.

Но если делать message.edit_text слишком часто, ловишь FloodWait. В итоге я выставил интервал в 0.7 секунд и обернул всё в жесткий try/except:

Стрим при этом не прерывается. Поспали и погнали дальше :) Если на этапе обработки файла или стриминга падает критическая ошибка - честно возвращаю юзеру запрос на баланс.

В handlers/gdz_handlers.py это выглядит так:

SQLite тащит

Почему не Postgre? Потому что для микро-SaaS с 2,5к пользователей SQLite хватает за глаза. Но в асинхронной среде она любит кидать ошибку database is locked.

Чтобы этого избежать, я включил WAL-режим при инициализации пула, разделил коннекты на db_writer и db_reader, а сложные операции доверил самому SQL.

Например, 00:00 запускается крон-таска, которая собирает огромную аналитику, начисляет всем активным юзерам +1 ежедневный запрос и сбрасывает просроченные подписки. И это всё это работает атомарно внутри database.py:

Умная корзина на APScheduler

Когда дело дошло до монетизации, всплыли две проблемы:

Первая: юзер оплатил, но забыл нажать кнопку «✅ Я оплатил» в боте. Бот ждет, юзер ждет, товар не выдается, поддержка кипит.

Вторая: юзер сформировал счёт и передумал ("брошенная корзина").

Вместе с LLM я с нуля изучил apscheduler и убил двух зайцев фоновыми задачами. Теперь в handlers/pay_handlers.py при генерации ссылки на оплату я создаю две отложенные таски:

Как это работает?

Через 5 минут срабатывает async def auto_check_payment(), которая тихо стучится в робокассу. Если статус success - бот сам начисляет запросы на баланс и радует клиента. Если статус pending - таска умирает, и в дело вступает 30-минутная таска.

Но она не шлёт спам вслепую, а лезит в БД и проверяет 3 бизнес-правила:

1. await db.has_successful_payment_recently - Не купил ли он другой товар за последние 3 часа?

2. await db.get_latest_invoice_id - А это точно самый последний сгенерированный им счет?

3. await db.can_send_agitation - Не присылали ли мы ему агитацию недавно?

Если проверки пройдены, то юзер получает сообщение: "⏳ Домашка сама себя не решит! Ты начал оформлять покупку, но оплата так и не прошла...". Это поднимает конверсию оплат.

Финал

Почему я не использую Redis для стейтов? Ответ банален: мой дешевый VPS имеет всего 1 гб оперативки. Пул aiohttp, In-Memory стейты и асинхронные таски и так жрут 70% RAM. Редис тупо не влезет.

Как говорится, работает — не трогай.

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

Готов ответить на вопросы по архитектуре и послушать советы в комментариях \(^^)/

P.s. вот ссылка на первую статью о моём проекте:

P.s. Если кто-то хочет потестить вживую(не реклама), то юз бота в тг @gdzshchelk_bot

Рабочий день разработчика в команде обычно начинается с проверки текущего состояния проекта. В трекере могли появиться комментарии к задаче, в pull request замечания от ревьюеров, а в CI могла упасть сборка. Иногда приоритет меняется из-за стоппера в соседней команде или ошибки, найденной во время тестирования.

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

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

Если задачу можно брать в разработку, перед первым коммитом стоит ещё раз проверить её содержание. В карточке должны быть указаны:

• цель изменения,
• ожидаемое поведение системы,
• пользовательские сценарии,
• ограничения,
• условия приёмки.

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

Как задача попадает в работу

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

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

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

Готовая к разработке карточка обычно содержит:

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

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

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

С этого момента начинается техническая работа: исследование проекта, выбор решения и декомпозиция реализации.

Что проверяет разработчик перед кодом

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

• где находится код, связанный с задачей;
• какие модули, интерфейсы и пользовательские сценарии изменятся;
• какие готовые компоненты можно использовать;
• зависит ли реализация от другой задачи или сервиса;
• потребуется ли feature toggle или A/B-тест;
• какие проверки нужно добавить или обновить.

Отдельно разработчик смотрит активные ветки и pull request в той же части проекта. Параллельные изменения могут затронуть общий интерфейс или компонент. Если узнать об этом заранее, можно согласовать порядок мержа и избежать повторной проверки обеих задач.

Дальше разработчик определяет объём тестирования. Он изучает существующие тест-кейсы, отмечает затронутую функциональность и решает, где понадобятся юнит-тесты или UI-тесты. Эти данные пригодятся и тестировщику при подготовке функциональной проверки и регресса.

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

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

Как проходит код-ревью

Когда реализация готова, разработчик открывает pull request и связывает его с карточкой задачи. Вместе с кодом ревьюер получает контекст: цель изменения, требования, затронутые компоненты и способ проверки.

Перед ручным ревью запускается CI. Пайплайн собирает проект, проверяет код линтером и прогоняет юнит-тесты. Результаты видны прямо в pull request, поэтому ошибки сборки и упавшие тесты можно исправить до мержа.

Ревьюеры проверяют:

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

Обычно pull request смотрят разработчики, которые работают с той же функциональностью и знают её ограничения. Если в команде только один специалист по нужной платформе, подключают коллегу из другой команды с подходящей технической экспертизой.

Замечания оставляют в комментариях к конкретным строкам или участкам решения. Автор исправляет код, обновляет pull request и повторно запускает проверки. Если комментариев недостаточно для обсуждения сложной реализации, участники созваниваются и разбирают решение вместе.

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

Как задачу тестируют

После код-ревью CI собирает тестовую версию. Ссылка на сборку появляется в карточке задачи, поэтому разработчик и тестировщик работают с одним и тем же вариантом приложения.

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

Тестировщик проверяет соответствие условиям приёмки, работу связанных компонентов и регрессионные сценарии. Быстрые автоматические проверки запускаются в CI, а ресурсоёмкие UI-тесты могут выполняться по расписанию или перед релизом.

Найденная ошибка возвращает карточку в статус Reopen. Разработчик исправляет код, CI выпускает новую сборку, и проверка запускается повторно. После успешного тестирования задача получает статус готовности к релизу и связывается с нужной версией продукта.

Как команда готовит релиз

Когда задачи прошли тестирование, команда фиксирует состав релиза. Карточки связывают с конкретной версией продукта, а изменения, которые не успели пройти все проверки, переносят в следующую.

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

Перед выпуском срабатывают quality gates:

• проект успешно собирается;
• юнит-тесты проходят;
• статический анализ не находит критических проблем;
• регрессионные и UI-тесты завершаются успешно.

Если в релизной версии находят ошибку, исправление делают в отдельной ветке от релизной. После повторного ревью и тестирования код возвращают в релиз, а затем переносят в основную ветку разработки. Так исправление сохраняется и в следующих версиях.

Дальнейший процесс зависит от настроек CD. При Continuous Delivery готовая сборка ждёт ручного подтверждения выпуска. При Continuous Deployment изменение автоматически отправляется в прод после прохождения всех проверок.

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

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

Что происходит после выхода в прод

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

Команда отслеживает:

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

Набор метрик зависит от цели изменения. Для нового пользовательского сценария можно смотреть количество открытий, завершённых действий и выходов на отдельных этапах. Если фича выпущена в рамках A/B-теста, команда сравнивает поведение контрольной и тестовой групп.

При серьёзной ошибке собирается инцидент-колл. Разработчики, тестировщики и инженеры эксплуатации определяют причину сбоя и выбирают способ восстановления сервиса. Это может быть исправление, откат версии или отключение проблемной функциональности.

Для срочного исправления создают hotfix. Он проходит сокращённый по времени цикл, сохраняя обязательные проверки: код-ревью, сборку и тестирование затронутого сценария. После выпуска исправление добавляют в основную ветку разработки, чтобы ошибка не вернулась в следующем релизе.

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

Как рабочие встречи связаны с задачей

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

Основные встречи связаны с процессом так:

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

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

Итого

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

Поэтому статус Done для нас означает конкретный результат: изменение вышло в прод, работает стабильно и решает исходную задачу. До этого момента карточке ещё есть куда двигаться.

Почему прогнозы об ИИ плохо помогают в работе

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

Сейчас цикл обновления инструментов короче цикла согласования решения. Команда обсуждает переход на новый AI-стек несколько недель. За это время выходит модель, которая меняет экономику задачи. Разработчик осваивает возможности одного агентного фреймворка — к моменту, когда он их освоил, на рынке уже работает следующий, с другим набором ограничений.

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

Где брать тогда актуальную информацию? Из опыта тех, кто быстрее смог внедрить и протестировать: опыт человека, который прямо сейчас собирает продукт, нанимает агентов вместо части команды или внедряет AI в рабочие процессы, обгоняет по актуальности материал с прогнозом. Любой прогноз фиксирует состояние рынка на момент написания, а опыт — в моменте использования.

Что меняется в работе разработчика прямо сейчас

На первой «Точке сборки» обсуждалось, с чем разработчик сталкивается на текущем проекте. AI-native компании, вайб-кодинг, мультиагентные системы, запуск MVP и проверка гипотез, корпоративные AI-продукты, управление командами в новых условиях.

Вайб-кодинг перестал быть нишевым экспериментом энтузиастов и стал рабочим подходом в командах, где скорость сборки прототипа уже важнее архитектуры на старте. Агенты берут на себя часть задач, которые раньше требовали отдельного человека в штате — от рутинных проверок до первичной обработки данных. MVP, для которого раньше закладывали спринт, сейчас собирается за выходные, и это меняет саму экономику проверки гипотез: тестировать идею стало дешевле, чем спорить о её перспективности.

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

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

Зачем МФТИ собирает предпринимателей на вебинарах

Кафедра технологического предпринимательства МФТИ запустила «Точку сборки» как серию открытых встреч о том, как технологии, продукты и компании меняются под влиянием AI. Первый вебинар прошёл 29 мая и собрал предпринимателей, основателей AI-стартапов, продуктовых лидеров и исследователей.

Программа строилась на практических кейсах, рабочих инструментах и разборе того, что уже происходит с разработкой, командами и запуском продуктов.

Список спикеров первого эпизода:

• Александр Горный — сооснователь AiAcademy, бывший директор по стратегии Mail.Ru Group (VK)
• Илья Бердыш — CEO mymeet.ai
• Денис Сметнёв — сооснователь Skyeng и uForce, ментор Кафедры ТехПреда МФТИ
• Жемал Хамидун — Head of AI, Alpina Digital, выпускник Кафедры ТехПреда МФТИ
• Александр Писемский — founder Zenpulsar, ex-cofounder Group-IB
• Артемий Малков — founder DataMonsters, преподаватель Кафедры ТехПреда МФТИ
• Артём Астапенко — founder AgentArea, выпускник Кафедры ТехПреда МФТИ

После основной программы конференция продолжилась открытым нетворкингом: участники обсуждали собственные проекты и искали партнёров.

Следующие эпизоды закроют развитие AI-продуктов, технологическое предпринимательство, управление командами и запуск стартапов. Программа и анонсы новых эпизодов — на странице Кафедры технологического предпринимательства МФТИ.

Итого

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

Собрали три рабочих вывода для разработчика:

1. компетенции обновляются быстрее, чем раньше, и способность быстро освоить новый инструмент становится частью основной специализации, а не факультативным навыком
2. конкурентное преимущество формируется не доступом к технологии, а скоростью её встраивания в реальный рабочий процесс
3. сообщества и открытые встречи, где практики делятся конкретным опытом, дают более актуальную информацию, чем аналитические материалы

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

Реклама. Рекламодатель: МФТИ, Физтех ИНН 5008006211, erid: 2W5zFHdG7aR

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

Геймификация — не превращение ежеквартального отчёта в Mario. Это применение игровых механик к неигровым задачам: внимание, лиды, удержание, обучение, лояльность, сбор данных. Разница с игрой в одном: в хорошей игре процесс самоценен, в бизнесе — измеряется результатом.

Геймификация решает бизнес-задачи: внимание, лиды, удержание, обучение, лояльность и данные.

Работающие механики — прогрессия, стрики, лидерборды и дефицит — но только если они усиливают основную петлю, а не заменяют её.

Duolingo вырос в DAU в 4,5 раза за счёт CURR и loss aversion, но копирование механик Candy Crush провалилось.

Wordle показал, что простая механика + шеринг дают органический рост на 1100% и десятки миллионов пользователей.

Механики копировать можно, но реализацию, название и ассеты — нет: примеры 2048, клоны Wordle и дело Tetris v. Xio.

Поинтсификация и тёмные паттерны вредят бренду: механика без цели убивает мотивацию.

Карта бизнес-задач: зачем бизнесу игровые механики

Прежде чем добавлять бейджи и очки, нужно понять, какую конкретно проблему решает продукт. У каждой бизнес-цели — своя механика, и подмена цели ведёт к провалу.

Внимание

Брендовые мини-игры и интерактивные квизы нужны, чтобы человек остановил скролл. По данным BeeLiked, потребитель уже не откликается на баннеры так же, как раньше, а игровой формат даёт время контакта и эмоциональную привязку. Примеры: колесо фортуны, scratch-карты, аркадные мини-игры от Adact и Drimify. Главный KPI — не время в игре, а стоимость привлечения внимания и переход к следующему шагу.

Лиды

Квиз, подборка продукта или конкурс — это обмен ценности на контакт. Человек тратит две минуты на игру и оставляет email или номер, потому что ему интересен результат. Работает, когда игра связана с продуктом напрямую: подбор кофе, расчёт страховки, тест знаний.

Удержание

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

Обучение

Gamified learning повышает завершаемость курсов. По данным AmplifAI, курсы с геймифицированными элементами доходят до завершения в 90% случаев против 25% у обычных. Прогресс-бары, достижения и микроуроки помогают преодолевать порог входа. Главное — чтобы награда шла за понимание, а не за просмотр видео.

Лояльность

Программы лояльности с уровнями, бейджами и эксклюзивом увеличивают повторные покупки. По данным AmplifAI, геймифицированные программы лояльности дают рост удержания клиентов на 22%. Механика дефицита и статуса работает сильнее скидок, потому что создаёт ощущение принадлежности к закрытой группе.

Данные

Игры — один из самых ненавязчивых способов собрать zero-party data. В ходе квиза или рекомендательной игры пользователь сам рассказывает о предпочтениях, и это данные высокого качества. Но сбор данных не должен быть единственной целью: если игра создана только ради формы, конверсия будет низкой.

Механики под KPI: что реально влияет на поведение

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

Прогрессия

Полоска опыта, уровни, круги мастерства. Человеку важно видеть, что он продвинулся. Эффект одарённого прогресса показывает: если пользователь видит, что уже часть пути пройдена, он скорее дойдёт до конца. Бизнес-вывод: показывайте прогресс к конкретной выгоде, а не абстрактный счётчик.

Стрики

Последовательные дни действий — самая мощная и самая опасная механика. Она опирается на loss aversion: потеря 100-дневного стрика болезненнее, чем удовольствие от нового уровня. Работает, когда действие полезно само по себе. Превращается в манипуляцию, когда пользователь держится ради счётчика.

Лидерборды

Соревнование работает, если участники чувствуют, что победа достижима. Открытый глобальный рейтинг демотивирует новичков, а сегментированные группы из 20–30 человек повышают вовлечённость. Duolingo использует именно когортные лиги, а не единую таблицу всех пользователей.

Дефицит

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

Правило одной петли: каждая механика должна усиливать основное действие продукта. Если стрик не ведёт к реальному навыку, а лидерборд не ведёт к результату — это поинтсификация, а не геймификация.

Кейс Duolingo: как DAU вырос в 4,5 раза

Duolingo — лучший учебник по тому, как геймификация строит привычку. По данным Ludaxis, приложение достигло 50 млн ежедневных активных пользователей в 2025 году, а DAU вырос в 4,5 раза за четыре года. Ключевой метрикой стал CURR — Current User Retention Rate, вероятность того, что активный пользователь останется активным завтра.

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

По данным Siddhartha Arora, внедрение лидербордов дало прирост общего времени обучения на 17% и утроило число высокововлечённых пользователей. Пользователи с семидневным стриком в 3,6 раза чаще остаются в продукте надолго. Это не волшебство — это loss aversion и повторяющийся цикл действие-награда.

Почему механика из Candy Crush провалилась

Интересный контрпример: Duolingo пробовал перенести ограничение ходов из match-3 — «счётчик ошибок» в уроке. Идея казалась логичной: ограниченные попытки создают напряжение. Результат — провал: retention не вырос, пользователи не отреагировали, идею отменили. Вывод, который стоит выгравировать на рабочем столе продакт-менеджера: механика работает только в контексте.

Ре-скин механик: вечнозелёные форматы и короткое окно хайпа

Большая часть брендовых игр — не новые механики, а ре-скин проверенных форматов. Это нормально: простые правила снижают порог входа, а короткая сессия соответствует мобильному поведению.

Вечнозелёные конвейеры

Match-3, 2048, слова, колесо фортуны, Memory, quiz — эти механики давно стали SaaS. Платформы вроде Adact, Drimify и BeeLiked предлагают белый лейбл: маркетолог меняет скины, призы и вопросы, не трогая код. Такие игры не дают вирусного взрыва, но стабильно собирают лиды и удерживают аудиторию.

Хайповые моменты

Wordle, Connections, Strands — это не вечнозелёные механики, а кратковременные культурные явления. Они растут на простоте, ежедневном ритуале и шеринге. Окно для копирования короткое: через несколько месяцев аудитория устает, и новый клон не взлетает. Бренду важно не повторить Wordle, а поймать, почему он взлетел, и быстро адаптировать механику под свой контекст.

Что делает механику ре-скинуемой

• Простые правила. Объяснение за 10 секунд или одной картинкой.
• Короткая сессия. Одна попытка занимает меньше минуты.
• Слабый нарратив. Не нужно знать сюжет, чтобы играть.
• Встроенная причина вернуться. Ежедневный пазл, новый уровень, еженедельный рейтинг.
• Лёгкий шеринг. Результат можно показать без спойлера — как эмодзи-сетка Wordle.

Кейс Wordle: одна страница на React и органика +1100%

Wordle — эталонный пример того, как простая механика становится бизнес-активом. В октябре 2021 года разработчик Джош Уордл выложил игру для партнёшки; к январю 2022 у неё были миллионы ежедневных игроков. The New York Times купил Wordle за сумму в «low seven figures» — оценки указывают на 1–3 млн долларов, по данным Dinogame.

Сделка была интересна не ценой, а стратегией. Wordle остался бесплатным: его задача — верхушка воронки для подписок NYT Games. По данным Digiday, к марту 2023 года Wordle привёл в экосистему NYT «десятки миллионов» новых пользователей, а к декабрю 2023 большая часть времени в официальных приложениях NYT приходилась на игры.

Цифры ещё красноречивее. По данным CommandLinux со ссылкой на WordsRated, органический трафик NYT вырос с 0,13 млрд визитов в Q4 2021 до 1,56 млрд в Q1 2024 — прирост на 1100%. Доля Wordle в общем органическом трафике NYT достигла 82,69%. В 2024 году Wordle собрал 5,3 млрд игр и около 14,5 млн ежедневных игроков.

Вывод: Wordle не выдумал новую механику — механика угадывания слов известна десятилетиями. Революция случилась в сочетании: простое правило, один пазл в день, emoji-шеринг без спойлера и ежедневный ритуал. Бизнесу важнее понять эту комбинацию, чем копировать внешний вид.

Юридика: механику можно, а внешний вид — нет

Разработчики часто спрашивают: а можно ли просто сделать игру «как Wordle, но для нашего бренда»? Ответ — да, но с оговорками.

По данным Wikipedia и практике авторского права, игровые механики, правила и общие идеи не охраняются копирайтом. Охраняется конкретное выражение: код, графика, музыка, название, персонажи, визуальный стиль, а иногда и общий «look and feel». Именно поэтому существуют тысячи клонов match-3, но любой из них рискует, если копирует ассеты Candy Crush.

Threes! и 2048

Классический пример: Threes! вышел в 2014 году, через месяц появился 2048 с той же механикой слияния плиток, но другой визуализацией. 2048 стал вирусным, а Threes! остался нишевым. Механика была скопирована легально, но история показывает, что копия победила не из-за качества, а из-за простоты и скорости распространения.

Клоны Wordle

После покупки Wordle NYT появились сотни клонов на разных языках. Большинство не нарушают закон, пока не используют название Wordle, цветовую схему и ассеты NYT. Механика «угадай слово за шесть попыток» свободна для повторного использования.

Tetris Holding v. Xio Interactive

Дело Tetris Holding v. Xio Interactive (2012) стало важным прецедентом. Суд признал, что сама механика Tetris не охраняется, но конкретное выражение — размер поля 20×10, форма и цвет фигур, тень падения, демонстрация следующей фигуры — защищено. Mino оказался настолько похож в «look and feel», что суд запретил его распространение. Вывод: копируйте идею, но рисуйте свои фигуры.

Этика: когда геймификация становится поинтсификацией

Не вся геймификация одинаково полезна. Себастьян Детердинг ввёл термин поинтсификация — навешивание очков, бейджей и таблиц на активность без изменения её структуры. Это работает на короткой дистанции, но не создаёт ни навыка, ни лояльности.

Иэн Богост назвал подобный подход exploitationware: система, которая использует психологические уязвимости ради метрик продукта. Тёмные паттерны — искусственный дефицит, вина за разрыв стрика, манипулятивные пуши — повышают retention, но разрушают доверие. По данным NerdSip, долгие стрики часто превращаются в тревогу, а пользователи начинают выполнять бесполезные действия ради сохранения счётчика.

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

Как не убить рабочую петлю брендингом и формами

1. Не ставьте форму до ценности. Если игра начинается с регистрации, половина аудитории уйдёт до первой награды.
2. Не перегружайте брендом. Логотип на каждом экране не повышает лояльность, а отвлекает от механики.
3. Давайте opt-out. Возможность отключить лидерборд, пуши или стрик снижает тревожность и повышает доверие.
4. Связывайте награду с реальным результатом. Бейдж за прохождение урока ценнее бейджа за вход в приложение.
5. Тестируйте уязвимые группы. Дети, новички и люди с тревожностью реагируют на loss aversion сильнее остальных.

Выводы

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

Gamification should be a strategy, not an afterthought or add-on.

Для геймдева это хорошая новость. Бизнесу нужны люди, которые умеют проектировать петли вовлечения, балансировать экономику и понимать психологию игрока. Но переход из игр в бизнес требует дисциплины: здесь нет места «just for fun». Каждый уровень, каждый стрик и каждая награда должны вести к измеримому результату.

Если вы планируете внедрять геймификацию — начните не с выбора платформы, а с вопроса: «что человек будет делать завтра, потому что вчера ему было полезно?». Ответ на него и станет вашей рабочей петлёй. Всё остальное — обёртка.

Источники: AmplifAI, Mordor Intelligence, BeeLiked, CommandLinux / WordsRated, Digiday, Dinogame, Deconstructor of Fun, Ludaxis, Siddhartha Arora, Peek & Poke, Adact, Drimify, Redbit Games, NerdSip, Growth Engineering, Wikipedia: Video game clone, Wikipedia: Tetris v. Xio.

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

Я работаю в ретейле больше двадцати лет, и за это время успела убедиться: самые дорогие проблемы в магазине — не технические, а операционные. Товар лежит на складе, но не на полке. Покупатель уходит, продажа теряется. Мы с командой Lenta tech (ИТ-бренд «Группы Лента») решили, что пора выстроить платформу, которая сама определяет, какой товар донести до полки, из какой палеты и в каком порядке. Проектную группу собрали из сотрудников разных подразделений: Big Data, SAP, мобильная разработка, онлайн и операционный бизнес. Именно то, что за одним столом сидели инженеры, аналитики и люди, которые каждый день работают в торговом зале, позволило учесть все аспекты — от архитектуры до количества кликов на экране ТСД.

Почему классические процессы перестали масштабироваться

Гипермаркет — это не магазин у дома. Это десятки тысяч товарных позиций (SKU), сотни палет ежедневно и непрерывный поток перемещений между складскими зонами, верхними стеллажами и торговым залом. Ручной поиск товара, бумажные описи на палетах, выкладка «на глаз» — все это работало до определенного момента. Но при масштабах крупной сети процесс перестал справляться.

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

Три слоя архитектуры: что оставили, а что написали с нуля

Архитектурно решение выстроили вокруг трех слоев: система планирования ресурсов предприятия (ERP) на базе SAP, слой больших данных (Big Data) и серверная часть мобильного приложения (backend), написанная с нуля.

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

Слой Big Data взял на себя аналитику и генерацию задач. Здесь лежит основной объем логики: обработка прогнозов, анализ расхождений между запасом и фактическими продажами, формирование потребностей к пополнению полки. Данные содержатся и обрабатываются в корпоративном хранилище (Data Lake), откуда потребности уходят дальше — в backend приложения.

Backend мобильного приложения — новый компонент, созданный специально для проекта. Команда мобильной разработки отвечала за этот слой с нуля: он получает от Big Data потребности к пополнению, формирует задания для сотрудников, обрабатывает операции изъятия товара из палет и передает информацию о местах хранения обратно в SAP. Помимо этого, backend взаимодействует с системой онлайн-заказов (PDA PickerApp): когда сборщик не находит товар на полке, событие поступает в backend и тоже превращается в задание.

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

Почему legacy не стало препятствием

В крупных ретейл-проектах legacy-системы воспринимаются как неизбежное зло, с которым нужно «бороться». Наши архитекторы пошли другим путем: не боролись, а использовали legacy там, где это было эффективнее.

Решение о том, что оставить на существующих системах, а что вынести в новые сервисы, команда принимала прагматично. SAP отлично справлялся с учетом запасов и ячеечным хранением — зачем его дублировать? А вот логику формирования задач, приоритизацию, аналитику и мобильный интерфейс строили с нуля, потому что здесь нужны были скорость разработки и гибкость, которые legacy-контур дать не мог.

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

Логика задач: прогнозы, приоритеты и пересечения списков

Ключевая логика системы сосредоточена в механизме формирования задач. Эту часть взяла на себя команда Big Data. Нельзя проверить весь ассортимент — ресурс сотрудника ограничен. Поэтому система выдает только наиболее приоритетные задания, и логика их отбора довольно сложная. В продакшне работают несколько видов автоматических задач:

• Событие «нулевого пика» (zero pick). Сборщик онлайн-заказа не нашел товар на полке и ставит отметку в PickerApp. Система проверяет остаток: если он ненулевой, рассчитывает количество к выкладке и создает задание. Это самый «чистый» сигнал — живой человек уже подтвердил, что товара на месте нет.
• Пустая полка. Раз в час Big Data сверяет остатки на основном складе магазина с запасом в палетах. Если эти цифры совпадают, значит, весь товар лежит в палетах — на полке ноль. Генерируется задача.
• Недостаточный запас. Товар на полке есть, но система сопоставляет текущий остаток с прогнозом продаж. Если остатка не хватает для покрытия спроса, формируется задание на пополнение. Здесь важно, что задача возникает не по факту «полка пуста», а на опережение.
• Товары без продаж. Если по позиции в течение недели не было ни одной продажи, система берет товары с наибольшим объемом запаса для каждой секции и собирает из них перечень задач на неделю. Если по позиции уже была отработка — повторно она не добавляется. Логика здесь в том, что большой запас без движения — потенциальный симптом невыложенного товара.

Помимо автоматики, руководящий персонал может создать задачу вручную через Web UI.

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

«Каждый лишний клик стоит денег»

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

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

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

Пять команд и одна зона неопределенности

Как я уже говорила, проектная группа была собрана из пяти подразделений: Big Data, SAP, мобильная разработка, команда онлайна и операционный бизнес. Каждое было опытным, каждое умело работать по своим задачам. Проблема проявилась на стыках.

Когда в продакшн-среде возникала ошибка, далеко не всегда было очевидно, какое именно подразделение ее допустило. Данные проходят через несколько слоев: Big Data сформировала потребность, backend ее получил, мобильное приложение отобразило задачу, SAP отдал информацию о палетах. Если задание некорректно, нужно пройти всю цепочку и определить, где произошел сбой. Разграничение зон ответственности и процедура разбора инцидентов — то, на что было заложено недостаточно времени на старте. Притирка заняла ощутимый ресурс, хотя ни одна из команд не была новичком.

Синхронизация изменений тоже требовала внимания: когда Big Data меняет логику формирования задач, backend должен корректно обработать новую схему, а мобильное приложение — отобразить результат. Каскадные доработки ускоряли одно звено и ломали соседнее. Со временем процесс выстроился, но в ретроспективе — это одна из главных недооцененных статей расхода по срокам.

Лавина ложных задач и контроль качества данных

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

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

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

Волны, feedback loops и продукт, который менялся на ходу

Внедрение разделили на пять волн, и это было осознанным инженерно-процессным решением, а не просто осторожностью.

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

Циклы обратной связи (feedback loops) работали следующим образом: магазин фиксирует проблему, операционная служба передает ее в проектную команду, разработка вносит изменение, следующая волна получает обновленную версию. Между этими этапами проводится анализ метрик дисциплины и качества отработки задач. Если магазины первой волны показывали низкие результаты, разбирались: проблема в инструменте или в процессе?

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

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

Что показал проект

Дополнительная прибыль за 2025 год превысила целевые показатели на 7%. Но, помимо финансовых результатов, проектная группа вынесла несколько важных инженерных и процессных выводов.

Большие ретейл-технологические проекты — это всегда про процессы, а не только про код. Можно написать идеальный backend, но если магазин не размечает палеты, система бесполезна.

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

Архитектура должна учитывать реальную работу людей. Каждый лишний клик — это деньги, и инженерное решение обязано проходить через фильтр продуктового мышления.

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

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

Правило полуавтоматизации

Главный страх перед алгоритмами обычно связан с потерей контроля. Руководители боятся, что скрипт будет работать криво, отправит клиенту мем или одобрит платеж по неверным реквизитам. Чтобы убрать этот риск, нейросетям отдают исключительно рутину. Ищите регулярный процесс, где есть четкие входные данные и прозрачный результат, который легко проверить визуально. Идеальный старт — пайплайн на базе готового API, заменяющий пару часов ежедневного копипаста. Глобальные проекты по перестройке архитектуры лучше отложить до тех пор, пока вы не научитесь экономить время на мелочах.

Финансы и первичка: избавляемся от ручного ввода

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

1. Счета в автоматизированную таблицу

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

2. Сверка оплат: ИИ мэтчит банковскую выписку с инвойсами

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

3. Контроль дебиторки: поиск просрочек и автогенерация писем-напоминаний

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

4. Поиск аномалий: поиск задвоений или скачков расходов

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

5. Сверка заказа и поставки

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

Продажи и лиды: скоринг без участия менеджера

Автоматизация на этапе воронки напрямую влияет на выручку. Каждая минута, которую сотрудник тратит на ручную сортировку — это минус время общения с потенциальным клиентом и потерянные деньги.

6. Сортировка заявок: тегирование лидов по бюджету и срочности

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

7. Черновики ответов: генерация персонализированных первых сообщений

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

8. КП из переписки: сборка структуры коммерческого из лога чата

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

9. Фоллоу-апы и потерянные сделки: кластеризация причин отказов

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

10. Резюме звонка: транскрибация встреч с выделением договоренностей

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

Управленческие отчеты и инсайты

11. Еженедельная сводка: текстовое саммари из разных метрик

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

12. Анализ рекламы: связка расходов, лидов и продаж

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

13. Поиск аномалий и прогноз кассовых разрывов

Узнавать о просадках в конце месяца больно. Еще больнее осознать, что завтра нечем платить зарплату. ИИ умеет мониторить отклонения в реальном времени: резко просели продажи конкретного товара или зависли ожидаемые платежи от крупного клиента — скрипт отправляет алерт. Он сводит входящий поток денег с обязательными расходами и заранее показывает риск кассового разрыва. У владельца появляется время для переговоров с поставщиками или ускорения сбора дебиторки.

Чтобы настроить такую аналитику, разработчик в штате не требуется. Таблицы отлично работают через сервис Ajelix, а текст можно генерировать с ChatGPT. Научиться связывать эти инструменты в рабочие процессы можно на курсе «Нейросети на практике: для себя, работы и бизнеса» от Eduson Academy. Программа показывает, как делегировать рутину алгоритмам без навыков программирования.

Клиентский сервис и операционка

Эти механики не генерят выручку напрямую, но влияют на скорость работы команды и их вовлеченность.

14. Репутация и контроль качества: парсинг отзывов и проверка ответов менеджеров

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

15. Онбординг и базы знаний: из заметок в инструкции

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

Итого: с чего начать

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

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

Реклама. Рекламодатель: ООО «Эдюсон» ИНН 7729779476, erid: 2W5zFJcrBzy

В этой подборке разбираем, как устроена работа со сложными и большими проектами: какие подходы используют команды с технической экспертизой, какие предложения есть на рынке и как это влияет на конечный результат.

Selectel: серверные платформы с полным циклом разработки

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

Поэтому в Selectel разработка начинается не со сборки серверов под конкретный проект. Команда развивает собственную серверную платформу, которая становится основой для последующих решений: от серверов общего назначения до GPU-систем для задач искусственного интеллекта, высокопроизводительных вычислений и обработки данных.

От эксплуатации к разработке

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

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

Собственная аппаратная архитектура

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

Использование собственной платы позволяет самостоятельно выбирать компонентную базу, проектировать системную архитектуру и топологию платы, а также быстрее внедрять новые технологии без зависимости от готовых OEM-платформ.

Платформа Selectel поддерживает процессоры Intel Xeon 6, память DDR5, интерфейс PCI Express Gen5, модуль доверенной платформы TPM 2.0, а также предусматривает установку современных сетевых адаптеров и ускорителей вычислений.

Для задач искусственного интеллекта и высокопроизводительных вычислений используются серверы форм-фактора 8U с несколькими GPU, тогда как платформы 1U и 2U применяются для виртуализации, корпоративной инфраструктуры, баз данных, облачных сервисов и других сценариев эксплуатации.

BIOS, BMC и управление платформой

Разработка аппаратной части ведется одновременно с развитием встроенного программного обеспечения.

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

Для управления оборудованием Selectel использует собственный интерфейс Selectel Management Interface (SMI), разработанный на базе OpenBMC.

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

Программный уровень платформы

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

От платформы к решению под конкретную задачу

После того как серверная платформа разработана и проверена, она становится основой для инженерной работы с конкретными проектами.

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

Для CPU-интенсивных задач приоритетом становятся вычислительные ресурсы процессора и организация многопоточной нагрузки. Для систем хранения — производительность дисковой подсистемы и сетевых интерфейсов. При работе с GPU оцениваются баланс между центральным и графическими процессорами, пропускная способность PCI Express, требования к питанию и охлаждению. При необходимости проектируются конфигурации под storage- и backup-системы.

На этапе проектирования также анализируются особенности будущей инфраструктуры: тип рабочей нагрузки (CPU-bound, memory-bound, IO-bound или GPU-bound), требования к доступности и SLA, особенности электропитания, тепловыделения, размещения оборудования в стойке и существующей сетевой инфраструктуры.

Проверка гипотез до закупки оборудования

Для проверки используется Proof of Concept (PoC) — инженеры воспроизводят профиль нагрузки клиента на тестовом стенде, сочетая синтетические и прикладные тесты. Это помогает заранее оценить производительность, задержки, температурные режимы и запас вычислительных ресурсов.

Во время таких испытаний анализируются параметры, которые невозможно оценить по спецификации оборудования: NUMA-топология, баланс между CPU и GPU, производительность подсистемы хранения, влияние вариантов конфигурации памяти, пропускная способность сетевых интерфейсов и шин PCI Express.

По итогам команда получает рекомендации по конфигурации с учетом характера нагрузки и ожидаемой производительности.

Проверка совместимости и стабильности

После формирования конфигурации сервер проходит комплексную проверку.

На производственном этапе контролируются комплектность оборудования, версии компонентов и прошивок. BIOS, BMC, сетевые адаптеры, RAID- и HBA-контроллеры приводятся к согласованным версиям, что обеспечивает воспроизводимость конфигурации. Затем проверяется работа памяти, накопителей, сетевых интерфейсов, аппаратных датчиков и других компонентов платформы.

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

После этого выполняется серия нагрузочных испытаний. Для оценки производительности используются бенчмарки процессоров, памяти, подсистем хранения, сетевой инфраструктуры и GPU. Отдельно анализируется поведение системы под длительной максимальной нагрузкой: температурные режимы, эффективность охлаждения, корректировка ошибок ECC, журналы BMC и другие параметры, позволяющие выявить потенциальные проблемы до начала эксплуатации.

Что отличает подход Selectel

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

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

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

В целом, такой подход объединяет разработку платформы, инженерную экспертизу и эксплуатацию в один непрерывный цикл — собственная инфраструктура становится источником обратной связи для следующих поколений серверной платформы.

Deckhouse: Kubernetes-платформа и экосистема для Cloud Native

Deckhouse — экосистема инструментов для разработки, доставки и эксплуатации Cloud Native-приложений. В основе — Deckhouse Kubernetes Platform (DKP), которая автоматизирует управление кластерами Kubernetes поверх любой инфраструктуры: публичные и частные облака, bare metal, закрытые контуры без доступа в интернет. Вокруг платформы выстроен набор продуктов — управление виртуализацией, хранение секретов, CI/CD, мониторинг — всё в одной экосистеме с общим API и интерфейсом.

Продукты разрабатываются и размещаются на территории РФ. Платформа поддерживает российские ОС: РЕД ОС, Astra Linux, ALT Linux. Deckhouse Kubernetes Platform CSE имеет сертификат ФСТЭК России №4860, платформа внесена в реестр российского ПО.

Что входит в экосистему

Deckhouse Kubernetes Platform (DKP) — ядро. Управляет кластерами Kubernetes, системным ПО на узлах, базовыми компонентами. После установки платформа готова к работе: автомасштабирование, мониторинг, мультитенантность — из коробки, без ручной сборки из отдельных компонентов.

Deckhouse Virtualization Platform (DVP) — управление виртуальными машинами и контейнерами из одного интерфейса. Масштабируется до 1000 серверов и 50 000 виртуальных машин. Поддерживает IaC-подход через открытый API, что позволяет автоматизировать развёртывание и управление средой полностью декларативно.

Deckhouse Stronghold — управление жизненным циклом секретов: пароли, ключи API, сертификаты, SSH-ключи, токены. Совместим с API HashiCorp Vault, что упрощает миграцию с него — без выгрузки секретов наружу через внешние утилиты. Поддерживает двойное шифрование через внешние HSM (AES + ГОСТ, AES + RSA), автоматическое резервное копирование и межкластерную репликацию.

Как устроен процесс работы

Установка и конфигурация

После установки DKP полностью готова к работе. Узлы группируются под разные типы нагрузки, настраиваются политики безопасности, мониторинг, журналирование. Платформа автоматически управляет системным ПО на узлах и базовыми компонентами Kubernetes.

Развёртывание в закрытых контурах

Установка и использование продуктов возможны на серверах без доступа в интернет, включая географически удалённые объекты.

DevSecOps-практики

Сквозное применение DevSecOps на всех этапах поставки: управление сетевыми политиками, аутентификация и авторизация, заказ TLS-сертификатов, аудит-логирование, изолированные контейнеры.

Для кого это полезно

• Техлиды и архитекторы получают платформу, которая закрывает инфраструктурный слой: не нужно собирать стек из отдельных компонентов — мониторинг, service mesh, хранение секретов, балансировка уже встроены.
• Разработчики получают сокращение времени подготовки среды разработки до 15 раз, единый UI и API для управления всей инфраструктурой, понятный CI/CD-конвейер. DVP позволяет использовать IaC для управления виртуальными машинами так же, как контейнерами — через манифесты.
• QA-инженеры и SRE работают с уже настроенным мониторингом из коробки, автоматическими алертами и механизмами восстановления.

Что отличает подход

Вся экосистема продуктов разрабатывается одной командой и поддерживает единый канал экспертной поддержки. Не нужно разбираться, кто отвечает за проблему — платформа или отдельный модуль: всё покрывает один контракт.

Кластеры поддерживают любой тип инфраструктуры без изменения подхода к управлению: одни и те же практики работают в Yandex Cloud, в собственном ЦОД и на bare metal одновременно. В кейсе «Лемана ПРО» именно это позволило объединить кластеры из разных облачных провайдеров и дата-центров в единую инфраструктуру.

Высокая доступность из коробки: SLA 99,99% достигается за счёт отказоустойчивости компонентов платформы, геораспределённых конфигураций (Multicluster на базе Istio, MetroCluster) и fencing-механизмов для безопасного восстановления при сбоях узлов.

Техническая база

• Поддерживаемые ОС (host): Astra Linux SE, РЕД ОС, РОСА Сервер, ALT Linux, CentOS, Debian, Ubuntu
• Поддерживаемые ОС (guest в DVP): любые ОС на x86-64
• Интеграции: LDAP, OIDC, внешние HSM, аппаратные СХД (TATLIN, Huawei, HPE, NetApp), SCSI-протокол, LACP, VLAN
• API: открытый, совместим с HashiCorp Vault API (для Stronghold)
• Форматы дисков ВМ: VMDK, Qcow2, Raw
• Сертификация: ФСТЭК России №4860, реестр российского ПО

Управление и поддержка

Единый канал поддержки покрывает все продукты экосистемы. Для обучения работает Deckhouse Академия с курсами по платформе и инструментам безопасности. Обновления платформы приходят автоматически в выбранное окно обслуживания. Для знакомства с продуктами доступна 30-дневная пробная версия.

ELMA365 BPM: автоматизация бизнес-процессов на Low-code платформе

ELMA365 — Low-code BPM-платформа для оцифровки, автоматизации и оптимизации бизнес-процессов. В основе — процессный движок, который автоматически ставит задачи участникам, маршрутизирует процессы по заданной логике и собирает данные на каждом этапе. Моделирование ведётся в визуальном дизайнере по нотации BPMN 2.0 — без привлечения разработчиков. Сценарии и кастомная бизнес-логика пишутся на TypeScript с подсветкой синтаксиса и автодополнением прямо в интерфейсе.

Платформа разворачивается в облаке на серверах Яндекса — без установки дополнительных компонентов, всё работает через браузер. По данным TAdviser, ELMA BPM — самая внедряемая BPM-система в России и СНГ.

Продукт используют в корпоративной автоматизации: согласование документов, управление задачами и поручениями, электронный документооборот, CRM-процессы, КЭДО.

Как устроен процесс работы

Моделирование процессов

Процесс описывается в графическом дизайнере из готовых блоков: задачи, шлюзы принятия решений, таймеры, уведомления, запуск подпроцессов. Используется нотация BPMN 2.0 — схема понятна как аналитику, так и бизнес-заказчику. Дополнительно доступны готовые активности ECM для работы с документами: подписание, согласование, генерация по шаблону, вебхуки для интеграций.

Формы и данные

Все формы создаются в графическом редакторе. Поля настраиваются под специфику процесса, группируются по вкладкам и панелям, скрываются или отображаются в зависимости от контекста. На этапе моделирования добавляются сценарии на TypeScript: автозаполнение полей, вычисление значений, определение ветки процесса — всё без написания backend-логики.

Запуск и исполнение

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

Отладка и мониторинг

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

Быстрая оптимизация

Процессы редактируются без остановки уже запущенных экземпляров. Изменения вступают в силу сразу после публикации. Платформа поддерживает версионность процессов — можно откатиться к предыдущему состоянию, если что-то пошло не так. Это важно для компаний, у которых одновременно живут десятки «живых» процессов: по оценке ELMA, для компании в 500 человек таких процессов от 50 до 100, и каждый меняется со временем.

Для кого это полезно

• Разработчики и аналитики работают в среде с подсветкой синтаксиса, автодополнением и встроенным отладчиком — TypeScript-сценарии пишутся прямо в интерфейсе. Сторонние библиотеки и внешние системы подключаются через готовые скрипты и вебхуки. Стандартный API открывает возможности для интеграции с любыми внешними сервисами, веб-сайтами и базами данных.
• PM получает полную видимость по задачам и срокам: канбан, мониторинг процессов в реальном времени, автоматические уведомления при просрочке или ошибке. Перераспределение задач при отпусках и болезнях закрывается механизмом замещения — администратор назначает замещающего и выдаёт временные доступы.
• QA-инженеры могут использовать версионность процессов для контроля изменений и отладчик для проверки бизнес-логики до выхода в продакшн.

Что отличает подход

Платформа сочетает Low-code-скорость с гибкостью полноценного кода. Большинство процессов настраивается без программирования, но там, где нужна кастомная логика, TypeScript-сценарии дают полный контроль. Это позволяет аналитикам закрывать задачи самостоятельно, не ставя каждое изменение в очередь к разработчикам.

Версионность и редактирование «на лету» — принципиальная особенность для enterprise: процессы живут годами и постоянно меняются. ELMA365 позволяет управлять этим циклом без остановки операционной работы и без риска сломать уже запущенные экземпляры.

Интеграционная шина покрывает основные корпоративные сценарии: ЭДО через операторов ЮЗДО и Контур.Диадок, CRM с встроенной телефонией и мессенджерами через ChatDesk, КЭДО с электронной подписью, которая полностью легитимна и позволяет убрать бумажные носители.

Техническая база

• Язык сценариев: TypeScript (встроенная IDE с автодополнением и отладчиком)
• Нотация процессов: BPMN 2.0
• API: стандартный REST API для запуска процессов и управления ими из внешних систем
• Интеграции: ЭДО (ЮЗДО, Контур.Диадок), мессенджеры (ChatDesk), телефония, внешние БД и веб-сервисы через вебхуки и скрипты
• Развёртывание: облако (серверы Яндекс), браузерный интерфейс без установки компонентов

Управление и поддержка

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

Т1 Сфера: платформа полного цикла производства ПО

«Сфера» (SFERA — Scaled Framework for Enterprise Resilience and Agility) — платформа для управления разработкой, тестированием, эксплуатацией и поставкой ПО. Более 40 инструментов в одном контуре: таск-трекер, Git-репозиторий, CI/CD-конвейер, хранение артефактов, управление тестированием, мониторинг, документация. Платформа разрабатывается с 2020 года на основе опыта внедрения ИТ-конвейеров в крупнейших российских компаниях, включая банковский сектор.

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

Как устроена платформа

Управление процессами и задачами

Сфера.Задачи — таск-трекер с настройкой под любую методологию: Agile, Scrum, SAFe, Kanban. Управляет бэклогом, декомпозицией задач, приоритизацией, назначением ответственных и дедлайнов. Закрывает те же сценарии, что Jira, Notion, Trello и Azure DevOps — в одном инструменте.

Сфера.Знания и Сфера.Документы обеспечивают базу знаний и документооборот — аналог связки Confluence + Notion. Здесь хранятся архитектурные решения, регламенты, технические спецификации и всё, что обычно теряется в чатах и почте.​

DevOps-инструментарий

Сфера.DevOps — сквозная автоматизация цикла от написания кода до деплоя. Включает:

• Git-инструмент для хранения, рецензирования и версионирования кода
• CI/CD-конвейер для непрерывной интеграции, тестирования и развёртывания
• Единое хранилище артефактов разработки
• DevOps-сервис самообслуживания для операций первого и второго дня — создание компонентов, сборка, проверка, раскатка

Тестирование

Комплекс инструментов для автоматизированного тестирования встроен в DevOps-конвейер. Поддерживает быстрый и автоматизированный процесс проверки на всех этапах жизненного цикла — от написания тест-кейсов до интеграционного и регрессионного тестирования в пайплайне.​

Мониторинг и эксплуатация

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

Особенность платформы — 3D-дашборды для контроля всех процессов производства ПО. Верхнеуровневый мониторинг детализируется до уровня отдельной команды или стрима: видно, где тормозит пайплайн, где накапливается технический долг, где горят сроки.​

Для кого это полезно

Техлиды и архитекторы получают единую среду, в которой живут архитектурные схемы, API-документация, код и задачи — всё связано и не расползается по разным системам. Инструмент для проектирования архитектуры на разных уровнях входит в состав платформы отдельным модулем.​

Разработчики работают в знакомом Git-workflow с code review, CI/CD-конвейером и хранилищем артефактов — без необходимости настраивать интеграции между десятком разных инструментов. DevOps-сервис самообслуживания сокращает время на рутинные операции: создание компонентов, настройку сборок, деплой.​

QA-инженеры используют встроенный тест-менеджмент в связке с CI/CD — тест-кейсы, автоматизация, отчётность по покрытию в одном контуре.

Что отличает подход

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

Техническая база

• Методологии: Agile, Scrum, SAFe, Kanban​
• Инструменты: таск-трекер, Git, CI/CD, хранилище артефактов, тест-менеджмент, база знаний, документооборот, мониторинг, управление инцидентами​
• Интеграции: существующие системы контроля версий (GitLab и другие), внешние DevOps-инструменты​
• Развёртывание: корпоративный контур без выхода в интернет​
• Реестр: входит в реестр российского ПО​

Управление и поддержка

Платформа разработана совместно с VK, «1С», Лабораторией Касперского и Ростелекомом в рамках дорожной карты «Новое общесистемное ПО». Поддержка охватывает все модули платформы через единый канал. Новые команды могут опираться на встроенный методологический фреймворк для выстраивания процессов производства ПО с нуля.

Comindware Platform: Low-code BPM для автоматизации сложных процессов

Comindware Platform — Low-code BPM-платформа для моделирования, автоматизации и оптимизации бизнес-процессов предприятия. В одной среде работают корпоративная архитектура, процессный движок, кейс-менеджмент, управление данными и интеграции с внешними системами. Процессы описываются в визуальном дизайнере по нотации BPMN, исполняются движком точно в соответствии с моделью — без разночтений при переносе логики из схемы в код.

Среднее время реализации MVP на стороне клиента — 4 недели. Один из подтверждённых кейсов: бизнес-аналитик ABPMP в одиночку автоматизировал процесс обработки заявок за 30 часов, ускорив его в пять раз. Платформа применяется в промышленности, финансовом секторе, ритейле, телекоме, строительстве, медицине и государственных структурах. Среди кейсов нашла проекты для Газпром Авиа, НСПК, UCS, UserGate.

Как устроен процесс работы

Моделирование и автоматизация процессов

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

Управление данными и интерфейсами

Права доступа настраиваются на уровне отдельных кнопок, столбцов, таблиц и полей. Для отображения данных доступны рабочие области, виджеты, карты, графики, QR-коды.

Событийная оркестрация

Самогенерирующийся REST API развивается вместе с платформой и клиентскими приложениями, оставаясь обратно совместимым. Документирование через Swagger/OpenAPI: разработчики получают подробное описание каждого с примерами и возможностью тестирования на реальных данных без сборки приложения.​

Встроенные коннекторы покрывают стандартные корпоративные интеграции: Git, OpenLDAP/Active Directory, SMTP/IMAP, Exchange, OData (ERP), RabbitMQ/MSMQ, MSSQL/MySQL. Для событийных сценариев поддерживаются вебхуки — обмен данными с Telegram, Viber, JivoSite, телефонией (Novofon, Mango Office), почтовыми сервисами и любыми внешними системами через HTTP.

Для кого это полезно

• Архитекторы и аналитики управляют всей картой процессов компании в одной среде — от верхнеуровневой модели до исполняемых процессов. Изменения вносятся без остановки запущенных экземпляров, логика модели напрямую транслируется в поведение системы без ручной интерпретации.​
• Разработчики работают с самогенерирующимся REST API с Swagger-документацией, встроенными коннекторами к популярным сервисам и возможностью подключать кастомную логику на C#.
• PM получает прозрачность по статусу процессов в реальном времени и аналитику по отклонениям.
• QA и аналитики проверяют логику процессов на моделях до выхода в прод. Изменения можно откатить или протестировать на отдельном контуре.

Что отличает подход

Платформа объединяет в одной среде то, что обычно разведено по разным инструментам: архитектурное моделирование, исполнение процессов, кейс-менеджмент, управление данными и интеграции.

Самогенерирующийся API — нестандартное архитектурное решение для enterprise-платформ. Обычно API — это отдельный артефакт, который отстаёт от эволюции продукта. Здесь API генерируется автоматически по мере развития платформы и клиентских приложений, оставаясь обратно совместимым.

Платформа работает на собственном оборудовании, в частных или публичных облаках и по гибридной схеме. Интерфейс — браузерный, как для конечных пользователей, так и для разработчиков, установка ПО на рабочие места не требуется.​

Техническая база

• Нотация процессов: BPMN 2.0
• Языки кастомной логики: C#, N3
• API: самогенерирующийся REST API, документирование через Swagger/OpenAPI​
• Коннекторы: Git, Active Directory/OpenLDAP, Exchange, SMTP/IMAP, OData, RabbitMQ, MSMQ, MSSQL, MySQL​
• Интеграции через вебхуки: Telegram, Viber, JivoSite, Novofon, Mango Office, Unisender, Mailchimp, CRM-системы (Bitrix24, Megaplan, MS Dynamics)​
• Развёртывание: on-premise, частное и публичное облако, гибридная схема​

Управление и поддержка

Настройка большинства сценариев доступна аналитикам без привлечения разработчиков. Партнёрская сеть охватывает задачи внедрения и сопровождения. Для быстрого старта доступен пилотный проект — среднее время реализации MVP составляет 4 недели. Платформа развивается с учётом требований российского рынка и поддерживает работу в закрытых корпоративных контурах.

***

Общая закономерность у всех рассмотренных решений одна: экспертиза видна в глубине проработки конкретного слоя. Selectel копает до уровня BIOS/BMC и изучает, как ведёт себя железо под нагрузкой — потому что сами на нём работают. Чек-лист, который стоит держать в голове при выборе инструментов и подрядчиков для сложных задач:

• Есть ли у команды собственный опыт эксплуатации, а не только внедрения
• Можно ли протестировать решение под свой профиль нагрузки до принятия решения
• Насколько глубоко команда может разобраться в проблеме — до первопричины или только до симптома
• Покрывает ли поддержка весь стек или только отдельные его части
• Как решение ведёт себя при изменениях — масштабировании, миграции, обновлениях

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

SafeLine WAF — это бесплатный инструмент, который я лично тестировал.

Это полностью open-source решения, продукт с действительно бесплатной Community Edition, где ключевые функции не урезаны.

SafeLine WAF — веб-приложенийный межсетевой экран, который действительно поставляется с разумными настройками по умолчанию

Что он делает:

Защищает веб-приложения от SQL-инъекций, XSS-атак, командных инъекций, CSRF, SSRF, атак включения файлов и других угроз из списка OWASP Top 10. Также поддерживает защиту от CC/DDoS-атак, управление ботами и может работать как шлюз аутентификации.

Почему он:

Большинство WAF с открытым исходным кодом достаточно сложно настроить. Можно потратить часы на настройку правил, пытаясь остановить ложные срабатывания, из-за которых легитимные пользователи блокируются.

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

Некоторые показатели, которые стоит учитыват

1. Уровень обнаружения - SafeLine (Balanced) (71.65%), ModSecurity (Level 1) (69.74%), Cloudflare (Free) (10.7%)
2. Уровень ложных срабатываний - SafeLine (Balanced) (0.07%), ModSecurity (Level 1) (17.58%), Cloudflare (Free) (0.07%)
3. Точность - SafeLine (Balanced) (99.45%), ModSecurity (Level 1) (82.20%), Cloudflare (Free) (98.40%)

Сбалансированный профиль SafeLine обнаруживает более 70% атак, при этом блокируя легитимный трафик ошибочно всего в 0.07% случаев. Это именно тот уровень настроек по умолчанию, который можно использовать в промышленной среде без постоянного ручного контроля.

Установка выполняется одной командой

После запуска он разворачивается как набор Docker-контейнеров: Tengine (форк Nginx) используется в качестве reverse proxy, отдельный сервис отвечает за семантический анализ, PostgreSQL хранит конфигурации и логи, а удобная веб-панель администратора работает на порту 9443.Community Edition поддерживает до 10 сайтов, чего достаточно для большинства личных проектов и небольших бизнес-сценариев.

Сайт: https://cyberserval.tech/landing/safeline

GitHub: github.com/chaitin/SafeLine (более 21 тыс. звёзд)

Лицензия: GPL-3.0 / MIT (Community Edition)

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

Я пообщался о спорте и беге с участниками фестиваля RUNIT by AGIMA разных лет: кто-то участвует постоянно, кто-то собирается первый раз, кто-то не попадает в этому году. Но все бегают и занимаются ещё каким-то спортом, видят в этом пользу и что-то хорошее.

RUNIT by AGIMA — ежегодный фестиваль IT и спорта, который проводится в Москве летом. Впервые он прошел в 2018 году и собрал около сотни сотрудников AGIMA и их друзей, а уже в 2025 году в фестивале приняло участие 10 тысяч IT-специалистов. В этом году фестиваль пройдёт 5 июля в Мещерском парке.

Хотелось узнать, что бег и спорт делают с человеком по-настоящему — куда заводят, какие решения подсказывают, какие оставляют впечатления и воспоминания, над чем потом смеёшься. Получилось честно и местами неожиданно. Героев в этой статье четверо: Алексей Озеров (IT_One), Сайыына Колесова (КРОК), Млада Николаева (AGIMA) и Алексей Лосев (БФТ-Холдинг). Дальше — их дистанция, от старта до финиша.

Старт: «Сайыына, зачем тебе это?»

Почти у всех бег начинался с чужой компании — буквально.

Сайыына Колесова впервые побежала на RUNIT by AGIMA в 2024-м, в разгар адаптации в новой компании, когда записывалась подряд на все активности: «Мне показалось, что будет клёво большой командой в одинаковых футболках пробежать свои дистанции. Раньше я завидовала тем, кто приходит на забеги со своей командой, тоже хотелось быть частью такого драйвового сообщества». Воодушевившись, она выбрала десять километров — и до сих пор об этом жалеет, потому что дистанция далась непросто: «Я бежала и думала: «Сайыына, зачем тебе это?».

Но добежала. И, что важнее, унесла с финиша положительные эмоции: «Я увидела, как много моих коллег тоже увлечены спортом — даже из моего департамента, о чём я и не подозревала. Увидела друзей-коллег с новой стороны, да и себя показала — выжившей. С тех пор наши отношения только крепнут.

Для Алексея Озерова фестиваль — вообще точка отсчёта. «Это особенный для меня забег, с него начался мой беговой путь. Два года назад я пробежал здесь свои первые пять километров и чуть не умер. Год назад тут же была первая десятка». Следующая цель Алексея тоже привязана к фестивалю: первый в жизни полумарафон он хочет пробежать именно на RUNIT by AGIMA.

Стена: не всё так просто

А дальше у каждого наступает момент, ради которого, кажется, всё и затевается, — когда гонка перестаёт быть приятной.

Стена Алексея Лосева показалась мне особенно суровой. Он бегает ультратрейлы, и его главная история — «Золотое кольцо» под Суздалем с титульной дистанцией 110 километров. Первая попытка закончилась сходом на девяносто четвёртом километре. Со стороны — обидно, оставалось чуть-чуть. Но он принял это решение как человек, привыкший смотреть вдолгую: «В тот год дистанция была сто пятнадцать километров, каждый давался тяжело. Я решил сойти, чтобы не только вернуться, но и продолжать участвовать в таких событиях долгие годы». Он вернулся через два года подготовки.

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

У Млады Николаевой, которая помимо бега занимается пауэрлифтингом и тайским боксом, была своя стена — жара на петербургском полумарафоне «Северная столица». После первой в жизни половинки (прим. полумарафон, 21 километр) она шла за личным рекордом: «Питер, плоско, лето — что может пойти не так? Ответ: всё».

Тридцать с лишним градусов, набережные без тени, пульс на двадцать ударов выше обычного. «Это единственный забег, где я по-настоящему не была уверена, что добегу. В голове постоянно шёл торг: может, сойти? А может, ещё километр? А может, ну его?» Она финишировала еле передвигая ноги — и гордилась не временем, а тем, что не свернула.

Передышка: футбол, халявные футболки и первое место

Если бы спорт состоял из одних стен, в него бы никто не возвращался. К счастью, он состоит ещё и из историй, которые потом годами рассказывают друзьям.

Самая киношная — у Алексея Озерова, и она про футбол. «Во время легендарного чемпионата Европы, когда наша сборная обыграла Голландию 3:1, я работал в приёмной комиссии Бауманки. После той игры мы на радостях гуляли всю ночь, а утром напрямик пришли в кабинет приёмной комиссии, обвесили его флагами и с раскрашенными в цвета российского флага лицами весь день принимали документы у будущей технической элиты страны».

У Сайыыны Колесовой — история о том, как она случайно стала спортсменкой. Она долго считала себя человеком неспортивным и физкультуру терпеть не могла, пока тётя — тренер по лёгкой атлетике — не отдала ей ворох командных футболок со сборов. «Я ходила в этих халявных футболках на физру, и однажды физрук без объяснений перевёл меня в другую группу. А там оказались университетские легкоатлеты с особой программой. Тренеры, видимо, решили, что футболки мои по праву и я из какой-то сборной. Не спросили, к счастью». Так она «вступила в атлеты», сдала нормативы не хуже других, начала сама ходить в зал и бегать по утрам, доехала до соревнований в Германии: «Ну короче, с тех пор я на спорте».

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

Итог: первое место. «До сих пор одно из самых ярких и смешных воспоминаний. Мы все были просто большие дети, которые с восторгом соревнуются и шутят».

Второе дыхание: что изменил спорт

Самое интересное начинается, когда спрашиваешь не «что спорт дал», а «что поменял».

У Алексея Лосева два таких открытия, и оба выросли прямо из его гонок. Первое — про то, как браться за неподъёмное: «Сложную задачу начинаешь решать, сделав один шаг». Тот самый шаг из лагеря волонтёров, перенесённый в кабинет. Второе он усвоил на финишном отрезке, когда силы кончились и в одиночку он уже не укладывался в лимит: «Я зацепился за группу других участников, вцепился зубами и „рюкзаком“ продолжил с хорошим темпом». Так была закрыта сложнейшая гонка его жизни — не в одиночку. Отсюда вывод: «Сверхдостижений можно добиться только с командой единомышленников».

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

Млада вынесла из спорта другое — отношение к темпу: «В работе есть соблазн требовать от себя и команды одинаково высокой скорости всё время. Но в спорте так не бывает: есть дни, когда ты летишь, а есть дни, когда главная задача — не сломаться и сделать работу достойно».

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

Есть у бега и совсем прикладная польза — он «разгружает» голову. «В процессе голова освобождается от мыслей и проблем, ты как ребёнок находишься в потоке. А вот по завершении, на перезагрузившуюся голову, частенько приходят новые мысли», — говорит Алексей Озеров.

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

Финиш: разные награды

А вот на финише наши герои расходятся — и это, пожалуй, то самое честное и неожиданное.

Для Алексея Озерова главное — эйфория: «Обычно я страдаю с первого до последнего километра, но на 70–80% дистанции накрывает адреналин и особое чувство, когда кажется, что можешь абсолютно всё. Вот это я люблю больше всего».

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

Млада на том же финише чувствует другое и подбирает неожиданное для человека со штангой и боксёрскими перчатками слово — умиротворение. «Это не всегда эйфория с фанфарами. Иногда это тихое ощущение: «Я справилась». И оно мне очень дорого».

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

Почему RUNIT by AGIMA

Любопытно, что почти никто из них не говорит про секунды в протоколе.

«Это возможность увидеть коллег с другой стороны, позитивный формат и классная программа», — говорит Лосев, которому есть с чем сравнивать. Озеров привязан к фестивалю историей: здесь он начинал и здесь же хочет взять первый полумарафон. Колесова не скрывает мотивации и формулирует её очень обаятельно: «Меня привлекают коллеги. Они заманивают вкусняшками и пивом, и я не против — побегу с ними куда угодно, сколько угодно, возможно даже в +30. Фестиваль даёт почувствовать наше единство».

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

RUNIT by AGIMA пройдёт 5 июля в московском Мещерском парке. В программе — дистанции от детских 200 метров до полумарафона 21,1 км, командные зачёты и эстафеты, а после финиша — фестиваль с музыкой, фудкортом и зонами для своих.

Вместо вывода

Я попросил героев закончить фразу «бег научил меня тому, что…».

На мой взгляд, у Млады получилось мудро: «Устойчивость важнее героизма: не каждый день обязан быть победой, зато каждый может стать шажком вперёд».

А у Алексея Озерова парадоксально-честно: «Научиться бегу невозможно».

Практически гимн получился у Сайыыны Колесовой, им и хочется завершить эту статью: «Бег научил меня тому, что я могу бегать, могу бегать хорошо, быстро и долго. Я могу всё. Я могучий человек!»

В статье разберём этот эффект на примере легаси-систем, с которыми работает Centicore Group. Компания занимается модернизацией устаревшего кода, баз данных и инфраструктуры, а также системным и бизнес-анализом, разработкой ПО и контролем качества.

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

Что считаем техдолгом

Чтобы посчитать ROI рефакторинга, сначала нужно определить, что именно команда считает техническим долгом. Без этого в один список попадут баги, старые библиотеки, слабые тесты или желание сменить стек. У таких задач разные причины, цена и источники бюджета, поэтому их нельзя приоритизировать как одну категорию.

Термин «технический долг» ввёл программист Уорд Каннингем в 1992 году. Он использовал финансовую метафору: команда может выбрать более быстрое техническое решение, получить выгоду сейчас, а позже заплатить за это доработкой и дополнительными расходами.

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

Из этого определения следует, что не каждую техническую проблему стоит записывать в техдолг:

1. Баг — это ошибка в реализации. Техдолга здесь нет: никто не принимал осознанного решения сделать хуже. Поэтому баги относятся к дефект-менеджменту и финансируются из бюджета на поддержку, а не из бюджета на рефакторинг.
2. Желание применить новую технологию — это новое требование к продукту. Команда хочет заменить PostgreSQL на что-то другое или перейти с REST на gRPC. Если это обосновано и полезно — отлично, но это отдельная задача со своей оценкой и своим источником финансирования.
3. Устаревший код без измеримых последствий — тоже не долг. Если модуль написан пять лет назад, но команда работает с ним без дополнительных затрат времени, он никого не тормозит и не создаёт рисков — переписывать его ради переписывания не нужно. Техдолг возникает в момент, когда команда признаёт: вот это решение замедляет нас, и мы можем точно сказать, как именно.

У каждой категории своя логика и бюджет. Баги относятся к дефект-менеджменту, новые технологии — к развитию продукта, обучение — к развитию команды. Если всё сложить в один бэклог и назвать техдолгом, ресурсы будут расходоваться непрозрачно, а разговор с бизнесом снова сведётся к просьбе выделить время на внутренние задачи.

Как техдолг превращается в расходы

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

Объём работ — это всё, что нужно сделать, чтобы вернуться в целевое состояние. Раздробить монолитный модуль, заменить самописную библиотеку на поддерживаемую, переписать слой работы с БД. Объём работ оценивается в часах или стори-поинтах — это конечная сумма, которую команда выплатит один раз.

Текущие потери — это то, что команда теряет каждый спринт, пока долг не закрыт. Они накапливаются постепенно и часто не видны явно, пока их не начинают считать. Несколько типичных примеров: медленная сборка съедает по 20 минут на каждый деплой при восьми деплоях в день — это больше двух часов потерь ежедневно на каждого разработчика, который её ждёт. Запутанная структура модуля добавляет час к онбордингу каждого нового члена команды и увеличивает время оценки задач. Отсутствие тестов на критическом участке означает ручную проверку при каждом релизе.

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

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

Какие задачи по техдолгу считать через ROI

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

Через ROI стоит считать задачи, которые конкурируют с фичами за время команды. У таких задач есть цена, влияние на скорость разработки и понятный конфликт с продуктовым планом. Например:

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

Отдельно стоят системные решения — их нельзя решать на уровне одного спринта. Для них нужна отдельная оценка, архитектурное решение и согласование с бизнесом. Например:

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

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

Где искать расходы в легаси перед расчётом ROI

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

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

В результате у вас появляется список участков, где легаси создаёт дополнительные расходы, например: замедляет разработку, усложняет поддержку, повышает риски или ограничивает будущие изменения. Этот список нужен для следующего шага — оценки ROI рефакторинга.

Как считать ROI

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

Шаг 1. Посчитайте текущие потери. Зафиксируйте, сколько дополнительного времени команда тратит из-за конкретной проблемы прямо сейчас. Медленная сборка — сколько минут в день суммарно по команде. Сложный для понимания модуль — сколько часов уходит на оценку задач в нём. Отсутствие тестов — сколько времени занимает ручная проверка перед каждым релизом. Переведите это в деньги через стоимость часа работы команды.

Шаг 2. Оцените объём работ. Сколько займёт исправление — в часах, с буфером на непредвиденное. Это тоже деньги: стоимость часа умножить на объём.

Шаг 3. Посчитайте горизонт окупаемости. Если текущие потери составляют 20 000 рублей в неделю, а объём работ стоит 80 000 рублей, рефакторинг окупается за четыре недели. Дальше каждая неделя — чистая экономия. Если горизонт окупаемости укладывается в срок, на который планируется развитие продукта, рефакторинг финансово обоснован.

Шаг 4. Введите два порога вместо полного ранжирования. Определите верхний порог — задачи выше него идут в работу в приоритете над новыми фичами, потому что их текущие потери слишком высоки. И нижний порог — задачи ниже него откладываются, потому что их стоимость исправления не окупится в обозримом горизонте. Всё между порогами сравниваете через RICE: потенциальный эффект умножить на охват и коэффициент уверенности, разделить на трудоёмкость.

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

Как обосновать рефакторинг бизнесу

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

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

1. Скорость поставки. Покажите данные из трекера: сколько времени уходило на задачи в конкретном модуле полгода назад и сколько уходит сейчас. Если время выросло в полтора раза при сопоставимой сложности задач, это измеримое замедление с понятной причиной.
2. Предсказуемость оценок. Команда с накопленным техдолгом не может точно эстимировать: задача на три дня превращается в две недели, потому что в процессе обнаруживаются связанные проблемы. Для бизнеса это означает срыв сроков и невозможность планировать релизы. Покажите расхождение между оценками и фактом за последние несколько спринтов.
3. Риски. Неподдерживаемые зависимости, отсутствие покрытия тестами на критических участках, архитектура, которая не выдержит роста нагрузки при следующем масштабировании. Риски переводятся в деньги через вероятность и стоимость инцидента.

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

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

Итого

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

По факту, это обычное инженерно-финансовое решение: либо команда закрывает объём долга сейчас, либо продолжает оплачивать его через более дорогие фичи, поддержку, регресс и риски в проде.

Как из такого состояния перевезти 400 петабайтов логов в единую систему и не уронить работу сервисов, расскажем в статье совместно с экспертом.

Точка кипения — технический тупик

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

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

До старта проекта OneData в ключевых подразделениях компании — Почте Mail.ru, Одноклассниках, ВКонтакте, VK Рекламе и поиске — параллельно работало пять отдельных крупных инсталляций Hadoop. Существовавший ландшафт порождал серьезную неэффективность. Суммарные вычислительные мощности использовались в среднем лишь на 50% по CPU. При этом каждый кластер требовал выделенной команды администраторов: до 10 высококвалифицированных инженеров на каждый бизнес-юнит. Фактически десятки специалистов выполняли дублирующие задачи по поддержке идентичного стека. Расходы на железо (CAPEX) и эксплуатацию (OPEX) множились, не принося добавочной ценности.

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

Выбор технологического ядра

При проектировании фундамента единой платформы данных перед командой стоял выбор между тремя способами устройства инфраструктуры.

Первый вариант — классический Hadoop (HDFS). От него решили отказаться из-за плохой масштабируемости по количеству файлов (проблемы NameNode) и сложности адаптации под современные облачные подходы. Кроме того, поиск и найм специалистов по глубокой поддержке Hadoop становился все более сложной задачей.

Второй вариант — объектное хранилище (S3). Техническая база для построения огромного S3 в компании существовала, но этот путь признали подходящим скорее для долгосрочного архива. Главным минусом S3 стала невозможность эффективной работы в режиме near real-time (NRT). Для рекомендательных систем и рекламы, где данные должны обновляться практически мгновенно, задержки S3 были неприемлемы.

В итоге выбор пал на YTsaurus . Эта технология позволила построить гибкую систему, поддерживающую и батчевую, и потоковую обработку данных. Она работает на commodity-железе, что позволило эффективно переиспользовать серверы, оставшиеся от старых Hadoop-кластеров. В реализации OneData режим NRT работает бесшовно: в зависимости от бизнес-задачи используется либо микробатчинг, либо прямой стриминг из Kafka в таблицы.

Основным интерфейсом для работы с платформой стал YQL — SQL-подобный язык запросов. Это позволило снизить порог входа: 80% повседневных задач аналитики решают с помощью знакомого синтаксиса. Для тяжелых вычислений и ML-трансформаций в платформу интегрированы Python, SPYT (Spark над YT) и CHYT (аналитический слой ClickHouse над YT), который обеспечивает минимальные задержки при доступе к витринам.

Архитектура: от сырых логов до витрин

Процесс структурирования данных разбит на несколько строго регламентированных этапов. Источниками служат Kafka, PostgreSQL и внешние системы. Для доставки данных используется LogFather — унифицированный инструмент, работающий на двух уровнях: сбор миллионов мелких событий в реальном времени и репликация целых таблиц из рабочих баз без написания ETL-кода вручную.

Внутри выстроена слоистая архитектура, обеспечивающая чистоту данных:

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

• ODS (Operational Data Store). На этом этапе происходит первичная очистка, типизация и, что самое важное, проверка схем (Schema Validation). Если сервис-источник внезапно изменит формат лога (например, заменит числовое поле строковым), импорт в единую платформу данных будет заблокирован. Это защищает хранилище от каскадных падений и замусоривания невалидными данными.

• DDS (Detail Data Store). Слой нормализованных данных, приведенных к единому корпоративному стандарту.

• DM (Data Marts). Финальные витрины, оптимизированные под конкретные бизнес-отчеты. Благодаря ранее упомянутому CHYT, аналитики получают доступ к этим данным практически мгновенно.

Решение проблемы зоопарка идентификаторов

Одной из самых сложных инженерных задач стало приведение к общему знаменателю пользовательских идентификаторов. У каждого продукта была своя логика: в Почте это был uid, в Одноклассниках — userID, в Дзене — guid. Чтобы собрать единый профиль пользователя для сквозной аналитики, раньше требовались недели ручного маппинга и согласований.

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

Надежность данных: SLA и роль Data Owner

Чтобы платформа не превратилась в неуправляемое «болото данных», в ее архитектуру интегрированы механизмы контроля качества (Data Quality). На текущий момент в OneData полноценно функционируют два ключевых направления.

1. Контроль своевременности (SLA). Автоматизированный мониторинг в реальном времени непрерывно отслеживает график поступления информации в хранилище. В случае задержки обновления любой критически важной таблицы система в автоматическом режиме генерирует инцидент, который направляется команде владельца данных (Data Owner). Это решение выходит за рамки простой технической надстройки: для обеспечения бесперебойности приоритетных потоков данных в компании организованы дежурства в режиме 24/7.
2. Содержательный контроль (DQ-чеки). Специализированные алгоритмы-чекеры анализируют входящие потоки на предмет дублей, пропусков и различных статистических аномалий. Важной архитектурной особенностью является работа этих проверок в режиме уведомлений. Они не прерывают выполнение расчетов, чтобы не парализовать работу бизнес-юнитов, но при этом мгновенно оповещают потребителей о возникновении проблем в конкретной витрине. Такой подход позволяет сохранить непрерывность бизнес-процессов, одновременно информируя аналитиков о качестве доступных цифр.

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

Организационный вызов: песочницы и учения

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

Для преодоления барьера команда инфраструктуры использовала тактику учений. Заранее объявлялись даты физического вывода из эксплуатации старых Hadoop-кластеров, и проводились пробные кратковременные отключения. Это стало лучшим стимулом для бизнес-юнитов завершить миграцию в установленные сроки. Чтобы облегчить процесс, была организована масштабная поддержка: видеокурсы, чаты с экспертами и запуск ИИ-помощника Data Copilot. Основную нагрузку по переносу кода взяли на себя DWH-аналитики, что позволило продуктовым командам не останавливать разработку фич.

Для безопасного сосуществования 35 юнитов в одном контуре были внедрены песочницы (Unit Sandboxes). Каждый продукт работает в своем изолированном сегменте, имея доступ к общим справочникам и возможность делиться своими данными с другими командами внутри группы. Изменение данных в общих критических слоях требует обязательного ревью от Data Owner. Также внедрена строгая ролевая модель доступа: права выдаются персонально под задачу, а системы безопасности мониторят подозрительные паттерны активности (например, попытки выгрузки больших объемов данных за пределы контура).

Результаты для бизнеса: DevEx и A/B-тестирование

Главным итогом создания единой платформы данных стало кратное ускорение работы с данными (Time-to-Insight).

Благодаря автоматизации и внедрению Self-Service инструментов, скорость работы аналитиков с кросс-данными выросла в разы. Сегодня создание тестовой таблицы в песочнице для проверки гипотезы занимает около 1 часа. Вывод полноценного кода в продакшн с учетом всех доступов, автоматических проверок, ревью и постановки на расписание, сократился до 1–2 дней. Раньше этот процесс мог растягиваться на недели из-за межкомандных взаимодействий.

На базе платформы была развернута единая А/В-платформа. Это позволило внедрить общую методологию экспериментов по всей группе компаний. Теперь менеджеры продуктов могут корректно оценивать сквозные эффекты: например, как изменение алгоритма в одном сервисе влияет на вовлеченность пользователей в другом.

Будущее платформы: ИИ и глобальная дедупликация

Процесс развития OneData продолжается. Главная цель на ближайшее время — завершение миграции крупнейших проектов, включая ВКонтакте. Полный вывод из эксплуатации (EOL) всех старых разрозненных хранилищ Hadoop намечен на конец 2026 года.

За счет устранения дублирования данных и отказа от избыточного хранения объем информации только в рекламном контуре должен сократиться в три раза — со 100 ПБ до 30 ПБ. При этом платформа уже сегодня эффективно оперирует объемами в сотни петабайт.

Важным направлением станет интеграция ИИ в работу с данными. Чат-бот Data Copilot уже помогает аналитикам ориентироваться в тысячах таблиц и генерировать рабочий YQL-код по текстовому запросу, опираясь на внутренние метаданные о структуре платформы данных. В планах — интеграция этого функционала напрямую в интерфейсы разработки (IDE), что позволит еще сильнее сократить путь от бизнес-гипотезы до конкретных показателей.

Практика показывает, что без единого слоя данных компания упирается в потолок: метрики считаются по-разному, кросс-продуктовые сценарии не сходятся, а любые изменения требуют синхронизации между командами. Единый фундамент снимает эти ограничения. Данные становятся сопоставимыми, эффекты — измеримыми, а решения — быстрее и точнее.

BerryLM-XL заняла 3-е место в общем рейтинге MERA и 2-е среди ИИ-моделей.

Интегральная оценка — 0,835, эталон Human Benchmark — 0,852.

Вторая модель семейства, BerryLM-v2, с результатом 0,810 замкнула топ-5.

Модели применяются в продуктах Wildberries и приносят компании более 1 млрд рублей дополнительной выручки в год.

Что известно

MERA (Multimodal Evaluation for Russian-language Architectures) — открытый бенчмарк для оценки моделей, работающих с русским языком. Текстовый рейтинг строится на единой методологии с фиксированными заданиями и параметрами: модели проверяют на понимание текста, знания, логику и прикладные задачи.

BerryLM-XL получила интегральный балл 0,835. Для сравнения: Human Benchmark — эталонная оценка, рассчитанная на ответах людей на те же задания, — составил 0,852. Таким образом, дообученная RWB модель приблизилась к человеческому уровню на одном из крупнейших русскоязычных тестов.

Помимо BerryLM-XL, в топ-5 вошла ещё одна модель семейства — BerryLM-v2. Она набрала 0,810 и заняла пятое место в лидерборде.

Характеристики BerryLM-XL

• Архитектура: MoE-модель с 358 млрд параметров.
• Тип: закрытая модель с дообучением SFT и упором на reasoning.
• Контекст: до 202 000 токенов.
• Post-training: вариант GRPO с двумя reward-функциями для контроля качества рассуждений.

Где применяются модели BerryLM

Семейство BerryLM работает в продуктах Wildberries: ИИ-ассистент для покупателей, сравнение и поиск товаров, инструменты для продавцов — подготовка ответов на отзывы и вопросы. Кроме того, модели автоматизируют внутренние процессы RWB. По внутренней оценке компании, суммарный эффект от ИИ-инструментов на базе BerryLM превышает 1 млрд рублей дополнительной выручки в год.

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

Вопросы и ответы

Выводы

BerryLM-XL подтвердила уровень мировых LLM на русскоязычном бенчмарке. Главное же, по словам представителей RWB, — не сама позиция в рейтинге, а то, что модель приносит измеримый бизнес-эффект: покупатели получают более точные ответы, продавцы экономят время, а компания наращивает выручку. Подробные цифры и методику оценки можно посмотреть на странице сабмита BerryLM-XL на MERA.

Источники

• MERA — BerryLM-XL submit

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

Так появляется классическая ловушка legacy: систему надо модернизировать, но остановить развитие нельзя. Переписать всё с нуля страшно, поддерживать как есть — всё дороже. В результате продукт обрастает временными решениями, скорость разработки падает, а стоимость каждого следующего изменения растет.

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

Почему Big Bang-переписывание чаще всего заканчивается плохо

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

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

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

Допустим, команда решила переписать модуль заказов в e-commerce-продукте. В старой версии есть корзина, промокоды, доставка и оплата. Команда планирует за полгода сделать новый сервис заказов. Но за эти полгода бизнес добавляет подписки, подарочные сертификаты, частичную оплату бонусами и новую логику возвратов. В итоге новая система, которую проектировали под старые требования, к моменту релиза уже нуждается в доработке.

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

Big Bang всё-таки бывает оправдан — но в узких условиях. Если кодовая база молодая (год-два), пользователей мало, у системы нет критичного состояния в БД и продукт можно временно заморозить или вести в обоих контурах параллельно, полное переписывание может оказаться дешевле постепенной миграции. Это редкая ситуация, и она быстро исчезает по мере роста продукта. В зрелых системах безопаснее работает другой подход — постепенная архитектурная эволюция.

Пример: как команда переписала сервис документов и потеряла полгода

Команда сопровождала сервис — старый модуль на aiohttp с Pydantic v1, через который проходила вся обработка путевых листов и актов осмотра транспорта. Сервис существовал шесть лет, был покрыт тестами фрагментарно, а его API использовали мобильное приложение водителей, диспетчерская веб-панель и пакетный импорт.

Команда решила переписать сервис целиком: перейти на FastAPI, обновить Pydantic до v2, заодно почистить контракты и заменить внутреннее хранилище документов с MongoDB на PostgreSQL. План был рассчитан на четыре месяца.

Через восемь месяцев проект всё ещё не был готов к выкатке, а к десятому месяцу команда откатила миграцию полностью. Причин было несколько.

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

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

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

В-четвёртых, переключение было сделано «в лоб»: маршрут в API Gateway просто перенаправили на новый сервис. Фича-флага не было, теневого запуска не было, плана отката не было. Когда выяснилось, что новый сервис строже валидирует исторические форматы документов и отклоняет часть старых записей, быстро вернуться на старую реализацию не получилось — её к тому моменту уже отключили на стенде, а в БД успели уйти записи в новом формате.

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

Strangler Fig Pattern: как заменить систему по частям

Один из самых практичных подходов к модернизации legacy-кода — Strangler Fig Pattern. В софтверном виде паттерн был сформулирован Мартином Фаулером в 2004 году под названием StranglerFigApplication. Идея проста: не переписывать систему целиком, а постепенно выносить отдельные части в новую реализацию.

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

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

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

Strangler Fig хорошо работает там, где между старым и новым кодом есть сетевая граница: HTTP, message bus, RPC. Если такой границы нет — например, нужно постепенно заменить функцию или класс внутри одного процесса — используется родственный паттерн Branch by Abstraction: над старой реализацией создается абстракция, рядом пишется новая реализация, переключение происходит через конфигурацию или фича-флаг, после стабилизации старая ветка удаляется. Снаружи это выглядит как Strangler Fig, но без сетевого прокси.

Такой подход снижает риск. В системе нет одного большого релиза, где всё меняется сразу. Есть серия небольших контролируемых изменений. Каждое можно протестировать, измерить и откатить.

Главное правило: сначала повторить поведение, потом улучшать

Одна из частых ошибок при модернизации legacy-кода — попытка одновременно переписать систему и улучшить бизнес-логику. Команда смотрит на старый модуль и думает: «Раз уж мы его трогаем, давайте сразу сделаем нормальную архитектуру, изменим контракты, уберем странные кейсы и перепишем поведение».

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

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

Прежде чем менять поведение, его нужно зафиксировать. Для этого пишут характеристические тесты (characterization tests, иногда называемые golden master или approval tests). Идея простая: на реальных данных или их обезличенных копиях прогоняется старая реализация, её ответы сохраняются как эталон, и любые будущие изменения, отклоняющиеся от эталона, отлавливаются автоматически. Тесты пишутся не для красоты, а для того, чтобы зафиксировать существующее поведение — даже странное — перед тем, как его трогать. Подробно эта техника описана у Майкла Физерса в книге Working Effectively with Legacy Code; на практике её удобно реализовать через библиотеки семейства approval-tests (approvaltests-python, approvaltests-java и аналоги).

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

Feature toggles: как включать новую логику без риска

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

В обычной разработке релиз часто выглядит бинарно: код либо выкатили, либо нет. При миграции legacy это неудобно. Гораздо безопаснее иметь возможность включить новую реализацию для 1% пользователей, затем для 10%, потом для половины аудитории и только после этого для всех.

Например, команда переносит расчет стоимости доставки из монолита в новый сервис. С помощью фича-флага это выглядит так:

user_id передается явно, чтобы решение «попал ли пользователь в новый сегмент» было стабильным от запроса к запросу. Иначе один и тот же клиент будет получать разные ответы при обновлении страницы, и поведение системы станет непредсказуемым.

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

Важно различать два разных типа флагов. Флаг постепенной выкатки (rollout flag) меняется редко и контролирует, какой процент пользователей видит новую логику. Kill switch — отдельный флаг, единственная задача которого — мгновенно выключить новую реализацию при инциденте. Kill switch должен опрашиваться на каждом запросе, его кэширование должно жить секунды, а не минуты, и он принципиально не должен зависеть от той системы, которую он выключает. Иначе в момент аварии может оказаться, что выключатель сам недоступен.

В качестве инфраструктуры для флагов команды обычно берут одну из платформ: LaunchDarkly, Unleash, Flagsmith, GrowthBook, либо собирают собственную поверх Redis или конфигурационного сервиса. Для миграции важны три свойства: быстрое распространение изменений (секунды, а не минуты), поддержка таргетинга по пользователю/сегменту и аудит — кто и когда менял флаг.

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

Последний пункт особенно важен. Если флаги не удалять, система быстро превращается в набор ветвлений, где никто уже не понимает, какая логика актуальна.

Shadow testing: как проверить новую систему на реальном трафике

Feature toggles помогают безопасно переключать пользователей. Но перед этим хорошо бы понять, совпадает ли новая логика со старой. Для этого используют shadow testing.

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

Например, есть старый модуль расчета скидок. Он учитывает промокоды, сегмент пользователя, историю покупок, регион и партнерские условия. Команда пишет новый сервис скидок. Чтобы не переключать пользователей сразу, можно запустить теневой режим:

Два момента, на которые стоит обратить внимание в этом коде. Теневой вызов запускается через asyncio.create_task — корутина сразу планируется в event loop и начнёт выполняться, как только функция вернёт управление. И весь блок завернут в try/except: исключение в новой логике не должно ронять основной запрос. Без этих двух свойств shadow testing рискует ухудшить продакшен вместо того, чтобы безопасно его проверить.

Небольшая оговорка для продакшена: event loop держит на task только слабую ссылку, и без сохранённой ссылки задача может быть собрана сборщиком мусора прямо во время выполнения. В реальном коде Task имеет смысл класть в set фоновых задач и удалять оттуда через add_done_callback. В примере выше эта обвязка опущена для читаемости.

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

Shadow testing особенно полезен для критичных доменных частей: платежей, биллинга, расчета тарифов, персональных предложений, транзакций. Там нельзя просто «попробовать на пользователях» и посмотреть, что будет.

При этом важно отличать теневую проверку чтения от теневой проверки записи. Чтение проверить относительно дёшево: запрос идёт в обе системы, ответы сравниваются, никаких внешних эффектов нет. С записью всё сложнее. Если новая реализация в shadow-режиме действительно создаст заказ, спишет деньги или отправит письмо, у пользователя возникнут двойные эффекты. Поэтому для writes либо вводят идемпотентные ключи и shadow-режим без реальных побочных действий (внешние вызовы заменены no-op-стабами, БД — отдельной shadow-копией), либо вообще отказываются от теневой проверки записи в пользу постепенной выкатки за фича-флагом.

Сравнение ответов в реальной системе тоже не сводится к одной функции compare. Нужно отдельно решать, как игнорировать «нормальный» шум (метки времени, идентификаторы, порядок коллекций), как сэмплировать трафик, чтобы не утопить хранилище расхождений, и как организовать триаж — кто и в каком ритме разбирает накопившиеся диффы. Готовые решения этого класса — GitHub Scientist (Ruby и его порты в другие языки), Twitter Diffy, либо собственный лёгкий регистратор поверх Kafka и таблицы расхождений.

С чего начинать модернизацию

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

Удобный способ выбрать первый кусок — оценить кандидатов по двум осям: насколько модуль критичен для бизнеса (low / high) и насколько сильно он связан с остальной системой (low / high). Начинать стоит с квадранта low-criticality + low-coupling: ошибки в нем не уронят бизнес-показатели, а малое количество зависимостей позволит провести миграцию полностью, не утянув за собой смежные модули. Высоко-критичные и сильно связанные части (платежи, ядро авторизации) трогают в последнюю очередь — на этот момент команда уже наберёт опыт безопасной миграции.

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

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

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

Миграция данных: самая сложная часть

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

Базовый рабочий приём — Expand-Contract (он же Parallel Change). Изменение схемы делается в три такта. На этапе expand в БД добавляются новые поля, таблицы или индексы, при этом старое поведение полностью сохраняется. Затем — migrate: обе реализации начинают писать и в старое, и в новое место (dual writes), а отдельный фоновый процесс делает backfill — заполняет новые поля историческими данными. После этого читатели по одному переключаются на новую схему. Только когда никто из читателей не использует старую структуру, наступает contract — удаление лишних колонок и таблиц.

Несколько практических деталей, которые часто упускают:

· Dual writes — это не бесплатная операция. Две записи означают две точки отказа. Если одна из них упала, нужно решать, что делать: продолжать ли работу, ставить ли событие в очередь на повтор, помечать ли запись как несогласованную. Простое «сначала пишем туда, потом сюда» в продакшене на нагрузке приводит к расхождениям.

· Backfill часто длиннее, чем кажется. На большой таблице миграция в одном UPDATE блокирует продакшен. Поэтому backfill делают батчами по N тысяч строк с паузами, отслеживают прогресс и предусматривают возможность остановить и продолжить.

· Онлайн-изменения схемы на крупных таблицах делаются не штатным ALTER TABLE, а специализированными инструментами: gh-ost или pt-online-schema-change для MySQL, встроенные онлайн-механизмы PostgreSQL для индексов и колонок, Liquibase/Flyway — для управления версионированием изменений в репозитории.

· Shadow testing данные не покрывает. Можно сравнить, что новая реализация возвращает то же, что и старая, но если за этим стоит другая схема в БД, проверка корректности самой миграции данных — это отдельная работа: сверки, контрольные суммы, выборочный аудит исторических записей.

Без этих шагов любая красивая фасадная архитектура наталкивается на разъезжающиеся данные — и тогда даже идеальный Strangler Fig снаружи не спасает.

Прокси-слой как точка контроля

Чтобы постепенно заменять legacy-код, нужно управлять маршрутизацией запросов. Для этого часто создают прокси-слой, API Gateway или фасад, через который проходит обращение к старой и новой логике. В терминах Domain-Driven Design такой слой часто называют Anti-Corruption Layer: он защищает новую реализацию от старых контрактов и наоборот, позволяя двум моделям сосуществовать без взаимного «загрязнения».

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

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

В качестве технической основы команды обычно берут один из трех вариантов: классический API gateway (Kong, AWS API Gateway), service mesh (Envoy, Istio) или более простой reverse proxy (NGINX, HAProxy). Service mesh особенно удобен, когда трафик уже идёт внутри Kubernetes-кластера: маршрутизацию можно менять конфигурацией, без правок кода клиентов и сервисов.

Например, мобильное приложение обращается к endpoint /orders/history. Раньше этот endpoint напрямую обслуживал монолит. После введения API Gateway приложение продолжает ходить по тому же контракту, но внутри gateway может решать, куда направить запрос: в legacy-модуль или новый сервис истории заказов.

Управление маршрутизацией обычно делается не «всё или ничего», а на основании атрибутов запроса: значения заголовка (X-Migration-Cohort: new), куки, хэша от user-id (стабильное разбиение пользователей на сегменты) или географического региона. Это позволяет выкатывать новую реализацию сначала на одну страну, на сотрудников самой компании или на тестовый сегмент — и только потом расширять охват.

Для клиента ничего не меняется. Для команды появляется управляемость.

Наблюдаемость: без метрик миграция превращается в гадание

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

Минимальный набор — это логи, метрики и распределенная трассировка (distributed tracing). Нужно понимать, сколько запросов идет в старую и новую реализацию, сколько ошибок возникает, как меняется latency, где появляются таймауты, какие статусы возвращаются, какие бизнес-метрики проседают.

Технические метрики стоит формулировать не как «средний ответ» и «процент ошибок», а в терминах SLI и SLO: целевые показатели вида «99.9% запросов на /orders/history отвечают быстрее 300 ms за 30 дней» с явным error budget. Latency измеряется по перцентилям (p50, p95, p99) — среднее значение почти всегда обманчиво, а хвосты распределения говорят о реальном опыте пользователя. На время миграции имеет смысл выставить отдельные SLO для нового и старого пути и сравнивать их.

В качестве инструментов де-факто стандартом стал OpenTelemetry для трассировок, метрик и логов — единый протокол, который пишет в практически любое хранилище. Дальше — Prometheus и Grafana для метрик, Jaeger или Tempo для traces, Sentry или аналог для ошибок. Для миграции важна возможность фильтровать метрики по «варианту» — отдельно по старому и новому пути — иначе все цифры смешаются и реальную динамику будет не видно.

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

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

Практическая последовательность миграции

Рабочая последовательность обычно выглядит так.

Сначала команда выбирает ограниченный участок системы. На этом этапе важно не просто назвать модуль, а описать его границы. Какие сценарии он закрывает? Кто его вызывает? Какие данные он читает и пишет? Какие внешние интеграции использует? Какие неочевидные бизнес-правила в нем есть?

Затем поверх legacy-логики создается стабильный контракт. Это может быть API, фасад, gateway или отдельный слой внутри приложения. Главная задача — сделать так, чтобы клиенты зависели не от внутренней реализации, а от понятного интерфейса. На этом этапе полезно вспомнить про contract testing (Pact, Spring Cloud Contract): автотесты со стороны потребителей фиксируют, что именно они ожидают от API, и предупреждают о ломающих изменениях до того, как они доедут до продакшена.

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

Следующий этап — shadow testing. Новая система получает копии реальных запросов, считает результат, но пользователю по-прежнему возвращается ответ legacy. Команда сравнивает результаты и устраняет расхождения.

Когда новая реализация достаточно стабильна, начинается постепенное переключение через feature toggles. Сначала внутренние пользователи, потом 1% реального трафика, затем 5–10%, затем 50% и только после этого 100%.

На каждом этапе команда смотрит на метрики. Если всё стабильно, движение продолжается. Если появляются проблемы, флаг выключается, трафик возвращается в legacy, а команда разбирает причины.

Последний этап — удаление старого кода. Это не формальность, а обязательная часть миграции. И «удалить старый код» — это не один коммит, а явный Definition of Done: вырезана старая ветка кода, удалён фича-флаг, обновлена документация и схемы архитектуры, переименованы или удалены устаревшие дашборды и алерты, обновлены runbook’и для on-call и проведено короткое внутреннее обучение. Если этого не сделать, через полгода никто уже не вспомнит, какой путь актуален, и легаси-ветвление останется в коде навсегда.

Откат миграций: дешёвый только пока не пошли записи

Откатить миграцию, в которой ещё не было записи в БД, легко: достаточно переключить фича-флаг, и трафик снова идёт через старую реализацию. Откатить миграцию, в которой новая система уже неделю писала данные в новые таблицы, — отдельный, гораздо более тяжёлый разговор.

Поэтому ещё на этапе проектирования каждое изменение должно сопровождаться явным планом отката. Удобно различать три типа шагов.

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

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

Forward-only. После некоторой точки откат становится невозможен — например, после того, как старая схема удалена или внешние интеграции перенастроены на новый сервис. Такие шаги допустимы, но к ним нужно приходить отдельно, осознанно, с особенно строгими SLO в предыдущем этапе. До forward-only-перехода имеет смысл подержать систему в режиме параллельной работы дольше, чем по графику.

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

Пример: как тот же сервис мигрировали со второй попытки

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

На первом шаге они зафиксировали поведение существующего сервиса. На самые часто используемые сценарии (создание путевого листа, подпись акта осмотра, выгрузка пакета документов за период) написали характеристические тесты на реальных продакшен-данных, обезличенных и сохранённых как фикстуры. Любое будущее изменение поведения теперь падало в CI как явное расхождение.

Параллельно команда провела инвентаризацию побочных эффектов. Из исходного кода и логов выяснилось, что сервис не только хранит документы, но и: публикует событие в Kafka при смене статуса, инкрементирует счётчик в Redis для рейтинга водителей, отправляет webhook во внешнюю систему партнёра, пишет в таблицу аудита. Каждый из этих эффектов попал в отдельный пункт чек-листа «что должно остаться» в новой реализации.

Затем команда выбрала первый кусок для выноса — не весь сервис, а только чтение документов (GET /documents/{id} и GET /documents/by-driver/{driver_id}). Это была наименее рискованная часть: ошибки в чтении неприятны, но не ломают финансовые потоки.

Новый сервис написали на FastAPI рядом со старым. На уровне API Gateway появилось правило маршрутизации: запросы на чтение шли в старый сервис, но в фоне дублировались в новый. Ответ пользователю всегда возвращал legacy, а ответ нового сервиса сравнивался с эталоном и записывался в отдельную таблицу для разбора. Использовали обёртку поверх asyncio.create_task — на ответ пользователя теневой вызов не влиял.

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

Когда расхождений не осталось, включили фича-флаг на сотрудников самой компании. Через неделю — на 1% реальных водителей. Дальше шаг по 5%, 25%, 50%, 100% с паузой в несколько дней между этапами. На каждом шаге следили не только за HTTP-ошибками и latency, но и за продуктовыми метриками: количество подписанных актов, время от открытия документа до подписи, доля повторных запросов. Один раз пришлось откатиться с 25% на 5% — в одном из регионов выросло время отклика из-за неэффективного запроса. Исправили, выкатили снова.

Через два месяца чтение полностью перешло в новый сервис. Старый код чтения и фича-флаг удалили в том же релизе. После этого по той же схеме мигрировали запись документов, потом публикацию событий, потом импорт из внешних систем. Полная миграция заняла девять месяцев — почти столько же, сколько провалившийся Big Bang, — но продукт всё это время продолжал развиваться, инцидентов не было, и в конце команда осталась с системой, которую понимает.

Типичные ошибки при работе с legacy

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

Вторая ошибка — недооценивать скрытые зависимости и побочные эффекты. Legacy-код часто делает больше, чем кажется. На один и тот же вызов могут быть навешаны: запись в таблицу аудита, инкремент счётчика в кэше, публикация события в очередь, обновление статуса связанной сущности, инвалидация кэша, дёрганье webhook’а во внешнюю систему. Если в новой реализации воспроизвести только явный путь, скрытые потребители молча перестанут получать данные — и узнают об этом через жалобу бизнеса, а не через ошибку в логах. Поэтому перед выносом любого модуля имеет смысл составить инвентаризацию побочных эффектов: пройтись по коду и логам и выписать каждое нелогичное действие отдельным пунктом чек-листа.

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

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

Пятая ошибка — не удалять старый код. Временное сосуществование старой и новой логики нормально. Вечное сосуществование — нет. Если legacy не удаляется, технический долг не уменьшается, а просто меняет форму.

Шестая ошибка — не удалять фича-флаги после миграции. Флаг, который сыграл свою роль и больше никогда не выключается, превращается в постоянное ветвление в коде. Через год команда не помнит, можно ли удалить такую ветку или там сидит важный edge-case. Через два — кода с такими «мёртвыми» флагами становится больше, чем основной логики. Поэтому каждый флаг должен заводиться с условием удаления («после полной выкатки и двух недель стабильной работы») и иметь ответственного, кто этим удалением займётся.

Отдельно стоит упомянуть организационную сторону. Закон Конвея работает и в обратную сторону: если новый и старый код владеются разными командами с разными приоритетами, миграция будет тормозиться независимо от выбранного паттерна. На время миграции имеет смысл явно проговорить, кто отвечает за переход, и не разделять старую и новую реализации между несовместимыми roadmap’ами.

Компромиссы, к которым нужно быть готовыми

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

Shadow testing увеличит нагрузку на инфраструктуру, потому что часть запросов будет обрабатываться дважды. Команде придется поддерживать дисциплину: документировать контракты, отслеживать флаги, удалять старую реализацию после миграции, поддерживать contract-тесты в актуальном состоянии.

Но это контролируемая сложность. Она распределена во времени и управляется инженерными практиками. В отличие от Big Bang-риска, где команда долго работает с минимальной обратной связью, а потом выкатывает один большой релиз с максимальной неопределенностью.

Когда Strangler Fig особенно оправдан

Постепенная миграция особенно хорошо подходит для систем, где downtime невозможен или слишком дорог. Это финтех, e-commerce, биллинг, мобильные бэкенды с большой аудиторией, высоконагруженные продукты, старые монолиты и системы с большим количеством интеграций.

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

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

Когда модернизацию лучше не делать

Постепенная миграция — мощный инструмент, но у неё тоже есть стоимость, и иногда правильный ответ — оставить систему как есть. Несколько сценариев, в которых модернизация плохо окупается.

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

Модуль, который никто не трогает. Если код десятилетней давности продолжает работать, не падает, не требует изменений и не вызывает инцидентов, его «уродливость» — не повод его переписывать. Цель модернизации — упростить будущие изменения; если будущих изменений нет, цели тоже нет.

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

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

Что получает команда

Главный результат постепенной модернизации — управляемость. Команда начинает лучше понимать систему, контролировать изменения и снижать риск инцидентов.

Появляются понятные контракты, наблюдаемость, практика безопасных релизов, культура удаления старого кода. Разработчики перестают бояться legacy, потому что у них появляется метод, а не только желание «когда-нибудь всё переписать».

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

Модернизация — это процесс, а не проект

Legacy нельзя «починить за квартал». Если система развивалась годами, она не станет простой после одного рефакторинга. Но её можно системно улучшать.

Strangler Fig Pattern, Branch by Abstraction, feature toggles, shadow testing и аккуратная миграция данных дают рабочую модель: выбрать ограниченный участок, описать контракт, реализовать новую версию, проверить её на реальном трафике, постепенно переключить пользователей и удалить старый код.

Это не самый быстрый путь. Зато он управляемый. А в зрелых продуктах управляемость важнее скорости.

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

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

Зачем вообще нужны метрики и причем тут команда разработки

Бизнес, как правило, всегда хочет одного: чтобы мы делали гораздо больше, чем физически позволяет размер команды. Желание «впихнуть невпихуемое» — это классика.

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

• Метрики помогают увидеть реальный поток задач, а не ощущение «мы же целый день заняты».
• Они позволяют говорить с бизнесом на языке скорости и рисков, а не «нам ещё немного пооптимизировать» .

Еще раз скажу: разработка — это «поток», а не магия.

Как мы искали идеальную метрику (и почему из семи оставили только одну)

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

1. Отработанные часы в Jira (с точностью до 15 минут — чтобы видеть, куда уходит время).
2. Индивидуальная Velocity (сжигание Story Points на конкретного разработчика).
3. Time to Market (считали от первой идеи бизнес-заказчика до продакшена).
4. Throughput (пропускная способность — сколько карточек мы закрываем).
5. WIP (лимиты на количество задач в работе).
6. DORA (метрики частоты деплоев и стабильности).
7. Cycle Time (время выполнения задачи от «In Progress» до «Done»).

Что произошло дальше? Классическое «KPI-караоке» методом перебора

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

Сначала мы попробовали трекать часы в Jira. Хотели кристальной прозрачности, но в итоге товарищи разработчки тратили по полчаса в день просто на то, чтобы вспомнить и аккуратно раскидать свои 8 часов по таскам. Мы быстро поняли, что это бессмысленная рутина, и отказались от нее.

Следующей гипотезой стала Индивидуальная Velocity. И тут сработала психология: люди (сами того не замечая) перестали брать сложные задачи или очень сильно дробили их. Зачем рисковать закопаться и испортить свою красивую статистику спринта? Вместо этого разработчики начали наперегонки разбирать легкие минорные баги. Увидев, что командная работа превращается в соревнование, мы свернули и этот эксперимент.

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

Пытаясь найти рабочую альтернативу, мы поочередно пробовали опираться на Throughput, WIP и DORA. Но без уже выстроенной культуры это тоже давало сбои: Throughput за счет искусственного дробления задач на микроскопические части, а попытка деплоить чаще (ради красивых метрик DORA) приводила к нестабильности тестовых стендов.

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

Мы остановились только на Cycle Time. Почему? Потому что это единственная метрика из списка, которая честно оценивает работу всей системы (процесса), а не утилизацию конкретного человека. Она показала нам, где лежат реальные проблемы в разработке, не заставляя инженеров подстраиваться под графики.

Свой путь: почему метрики нельзя просто «скопировать»

Значит ли наш опыт, что Throughput, WIP или DORA — это плохие метрики? Абсолютно нет. Главный вывод, который мы сделали на своих ошибках: не все метрики подходят друг другу, и не все можно безболезненно внедрять в любой момент.

У каждой команды должен быть свой эволюционный путь. Нашим ключом к выздоровлению стал Cycle Time — именно с него мы начали распутывать процессный клубок. Другой команде, возможно, жизненно необходимо прямо сейчас ввести жесткие лимиты WIP, чтобы перестать тонуть в незавершенке. Третьей — посмотреть на DORA, чтобы перестать ронять прод каждую пятницу.

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

Базовый минимум по цифрам, которые объясняют, «Почему мы не успеваем»

Cycle Time: сколько задача живёт «в работе» на самом деле

Что это такое

Cycle Time — это время от момента, когда команда действительно начала работать над задачей, до момента, когда результат можно считать завершённым (обычно — до состояния «в проде» или хотя бы Done, если релизы батчевые). В классическом определении это от входа в «In Progress» до попадания в «Done».

Когда начинается и когда заканчивается

Чтобы Cycle Time не превратился в хаос, в команде нужны чёткие правила:

· Старт цикла: задача переведена из To Do в первый «рабочий» статус — например, In Progress или «В разработке».

· Конец цикла: задача в статусе Done или «В продакшене» — главное, договориться, учитываете ли вы время релиза внутрь Cycle Time.

Важный момент: ожидание в бэклоге — это не Cycle Time, это lead time и вопросы приоритизации, поэтому «лежит в backlog две недели» не должно портить вам картину по скорости выполнения.

В чём измерять

· В большинстве продуктовых команд имеет смысл мерить Cycle Time в рабочих днях; для инцидентов и срочных багов — в часах.

· Для анализа удобно смотреть не только среднее, но и медиану и, например, 85‑й перцентиль: «половина задач закрывается за 2 дня, 85% — не дольше чем за 5 дней».

Как читать Cycle Time

Cycle Time — это не просто «2,7 дня», это ответ на вопрос: сколько времени задача проводит внутри системы разработки. Если вы видите рост Cycle Time, значит:

· где‑то появилось узкое место (ревью, тесты, деплой);

· или раздут WIP, и задачи просто толкутся в очереди.

Полезная практика — разбирать на ретро задачи с самым длинным Cycle Time: где они застряли, что можно убрать или автоматизировать.

К примеру, в одной из моих команд бизнес постоянно жаловался: «Разработчики делают интеграцию с новым шлюзом уже три недели, почему так долго?!». Разработчики же клялись, что код написан за пару дней. Мы включили трекинг Cycle Time с разбивкой по статусам и увидели шокирующую картину: медианное время в статусе «In Progress» (написание кода) составляло 2,5 дня.

А вот время в статусах «Code Review» и «Ожидание AppSec» (проверка безопасниками) составляло суммарно 14 дней! Задача просто лежала и ждала, пока у смежного отдела появится окно. Метрика Cycle Time спасла команду от выгорания: мы перестали давить на разработку и пошли договариваться с отделом ИБ о том, что наши фичи не такие страшные как платежи или кредиты и можно проявить немного спокойствия и лояльности(менеджерские хитрости). Скорость доставки выросла кратно.

Как внедрить Cycle Time у себя

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

2. Включите отчёт по времени в статусах в Jira/YouTrack или используйте плагины «time in status» — большинство трекеров это умеют.

3. Зафиксируйте целевой ориентир: например, «85% задач среднего размера должны укладываться в 3 рабочих дня».

4. Раз в спринт смотрите на хвост задач, выбивающихся за этот порог, и обсуждайте причины: ревью, ожидание тестов, зависимость от других команд и т.п.

Throughput: сколько готовых задач вы реально выдаете

Что это такое

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

Как измерять

· Самый простой вариант: посчитать задачи, переведённые в Done за спринт или неделю.

· Лучше разделять типы задач: фичи, баги, техдолг — иначе есть соблазн «набить Throughput» мелкими фиксками.

· После нескольких итераций можно смотреть средний Throughput и доверительные интервалы, чтобы использовать это для планирования.

Как читать Throughput

Throughput отвечает на вопрос «сколько мы реально успеваем», а не «сколько хотим успеть». Его удобно использовать так:

· для планирования спринтов: ориентироваться на прошлый Throughput вместо «оптимистичных хотелок»;

· для отслеживания тренда: если состав команды не менялся, а Throughput падает — где‑то ухудшился процесс или накопился техдолг.

Сравнивать Throughput разных команд «в лоб» почти бессмысленно: у каждой свой контекст, размер задач и доля поддержки против фич.

WIP: сколько «незавершёнки» висит в системе

Что это такое

WIP (Work in Progress) — количество задач, которые уже начаты, но ещё не завершены в текущий момент. В канбан‑терминах это всё, что находится между колонками In Progress и Done.

Как измерять

Чтобы посчитать WIP, достаточно:

· определить, какие статусы считаются «в работе» — обычно это разработка, ревью, тесты, готово к релизу;

· подсчитать количество карточек в этих колонках; можно делать это ежедневно или раз в несколько часов, если хотите строить графики.

Некоторые команды дополнительно смотрят WIP в сторипоинтах — так видно не только количество задач, но и их суммарный «вес».

Как читать WIP

Здесь вступает в игру закон Литтла: при фиксированной пропускной способности системы среднее время цикла примерно равно отношению WIP к Throughput. Это означает: чем больше вы набрали задач в работу, тем дольше в среднем каждая из них будет идти до конца.

Высокий WIP = много переключений внимания, очереди перед узкими местами и затянувшийся Cycle Time. Если WIP растёт, а Throughput и число задач в Done не растут, система перегружена.

Как внедрить управление WIP

1. Явно установите WIP‑лимиты на ключевых стадиях: например, не больше 2 задач на разработчика в In Progress и не больше 5 задач в Testing.

2. Договоритесь: если колонка достигла лимита, новые задачи туда не тянем, пока не освободится место — сначала заканчиваем начатое.

3. Отслеживайте, на каких стадиях лимиты постоянно пробиваются: это хороший индикатор узких мест.

Узкие места: где «бутылочное горлышко» съедает релизы

Узкое место — это этап, который ограничивает скорость всей системы: например, ревью или QA, если там образуется очередь.​

Типичный симптом: в одной колонке доски скапливаются карточки, а время ожидания там непропорционально большое (например, разработка 1 день, ревью 3 дня).​

Чтобы искать такие места не на глаз, используют разбор времени по статусам (это часто умеют трекеры задач) и визуализации потока вроде value stream mapping и cumulative flow diagram (CFD).​

А есть еще что-нибудь из метрик?

Можно ли брать на вооружение другие метрики, которые не указаны в статье? Но тут как говорили классики. “Можно, а зачем?”

Мы взяли стартовый набор, который команда любой зрелости может применить к себе в любой момент.

Мини‑шпаргалка (что мерить и зачем)

Как внедрять метрики и не устроить “KPI-казнь”

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

План на месяц (лёгкий, но действенный):

• Неделя 1: договориться о дефинициях (что такое “начали”, что такое “done”, включаем ли релиз).

• Неделя 2: включить сбор Cycle Time/Throughput/WIP из трекера и посмотреть, где накапливаются очереди.

• Неделя 3-4: выбрать одно узкое место и провести маленький эксперимент.

• Неделя 4: добавить DORA‑метрики из CI/CD/инцидентов и проверить баланс «скорость vs надежность».

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

• Трекеры задач (Jira, YouTrack и др.) дают доски, лимиты WIP, контроль времени в статусах и отчёты по циклу задач, если команда честно обновляет статусы.
• CI/CD‑системы (GitLab CI/CD, GitHub Actions и т.п.) автоматизируют сборку, тестирование и деплой, убирая ручные узкие места и зависимость от «того самого человека, который умеет катить релизы».
• Мониторинг и observability‑платформы помогают быстро находить проблемы в продакшене и снижать MTTR, чтобы команда меньше жила в режиме бесконечных пожаротушений.

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

Анализ требований как способ снизить стоимость ошибок

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

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

• Согласованность: насколько новое требование стыкуется с общей логикой и уже работающими модулями системы?
• Техническая реализуемость: возможно ли воплотить задуманное без «костылей» в рамках текущих ограничений платформы?
• Влияние на данные: как изменение повлияет на целостность данных, интеграции и существующие бизнес-процессы?
• Риск-менеджмент: какие скрытые угрозы и неочевидные ограничения несет в себе эта реализация?

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

Проверка проектных решений и пользовательских сценариев

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

1. Соответствие бизнес-цели. Если интерфейс перенаправляет пользователя в общий реестр вместо карточки только что созданного объекта — это дефект соответствия, даже если технически всё сработало без ошибок. Пользователь теряет контекст и вынужден искать объект вручную, что противоречит исходной постановке.
2. Консистентность и логика. В крупных продуктах формируются единые принципы навигации и UI-гайды. Если во всех разделах кнопка сохранения находится вверху, а в новой фиче она переезжает вниз, QA подсвечивает это как нарушение консистентности пользовательского опыта и внутренних продуктовых стандартов. Сюда же относится путаница в терминологии: нельзя использовать «Применить» в одном месте и «Сохранить» в другом для идентичных действий.
3. Общепринятые паттерны. Существуют универсальные правила юзабилити и доступности. Если кнопка удаления оформлена зеленым цветом, это вводит в заблуждение, так как цвет ассоциируется с подтверждением или запуском. Форма, требующая обязательного заполнения поля без соответствующей маркировки, — еще один пример нарушения базовых практик.
4. Безопасность действий. Выполнение критических операций (удаление данных, изменение прав) без подтверждения — QA должен подсветить архитектурный риск до того, как он станет дорогостоящей проблемой в продакшене.

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

Тестирование в активной фазе: что проверяет QA проверяет помимо функциональности

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

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

Ответственность за релиз

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

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

Поддержка, анализ инцидентов и влияние на архитектуру

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

В качестве примера можно привести кейс с падением таск-трекера, управлявшего массовыми операциями. Во время тестирования массовые операции работали стабильно, однако в продакшене система столкнулась с реальной конкурентной нагрузкой. Пользователи запускали параллельные операции по одним и тем же сущностям, что приводило к race conditions и переполнению очередей. Анализ логов и трассировок показал, что архитектура не предусматривала ограничения конкурентного выполнения. Для решения проблемы команде пришлось внедрить throttling и переработать механизм обработки очередей. Решение проблемы потребовало архитектурных доработок: внедрения механизмов защиты от параллельного запуска (throttling) и переработки логики обработки очередей.

Другой пример связан с интеграцией через внешнюю платформу, которая исправно функционировала в течение года. С ростом объема данных обмен начал прерываться с нечитаемыми ошибками. Анализ сетевого взаимодействия и логов интеграции показал, что размер сообщений превысил жесткий лимит внешней платформы в 5МБ. Проблема заключалась в том, что первоначальная схема обмена не учитывала рост объема данных и ограничения внешней платформы. Результатом стала разработка нового формата обмена с пакетированием данных.

Вектор на инженерию

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

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

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

Как всё начиналось

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

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

А ещё скинул официальный регламент, в котором просил обозначить: как будут храниться персональные данные гостей, какое шифрование, у кого есть доступ к базе, какой регламент при утечке и соответствует ли система требованиям ФЗ-152. Я сел разбираться.

… и перевёл с корпоративного на человеческий

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

Дальше — доступы. Кто видит базу с данными гостей? Я начал перечислять: я сам, менеджер, иногда координатор, которого я привлекаю на крупные проекты. Потом вспомнил, что на всякий случай дал временный доступ знакомому разработчику, чтобы если что помог с одной технической штукой. Полез проверять. Да, действительно, аккаунт есть, надо убирать. Не страшно на этом этапе, но кто знает, чем бы всё закончилось, если бы не проверил.

Вопрос про шифрование поначалу вообще казался мне каким-то птичьим языком. Оказалось, что речь про то, передаются ли данные по защищённому соединению. Я проверил — с соединением всё было в порядке, https стоял.

Про ФЗ-152. Он же Федеральный закон о персональных данных. Если ты собираешь у людей имена, телефоны и почту (а любая форма регистрации на то и рассчитана), ты автоматически становишься оператором персональных данных. Со всеми вытекающими: нужно уведомить Роскомнадзор, разместить на сайте политику конфиденциальности, получить у пользователей явное согласие на обработку данных.

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

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

Я привык мыслить как вайб-кодер: мне важно, чтобы форма работала, данные сохранялись и письма улетали. А им надо понимать, кто ответит, если случится утечка? Как мы управляем доступом? Что у нас за процессы?

Тут я понял, что вырос из подхода «сам всё настрою». Теперь за мной команда, репутация агентства и крупный заказчик.

Что в итоге

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

Но я вышел из этого проекта с очень чётким ощущением, что дорос до точки, где одних инструментов уже недостаточно. Дальше нужна другая голова.

Мне, как владельцу бизнеса, теперь важно:

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

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

Как раз для таких предпринимателей и существует курс «ИТ-директор». Что там внутри — подсвечивать не буду, если надо, сами разберётесь. А вот для себя уже подметил суперважные моменты про айти-инфраструктуру в контексте управления и рисков. Ещё впереди 4 созвона с техническим директором. Может, тоже что-нибудь расскажу, если что-то полезное вынесу.

По промокоду ДИРЕКТОР на данный момент доступна скидка 65% + открывают доступ ко второму курсу сверху. Если нужно уберечь себя от критичных ошибок, то лучшего варианта, чем обучиться заранее, не найти!

Реклама. Рекламодатель: ООО «Эдюсон» ИНН 7729779476, erid: 2W5zFHCCh5K

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

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

Мультиклауд уже давно стал полноценной частью нашей жизни. Согласно исследованию MWS Cloud, среди компаний, пользующихся виртуальной инфраструктурой, 31% предприятий размещают свои данные в двух и более облаках, 10% — в трёх и более. Наше партнёрство с Cloud.ru позволит нам упростить использование этой концепции для наших клиентов — помочь им гибко управлять инфраструктурой сразу у двух ведущих российских провайдеров, чтобы эффективнее балансировать нагрузки и снижать затраты. Мы убеждены, что за мультиклаудом — будущее облачного рынка, и намерены формировать его вместе с ведущими провайдерами страны, делая мультиоблачные сценарии доступнее и удобнее для российского бизнеса.

Запуск сервиса запланирован на июнь 2026 года. На первом этапе услуга станет доступна через обращение в поддержку. В дальнейшем компании планируют организовать запуск сервиса «по клику». Это сократит время создания соединений между облаками партнёров до нескольких минут.

Подписание этого соглашения — важный шаг в реализации нашей стратегии по созданию надёжной и гибкой цифровой среды для бизнеса. Объединяя наши компетенции с Cloud.ru, мы предлагаем рынку уникальную синергию ресурсов. Наше сотрудничество позволит клиентам использовать преимущества мультиоблачного подхода, обеспечивая высокий уровень катастрофоустойчивости и доступ к передовым AI-технологиям, таким как интеллектуальные ассистенты и системы управления корпоративными знаниями.

Cloud.ru — один из крупнейших облачных и ИИ-провайдеров России. Компания основана в 2019 году и за несколько лет вошла в число лидеров рынка инфраструктурных, платформенных, а также ИИ-решений.

В портфеле Cloud.ru — более 100 инфраструктурных и платформенных сервисов, публичное облако Cloud.ru Evolution на базе собственных технологий, аттестованная инфраструктура для размещения ГИС и КИИ, платформа для частных и гибридных облаков Evolution Stack, а также цифровая среда для промышленной работы с генеративным ИИ — Evolution AI Factory.

В команде компании — более 2 000 специалистов, преимущественно в области ИТ, кибербезопасности и ИИ.

Реклама. Рекламодатель: ООО «Облачные технологии», ИНН 7736279160, erid: 2W5zFHDSEaD

После оффера уже начинается работа компании

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

Отдельно готовят информационный вход. Обычно это материалы по компании, welcome-видео, чек-лист первого дня и Onboarding book. HR остаётся контактом для человека до выхода, чтобы новичок не искал ответы через случайных людей в команде.

Onboarding book — внутренняя документация для новичка. В неё обычно входят история компании, ценности, FAQ, полезные контакты, ссылки на ресурсы и порядок действий для типовых ситуаций. Для разработчика в этом документе важнее рабочая часть: где лежит техническая документация, какие каналы используют для задач, как устроены доступы и кто помогает с настройкой.

Для удалённой команды подготовка начинается ещё раньше: технику и welcome-pack отправляют до первого дня, иначе старт задержится из-за доставки, склада и ручных уточнений.

К первому дню у разработчика должен быть минимальный технический набор:

• доступ к репозиториям;
• доступ к трекеру;
• доступ к документации;
• доступ к окружениям;
• доступ к внутренним чатам;
• инструкция по локальному запуску проекта;
• контакт человека, который поможет с первичной настройкой.

Команда должна знать, кто к ней пришёл

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

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

На старте лучше узнать:

• кто ревьюит изменения и как договариваться о ревью;
• где обсуждают архитектуру и продуктовые вопросы;
• как оформляют баги и где фиксируют договорённости;
• кто владеет конкретными сервисами и модулями;
• где искать историю решений по проекту.

Если HR исчез после первого рабочего часа — это небольшой красный флаг. В нормальном онбординге HR остаётся на связи весь день и следит, чтобы руководитель и команда не забыли про нового коллегу.

Наставник

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

Первые задачи

Забудьте всё, чему вас учили на курсах. Не потому что знания бесполезны — просто в реальном проекте их почти негде применить сразу — каждый новый проект живёт по своим правилам и со своей логикой кодовой базы. Это могут быть сложные абстракции поверх абстракций — кто-то когда-то решил так сделать. Уникальные архитектурные решения — кто-то выдумывал. Костыли — потому что сроки горели.

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

Отдельно про ТЗ. В тикете почти никогда нет полного контекста. Часть вещей считается само собой разумеющейся, часть обросла локальным сленгом. Сделаете задачу — появится дополнительный контекст, который никто не упомянул, и придётся переделывать. Мотивация падает именно здесь.

Что помогает:

• Уточнять задачу до того, как начали, а не после
• Узнавать, кто писал этот код — иногда человек ещё в команде
• Не пытаться добивать задачу самостоятельно, где не понимаете систему, нужно уметь разговаривать

Атмосфера

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

Показывайте, что понимаете нагрузку и какие решения можете предложить — этого достаточно, чтобы быстрее стать своим.

Три месяца

У нормального онбординга есть план на три месяца — что делать сейчас, что через месяц, к какому результату прийти в итоге. Это убирает главную тревогу на новом месте — ощущение, что непонятно вообще всё и непонятно когда станет понятно.

Как выглядит нормальный ритм:

• Еженедельные one-to-one с руководителем — задачи, сложности, обратная связь
• Встреча с HR через две недели — как адаптируетесь, всё ли понятно, нужна ли дополнительная поддержка
• Итоговая встреча через три месяца — что получилось, что нет, что дальше

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

Компании, где онбординг выстроен правильно, фиксируют снижение увольнений в первые полгода на 7%. Цифра небольшая, но она про системный эффект: когда человек понимает правила игры с первого дня, он реже уходит из-за того, что просто не разобрался.

На что смотреть

Три признака, что онбординг нормальный:

• Техника пришла до первого дня, доступы открыты, HR на связи.
• Есть наставник и план на три месяца.
• Вас представили команде — не попросили познакомиться самому.

Три красных флага:

1. Нет наставника вообще.
2. Нет плана задач даже на первый месяц.
3. HR исчез после первого дня и больше не появлялся.

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

Теперь переходим к 90-м и нулевым. Это период, когда российское IT начало собираться в индустрию: компьютеры появлялись в офисах, программистов доучивали на работе, вирусы распространялись по дискетам, отчётность переносили с бумаги на магнитные носители, а банки только учились показывать клиенту баланс через интернет.

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

Больше про историю российской IT-индустрии слушайте в аудио-шоу «От нуля до единицы» от экосистемы для бизнеса Контур и студии «Послушайте».

Сначала компьютер нужно было где-то достать

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

Один был вариантом «Радио-86РК» от ленинградского объединения ЛОМО, с плёночной клавиатурой. Другой, более известный, — клон британского ZX Spectrum 48K от московского НПО «Аксон», с полноценными клавишами и 48 килобайтами памяти — примерно столько занимает одна современная иконка приложения.

Чуть позже появились «Поиск» с процессором 8088 и дисководом 5,25 дюйма, а также «Искра» образца 1989 года. Это уже были IBM-совместимые машины с MS-DOS и Norton Commander.

Если сравнивать с сегодняшним ноутбуком, такой компьютер выглядит коробкой с клавиатурой: процессор — слабее любого смартфона, дисковод — вместо флешки или облака, MS-DOS — вместо привычной операционной системы с окнами, Norton Commander — вместо проводника файлов. Но для конца 80-х и начала 90-х на нём можно было запускать программы, хранить данные, работать с файлами и учиться тому, что позже станет вечным требованием в вакансиях — «уверенный пользователь ПК».

Даже эти первые машины уже показывали, что компьютеры нужны обычным людям, но в 1991 году средний компьютер стоил около 1000 долларов. Помимо денег нужно было выбрать конфигурацию, понять, у кого брать, и надеяться, что всё заработает. К 2000 году цена компьютера упала до 500–700 долларов. И тут появилась следующая проблема: купить компьютер вроде бы стало проще, но что с ним делать — непонятно.

Компьютеры появились быстрее, чем специалисты

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

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

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

Так сформировалась одна из фишек российского IT 90-х: компании не ждали готовых кадров. Они покупали компьютеры, автоматизировали учёт, подключали сети и параллельно доучивали людей на профильных задачах.

Как люди входили в IT в 90-е, рассказывают в подкасте «От нуля до единицы». Там же — про утечку мозгов, первых специалистов и путь к покупке компьютера: от поиска денег до поездок по полуподвальным конторам.

Те, кто научился программировать первыми — пошли делать софт для бизнеса

Бизнес всегда реагировал быстрее государства и образования, поэтому именно он стал первым большим заказчиком для зарождающегося IT. Как только в компаниях стало слишком много ручных операций — зарплат, учёта, отчётов, деклараций, — появился спрос на программы и софт. Тогда на рынке был только один кандидат.

Контур с программой «Учёт труда и заработной платы — АМБа», которую выпустили ещё в 1986 году, за два года до создания самого Контура, оказался очень вовремя. Программой пользовались государственные учреждения и заводы. В конце 90-х Контур помог перевести налоговую отчётность на магнитные носители — компании стали сдавать декларации на дискетах вместо бумаги. А в 2000 году появился «Контур.Экстерн»: предприятия впервые смогли отчитываться в налоговую через интернет, без личного присутствия в инспекции.

Когда данных от бизнеса стало больше, компьютеры пришлось связать в сеть

Машины уже умели хранить данные, запускать программы и помогать с учётом. Но без сети всё это работало только локально. Что случилось дальше? Правильно — начал появляться поиск, аналог того, которым мы сегодня пользуемся каждый день.

7 апреля 1994 зарегистрировали домен .RU. В тот же день появился первый сайт российской доменной зоны — www.1-9-9-4.ru: список из нескольких десятков адресов с короткими описаниями, что вообще можно узнать в новом русском интернете.

Именно из логики, когда нужно искать среди нарастающего потока страниц, выросли первые поисковики, но перед этим было одно важное событие.

В 1991 году в подмосковном Пущино пятеро инженеров-радиотехников из местных НИИ основали компанию «Стек». Они проложили IP-канал из Пущино к сети Курчатовского института — это был первый интернет-канал в России, выходящий за пределы Москвы. Потом подняли собственные ftp-, mail- и www-серверы. В 1996 разработчик компании Дмитрий Крюков написал ядро поисковика и назвал его Rambler. На момент запуска — 8 октября 1996 — система проиндексировала около 100 тысяч документов, хотя сайтов в Рунете тогда насчитывалось не больше 30–50.

23 сентября 1997 анонсировали Яндекс. Его сильной стороной стала работа с русским языком и морфологией — система понимала, что «купить», «купил» и «куплю» — одно и то же слово. В 1998 году на Yandex.ru появился контекстный баннер, который менялся в зависимости от запроса пользователя. Позже контекстная реклама стала основной бизнес-моделью компании.

С этого момента сеть перестала быть просто набором серверов и документов. Данных становилось больше, их нужно было искать, передавать и копировать. Но в 90-х обмен файлами ещё часто шёл не через интернет, а через дискеты: программы, документы и базы носили между компьютерами вручную.

Дискеты переносили не только программы, но и вирусы

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

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

Одним из первых проектов против вирусов был Tadpole. Затем появился антивирусный сканер Tornado. Позже эти разработки объединились в Spider’s Web. В 1993 году появился Dr.Web, а в 1994 году вышла первая коммерческая версия.

Параллельно развивалось другое направление. Евгений Касперский после работы в НИИ Министерства обороны ушёл в коммерческий IT, занимался антивирусной разработкой в КАМИ, а затем вместе с командой создал собственную фирму. В 1996–1997 годах команда договорилась с иностранными вендорами, поэтому теперь зарубежные компании использовали российский готовый движок в своих продуктах.

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

Дефолт ударил по рынку, но открыл дорогу аутсорсу

Экономика быстро напомнила, что рынок не существует отдельно от страны — в 1998 году случился дефолт. Рубль резко обесценился: 1 августа доллар стоил около 6,24 рубля, а к концу 1999 года уже около 27 рублей.

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

Иностранные компании начали отдавать задачи российским командам: качество уже было, а стоимость после обвала рубля стала выгодной — так кризис подтолкнул аутсорс. Но внешний спрос быстро упёрся в старую проблему российского IT: специалистов не хватало. Университеты не успевали выпускать людей под задачи, которые уже появились у компаний. Поэтому бизнес начал сам заходить в образование.

Компании начали выращивать специалистов

Acronis начинал с факультативов в МФТИ. В 2004 году Microsoft запустила в России программу IT Academy. В 2008 году Контур запустил образовательные программы в уральских вузах: стажировки, школу промышленного программирования, гранты и стипендии.

Российский рынок пытался закрывать кадровый разрыв своими силами. Университеты давали базу, а компании добавляли практику: реальные задачи, стажировки и обучение под свои технологии.

Про то, как российское IT переживало дефолт, кадровый голод и переход к аутсорсу, подробнее говорят в подкасте «От нуля до единицы». Новые эпизоды выходят каждую среду.

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

Банки шли к онлайну через бумагу, модемы и первые карты

В 90-х в типичном банке мог стоять один компьютер, но его использовали в основном как печатную машинку. Баланс сводили в бумажной книге и передавали в Центральный банк для контроля, а платежи оставались наличными.

Первые коммерческие банки появились ещё в 1988, к концу 1991 года их было около 1400, а в 1992-м — уже больше 2000. Чем больше становилось операций, тем труднее было сводить всё вручную.

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

В середине 90-х в Россию пришли Visa и MasterCard. Параллельно появились отечественные платёжные системы: Union Card и «Золотая Корона». Первые карты были магнитными, без чипов — и почти бесполезными в повседневной жизни: магазины, кафе и заправки карты не принимали. Терминал для безналичной оплаты был редкостью даже в Москве. Поэтому владелец карты чаще всего шёл к банкомату, снимал наличные и дальше платил как обычно — бумажными деньгами.

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

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

Только к 2010 году IT стало реальной индустрией

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

К 2010 году доля IT-сектора в российском ВВП достигла 1%. Это уровень, сопоставимый с индустрией развлечений или гостиничным бизнесом. Путь от редкого компьютера, дискеты, модема и сисадмина на все руки занял около 20 лет.

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

Эксперты Centicore Group собрали чек-лист из 12 пунктов, которые реально работают при выборе интегратора, а когда у вас станет вопрос подрядчика – вы можете воспользоваться этим списком.

1. Опыт в вашей индустрии

Системный интегратор, который делал проекты для e-commerce, не обязательно справится с финтехом. У каждой индустрии свои особенности: требования к безопасности, специфика бизнес-процессов, регуляторные ограничения.

Что проверять:

1. Портфолио с проектами в вашей сфере. Нужны конкретные кейсы: что делали, какой стек, какие результаты.
2. Понимание специфики. Если интегратор сразу задаёт правильные вопросы про ваши бизнес-процессы — хороший знак. Если предлагает типовое решение без погружения в специфику — советуем искать дальше.
3. Измеримые результаты. Везде понятные показатели: на сколько сократили время обработки заявок, сколько проект занял по времени, какая команда специалистов и к чему в итоге пришли.

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

2. Что по техстеку и обновлениям

В 2026 году оценивать интегратора по знанию условного языка программирования бессмысленно. Смотреть нужно на то, как команда работает с энтерпрайз-стеком и требованиями безопасности.

На что смотреть:

1. Соответствие вашему контуру. Если у вас закрытый on-premise, а подрядчик умеет деплоить только в публичные облака — вам не по пути.

2. Релевантные сертификаты и лицензии. Если делаете финтех — нужен опыт прохождения PCI DSS. Если работаете с госсектором или персональными данными — ищите подрядчика с лицензиями ФСТЭК и ФСБ.

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

4. Геополитические и санкционные риски. В 2026 году для российского рынка это один из ключевых рисков. Что здесь нужно проверять:

• Зависимость от иностранных облаков и компонентов.
• Отдельно open-source библиотек и фреймворков с высокой санкционной уязвимостью.
• Наличие у подрядчика плана «Б» на случай новых ограничений (альтернативные поставщики, российские облака, on-premise).
• Опыт работы с проектами, которые уже проходили через санкционные ограничения.

Красный флаг: Подрядчик говорит «у нас всё на AWS и мы не видим в этом проблемы» или не может ответить, как будет развивать систему при усилении ограничений.

5. Отношение к ИИ-инструментам и low-code решениям. В 2026 году почти все интеграторы так или иначе используют ИИ (Cursor, GitHub Copilot, Claude, внутренние агенты). Важно понимать политику компании. Что проверять:

• Есть ли у подрядчика регламент использования ИИ-инструментов (что разрешено, что запрещено, как проверяется код, сгенерированный ИИ).
• Насколько активно они применяют low-code/no-code платформы и как это влияет на качество и поддержку решения.
• Готовы ли они комбинировать ИИ + ручную разработку или полностью полагаются на «ИИ всё сделает».
• Есть ли у них экспертиза по prompt engineering и проверке качества ИИ-генерируемого кода.

Красный флаг: Подрядчик либо полностью игнорирует ИИ («мы всё пишем руками»), либо говорит «мы всё делаем через ИИ и это в 10 раз быстрее» без упоминания проверок и рисков.

3. Насколько гибкие в разработке

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

Что важно:

1. Подход к кастомизации показывает философию компании. Если подрядчик сразу говорит о готовом решении и предлагает подстроить бизнес-процессы под него — это провал для специфичных задач. Подбор решения под клиента, а не наоборот — признак зрелого подхода.
2. Работа с изменениями — реальность любого проекта. Требования меняются в процессе, это нормально. Agile не на словах, а на деле означает готовность пересмотреть приоритеты, адаптировать бэклог, обсуждать изменения.
3. Понимание бизнес-задачи отличает хорошего интегратора от посредственного. Технари часто зацикливаются на том, как реализовать, забывая спросить, зачем это нужно. Вопрос о том, какую проблему решает функция, должен звучать чаще, чем обсуждение технологии.

Спросите, как подрядчик работает с меняющимися требованиями в середине спринта. Если ответ сводится к пунктам контракта и доп.оплате — это может быть, но для начала лучше обсудить приоритеты и найти компромисс.

4. Прозрачность процессов

Вы должны понимать, что происходит на проекте в любой момент.

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

1. Структура коммуникации определяет скорость решения вопросов. Кто ваш контакт — менеджер без технической экспертизы или техлид команды? Как быстро получаете ответы? Есть ли прямой доступ к разработчикам для обсуждения технических деталей?
2. Регулярная отчётность — это не бюрократия, а инструмент контроля. Демо каждый спринт, доступ к таск-трекеру вроде Jira, понимание прогресса в реальном времени. Компании с 24/7 поддержкой обычно имеют настроенные процессы коммуникации и реагирования.
3. Документация показывает зрелость процессов. Если подрядчик не может показать примеры технической документации, процессов разработки, архитектурных решений — это тревожный звонок.
4. Совпадение ценностей и корпоративной культуры. Технические навыки важны, но если ценности не совпадают — проект будет постоянным источником конфликтов. Попросите пообщаться не только с техлидом, но и с 1–2 разработчиками, которые будут работать над проектом. Задайте вопросы про их реальный опыт работы в компании. Что проверять:

• Отношение к удалённой работе и овертаймам (есть ли культура «гореть на проекте» или уважают work-life balance).
• Прозрачность внутри компании (как принимаются решения, насколько открыто руководство общается с командой).
• Отношение к качеству vs скорость (готовы ли отказываться от «быстрых костылей» ради долгосрочного результата).
• Корпоративные ценности: как компания относится к клиентам, к сотрудникам, к этике в разработке.

Красные флаги:

1. Вам говорят, что всё хорошо, но конкретики нет. Нет демо, доступа к репозиторию, промежуточных результатов. А потом в день дедлайна выясняется, что половины функционала нет. Нормальная практика — давать клиенту видимость работы: задачи, коммиты, тесты.
2. Проводите демо результатов каждые 1-2 недели. Так будете видеть рабочий код, сможете проверить функционал, задать вопросы напрямую техлиду. Ошибки дешевле исправлять на ранних этапах, чем в продакшене.
3. Команда говорит одно на собеседовании, а на деле — жёсткий overtime, токсичная культура и «мы просто кодим, а менеджеры решают».

5. Команда и культура разработки

Код пишут люди, а люди работают эффективно только в правильной среде. Культура разработки подрядчика напрямую влияет на качество вашего продукта.

Что проверять:

1. Квалификация разработчиков определяет скорость и качество работы. Соотношение мидлов и сеньоров в команде показывает, кто будет делать архитектурные решения, а кто — рутинные задачи. Если в команде только джуны под управлением одного сеньора — это риск.
2. Текучка кадров — критический показатель стабильности. Высокая текучка означает проблемы: либо с зарплатами, либо с управлением, либо с атмосферой. Всё это отразится на вашем проекте.
3. Практики разработки видны в деталях. Code review, автоматизированное тестирование, CI/CD — это страховка от багов в продакшене. Спросите, как организован процесс: делают ли ревью кода, какое покрытие тестами, как часто деплоят.

Попросите пообщаться с командой, которая будет работать над проектом. Нормальные компании не скрывают разработчиков за менеджерами. Обратите внимание на культуру внутри компании. Человекоцентричный подход, забота о сотрудниках, корпоративная культура поддержки — всё это влияет на мотивацию команды.

6. Пост-интеграционная поддержка

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

На что смотреть:

1. Гарантии и доработки. Что будет, когда система упадет из-за архитектурной ошибки вендора? Условия фикса багов и доработок после релиза должны быть зафиксированы в контракте.
2. Контроль ответственности. Должно быть четко расписано, где заканчивается зона ответственности интегратора и начинается зона ваших админов, девопсов или первой линии поддержки.
3. Документация и передача знаний. Подрядчик обязан выгрузить не только исходники, но и актуальную документацию: ADR (архитектурные решения), схемы инфраструктуры, регламенты развертывания.

Юридическая и договорная часть. Условия расторжения договора и стратегия. Кто владеет кодом и данными после завершения проекта. Штрафы за срыв сроков и SLA. Право на аудит кода и инфраструктуры.

7. Безопасность и комплаенс

1. Проверяйте сертификаты и стандарты: ISO 27001 по информационной безопасности, соответствие ФЗ-152 о персональных данных, отраслевые стандарты вроде PCI DSS для платёжных систем.
2. Пентесты, аудит кода на уязвимости, шифрование данных, управление доступами — всё это должно быть в процессе по умолчанию.
3. Убедитесь, что контракт чётко прописывает, кому принадлежит код, как защищаются ваши данные, какие санкции за утечку.

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

8. Реальные кейсы и рекомендации

Самый очевидный и простой способ проверить подрядчика — поискать в открытом доступе упоминания и кейсы в медиа или на специальных площадках. Вот на что смотреть:

1. Соблюдение сроков — классический больной вопрос IT-проектов. Уложились ли в первоначальные оценки? Если были задержки — как объясняли и решали?
2. Работа с изменениями — насколько гибко подрядчик реагировал на новые требования? Были ли конфликты по поводу доп.функционала?
3. Качество коммуникации — как быстро отвечали, насколько понятно объясняли технические вещи, был ли прямой контакт с командой?
4. Пост-поддержка — что происходило после запуска? Быстро ли реагировали на проблемы? Помогли ли с развитием продукта дальше?

9. Финансовая прозрачность

Цена проекта состоит не только из цифры в коммерческом предложении. Важно понимать, что входит в стоимость и какие могут быть скрытые расходы.

На что смотреть:

1. Детализация оценки показывает зрелость процессов. Хорошее КП разбито на этапы, модули, компоненты. Вы видите, сколько стоит разработка каждой части, инфраструктура, тестирование, документация.
2. Скрытые расходы появляются, когда подрядчик не включил в оценку важные вещи: тестирование, документацию, обучение команды, настройку мониторинга. Уточняйте, что именно входит в стоимость, а что может потребовать доп.оплаты.

Красные флаги:

• Слишком низкая цена по рынку — либо подрядчик неправильно оценил сложность и потом будет просить доплату, либо сэкономит на качестве: джуны вместо мидлов, отсутствие тестирования, урезанная документация.
• Отказ детализировать оценку под предлогом коммерческой тайны. Нормальная практика — объяснить клиенту, из чего складывается стоимость. Если подрядчик этого не делает — он либо сам не понимает, либо что-то скрывает.

10. Масштабируемость решения

Интегратор не сдает вам в аренду серверы, поэтому он должен спроектировать систему так, чтобы при х10 росте нагрузки вам не пришлось переписывать ядро, менять СУБД или сносить весь проект.

1. Проектирование под рост бизнеса отличает стратегическое мышление от тактического. Хороший интегратор спросит о ваших планах: сколько пользователей сейчас, сколько планируется через год, через три года. И заложит архитектуру с запасом.
2. Постепенное расширение функционала дешевле полной переделки. Модульная архитектура, микросервисы, API-first подход — всё это позволяет добавлять новые возможности без переписывания существующего кода.
3. Управление техническим долгом. Любая разработка накапливает технический долг: быстрые решения, костыли, устаревшие зависимости. Профессионалы планируют рефакторинг, выделяют время на улучшение кода, следят за обновлениями библиотек.
4. Vendor lock-in и технологическая независимость. Хороший интегратор не строит систему так, чтобы вы навсегда зависели от его экспертизы, конкретного облака или проприетарного инструмента. Проверяйте: на каких лицензиях работает стек, можно ли сменить подрядчика без переписывания системы, кто владеет кодом и есть ли возможность развивать продукт силами инхаус-команды.

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

11. Скорость и качество коммуникации

Здесь должно быть все понятно, но на всякий случай зафиксируем:

1. Время отклика на первый запрос — если на ваше обращение отвечают через неделю — представьте, как будет идти коммуникация в процессе проекта.
2. Интегратор должен задавать вопросы не только про технические требования, но и про то, какую проблему бизнеса решает система. Это показывает стратегическое мышление.
3. Хороший подрядчик не просто делает, что сказали, а предлагает улучшения: как сделать эффективнее, дешевле, быстрее. Это требует глубокого понимания вашего бизнеса.

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

12. Репутация на рынке и стабильность

Последний пункт проверки — надёжность подрядчика как бизнеса. Вы инвестируете в долгосрочные отношения, и компания должна быть стабильной.

Что оценивать:

1. Время на рынке — один из положительных сигналов, но не гарантия. Компании с опытом 8+ лет, как правило, пережили кризисы, накопили экспертизу и выстроили процессы. Но возраст сам по себе не означает качество: проверяйте кейсы, репутацию и стабильность команды, а не только дату основания. Стартапы могут быть инновационными — просто риски у них другие.
2. Финансовая устойчивость проверяется косвенно: по масштабу проектов, количеству офисов, размеру команды.
3. Участие в профессиональных мероприятиях показывает открытость. Компании, которые выступают на конференциях, пишут статьи, делятся опытом, обычно уверены в своей экспертизе. Это также помогает проверить репутацию через знакомых в индустрии.
4. Партнёрские отношения с крупными вендорами — ещё один индикатор.

Проверка на негатив:

• Поищите упоминания компании в негативном контексте: судебные споры, публичные конфликты с клиентами, жалобы сотрудников. Одна претензия — не приговор, но если их много — стоит задуматься.
• Отсутствие следов в интернете тоже настораживает. Нормальная IT-компания в 2026 году должна быть видна: сайт, соцсети, публикации, упоминания в медиа.

Как использовать чек-лист

1. Первичный скрининг отсекает неподходящих кандидатов. Пройдитесь по критичным пунктам: опыт в индустрии, технологический стек, безопасность, репутация. Если есть красные флаги — не тратьте время на глубокую оценку.
2. Глубокое интервью для финалистов. Возьмите 2-3 компании, которые прошли скрининг, и проверьте остальные пункты детально. Встречи с командой, разбор кейсов, общение с референсами, обсуждение процессов.
3. Пилотный проект снижает риски. Перед большим контрактом протестируйте подрядчика на небольшой задаче. Это покажет реальное качество работы, скорость коммуникации, соблюдение договорённостей. Дешевле потратить месяц на пилот, чем год на исправление ошибок.

Чек-лист работает, когда применяете его последовательно. Не пропускайте пункты, которые кажутся очевидными — именно там часто скрываются проблемы. И помните: идеального подрядчика не существует. Важно найти того, чьи сильные стороны совпадают с вашими приоритетами, а слабые — не критичны для проекта.

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

Если верить статистике, сейчас ежедневно создается около 402,74 миллионов терабайт данных.

Согласитесь, довольно внушительная цифра.

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

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

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

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

Вот почему мы подыскали аналог Nextcloud – ownCloud. В отличие от более функционального Nextcloud, ownCloud заточен исключительно на работу с файлами. И при этом он поддерживает подключение облачного объектного хранилища S3. Поэтому для нас в сравнении Nextcloud vs ownCloud выбор был очевиден.

В этой статье я расскажу, какие возможности есть у ownCloud, почему это ПО может быть полезно и как настроить связку ownCloud и S3. Если вы хотите организовать безопасное, контролируемое хранение и обмен данными на работе или дома, то этот материал будет для вас полезен.

Что может ownCloud

Для начала – буквально несколько слов об ownCloud и его возможностях.

Это программное обеспечение с открытым исходным кодом для хранения, синхронизации и обмена файлами появилось в 2010 году благодаря усилиям разработчика KDE Франка Карличека, который стремился создать бесплатную альтернативу коммерческим облачным сервисам хранения данных.

OwnCloud позволяет:

1. получать доступ к данным из любой точки мира и хранить файлы на собственном сервере – под вашим полным контролем;
2. синхронизировать данные между устройствами – доступ к файлам возможен с компьютеров (Windows, macOS, Linux), смартфонов (iOS, Android) и через браузер, изменения на одном устройстве мгновенно появляются на всех остальных;
3. делиться файлами и папками по ссылке, настраивая права доступа, пароли и срок действия ссылок;
4. совместно работать с документами, отслеживать историю изменений и возвращаться к любой предыдущей версии файла.

Только ownCloud сочетает в себе полный контроль над данными с простыми в использовании функциями обмена файлами, делая совместную работу более эффективной и безопасной.

Сегодня ownCloud используют компании (Philips, Nationwide, Zeppelin и др.) в самых разных сферах (IT, машиностроение, медицина и т. д.).

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

С ownCloud мне не нужно слепо доверять какой-то неопределенной организации. Я контролирую, как происходит обмен файлами, и ownCloud помогает мне на каждом этапе.

OwnCloud позволяет решать самые разные задачи, связанные с работой с файлами, – расскажем на примере трех кейсов, как это облачное хранилище помогает нам в отделе маркетинга.

Для каких задач мы используем ownCloud и S3

1. Централизованное управление материалами

Мы часто работаем с текстами, изображениями и презентациями. Дизайнеры и авторы загружают эти материалы в ownCloud, файлы автоматически сохраняются в S3, а для удобства поиска у нас настроены теги.

В итоге каждый член команды может видеть версии файлов (это важно для правок), нет хаоса в почте и мессенджерах.

2. Безопасное взаимодействие с подрядчиками

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

На практике это работает так: менеджер создает ссылку и отправляет подрядчику, подрядчик переходит по ссылке и загружает архив с готовыми материалами, файл попадает в ownCloud, а его содержимое сохраняется в S3. Таким образом, подрядчик не видит, какие еще файлы лежат в папке, а мы контролируем, кто, что и когда загрузил.

3. Долгосрочный архив креативов и отчетов

По закону (152-ФЗ в РФ или GDPR в Европе) компания обязана хранить персональные данные клиентов, а также отчеты о рассылках и рекламных акциях на протяжении определенного времени.

Для решения этой задачи мы настроили правило: файлы старше 90 дней автоматически перемещаются в S3 Glacier (холодное хранилище) – этот класс снижает стоимость хранения, а если, например, юристу понадобится скачать какой-нибудь отчет спустя 2–3 года, он просто выгрузит его из ownCloud буквально за 5–10 минут.

Теперь – в деталях и по шагам о том, как начать использовать ownCloud в связке с S3.

Как развернуть ownCloud и подключить S3

OwnCloud удобно использовать с объектным хранилищем S3 – таким образом можно:

1. масштабировать систему – S3 расширяется автоматически и не имеет ограничений по объему и количеству размещаемых данных и файлов;
2. оптимизировать затраты – можно платить не за дорогую конфигурацию виртуального сервера с большим объемом диска, а лишь за фактически занимаемое место, по модели pay as you go (оплата по мере потребления);
3. повысить надежность хранения – за счет встроенной в S3 тройной репликации данных (файлы хранятся в 3 копиях и размещаются на независимых серверах в разных стойках для абсолютной сохранности данных).

Итак, разберем, как настроить связку ownCloud и S3.

Разработчики ownCloud предлагают два варианта установки. Можно скачать ownCloud и установить его вручную или использовать Docker-контейнеры. Мы выберем второй вариант.

Для размещения ownCloud в нашем примере создадим виртуальный сервер на базе готового решения Docker.

Можно подключиться к серверу по SSH или с помощью терминала в панели управления.

Для размещения файлов создайте бакет объектного хранилища S3. Реквизиты доступа к нему будут в карточке бакета в панели:

Создайте директорию для размещения конфигурационных файлов проекта и перейдите в нее:

Затем вставьте в файл docker-compose.yml следующее содержимое с помощью любого текстового редактора:

После этого создайте файл .env, в котором будут храниться значения переменных. Шаблон файла следующий:

Теперь необходимо отредактировать эти строки:

1. ownCloud_DOMAIN и ownCloud_TRUSTED_DOMAINS – укажите домен (так как ownCloud будет размещен за обратным прокси, указывать рабочий порт здесь не требуется);
2. ADMIN_USERNAME – логин администратора;
3. ADMIN_PASSWORD – пароль администратора.

Обратите внимание! Изменение ADMIN_USERNAME и ADMIN_PASSWORD уже после развертывания контейнеров не возымеет эффекта. Изменить пароль администратора вы можете в настройках пользователя в веб-интерфейсе.

Далее необходимо указать параметры подключения к S3.

• ownCloud_OBJECTSTORE_BUCKET – имя бакета S3;
• ownCloud_OBJECTSTORE_ENDPOINT – эндпоинт хранилища (например, https://s3.ru1.storage.beget.cloud);
• ownCloud_OBJECTSTORE_REGION – регион (ru1 для Beget);
• ownCloud_OBJECTSTORE_KEY – Access key бакета;
• ownCloud_OBJECTSTORE_SECRET – Secret key бакета.

Сохраните файл.

Остается лишь добавить файл конфигурации для Caddy – обратного прокси, через который пользователи будут получать доступ к ownCloud.

Создайте директорию config:

После чего создайте в ней файл конфигурации Caddyfile. Добавьте в него следующее содержимое, указав вместо ownCloud.betutorial.ru ваш домен ownCloud:

Обратите внимание! Caddy выпустит SSL-сертификат на домен автоматически.

Все запросы к домену будут проксироваться в контейнер ownCloud_server.

На этом настройка конфигурационных файлов завершена, можно запускать контейнеры:

Потребуется несколько минут, чтобы docker загрузил образ и развернул контейнеры.

После запуска перейдите по домену, чтобы проверить работу хранилища:

Выполните вход со стандартными доступами.

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

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

Теперь проверим работу объектного хранилища – перейдем на главную страницу и загрузим файлы:

Файлы также появились и в объектном хранилище:

Обратите внимание! Файлы, которые вы удалите в ownCloud, будут перемещены в корзину и останутся в S3. Для их полного удаления очистите корзину ownCloud.

Чтобы делиться паролями с новыми пользователями, необходимо настроить отправку почты в ownCloud, сделать это можно в разделе Settings>General.

В нашем примере мы настроим отправку через SMTP:

После указания данных введите тестовый email и нажмите “Send email”. Если отправка успешна, вы получите уведомление об этом:

А на почтовый ящик поступит письмо:

На этом настройка завершена – можно начинать работать с файлами, используя связку ownCloud и S3.

Заключение

Если вы ловите себя на мысли, что данных стало настолько много, что поиск нужного файла порой происходит дольше, чем работа с ним (особенно если одни файлы хранятся на почте или в мессенджере, а другие – на ноутбуке или флешке), облачное хранилище может вам помочь.

Подобное ПО пригодится как для личных целей, так и для бизнеса – недаром в 2025 году в нашей стране был зафиксирован рост интереса крупного и среднего бизнеса к технологии облачного хранилища.

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

Один такой кейс я помню особенно болезненно. Заказчик специально ушёл от «тяжёлых» платформ ради самописного решения: быстрее сроки, ниже чек на входе. Полгода спустя каталог перевалил за 10 000 позиций. Страницы открывались по 8–12 секунд, поиск фактически умер, обмен с учёткой превратился в ручной ад. В итоге пришлось пересобирать магазин на другой системе — и суммарно это стоило примерно в три раза больше, чем если бы выбрать нормальный фундамент сразу.

Вывод простой и непопулярный: для интернет-магазина CMS — это не «движок сайта», а контур бизнеса. Если он не тянет каталог, склады, оплаты и промо — экономия на старте превращается в налог на переделку.

Почему «красивая витрина» не спасает

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

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

Где Битрикс реально оправдан

На корпоративных и сетевых историях Битрикс заходит потому, что это не «лендинг с корзиной», а связка магазина с процессами: каталог, заказы, складские и клиентские сценарии из коробки, обмен с 1С как отдельная экосистема.

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

Цена лицензии и сервера — да, это не «бесплатный WordPress». Зато это честная модель: вы платите за то, что масштаб и интеграции уже заложены в архитектуру, а не пробиты латками.

Kогда разумнее WooCommerce и облако

Если у вас не миллион SKU и не десять складов, а тысяча позиций и простая воронка — связка WordPress + WooCommerce часто выигрывает по скорости запуска и по цене входа. Экосистема плагинов закрывает типовые задачи без заказной разработки на каждый чих.

Облачные SaaS вроде Shopify годятся, когда компании нужен быстрый старт без администрирования сервера и команды DevOps. Комиссии и ограничения платформы нужно закладывать в юнит-экономику заранее — но для проверки гипотезы это иногда лучший компромисс.

OpenCart и аналоги я чаще видел у проектов, где важна предсказуемость и «руки разработчика на аутсорсе»: проще найти исполнителя, меньше сюрпризов, чем на экзотике. Magento и тяжёлый enterprise-класс имеют смысл, когда команда уже сильная технически и каталог — это отдельный продукт, а не «сайт с корзиной».

Самопис — не зло, но это отдельная ставка

Своя CMS имеет смысл, когда продукт по сути уникален и типовые решения мешают. Во всех остальных случаях вы покупаете не «уникальность», а дорогую поддержку собственного монстра: каждый апдейт PHP, каждый новый способ оплаты — ваш головняк.

Если уже понятно, что платформа не та

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

На этом этапе экономить опаснее всего: «перенесём как получится» почти всегда означает битые URL, дубли в выдаче и потерянные заказы в переходный месяц. Если уж делаете миграцию — делайте её один раз и основательно.

Что мы делаем перед выбором

• Считаем не «стоимость запуска», а стоимость трёх лет жизни: лицензии, хостинг, доработки, интеграции.
• Фиксируем сценарии: каталог, промо, B2B/B2C, обмен с учёткой, маркетплейсы.
• Закладываем буфер на рост — если через год SKU вырастет в пять раз, платформа должна выдержать без полной переделки.
• Перед подписанием уточняем у подрядчика три неудобных вещи: сколько стоит час поддержки после запуска, как закрываются интеграции «не из коробки», и что будет, если через полгода понадобится второй склад или новый тип оплаты.

Ответы без конкретики («сделаем как надо») для меня красный флаг. Нормальный исполнитель называет риски и диапазоны хотя бы порядка величины.

Если очень коротко: не экономьте на фундаменте там, где сайт — канал продаж. Экономия почти всегда вернётся чеком на миграцию.

Подробнее разобрал платформы и критерии в материале на сайте: как выбрать CMS для интернет-магазина — сравнение подходов.

1. Советские математики заложили базу для российских бигтехов

Чтобы понять, откуда в России вообще взялись программисты, вернемся в конец 1940-х годов. После Великой Отечественной войны началась технологическая гонка вооружений. У США уже была ядерная бомба, поэтому Советскому Союзу нужно было срочно создать свою. Для разработки похожего оружия применяли сложные математические расчеты, которые люди с механическими арифмометрами выполняли бы годами, поэтому Советский Союз взял курс на создание своих вычислительных машин.

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

Развитие советской техники возглавил ученый Сергей Лебедев. Сначала он построил первую отечественную ЭВМ — МЭСМ (малую электронную счетную машину), а после начал разработку серии БЭСМ (больших электронных счетных машин).

Больше о том, как создавались первые советские ЭВМ, узнайте в подкасте Контура и студии «Послушайте!» «От нуля до единицы. История российского IT». Там про это рассказывает антрополог и автор книги «Антропология русского интернета» Наталья Конрадова — с деталями, которых нет ни в этой, ни в других популярных статьях.

Вершиной разработки в Советском Союзе стала БЭСМ-6, она серийно производилась с 1968 по 1987 год и стала основным инструментом для ученых и инженеров. На этой машине считали траектории ракет и моделировали ядерные реакции. Именно на ней учили программированию студентов лучших технических вузов страны.

Работа с первыми ЭВМ сформировала советскую инженерную культуру. Специалисты привыкли писать алгоритмы в условиях ограничений вычислительных ресурсов.

2. Программирование стало языком — и это открыло рынок для коммерческих продуктов

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

Прорыв случился в середине 1950-х годов в США — именно тогда появился первый язык Fortran: один и тот же код можно было запустить на разных машинах без полного переписывания. Это был принципиальный сдвиг в индустрии, потому что разработчик перестал зависеть от конкретного железа и начал думать над созданием новых архитектур и алгоритмов.

В СССР этот мировой принцип быстро подхватили и развили локально. Программист Владимир Курочкин написал транслятор универсального языка Алгол-60 сначала для БЭСМ-2, а затем для БЭСМ-6. На этой базе выучились тысячи советских инженеров, которые впоследствии стали основателями ведущих отечественных IT-компаний.

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

3. Технологии 50-х годов помогли заложить основы для автоматизации документооборота

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

Китов предложил создать единую сеть вычислительных центров, чтобы собирать все данные автоматически. Поскольку сам он служил в армии, первый такой проект Китов предложил реализовать на базе вычислительных мощностей Министерства обороны. Эту идею реализовать он не успел: из-за резкой критики руководства Китова исключили из КПСС и сняли с должности.

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

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

Каждую команду нужно было набить вручную, распечатать, проверить и только потом загрузить в машину. Именно с помощью таких инструментов планировалось автоматизировать учет в стране.

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

К концу 1970-х компьютеры на разных базах уже обменивались данными напрямую, и армейская инфраструктура стала работать как полноценный интранет.

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

4. До хакатонов были олимпиады: как школьные соревнования воспитали первых разработчиков коммерческого софта

Сегодня IT-специалисты соревнуются на хакатонах, а в Советском Союзе были олимпиады по программированию. В 1981-м в Москве прошло первое такое соревнование среди школьников, а уже через четыре года информатика официально стала школьным предметом. К 1988 году в Свердловске (ныне Екатеринбург — родина Контура) организовали уже всесоюзное соревнование.

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

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

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

Победителям хотели подарить отечественный персональный компьютер за 500 рублей при зарплате инженера около 100 рублей в месяц. Денег у организаторов не нашлось, поэтому вручили бумажные дипломы и пригласили поступать в МГУ. Из таких олимпиадников и выросло поколение, написавшее первые коммерческие продукты.

5. Кооперативы 1987 года — точка, где наука стала бизнесом

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

В 1988 году трое выпускников Уральского политехнического института (УПИ) создали компанию СКБ Контур. Их первым продуктом стала программа «АМБа» — с ней бухгалтеры смогли вести электронный учет труда и зарплаты на предприятиях. Первыми покупателями стали предприятия Свердловска, в том числе Уральский алюминиевый завод.

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

Со временем алгоритмы и опыт разработки «АМБы» стали базой для новых IT-продуктов Контура. К 2000 году появился «Контур.Экстерн» — платформа для сдачи электронной отчетности в госорганы. Она работает и развивается уже 26 лет.

6. Горбушка и пиратство создали инженерную школу реверс-инжиниринга

На московском рынке Горбушка в 1990-х продавцы торговали прямо с ящиков: запчасти для ZX Spectrum, пиратские операционные системы, бухгалтерские программы на дискетах.

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

В условиях постоянной нехватки денег и информации сформировалась уникальная техническая культура. Программисты набивали руку на сложных задачах: они учились разбирать чужие системы изнутри, понимать скрытые архитектурные решения без официальной документации и воспроизводить сложную функциональность с нуля. Государство технологический сектор в тот период никак не поддерживало, поэтому специалисты выживали самостоятельно. Часть построила собственные компании, часть уехала работать в западные корпорации вроде Microsoft и Oracle — и в обоих случаях сформировала международную репутацию российских инженеров как людей, которые могут решать сложные задачи при минимуме ресурсов.

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

7. Релком доказал, что открытые сети работают — и дал старт провайдерскому рынку

Параллельно с развитием стихийных рынков ПО появлялись отечественные сети связи. В начале 1990-х годов в подвале Курчатовского института группа ученых подняла первую публичную компьютерную сеть в стране — Релком. Секретные военные вычислительные центры прошлого оставались строго изолированными системами. Релком подключал всех: нужен был компьютер, модем и телефонная линия. Инфраструктура строилась на операционной системе UNIX и машинах производства DEC.

Сеть сначала объединила Москву, затем продолжилась в регионах и вышла за пределы страны. Из этого комьюнити вышли первые отечественные провайдеры и первые технологические стартаперы.

Локализация победила глобальных игроков — и это стало моделью для всего российского бигтеха

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

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

Разработчики Контура тоже двигались по этому пути: они начали с профильных программ для бухгалтерии и шаг за шагом переносили бумажное делопроизводство в электронный вид. Решение сложных и рутинных задач бизнеса оказалось отличной стратегией: постепенно продуктовый портфель Контура превратился в экосистему — по такой же логике развивались многие другие российские компании.

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

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

О том, почему бизнес до сих пор считает геймификацию «баловством», в то время как она может стать ключом к решению проблем продуктового онбординга и удержания внимания, рассказал Роман Горшков, арт-директор Битрикс24.

Немного о дефиците внимания

За последние два десятилетия ландшафт человеческого внимания изменился до неузнаваемости. Если в 2004 году среднее время концентрации на одном объекте составляло 150 секунд (2,5 минуты), то к 2024–2025 годам этот показатель упал до критических 40 секунд.

Это означает, что у разработчика B2B-продукта есть меньше минуты, чтобы доказать пользователю ценность инструмента. В геймдеве это понимают лучше, чем где-либо еще: если игрок не понял, что делать в самом начале, шанс, что он вернется в игру стремится к нулю. Бизнес-софт же традиционно полагается на обучение без выбора: многостраничные PDF-инструкции, вебинары и распоряжения руководства. Но в условиях экономики внимания этот подход больше не работает. Поэтому бизнесу стоит искать готовые решения для управления UX (User Experience) у геймдева.

Когнитивная база: эффект генерации и лимиты памяти

Одной из фундаментальных проблем корпоративного ПО является перегрузка рабочей памяти пользователя. Современные исследования показывают, что зрительная рабочая память человека способна удерживать одновременно от 3 до 5 объектов. При превышении этого порога внимание рассеивается, а скорость принятия решений падает.

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

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

«Светлая» vs «Темная» геймификация: этика и эффективность

Геймификацию часто критикуют за манипулятивность. Для B2B-сектора крайне важно разделять типы используемых механик, так как на кону стоит долгосрочное доверие сотрудника к компании.

Белая геймификация: визуальное подкрепление

Это инструменты, которые делают прогресс осязаемым и приносят «чистый» дофамин. К ним относятся:

1. Визуальный восторг: анимация при достижении важной вехи (например, закрытие первой сложной сделки в CRM). Это создает позитивный эмоциональный якорь.
2. «Медальки» за выполнение KPI: награждение за реальные успехи — например, за самую высокую скорость обработки заявок в отделе. Это не манипуляция, а признание профессионализма.
3. Персонализированная мотивация: система достижений (badges), которая фиксирует рост компетенций сотрудника.

Темная геймификация: манипуляция

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

Чек-лист: что внедрить в B2B-продукт

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

• Контекстные подсказки вместо мануалов. Сократите количество ссылок на базу знаний. Информация должна появляться там, где наведен курсор, и тогда, когда пользователь в ней нуждается.
• Поощрение исследовательского поведения. Сделайте интерфейс «безопасным». Пользователь должен чувствовать, что он может «потыкать» любые кнопки без риска сломать систему. Это лучший способ быстрого освоения продукта.
• Визуальное подтверждение успеха. Когда сотрудник выполняет рутинное действие быстрее или качественнее нормы, система должна давать мгновенную визуальную обратную связь.
• Гигиена интерфейса. Соблюдайте когнитивный лимит в 3–4 объекта в фокусе. Если экран перегружен информацией, ни одна геймификация не спасет продукт от отторжения.

Вектор развития: от функций к вниманию

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

На рынок труда выходит поколение, сформированное пользовательским опытом современных игровых платформ. Цифровая среда должна соответствовать ожиданиям тех, кто в ней работает. Сегодняшние нанимаемые специалисты привыкли к качеству UX (пользовательского опыта) уровня потребительских приложений и игр. Если корпоративная экосистема выглядит как софт из 90-х, компания проиграет в борьбе за таланты — люди будут уходить туда, где рабочие инструменты удобнее.

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

1. Visary BI: облачная BI-платформа для анализа и визуализации данных

Visary BI — платформа бизнес-аналитики от НПЦ «БизнесАвтоматика», в реестре отечественного ПО с декабря 2023 года (реестровый номер №20974). По данным TAdviser, система на втором месте по доле на российском рынке BI за 2022–2024 годы. Поставляется в двух форматах: облако с соответствием 152-ФЗ или серверный дистрибутив — для тех, у кого данные за периметр корпоративной сети не выходят.

Что внутри

В основе три инструмента: конструктор дашбордов, конструктор отчётов и визуальный конструктор запросов.

Конструктор запросов подходит — для аналитиков, которые в целом умеют писать SELECT, но не хотят разбираться в диалекте каждой конкретной базы. Объединить 1С, Excel и CRM в один источник можно визуально, без разработчика.

No-code здесь топ-фича: источники данных добавляются без написания кода, связи между источниками настраиваются через визуальный конструктор. При необходимости поддерживается и стандартное написание SQL-запросов к БД. Периодичность обновления данных в дашбордах и отчётах задаётся системными настройками. Среднее время запуска, по данным вендора, около недели.

Отдельно стоит сказать про разграничение прав доступа — оно работает на трёх уровнях: система, дашборд, конкретный объект. Плюс полное логирование действий пользователей.

Из того, что встречается реже, чем хотелось бы в других BI-инструментах: интеграция с видеокамерами и компонент геоаналитики «Карта».

Источники данных, интеграции и экспорт

Для источника данных подключаются внешние ERP, WMS, 1С и другие системы: Visary BI поддерживает типовые коннекторы к реляционным СУБД (MS SQL, Oracle Database, PostgreSQL и др.), работает с файловыми форматами (Excel, CSV, Google Sheets и др.).

Из ОС поддерживаются Windows и AstraLinux — второе актуально для организаций, которые переходят на отечественный стек. Экспорт готовых отчётов — PDF, XLS, XLSX, DOCX, RTF, MHT, HTML, CSV, изображения.

Visary BI — часть экосистемы Visary Cloud, что это значит: корпоративный чат, видеосвязь, файловое хранилище и онлайн-редактор документов подключаются бесплатно в базовой поставке, а не продаются отдельными сервисами сверху. Если нужна трансформация данных перед загрузкой в BI — есть отдельный платный модуль Visary ETL.

Где это используется

Мы попросили вендора привести конкретные примеры, что уже происходило у клиентов.

Первый кейс — розничная сеть. Владелец нескольких точек не понимал, какие товары реально прибыльные с учётом логистики и акций: данные из 1С расходились с Excel, а сводить их вручную занимало несколько дней. Подключили оба источника и CRM. Аналитик за один рабочий день собрал дашборд с маржинальностью по категориям, выполнением плана по точкам и динамикой продаж.

Настроили ежедневную рассылку в Telegram — теперь руководитель видит актуальные данные без обращения к аналитику. От подключения источников до рабочего дашборда — три дня.

Второй кейс — производственное предприятие. Три отдела работали в изоляции: производство в ERP, склад в WMS, бухгалтерия в MSSQL. Сводный P&L собирался вручную две недели. После объединения источников через визуальный SQL-конструктор аналитики без помощи программистов создали OLAP-куб с разбивкой себестоимости по цехам, партиям сырья и временным периодам. Разграничили доступ: цех видит только свои показатели, финансисты — детализацию по статьям затрат, директор по производству — сводную. P&L теперь формируется за один день вместо двух недель. Попутно нашли систематический перерасход сырья в одном из цехов — следующий квартал закрыли с экономией 15%.

Пример дашборда мониторинга финансов

Деньги

Бесплатной версии нет. От 2 000 рублей за пользователя в месяц, тариф «Корпоратив» — 1 600 рублей. Полная сетка с детализацией по функциям — на visary.cloud/tariffs. Оплата через расчётный счёт для юридических лиц.

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

Поддержка и документация

Поддержка работает по Telegram, почте и телефону. Документация на русском языке, видеоуроки в открытом доступе — можно разбираться самостоятельно. По запросу проводятся очные и онлайн-курсы, что актуально, когда нужно обучить несколько команд одновременно. В роадмапе — интеграция AI-инструментов для прогнозной и предиктивной аналитики, а также развитие концепции Action BI: система не только фиксирует проблему, но и предлагает действия для решения. Например, если заметит отставания по срокам — автоматически предложит собрать совещание или пересмотреть направление проекта.

2. Visiology: корпоративная BI-платформа с собственным аналитическим движком

Visiology работает с 2015 года. 500+ клиентов, 2000+ специалистов в сообществе. Трижды побеждала в «BI-круге Громова» (2019, 2021, 2022), взяла номинацию «Драйвер BI» на «Битве BI» при поддержке Минцифры и выиграла конкурс «Лучшие цифровые решения» Аналитического центра при Правительстве РФ.

Что внутри

В основе платформы аналитический движок ДанКо. Он берёт на себя хранение, вычисления и управление доступом, а поверх него работают два продуктовых модуля.

Visiology Dashboards — среда для построения дашбордов и регламентных отчётов. Интерфейс работает в браузере на любой ОС. Поддерживается синтаксис DAX: аналитик строит сложные расчётные показатели прямо в конструкторе, без правок на уровне витрин DWH и без JS- или Python-кода. Новые представления создаются бизнес-пользователями в режиме конструктора — программирование не нужно. Виджеты переиспользуются между проектами или берутся из маркетплейса. По данным вендора, первый дашборд — через два дня после начала обучения.

Visiology Smart Forms закрывает задачу сбора данных с филиалов и подразделений. Форма открывается в браузере на компьютере или мобильном, вводить данные можно или вручную, или загрузкой Excel. Для каждого поля задаются допустимые значения и формат — выбросы система отправляет на уточнение до попадания в хранилище. После заполнения данные сразу попадают в ДанКо, без ручного импорта. Каждый пользователь видит только те ячейки, которые ему открыты по правам доступа.

Разграничение прав работает на уровне движка ДанКо: RLS-политики применяются автоматически, один и тот же дашборд покажет аналитику полную картину, а рядовому сотруднику — только его данные.

Источники данных, интеграции и экспорт

Экспорт дашбордов: PDF, PPTX, PNG. Регламентные отчёты формируются на основе шаблона Excel и можно использовать для печати. Дашборды публикуются на любой внутренний или внешний портал.

Экосистема

Self-Service ETL закрывает предобработку данных до загрузки в ДанКо — без ETL-инженера. В маркетплейсе Visiology есть готовые виджеты и решения партнёров. Для крупных внедрений есть услуги архитектурного и стратегического сопровождения.

Поддержка и документация

YouTube-канал с обучающими материалами в открытом доступе, база знаний, документация, Telegram-сообщество — вендор называет его самым активным среди российских корпоративных BI-платформ. Есть учебник по Visiology 3, история релизов и публичная дорожная карта. Подготовка специалистов — при поддержке вендора.

3. Yandex DataLens: облачный BI от Яндекса с встроенным ИИ-аналитиком

Yandex DataLens — продукт Яндекса, включён в реестр отечественного ПО, работает на сертифицированной облачной платформе и часто проходит пентесты. Поставляется в двух форматах: облако с быстрым стартом или развёртывание в собственной инфраструктуре.

Что внутри

Конструктор визуализаций работает в браузере. Дашборды собираются в визуальном редакторе, без программирования, готовые шаблоны доступны в Галерее — 91 пример по категориям: продажи, маркетинг, HR, геоаналитика, маркетплейсы.

Для сложных расчётов есть встроенный DataLens Formula Language. Когда формульного подхода недостаточно — подключается Editor: JavaScript-кастомизация визуализаций и обработка данных кодом. Там же доступны API-коннекторы для работы с BI как с кодом.

Отдельная фича, которая в других российских BI-системах пока редкость: встроенный ИИ-агент Нейроаналитик. Он создаёт вычисляемые поля в синтаксисе DataLens, пишет JavaScript для Editor и суммаризирует данные для быстрых инсайтов. Работает прямо в интерфейсе.

Права доступа настраиваются через SSO или Яндекс ID, гибко — для групп и отдельных пользователей.

Источники данных, интеграции и экспорт

Больше 30 источников: от загрузки Excel и CSV до нативных коннекторов к ClickHouse и другим СУБД. Модель данных описывается через схемы «звезда» и «снежинка» с оптимизацией связей или через нативный SQL там, где это нужно.

Экспорт дашбордов: PDF, PPTX, PNG. Готовые дашборды публикуются через iframe в корпоративные порталы, CRM и ERP. Рассылка — по расписанию или по событию, в том числе в Telegram. Интерфейс адаптирован под мобильные устройства.

Экосистема

Внешний вид платформы кастомизируется под корпоративный бренд. On-Premises поставляется как архив с Docker-контейнерами и Helm-чартами для развёртывания на k8s/k3s, с регулярными обновлениями и ранним доступом к новым функциям. Сеть из 30+ партнёров с сертифицированными специалистами берётся за внедрение под ключ.

Деньги

Два варианта. Облако — 990 рублей за рабочее место в месяц, для индивидуального использования бесплатно, пробный период 30 дней. On-Premises — от 1,6 млн рублей в год, доступна как годовая подписка, так и бессрочная лицензия.

Поддержка и документация

Telegram-сообщество насчитывает больше 14 000 участников — по этому показателю DataLens заявляет лидерство среди российских BI-платформ. Есть программа сертификации специалистов, вебинары и книга «От дашборда к системе: как построить операционную аналитику в компании» в открытом доступе. Поддержка облачной версии — от Yandex Cloud, on-premises — через авторизованных партнёров и дистрибьюторов.

4. Luxms BI: платформа бизнес-аналитики с 20-летней историей и лицензией ФСТЭК

Luxms BI — платформа ГК Luxms, работает на рынке больше 20 лет. Внесена в реестр российского ПО, имеет лицензию ФСТЭК на безопасную разработку — по этому показателю вендор заявляет первое место среди российских BI-систем. В рейтинге «Созвездие BI — 2025» платформа вошла в топ-3, заняла второе место по приросту функционала за год и первое по доле прироста в стратегии развития.

Что внутри

Платформа покрывает полный цикл работы с данными: получение и подготовка, встроенное хранилище, визуализация, отчётность, администрирование и кастомизация. Self-Service позволяет бизнес-пользователям строить дашборды самостоятельно.

Отдельный продукт внутри экосистемы — Luxms Data Boring, встроенный ETL/ELT-инструмент. Он закрывает задачу предобработки данных до загрузки в платформу. Есть даже поддержка write-back (обратная запись данных через формы ввода прямо в дашбордах), графовые базы данных для анализа связей, предиктивное обслуживание оборудования через интеграцию с IoT-датчиками.

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

Источники данных, интеграции и экспорт

Платформа подключается к CRM, ERP, реляционным СУБД, Excel и внешним API. Есть совместимость с Arenadata Prosperity и Tantor Certified 15. Среди форматов работы с данными: массовая загрузка из Excel, реестровый сбор через веб-формы, интеграция с LoRaWAN-датчиками.

Поддержка и документация

Документация разделена на три роли: оператор, аналитик, администратор. Обучение проводится очно, есть официальный Telegram-канал и отдельное комьюнити для пользователей платформы. Услуги включают внедрение, техподдержку, технический аккаунт-менеджмент и миграцию с Qlik, Power BI и SAP.

Вместо вывода

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

Если нужна точка входа и быстрое решение: Visary BI стартует от 2 000 рублей за пользователя в месяц, среднее время от подключения источников до рабочего дашборда по данным вендора — около трёх дней. Для команды, которая хочет сначала увидеть результат, а потом принимать решение о масштабировании, это конкретный ориентир. Остальное зависит от задачи: объём данных, инфраструктурные требования, нужен ли ETL внутри платформы или он уже есть.

Oracle — один из крупнейших поставщиков корпоративных баз данных и облачной инфраструктуры. По данным CNBC, компания начала массовые увольнения на фоне агрессивных инвестиций в ИИ-инфраструктуру и падения акций на 25% с начала года.

• Oracle увольняет от 20 до 30 тысяч сотрудников — около 18% от 162 000 штата
• Сотрудники получили письмо об увольнении в 6 утра без предупреждения — доступ к системам отключён немедленно
• Сэкономленные $8–10 млрд пойдут на строительство ИИ-дата-центров и GPU-кластеров
• Oracle планирует вложить $156 млрд в ИИ-инфраструктуру и уже привлекла $45–50 млрд долгового и акционерного финансирования в 2026 году
• При этом чистая прибыль Oracle выросла на 91% до $6,1 млрд за квартал — компания прибыльна

Как Oracle уволила тысячи людей за одно утро

Массовые сокращения начались 31 марта 2026 года. Сотрудники в нескольких странах получили письмо от «Oracle Leadership» около 6 утра по местному времени. Ни HR, ни непосредственные руководители не предупреждали заранее. В письме говорилось, что должность ликвидирована в рамках «организационных изменений», а день получения письма — последний рабочий день.

Доступ к корпоративным системам был отключён немедленно. Сотрудники начали подтверждать увольнения в реальном времени на Reddit и анонимной платформе Blind. По их данным, в подразделениях Revenue and Health Sciences (RHS, медицинские данные и аналитика доходов) и SaaS and Virtual Operations Services (SVOS, облачные операции) сокращения затронули минимум 30% команд. Часть позиций, по данным Bloomberg, были внутренне отмечены как «заменяемые ИИ» — какие именно роли, Oracle не уточняла.

Масштаб: до 30 000 сотрудников Oracle

Oracle официально не подтвердила общее число уволенных. Инвестиционный банк TD Cowen оценивает масштаб в 20–30 тысяч человек — около 18% глобального штата компании (162 000 сотрудников по данным на май 2025 года). Если оценка подтвердится, это будет крупнейшее сокращение в истории Oracle.

Информация о планируемых сокращениях впервые появилась 5 марта 2026 года в Bloomberg — тогда источники говорили о «тысячах» увольнений. 31 марта план начал исполняться.

Зачем Oracle это делает: $156 млрд на ИИ-инфраструктуру

Oracle взяла курс на масштабное строительство ИИ-инфраструктуры: дата-центры, GPU-кластеры и облачные мощности для клиентов, включая OpenAI, Meta и Nvidia. Деньги на это нужны быстро, а текущий баланс не позволяет финансировать строительство без жертв.

• $156 млрд — оценка TD Cowen совокупных капитальных затрат Oracle на ИИ-инфраструктуру
• $45–50 млрд — долговое и акционерное финансирование, которое Oracle планировала привлечь в 2026 году
• $8–10 млрд — ожидаемая ежегодная экономия от сокращения штата, по оценке TD Cowen
• $2,1 млрд — бюджет плана реструктуризации (раскрыт в ежеквартальном отчёте 10-Q); $982 млн из него уже потрачены, остаток ~$1,1 млрд предназначен для выходных пособий

При этом Oracle — прибыльная компания. Чистая прибыль за последний квартал составила $6,1 млрд (рост на 91% год к году). Но прибыль и свободный денежный поток — разные вещи: Oracle привлекает десятки миллиардов долга, и инвесторы видят, что денег на строительство дата-центров не хватает даже при рекордной выручке. Отсюда — падение акций на 25% с начала года, худший показатель среди технологических гигантов.

Спрос на ИИ-инфраструктуру — как на GPU, так и на CPU — по-прежнему превышает предложение. Это напрямую отражается в наших контрактных обязательствах на $553 млрд.

Реакция рынка и сотрудников Oracle

Несколько американских банков, по данным TNW, повысили стоимость кредитования или отказались финансировать часть проектов Oracle по строительству дата-центров. Сотрудники на Reddit и Blind описывают процесс увольнения как «бесчеловечный»: отсутствие предупреждения, немедленное отключение от систем, безличное «Oracle Leadership» вместо имени руководителя. Oracle публично не прокомментировала события 31 марта.

Контекст: люди vs инфраструктура

Oracle — не единственная компания, которая жертвует штатом ради ИИ. Но она делает это откровеннее других: увольняет при рекордной прибыли, а не при убытках. Microsoft закрыла худший квартал с 2008 года на фоне масштабных ИИ-капрасходов. OpenAI привлекла $122 млрд — и именно Oracle строит для неё облачную инфраструктуру.

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

Выводы

Oracle увольняет до 30 тысяч человек не потому, что бизнес убыточен — прибыль на рекордном уровне. Компания сделала выбор: люди сейчас или машины на будущее. Деньги, которые шли на зарплаты, пойдут на GPU-кластеры и дата-центры для OpenAI и Meta.

Источники: CNBC, The Next Web, Boing Boing

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

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

Хроники бумеранга

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

Статистическое подтверждение тренда

Аналитики компании Visier, изучив данные о трудоустройстве 2,4 млн сотрудников из 142 международных компаний, пришли к выводу: часть уволенных работников впоследствии возвращаются к прежнему работодателю.

В исследовании отмечают, что этот показатель стабильно рос в течение 2025 года, особенно в подразделениях, активно внедрявших ИИ. Аналитики связывают это с тем, что многие руководители начинали сокращениям, толком не разобравшись, в решении каких конкретно задач новые технологии смогут помочь.

Экономическая неэффективность массовых сокращений

Глубинной причиной этого тренда стала низкая отдача от инвестиций в ИИ. Исследование Массачусетского технологического института (MIT) «The GenAI Divide: State of AI in Business 2025» демонстрирует фундаментальную проблему: 95% компаний не получили ощутимой прибыли от своих вложений в генеративный ИИ. Многие проекты зависали на стадии пилотов, так и не выходя в промышленную эксплуатацию.

Смена приоритетов бизнеса

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

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

Влияние на рынок труда

Воздействие ИИ-решений на занятость неоднородно. Исследование профессора НИУ ВШЭ Ларисы Смирных, охватившее почти 1800 российских предприятий, показало, что в среднем внедрение ИИ приводило к сокращению занятости на 0,79 процентного пункта.

Однако на малых предприятиях сокращение составило 1,26 п.п., на крупных — 2,08 п.п., а предприятия среднего размера, напротив, увеличили численность работников на 2,96 п.п.. Это доказывает, что эффект зависит от сочетания структурных и финансовых факторов конкретного бизнеса.

Косвенные эффекты и кризис воспроизводства кадров

Параллельно с возвратным наймом развивается и другой тренд — сокращение входных позиций для новичков. Исследование Stanford Digital Economy Lab выявило, что с момента запуска ChatGPT занятость молодых специалистов в профессиях, подверженных автоматизации, снизилась на 13%.

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

Реальные кейсы: кто и почему возвращает сотрудников

Истории замены и возврата оказались сложнее примитивной схемы «робот занял место человека». Компании столкнулись с тем, что эффективное использование ИИ требует не устранения человеческого фактора, а его интеграции с технологиями.

Amazon и цена ошибки

История Amazon показательна. Осенью 2024 года ИИ-система, заменившая часть DevOps-инженеров, стала причиной катастрофического сбоя в AWS (многофункциональный облачный сервис). Длительный простой десятков крупных интернет-платформ наглядно продемонстрировал — алгоритмы не справляются с нештатными ситуациями.

После инцидента компания начала тихий возврат ключевых специалистов — для создания систем контроля и аварийного реагирования.

McDonald's: 260 наггетсов вместо бургера

Голосовой ИИ от IBM в drive-in сетей McDonald's должен был ускорить прием заказов. Система анализировала историю покупок и предлагала клиентам персональные варианты. Но что-то пошло не так. В 2024 году соцсети наполнились роликами с ошибками алгоритма. ИИ добавлял бекон к мороженому, предлагал девять порций чая вместо булочки и выставлял счета на 260 наггетсов.

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

Российский подход: адаптация через переобучение

В России компании демонстрируют стратегию осторожной интеграции, делая ставку на трансформацию должностей вместо их ликвидации. Исследование TAdviser показывает, что доля крупных российских компаний, использующих AI-решения, выросла с 28% до 43% за 2024-2025 годы.

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

Изначально банк запланировал три волны увольнений на 2025 год с целью сокращения издержек и увеличения прибыли. Вторая волна, по заявлению компании, напрямую связана с внедрением AI-ассистентов. Алгоритмы брали на себя рутинные задачи тестировщиков, разработчиков и руководителей команд.

Но катастрофических сокращений не последовало. Банк начал создавать новые подразделения поддержки AI-продуктов. Часть уволенных сотрудников получила предложения вернуться на измененных условиях. Не как исполнители, а как наставники алгоритмов.

Где ИИ действительно преуспел, а где провалился

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

Сферы эффективного применения ИИ

Наибольшую результативность алгоритмы демонстрируют в областях с четко определенными правилами и большими объемами структурированных данных:

• обработка типовых тикетов технической поддержки увеличивает скорость ответа на 30-50%;
• генерация шаблонного кода стала рутинной практикой, особенно в мобильной разработке где преобладают типовые архитектурные паттерны;
• первичный анализ данных и построение базовых отчетов перешли в зону ответственности ИИ;
• автоматическое тестирование стандартных сценариев освободило QA-инженеров от рутины.

Инструменты типа GitHub Copilot успешно справляются с созданием стандартных функций. Время на написание повторяющегося кода сокращается в среднем на 35-40%. Алгоритмы эффективно обрабатывают большие массивы информации, выявляя очевидные зависимости и аномалии.

Области, требующие человеческого участия

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

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

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

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

Почему сокращения оказались убыточными — экономический аспект

Платформа Orgvue провела расчет полной стоимости увольнений. Результат озадачил финансовых директоров. На каждый сэкономленный доллар на зарплатах компании несли $1.27 скрытых расходов.

В анализ вошли:

• выходные пособия и страховые выплаты;
• потеря продуктивности в переходный период;
• затраты на рекрутинг новых сотрудников;
• удар по бренду работодателя;
• расходы на дообучение оставшегося персонала.

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

Новые профессии на стыке человека и алгоритма

Рынок труда демонстрирует адаптивность в ответ на распространение ИИ. Вместо массового сокращения штатов формируется сегмент гибридных специальностей, требующих сочетания предметной экспертизы и технологической грамотности. Согласно исследованию hh.ru, зарплаты в этих направлениях выросли на 20-45% за 2024-2025 годы, отражая дефицит квалифицированных кадров.

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

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

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

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

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

Фундаментальные ограничения: почему ИИ не заменит человека в ближайшем будущем

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

Когнитивные барьеры:

• отсутствие здравого смысла — ИИ не понимает очевидных для человека вещей;
• хрупкость моделей — при столкновении с нестандартными данными выдают абсурдные результаты;
• неспособность к настоящему творчеству — только комбинация существующих паттернов;
• отсутствие эмоционального интеллекта — не могут сопереживать и понимать чувства.

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

Российский рынок труда: трансформация, а не замена

В 2025 году российский рынок труда демонстрирует осторожный подход: несмотря на активное внедрение технологий, он развивается по пути трансформации и сотрудничества, а не массового замещения сотрудников.

Экономический контекст и кадровый дисбаланс

Ситуация на рынке труда в целом неоднозначна. Исследование «Актион Кадры и HR» показывает, что более 40% российских компаний не исключают сокращений штата в 2025-2026 годах. Основными причинами называют высокую ключевую ставку, удорожание кредитов и общую экономическая неопределенность.

При этом существует острый дефицит квалифицированных кадров в промышленности, строительстве и IT — здесь работодатели готовы повышать зарплаты для привлечения специалистов. Это противоречие объясняется нехваткой сотрудников с конкретными, востребованными навыками.

Внедрение ИИ: осторожность и прагматизм

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

• Упор на эффективность. Генеративные модели стали базовым инструментом в финтехе, промышленности и медицине. При грамотном использовании они увеличивают производительность труда до 20%, а снижение издержек достигает 15%.
• Ограниченное использование в HR. Только 38% компаний применяют генеративный ИИ для скрининга резюме, что говорит о предпочтении человеческого контроля в ключевых процессах управления талантами.
• Сдвиг в IT-найме. В IT-сфере наблюдается профицит кандидатов начального уровня (джунов), в то время как дефицит высококвалифицированных senior-специалистов сохраняется. Индекс конкуренции на одну вакансию достигает 12.5 резюме, но для позиций senior-уровня он составляет всего 2.5.

Барьеры на пути автоматизации

Несколько ключевых проблем мешают российскому бизнесу провести тотальную автоматизацию:

• Недоверие и дефицит компетенций. 43% компаний отмечают недоверие к ИИ как к технологии, а в 40% организаций просто не хватает специалистов, способных с ним работать.
• Сопротивление изменениям. Сотрудники на всех уровнях — от рядовых специалистов до топ-менеджеров — часто сопротивляются внедрению новых технологий, опасаясь неопределенности.
• Технологическое отставание и гибридные решения. Необходимость адаптации западных ИИ-решений к местным реалиям и отставание российских аналогов вынуждают компании искать сложные гибридные подходы, что замедляет процесс.

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

Государство и регуляция: запаздывающая реакция

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

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

Что делать специалисту: практические выводы

Стратегия «возьми готового, используй, замени» оказалась нежизнеспособной. 71% сотрудников уходят из компаний из-за низкой зарплаты, 57% — из-за стресса и перегрузок. В новых условиях компании стали больше ценить персонал, но и специалистам стоит позаботиться о своем будущем.

Как сохранить ценность на рынке:

• развивать мягкие навыки — эмпатию, адаптивность, гибкость управления;
• осваивать ИИ как инструмент, а не конкурировать с ним;
• фокусироваться на задачах, требующих человеческого понимания контекста;
• инвестировать в непрерывное обучение, особенно в смежных областях.

Успешные компании создают экосистему долгосрочной лояльности. Развитие сотрудников и забота об их благополучии становятся главными конкурентными преимуществами в борьбе за таланты.

Трансформация рабочих мест: реалии и перспективы симбиоза человека и ИИ

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

Масштабы воздействия: от апокалиптических прогнозов к реальным цифрам

Исследования показывают значительный, но не катастрофический потенциал автоматизации. Ученые из Массачусетского технологического института (MIT) с помощью инструмента «Индекс айсберга» смоделировали влияние ИИ на почти 1000 профессий.

Результаты показывают, что современные системы теоретически могут заменить задачи, эквивалентные 11,7% всей рабочей силы США. Однако авторы подчеркивают, что экономические препятствия, затраты на внедрение и необходимость человеческого контроля сдержат тотальную автоматизацию в обозримом будущем .

Этот вывод перекликается с настроениями бизнес-лидеров. Опрос Forbes Research 2025 AI Survey демонстрирует, что 94% руководителей по всему миру ожидают сокращения менее 5% рабочих мест в течение следующих двух лет. Более того, 59% полагают, что ИИ в конечном итоге создаст новые профессии, а не ликвидирует существующие.

В России потенциал автоматизации оценивается примерно в 11 миллионов эквивалентов занятости. Речь идет в первую очередь о перераспределении задач, а не об исчезновении профессий как таковых .

Два пути развития: почему будущее за усилением, а не за автоматизацией

Аналитики и историки технологий выделяют два принципиально разных сценария развития ИИ в экономике:

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

Текущая практика показывает движение по второму пути. Внедрение ИИ становится корпоративным трендом, но не приводит к массовым чисткам.

Новый ландшафт профессий: что происходит на рынке труда

Профессии не исчезают массово, но интенсивно трансформируются. Этот процесс имеет несколько четких проявлений:

1. Рождение гибридных специализаций. Рынок создает спрос на интеграторов моделей, специалистов по безопасности ИИ, AI-тренеров и промпт-инженеров. Эти профессионалы, обладающие навыками работы с алгоритмами, могут получать на 20% больше, чем их коллеги без такого опыта .
2. Перераспределение задач внутри профессий. ИИ берет на себя рутинные операции, освобождая время людей для более сложных задач. В результате меняются должностные инструкции, а не состав персонала. Исследование Microsoft показывает, что ИИ может выполнять до 98% задач переводчика, 91% задач математика и 81% задач журналиста, но это не делает сами профессии ненужными — оно меняет их суть.
3. Устойчивость «человеческого» в работе. Даже самые продвинутые алгоритмы сталкиваются с фундаментальными ограничениями. Группа ученых из США и Австрии объясняет это «вложенностью навыков». Продвинутые профессиональные умения опираются на широкий спектр базовых — логику, математику, эмпатию, анализ рисков, работу в условиях неопределенности. Создать такую многослойную систему в цифровой среде пока невозможно. ИИ не обладает интуицией, ценностями и эмоциональной вовлеченностью.

Итоги

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

24 марта 2026 года OpenAI объявила о прекращении работы приложения Sora, API и всех связанных функций генерации видео — включая видеовозможности внутри ChatGPT. Приложение закроется 26 апреля, API — 24 сентября.

— Sora обходилась OpenAI в $15 млн ежедневно (Forbes) при совокупной выручке $2,1 млн (Appfigures) — Disney отменила инвестицию в $1 млрд, привязанную к Sora — За последний год OpenAI запустила и свернула шопинг в ChatGPT, развернула позицию по рекламе и NSFW, затормозила проект Stargate — The Atlantic называет это «кризисом идентичности собственного производства»

Почему Sora провалилась

Один 10-секундный клип в Sora требовал около 40 минут GPU-времени на четырёх параллельных видеокартах — примерно $1,30 за ролик. Ещё осенью 2025 года Forbes оценивал ежедневные расходы на Sora в миллионы долларов.

Экономика [Sora] абсолютно неустойчива

К моменту закрытия расходы достигли $15 млн в день. Совокупная выручка от покупок в приложении за всё время — $2,1 млн (оценка Appfigures). Скачивания упали на две трети от ноябрьского пика — с 3,3 млн до 1,1 млн в феврале. Сделка с Disney, которая разрешила использовать более 200 персонажей Marvel, Pixar и Star Wars и включала план инвестирования $1 млрд, развалилась — деньги так и не были переведены.

«Слоп — это не бизнес-стратегия»

Но дело не в одной Sora. Как пишет The Atlantic, быстро запустить продукт и внезапно свернуть его — фирменный приём OpenAI. Компания провела последние годы, перебирая бизнес-модели с «впечатляющей скоростью» в попытке найти путь к прибыльности. И, похоже, наконец учится: слоп — это не бизнес-стратегия.

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

После успеха ChatGPT инвесторы залили OpenAI деньгами. Компания сейчас стоит дороже, чем Toyota, Coca-Cola и Disney вместе взятые. Но инвесторы хотят видеть отдачу — а OpenAI до сих пор не доказала, что способна генерировать достаточно денег, чтобы не уйти в минус.

Хроника разворотов

Летом 2025 года Альтман описал OpenAI как четыре отдельные компании одновременно: потребительский бизнес, масштабный инфраструктурный проект, ИИ-лаборатория и инкубатор «нового», включая железо. The Atlantic замечает: проблема попытки делать всё — иногда ты кончаешь тем, что не делаешь хорошо ничего.

• Stargate — масштабный инфраструктурный проект с Oracle и SoftBank. Застопорился из-за плохой координации между партнёрами
• Реклама — Альтман называл её «крайней мерой», но в начале 2026 года OpenAI запустила рекламную инициативу
• Шопинг в ChatGPT — запущен осенью 2025, закрыт тут же. Компания пивотнулась к «product discovery»
• Собственное устройство — первый девайс обещали в 2026, по судебным документам — не раньше 2027
• NSFW-контент — запретили, потом объявили об исключениях, запланировали запуск эротики в декабре, потом отложили на неопределённый срок
• Nvidia — отозвала план инвестировать до $100 млрд в OpenAI. По данным WSJ, CEO Дженсен Хуанг выражал озабоченность «недостатком дисциплины» в бизнес-подходе (сам Хуанг назвал эти сообщения «ерундой»)

По словам The Atlantic, ни одно партнёрство и ни одна дорожная карта продуктов OpenAI не выглядят гарантированно живучими. Планы компании всегда условны.

Копируя Anthropic

На фоне хаоса OpenAI теряет позиции перед Anthropic — главным конкурентом в гонке ИИ. Anthropic последовательно фокусировалась на корпоративном рынке, продавая инструменты для повышения продуктивности бизнесу, — и добилась заметных успехов. Теперь OpenAI пытается скопировать этот плейбук.

Мы не можем упустить этот момент, потому что отвлекаемся на побочные квесты

Симо заявила сотрудникам, что компания сосредоточится на «продуктивности на бизнес-фронте». OpenAI планирует почти удвоить штат в 2026 году и готовит «суперприложение» — объединение всех продуктов в одно, чтобы конкурировать с корпоративными инструментами Anthropic. «Мы размазывали усилия по слишком многим приложениям, — написала Симо. — Эта фрагментация замедляла нас».

По информации Variety, реструктуризация связана с подготовкой к IPO в четвёртом квартале 2026 года.

Что будет с технологией

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

Рынок генерации видео при этом не пустует: Runway, Pika и другие продолжают развиваться. Но история Sora показывает, что генерация видео пока остаётся технологией в поисках бизнес-модели — ни один игрок не нашёл способ сделать её прибыльной.

Источники: The Atlantic, Variety, TechCrunch, CNBC, Forbes

Инструменты собирают заявки из чата на сайте, мессенджеров, соцсетей и электронной почты, чтобы оператор не переключался между вкладками.

Системы подключают базы знаний, сценарии ответов и распознавание тональности диалога.

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

Краткий ТОП-5 сервисов технической поддержки клиентов

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

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

Umnico — омниканальная платформа интегрирует мессенджеры и соцсети с CRM, включая WhatsApp, Telegram, Instagram, ВК и Авито. Сервис позволяет создавать чат-ботов на базе GPT-4 для автоматизации до 90% первичных обращений.

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

Chat2Desk — сервис объединяет переписки из мессенджеров, соцсетей и веб-виджетов в едином интерфейсе с привязкой к CRM. Платформа включает конструктор чат-ботов без программирования, поддерживает рассылки по клиентской базе.

14 лучших сервисов технической поддержки клиентов

Happydesk

Тестовый период: 2 недели бесплатно

Облачная система для поддержки клиентов собирает обращения из почты, мессенджеров, соцсетей и веб-виджетов в едином окне. Платформа подключает ИИ-ассистента на базе ChatGPT, который берет на себя типовые запросы и работает 24/7.

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

Функционал:

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

Контролирует соблюдение времени реакции по каждому обращению. Формирует отчеты любого уровня детализации автоматически. Интегрируется с телефонией, CRM.

Плюсы:

• Хорошая интеграция со сторонними CRM;
• Анализ и сегментация обращений из различных источников;
• Удобный для восприятия интерфейс;
• Доступные цены.

Минусы:

• Исключительно подходит для работы с жалобами, нет дополнительного функционала.

Тарифы: от 1200 р/3 месяца

Юздекс

Тестовый период: не указано

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

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

Система автоматически оценивает качество ответов по нескольким параметрам, включая полноту, вежливость и отсутствие ошибок.

Встроенный ИИ формирует краткие резюме длинных диалогов, чтобы новый оператор быстро вникал в контекст.

Функционал:

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

Плюсы:

• Работа с тональностью обращений;
• Фильтрация обращений по множеству параметров;
• Есть функция автоперевода.

Минусы:

• ИИ-помощник часто некорректно интерпретирует пользовательские сообщения, нужна ручная проверка.

Тарифы:

• Стандарт: 3499 р/мес. 50 ГБ данных, 3 готовых интеграции и до 50 автоматических правил.
• Эксперт: 4499 р/мес. Стандарт + ИИ-помощник.
• Премиум: рассчитывается индивидуально. Разработка своей собственной базы Знаний + ботов под ключ.

Umnico

Тестовый период: 3 дня после регистрации + бесплатный чат-бот на сайте клиента

Комплексная платформа управляет клиентскими коммуникациями в едином интерфейсе с поддержкой всех ключевых каналов: мессенджеры, соцсети, маркетплейсы, онлайн-чаты на сайтах.

Система маршрутизирует диалоги между операторами по заданным правилам и хранит полную историю переписки по каждому клиенту независимо от канала обращения.

Платформа позволяет создавать чат-ботов на базе GPT-4 для автоматизации до 90% первичных запросов. Открытое API дает возможность интегрировать Umnico с любыми CRM.

Функционал:

Объединяет мессенджеры, соцсети и маркетплейсы в едином окне. Маршрутизирует диалоги между операторами по заданным правилам. Создает чат-ботов на базе GPT-4 без программирования. Хранит историю переписки по каждому клиенту в профиле. Интегрируется с любыми CRM через открытое API.

Плюсы:

• Есть конструктор чат-ботов;
• Надёжное API;
• Есть история взаимодействий с клиентом.

Минусы:

• Автоматизированные ответы слишком шаблонны, это часто раздражает пользователей.

Тарифы: зависит от подключаемого модуля

ВебОфис

Тестовый период: не указано

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

Доступны доски для управления проектами, диаграммы для планирования, а также гибкая настройка прав доступа по ролям и группам.

Функционал:

Объединяет заявки из разных каналов в едином реестре. Настраивает маршрутизацию обращений с учетом загрузки сотрудников. Подключает базу знаний с древовидной структурой. Контролирует соблюдение времени реакции и собирает статистику по операторам. Добавляет доски для проектов и диаграммы планирования.

Плюсы:

• Построение сложной логики диалога;
• Работа с заявками из разных каналов связи;
• Работа с несколькими пользователями.

Минусы:

• Непрозрачная тарификация.

Тарифы: рассчитывается индивидуально под персональное решение

Chat2Desk

Тестовый период: до 50 тестовых диалогов через чат-бота

Центр обработки сообщений объединяет WhatsApp, Telegram, Instagram, ВКонтакте, Viber, email и онлайн-чат на сайте в едином интерфейсе с привязкой к CRM. Платформа подключает внешние каналы для приема сообщений, включая маркетплейсы и площадки объявлений.

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

Функционал:

Объединяет мессенджеры, соцсети и маркетплейсы в одном окне. Подключает площадки объявлений как каналы обращений. Дает доступ к конструктору чат-ботов без программирования. Интегрируется с CRM и учетными системами через API. Позволяет нескольким менеджерам работать с одним аккаунтом.

Плюсы:

• Объединяет сразу несколько мессенджеров и чатов воедино;
• Хорошая интеграция с CRM, в том числе — самописными;
• Работа с маркетплейсами.

Минусы:

• Низкие лимиты на всех тарифах.

Тарифы:

• Базовый: 5000 р/мес. 2 мессенджера и до 1000 диалогов;
• Стандарт: 9000 р/мес. 4 мессенджера и до 4000 диалогов;
• Профессиональный: 15 000 р/мес. 6 мессенджеров и до 8000 диалогов.
• Индивидуальный: по запросу.

Hubex

Тестовый период: есть демо-версия по запросу

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

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

Функционал:

Управляет заявками с привязкой к выездному персоналу. Распределяет обращения с учетом геолокации и загрузки сотрудников. Контролирует выполнение работ на каждом этапе в мобильном приложении. Подключает управление активами и оборудованием. Учитывает складские запасы запчастей и материалов.

Плюсы:

• Есть вспомогательные модули для управления бизнесом;
• Синхронизация хелпдеск-системы с панелью управления складом, подходит для работы выездных и технических сотрудников;
• Быстрая и надёжная синхронизация.

Минусы:

• Высокая стоимость даже базовой комплектации программы.

Тарифы:

• Базовый: 40 000 р разово или 20 000 за год. До 500 сообщений и 200 МБ памяти;
• Стандарт: 60 000 р разово или 30 000 за год. До 1000 сообщений и до 400 МБ памяти;
• Бизнес: 80 000 р разово или 40 000 за год. До 1500 сообщений и до 600 МБ памяти.

Intradesk

Тестовый период: бесплатно до 1 Гб памяти и 3 исполнителей

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

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

Функционал:

Автоматически превращает сообщения из мессенджеров в заявки. Формирует краткие резюме диалогов через ИИ. Транскрибирует звонки и оценивает тональность общения.

Подсказывает релевантные статьи из базы знаний. Управляет инцидентами по методологии. Ведет учет активов с интеграцией систем мониторинга. Настраивает маршрутизацию и автозаполнение полей через веб-интерфейс. Генерирует QR-коды для быстрой подачи заявок.

Плюсы:

• Удобная в освоении система;
• Есть транскрибатор звонков;
• Разделение и работа с обращениями по группам.

Минусы:

• Синхронизация с мессенджерами не всегда срабатывает, как надо.

Тарифы:

• Стандарт: 10 000 р/месяц. До 20 исполнителей;
• Бизнес: 20 000 р/месяц. До 50 исполнителей.

Mango Office

Тестовый период: есть демо-версия

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

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

Функционал:

Объединяет виртуальную АТС и контакт-центр в облаке. Распределяет звонки через голосовое меню с разными сценариями.

Записывает все разговоры для контроля качества. Переключает клиентов на операторов или оставляет голосовые сообщения. Интегрируется с CRM и другими системами через API.

Плюсы:

• Есть работа как с ботами, так и с живыми сотрудниками;
• Хорошая интеграция с иными CRM;
• Запись и расшифровка разговоров.

Минусы:

• Заточена сугубо под звонки и голосовую помощь.

Тарифы: рассчитываются после регистрации

ITSM365

Тестовый период: 14 дней

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

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

Функционал:

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

Плюсы:

• Есть разные модули для разных направлений бизнеса;
• Качественная и быстрая интеграция;
• Есть мобильное приложение с разделением ролей.

Минусы:

• Тариф Стандарт и Бизнес слишком дороги для предоставляемого функционала.

Тарифы:

• Старт: 9500 р/мес. До 5 лицензий;
• Лайт: 17 000 р/мес. 10 лицензий;
• Стандарт: 35 000 р/мес. 10 лицензий + точная индивидуальная настройка;
• Бизнес: 69 000 р/мес. Персональная поддержка и консультации.

Upservice

Тестовый период: 2 недели

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

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

Функционал:

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

Подключает базу знаний и сценарии для стандартных ответов. Интегрируется с CRM и учетными системами через API.

Плюсы:

• Удобная и быстрая систематизация всех обращений в едином окне;
• Быстрая и простая синхронизация;
• Недорогие тарифы.

Минусы:

• Нет нормальных ИИ-решений, что снижает скорость автоматизации.

Тарифы:

• Базовый: 1890 р/мес за сотрудника. Гостевой доступ + ИИ-ассистент;
• Энтерпрайз: по запросу, до 50 сотрудников. Помощь во внедрении и поддержка.

Omnidesk

Тестовый период: не указано

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

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

Функционал:

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

Плюсы:

• Простота в настройке и управлении;
• Есть автоматическое распределение ролей между сотрудниками;
• Хорошая работа со статистикой.

Минусы:

• Недостаточно проработанный функционал, подходит для несложных задач.

Тарифы:

• Базовый: 15 евро/мес. От 2 до 10 сотрудников, базовый функционал;
• Про: 25 евро/мес. От 5 сотрудников, все лимиты повышены вдвое.

Intraservice

Тестовый период: до 1 ГБ баз данных и до 3 исполнителей, данные хранятся в облаке.

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

Встроенный модуль SLM контролирует соблюдение соглашений по времени реакции и решения проблем. Система поддерживает каталог услуг с согласованиями, учет оборудования и интеграции с системами мониторинга.

Функционал:

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

Плюсы:

• Есть удобная бесплатная версия;
• Интеграция с системами мониторинга и контроля за рабочим временем;
• Хорошо работает с модулями технического учёта, незаменима для сервисных центров.

Минусы:

• Перегруженный и дорогой функционал.

Тарифы:

• SaaS+: 10 000 р/мес. 15 пользователей и БД до 20 ГБ.
• Enterprice: 790 000 р разово за полную коробочную версию.

PYRUS

Тестовый период: 0 р за базовую версию из коробки.

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

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

Функционал:

Объединяет звонки, чаты и мессенджеры в контакт-центре. Подключает ИИ-ассистентов для автоматической обработки. Анализирует разговоры через речевую аналитику. Оценивает качество работы операторов автоматически. Управляет очередями и маршрутизирует по гибким сценариям. Поддерживает предиктивный и прогрессивный обзвон.

Плюсы:

• Есть удобная база знаний по системе и бесплатное приложение;
• Хорошая работа с нейроинструментами;
• Удобный интерфейс.

Минусы:

• Иногда слетает синхронизация.

Тарифы: Облачно: 415 р/мес. Визуальный конструктор и CRM-для бизнес процессов. Есть возможность приобрести оффлайн-версию с пожизненной поддержкой.

Naumen

Тестовый период: не указано

Платформа класса CX (Customer Experience) объединяет управление клиентским сервисом, контакт-центр и аналитику взаимодействий в единой экосистеме. Система обрабатывает обращения из любых каналов: телефонные звонки, чаты, мессенджеры, соцсети, почты и веб-формы.

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

Функционал:

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

Плюсы:

• Работа с тональностью обращений;
• Помимо хелпдеск-системы — полноценная CRM.

Минусы:

• Непрозрачные условия сотрудничества.

Тарифы: рассчитываются после регистрации.

Заключение

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

Но в повседневной жизни люди пользуются не одним паспортом, у каждого на руках целая стопка: СНИЛС, ИНН, трудовая книжка, водительское удостоверение, свидетельства о рождении, браке, полисы и другие документы. И каждый из этих документов в какой-то момент нужно предъявить, загрузить или верифицировать, поэтому мы обучили наш ИИ распознавать более 5000 шаблонов документов.

Рассказываем, в каких сценариях сегодня применяется наша технология.

Банки: выдача карт и кредитный скоринг

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

В случае с кредитованием банку нужно не только провести KYC, но и проверить платёжеспособность клиента. Для этого требуются новые документы: справка о доходе, СНИЛС, водительское удостоверение, свидетельство о постановке на налоговый учёт, загранпаспорт, трудовая книжка.

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

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

Трудоустройство: как ИИ устраняет узкое место в HR

Если вы когда‑либо заключали договор или оформляли на работу сотрудника, вы знаете: в этом процессе необходим ИНН. Свидетельство о постановке на налоговый учёт — еще один важный документ, который часто требуется в реальной жизни. Наш ИИ точно распознает все ключевые поля из документа, включая ФИО, дату рождения, серию и номер.

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

Вместо того чтобы фотографировать каждый документ по одному, можно разместить их рядом и сделать один снимок. Для этого мы добавили возможность мультиобъектного распознавания. Показываем, как это работает:

ИИ сам находит на изображении все документы, автоматически классифицирует их а затем извлекает необходимые поля.

Найм и обслуживание мигрантов

В РФ работает больше 6 млн мигрантов из разных регионов мира, в том числе из стран СНГ, а также Индии, Китая, Пакистана и других государств. У многих из них на руках не только национальные паспорта и ID-документы, но и заграничные удостоверения личности, миграционные карты, патенты на работу, временная регистрация. В итоге операторам в банках и HR-специалистам нужно работать с документами самых разных форматов и на десятках языков.

Чтобы закрыть этот кейс, мы научили наши ИИ-системы работать с удостоверениями личностей стран СНГ и других регионов мира. Наш ИИ распознает арабский, армянский, греческий, грузинский, иврит, китайский, корейский и японский. В сумме решение поддерживает документы более 230 стран и юрисдикций мира на 103 языках.

От покупки авто до продажи авто

Еще один тип документов, который часто требуется в ежедневных сценариях, – это водительские права и документы на транспортное средство. Для автоматического ввода данных этих документов мы добавили возможность распознавания ВУ, СТС и ПТС. Высокое качество распознавания сохраняется вне зависимости от документа и условий съемки.

Сегодня наш ИИ может распознавать даже специфические удостоверения – например, права трактористов.

Бухгалтерия

Для бухгалтерии и распознавания первички мы представили эталонную ИИ-модель, которая специализируется на финансовых, юридических, учётных и других деловых документах. Технология поддерживает более 80 шаблонов, включая УПД, акты, счета, счета-фактуры, формы ТОРГ-12 и другие документы. При этом ИИ-агент работает полностью локально, не требует интернет-соединения и GPU, а еще не сохраняет и никуда не передает данные для распознавания.

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

Вывод: паспорт — это только малая часть

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

Для решения этой задачи мы настроили автоматическое распознавание всех упомянутых в этом тексте документов – и даже больше. Сегодня наш ИИ быстро и точно распознает свыше 3 000 типов и 5 000 уникальных шаблонов документов, позволяя автоматизировать ввод данных в ключевых повседневных сценариях и исключить ошибки, задержки и раздражение.

Российский рынок распознавания документов перевалил за 3 миллиарда рублей, а выручка отечественных разработчиков таких систем растёт кратно каждый год. Почти каждый из нас сталкивается с этими технологиями ежедневно и почти не замечает их.

За этим стоит больше 20 лет разработок: от первых OCR-программ, которые только справлялись с книжными сканами, до нейросетей, читающих паспорт в полной темноте с произвольного угла съёмки. Как прошёл этот путь — разбираем по всем этапам истории.

OCR умел читать книги. С паспортом всё сломалось

OCR-программы появились ещё в 60-х, тогда первые решения использовались для оцифровки книг: система получала качественный скан с планшетного сканера и забирала текст. Для своего времени — хороший результат: одна страница обрабатывалась за десять секунд, на листе формата А5 в среднем оставалось одна-две ошибки.

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

Чтобы добраться до паспортных данных, нужны были другие алгоритмы и другой подход.

2005: кто-то наконец сделал это правильно

В 2005 году компания Cognitive Technologies, основанная Владимиром Львовичем Арлазаровым (советский и российский учёный, член-корреспондент РАН, доктор технических наук), представила первый программный продукт для распознавания паспорта РФ — Cognitive Passport. В основе лежала собственная технология компании Scanify для автоматической обработки документов на государственных бланках и сбора из них текстовых и графических данных.

Система работала на любых сканерах и закрывала реальные сценарии:

1. корректно обрабатывала документы с линиями сгиба или корешком, которые неплотно прилегали к стеклу сканера
2. распознавала текст, пересекающийся с подписями, штампами и печатями
3. считывала символы с близкой контрастностью к цветному фону гербовой бумаги
4. распознавала строку MRZ — машиночитаемую зону идентификационных документов

Отдельно расскажем про программный интерфейс API: разработчики могли встраивать систему в другие решения, в том числе СКУДы и пропускные системы. Позже возможностей ещё больше: помимо российского паспорта, система научилась работать с загранпаспортом, водительским удостоверением, военным билетом, свидетельством о регистрации транспортного средства и свидетельством обязательного пенсионного страхования.

В 2010 году Cognitive Technologies подписала соглашение о стратегическом сотрудничестве с NVIDIA. Итогом стала версия Cognitive Passport API 2.0, где часть вычислений переложили с процессора на видеокарту — это стандартный приём, когда нужно ускорить массовую обработку изображений

2013: рынок перестал быть монополией одного игрока

Вслед за Cognitive Technologies на рынок распознавания документов вышла компания ABBYY, основанная выпускником МФТИ Давидом Яном. В 2013 году она сделала ABBYY PassportReader SDK — «коробочное» решение для распознавания идентификационных документов. Система умела обрабатывать и сканировать данные из паспорта РФ, водительского удостоверения и загранпаспорта.

К началу 2010-х годов извлечение данных паспорта на базе сканера занимало всего несколько секунд. Технологии вышли за рамки лабораторий и начали работать в реальном бизнесе — логистических компаниях, гостиничных сетях, нотариальных конторах. Но именно в это время стало очевидно, что сканер как аппаратная база — тупиковая ветка для роста. Удалённые сервисы развивались быстро, привычные операции уходили в онлайн, и OCR-системы, намертво привязанные к стационарному оборудованию, этому запросу уже не отвечали.

Рынку нужно было распознавание на смартфоне.

2015: паспорт научились читать прямо со смартфона — и всё изменилось

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

Первой задачу решила компания Smart Engines, основанная Владимиром Викторовичем Арлазаровым — внуком Владимира Львовича Арлазарова, создателя Cognitive Technologies. В 2015 году они сделали Smart PassportReader (сегодня — Smart ID Engine): система распознавала третью страницу паспорта РФ с основными данными держателя на фотографиях и в видеопотоке. Точность распознавания серии и номера в первой версии — больше 99%, ФИО — выше 95%.

Главное техническое решение, которое сразу сделало продукт лучшим на рынке: всё работало локально — на телефоне, компьютере или сервере без GPU. Никакой отправки изображений в облако, никаких краудсорсинговых платформ, никакого сохранения фотографий документов, никакого интернет-соединения. Это напрямую отвечало закону «О персональных данных» (152-ФЗ).

В 2016 году решение уже использовали: Тинькофф Банк (ныне Т-Банк), Почта Банк, Альфа Банк, Газпромбанк, вся большая тройка сотовых операторов — МТС, МегаФон, Билайн — и аэропорт Шереметьево. Фактически именно с этого момента началась эпоха массовых OCR-технологий в российском бизнесе.

Углы, рукопись, все страницы и браузер: что добавили за следующие шесть лет

После 2016 года развитие ускорилось, как двигались разработчики:

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

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

Все страницы паспорта. Со временем OCR-системы научились работать с абсолютно всеми страницами российского паспорта: ИИ находит номера страниц и читает любые штампы.

Распознавание в браузере. В 2021 году распознавание паспорта впервые запустили прямо в браузере — без установки приложения, сделали это с помощью технологии WebAssembly. Банки, страховые и другие компании получили возможность перенести OCR-функциональность сразу на сайт.

Читать паспорт умеют все. Теперь нужно понять, настоящий ли он

Число подделок растёт, и для бизнеса это меняет приоритеты: уже недостаточно просто считать данные из паспорта — нужно ещё понять, не фальшивка ли это. Порог в 95%, который считался нормой ещё пять-десять лет назад, сегодня не подходит, теперь минимальный уровень — 99% и выше.

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

При тысячах таких случаев недополученная выручка становится огромной.

Следующий уровень: антифрод и мультимодальность

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

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

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

Как устроена школа

Программа ориентирована на широкую аудиторию, интересующуюся бизнесом: от студентов и идейных выпускников до действующих предпринимателей, топ-менеджеров и основателей стартапов, столкнувшихся с замедлением роста. Особое внимание будет уделяться практической работе над проектами вместе с экспертами и практиками МФТИ.

За пять недель участникам в формате мини-групп предстоит:

• Разработать бизнес-модель.
• Провести фокусировку на рынке и целевой аудитории.
• Сформулировать стратегию роста.

Подробную программу онлайн-школы можно узнать на сайте.

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

Детали программы

• Сроки обучения: 27 февраля — 27 марта 2026 года.
• Формат: Онлайн.
• Дедлайн подачи заявок: 27 февраля 2026 года (включительно). Количество мест ограничено.
  

Объём инвестиций в стартапы за первое полугодие 2025 года вырос почти на 91% по сравнению с аналогичным периодом 2024-го. При этом общее количество сделок продолжает снижаться. Это глобальный тренд — рынок консолидируется вокруг сильных игроков.

В таких условиях особенно интересно посмотреть, какие проекты оказались в фокусе внимания фондов. Список составлен на основе данных о крупнейших сделках 2025 года в российском IT. Рейтинг построен по объёму привлечённых инвестиций.

Тренды 2025: ИИ, импортозамещение и роботы

Анализ крупнейших инвестиционных раундов года выявляет три устойчивых тренда. Эти направления формируют новую карту технологического развития.

Первый и главный тренд — искусственный интеллект перестал быть отдельной категорией. Теперь это стандартный компонент, как база данных или веб-сервер. Если в 2023-2024 годах упоминание ИИ в презентации было конкурентным преимуществом, то сейчас его отсутствие вызывает вопросы у инвесторов.

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

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

Третий тренд — сращивание технологий. Чистый софт уступает место гибридным решениям. ИИ объединяется с робототехникой, чтобы алгоритмы взаимодействовали с физическим миром. Компьютерное зрение дополняется системами навигации и датчиками. Создаются комплексные продукты, в которых аппаратная часть и программное обеспечение разрабатываются совместно. Это требует больше времени и капитала, но создаёт более устойчивые бизнес-модели.

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

1. Medical Visual Systems (MVS)

Инвестиции: $12.7 млн (Раунд C+, июнь 2025)

Инвесторы: УК «Первая», РФПИ

Технология: Аппаратно-программные комплексы, ИИ, телемедицина.

Рыночная ниша: Здравоохранение

Если вам нужен пример «тяжелого» и капиталоемкого стартапа, который прошел путь от идеи до лидера рынка, — это MVS. Компания основана ещё в 2015 году, и ее история — это методичное движение к полной цифровизации операционной.

MVS создает автоматизированные комплексы для хирургии. Представьте «умную» операционную, где все оборудование связано в единую сеть. Хирургические мониторы, источники света, инструменты — всем можно управлять голосом или с единой панели. Система записывает ход операции в 4K, ведет автоматический протокол и позволяет в режиме реального времени проводить телемедицинские консультации с коллегами из других городов или стран.

Инвестиция в 12.7 млн долларов в июне 2025 года от УК «Первая» и РФПИ — это раунд для масштабирования и выхода на новые рынки. Продукт прошёл клиническую валидацию и внедрён в более чем 270 операционных в 55 клиниках разных городов России, включая федеральные центры. В условиях поддержки импортозамещения медоборудования такие комплексные российские решения получают серьёзный госзаказ. MVS продаёт не софт, а новый стандарт работы современной клиники.

2. Cognitive Pilot

Инвестиции: $8.96 млн (Раунд C+, январь 2025)

Инвесторы: Фонд «Восход»

Технология: Искусственный интеллект, компьютерное зрение, автономные системы.

Рыночная ниша: Беспилотные транспортные средства для сельского хозяйства и логистики.

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

Второй блок продуктов — системы помощи машинистам трамваев на базе ИИ, компьютерное зрение для железнодорожных переездов и маневровых локомотивов, повышающие безопасность.

Инвестиция в почти $9 млн — это pre-IPO раунд. Компания готовится к публичному размещению в горизонте 3-4 лет. По данным сайта, компания Cognitive Pilot в 2025 году вошла в мировой Топ-5 разработчиков автопилотов для сельхозтехники. Инвесторы считают, что «железный» ИИ, встроенный в реальную технику, — это устойчивый бизнес с понятной экономикой.

3. Qummy

Инвестиции: $5.59 млн (Раунд C+, июнь 2025)

Инвесторы: Консорциум (фонд «Восход», Альфа-Банк, Т-Банк)

Технология: FoodTech, умные устройства, шоковая заморозка.

Рыночная ниша: Системы автоматического питания для B2B-сегмента.

Qummy — редкий для современного российского венчурного рынка пример успешного B2C/B2B2C-стартапа в области FoodTech. Компания придумала и вывела на рынок «умную печь», которая распознает блюдо по QR-коду на упаковке и сама выставляет нужный режим приготовления.

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

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

4. Экспанта

Инвестиции: $3.7 млн (Раунд B, октябрь 2025)

Инвесторы: Фонд «Гранит капитал»

Технология: Промышленный ИИ, системы поддержки принятия решений (DSS, APC).

Рыночные ниши: Импортозамещение промышленного ПО для нефтегаза, Энергетика, Промышленные технологии

«Экспанта» — объединение российских разработчиков промышленного софта. Компания создает программные продукты для управления технологическими процессами на промышленных предприятиях. Их целевые клиенты — нефтегазовые, нефтехимические и горнодобывающие компании.

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

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

5. Dresscode.ai

Инвестиции: $3.7 млн (Seed раунд, октябрь 2025)

Инвесторы: Частные инвесторы

Технология: Генеративный ИИ, компьютерное зрение, AR.

Рыночная ниша: FashionTech

Dresscode.ai — самый молодой проект в топе, основан в августе 2024 года. Компания разрабатывает технологию виртуальной примерки одежды. При этом он сразу привлек внушительный для посевной стадии капитал. Это говорит об огромном интересе инвесторов к сочетанию ИИ и immersive-технологий (AR/VR).

Компания разрабатывает виртуальную примерочную. Пользователь загружает своё фото, а ИИ генерирует изображение в выбранном наряде. Решение можно интегрировать в виде виджета на сайт, в мобильное приложение или использовать в офлайне в виде «умного зеркала».

Крупный seed-раунд в $3.7 млн показывает высокий интерес инвесторов к генеративному ИИ в коммерции. Технология уже внедрена в ЦУМе и других ТРЦ Москвы. Для ритейлеров это инструмент снижения возвратов и увеличения среднего чека. Dresscode.ai нужно быстро перейти от пилотов к массовым внедрениям, чтобы оправдать оценку.

6. ARS Smart Robotics

Инвестиции: $3.05 млн (Раунд C+, май 2025)

Инвесторы: Частные инвесторы через платформу Rounds

Технология: Робототехника, автоматизация складов, кубическое хранение.

Рыночная ниша: Роботизированные складские системы (Robotic Mobile Fulfillment System).

Команда ARS Smart Robotics, основанная выпускниками МГТУ им. Баумана, с 2016 года занимается складской робототехникой. Их ключевой продукт — система кубического хранения SmartCube™. Это российская разработка полного цикла — от проектирования до сборки и внедрения.

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

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

Инвестиция в $3.05 млн в мае 2025 года — это pre-IPO раунд. Рынок логистической автоматизации стабильно растёт на фоне дефицита кадров и бума онлайн-торговли. Полный цикл производства в России стал для ARS конкурентным преимуществом, гарантирующим независимость от санкций и контроль над цепочкой поставок. Сейчас компания готовится к следующему этапу — публичному размещению.

7. Target AI (Cashee)

Инвестиции: 1.46 млн долларов (Seed раунд, июнь 2025)

Инвесторы: ФРИИ, фонд «Хайв»

Технология: Обработка естественного языка (NLP), речевая аналитика, LLM-агенты.

Рыночная ниша: Программное обеспечение для бизнеса

Target AI — это амбициозный проект в области речевой аналитики и LLM-агентов (Large Language Model). Их платформа предназначена для автоматизации клиентского сервиса, продаж и обучения сотрудников. Проще говоря, они создают ИИ-агентов, которые могут вести диалог с клиентом, решая его проблему или продавая продукт.

Seed-раунд в S1.46 млн от ФРИИ и фонда «Хайв» — это старт для амбициозной команды. Важно, что ранее, в ноябре 2023 года, в проект уже крупно инвестировал «ВымпелКом» (Билайн). Интерес стратегического инвестора из телекома подтверждает востребованность технологии.

Компания стала одним из заметных проектов, использующих российскую языковую модель GigaChat. На конференции Moscow Startup Summit их платформа была отмечена как лучшее решение на этой технологии. Инвесторы верят, что за LLM-агентами будущее клиентских коммуникаций, и стремятся занять место в этом тренде на раннем этапе.

8. SenseMachine

Инвестиции: 1.27 млн долларов (Раунд A, июнь 2025)

Инвесторы: Фонд «Восход», «Хайв»

Технология: Компьютерное зрение, нейромаркетинг, айтрекинг.

Рыночная ниша: Реклама и маркетинг

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

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

9. Platformeco

Инвестиции: 1.25 млн долларов (Раунд A, август 2025)

Инвесторы: KAMA FLOW

Технология: Интеграционная платформа, оркестрация данных, API-менеджмент.

Рыночная ниша: Импортозамещение корпоративных интеграционных решений (аналог MuleSoft, Apache Camel).

Platformeco решает проблему интеграционного хаоса в крупных компаниях. После ухода зарубежных вендоров IT-ландшафт многих предприятий превратился в набор несовместимых систем. Platformeco создаёт единую платформу для оркестрации всех бизнес-процессов, данных, микросервисов и API.

Раунд A от отраслевого фонда KAMA FLOW — инвестиция в базовую инфраструктурную потребность. Без таких решений цифровая трансформация крупного бизнеса останавливается. Стартап занимает сложную, но важную нишу, создавая технологический фундамент для развития.

10. OneCell

Инвестиции: 1.08 млн долларов (Раунд A, февраль 2025)

Инвесторы: Агентство инноваций города Москвы (АИС)

Технология: Искусственный интеллект в медицине, анализ медицинских изображений.

Рыночная ниша: Здравоохранение

OneCell разрабатывает систему на основе ИИ для помощи врачам-онкологам. Платформа анализирует комплексные медицинские данные: гистологические снимки, результаты КТ и МРТ, геномную информацию. Алгоритм помогает в ранней диагностике и планировании лечения.

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

Итоги: деньги идут за конкретным результатом

Инвестиционный ландшафт 2025 года сформировали три силы: осторожность инвесторов, запрос на технологический суверенитет и прагматичный подход к ИИ.

Деньги концентрируются в «взрослых» стартапах на стадиях Расширение (Expansion) и Рост (Growth). Фонды поддерживают проекты, которые уже имеют продукт, первых клиентов и доказанную экономику. Бизнес-модель B2B доминирует безраздельно.

Искусственный интеллект стал обязательным элементом, но в роли инструмента, а не цели. Ценность создают не сами алгоритмы, а их применение в промышленности, медицине, логистике. Интеграция ИИ с робототехникой и другим «железом» создаёт более высокие барьеры для конкурентов.

2026 год, вероятно, станет годом консолидации. Крупные игроки, вроде компаний из топ-5 рейтинга выручки (Яндекс, Сбер, VK и др.), которые генерируют 95% доходов на рынке ИИ, будут активно присматриваться к таким самостоятельным технологическим командам для поглощений. Цель — интеграция передовых разработок в свои экосистемы.

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

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

Кому ИИ ближе всего по задачам

Исследование основано на анализе более 200 000 реальных сессий использования Copilot. Также эксперты сопоставили то, с чем ИИ справляется лучше всего, и задачи конкретных профессий.

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

Туда же попали менеджеры по продажам и сотрудники поддержки клиентов. В США это около 5 млн рабочих мест. Более того — именно здесь компании уже активно экспериментируют с автоматизацией, чат-ботами и ИИ-ассистентами.

Microsoft подчеркивает: высокий показатель применимости ИИ не означает автоматического исчезновения профессии. Но на практике работодатели все чаще замораживают найм или сокращают команды, рассчитывая «закрыть» часть задач за счет ИИ.

Высшее образование больше не защита

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

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

Кого ИИ почти не трогает

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

Это не значит, что автоматизация их не коснется вообще, но именно LLM здесь пока бесполезны.