Analyst IT

Салют! Сегодня продолжаю тему ретроспективы и делюсь подборкой статей: - Что такое ретроспектива - Что такое ретроспективы agile - Что такое ретроспектива простыми словами - Что такое ретроспектива проекта и как её провести - Ретроспектива Спринта (Sprint Retrospective) - Ретроспектива: личный опыт, как сделать практику продуктивной - Заметки для новичка: Как провести первую ретроспективу и не облажаться Источник: @ba_and_sa 💙 BA|SA | 💬 BA|SA

Аналитики, которые строят highload: в чём их секрет? 28 мая в 18:00 собираемся в Санкт-Петербурге чтобы узнать, как наладить процессы системного анализа в сложных проектах. На митапе разберем: ▶️как выстроить системный анализ с нуля и перейти от хаоса к стандартам ▶️как писать спецификации, которые архитекторы принимают с первого раза (с расчётом RPS и сайзинга БД) ▶️погрузимся в Sequence Diagram и проверим, насколько ваши знания соответствуют спецификации UML. Митап пройдет в гибридном формате: вы можете присоединиться лично или онлайн. Участие бесплатное, ссылку на трансляцию пришлем накануне. Регистрация и подробности по ссылке: https://career.crpt.ru/events/system-analytics Чат для общения и нетворкинга: https://t.me/+C3mXc_pzTpYwMGMy #43Tech #системныйанализ #UML

Заметки для новичка: Как провести первую ретроспективу и не облажаться? ⏳ 4 мин | 🟡⚪️⚪️ Читать статью | @analysis_it 💙 Analyst IT | 💬 Analyst IT

Как удачно провести первую ретроспективу? 🔍 Салют! За 12 лет в аналитике я провела ретроспективы в фин.техе, стартапе, производстве, государственных проектах и e-commerce. И везде — одни и те же грабли у тех, кто делает это впервые. Сегодня разбираю всё по-честному. Часть 1. ❓ Что такое ретроспектива вообще? Это не «разбор полётов» и не поиск виноватых. Ретроспектива — это встреча команды, где вы останавливаетесь, смотрите назад на пройденный период и отвечаете на три вопроса: 1. Что шло хорошо? 2. Что мешало работать? 3. Что конкретно изменим?

Это инструмент из Agile, но работает в любой команде — даже если вы не слышали про Scrum.

Ошибка №1: «Ну давайте просто поговорим» Без структуры ретро превращается в жалобный хор или монолог самого громкого человека в комнате. Выберите формат заранее. Самый простой для старта — Start / Stop / Continue: ▸ Start — что начать делать ▸ Stop — что прекратить ▸ Continue — что оставить как есть Занимает 60 минут, подходит для любой команды от 4 человек. Ошибка №2: Собрать всех — и молчание Люди боятся говорить правду вслух, особенно если в комнате руководитель. Решение — анонимный сбор тезисов. Используйте Miro, Mural или даже обычный Google Forms. Люди пишут честнее, когда не смотрят в глаза начальнику. Ошибка №3: Обсудили — и разошлись Это убивает доверие к ретро навсегда. Если в конце не зафиксировано 2–3 конкретных действия с ответственным и дедлайном — встреча прошла впустую. Пример плохого итога: «Надо улучшить коммуникацию» Пример хорошего: «Петя до пятницы настраивает общий чат для согласований, больше не пишем в личку» Мой чеклист для первой ретро👇 ✅ Предупредить команду за 2 дня — зачем встреча и что ожидается ✅ Выбрать нейтрального фасилитатора (не руководитель проекта!) ✅ Установить таймбокс — 60–90 минут максимум ✅ Собрать тезисы анонимно до встречи ✅ Проголосовать за топ-проблемы (не обсуждать всё подряд) ✅ Зафиксировать 2–3 action points с именем и датой ✅ Через 2 недели — проверить выполнение ‼️ И последнее — самое важное Ретроспектива работает только в психологически безопасной среде. Если люди боятся говорить правду — никакой формат не поможет. Первое, что скажите команде в начале встречи:

«Здесь нет правых и виноватых. Мы говорим о процессах, не о людях.»

Повторяйте это как мантру, пока не станет нормой. В след раз поделюсь первым проведением ретро💪 и расскажу, как я там провалилась Источник: @ba_and_sa 💙 BA|SA | 💬 BA|SA

ИИ разработке нужны не спецификации, а полноценная трассировка требований ⏳ 9 мин | 🟡🟡⚪️ Читать статью | @analysis_it 💙 Analyst IT | 💬 Analyst IT

