FOKIN MEDIA | Опыт в IT

Public

Просмотреть канал

Не можете присоединиться? @fokin_media

1.4k Участники

Обновлено: May 11, 2026 at 5:31 AM

FOKIN MEDIA | Опыт в IT

Данила Фокин Начальник отдела системного анализа и технической документации, Team Lead 3-х направлений, НСИС (Центральный Банк) Автор - @sotoros

Join @fokin_media for exclusive sotoros and team content and discussions in 12

Рейтинг

Глобальный рейтинг

#456

Рейтинг по языку

#45

Рейтинг по категории

#23

-1

Рост участников (Последние 9 дней)

Всего: 1.4K

Рост за 24ч: -23 2%

Последние посты

FOKIN MEDIA | Опыт в IT

13 мая 2026 г., 03:13

📌 Как внедрить RAG в отдел и перестать тратить часы на поиск информации

В любой инженерной команде регулярно возникают сложные вопросы:

• через какие сервисы проходит цепочка вызовов в конкретном бизнес-процессе
• где описана логика изменения статусов заявки
• какой payload используется в интеграции и где происходят трансформации данных
• какие события публикуются в шину и какие сервисы их обрабатывают
• где посмотреть sequence-диаграмму всего процесса

Чтобы ответить на один такой вопрос, обычно приходится пройтись по: Confluence, Swagger / OpenAPI, архитектурным схемам, коду, старым задачам в Jira и т.д. И на это легко уходит 30–60 минут анализа.

Здесь и появляется RAG (Retrieval-Augmented Generation).

Технически это довольно простая архитектура:

• Документация (wiki, PDF, код, схемы) разбивается на небольшие фрагменты.
• Для каждого фрагмента считается https://en.wikipedia.org/wiki/Embedding_(machine_learning) - векторное представление текста.
• Эти векторы кладутся в vector database (например Pinecone, Weaviate, Qdrant).
• Когда пользователь задает вопрос, он тоже превращается в embedding.
• Система ищет наиболее похожие фрагменты в базе знаний.
• Найденный контекст передается в LLM, которая формирует ответ.

То есть модель не «угадывает» ответ, а генерирует его на основе найденных документов. Это делает RAG особенно полезным для корпоративных знаний.

Где он реально применяется в командах:

• поиск по архитектурной документации
• анализ интеграций и API
• runbook и инструкции для поддержки
• ответы на сложные инженерные вопросы
• ускорение онбординга новых сотрудников

Фактически RAG решает одну проблему: знания в компании есть, но их сложно быстро собрать в единый контекст. RAG делает это автоматически.

А для руководителя эффект измеряется довольно просто:

• меньше времени на поиск информации
• меньше повторяющихся вопросов
• быстрее адаптация новых сотрудников
• меньше отвлечений ключевых экспертов команды

Если хотите посмотреть, какие RAG-решения уже существуют на рынке и чем они отличаются, Сергей как раз сделал https://t.me/sgavrilov_ai

#эффективность #процесс

434

111

FOKIN MEDIA | Опыт в IT

13 мая 2026 г., 03:13

📌 Простые решения никто не замечает

Прочитал на Хабре https://habr.com/ru/companies/ruvds/articles/1009034/ про то, что за простые решения редко повышают. Логика там довольно жизненная: сложные решения выглядят эффектно — диаграммы, сервисы, паттерны. А простое решение часто выглядит так, будто «ничего особенного не произошло».

И это интересно ложится на мой предыдущий «Лучшее — враг хорошего».

Очень часто инженерная культура поощряет сложность. Сделал архитектуру из пяти сервисов — звучит серьёзно. Написал решение в пару функций — выглядит будто «слишком просто». Хотя иногда именно это и есть хорошая инженерия.

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

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

И вот это, как ни странно, одна из самых сложных инженерных компетенций.

Не написать сложную систему.
А удержаться от того, чтобы её написать.

#эффективность #менеджмент #процесс

400

122

FOKIN MEDIA | Опыт в IT

13 мая 2026 г., 03:13

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

Один из самых частых диалогов в IT выглядит примерно так:

— Сколько это будет стоить по времени?
— Надо посмотреть.

