Команда разработки Фора Софт: стек, агентный инжиниринг и что нужно, чтобы вывести продукт

Зачем Фора Софт написала эту статью

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

Фора Софт за 20 лет выпустила 625+ продуктов — видео, AI, телемедицина, e-learning, видеонаблюдение, финтех. Реальные кейсы: V.A.L.T. (770+ организаций, 2 000+ IP-камер), BrainCert (500 млн+ минут эфира), Tradecaster. Инженерные паттерны, описанные ниже, — это и есть то, что позволяет держать такой темп выпуска при команде, выстроенной вокруг мастерства, а не имитации численности.

Как устроена инженерная команда

На каждом проекте есть техлид (сеньор, отвечает за архитектуру и проверку кода), основная команда разработки (мидлы и сеньоры, 2–6 человек в зависимости от объёма) и доменные специалисты на подхвате (WebRTC, ML/AI, платежи, видеостриминг). Над техлидом — руководитель инженерного подразделения: распределяет ресурсы, развивает мастерство в команде и эскалирует кросс-проектные решения по железу и облаку.

Мы намеренно держим высокую долю сеньоров. У большинства наших инженеров 5–12+ лет в релевантной области. Джунов берём только в структурированной модели наставничества под лидом, никогда — основными исполнителями на клиентских задачах. Так мы держим короткие циклы проверки кода и низкий уровень дефектов.

На каких стеках мы работаем — и почему выбираем именно их

Мы расскажем о компромиссах, которые видим, прежде чем дадим вам выбрать. Принцип «используй то, что знаешь» обычно выигрывает по сопровождаемости. Но для real-time видео, аудио и тяжёлых ML-бэкендов выбор стека напрямую влияет на производительность.

Наш инженерный процесс, спринт за спринтом

Спринт 0 — техническая архитектура (1 неделя). Техлид превращает результаты работы аналитика в архитектурные эскизы, ADR, контракты API, инфраструктурный план и стратегию тестирования. Инженеры читают, вопросы попадают в бэклог первого спринта.

Спринты 1–N — разработка (двухнедельные спринты). Берём задачи, ведём разработку через PR, CI должен быть зелёным, ежедневные асинхронные стендапы. Каждый PR проходит через как минимум одного старшего ревьюера и автоматические проверки (типы, тесты, линт, безопасность).

Еженедельный бюджет на технический долг. 10–15% каждого спринта мы резервируем на выплату долга — рефакторинги, обновление зависимостей, латание тестов. Пропуск этой работы — причина №1, по которой проекты замедляются на третьем месяце.

Предзапусковая стабилизация (1–2 недели). Нагрузочные тесты, аудит безопасности, проверка доступности, хаос-сценарии. Финальное согласование закрывает наша команда тестирования.

Постзапусковый SRE-цикл. Наблюдаемость остаётся включённой, еженедельные ревью надёжности, ежемесячный пересмотр дорожной карты. После релиза мы не исчезаем; большинство клиентов остаётся с нами на сопровождении.

Рис. 1. Инженерный ритм по фазам: спринт 0, разработка, стабилизация, постзапуск.

Качество кода: что это значит на практике

1. Строгие типы на границах. Strict-режим в TypeScript, строгий pyright в Python, дженерики там, где они отсекают целый класс багов. Валидация во время выполнения на входах (Zod, Pydantic), чтобы клиенты API не могли пропихнуть некорректные данные.

2. Тесты как полноправные участники. Юнит-тесты на логику, интеграционные на контракты, end-to-end на критические пользовательские сценарии. Пороги покрытия включены в CI (обычно 70%+ юнит, 80%+ на критических путях). Без порогов покрытие деградирует.

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

4. Записи архитектурных решений (ADR). Любой нетривиальный архитектурный выбор фиксируем в коротком markdown-файле ADR (контекст, решение, последствия). Через полгода, когда кто-то спросит «почему мы выбрали X?», ответ лежит в репозитории.

5. Наблюдаемость с первого дня. Структурированные логи, трассировка и метрики появляются с первого спринта, а не докручиваются потом. «У нас работает на стейджинге» — не сертификат.

Агентный инжиниринг — как мы выпускаем быстрее, не срезая углы

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

1. Генерация по спецификации. Спецификации аналитика подаются агентам, которые набрасывают каркас, типы, границы сервисов и тесты. Инженеры дорабатывают черновик, а не начинают с нуля.

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

3. Ассистент проверки кода. Агенты подсвечивают очевидные регрессии, пропущенные null-проверки и анти-паттерны безопасности до того, как код попадёт к человеку-ревьюеру. Человек концентрируется на проектировании и замысле.