🦾 Препарируем рекомендательные системы методами машинного обучения На открытом уроке разберём, как работают рекомендательные системы и какие подходы используются в машинном обучении. Покажем, как формируется рекомендация и как реализовать один из методов на практике с помощью Python. Вы не просто послушаете теорию, а соберёте свою первую рекомендательную модель. 👨‍💻🛠👨🏻‍💻 Урок подойдёт тем, кто начинает путь в машинном обучении и хочет разобраться в одной из самых востребованных задач. Встречаемся 20 мая в 18:00 МСК в преддверии старта курса «Машинное обучение. Специализация». ➡️ Принять участие бесплатно: https://clck.ru/3ThrnQ Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

«Боргворглер: боргает ворглер», или как сделать действительно полезную документацию к проекту ⏳ 8 мин | 🟡⚪️⚪️ Читать статью | @analysis_it 💙 Analyst IT | 💬 Analyst IT

Почему проекты превращаются в спагетти даже у хороших программистов ⏳ 4 мин | 🟡🟡⚪️ Читать статью | @analysis_it 💙 Analyst IT | 💬 Analyst IT

Об организации труда ИИ-агентов ⏳ 32 мин | 🟡🟡⚪️ Читать статью | @analysis_it 💙 Analyst IT | 💬 Analyst IT

Аналитики и нагрузочное тестирование: как это работает на практике ⏳ 11 мин | 🟡⚪️⚪️ Читать статью | @analysis_it 💙 Analyst IT | 💬 Analyst IT

Почему spec-driven development плохо работает на микросервисах: часть 1. Где теряется контекст ⏳ 12 мин | 🟡🟡⚪️ Читать статью | @analysis_it 💙 Analyst IT | 💬 Analyst IT

Семь раз посчитай — один раз урони: моделируем инциденты до деплоя ⏳ 8 мин | 🟡🟡⚪️ Читать статью | @analysis_it 💙 Analyst IT | 💬 Analyst IT

AI-friendly и AI-first: как адаптировать ИТ-проекты под эру LLM ⏳ 6 мин | 🟡⚪️⚪️ Читать статью | @analysis_it 💙 Analyst IT | 💬 Analyst IT

Салют! Хочу продолжить тему невидимых / очевидных требований, и поделиться еще одной историей с моей рабочей жизни)) ‼️ «Сделайте нам заявку» — и два цеха три месяца не могли договориться До финтеха я работала аналитиком в крупной нефтепереработке — участвовала в проектах автоматизации производственных процессов на заводе. Это совсем другой мир: здесь заказчики — не продакты в кроссовках, а начальники цехов с тридцатилетним стажем, которые привыкли работать в Excel, журналах и телефонных звонках. Один из проектов — автоматизация подачи заявок на ремонт оборудования. Звучит просто. Бизнес-заказчик — главный механик — сформулировал задачу так:

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

Все кивнули. Я записала. Пошли проектировать. Первое интервью — начальник механического цеха. Рассказывает, как подаёт заявку: звонит мастеру, тот записывает в журнал, передаёт в плановый отдел, те согласовывают с главным механиком. Я рисую флоу, кажется, всё понятно. Второе интервью — начальник технологического цеха. И тут я понимаю, что он описывает совершенно другой процесс 🤯 У них заявка не на ремонт как таковой, а на вывод оборудования из работы — это требует согласования с диспетчером, технологом и службой безопасности, потому что остановка установки влияет на всю цепочку производства. Оба называли это словом «заявка на ремонт». Но за этим словом скрывались два принципиально разных процесса: в одном случае — административное поручение внутри цеха, в другом — межведомственное согласование с остановкой производственной установки и рисками для безопасности. Если бы мы спроектировали одну форму под оба сценария — она не подошла бы ни одному. Я остановила проектирование и провела ещё четыре интервью — с диспетчером, технологом, сотрудником службы промышленной безопасности и плановым отделом. Попросила каждого показать мне реальный случай: вот конкретная заявка из прошлого месяца — как она шла, кто что делал, где могло застрять. В итоге оказалось, что под «заявкой на ремонт» на заводе существовало пять разных сценариев с разными маршрутами согласования, разными сроками, разными уровнями критичности и разными ответственными. Некоторые из них пересекались, некоторые — нет. Я собрала это в карту процессов с разветвлениями по типу оборудования и категории работ. Когда вынесла на общий митинг — начальники цехов впервые увидели процессы друг друга. Главный механик сказал:

«Я не знал, что у технологов это работает вот так».