И это не попытка уйти от ответа. Это нормальная реакция инженера на неопределенность.

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

В управлении проектами есть понятие конуса неопределенности. В начале проекта неизвестных максимально много: требования не до конца понятны, архитектура не выбрана, интеграции не исследованы, риски не выявлены. Поэтому оценки на старте могут отличаться в разы - и это нормально. По мере анализа и декомпозиции точность оценки растет.

Но при этом возникает парадокс.

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

И вот тут появляется необходимость верхнеуровневой оценки.

Она нужна не для того, чтобы пообещать точный срок.
Она нужна, чтобы понять порядок величины.

— стоит ли вообще делать проект?
— влезает ли он в бюджет?
— сколько людей потребуется?
— когда примерно ожидать результат?

Без этой информации невозможно управлять портфелем проектов, планировать ресурсы и расставлять приоритеты.

Но здесь важно понимать одну вещь.

Верхнеуровневая оценка - это двухсторонний контракт между исполнителями и руководством.

Со стороны инженеров важно понимать, зачем эта оценка нужна. Это не попытка «выбить обещание». Это попытка понять масштаб задачи и принять управленческое решение.

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

Есть несколько подходов, которые помогают делать такие оценки более адекватно.

Во-первых, оценивать диапазоном, а не одной цифрой. Не «два месяца», а «от двух до четырех». Это честнее отражает уровень неопределенности.

Во-вторых, использовать аналогии. Если команда уже делала похожие задачи, можно оценивать масштаб через сравнение: меньше, примерно так же или значительно больше.

В-третьих, делить проект на крупные атомарные части — релизы, этапы или спринты. Это решает сразу несколько проблем:

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

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

Поэтому задача верхнеуровневой оценки - не угадать будущее.

Ее задача - уменьшить неопределенность настолько, чтобы можно было принять решение.

И если и инженеры, и руководство понимают эту логику, оценки перестают быть источником конфликтов и становятся нормальным инструментом управления.

#менеджмент #процесс #эффективность

FOKIN MEDIA | Опыт в IT

13 мая 2026 г., 03:13

📌 Лучшее - враг хорошего

В IT есть одна очень коварная ловушка. Она выглядит как стремление сделать все идеально.

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

Проблема в том, что между «хорошо» и «идеально» иногда лежит пропасть по времени и ресурсам.

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

— давайте перепишем модуль
— а тут можно сделать архитектуру почище
— надо еще один слой абстракции добавить

В итоге проходит три месяца, продукт всё ещё в разработке, а бизнес продолжает ждать.

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

Но бизнес живет в другой логике. Для него ценность - это не идеальный код. Ценность - это работающий результат.

Есть простое правило: сначала нужно сделать достаточно хорошо, чтобы это начало работать, а уже потом думать, где есть смысл улучшать.

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

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

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

Я часто вспоминаю одну мысль: если решение работает и закрывает задачу бизнеса - это уже хорошо.

А вот стремление сделать «лучше всех» иногда просто откладывает момент, когда система начнёт приносить пользу.

И в этом смысле старое правило работает безотказно:

Лучшее - враг хорошего.

#менеджмент #эффективность #проект

FOKIN MEDIA | Опыт в IT

13 мая 2026 г., 03:13

📌 Я могу это сделать лучше

Периодически у каждого из нас возникает мысль: «Ну это же можно сделать удобнее. Я бы сделал по-другому». И технически чаще всего правда можно.

Помню, когда я работал начальником отдела веб-технологий в университете, ко мне пришел студент и говорит:

Почему вы не сделаете электронное расписание с уведомлениями об изменениях? Чтобы сразу было понятно куда и когда идти. Я могу разработать и вам дать.

Я ответил честно:

Разработать я и сам могу. Вопрос не в этом. Вопрос - кто это будет заполнять и поддерживать в актуальном состоянии?

Он удивился:

Ну сейчас же кто-то делает расписание. Формируют Word-документ.

И вот тут начинается реальность, которую снаружи не видно.

В вузе был человек, который вручную сводил огромную матрицу пересечений: учебные группы, аудиторный фонд, дисциплины, преподаватели, часы.

