analyst_exe | инженерное мышление в IT

Никогда не делайте "техническую интеграцию" и вот почему

Однажды на проекте прилетела задача: "Нужна техническая интеграция с [название системы]". Не попросили — практически приказали. Сроки горят, давайте быстрее.

Что за проект — не скажу. Абсолютно реальная история из МТС.

Мы нашли документацию сами. Потому что её никто не дал. Сделали еле-еле, душа в теле. Отметили галочкой. Положили в ящик.

Через полгода бизнес наконец согласовал финансовые вопросы. Приходят радостные: "Ну, вам же только включить?"

А там не просто вершина айсберга. Там "зачем мы это вообще делали". Проще было начать с нуля.

Что пошло не так

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

Но никто не спросил:

🔸 Какой бизнес-процесс это поддерживает?
🔸 Какие данные реально нужны, а какие "на всякий случай"?
🔸 Кто будет пользоваться и как?
🔸 Что изменится в процессах, когда включим?

Мы интегрировали системы. А надо было интегрировать процессы.

За полгода изменилось всё: требования бизнеса, структура данных на той стороне, даже команда, которая это заказывала. А наша "техническая интеграция" осталась памятником тому, что было полгода назад.

Почему так происходит

"Давайте сделаем техническое, пока бизнес согласовывает" — звучит логично. Параллелим работу, экономим время.

На практике:

🔸 Техническое без бизнесового контекста — это код в вакууме
🔸 Требования меняются, пока ждёшь согласований
🔸 "Просто включить" никогда не бывает просто

Интеграция — это не про "данные ходят". Это про "бизнес-процесс работает".

Что стоило сделать

Задать вопросы до начала работы:

🔸 "Какую проблему решаем этой интеграцией?" — если ответ "ну, надо связать системы" — красный флаг
🔸 "Когда планируется запуск в прод?" — если "непонятно" или "когда согласуют" — может, не стоит начинать
🔸 "Что будет, если не сделаем сейчас?" — если ничего страшного — точно не стоит

И главное: интеграция без согласованного бизнес-процесса — это технический долг с первого дня.

Выводы

🔸 "Техническая интеграция" без бизнес-контекста — это не интеграция, это заглушка
🔸 Если бизнес не готов — техника тоже не готова
🔸 Вопрос "зачем?" важнее вопроса "как?"
🔸 Галочка в трекере ≠ готовая фича

Иногда лучший результат работы аналитика — не сделанная задача. Потому что вовремя спросил "а точно надо сейчас?"

А у вас были проекты, которые "сделали заранее", а потом выкинули?

@analyst_exe

Жить! Держаться! Срочно инъекцию кофя в мозг!

@analyst_exe

Вчера в комментах к прошлому посту сказали, что нормальные парни работают по FFF (fix time, budget, flex scope -> читай как режем фичи, но делаем дело)

Где-то смеется один синий или зеленый, а может и красный, в общем любой банк 🥲🥲🥲

@analyst_exe

Как торговаться за скоуп и не стать врагом заказчика

У друга был проект. Заказчик пришёл с запросом: "небольшой CRM для отдела продаж".

На первой встрече набросали требования. Получилось 47 пунктов.

Заказчик назвал бюджет. Его хватило бы на 15 пунктов. Или на 20, если сильно ужаться.

"Ну давайте всё сделаем, потом посмотрим" – говорит заказчик. Классика.

Друг уже видел, чем это заканчивается. Бессонные ночи, переработки, "а вы же обещали", и в конце – недовольный заказчик, которому "не совсем то сделали".

Пришлось торговаться.

Почему это вообще задача аналитика

Потому что менеджер хочет продать. А заказчик хочет получить реализацию всех пунктов.

Аналитик – единственный, кто видит картину целиком: что реально нужно, что "хотелось бы", и что написали, потому что пришло в голову на встрече.

Если ты просто записываешь требования и передаёшь дальше – ты секретарь, а не аналитик.

Как друг разрешил ситуацию

Разбил на категории. Взял все 47 требований и разложил:

