Внутри аналитической команды Фора Софт: 20 лет превращения хаоса в готовые продукты

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

Это взгляд изнутри на то, как работает наша команда аналитики. Скучная правда о софтверных проектах в том, что команда, которая занимается дискавери и анализом, важна как минимум не меньше, чем команда, которая пишет код. Фора Софт за 20 лет запустила более 625 проектов в видео, ИИ, телемедицине, e-learning и видеонаблюдении (см. наши флагманские кейсы вроде BrainCert и V.A.L.T.). Почти ни один из этих проектов не уложился бы в скоуп без аналитиков, которые ловили нюансы до старта реализации.

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

Чем именно занимаются наши аналитики на вашем проекте

«Бизнес-аналитик» — широкое название должности. В нашей практике за ним стоит конкретный набор результатов, которые появляются на каждом проекте, независимо от отрасли.

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

2. Сбор и приоритизация требований. Пользовательские истории, критерии приёмки, крайние случаи (edge cases), нефункциональные требования (задержки, время доступности, соответствие нормативке). Приоритизируем по MoSCoW или RICE, чтобы дорожная карта строилась на ценности, а не на списке желаний.

3. Визуализация. Сначала вайрфреймы в Visily (в 2× быстрее, чем рисовать с нуля) и интерактивные прототипы в Axure RP; диаграммы процессов в Whimsical/Miro; диаграммы потоков данных и последовательностей в Mermaid или Lucidchart. Подробнее — в наших материалах об ИИ-инструментах для вайрфреймов и о вайрфреймах в разработке ПО.

4. Технический перевод. Наши аналитики говорят на двух языках — API, архитектура, допустимые задержки, — так что инженер получает однозначное задание, что именно строить.

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

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

7. Защита пользователя. Когда бизнес-цели сталкиваются с удобством использования, аналитик задаёт вопрос: «это удобно? решает ли это проблему пользователя?» Эту роль больше никто в команде надёжно не берёт.

Наш процесс аналитики, этап за этапом

У нас четыре аналитические фазы, которые обрамляют инженерную работу.

Фаза 1 — Дискавери (1–2 недели). Интервью со стейкхолдерами, разбор конкурентов, черновики пользовательских сценариев, проверка реализуемости стека, список допущений. Результат: формулировка проблемы, шорт-лист подходов к решению, реестр рисков.

Фаза 2 — Скоупинг (1–3 недели). Низкодетализированные вайрфреймы в Visily, карта пользовательских историй, матрица приоритетов, оценочные диапазоны вместе с инженерами. Результат: черновая дорожная карта, граница MVP и обоснованная оценка. Подробнее об этом этапе — в нашем материале о персонализированном процессе планирования.

Фаза 3 — Детальный дизайн (2–4 недели). Высокодетализированные вайрфреймы в Axure, спецификации взаимодействий, диаграммы потоков данных, наброски контрактов API. Параллельно подключаются инженеры и начинают сборку. Результат: документация, по которой команда реально доставляет продукт.

Фаза 4 — Сопровождение в полёте (постоянно). Каждый спринт аналитик уточняет крайние случаи, дорабатывает следующие истории и поддерживает документацию в актуальном состоянии. После запуска он подаёт пользовательские данные и аналитику обратно в дорожную карту.

Рисунок 1. Четыре аналитические фазы, которые обрамляют каждый проект Фора Софт.

Инструменты и стек, которыми пользуются аналитики

Мы не навязываем инструмент — мы требуем результат. Но вот стек, который для большинства проектов даёт самое короткое время до ясности.

Как ИИ изменил наш процесс аналитики

Мы не заменяем аналитиков ИИ. Мы даём им мощный инструмент. Что измеримо изменилось:

1. Резюмирование звонков и извлечение задач. 90-минутный звонок со стейкхолдерами раньше требовал 2 часов письменного разбора. С LLM это 15 минут, и аналитик не печатает, а проверяет факты.

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

3. Стресс-тест требований. Скармливаем черновик пользовательской истории LLM с вопросом «чего не хватает?» — и ловим 60–80% крайних случаев, которые раньше всплывали только на ревью-встречах.

4. Конкурентный разбор. С помощью LLM делаем разборы 5–10 конкурентов за утро, а не за неделю.

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

Десять принципов, по которым живут наши аналитики

1. Учитесь слышать, а не просто слушать. Клиенты описывают решения; ваша задача — раскопать настоящую проблему.

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

3. Структурируйте хаос. Превращайте запутанные идеи в пользовательские истории, диаграммы и логику.

4. Думайте сценариями. Не «что умеет система», а «что произойдёт, когда пользователь сделает X».

5. Будьте технически грамотны. Вы не пишете код, но понимаете API, архитектуру и ограничения.

6. Пишите ясно. Клиенты узнают свою идею; разработчики понимают, что именно строить.

7. Не бойтесь конфликта. Неудобные вопросы на старте лучше болезненных правок в конце.

8. Защищайте пользователя. Когда бизнес-цели заглушают удобство, возражайте.

9. Визуализируйте всё. Вайрфреймы, карты, диаграммы — и сложное становится простым.

10. Управляйте ожиданиями. Все хотят всё и сразу; ваша задача — показать реалистичный путь.

Что вы получаете в первые три недели

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

Мини-кейс: как аналитика спасла квартал на десятки миллионов

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

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

Тот же сюжет мы видели и в наших самых крупных проектах: BrainCert с более чем 500 млн доставленных минут, V.A.L.T. с более чем 770 организациями, Tradecaster со сложными процессами живой биржевой торговли. Ни один из них не совпадает с тем, с чем клиент пришёл изначально. Задача аналитика — помочь рано найти лучший вариант.

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

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