Реально вручную, на бумаге, с логикой уровня «комбинаторика на максималках». А потом другие люди просто нарезали эту историю на docx-таблички для разных групп. Аналоговая система уже работала. Просто она была неудобной и хрупкой.

И да, самое смешное: даже разрабатывать ничего не надо. Есть готовые решения. Тот же функционал в 1С:Университет, который умеет распределять нагрузку и формировать расписание на основе аудиторного фонда с учетом вместимости, штатного расписания, рабочих программ, праздничных дней, учебы в субботу, плюс умеет править расписание на лету, когда нужно кого-то заменить. Но это не решает главный вопрос - Кто и как будет жить в новом процессе?

Вот почему «сделать систему» почти всегда проще, чем «сделать так, чтобы она реально работала». Проблема редко в том, что не существует решения. Проблема в том, что решение упирается в процессы, компетенции, ФОТ, менталитет, необходимость, политические аспекты и банальное «и так работает». И вот это уже не про разработку.

Поэтому когда у вас возникает мысль «я могу лучше», я бы добавил второй слой рефлексии: а все ли вы учли? Может то, что вы считаете проблемой, на самом деле не проблема, а симптом. И ваше «лучшее решение» упирается не в код, а в людей и систему управления.

Код написать проще, чем изменить привычку.

#кейс #менеджмент #процесс

FOKIN MEDIA | Опыт в IT

13 мая 2026 г., 03:13

📌 А вдруг он обучится и уйдет?

Слышал нексолько раз следующее:

— Зачем отправлять людей на обучение? Сейчас выучатся и уйдут к конкурентам.

И каждый раз думаю: а вас не пугает обратный сценарий?

Что человек не обучится.
И останется.

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

Да, сотрудник может вырасти и уйти. Такое бывает. Но если он растет - он какое-то время растет у вас. Улучшает процессы, принимает более зрелые решения, снижает количество ошибок, экономит бюджет на переделках. Это инвестиция с отдачей, а не благотворительность.

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

— А что если мы обучим сотрудников, и они уйдут?
— А что если не обучим, и они останутся?

Я правда больше боюсь второго варианта.

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

Обучение - это не про «сделать подарок сотруднику». Это про удержание конкурентоспособности компании.

И да, если человек уходит после роста - значит, рынок стал для него шире. Это нормально. Ненормально - сознательно держать команду в профессиональном дефиците из страха потери.

Я боюсь не того, что сотрудник обучится и уйдет.
Я боюсь, что он не обучится - и останется.

#менеджмент #карьера #процесс

484

FOKIN MEDIA | Опыт в IT

13 мая 2026 г., 03:13

📷 Photo

НСИС «Цифровые голоса» | Системный анализ: Эпизод 2 (S02/E14)

ИИ в системном анализе: реальный помощник или просто новая головная боль?

Только практика и честные кейсы.
Гости: (НСИС) и https://t.me/sgavrilov_ai («Россия — страна возможностей»).

Разбираем: где ИИ помогает аналитикам, можно ли доверять ему документацию, что такое RAG (ИИ, который сначала ищет ответ в документах компании, а потом отвечает) и что будет с профессией дальше.

А вы уже используете ИИ в работе?

Выпуск уже на наших площадках:

— https://rutube.ru/video/06b4d1fb04fdbf76b9bdc20044a59f6a/
— https://podster.fm/podcasts/nisi-tehnicheskij-podkast/e/452278/nsis-tsifrovye-golosa-sistemnyy-analiz-epizod-2-s02e14
— https://music.yandex.ru/album/32230441

Лайки, комментарии, репосты 🎉

#подкастНСИС #НСИС_подкаст #ЦифровыеГолоса #SA

672

FOKIN MEDIA | Опыт в IT

13 мая 2026 г., 03:13

📌 Давай просто докинем железо

Есть в enterprise магическая фраза. Она звучит примерно так:

— А может… просто железа докинем?

И в этот момент где-то тихо плачет один оптимизированный SQL-запрос.

С инженерной точки зрения все же понятно: нашли узкое место - профилируем, переписываем, кешируем, убираем N+1, думаем головой. Красиво, академично, как в книжках.

Но потом включается бухгалтерия.

Оптимизация - это: месяц работы команды, приоритеты, регресс, риски, «а вдруг сломаем прод», совещания, еще совещания, и один человек, который говорит «мы так всегда делали».