‼️ Что этот проект закрепил для меня навсегда: ✅ На производстве слова особенно обманчивы — один термин может означать разное в зависимости от цеха, должности и стажа собеседника. ✅ Всегда проси показать реальный документ или журнал: бумажный процесс честнее любого описания на словах — в нём видны все обходные пути и неформальные договорённости. ✅ Интервью только с «главным заказчиком» — это половина картины. Истина живёт на уровне исполнителей и смежников. ✅ Карта процессов как артефакт работает лучше любого ТЗ на старте — люди узнают себя и сами начинают уточнять и исправлять. В финтехе за неправильно понятое требование платишь переделкой функции. На производстве цена ошибки — это остановка установки, нарушение регламента безопасности или срыв ремонтной кампании. Ставки другие. Но болезнь та же: «очевидное» требование, которое никто не потрудился проверить. Вывод: Чем сложнее домен — тем опаснее простые формулировки. Когда опытный заводчанин говорит «ну это понятно» — это сигнал остановиться и спросить ещё раз, но по-другому: «Покажи мне конкретный случай из прошлого месяца». Именно там, в реальном примере, прячется настоящее требование. Источник: @ba_and_sa 💙 BA|SA | 💬 BA|SA

Дерево решений vs граф работ: как я объединила Data Science и JTBD в одном проекте ⏳ 8 мин | 🟡🟡⚪️ Читать статью | @analysis_it 💙 Analyst IT | 💬 Analyst IT

Безопасность ИИ: как перестать бежать анализировать каждое новое ПО и перейти к системному подходу ⏳ 9 мин | 🟡🟡⚪️ Читать статью | @analysis_it 💙 Analyst IT | 💬 Analyst IT

Agile systems engineering по ISO/IEC/IEEE 24748-10:2026: как быть гибким и не потерять жизненный цикл ⏳ 10 мин | 🟡🟡⚪️ Читать статью | @analysis_it 💙 Analyst IT | 💬 Analyst IT

Проектируем сервис HTTP-запросов: Kafka, PostgreSQL, Redis-очередь и миллионы логических партиций ⏳ 11 мин | 🟡🟡⚪️ Читать статью | @analysis_it 💙 Analyst IT | 💬 Analyst IT

Почему я перестала доверять «очевидным» требованиям Есть одна фраза, от которой у меня теперь непроизвольно сжимается желудок🤨. Звучит она так: «Ну это же понятно, зачем это писать». За несколько лет в аналитике я слышала её десятки раз — от бизнеса, от заказчиков, от коллег. И почти каждый раз за этой фразой прятался баг. Не в коде. В голове у людей, которые были уверены, что думают об одном и том же. Расскажу один конкретный случай из своей практики в финтехе. Мы работали над внутренним порталом для операционного отдела. На установочном митинге руководитель направления сказал: «Нам нужна кнопка выгрузки отчёта по клиентам» Коротко. Чётко. Все кивнули — и я в том числе. Требование ушло в бэклог. Через пять недель разработчики показали готовую выгрузку: все поля на месте, данные корректные, формат .xlsx, скачивается за секунду. Я проверила — полное соответствие тому, что обсуждали. Передаю на приёмку. Через час приходит сообщение: «Это не тот отчёт. Нам нужна выгрузка строго по форме № ОП-7 из нашего внутреннего регламента — с группировкой по менеджерам, подитогами по продуктам и отдельной вкладкой для просроченных клиентов». Про форму № ОП-7 на митинге не было сказано ни слова. Потому что «это же очевидно» 🤯 Две недели переделок. Недовольный заказчик. Разбор полётов с тимлидом. И главное — ощущение, что я подвела команду, хотя сделала ровно то, о чём договорились. После этого случая я изменила подход к сбору требований. Теперь любое упоминание слов «отчёт», «выгрузка», «уведомление», «форма», «статус» — это для меня стоп-сигнал. Я не иду дальше, пока не получу ответ на три вопроса: 1️⃣ Как это выглядит прямо сейчас? Покажи файл, скриншот, распечатку — что угодно реальное. 2️⃣ Кто это использует и когда? Конкретный человек, конкретная ситуация. 3️⃣ Что произойдёт, если этого не будет? Это помогает понять реальный приоритет и критичность. Эти три вопроса кажутся простыми — но именно они вскрывают всё скрытое. Форму № ОП-7. Макросы. Регламенты безопасности. Согласования со смежниками. То, что заказчик считает само собой разумеющимся и поэтому не говорит вслух. Самое неприятное в «очевидных» требованиях — они не выглядят как проблема. Никто не молчит намеренно. Люди просто не умеют видеть границу между тем, что знают они, и тем, что знаешь ты. Это не злой умысел — это разрыв контекстов. И устранять этот разрыв — наша работа, а не заказчика. Вывод: Документируй не то, что кажется сложным, — а то, что кажется очевидным. Именно там живут самые дорогие ошибки. Один уточняющий вопрос на старте стоит дешевле двух недель переделок на финише. Я убедилась в этом на собственном опыте — и теперь не киваю молча никогда! Источник: @ba_and_sa 💙 BA|SA | 💬 BA|SA