4. Генерация документации. Документация API, заготовки README, архитектурные сводки — всё это собирается из кода и ADR. Поддерживающая документация остаётся актуальной, что в индустрии большая редкость.

Эффект на сроки: типовые шестимесячные проекты у нас доходят до первого продакшена за 10–14 недель. Поэтому наши оценки выигрывают у конкурентов и по цене, и по срокам — не потому, что мы пропускаем шаги, а потому, что агент сжимает рутину.

Мини-кейс: аудио в реальном времени в V.A.L.T. — победы, которые не подделаешь

Один из наших долгих проектов, V.A.L.T., потребовал новой функции Talkback — двусторонней аудиосвязи из веб-браузера до IP-камер по парку устройств, в который входили и старые, ресурсоограниченные модели. Задержка на горячем пути должна была оставаться ниже 300 мс; аудио требовало ресемплинга, нормализации кодирования и шумоподавления; камерам без нативной поддержки WebRTC нужна была прослойка-шим.

Что было выпущено: переписанный пайплайн захвата аудио на фронтенде, серверный аудиопроцессор с ресемплингом и шумоподавлением, бэкенд-доработки для совместимости с камерами и — как побочный проект — миграция на Vite, которая сократила время сборки фронтенда у команды примерно с 15 минут до ~25 секунд. Итог: рабочий Talkback на всём парке камер клиента и измеримый прирост продуктивности на каждой следующей фиче, потому что сборка перестала быть бутылочным горлышком. История с Vite — это типичная «невидимая» победа, которая отделяет инженеров, которым важно качество, от тех, кому всё равно.

Инженерия надёжности: скучные, но важные вещи

1. SLO раньше фич. Цели по доступности, задержке и уровню ошибок согласуем с клиентом; дашборды и алерты подключаем до первого пользователя.

2. Безвинные постмортемы. На каждый инцидент — разбор по методу «5 почему» и список действий. Пункты попадают в бэклог с владельцем и сроком.

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

4. Аудит безопасности. Модель угроз во время архитектурного этапа; OWASP Top-10 проверяется в CI; пентест перед продакшеном для любого продукта с авторизацией и чувствительными данными.

5. Учения по аварийному восстановлению. Раз в квартал на продуктах, у которых есть пользователи в продакшене. RTO/RPO задокументированы и протестированы — а не просто записаны в Confluence.

Облако, инфраструктура и стек доставки

Хостинг. AWS, GCP, Azure — работаем со всеми тремя. Для бюджетных видеонагрузок дополнительно используем серверы Hetzner серии AX и DigitalOcean. Cloudflare — для edge и CDN.

Оркестрация. Kubernetes для мультисервисных приложений, Nomad для более простых стеков, ECS/Fargate для команд, живущих в AWS. Используем то, что сможет эксплуатировать команда клиента.

CI/CD. GitHub Actions, GitLab CI, Buildkite. Blue-green или канареечные деплои на любых продакшен-системах с реальными пользователями.

Наблюдаемость. Datadog, Grafana + Prometheus, OpenTelemetry. Структурированные логи в Loki или CloudWatch. Алерты в PagerDuty или Opsgenie.

Данные. Postgres по умолчанию; Redis для кэша; Kafka и NATS для шин событий; ClickHouse или Snowflake для аналитических нагрузок.

Сколько на самом деле стоит разработка

Три реалистичных формата на 2026 год, основанных на наших последних проектах:

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

Как принять решение — когда нанимать инженеров Фора Софт

В1. Сложность продукта связана с real-time, AI или регулируемыми системами? Если да — мы хорошо подходим: наш 20-летний портфель сосредоточен именно там.

В2. Нужны инженеры, способные принимать архитектурные решения, а не только исполнять? Если да — именно так мы и комплектуем команды. Наши сеньоры наняты за инженерное суждение, а не за пропускную способность по задачам.

В3. Хотите команду, которая останется после релиза? Большинство наших клиентов остаются с нами на сопровождении и развитии. Мы строим вдолгую.

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

В5. Бюджет проекта от 3 млн ₽? Если меньше — возможно, мы порекомендуем партнёра поменьше: лучше отдать его рекомендацию, чем взять контракт, который нам не подходит.

Пять инженерных ловушек на спасательных проектах

1. Всё в одном большом сервисе. Монолит на 50 тысяч строк без модульных границ губит проект с пятого спринта. Рефакторите рано.

2. Никакой типизации. Чисто динамический JavaScript или нетипизированный Python съедают скорость поставки к третьему месяцу. Типы окупают себя.

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