А масштабирование - это: плюс 30% к облаку и тикет на 10 минут.

И внезапно выясняется, что сервер дешевле разработчика. Разработчик просит зарплату, отпуск и ревью кода. Сервер просит только оплату счета.

Вот так инженерная мысль проигрывает OPEX.

Самое смешное - это не всегда плохо. Иногда реально дешевле и быстрее добавить мощности, чем устраивать месячный рефакторинг ради красивой диаграммы. Бизнесу важен SLA, а не твой внутренний дзен от идеальной архитектуры.

Проблема начинается, когда «временно» становится «стратегией». Когда каждый новый релиз - это +2 инстанса. Когда инфраструктура растет быстрее, чем аудитория. Когда система уже HighLoad… но только по счету в облаке.

И вот тогда появляется проект «Оптимизация расходов на инфраструктуру» в KPI у руководства - вся команда внезапно начинает читать документацию по индексам.

Поэтому я всегда смотрю на это прагматично. Не «оптимизировать или масштабировать», а «что сейчас экономически разумнее».

Enterprise - это не про красивый код. Это про баланс между деньгами, скоростью и риском.

Главное - чтобы «докинем железа» было решением, а не образом мышления.

#эффективность #процесс #менеджмент #кейс

FOKIN MEDIA | Опыт в IT

13 мая 2026 г., 03:13

🎥 Video

📌 IT-Power, FinTech и немного тревожных мыслей про ИИ

Недавно был на встрече IT-руководителей финансовых компаний - IT-Power от Global CIO. Формат хороший: сначала доклады, потом дискуссия. В обсуждении - технические директора Альфы, РСХБ, ОТП, Московской биржи и другие. Не теоретики, а люди, которые отвечают за реальные системы, деньги и риски.

ИИ там обсуждали без восторженного хайпа. Скорее прагматично.

Один из инсайтов, который меня зацепил: LLM уже давно не только «внутренний чат в периметре». Да, компании разворачивают локальные модели, дают copilot в IDE, ограничивают периметр - это уже база. Но дальше начинается интереснее.

ИИ начинают использовать:

🤩для оценки трудоемкости задач на основе входных артефактов BA
🤩для code review и сопоставления качества кода с грейдом разработчика
🤩для проверки «честности» трудозатрат относительно фактического объема изменений
🤩для замеров продуктивности команд после внедрения ИИ

То есть ИИ становится не помощником, а инструментом контроля и аналитики.

И тут у меня родилась мысль, которую пока вслух почти не озвучивают. Если ИИ уже измеряет продуктивность внутри компании - что мешает рынку труда прийти к «шкале продуктивности специалиста»?

Условный AI-score как часть профиля. Не просто «5 лет опыта», а сравнительный показатель эффективности. От него может зависеть грейд, зарплата, карьерный трек. Команды будут собираться алгоритмически - по взаимодополняемости, а не по интуиции менеджера.

Это уже не эксперимент. Это инфраструктура.

В дискуссии звучали и более радикальные позиции. Фраза, которая повисла в воздухе: «Хотели бы вы полететь на самолете, который спроектирован инженером, выросшим на ИИ?»

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

И вот тут рынок может сделать неожиданный поворот. Если ИИ снижает порог входа, то ценность опыта может вырасти. Не потенциала, а именно глубины понимания. Ейджизм может развернуться: «молодой = гибкий» уступит «опытный = надежный».

Еще одна гипотеза - стирание границ между бизнесом и IT. Если стейкхолдер может через ИИ формировать требования, прототипы, отчеты, SQL, MVP, то количество промежуточных ролей действительно может сократиться. Вопрос только в том, кто будет отвечать за последствия.

И да, отдельный культурный шок. Сейчас есть разработчики, которые учатся по TikTok. Раньше были книги. Потом форумы. Потом YouTube. Теперь вертикальные видео. Следующий шаг - просто спросить у ИИ.

Эволюция источников знаний ускоряется. Глубина - не факт.

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

Но ответственность, архитектурное мышление и системность останутся дефицитом.

ИИ - это усилитель. Вопрос только - кого?

#менеджмент #ИИ #BI #процесс