🔸 Must have – без этого система бесполезна (12 пунктов)
🔸 Should have – важно, но можно запуститься без (18 пунктов)
🔸 Could have – было бы круто (11 пунктов)
🔸 Won't have – хотелки на будущее (6 пунктов)

Получается MoSCoW. Но название не важно – важен принцип.

Привязал к боли. Пошёл к заказчику не со списком, а с вопросом:

"Какую проблему мы решаем в первую очередь?"

Оказалось – менеджеры теряют сделки, потому что забывают перезвонить. Вот боль. А остальное – "ну было бы неплохо".

Сразу 20 требований отвалились. Они не решали эту проблему.

Показал trade-offs. Не "это не влезает в бюджет", а:

"Если делаем интеграцию с телефонией сейчас – запуск через 4 месяца. Если откладываем на вторую версию – через 2 месяца уже работаем и собираем обратную связь."

Заказчик сам выбрал быстрый запуск. Это уже не ты режешь скоуп – это он принимает решение.

Зафиксировал письменно.

По итогам обсуждения в MVP входит: ...
В следующую версию планируем: ...

Подпись заказчика. Теперь "а вы же обещали" не работает.

Что в итоге

Запустились через 2.5 месяца с 16 требованиями. Заказчик доволен – проблема с потерянными сделками решена.

Через полгода пришли за второй версией. Половину из отложенных требований выкинули сами – оказалось не нужно.

Друг говорит: если бы сделали всё сразу, потратили бы в 3 раза больше времени на фичи, которые никто не использует.

Выводы
🔸 Приоритизация – твоя работа, не заказчика. Он хочет всё. Твоя задача – помочь выбрать.
🔸 Привязывай к боли. "Это решает вашу проблему?" – главный вопрос.
🔸 Показывай trade-offs, а не говори "нет". Пусть заказчик сам выбирает.
🔸 Фиксируй письменно. Память – штука ненадёжная, особенно когда дедлайн горит.
🔸 MVP – это не "урезанная версия", это "версия, которая решает главную проблему".

Так что умение говорить "давайте выпустим это в следующей версии" – это не слабость. Это профессионализм.

А как вы торгуетесь за скоуп? Получается или заказчики давят?

@analyst_exe

Точно-точно, вот прям сегодня и начну

@analyst_exe

Как работают пароли

Ни один нормальный сервис не хранит твой qwerty123 в открытом виде. Иначе одна утечка – и все пароли у злоумышленника.

Вместо пароля хранят его "отпечаток" – хеш.

Хеш-функция превращает любой текст в строку фиксированной длины. Главное свойство – односторонность: из хеша нельзя получить исходный пароль.

password123 → ef92b778...
password124 → a1b2c17a...

Любое изменение данных → новая строка

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

Сколько стоит взломать

MD5 – устарел. Видеокарта перебирает ~40 млрд хешей/сек. Пароль из 8 символов подберет за считанные минуты.

bcrypt – надёжный, проверенный временем. Встроенное замедление: ~30 тыс хешей/сек. Разница с MD5 – в миллион раз.

Argon2 – современный стандарт. Сильно нагружает память, чем ломает перебор на GPU.

Медленный алгоритм – это фича. Пользователь ждёт 100мс и не замечает. Злоумышленник при переборе миллиарда вариантов ждёт годы.

Но есть НЮАНС

Квантовые компьютеры. Да, они сломают все шифрование.

А потом мир перейдет на постквантовое шифрование. В общем, пока живем спокойно.

Зачем нужна соль

Если у тысячи юзеров пароль password123 – у всех одинаковый хеш. Взломал один – взломал всех.

Соль – случайная строка, уникальная для каждого пользователя:

password123 + x7Ks9pLm → 8f4a2b1c...
password123 + Qw3rTy5z → d9e8f7a6...

Теперь каждый пароль нужно подбирать отдельно.

Как это работает

Регистрация:
Пароль прилетает по HTTPS в теле POST-запроса (не в URL – там логируется). Сервер генерирует соль, считает хеш, сохраняет в базу данных. Сам пароль не хранится.

