Разработчики и бизнес часто как будто говорят на разных языках. Для бизнеса важны процессы, деньги и удобство работы людей. Для разработчиков — функции, таблицы, API и код. Без человека‑«переводчика» между этими мирами задачи и ожидания легко расходятся, а проекты вылезают за сроки и бюджет.

Как выглядит непонимание на практике
Бизнес говорит: «Нужно ускорить обработку заказов». В голове у руководителя — понятная картинка: сейчас от заявки до отгрузки проходит 3 дня, надо сделать так, чтобы клиент получал товар за 4 часа за счёт автоматических уведомлений, понятных статусов и нормальной связи со складом и логистикой.
Разработчик слышит: «ускорить» и «заказы» — и делает, например, быстрый поиск заказов в базе или ускоряет работу формы. Поиск действительно начинает работать быстрее, но узкие места в согласованиях, оплате и логистике никто не трогает. Для бизнеса ничего по сути не поменялось: клиент как ждал 3 дня, так и ждёт, хотя «что‑то же внедрили».

Примеры из CRM и продаж
В CRM‑проектах это особенно заметно.
·Бизнес формулирует задачу: «Хотим лучше управлять продажами». Внутренне это означает: нужен дашборд, где руководитель видит планы/факт, воронку, просроченные задачи по клиентам, эффективность менеджеров по регионам.
·Разработчики делают отчёт по данным из 1С/CRM: большая таблица с кучей строк и колонок, без нормальных фильтров и понятных визуализаций. Формально «отчёт есть», по факту — руководитель им не пользуется, менеджерам он не помогает, продажи не меняются.
Другой типичный случай: «Нужна интеграция с Bitrix24».
Бизнес подразумевает, что лиды и сделки должны нормально перетекать между CRM и 1С: статусы обновляются, задачи менеджерам ставятся автоматически, видно всю историю общения с клиентом.
Команда делает однократный или примитивный обмен контактами: выгрузили телефоны и e‑mail, но потеряли историю взаимодействий, статусы и задачи. Формально интеграция есть, по сути — это почти бесполезный экспорт.

Почему это вообще происходит
Корень проблемы — разные фокусы мышления:
·Бизнес мыслит языком процессов и результата:

• «Клиент должен получить товар в срок»,
• «Менеджер должен видеть свои задачи и план»,
• «Хочу увеличение прибыли и снижение ручной работы».

·Разработчики мыслят языком функций, процедур и технологий:

• «сделать поиск»,
• «настроить обмен»,
• «добавить кнопку»,
• «написать API».

Если между ними нет аналитика, никто не переводит бизнес‑цель в понятные для разработки истории и сценарии. В ТЗ попадают разрозненные пожелания («нужен отчёт», «сделать интеграцию»), но не описано:

• кто именно этим будет пользоваться;
• в какой ситуации;
• как выглядит «успех» для бизнеса;
• по каким критериям задача считается выполненной.

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

Зачем здесь аналитик и что он делает
Роль аналитика — как раз быть «двуязычным» между бизнесом и разработкой.
Он:

• разговаривает с руководителями и пользователями на их языке: спрашивает про процессы, боли, деньги, а не про «какие кнопки добавить»;
• описывает сценарии работы (как должно происходить от заявки до отгрузки, от лида до сделки, от заказа до оплаты) — в схемах и простых текстах;
• переводит это в понятные для разработчиков требования: user stories, диаграммы, ТЗ, критерии приёмки («заказ считается обработанным, если…»);
• заранее продумывает риски и узкие места — что может пойти не так, где пользователи запутаются, что вызовет сопротивление.

Инструменты — BPMN, ArchiMate, прототипы интерфейсов, интервью с пользователями — нужны не ради «красивых схем», а чтобы:

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

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