Телеграм канал «Наташа Косинова. Варю айти СУП»

🔔Уже совсем скоро, сегодня в 19:00 по Москве, встречаемся на прямом эфире про проектирование!

🙂Приходите! Ссылка на подключение в сообщении выше 🔝

Грустная новость: в этом году конференцию Flow мы организовать не сможем. 🙈

Но предметная область остается для нас интересным направлением. Поэтому будем стараться хоть иногда встречаться для обсуждений и обмена знаниями.

Завтра 6 октября будем говорить о том, каких скилов не хватает системному аналитику вместе с Сергеем Нужненко и Натальей Косиновой.

Заходить сюда, а более подробное описание ниже.

Всем знакомая ситуация: аналитик написал требования, а разработчик говорит, что по ним систему не собрать без кучи уточнений. Или молча пишет как понял, и получается совсем не то, что нужно.

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

Участники:
🔹 Сергей Нужненко расскажет о наблюдениях с собеседований, о модели компетенций и о своём пошаговом подходе к проектированию: от путей пользователя до схем данных и CRUD-матриц.
🔹 Наталья Косинова расскажет о результатах качественного исследования: интервью с 15 аналитиками. Поделится опытом менторства, обучения и руководства аналитиками.

О чём поговорим:
▪️ какие дефициты видны на практике: потоки данных, интеграции с несколькими участниками, полнота решений, управление изменениями;
▪️ что мы вообще называем проектированием и можно ли знать нотации, но не уметь проектировать;
▪️ чего разработка ждёт от аналитика и кто делает его работу, если аналитика в команде нет;
▪️ живой разбор кейса: интернет-магазин уведомляет клиента о готовности заказа. Участники покажут, как рассуждают. Потом добавим условие, что заказ выдаётся частями, и посмотрим, что сломается;
▪️ чему учиться и что курсы не исправят.

👥 Для кого: системные аналитики и разработчики
📅 Когда: 6 октября 2026 19:00 МСК
📍 Где: зум

Зачем нужно концептуальное проектирование?

Побуду #капитаночевидность сегодня, меня спросили зачем нужно концептуальное проектирование и можно ли без него?) Конечно можно!

Мои мысли следующие:
✔️1.Концепт - это вижен сверху, того, что делаем, нужен для понимания собственно, а что мы делаем?
✔️2.Границы проекты - банально, что делаем, что не делаем и управление очерёдностью.
✔️3.Контекст куда встречаем решение (может быть организационный или системный контекст), то есть вижен того, что нужно сделать в конкретных условиях.
✔️4.Способ управления, это как шкаф, мы видим его размер и дверцы, за которые можно потянуть и увидеть, что внутри, на какой полке, что лежит и с какой полкой нужно работать (спроектировать шкаф, ещё та задачка).
✔️5.На уровне концепта действительно реально управлять, так как есть понятный перечень, а не на 100500 пунктов, и пока дошли до середины, забыли начало.
✔️6.Оценка, планирование, декомпозиция.
✔️7.Я бы ещё сказала концепт может стать контекстом для ИИшки.
✔️8.Выравнивание, синхронизация команды и возможность уходить в управляемые детали.

На конференции #секон были интересные вопросы. И один из них был про управление изменениями.

Что ещё круто в концепте - такие диаграммы, артефакты не должны меняться. Даже если будут изменения, то небольшие и нечасто, что опять же управляемо.

💡И ещё один #лайфхак чтобы спроектировать концепт, часто нужно сначала уйти вширь, в детали, а потом сузить и сделать концепт. Если хватает опыта можно и сразу кубики рисовать. Но как показывает практика - концепт это сложно, и нужно прокачивать скиллы когда отходишь подальше и смотришь сверху на происходящее.

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

И ещё мысль, что любой артефакт - это способ структурирования информации для принятия решения, способ коммуникации.

Когда система очень сложная и большая, тут помогает концептуальное проектирование, как карта навигации.

----------------
Другие посты на тему концепции:

1⃣Шаги проектирования концепции

2⃣Почему сложно проектировать концепцию

Конференции делают люди!
Второй раз была в ПЕНЗЕ на СЕКОНе, и снова вернулась с кучей мыслей и инсайтов. Выше в постах Владислав описал кратко работу нашей секции. Никита Мельников замечательно собрал доклады, что один дополнял другой.

А я теперь в одном предложении могу говорить, что риск - это требования, и как экономически обосновать работу аналитика, а может вообще его уволить, ну и конечно всё можно залить в ИИ.

Пенза какое-то невероятное место, воздух какой-то там особенный, что до сих пор все свои инсайты, идеи перевариваю)

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

Спасибо Пенза, спасибо СЕКОН, надеюсь ещё увидимся!

P. S. Надеюсь наши доклады мы сможем повторить в прямых эфирах 😎💪

SECON'2026 · трек бизнес и системного анализа

Мой доклад был провокационным: «Кросс-функции аналитика: а что может аналитик с AI?». Вопрос на самом деле про то, что нам всем делать дальше, когда рынок требует от аналитика всё больше, а времени и сил не становится.

Проблема простая: профстандарты и рекомендации описывает одну роль аналитика (59+ практик, 6+ функций), а рынок просит 13+ специализаций, от BA и SA до PO, DWH-данных и архитектора. Разрыв очевиден: стандарт фиксирует один «мир», а на деле нужно закрывать все четыре. И совмещать всё самому рискованно: выгорание от переключения контекста, переработка, единая точка контакта, когда бизнес ждёт ответа на «когда?», падение качества и конфликт интересов.

Поэтому в докладе две ключевые мысли.