Вход:
Сервер достаёт соль и хеш из базы данных, считает хеш введённого пароля с той же солью, сравнивает. Совпало – пускает.

Диаграммы процессов приложу в комментах.

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

password123 + x7Ks9pLm + pepper1# → 16hs8ac0...

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

Выводы

🔸 Пароли не хранятся в открытом виде – только хеши
🔸 Соль препятствует массовому подбору
🔸 Перец защищает хеши при утечке БД
🔸 Медленный алгоритм – не баг, а метод защиты

И никакой магии. Когда пишешь требования к аутентификации – за фразой "пользователь может войти" стоит конкретная инженерная логика.

А вы знали, как это работает?

@analyst_exe

Коллеги, субботний мэм, честно украденный, все как вы любите

Если кто-то из вас работает сегодня - "фу, брось бяку"

@analyst_exe

Заказчик не знает, что такое НФТ. И не должен

"Какие у вас нефункциональные требования?" – спрашиваю на встрече.
Заказчик смотрит как на инопланетянина.
Он не мыслит категориями "производительность 1000 RPS" или "доступность 99.9%". Он вообще не понимает, чего я от него хочу.
Зато он точно знает, как его бизнес работает. И вывести из этого НФТ – задача аналитика.

ФТ vs НФТ – в чём разница

Функциональные требования – это ЧТО система делает.

Пользователь может авторизоваться

Нефункциональные – это КАК она это делает.

Авторизация занимает не больше 2 секунд

Основные типы НФТ

🔸 Производительность – сколько запросов в секунду, время отклика
🔸 Доступность – какой процент времени система работает (SLA 99.9% = 8 часов простоя в год)
🔸 Масштабируемость – что будет при росте нагрузки в N раз
🔸 Безопасность – разграничение доступа, шифрование, аудит
🔸 Надёжность – что происходит при сбоях, как восстанавливаемся
🔸 Совместимость – с какими браузерами, ОС, устройствами работает
🔸 Локализация – языки, часовые пояса, форматы дат

Проблема в том, что заказчик не думает этими категориями.

Кейс с собеседования

На интервью в Леруа Мерлен дали задачку: собрать функциональные и нефункциональные требования для приложения, которое показывает сотрудникам – сейчас день или ночь.
Звучит как шутка. Но попробуй вытащить из этого НФТ.

Я начал спрашивать:

🔸 Сколько человек работает в компании?
→ 20 000 сотрудников → понимаю нагрузку

🔸 Есть геораспределение? Часовые пояса важны?
→ Магазины по всей стране → нужна логика определения времени по локации

🔸 Как будут использовать и зачем это вообще нужно?
→ "По приколу, сидят в тёмном помещении, не знают – идти домой или нет" → Низкая критичность, не нужен SLA 99.99%

🔸 На каких устройствах?
→ Личные телефоны → кроссплатформенность, разные версии ОС

Из ответа про использование понял ещё кое-что: пики нагрузки будут в начале рабочего дня и под конец. Все одновременно проверяют – пора домой или нет.

Что я упустил

Не спросил: "Нужно ли собирать статистику? Логировать действия? Синхронизировать что-то между пользователями?"

Если нет – день/ночь можно определять вообще без сервера, просто по времени на телефоне. И тогда:
🔸 Нет бэкенда → нет нагрузки
🔸 Нет интернета → работает офлайн
🔸 Нет синхронизации → нет проблем с часовыми поясами

Один вопрос мог изменить всю архитектуру.

Вопросы, которые вытаскивают НФТ

Заказчик не скажет "мне нужна доступность 99.9%". Но ответит на вопросы:

🔸 "Что случится, если система не будет работать час? День?"
→ Критичность, требования к доступности

🔸 "Сколько человек будет пользоваться одновременно?"
→ Нагрузка, производительность

🔸 "Откуда будут заходить – офис, дом, в дороге?"
→ Мобильность, офлайн-режим

🔸 "Данные одинаковые для всех или у каждого свои?"
→ Архитектура, где хранить логику

