ПРО АНАЛИТИКА | СИСТЕМНЫЙ АНАЛИТИК | АЛЕКСАНДР НЕЗДЕМИНА

Каждый тип данных — три созвона и кровь

Это из Threads. Разработчик познал весь дзен работы аналитика.

Раньше многие разрабы не сильно понимали, чем мы с вами занимаемся.

Видимо, думали, что мы просто на встречи ходили, и, как пишет сам автор, "сделал маппинг, отдал разработчику и дальше сиди попивай латте".

Однако реалии немного другие.

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

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

И вот 2026 год.

Во многих крупных компаниях решили сделать из команды разработки фуллстак Product Engineer'ов, которые смогут управлять агентами, делать работу e2e и сократить time to market до 1 дня. Про них я писал тут.

Разработчики теперь фуллстаки и страдают.

Я прям вижу, как тяжело некоторым справиться с работой аналитика.
Они спотыкаются на общении с бизнесом, потому что нет привычки работать с большим уровнем неизвестности.

У меня сейчас на проекте так. Человек в начале не хотел переписываться, потом написал письмо и переписка длится уже неделю.

На предложение созвониться на 15 минут он долго отнекивался, но как раз встреча все порешала.

Для разработчика ставить встречи и общаться голосом прям какой-то геморрой.

Еще история.

Говорит мне, что ему не отвечают на почту. Я говорю: "напиши в корпоративный мессенджер и попроси". А он: «А что, так можно было?» 😅

Короче, боятся они коммуникации.

А мы, хоть у многих это на уровне интуиции или просто практики, знаем техники переговоров, поиска инфы, проведения интервью и так далее.

И если мы хотим стать фуллстаками и делать сами фичи e2e, у нас есть ОФИГЕНСКОЕ преимущество: мы видим картину целиком и понимаем, что надо на старте.

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

➖➖➖

К чему я это все решил написать в эту пятничку?
Многие переживают из-за ИИ. Думают, что их заменят, но, на мой взгляд, это не так.

ИИ нас только усиливает.
Он помогает ускорить работу и прикрыть некоторые технические дыры.
Это технология, с которой мы можем делать результат быстрее и при этом успевать попить латте ☕️

Надеюсь, мои мысли хоть немного добавят вам опоры и уверенности в своих силах 😉

ЛОГИКА НА ФРОНТЕ ИЛИ В API?

На одном из вебинаров меня спросили:

"Где должен происходить маппинг параметров, на API или на фронте?"

Ведь часто проще воткнуть логику на фронт, и все будет супер.

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

Но так работает не всегда.

➖➖➖

Что на это влияет?

1⃣ Бизнес-правила
На одном из проектов мы занимались печатью документов, и для карточных квитанций логику зашили прямо на фронте.

По требованиям PCI DSS (стандарт безопасности данных платежных карт) полный номер карты не должен светиться нигде: ни в промежуточных сервисах, ни в логах, поэтому передавать параметры с полным номером между слоями мы не могли.

Фронт шел сразу в PCI DSS-контур, там формировался документ и отдавался напрямую клиенту.

Красиво через оркестратор такое не прогонишь, и даже BFF (Backend for Frontend, бэк, который собирает данные под конкретный фронт) использовать было нельзя.

2⃣ Простота реализации
Чтобы быстро собрать MVP, можно накидать что-то на фронте, а уже потом, если это добро завелось и приносит деньги, переносить кусочки на бэк.
Минус тут один: нет ничего более постоянного, чем временное.

3⃣ Количество UI
Если у вас мобилка, веб, админки и прочий набор клиентов, общую логику проще держать на бэке, чтобы поведение везде было одинаковым, а если у каждого UI свое поведение, которое не унифицировать, то либо добавлять логику на UI, либо делать на бэке отдельные методы под каждый фронт. По сути, тот же BFF.

Есть, конечно, еще легаси и договоренности на проектах. Но это скорее исключение, чем правильный подход к проектированию систем.

➖➖➖

Подытожу

Если встает вопрос, где лучше, старайтесь все-таки размещать логику на API и бэке. Потом будет меньше мучений с поддержкой и релизами.

Полезно - ставим 🔥

ПОЧЕМУ АНАЛИТИК НЕ ПОПАДАЕТ В СРОК?

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

Решить эту проблему помогает самый простой и 100% рабочий инструмент: ДЕКОМПОЗИЦИЯ. Большую задачу разбиваете на маленькие пользовательские истории, и каждую из них можно отдельно описать и оценить.

Но не все знают, какими способами ее делать.

Лично я пользуюсь этими:

1⃣ Workflow
Расписываете шаги, которые пользователь проходит по бизнес-процессу.

В нашем примере это:
• смотрит меню,
• выбирает блюда,
• проверяет заказ,
• подтверждает.

Каждый шаг становится отдельной историей, и сразу видно, какие из них можно отложить.

2⃣ Операции (CRUD)
То есть делите задачу на операции с данными:
• создание,
• чтение,
• изменение,
• удаление.

Например, "работа с заказом" превращается в:
• создание заказа,
• просмотр,
• изменение состава,
• отмену.

Так видно, какие действия нужны сразу в MVP, а какие можно сделать попозже. Скажем, заказы отменяют редко, и отмену спокойно можно отложить.

3⃣ Спайк
Если в задаче есть то, чего вы пока не знаете, например, как подключить сервис перевода меню - выносите исследование в отдельную задачу с ограничением по времени.

Обычно на спайк уходит 1-2 дня.

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

Есть и другие способы, например, деление на USE CASES или по экранам. Все запомнить практически нереально, но как-то я подсмотрел у скрам-мастера на проекте файлик, где их был 21. Собрал по нему свой вариант и периодически в него заглядываю, когда кейс попадается сложный.

Сохраняйте и отправляйте друзьям, пригодится на следующем планировании 😉️️️️️️

#материалы@proanalitica

➖➖➖

Подписывайся на резервный канал, чтобы не потерять

💙 я в ВК | 🇷🇺 я в Макс