Первые три победителя есть. Играем дальше

Итоги подведем 21 декабря перед следующей частью c помощью рандомайзера. Не забудьте кинуть скрин в комментарии.

Несколько инсайтов от тех, кто нашел все 8 пасхалок:

Попыток было несколько))) и несколько устройств🤫 как оказалось можно все с ноута воспроизвести)
Кликайте везде, а где-то острожно) и внимание на детали
Мне понравилось))) потыкать и сломать всегда интересно))) ну и порой такой "будь как пользователь, кликай бездумно и сломай"

Да, было интересно) мы примерно также каждую сборку подсистемы тестим сразу после выхода))) поэтому уже плюс/минус было понятно куда тыкать и на что обратить внимание

Давай, давай, давай, надо пройти этот путь самому, "на бережно расставленные грабли"--> https://test.analystexe.ru/

@analyst_exe

Папищики вы там живые вообще? Уже вторник, информирую

@analyst_exe

Моя задача – зажечь в вас огонь

Да, вам не показалось. Моя первостепенная задача на этом канале – передать частичку своего внутреннего огня вам. Чтобы маленький, но яркий отблеск в ваших зрачках говорил "Да, эта штука пробудила интерес, любопытство, я готов потерять счет времени и погрузиться в неизведанное".

Недавно я стал ходить к преподавателю по электрогитаре (Серега не читай это ахаха). Ну вы представляете себе это? "Один опытный учитель рассказывает другому также прошаренному учителю и профилактически пиздит его за отсутствие самостоятельной работы".

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

Или вот, например, в этом канале в комментарии периодически заходит Денис Котов, CEO StormBpmn. Вчера там же появился Алексей Голобурдин с канала Диджитализируй! Вы представляете, какую поддержку они мне оказывают? Да я каждый раз просто в афиге сижу и такой "надо делать, надо, вот умные люди, с которых я стараюсь брать пример, заряжают меня своей энергией".

Какой вывод? Ищите тех, кто вас по настоящему вдохновляет. Берите тот огонь, которым с вами делятся. Используйте его для собственного развития и передавайте другим.

Штош, сияйте, а я пойду готовить материал про QR-коды и новую часть игры. Приятного вечера!

@analyst_exe

Воскресные игры #2

Есть такая штука, которую никто не проговаривает вслух.
Ты пишешь требования. Всё чётко: acceptance criteria, edge cases, диаграмму нарисовал. Отдал в разработку.
Вернулось с комментарием: «А вот тут противоречие, поправь».
И ты смотришь – и правда противоречие. Которое ты сам написал. И не заметил.

Это не про невнимательность. Это про то, что видеть текст требования и видеть, как оно ляжет в код – разные навыки.
И второму почему-то нигде не учат.

Сделал тренажёр. Не курс, не лекция – просто ситуация «требования vs реализация».

Твоя задача – найти, где баг, а где ок.

👉 test.analystexe.ru

Сайт адаптирован под мобилки, можно играть с любых устройств

Правила те же:
1. Присылаете скрин с результатом в комментариии (больше 70%)
2. Подведу итоги через рандомайзер ближе к новому году
3. Приз: книга на выбор или 30 минут консультации


Результаты прошлой игры

@fedos16 и @Aeternam_31337 парни, не забудьте получить призы

Играем дальше!
А я пошел придумывать новую часть =)

@analyst_exe

Две боли перед собесом:

1. Резюме вроде норм, но под эту вакансию не бьётся
2. Готовишься ко всему — и ни к чему конкретно

Тестирую гипотезу двух инструментов:
📄 Матчер — показывает, что в резюме переписать под вакансию
🎯 Скринер — даёт вопросы именно под эту позицию

Сейчас проверяю, нужно ли это кому-то кроме меня. Погляди и скажи: "надо или фигня"

https://s.analystexe.ru/

@analyst_exe

Stormbpmn делает крутейшую фичу и для её тестирования устраивает чемпионат

На кону не только деньги, но и знания

https://t.iss.one/bpmn2ru/1846

Будет чем заняться на новогодних
Рекомендую поучаствовать

@analyst_exe

Я буду работать 10, нет, 12, нет, все 18 часов, только согласуйте 🙏

@analyst_exe

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

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

@analyst_exe

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

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

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

Ура!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@analyst_exe

Привет

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

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

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

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

Интересные посты:
🔸Матрица заинтересованных сторон - https://t.iss.one/analyst_exe/13
🔸Рисование как способ донести мысль - https://t.iss.one/analyst_exe/15
🔸Берегите глаза - https://t.iss.one/analyst_exe/19
🔸Книга - Разработка высоконагруженных систем - https://t.iss.one/analyst_exe/31
🔸Что делать с резюме? - https://t.iss.one/analyst_exe/150
🔸Как описать контекст и причем тут c4 - https://t.iss.one/analyst_exe/151
🔸Как научиться задавать вопросы - https://t.iss.one/analyst_exe/205
🔸4 стадии осознанности и компетентности - https://t.iss.one/analyst_exe/208
🔸Как правильно что-то делать? (Никак) - https://t.iss.one/analyst_exe/245
🔸Пост про SQL и с чекм его есть - https://t.iss.one/analyst_exe/320
🔸Работа с локальными LLM у себя на компутере - https://t.iss.one/analyst_exe/405
🔸Неэффективный менеджер - https://t.iss.one/analyst_exe/436
🔸6 лет работы аналитиком резюме - https://t.iss.one/analyst_exe/442
🔸Клавиатурный тренажер (учимся слепой печати) - https://t.iss.one/analyst_exe/452
🔸Как я пытался заскамить магазин на 10 стульев или причем тут валидация - https://t.iss.one/analyst_exe/467
🔸JSON vs YAML - https://t.iss.one/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.iss.one/analyst_exe/86
🔸Видео как продукт меняет архитектуру - https://www.youtube.com/watch?v=jhemRoXoass
🔸Жизненный урок и девиз канала - https://youtu.be/KWC6PwoEdjk
🔸А что вообще почитать? - https://t.iss.one/lib_analyst/59
🔸Мем про выдуманное резюме, или hr не читают их от слова совсем - https://pikabu.ru/story/yekspert_po_mia_khalife_kak_sostavit_uspeshnoe_feykovoe_rezyume_v_ayti_8591011

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

@analyst_exe

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

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

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

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

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

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

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

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

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

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

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

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

@analyst_exe

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

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

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

@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

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

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

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

@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

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

@analyst_exe

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что я упустил

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@analyst_exe

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

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

@analyst_exe