4. Игнорирование бюджета на технический долг. Без постоянных 10–15% на спринт долг копится, а скорость падает вдвое.

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

KPI, по которым мы оцениваем инженерную команду

KPI качества. Доля дефектов, доходящих до продакшена (<3 на 10 тыс. строк кода). Среднее время обнаружения инцидента (<5 минут). Среднее время восстановления (<30 минут для SEV-2, <4 часов для SEV-1). Доля откатов после деплоя (<5%).

KPI скорости. Время от открытия PR до его слияния (<2 дней). Частота деплоев (несколько раз в день на зрелых проектах). Lead time на изменение (часы, не недели).

KPI стоимости. Отклонение оценки от факта (потолок ±15% на фикс-цене). Тренд расходов на облако в пересчёте на DAU (должен снижаться после оптимизации). Удержание инженеров (>90% годовых).

Когда инженеры Фора Софт вам не нужны

Если ваш продукт — простое CRUD-приложение без real-time, AI или стриминговой части и у вас уже есть сильная команда, мы, скорее всего, избыточны. Если нужен один подрядчик, который быстро правит легаси на PHP, фрилансер подойдёт лучше нашей модели поставки.

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

Модель выделенной команды — когда это правильный паттерн

Для клиентов с постоянной продуктовой разработкой мы предлагаем модель выделенной команды — именованных инженеров, которые работают как продолжение вашей организации месяцами и годами. Мы вели команды по 3–10 человек на одних и тех же клиентов непрерывно по 5+ лет. Эта модель работает, когда дорожная карта непрерывна и вы хотите, чтобы продуктовую память хранили одни и те же сеньоры.

Как мы работаем с вашей командой

Ваши инструменты. Jira, Slack, GitHub/GitLab, Linear, Notion, Confluence, PagerDuty — встраиваемся в то, на чём живёт ваша компания. Наши инженеры приходят на ваши стендапы и ретро.

Часовые пояса. Мы охватываем Европу и регион MENA: значимое пересечение с утром Северной Америки и европейским рабочим днём. Асинхронный формат там, где можно, синхронный — там, где нужно принимать решения.

Безопасность и комплаенс. NDA и MSA до получения доступа к коду. У нас выстроены внутренние контроли, согласованные с SOC 2; мы можем подписывать BAA для проектов под HIPAA. Ограничения по резидентности данных учитываем на уровне деплоя.

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

Несколько слов о культуре

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

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

FAQ

Можно познакомиться с инженерами до подписания контракта?

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

Кому принадлежит код?

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

Вы работаете по фикс-цене или time-and-materials?

И так, и так. Фикс — после скоупинга, когда объём работ достаточно ограничен, чтобы цифру можно было защитить. T&M — когда продукт исследовательский. Мы не закроем вас в фикс на неопределённый объём — это плохо для обеих сторон.

Как вы работаете с изменением скоупа в середине проекта?

Наш аналитик ведёт процесс изменений: оценка влияния, обновлённый план, обновлённая оценка, согласование. Мелкие правки укладываются в буфер, крупные оформляются как change orders. Ничего не проскакивает под видом «просто доработки».

Можете подключиться к существующему коду или предпочитаете greenfield?

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

Подписываете ли вы HIPAA BAA, SOC 2 DPA, GDPR DPA?

Да на все три. Мы выпускали HIPAA-совместимые сценарии для медицинского обучения, согласовываем внутренние контроли с SOC 2 для корпоративных заказчиков, разворачиваем системы с EU-резидентностью под GDPR DPA.

Как агентный инжиниринг влияет на стоимость?

Чистый эффект: на 20–40% меньше календарного времени и на 10–25% ниже стоимость на типовых проектах. Экономия не за счёт сокращения людей, а за счёт того, что сеньоры тратят меньше времени на рутинный код.

Беретесь ли вы за работу рядом с железом и embedded-проекты?

Да — мы выпускали проекты на Jetson Orin (edge AI), интеграции домофонов и камер, ONVIF-видеонаблюдение, кастомные аудиопайплайны. Прошивки — не наш основной профиль, но edge-смежная работа — типовой формат сотрудничества.

Что почитать дальше

Готовы нанять инженеров, которые отрабатывают своё место?

Инженерия в Фора Софт — это мастерство плюс дисциплина плюс эффект сложного процента от агентных воркфлоу. Мы выпускаем надёжные, наблюдаемые и сопровождаемые системы в тех областях, где это критично, — видео, AI, телемедицина, видеонаблюдение, финтех. Берём сеньоров, проверяем каждый PR, закладываем доступность и комплаенс с первого дня и остаёмся на проекте после релиза. Так мы работаем уже 20 лет.

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