FOKIN MEDIA | Опыт в IT

13 мая 2026 г., 03:13

📷 Photo

НСИС «Цифровые голоса» | Системный анализ: Эпизод 1 (S02/E13)

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

В студии эксперты: — начальник отдела системного анализа и технической докумениации в НСИС; https://t.me/system_analyse — экс-аналитик Miro, Т-Банка и WB, основатель школы системного анализа.

В выпуске:

— Реальная роль системного аналитика в жизненном цикле разработки
— Где именно он влияет на результат
— Почему без анализа ИТ-проекты становятся «дорогим и болезненным экспериментом»?

Выпуск уже на наших площадках:

— https://rutube.ru/video/e5afb104f11e7236d1619829e5f4b3b0/
— https://podster.fm/podcasts/nisi-tehnicheskij-podkast/e/449307/nsis-tsifrovye-golosa-sistemnyy-analiz-epizod-1-s02e13
— https://music.yandex.ru/album/32230441

Лайки, комментарии, репосты 🎉

#подкастНСИС #НСИС_подкаст #ЦифровыеГолоса #SA

FOKIN MEDIA | Опыт в IT

3 апр. 2026 г., 04:11

💻 Пост-навигатор

В этом канале я пишу про IT, системный анализ, управление, процессы, карьеру и работу с людьми. Чтобы новым подписчикам было проще ориентироваться в канале, собрал ключевые темы и публикации, которые выходили здесь в последнее время.

Системный анализ и архитектурное мышление

🔹
🔹🔹
🔹🔹
🔹
🔹
🔹
🔹
🔹

Менеджмент, команды и процессы

🔹
🔹🔹🔹«🔹🔹🔹
🔹
🔹
🔹

Карьера в IT и профессиональный рост

🔹
🔹🔹
🔹
🔹
🔹
🔹
🔹🔹 🔹

Личная эффективность, опыт и размышления

🔹
🔹🔹
🔹🔹🔹🔹🔹
🔹
🔹

Все публикации сгруппированы по темам: можно нажать на хештег и посмотреть материалы по интересующему направлению

#SA — роль системного аналитика, процессы, интеграции, документация, DWH, ФЛК, компетенции
#менеджмент — управление людьми и процессами, принятие решений, структура, планирование
#карьера — рост в IT, рынок труда, смена роли, собеседования, позиционирование
#эффективность — продуктивность, фокус, цели, рабочие привычки, выгорание
#BI — ценность аналитики для бизнеса, BI, процессы, влияние на продукт
#найм — рынок труда, грейды, интервью, зарплатные вилки, деградация компетенций
#процесс — роли, ответственность, коммуникация, культура работы
#кейс — личный опыт, реальные истории, управленческие ситуации
#подкаст — участие в подкастах, публикации выпусков
#митап — выступления, конференции, публичные доклады
#обзор — тренды IT, изменения отрасли, технологии, влияние ИИ

Спасибо, что читаете канал! ❤️

527

FOKIN MEDIA | Опыт в IT

3 апр. 2026 г., 04:11

pinned «💻 Пост-навигатор В этом канале я пишу про IT, системный анализ, управление, процессы, карьеру и работу с людьми. Чтобы новым подписчикам было проще ориентироваться в канале, собрал ключевые темы и публикации, которые выходили здесь в последнее время. Системный…»

FOKIN MEDIA | Опыт в IT

3 апр. 2026 г., 04:11

📷 Photo

🎙 Записали подкаст про системный анализ

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

Приглашенным гостем была Ольга Пономарёва — основатель школы системного анализа. Работала в Miro, Т-Банке, Райффайзенбанке, Wildberries, ведет https://t.me/system_analyse про системный анализ на 30k+ подписчиков, регулярно выступает на Flow, ЛАФ, Summer Merge, Analyst Marathon, Podlodka и других конференциях.

Ведущая выпуска — https://t.me/mlemory руководитель внутренних коммуникаций НСИС, задавшая четкий темп и рамку для содержательного диалога.

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

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

Спасибо https://t.me/s за предоставление площадки для подкастов https://music.yandex.ru/album/32230441

#эффективность #процесс
#подкаст #SA #кейс #карьера

