Как мы строим процессы: взгляд на разработку от команды Embedika

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

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

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

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

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

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

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

В следующих материалах покажем, как эти принципы реализуются в конкретных инструментах и практиках фронтенд-команды Embedika.

Влияние фронтенд-разработчиков на проект: от постановки задачи до интерфейсных решений

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

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

Какие задачи поступают фронтенд-команде, кто их ставит и где проходит граница ответственности разработчика — разбираемся ниже.

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

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

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

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

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

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

Первый квартал 2026-го: регулирование, агенты и оценка реальных результатов от инвестиций в ИИ

Проанализировали и собрали для «РБК Трендов» ключевые события первых трех месяцев этого года.

🔗 Полная версия доступна на сайте РБК Тренды

Как фронтенд влияет на проект и как выстроены процессы в команде Embedika

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

Процесс работы фронтенд-разработчика над задачей состоит из нескольких этапов:

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

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

3️⃣ Код-ревью. Обязательный этап перед попаданием кода в общее хранилище. Один-два фронтендера проверяют корректность решения, отмечают возможные проблемы и следят за соблюдением принятых в команде правил оформления кода.

4️⃣ Передача в тестирование. Если тестировщики выявляют проблемы, задача возвращается на доработку. Если замечаний нет — переходит в статус готовности к релизу.

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

Agent ready — новый стандарт или необходимость для онлайн-торговли?

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

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

В 2026 году ИИ платформы продолжают становиться полноценным каналом продаж, а не просто поиском с чатом. EMarketer прогнозирует, что только в США объем ecom продаж через ИИ платформы превысит 20 млрд долларов в 2026 и вырастет до 144 млрд к 2029 году. В прошлом году индустрия начала договариваться об общем языке для агентов: появляются открытые протоколы вроде Universal Commerce Protocol и Agentic Commerce Protocol, которые стандартизируют, как агенту посмотреть каталог, собрать корзину, посчитать налоги, оформить оплату и отследить доставку.

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

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

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

Чтобы не отстать в этой новой гонке стоит посмотреть на свой сайт и ответить на вопросы:
▪️ Можем ли мы описать наш каталог, стоки, цены и доставку в виде чистых, стабильных API, понятных любому внешнему агенту?
▪️ Можем ли мы отдавать бизнес правила (скидки, промо, ограничения по регионам) в четком и понятном виде?
▪️ Есть ли в дорожной карте отдельный пункт — быть agent ready?
▪️ Готова ли команда жить в мире, где JSON становится главным интерфейсом к вашему магазину?

Больше интересных новостей об ИИ, рителе, екоме и маркетплейсах 👉 Подписаться на канал

Принципы построения интерфейсов и негативные практики фронтенд-разработки

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

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

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

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

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

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

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

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

Как фронтенд-разработчик взаимодействует с командой и участвует в создании интерфейса

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

Взаимодействие с аналитиками и тестировщиками

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

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

Работа с дизайнерами и влияние на финальный интерфейс

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

Как происходит передача результатов работы

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

Если замечаний нет — задача переходит в статус «Готово» и ожидает выпуска релиза для передачи конечному заказчику. Если проблемы обнаружены — задача возвращается на доработку и проходит весь цикл заново.

Дайджест событий в области искусственного интеллекта

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

В России:
☁️ Сбербанк создаст группу компаний «Сбер2В»: под новым брендом объединят нефинансовые ИТ-продукты, включая облачные и ИИ-решения для корпоративных клиентов.
📊 Правительство РФ установило для ведомств KPI по внедрению ИИ, теперь у госорганов есть конкретные нормативы, стимулирующие использование нейросетей в работе.
🧠 «Сбер» и НИУ ВШЭ представили метрику Persistence: новая технология позволяет оценивать качество эмбеддингов без участия человека и предразмеченных датасетов, помогая точнее выбирать архитектуру модели и момент остановки обучения.
🚀 «Ростелеком» запустил акселератор ИИ-решений: программа нацелена на поиск и поддержку перспективных российских стартапов.

В мире:
💬 OpenAI анонсировала Workspace Agents в ChatGPT: функция позволяет командам создавать общих ИИ-агентов для совместной работы прямо в интерфейсе чата.
🦾 Siemens представил Eigen Engineering Agent — специализированного ИИ-агента для решения задач промышленной автоматизации.
📋 DeepSeek регистрирует товарный знак в России: китайский вендор планирует официально продавать ПО и предоставлять услуги анализа данных на российском рынке.
📓 Google добавила в Gemini инструмент Notebooks, он позволяет формировать и структурировать базу знаний на основе истории взаимодействий с моделью.

Аналитика:
📈 Servicepipe фиксирует троекратный рост спроса на ИИ-агентов. По итогам первого квартала 2026 года обращения бизнеса на услуги настройки агентов выросли в 3 раза.
💰 HeadHunter и ГК «Солар» выяснили, что использование больших языковых моделей в закрытом контуре сокращает годовой ФОТ команд AppSec на 20–50% в зависимости от масштаба разработки.

#дайджест

CEO Embedika о главном условии ускоренного внедрения ИИ в России

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

Делимся ключевыми мыслями из статьи:

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

🔗 Подробнее — в материале CNews.

#сми_о_нас

Как устроена бэкенд-разработка в Embedika: роли, стек и этап подключения к проекту

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

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

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

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

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