🔸 "Что будет через год – пользователей станет больше?"
→ Масштабируемость

🔸 "Кто не должен видеть эти данные?"
→ Безопасность, разграничение доступа

Выводы для аналитика

🔸 Не спрашивай про НФТ напрямую – спрашивай про сценарии использования
🔸 Из контекста бизнеса рождаются конкретные требования
🔸 Один вопрос про архитектуру может перевернуть всё решение
🔸 Упущенное ограничение больнее упущенной фичи – фичу добавишь, а переделывать архитектуру дорого

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

А как вы вытаскиваете НФТ из заказчиков? Есть любимые вопросы?

@analyst_exe

Обезьяны. Вместе. Сила

@analyst_exe

Три дороги к решению: коробка, Open Source или самопис

Заказчик просит софт. Перед богатырем-аналитиком камень с надписями:

Направо пойдешь – купишь готовое решение: быстро, но дорого .
Налево пойдешь – поднимешь Open Source: дешевле, но сложнее.
Прямо пойдешь – напишешь своё: долго, но под себя.

Аналитик должен понимать, куда ведёт каждая дорога.

Коллега получил запрос: "Нужна система управления задачами. Бюджет – 200 000 ₽, срок – месяц".

Смотрит на требования и думает: "Стандартная история, берём Jira и закрываем вопрос".

А потом считает: Jira Cloud – это $7-14 на юзера в месяц. За год выйдет 400 000–800 000 ₽. Весь бюджет уйдёт на подписку.

On-premise поставить? Нет инфраструктуры. Писать с нуля? Через месяц даже MVP не успеем.

Пришлось разобраться: какие варианты есть? И в каких случаях что выбирать?

Три пути

Когда нужна какая-то функциональность, у вас три варианта:

🔸Open Source – берёте готовый код, поднимаете сами
🔸Проприетарное решение – покупаете у вендора
🔸Самописное решение – пишете с нуля

Разберём каждый.

Open Source: бесплатно, но не совсем

Берёте готовый проект (Redmine, GitLab Community), разворачиваете на своём сервере.

Плюсы: не платите за лицензию, полный доступ к коду, community.

Минусы: поддержка кодовой базы – на вас. Обновления, баги, безопасность – сами. Нужна команда или подрядчик.

Лицензии – это важно

Не все Open Source одинаковые. Лицензия определяет, что можно делать с кодом:

🔸 MIT – делай что хочешь, хоть продавай
🔸 Apache 2.0 – как MIT, но с защитой от патентных исков
🔸 GPL – можно менять, но изменения тоже должны быть открытыми
🔸 AGPL – даже если используете в SaaS, код должен быть открытым

Если берёте библиотеку с GPL и встраиваете в свой продукт – ваш код тоже должен стать открытым.

Когда выбирать:
Есть готовое решение, которое на 80% закрывает требования. Есть команда или подрядчик для поддержки.

Проприетарные решения: платишь и спишь спокойно

Покупаете у вендора – Jira, Salesforce, 1C.
Типы поставок: SaaS (облако), on-premise (у себя), гибрид.

Плюсы: быстрый старт, вендор фиксит баги и выкатывает обновления, есть документация.
Минусы: vendor lock-in (привязка к поставщику), ограниченная кастомизация, регулярные платежи.

Поддержка кодовой базы на вендоре, но в рамках SLA. Нестандартная фича – за доплату или никак.

Когда выбирать: нужно быстро, есть бюджет, требования стандартные.

Самописное решение: полный контроль и ответственность за всё
Пишете систему с нуля под ваши требования.

Плюсы: полный контроль, точное соответствие требованиям.
Минусы: долго, дорого, поддержка кодовой базы требуется постоянно. Обновления, баги, новые фичи – навсегда ваша ответственность. Люди уходят, код стареет.

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

А как же вайбкодинг?

"Но ведь сейчас есть AI! Cursor, Codex, Claude пишут код за минуты. Самопис стал быстрым!"

Да, вайбкодинг ускоряет написание кода. Но есть нюанс.

Написать код ≠ внедрить в эксплуатацию.