FOKIN MEDIA | Опыт в IT

3 апр. 2026 г., 04:11

📷 Photo

📌 Как взаимодействуют роли в IT-разработке и где тут системный аналитик

В каждой команде есть роли, но не всегда есть четкое понимание, кто за что отвечает. Особенно когда артефакты пересекаются, а процессы - не всегда формализованы.

Чтобы расставить точки над «i», я собрал схему. Она построена вокруг системного аналитика на базе вопросов - «что?», «где?» и «как?».

🔹 Бизнес-аналитик отвечает на вопрос «что?» - что необходимо реализовать? - его зона ответственности: Vision, BRD, бизнес-контекст и цели.

🔹 Архитектор отвечает на вопрос «где?» - где необходимо реализовать? - с опорой на BRD и Vision формирует ADR и архитектурные решения.

🔹 Системный аналитик отвечает на вопрос «как?» - как необходимо реализовать? - на выходе SRS, сценарии, спецификации, схемы интеграции и логика, понятная и разработке, и тестированию, и поддержке.

Эта связка работает только в том случае, если каждый делает свою часть.

Системный аналитик не должен «додумывать» за BA, не обязан закрывать пробелы в архитектуре, не обязан отписывать вместо QA.

🧩 Его задача - трансляция требований в реализацию.

Именно через него проходят все входные артефакты (BRD, ADR), и именно он делает из них понятную инструкцию на выход: для разработчиков, тестировщиков, поддержки. Чтобы:

• разработка могла реализовать функциональность с первого раза
• QA смог протестировать по сценарию
• поддержка могла ответить на вопрос не из головы, а из документации

🛠️ Все это - не про теорию. Это про ежедневную практику. Как сделать так, чтобы задачи шли в спринт без десятка уточнений, чтобы при увольнении ключевого сотрудника знания остались, а не исчезли.

Картинка в посте - схема взаимодействия, адаптируйте под свою реальность.

#SA #процесс

FOKIN MEDIA | Опыт в IT

3 апр. 2026 г., 04:11

📌 Я узнал, как это называется - «волчизм»

В какой-то момент стал ловить себя на странном ощущении. Все чаще на собеседованиях я видел людей, которые очень хотят «легко войти в IT». Не вырасти, не разобраться, не пройти путь - а именно войти. Быстро. Аккуратно. С правильными словами.

Сначала я думал, что это просто особенность времени. Курсы, рынок, хайп. Люди готовятся к интервью, учат формулировки, читают «топ-100 вопросов», подгоняют резюме под вакансию, накручивают опыт. Ну хорошо, рынок такой. Но чем дальше, тем отчетливее стало: это не отдельные случаи, это повторяющийся паттерн.

И только сравнительно недавно я узнал, что у этого явления вообще есть название - https://habr.com/ru/companies/it_sense/articles/916176/?ysclid=ml2w836efj787548369 И в этот момент многое встало на свои места.

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

Меня это сильно обеспокоило, потому что я уже видел это раньше. Когда был преподавателем. Тогда студенты приносили идеально оформленные работы, но стоило задать простой вопрос: «А как ты это сделал?» - а в ответ тишина. Сейчас я вижу ту же картину, только вместо курсовых - резюме, а вместо защиты - собеседование.

Недавно я писал пост про Человека с резюме уровня senior, правильными словами и полной растерянностью, когда речь дошла до элементарных практических вещей. Тогда мне казалось, что это какой-то крайний случай. Сейчас понимаю - нет, это просто один из типичных примеров волчизма вживую.

Самое неприятное - что люди начинают верить, что умение проходить собеседования = умение работать. Что если ты знаешь правильные слова, то система сама как-нибудь сложится.

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

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

Я не знаю, к чему мы придем через 5–10 лет, если эта логика сохранится. Но мне всё больше кажется, что настоящим конкурентным преимуществом станет не умение красиво говорить, а способность честно сказать: «Я этого не знаю, но могу разобраться».

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

#менеджмент #процесс

FOKIN MEDIA | Опыт в IT

3 апр. 2026 г., 04:11

📌 «Делаю все сам» - самый надежный путь к выгоранию

