Как аналитики Форсофт за 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-минутного звонка со стейкхолдерами занимал у аналитика два часа. С 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% переделок).

Бизнес-цели. Точность оценки (разница между фактом и планом — не более ±15%). Индекс лояльности клиента на этапе аналитики (цель — выше 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 недель) с вайрфреймами, бэклогом пользовательских историй, наброском архитектуры и обоснованной оценкой. Результаты остаются у вас. Многие клиенты возвращаются за разработкой, увидев качество работы на этапе дискавери; некоторые — нет, и это нормально.

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

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

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

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