Latest posts
FOKIN MEDIA | Опыт в IT
10 Sept, 06:02edited
📌 Что я увидел на защитах магистров этим летомВсе лето слышал одно и то же: с ИИ в России все не очень, мы отстаем, тюнингуем чужие модели под своим лейблом. Спорить с этим сложно - в инфраструктуре и вычислительных мощностях разрыв реальный, и сам по себе он скорее не сокращается.Летом я был председателем государственной итоговой комиссии на защите магистров направления «Аналитика больших данных». И то, что прошло передо мной на защитах, немного расходилось с разговорами последних месяцев.Десятки проектов - и почти каждый закрывал конкретную прикладную задачу, а не абстрактную «модель ради модели»:- Прогноз урожайности сельскохозяйственных культур по спутниковым снимкам, истории погоды и интеграции прогноза засух - Автоматизированная система извлечения структурированных данных из заключений врачей-рентгенологов на русском языке - Интеллектуальный межсетевой экран для защитыFOKIN MEDIA | Опыт в IT
8 Sept, 06:01
📌 Волна несет, куда несет - и человек называет это обстоятельствами.Разработчик получает задачу в мутной формулировке, делает по-своему, и через месяцы работы слышит «мы не то имели в виду». Он жалуется на менеджмент - и продолжает работать так же, в той же компании, по тем же правилам.Руководителю ограничивают зону влияния: решения по его же направлению принимают без него, а его просто ставят в известность по факту. Он жалуется на систему - и ничего не предпринимает, чтобы изменить свое место в ней.Разные роли, разные ситуации, один и тот же сценарий поведения. Человека что-то не устраивает - годами. И человек ничего не делает - годами. Это не совпадение, это устойчивая позиция, у которой есть имя: жертва обстоятельств.Жалоба - это сигнал о том, что тебя не устраивает результат. Но сигнал, направленный в пустоту - коллегам за кофе, на неформальной встрече, самому себе, -FOKIN MEDIA | Опыт в IT
3 Sept, 06:00
📌 T-shape придумали, чтобы усилить специалиста. Рынок читает это как лицензию на эксплуатацию.Изначальная идея T-shape простая: у человека есть глубокая экспертиза в одной области - и широкий кругозор вокруг неё. Не для того, чтобы делать всё. А для того, чтобы делать своё - быстрее и качественнее, потому что понимаешь контекст соседних отделов, говоришь с ними на одном языке, не создаёшь трения на стыках.Широта - это не замена глубины. Это то, что помогает глубине работать в реальной системе, а не в вакууме.На рынке эту идею вывернули наизнанку.«У тебя широкий кругозор» незаметно превратилось в «значит, ты можешь за всех». Аналитик, который понимает архитектуру, - значит, пусть и архитектурит. Разработчик, который шарит в аналитике, - значит, пусть сам себе требования пишет. Менеджер, который разбирается в коде, - значит, ревью тоже на нём.Формально это называется T-shape.FOKIN MEDIA | Опыт в IT
1 Sept, 06:01edited
📌 Лучшие практики - самая дорогая фраза в бизнесеАрхитектор добавляет еще один слой абстракции. Бизнес-аналитик вписывает в требования еще один пункт «на всякий случай». Системный аналитик добавляет в схему интеграции еще один сценарий «чтобы потом было проще». Разработчик пишет свою версию паттерна вместо простого решения, потому что «так правильнее». Спрашиваешь зачем - везде один ответ: «так принято», «лучшие практики так велят».За этой фразой почти никогда не стоит расчет. Ни цифр, сколько это сэкономит. Ни сценария, в котором это реально понадобится. Ни оценки, во сколько обойдется поддержка. Просто - так делают «хорошие» специалисты.Разница не в том, кто из них честнее. Разница - в цене ошибки.Когда разработчик усложняет один модуль - это лишние часы на этот модуль. Когда системный аналитик закладывает избыточную гибкость в интеграцию - это лишние недели на реализацию иFOKIN MEDIA | Опыт в IT
27 Aug, 06:04
📣 Ты следующий?Что общего у хороших системных аналитиков и хороших руководителей IT-команд? Они умеют объяснять сложное просто. Как раз таких гостей мы ищем для FOKIN MEDIA.Ждем в гости тех, кто разбирается в:— системном анализе и/или архитектуре — управлении IT-командами — разработке — продуктовой аналитикеКак проходит запись: студия в Москве, 45–60 минут, вопросы обсуждаем заранее.Последний выпуск с Федором Лежневым, IT-директором Альфа-Капитал:YouTube: https://youtube.com/@fokin_mediaRutube: https://rutube.ru/video/2c9b9ca618fa3356f7b790243c5e5459/VK видео: https://vkvideo.ru/video-202150151_456239046FOKIN MEDIA | Опыт в IT
25 Aug, 06:00
👀 Рынок тихо сдвигается от разработки к аналитикеПоследнее время замечаю активное смещение рынка: разработчики все чаще воспринимают как массовый кадровый ресурс, а аналитика и управление данными - это спрос, который компании готовы оплачивать выше среднего.Недавно прочитал анализ 106 тысяч вакансий за апрель-июль 2026. И числа подтверждают то, что я слышу на практике.Python-разработчики упали на 18-е место в спросе. Системная аналитика, аналитика данных, DS/ML - топ.Это не про моду. Это про то, что написание кода оставляет место анализу данных, пониманию потребностей, переводу бизнес-задач в системы.Вот еще что важнее: 1% работодателей публикует 29% всех вакансий. Это огромная концентрация. Что это означает? Что рынок не такой большой, как кажется. Что компании ищут одно и то же: способность к анализу, превод требований, работа с неструктурированными данными.Гиганты (Сбер,FOKIN MEDIA | Опыт в IT
20 Aug, 08:03edited
📌 Агенту делегировали полномочия.Вопрос - кому по-прежнему принадлежит ответственность. Классика управления: полномочия делегируются, ответственность - нет.Руководитель передал сотруднику право действовать в рамках задачи. Но перед своим начальством за результат по-прежнему отвечает он сам. Это не теория из учебника - это принцип единоначалия, на котором стоит вся модель делегирования.С агентом это правило вдруг начинает казаться необязательным. Агенту дают полномочия: доступ к системам, право менять данные, право действовать без подтверждения на каждом шаге.Это ровно то же самое делегирование, что и с человеком. Но внедрение часто происходит так, будто вопрос ответственности решится сам - потому что действие совершил алгоритм, а не сотрудник. Не решится.Ответственность за то, что сделал агент, не растворяется в коде и не исчезает вместе с “это же ИИ решил”. Она как была, такFOKIN MEDIA | Опыт в IT
17 Aug, 17:01
Мысли из канала одной строкой- «Ответственный - это имя и фамилия, а не функция» - источник - «"У нас так всегда было" - это не объяснение. Это диагноз» - источник - «Готовность не приходит до действия. Она приходит во время» - источник - «Технический долг начинается не с кода. Он начинается с планерки, где решили срезать угол» - источник - «Это не комплимент людям. Это диагноз системе» - источник - «Чем конкретнее запрос - тем опаснее брать его буквально» - источникКакая мысль откликается сильнее всего?@fokin_media #менеджмент #карьераTelegramFOKIN MEDIA | Опыт в IT🎯 Задача без владельца На стендапе задачу упомянули три раза. Все кивнули. Через неделю её никто не сделал. Кто виноват? Все. А значит - никто. Если у задачи нет конкретного владельца - она не будет сделана. Не потому что люди ленивые. Это называется диффузия…FOKIN MEDIA | Опыт в IT
6 Aug, 06:00
Тест на паттерны в команде🧩 Проверьте свою команду за 30 секунд- Есть задача, про которую "все в курсе", но конкретно за нее никто не отвечает - диффузия ответственности - Фраза "у нас так всегда было" звучит в команде минимум раз в месяц - нормализация отклонения - Есть человек без статуса senior, к которому идут за реальным советом в обход тимлида - неформальный авторитет - Сроки регулярно сдвигаются, хотя оценивали "по опыту" - planning fallacy - В команде недавно кто-то громко "спас прод", и все это запомнили - культура героизма - Кто-то тихо предотвратил проблему заранее, и об этом никто не узнал - невидимая работаЕсли совпало 3 и больше: у вас не проблема с людьми, а системная проблема, которая прячется за человеческими именами.А сколько совпало у вас? @fokin_media#менеджмент #процессTelegramFOKIN MEDIA | Опыт в IT🎯 Задача без владельца На стендапе задачу упомянули три раза. Все кивнули. Через неделю её никто не сделал. Кто виноват? Все. А значит - никто. Если у задачи нет конкретного владельца - она не будет сделана. Не потому что люди ленивые. Это называется диффузия…FOKIN MEDIA | Опыт в IT
30 Jul, 06:10edited
🎯 Систему целиком не знает никтоРазработчик знает свой сервис. Тестировщик - свои сценарии. Архитектор - целевую модель. А систему целиком не знает никто - потому что это ничья зона ответственности, если нет системного аналитика.Мой коллега Эмиль Астанов столкнулся с этим в чистом виде: получил задачу доработать подсистему аудита высоконагруженной платформы - и обнаружил, что документации много, а картины системы нет. Где метаданные, а где тела запросов. Кто отвечает за повторную обработку. Что из этого - актуальная реализация, а что осталось от предыдущего поколения архитектуры.Каждый ответ начинался и заканчивался на границе своей зоны ответственности. Собрать из этих локальных знаний единую цепочку - от возникновения события до поиска через несколько лет - не получалось ни на встречах, ни в документах.Когда документация заканчивается, системный аналитик начинает читать код.FOKIN MEDIA | Опыт в IT
28 Jul, 07:53
🎯 «Нам нужен еще один аналитик» - не аргумент— В отделе не хватает людей, задачи стоят в очереди. — Сколько нужно и почему именно столько? — Ну... много задач.Так штатное расписание не защищают. Способов посчитать, сколько вас должно быть, несколько: расписать трудозатраты на предстоящий объем и перевести в человеко-часы, посмотреть на метрики потока - очередь, лид-тайм, долю возвратов. А можно свериться с рынком - сравнить, как в сопоставимых командах соотносятся роли между собой. Разберем последний способ.Способ называется бенчмаркинг соотношений. Берете сопоставимые команды, считаете коэффициент - сколько системных аналитиков приходится на разработчика - и умножаете на размер своей разработки. Черновое обоснование штатки готово за час, а не за неделю расчетов трудозатрат.За годы работы в разных командах у меня накопилась своя цифра. Комфортный состав функции на среднююFOKIN MEDIA | Опыт в IT
7 Jul, 09:59edited
📌 Функция, которую нельзя измерить, финансируется по инерцииЛюбой отдел в IT рано или поздно получает от финансов вопрос: «а чем вы, собственно, полезны?». И «мы пишем хорошие постановки» - не ответ. Финансы мыслят цифрами.За годы в разных командах я видел, как на этот вопрос отвечают зрело. Схема сводится к двум осям.Ось первая - скорость. Lead Time задач, попадание в плановые сроки реализации, для потока задач поддержки - SLA. Дешево измерять, все данные уже лежат в трекере, и это язык, который финансы понимают без переводчика.Но у скорости есть ловушка - закон Гудхарта: когда метрика становится целью, она перестает измерять. Аналитик, которого оценивают по скорости закрытия задач, научится закрывать задачи. Именно не решать проблемы - закрывать задачи.Поэтому нужна ось вторая - удовлетворенность потребителя результата. Принцип простой: у каждого артефакта есть потребитель,FOKIN MEDIA | Опыт в IT
2 Jul, 15:05edited
🎙 Новый выпуск подкаста FOKIN MEDIAГость - Федор Лежнев, IT-директор Альфа-Капитал.Поговорили о том, как управлять IT в крупной компании, выстраивать партнерские отношения с бизнесом, масштабировать команды и внедрять ИИ в ежедневную работу.Обсудили Team Topologies, ответственность команд за результат, управление ресурсами, роль доверия в организации и практические кейсы применения искусственного интеллекта в разработке и системном анализе.Получился насыщенный разговор про современное IT-управление про подходы и опыт, проверенные на практике.Выпуск уже доступен на всех площадках. Приятного просмотра и прослушивания!— YouTube — Rutube — VK видео@fokin_media #подкаст #менеджмент
FOKIN MEDIA | Опыт в IT
1 Jul, 06:56edited
🎙 Уже завтра в 18:00 выйдет выпуск моего подкаста FOKIN MEDIAМой гость Фёдор Лежнёв - IT-директор Альфа-Капитал.Обсудили, как сегодня управлять крупным IT-подразделением, выстраивать отношения с бизнесом, масштабировать команды и использовать искусственный интеллект в работе руководителей и инженеров.Фёдор поделился опытом управления командой из 250+ человек, рассказал про Team Topologies, ответственность команд за результат, работу с техдолгом и применение AI в процессах разработки. Мы, опираясь на опыт управления аналитикой и командами разработки, разобрали вместе с гостем практические подходы к организации IT и роли современных руководителей.В выпуске:— Почему бизнесу нужен не подрядчик, а партнер со стороны IT — Как управлять capacity команд и объяснять бизнесу стоимость задач — Зачем оставлять резерв ресурсов и когда использовать аутстафф — Team Topologies и стримоваяFOKIN MEDIA | Опыт в IT
25 Jun, 10:30
🎙 Запускаю FOKIN MEDIA - личный формат подкастов про IT и системный анализ.Я решил развивать это направление от своего имени - как отдельный медиапроект про IT, системный анализ, управление, команды и практику работы с технологиямиВ подкасте FOKIN MEDIA скоро новый гость - Федор Лежнев, IT-директор Альфа-Капитал.Записали разговор о том, как устроено IT-управление в крупной компании, какие вызовы стоят перед командами сегодня и почему роль IT давно вышла за рамки просто “поддержки бизнеса”.Получился сильный выпуск - про управление, ответственность, масштаб, взаимодействие с бизнесом и современные подходы, которые действительно работают в реальной среде.Уже в следующий четверг, 2 июля, поделимся полным выпуском на YouTube, Rutube и VK Video#подкаст #менеджментRUTUBEFOKIN MEDIA | Опыт в IT — полная коллекция видео на RUTUBEНачальник отдела системного анализа и технической документации, Team Lead 3-х направлений, НСИС (Центральный Банк)FOKIN MEDIA | Опыт в IT
23 Jun, 06:04
📌 Мы убрали узкое место в сервисе обработки заказовПроизводительность выросла на 40%.Через три дня очередь встала в соседнем сервисе - который не справился с возросшим потоком. Инцидент. Разбор. Снова.Локальная оптимизация дала локальный результат. Система просто сдвинула проблему.Это структурный принцип, который работает и в технических, и в организационных системах.Срезали команду на 20% - нагрузка перераспределилась на оставшихся. Ускорили один этап pipeline - следующий стал узким местом. Убрали ручную проверку - ошибки начали накапливаться дальше по процессу.Системы не оптимизируются локально. Они перераспределяют нагрузку.Отсюда контринтуитивный вывод: «быстрые фиксы» нередко дороже долгих решений. Быстрый фикс устраняет симптом и сдвигает проблему. Долгое решение убирает причину.Это не значит, что быстрые решения всегда плохи - иногда нужно сначала потушить пожар.FOKIN MEDIA | Опыт в IT
18 Jun, 06:01
👀 «У нас огромный технический долг»Менеджер говорит это с усталостью в голосе. Как будто долг появился сам собой - из воздуха, из лени разработчиков, из природы вещей.Но технический долг не возникает сам по себе.Его создают решения: «сделай быстро, потом почистим», «нет времени на рефакторинг», «запустим, а потом разберемся». Разработчик исполняет. Менеджер принимает решение.Технический долг - это управленческий долг. Просто записанный в коде.Это не значит, что разработчики ни при чем. Но природа долга - в компромиссах, которые принимались на уровне приоритетов, сроков, ресурсов. Эти решения принимает менеджмент.Когда менеджер говорит «мы накопили технический долг» - он часто описывает последствия своих же решений. Без злого умысла. Просто каждый раз казалось, что срок важнее качества.Практический вывод: решение «сделай быстро» - это кредит с процентами. Вы берете будущееFOKIN MEDIA | Опыт в IT
16 Jun, 06:02
📌 Дима починил прод в 3 ночиДиректор написал благодарность в общий чат. Команда поставила огонечки.Вася за неделю до этого закрыл тикет, который мог привести к этому инциденту. Молча. В обычный рабочий день.Никто не заметил.Это называется культура героизма - и она убивает системность.Механизм простой. Героизм виден: человек спас ситуацию, есть драма, есть контраст до/после. Профилактика невидима: ничего не сломалось, значит, ничего и не было.Компании неосознанно дрессируют команду на пожаротушение. Если хочешь признания - жди пожара и туши громко. Профилактика не монетизируется в аплодисменты.Если в вашей команде регулярно появляются герои - это не комплимент людям. Это диагноз системе.Регулярный героизм означает: предотвращение не работает, процессы не надежны, нагрузка распределена неравномерно. Героев создает не выдающийся характер - их создает система, которая неFOKIN MEDIA | Опыт в IT
11 Jun, 06:00
👀 Разработчик сделал именно то, что написано в ТЗБизнес получил не то, что хотел.Кто виноват?Никто. В этом вся проблема.Есть структурный принцип, который я видел в каждом достаточно большом проекте: при каждой передаче требований теряется контекст. Бизнес формулирует задачу → аналитик интерпретирует → разработчик читает ТЗ → тестировщик проверяет по критериям приёмки.На каждом шаге что-то теряется и что-то добавляется. Не потому что люди плохо работают. А потому что устная и письменная передача информации по своей природе искажает.Чем длиннее цепочка передачи - тем меньше шанс, что на выходе окажется то, что нужно.Это не про некомпетентность. Это про архитектуру процесса. Каждый человек в цепочке добавляет своё понимание - и убирает то, что считает незначимым.Что работает: - Сократить цепочку там, где возможно - Зафиксировать «зачем», а не только «что». Контекст задачиFOKIN MEDIA | Опыт в IT
9 Jun, 06:01
📌 Планка, которую не видно снаружиВ разных командах я замечал одну закономерность: самые сильные специалисты почти никогда не думают, что делают достаточно.Не потому что они мало делают. А потому что они всегда видят, что можно было сделать еще.Механизм простой. Сильный специалист измеряет себя не по требованиям задачи, а по своему потолку. И потолок всегда чуть выше, чем текущий результат. Можно было написать код чище. Провести встречу эффективнее. Закрыть ещё одну задачу до конца дня.Итог: хроническое ощущение «сделал недостаточно» при объективно высоком результате.То, что ты можешь делать больше, - это не значит, что ты делаешь недостаточно. Это значит, что у тебя высокая планка.Это не повод для самобичевания. Это признак компетентности. Новичок не видит, что можно было лучше - потому что у него нет картины «лучше». Видеть разрыв между тем, что сделано, и тем, что
Related Channels
Other channels in the same section of the catalogue.