Иногда системные аналитики берут на себя «немного больше». Чуть подправить задачу от бизнес-аналитика, чуть уточнить формулировки, чуть переписать - ну чтобы все было как надо. И вроде молодец. Только через пару месяцев почему-то у тебя 6 задач, в которых ты и бизнес-аналитик, и архитектор, и QA впридачу. А у соседей - нормальная скорость, нормальная загрузка и никакого стресса.

На практике это выглядит так: BA отдал задачу. Ты видишь, что половина требований эфемерные, сценарии не полные, бизнес-цели туманны. Вместо того чтобы вернуть и прояснить - ты «додумываешь». За бизнес. За команду. За всех.

И тут важный момент: Это не геройство. Это неэффективность.

Ты не ускоряешь процесс. Ты тормозишь его. Потому что:

- вместо одной задачи у тебя теперь полторы;

- ты не можешь брать новую, потому что допиливаешь чужую;

- в KPI упираешься ты, а не тот, кто сдал некачественный результат.

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

💡 Это не про «моя хата с краю». Это про «не лезь на чужую грядку с лопатой - свою перекопать не успеешь».

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

⚠️ И в среднем по больнице - все ок: задачи закрыты, процессы идут.

А по факту - ты тот самый тормоз, потому что тянешь лишнее, а сам не можешь двигаться дальше.

📌 Делать необходимое и достаточное - это тоже профессионализм.

Ты не «отказался помочь». Ты обеспечил устойчивость своей роли и дал системе шанс работать корректно.

#менеджмент #эффективность #процесс

FOKIN MEDIA | Опыт в IT

3 апр. 2026 г., 04:11

🎥 Video

🎥 Запись доклада: «Системный анализ в НСИС - процессы, документация, интеграции, DWH»

Мы выступили на конференции НСИС про HighLoad АИС Страхования. В этом посте пройдемся по содержанию и ключевым тезисам. Запись прикрепляю.

Спикеры: Данила Фокин, Анастасия Власова, Андрей Красноусов, Олег Алексеев.

00:00 - Вступление, представление спикеров
00:49 - Повестка доклада
01:27 - Зачем бизнесу системный анализ (ценности)
04:18 - Роли и артефакты (BA/архитектор/СА)
05:46 - BI в управлении отделом
09:05 - Техническая документация
15:14 - Интеграции по СМЭВ
22:30 - DWH / ETL / витрины данных
30:53 - Q&A / Вопросы-ответы

О чем внутри?

Зачем бизнесу системный анализ? 4 ключевые ценности:

- сохранение экспертизы и непрерывность разработки
- снижение порога вхождения для конечных исполнителей
- фокус разработчиков за счет того, что рутина уходит в поддержку и СА
- единый понятийный аппарат между бизнесом и конечными исполнителями

Как устроены роли и артефакты

BA формирует бизнес-требования, архитектор - ADR, системный аналитик - сценарии, спецификации, интеграции, чтобы разработчики, тестировщики и поддержка могли работать «с первого раза».

BI в управлении отделом

Дашборды по обращениям и трудозатратам позволили выровнять загрузку: кейс, когда 3 аналитика были размазаны по 3 проектам, двое перегружены, третий простаивает. В разрезе проектов «все ок», в разрезе людей - нет. BI подсветил дисбаланс и помог его убрать.

Техническая документация

Принципы качества: полнота, непротиворечивость, актуальность, удобочитаемость. Шаблоны для разных типов документов, диаграммы (sequence/state/ERD) с встраиваемым кодом, версионирование, баги на документацию, жизненный цикл.

Интеграции с государственными системами

СМЭВ-3 - гарантия доставки и очереди, СМЭВ-4 - высокие объемы и витрины данных. Кейсы: первая успешная интеграция с ЕПГУ, двустороннее взаимодействие с эПТС, подключение ГИБДД к регламентированным запросам (проверка наличия ОСАГО по камерам дорожного движения).

DWH, ETL и витрины

DWH как предметно-ориентированное интегрированное хранилище; ETL; витрины - «полка в магазине» для прикладных задач. Роль DWH системного аналитика: перевод требований, проектирование моделей, сильный SQL, коммуникация с разработчиками ETL и архитекторами. Практический кейс: оперативная витрина для ГИБДД.