AI генерирует код быстро. А дальше: тестирование, фикс багов, интеграция, деплой, поддержка.

В книге "Чистый код" Роберт Мартин пишет:

разработчики тратят в 10 раз больше времени на чтение кода, чем на его написание

Поддержка – это основная работа.

Вайбкодинг снижает порог входа, но не избавляет от расходов на поддержку.

Выводы для аналитика

🔸 Бюджет – сколько нужно сейчас и на поддержку?
🔸 Сроки – когда запуск?
🔸 Команда – кто будет поддерживать?

Считайте TCO (стоимость владения): не только лицензию, но и поддержку, обновления, обучение, инфраструктуру. Open Source может выйти дороже коробки.

Нужно быстро → проприетарный софт.
Важен контроль → Open Source или самопис.
Ограничен бюджет → считайте TCO целиком.

В том проекте с трекером задач они в итоге выбрали Open Source (Taiga), развернули на VPS за 500₽/месяц, наняли подрядчика для интеграции с их CRM.

Уложились в бюджет, запустились за 3 недели. Заказчик доволен, команда работает.

А вы сталкивались с выбором между разными типами решений? Что выбрали и почему? Есть, кстати, еще один реальный кейс...

@analyst_exe

⚡️ ДЕРЖАТЬ СТРОЙ! Пережили 1 день, переживем и еще 4!

Заряжаемся мотивацией. Читаем мантру

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

@analyst_exe

Как работает оплата по QR-коду (СБП)

"Оплатите, пожалуйста, по QR-коду" – слышу это на кассе каждый день.

Вчера задумался: а как это вообще работает изнутри?

Когда я впервые описывал интеграцию с НСПК для оплаты по QR, думал: "Ну что там сложного? Генерируем код, показываем, деньги пришли". Рас рас и готово.

Но оказалось, что там куча нюансов.

(Кстати, если интересно, почему кассиры так просят оплатить по QR – напишите «почему», расскажу. А если знаете – поделитесь в комментах)

Два типа QR-кодов

🔸 Статический – один на всю точку, печатается и вывешивается у кассы. Раньше покупатель сам вводил сумму (фрод). Сейчас QR ведёт на веб-страницу, которая подтягивает сумму от кассы.
🔸 Динамический – генерируется для каждой транзакции, сумма уже в коде.

Как касса узнаёт, что оплата прошла?

Логично предположить: покупатель оплатил → банк отправляет уведомление на кассу (webhook) → "Оплачено ✓"

Но нет.

Касса сама спрашивает банк каждые 2-3 секунды:
"Заказ [OrderID] оплачен?"
→ Нет → пауза → снова спрашивает
→ Да → "Оплачено ✓"

Это называется polling (опрос).

Почему?
Кассе нельзя "позвонить" из интернета: она за роутером, у неё нет постоянного адреса. Или работает через 4G-модем.

Зато касса сама может позвонить в банк – это работает откуда угодно.

Как работает динамический QR:

1. Кассир пробивает товар, например, на 350 ₽ → касса генерирует уникальный OrderID
2. Касса через API банка запрашивает создание QR на 350 ₽ → показывает QR на экране
3. Касса начинает polling: "Оплатили OrderID?"
4. Покупатель сканирует → в приложении сумма уже заполнена → оплачивает
5. При очередном запросе от кассы "Оплатили OrderID?" банк отвечает "Да" → касса печатает чек

[сиквенс-диаграммы в комменте под постом]

Выводы для аналитика

🔸Уточняйте тип QR – статический или динамический (разные flow)
🔸Если устройство за NAT/роутером (у него не статический IP адрес, оно недоступно из внешней сети) – polling, не webhook
🔸 Проверяйте уникальность OrderID – формат типа ORD-{TerminalID}-{Timestamp}
🔸 Думайте о коллизиях – что если на точке несколько касс и несколько активных чеков? При статическом QR это проблема
🔸 Крайние случаи – что если интернет пропал? Кто отменяет транзакцию?

Именно в таких деталях кроется разница между "описал на коленке" и "продумал как надо".