У нас никто не «просто записывает протоколы». Каждый аналитик отвечает за результат проекта и имеет полномочия возражать как клиентам, так и инженерам, если что-то не сходится.

Как получить максимум от работы с нашими аналитиками

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

2. Подключите стейкхолдеров. Лицо, принимающее решение, плюс предметный эксперт в одной комнате стоят пяти раундов почтовой переписки.

3. Расскажите, что вы уже пробовали. Неудачные подрядчики, внутренние прототипы, конкуренты-вдохновители — аналитик быстро встроит этот контекст.

4. Будьте честны об ограничениях. Бюджет, сроки, нормативка, легаси-системы. Скрытые ограничения всё равно всплывут; чем раньше, тем лучше.

5. Дайте нам с вами поспорить. Если вопрос вызывает дискомфорт, скорее всего, это правильный вопрос. Наша работа — не кивать.

Фреймворк решения — нужен ли вам аналитик в проекте

В1. Запускали ли вы раньше продукты такого типа? Если нет — аналитик нужен.

В2. Есть ли у вас более двух стейкхолдеров с разными критериями успеха? Если да — аналитик нужен.

В3. Есть ли регуляторные риски или требования к соответствию нормативке? Если да — нужен сеньор-аналитик.

В4. Оценка ниже 2 млн ₽, и в скоупе одна хорошо понятная функция? Можно обойтись — но держите аналитика на связи для полудневного ревью.

В5. Будет ли продукт развиваться больше шести месяцев? Если да — аналитик должен оставаться на проекте до релиза, а не только на старте.

Пять ошибок, которые убивают ценность аналитика

1. Считать аналитику одноразовой фазой. Клиенты, которые хотят «скорее давайте к коду», тратят бюджет на аналитика, не получая взамен ясности.

2. Ставить джуниор-аналитика на сложный продукт. Сложная предметная область и джуниор — плохая пара: он пропустит важные ограничения.

3. Хранить документацию только в голове аналитика. Если этого нет в Notion или Confluence — этого не существует.

4. Отделять аналитику от инженерии. Аналитик, не сидящий на спринт-ревью, быстро теряет контекст и превращается в писаря, а не в партнёра.

5. Пропускать защиту пользователя. Если аналитик ни разу не сказал «пользователь так делать не будет» — он не выполняет половину своей работы.

KPI, по которым мы оцениваем нашу аналитическую команду

KPI качества. Доля изменений требований после реализации (цель <10%). Доля дефектов по историям, написанным аналитиком (цель <5% переделок).

Бизнес-KPI. Точность оценки (факт vs. план в пределах ±15%). NPS клиента по этапу аналитики (цель >50). Доля проектов, попавших в дедлайн MVP (цель >90%).

KPI развития. Рост производительности аналитика год к году (цель 20%+ за счёт ИИ-инструментов). Удержание сеньор-аналитиков (цель >90% в год).

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

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

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

Агентная инженерия + аналитика = более быстрые проекты

Наши аналитики передают свои результаты прямо в наш конвейер агентной инженерии (spec-driven agent engineering). Чёткие истории становятся качественными промптами для агентов; вайрфреймы — тестируемыми критериями приёмки; диаграммы — архитектурным каркасом. Стык аналитик–инженер сейчас даёт самый высокий ROI среди всей автоматизации, которую мы делали.

Практический эффект: проекты, которые занимали 20 недель, укладываются в 12–14. Время аналитика возвращается как более быстрая доставка, а не как бюджет на новую печатную работу. Поэтому наши оценки бьют конкурентов и по цене, и по срокам — не потому что мы торопимся с аналитикой, а потому что вшили её в движок.

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

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

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

Куда мы развиваем практику дальше

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

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

3. Отраслевые плейбуки. Видео, интерпретация ИИ, телемедицина, e-learning — для каждой области свой структурированный плейбук старта, чтобы аналитика шла быстрее, не теряя глубины.

FAQ

Аналитика оплачивается отдельно?

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

Можно ли привести своего продакт-менеджера и всё равно нанять Фора Софт?

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

А если у нас уже есть дизайны в Figma?

Отлично — аналитик сверит их с формулировкой проблемы и подсветит пробелы (крайние случаи, альтернативные сценарии, пустые состояния, флоу ошибок). Figma — это дизайн-артефакт; мы добавляем поверх неё аналитический слой, чтобы команда разработки понимала, что с ним делать.

Подписываете ли вы NDA и работаете ли в наших инструментах (Jira, Slack, Confluence)?

Да и да. NDA — стандарт перед любой скоупинг-работой. Наши аналитики сидят в вашей Jira, Slack, Confluence, Linear, Notion — в том, на чём работает ваша команда. Контекст остаётся там, где вы его сможете найти после того, как мы передадим дела.

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

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

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

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

Остаются ли ваши аналитики на проекте после запуска?

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

Можно нанять только этап аналитики и забрать результаты в другую команду?

Да. Мы делаем отдельные скоупинг-проекты (2–6 недель) с вайрфреймами, бэклогом пользовательских историй, наброском архитектуры и обоснованной оценкой. Результаты ваши. Многие клиенты возвращаются за разработкой, увидев качество дискавери; некоторые — нет, и это нормально.

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

Готовы к аналитику, который оправдывает своё место в проекте?

Аналитика в Фора Софт — не фаза, а позвоночник проекта. Наши аналитики превращают сырые идеи в готовое ПО: задают сложные вопросы на старте, всё визуализируют и остаются в команде до релиза. Это вы и покупаете, нанимая нас, — мышление наравне с кодом.

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