Q&A на выступлении

Используем LLM для подготовки документации - в безопасном периметре на локальных моделях.

BI-мониторинг помог принять кадровые решения и сократить «хвосты» по инцидентам (и время их закрытия).

«Работающий продукт важнее исчерпывающей документации?» - в R&D мы двигаемся быстро, но при переходе в эксплуатацию документация становится критичной: снижает нагрузку на разработчиков и держит систему управляемой.

#SA #BI #митап

FOKIN MEDIA | Опыт в IT

3 апр. 2026 г., 04:11

📌 Системный анализ: не про ТЗ и не про схемы

Если вы думаете, что системный анализ - это про красивые диаграммы и «тех, кто пишет ТЗ», то вот плохая новость: с таким подходом системный анализ у вас точно не работает.

На деле это инженерная практика, которая позволяет держать под контролем сложную систему: где интеграции с внешними сервисами и десятки исполнителей. Это не «написал требования» - это способ защитить бизнес от хаоса.

Четыре вещи, которые дает хороший системный анализ:

• Сохранение экспертизы

Когда ключевой специалист уходит, а система продолжает работать, потому что все задокументировано. Не в голове. Не в устной передаче. В артефактах.

• Эффективная разработка

Когда спецификации написаны так, что junior-разработчик может взять и сделать. А senior - не тратит время на то, чтобы «понять, что имели в виду».

• Фокус разработчиков

Когда вопросы поддержки - это не «а зачем тут два поля?» или «а что имел в виду автор», а нормальный SLA. Потому что все уже описано.

• Соответствие требованиям

Когда вы получаете ровно тот продукт, который планировали. Без сюрпризов. Без дорогостоящих правок в последний спринт.

Но чаще бывает иначе. Аналитика зовут в проект, где «все уже как-то работает». Процессов нет, требований нет, цели туманны. Роль - размыта. Через месяц аналитик превращается в техписателя. А еще через два - в кандидата на сокращение.

Системный анализ работает только тогда, когда у него есть место в процессе. Когда он не в хвосте, а в начале. И когда он встроен не в бюрократию, а в ценность.

#SA #BI

436

FOKIN MEDIA | Опыт в IT

3 апр. 2026 г., 04:11

✏️ Если не записано - этого не существует

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

Если ты хочешь, чтобы твою работу покупали (да, та самая ), сначала сделай ее видимой. В IT «видимость» - это не громкий статус «In Progress», а след из артефактов: комментарии, решения, критерии готовности, ссылки на документы, итог созвона. Артефакт бьет память.

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

Мини-шпаргалка, которую можно держать под рукой (и копипастить в задачи): «Фиксирую договоренности: … Критерии готовности (DoD): … Почему так: … Риски: … Следующие шаги: … Ответственные: … Срок: …». Этого достаточно, чтобы завтра никто не «забыл» и чтобы послезавтра у вас не родился новый проект «переписать то, что уже сделали».

Отдельный момент - «сарафанное RACI»: когда все думают, что «кто-то другой» зафиксирует. Никто не зафиксирует. Если ты исполнитель - закрепи ожидания. Если ты руководитель - закрепи решения. Иначе тебя прижмут ровно в тот момент, когда у другой стороны появится стимул «помнить по-своему».

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

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

#менеджмент #эффективность #процесс

Showing 19 of 19 posts

No more posts

Рейтинг

Требуется вход

Отзывы пользователей (0)

Пока нет отзывов. Будьте первым, кто поделится своим опытом!

FOKIN MEDIA | Опыт в IT

FOKIN MEDIA | Опыт в IT

Рейтинг

Рост участников (Последние 9 дней)

Последние посты

Рейтинг

Отзывы пользователей (0)

Похожие каналы Telegram

ArtTube Editions

Аквариум - мое хобби🇺🇿

Фонд креативных индустрий Пермского края

Галерея «Виктория»

Hovard Club

Shift

Миша Aizek

FARFORITE

Похожие каналы Telegram

ArtTube Editions

Аквариум - мое хобби🇺🇿

Фонд креативных индустрий Пермского края

Галерея «Виктория»

Hovard Club

Shift

Миша Aizek

FARFORITE

Отзывы пользователей (0)

Последние посты