А вы сталкивались с описанием платёжных интеграций?

Пишите в комментах 👇

@analyst_exe

Орёл - птица гордая
Пока не пнешь, не полетит

@analyst_exe

Своровать мем из рабочего чата в первую неделю января - бесценно

Для всего остального есть @analyst_exe

Я тут читалку сделал.. прототип

Наверное это достойно небольшого поста, раз скушало 2 часа моей жизни

Значит как и все, я пробовал поучиться скорочтению. Таблицы шульте, субвокализация, все дела..Планшет покупал... Вон даже купил себе fold, чтобы читать книги. В общем старался.

Сколько я прочитал книг? Не много..

Почему? Да я и так устаю..А тут еще глазами надо водить, голос этот про себя проговаривать. Неудобно короче.

И вот около 21 я увидел пост - https://t.me/naebnet/14126

В нем показлывали опенсорс утилиту, которая позволяет хитро подкидывать слова и ускорять свой темп. Я тут же закинул туда книгу, которая была под рукой и залип минут на 20.

И мне понравилось. Только вот оригинала не хватало, картинки, фотки, все это игнорировалось.. Погуглив, я понял, что такого продукта нет..

И я решил его навайбкодить..

Самое оптимальное из того, что вышло на видео. Кажется этот вайбкодинг сведет меня с ума..

Ну что, доделываем и публикуем на analyst_exe? Будем читать?

Пишите свое мнение

@analyst_exe

Привет

Я бы хотел сказать спасибо за то, что вы меня читаете.

Поэтому собрал для вас все интересное, что было на канале в 2024 и 2025 году, в одном посте. Думаю, каждый найдет для себя что-то по вкусу.

Важное:
🔸Навыки и знания аналитика - https://t.me/analyst_exe/291
🔸Разбирая рабочую задачу - https://t.me/analyst_exe/300
🔸И еще одну задачу разбирая - https://t.me/analyst_exe/309
🔸Гайд по профессии с хабра - https://t.me/analyst_exe/365
🔸Как зарисовывать все и всегда (Obsidian+Excalidraw) - https://t.me/analyst_exe/375
🔸Мок-собеседование на fullstack аналитика - https://t.me/analyst_exe/387
🔸Папочка с реальными тестовыми заданиями - https://t.me/analyst_exe/388
🔸Аналитическая прожарка с Галиной Кореневской - https://t.me/analyst_exe/408
🔸Как проводить эффективные конференции - https://t.me/analyst_exe/446
🔸О прикольных факапах на работе - https://t.me/analyst_exe/454
🔸Откуда к нам пришел UML - https://t.me/analyst_exe/477
🔸Как я ходил в дикси и нажал туда, куда не надо - https://t.me/analyst_exe/511
🔸Кейс с предзаказами кофе vs реальность - https://t.me/analyst_exe/512
🔸Как найти работу - https://t.me/analyst_exe/536
🔸Разбираем телеграмм бота - https://t.me/analyst_exe/539
🔸Разбираем сокращатель ссылок - https://t.me/analyst_exe/543

😁 КУЧА МЕМОВ - https://t.me/analyst_exe/110 😁

Интересные посты:
🔸Матрица заинтересованных сторон - https://t.me/analyst_exe/13
🔸Рисование как способ донести мысль - https://t.me/analyst_exe/15
🔸Берегите глаза - https://t.me/analyst_exe/19
🔸Книга - Разработка высоконагруженных систем - https://t.me/analyst_exe/31
🔸Что делать с резюме? - https://t.me/analyst_exe/150
🔸Как описать контекст и причем тут c4 - https://t.me/analyst_exe/151
🔸Как научиться задавать вопросы - https://t.me/analyst_exe/205
🔸4 стадии осознанности и компетентности - https://t.me/analyst_exe/208
🔸Как правильно что-то делать? (Никак) - https://t.me/analyst_exe/245
🔸Пост про SQL и с чекм его есть - https://t.me/analyst_exe/320
🔸Работа с локальными LLM у себя на компутере - https://t.me/analyst_exe/405
🔸Неэффективный менеджер - https://t.me/analyst_exe/436
🔸6 лет работы аналитиком резюме - https://t.me/analyst_exe/442
🔸Клавиатурный тренажер (учимся слепой печати) - https://t.me/analyst_exe/452
🔸Как я пытался заскамить магазин на 10 стульев или причем тут валидация - https://t.me/analyst_exe/467
🔸JSON vs YAML - https://t.me/analyst_exe/469