Мысль первая. Если у тебя профессия аналитика, переключайся на роль. Профессия это выделенный знаток с картой компетенций, а роль это тот, кто делает анализ, кем бы он ни был. Роль переходит от одного к другому в зависимости от того, в каком «мире» ты работаешь: стандарт, продукт, внутренняя разработка или разработка на заказ. У каждого края креста своя граница роли, и один и тот же навык в разных условиях даёт разные вещи. Поэтому не жди, что кто-то закрепит за тобой «мир» навсегда. Свободное время трать на изучение AI, осваивай смежные функции, а не только свою, и помни: роль берёт любой, кто делает анализ.

Мысль вторая. Руководство предлагает смежные функции, бери. Нет предложения, предложи сам. Покажи, как передаёшь часть работы AI, и демонстрируй готовность делать больше. Потому что рынок сегодня требует универсала «на вес золота», а спрос растёт: системные аналитики +23%, бизнес-аналитики +31% (поиск по hh.ru, сентябрь 2026). И вакансии уже смещаются от «собрать требования» к «спроектировать, как AI решает задачу».

Ключевой вывод доклада: аналитик не исчезает, он становится оркестратором решений. Ядро остаётся за человеком: проектирование и описание решений, понимание контекста и причинно-следственных связей, стратегические решения, ответственность и коммуникация с бизнесом. А рутина уходит агентам: сбор и первичный анализ требований, генерация запросов и документации, поиск аномалий, формулирование гипотез. Аналитик становится агентом-маршрутизатором, который раздаёт задачи специализированным агентам и контролирует результат.

Я показал это на себе: мой профиль менеджера это оркестрация команды AI-агентов. Менеджер ведёт бэклог, команду и процессы, аналитик пишет BRD и требования, дизайнер делает презентации, разработчик пишет код, валидаторы проверяют качество. Аналитик ставит задачу на естественном языке, агент выполняет её автономно, аналитик верифицирует и оркестрирует передачу дальше. Плюс четыре кейса, как AI закрывает кросс-функциональные переключения: продукты (SQL и аномалии), анализ обращений (группировка по темам), переключение BA и SA (диаграммы PlantUML и OpenAPI, черновики User Stories) и оркестрация команды агентов.

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

Я был одним из четырёх спикеров трека. Кроме меня выступали ещё трое сильных докладчиков: Анастасия Московкина («Что, если риск, это требование?»), Наталья Косинова («Сила контекста: точка входа в проект») и Сергей Нужненко («Увольте аналитика»). Все четыре презентации лежат в открытом доступе на Я.Диске.

📂 Все презентации с трека: https://disk.yandex.ru/d/YdF0_wBQjjs9iQ

SECON'2026 · трек бизнес- и системного анализа

Вернулся с конференции SECON'2026. Держу главное с трека бизнес- и системного анализа: четыре доклада, которые стоит глянуть всем, кто работает с требованиями. Их объединяет одна мысль: аналитик сегодня не «человек с бумажками», а тот, кто разбирается с неопределённостью, контекстом и решениями.

Анастасия Московкина, «Что, если риск — это требование?»

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

Суть в том, чтобы различать: факт уже существует, проблема, когда последствие наступило, ограничение, заданная граница, а риск, то, что может повлиять на цель. Один и тот же случай можно описать тремя способами, и от этого зависит, кто за него отвечает. В примере «билет уже оплачен» один риск дал четыре разных решения: retry, другая интеграция, допустимая задержка или SLA с провайдером.

Ключевая мысль: если неопределённость меняет продукт, это уже твоя работа. Переведи риск в требование и реши, как продукт должен себя вести.

Владислав Котов, «Кросс-функции аналитика: а что может аналитик с AI?»

Профстандарт описывает одну роль аналитика (59 действий), а рынок просит 13+ специализаций, от BA и SA до PO, данных и архитектора. Стандарт пишет про один «мир», а на деле нужно всё сразу. Вывод: узкая специализация умирает.

Решение: закрывать функции из всех миров, не выгорая. AI берёт рутину, делает диаграммы PlantUML и OpenAPI, разбирает обращения, черновики user stories. Аналитик раздаёт задачи агентам и держит контекст и ответственность.

Ключевая мысль: разбирайся в AI и забирай роли. Аналитик не пропадает, он становится тем, кто рулит агентами и решает.

Наталья Косинова, «Сила контекста: точка входа в проект»

Знакомо? На новом проекте все думают, что у тебя такой же контекст, как у них. Заказчик злится: «я же всё уже рассказал». Каждый сидит в своём вакууме задач. А контекст и есть система координат будущего проекта. Поменяешь его, получишь другое решение.

Собрать его: карточка проекта, карта стейкхолдеров, текущий статус, политика, риски. Плюс раскрыть скрытый контекст: финансы и реальные сроки менеджеры часто недоговаривают. И синхронизировать команду короткими заметками после встреч, чтобы кто-то держал вектор и выравнивал всех.

Ключевая мысль: контекст сужает фокус и помогает решать взвешенно. Без плана погружения и границы «что обязательно передавать» аналитик ошибается на неполной картине.

Сергей Нужненко, «Увольте аналитика»

Провокация, но с честной математикой: предпроект это 1–3–10% проекта, а всё проектирование (бумаги) не больше 25–30%. В аутсорсинге аналитик окупается. Во внутренней «стройке» надо мерить отдачу. А когда решение «уже знают» и бумага нужна только для ритуала, её перекидывают через забор.

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

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

📂 Презентации: https://disk.yandex.ru/d/YdF0_wBQjjs9iQ
🌐 Страница конференции: https://2026.secon.ru/about

#БизнесАнализ #СистемныйАнализ #Требования #AI

Обилие иишного языка в рабочей документации меня довело до Александра Сергеевича Пушкина! Читаю и восхищаюсь!
Робоязык конечно прост, но без сути просто какая-то галимотья 🙈🤪