Ролики/Оффтоп/Интересное:
🔸Учиться быстрее - https://youtu.be/edUP-d0E4z4?si=0eaZfsELFk9hxOhs
🔸Как работает браузер - https://www.youtube.com/watch?v=EAqrn9debZ0&t=20s
🔸Обзорная экскурсия в мир SystemDesign - https://habr.com/ru/articles/770564/
🔸Замечательная книга про управление на обезьянках - https://monkey-habits.com/ru/book
🔸БД для самых маленьких - https://t.me/analyst_exe/86
🔸Видео как продукт меняет архитектуру - https://www.youtube.com/watch?v=jhemRoXoass
🔸Жизненный урок и девиз канала - https://youtu.be/KWC6PwoEdjk
🔸А что вообще почитать? - https://t.me/lib_analyst/59
🔸Мем про выдуманное резюме, или hr не читают их от слова совсем - https://pikabu.ru/story/yekspert_po_mia_khalife_kak_sostavit_uspeshnoe_feykovoe_rezyume_v_ayti_8591011

Приятного вечера, stay tuned. Готовлю все, что обещал

@analyst_exe

2026, иди сюда! Тебе понравится!

А пока разомнем извилины, господа (помните, думать – это больно)

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

Для этого есть целый арсенал методов выявления требований:
🔸интервью
🔸наблюдение
🔸воркшопы
🔸анализ документов
🔸прототипирование...
и опросы!

Опросы – это такой младший брат интервью. Менее глубокий, зато масштабируемый. Там, где интервью – это 10 созвонов по часу (и потом ещё расшифровывать, ага), опрос – это сотня ответов за день.

Когда использовать? Когда нужно быстро собрать картину по БОЛЬШОЙ выборке. Понять распределение. Найти паттерны, которые потом можно изучить глубже.

Как не запороть:

🔸Не затягивать. 5-7 вопросов. Каждый лишний вопрос – минус 10% дошедших до конца.
🔸Не спрашивать "чего бы вы хотели". Люди не знают. Серьёзно. Спрашивай про реальность: "когда последний раз застрял", "куда пошёл искать ответ".
🔸Открытые вопросы – за инсайтами. Закрытые – за сегментацией.
🔸Заманушка. Пообещай что-то полезное в конце – и люди найдут 3 минуты на прохождение опроса. В противном случае – "потом заполню". Потом = никогда.

Ладно, к чему это всё.

Я тут подумал, что веду канал уже больше года, а толком не знаю, кто вы. Ну, то есть догадываюсь. Но догадки – это не данные, верно?

Собрал опрос. 7 вопросов, всего на 3-4 минуты. Без регистрации и смс, как говорится. Плюшка прилагается.

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

—> Пройти опрос и посмотреть книгу! <—
—> Пройти опрос и посмотреть книгу! <—
—> Пройти опрос и посмотреть книгу! <—

Результаты разберу в посте – посмотрим, какой портрет аудитории нарисуется. Заодно разберемся, как анализировать результаты опросов.

@analyst_exe

Год прошёл, число сменилось

Все на свете изменилось!

С праздником! Нового счастья, новых идей. Пусть в новом году все получится. Как сказал Владимир Владимирович, продолжаем подставлять плечо друг другу! Рад быть частью небольшого, но крепкого сообщества

Ура!

❤️❤️❤️❤️❤️❤️

@мы_сообщество_аналитиков

Что, уже 2026 близко? А как же недоделанные дела?

Бросайте все. Пусть горит. Завтра итоги подведём и наметим планы. А пока вот вам Новогодняя Фея!

@analyst_exe