FOKIN MEDIA | Опыт в IT

👀Два поста канала, которые как будто спорят друг с другом

Один пост говорил: «Пока ты незаменим - ты не свободен»
Выход из ловушки один: делать себя заменимым.

Другой пост говорил обратное на первый взгляд: «Формальный авторитет дают должностью. Неформальный - зарабатывают годами»
И именно к такому человеку идут за настоящими вопросами в обход тимлида.

Противоречия здесь нет. Разница не в статусе, а в том, что именно незаменимо.

- Если незаменима функция (только ты умеешь чинить конкретный модуль) - это ловушка, знания не передаются, все в заложниках

- Если незаменимо доверие (к тебе идут, потому что ты не подводил) - это капитал, который растет вместе с тобой, а не держит на месте

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

#менеджмент #карьера
@fokin_media

📌 Что я увидел на защитах магистров этим летом

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

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

Десятки проектов - и почти каждый закрывал конкретную прикладную задачу, а не абстрактную «модель ради модели»:

- Прогноз урожайности сельскохозяйственных культур по спутниковым снимкам, истории погоды и интеграции прогноза засух
- Автоматизированная система извлечения структурированных данных из заключений врачей-рентгенологов на русском языке
- Интеллектуальный межсетевой экран для защиты MCP-серверов в агентных ИИ-системах
- Гибридная оценка кредитного риска корпоративных заёмщиков и модель раннего выявления дефолта в портфеле кредитных карт
- Кросс-национальный анализ доверия европейцев к политическим институтам на данных ESS
- Адаптивное зонирование в логистике быстрой доставки на основе прогноза спроса и пространственной кластеризации
- Агентная система сопровождения процесса разработки аналитических витрин

Ни один из этих проектов не претендует на звание передовой модели уровня GPT. Но это и не то, ради чего их делали.

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

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

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

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

#ИИ #аналитика #образование

@fokin_media

📌 Волна несет, куда несет - и человек называет это обстоятельствами.

Разработчик получает задачу в мутной формулировке, делает по-своему, и через месяцы работы слышит «мы не то имели в виду». Он жалуется на менеджмент - и продолжает работать так же, в той же компании, по тем же правилам.

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

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

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

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

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

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

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

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

#менеджмент #команда #лидерство

@fokin_media

📌 T-shape придумали, чтобы усилить специалиста. Рынок читает это как лицензию на эксплуатацию.

Изначальная идея T-shape простая: у человека есть глубокая экспертиза в одной области - и широкий кругозор вокруг неё. Не для того, чтобы делать всё. А для того, чтобы делать своё - быстрее и качественнее, потому что понимаешь контекст соседних отделов, говоришь с ними на одном языке, не создаёшь трения на стыках.

Широта - это не замена глубины. Это то, что помогает глубине работать в реальной системе, а не в вакууме.

На рынке эту идею вывернули наизнанку.

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

Формально это называется T-shape. По факту - это «и швец, и жнец, и на дуде игрец» с зарплатой на одну ставку.

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

И у этой экономии есть счет, который приходит не сразу.

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

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

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

Если из специалиста делают универсального солдата - его перестают использовать по компетенции. Его используют по нехватке бюджета на нормальный найм.

#менеджмент #команда #найм

@fokin_media

📌 Лучшие практики - самая дорогая фраза в бизнесе

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

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

Разница не в том, кто из них честнее. Разница - в цене ошибки.

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

Особенно когда сроки уже согласованы и зафиксированы, а наверху проектируют так, будто их не существует.

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

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

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

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

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

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

@fokin_media

📣 Ты следующий?

Что общего у хороших системных аналитиков и хороших руководителей IT-команд? Они умеют объяснять сложное просто. Как раз таких гостей мы ищем для FOKIN MEDIA.

Ждем в гости тех, кто разбирается в:

— системном анализе и/или архитектуре
— управлении IT-командами
— разработке
— продуктовой аналитике

Как проходит запись: студия в Москве, 45–60 минут, вопросы обсуждаем заранее.

Последний выпуск с Федором Лежневым, IT-директором Альфа-Капитал:

YouTube: https://youtube.com/@fokin_media

Rutube: https://rutube.ru/video/2c9b9ca618fa3356f7b790243c5e5459/

VK видео: https://vkvideo.ru/video-202150151_456239046

Узнали себя? Пишите в комментарии или в личные сообщения, поговорим.

#подкаст #SA #менеджмент

@fokin_media

👀 Рынок тихо сдвигается от разработки к аналитике

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

Недавно прочитал анализ 106 тысяч вакансий за апрель-июль 2026. И числа подтверждают то, что я слышу на практике.

Python-разработчики упали на 18-е место в спросе. Системная аналитика, аналитика данных, DS/ML - топ.

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

Вот еще что важнее: 1% работодателей публикует 29% всех вакансий. Это огромная концентрация. Что это означает? Что рынок не такой большой, как кажется. Что компании ищут одно и то же: способность к анализу, превод требований, работа с неструктурированными данными.

Гиганты (Сбер, Яндекс, VK) платят не выше среднего - несмотря на размер. А вот нишевые компании, которые ищут специалистов по конкретным системам, платят 50-100% дороже. Это говорит о том, что рынок идет от массовой разработки к узкоспециализированной аналитике.

Вывод про карьеру простой: если раньше путь был "junior разработчик → senior → lead", то теперь хорошее развитие это "разработчик → аналитик-архитектор → управление данными". Потому что именно там деньги, именно там дефицит, и именно туда рынок переходит уже сейчас.

P.S. Региональные компании занимают себя поддержкой 1С и legacy-кода - это тоже видно. Москва/СПб сосредоточили 47% рынка, и это место аналитики и управления. Среди моего окружения, есть ряд разработчиков, которые сменили свою специализацию в пользу 1С.

#карьера #SA #процесс

@fokin_media

📌 Агенту делегировали полномочия.

Вопрос - кому по-прежнему принадлежит ответственность.
Классика управления: полномочия делегируются, ответственность - нет.

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

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

Это ровно то же самое делегирование, что и с человеком.
Но внедрение часто происходит так, будто вопрос ответственности решится сам - потому что действие совершил алгоритм, а не сотрудник.
Не решится.

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

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

Отсюда и растет волна инцидентов, где агент, не решив задачу штатно, находит нештатный способ - обходит ограничение, использует чужой доступ.

С точки зрения бизнеса это не “сбой ИИ”. Это отсутствие человека, который должен был отвечать за то, что агенту разрешили делать.

Поэтому весь разговор про “агентную экономику” в итоге сводится к одному скучному вопросу: кто именно отвечает за этого агента. Не абстрактно “компания” - конкретный человек.

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

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

Мысли из канала одной строкой

- «Ответственный - это имя и фамилия, а не функция» - источник
- «"У нас так всегда было" - это не объяснение. Это диагноз» - источник
- «Готовность не приходит до действия. Она приходит во время» - источник
- «Технический долг начинается не с кода. Он начинается с планерки, где решили срезать угол» - источник
- «Это не комплимент людям. Это диагноз системе» - источник
- «Чем конкретнее запрос - тем опаснее брать его буквально» - источник

Какая мысль откликается сильнее всего?

@fokin_media
#менеджмент #карьера

Тест на паттерны в команде

🧩 Проверьте свою команду за 30 секунд

- Есть задача, про которую "все в курсе", но конкретно за нее никто не отвечает - диффузия ответственности
- Фраза "у нас так всегда было" звучит в команде минимум раз в месяц - нормализация отклонения
- Есть человек без статуса senior, к которому идут за реальным советом в обход тимлида - неформальный авторитет
- Сроки регулярно сдвигаются, хотя оценивали "по опыту" - planning fallacy
- В команде недавно кто-то громко "спас прод", и все это запомнили - культура героизма
- Кто-то тихо предотвратил проблему заранее, и об этом никто не узнал - невидимая работа

Если совпало 3 и больше: у вас не проблема с людьми, а системная проблема, которая прячется за человеческими именами.

А сколько совпало у вас?
@fokin_media

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

🎯 Систему целиком не знает никто

Разработчик знает свой сервис. Тестировщик - свои сценарии. Архитектор - целевую модель. А систему целиком не знает никто - потому что это ничья зона ответственности, если нет системного аналитика.

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

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

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

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

Рекомендую:
👉 Разработчики знали код. Никто не знал систему

#SA #процесс #кейс
@fokin_media

🎯 «Нам нужен еще один аналитик» - не аргумент

— В отделе не хватает людей, задачи стоят в очереди.
— Сколько нужно и почему именно столько?
— Ну... много задач.

Так штатное расписание не защищают. Способов посчитать, сколько вас должно быть, несколько: расписать трудозатраты на предстоящий объем и перевести в человеко-часы, посмотреть на метрики потока - очередь, лид-тайм, долю возвратов. А можно свериться с рынком - сравнить, как в сопоставимых командах соотносятся роли между собой. Разберем последний способ.

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

За годы работы в разных командах у меня накопилась своя цифра. Комфортный состав функции на среднюю команду выглядит так: 0,5 FTE бизнес-аналитика, 1 FTE системного аналитика, 2 FTE разработчика, 0,75-1 FTE тестировщика. Если считать коэффициент разработчик:системный аналитик, получается 2 - и это близко к рыночному диапазону: для относительно небольших компаний он обычно колеблется от 1,5 до 2,5.

Меньше 1,5 - аналитики становятся бутылочным горлышком, задачи копятся в очереди на постановку. Больше 2,5 - аналитик размазывается по разработчикам и не успевает вникать в детали, растет доля возвратов с разработки.

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

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

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

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

@fokin_media

📌 Функция, которую нельзя измерить, финансируется по инерции

Любой отдел в IT рано или поздно получает от финансов вопрос: «а чем вы, собственно, полезны?». И «мы пишем хорошие постановки» - не ответ. Финансы мыслят цифрами.

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

Ось первая - скорость. Lead Time задач, попадание в плановые сроки реализации, для потока задач поддержки - SLA. Дешево измерять, все данные уже лежат в трекере, и это язык, который финансы понимают без переводчика.

Но у скорости есть ловушка - закон Гудхарта: когда метрика становится целью, она перестает измерять. Аналитик, которого оценивают по скорости закрытия задач, научится закрывать задачи. Именно не решать проблемы - закрывать задачи.

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

В ITSM для этого даже придумали отдельный термин - XLA. Долгое время в ITSM главным ориентиром были SLA. Они фокусировались на технических метриках: время отклика, доступность системы, скорость решения инцидента. Проблема в том, что можно формально выполнить SLA (все дашборды «зеленые»), но при этом пользователи будут страдать: сервис может быть медленным, запутанным, из-за чего люди теряют продуктивность. В профессиональной среде это называют «эффектом зеленого арбуза»: снаружи все красиво, а внутри - проблемы. XLA решает эту задачу. Он ставит в центр внимания опыт пользователя: насколько ему удобно, легко ли решать задачи, чувствует ли он, что IT действительно помогает ему работать, а не мешает. IT-директор Альфа-Капитал рассказывал в подкасте, что у него в KPI вшит «уровень удовлетворенности бизнеса» - ровно по этой причине.

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

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

@fokin_media

🎙 Новый выпуск подкаста FOKIN MEDIA

Гость - Федор Лежнев, IT-директор Альфа-Капитал.

Поговорили о том, как управлять IT в крупной компании, выстраивать партнерские отношения с бизнесом, масштабировать команды и внедрять ИИ в ежедневную работу.

Обсудили Team Topologies, ответственность команд за результат, управление ресурсами, роль доверия в организации и практические кейсы применения искусственного интеллекта в разработке и системном анализе.

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

Выпуск уже доступен на всех площадках. Приятного просмотра и прослушивания!

— YouTube
— Rutube
— VK видео

@fokin_media #подкаст #менеджмент

🎙 Уже завтра в 18:00 выйдет выпуск моего подкаста FOKIN MEDIA

Мой гость Фёдор Лежнёв - IT-директор Альфа-Капитал.

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

Фёдор поделился опытом управления командой из 250+ человек, рассказал про Team Topologies, ответственность команд за результат, работу с техдолгом и применение AI в процессах разработки. Мы, опираясь на опыт управления аналитикой и командами разработки, разобрали вместе с гостем практические подходы к организации IT и роли современных руководителей.

В выпуске:

— Почему бизнесу нужен не подрядчик, а партнер со стороны IT
— Как управлять capacity команд и объяснять бизнесу стоимость задач
— Зачем оставлять резерв ресурсов и когда использовать аутстафф
— Team Topologies и стримовая структура команд на практике
— Почему контрольные функции часто мешают эффективности
— Как выстроить доверие между IT и бизнесом
— Роль CTO в современном IT-подразделении
— Как искусственный интеллект помогает в управлении и системном анализе
— Автоматизация документации и AI-review требований

Смотрите на всех площадках YouTube, Rutube и VK Video

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

@fokin_media

🎙 Запускаю FOKIN MEDIA - личный формат подкастов про IT и системный анализ.

Я решил развивать это направление от своего имени - как отдельный медиапроект про IT, системный анализ, управление, команды и практику работы с технологиями

В подкасте FOKIN MEDIA скоро новый гость - Федор Лежнев, IT-директор Альфа-Капитал.

Записали разговор о том, как устроено IT-управление в крупной компании, какие вызовы стоят перед командами сегодня и почему роль IT давно вышла за рамки просто “поддержки бизнеса”.

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

Уже в следующий четверг, 2 июля, поделимся полным выпуском на YouTube, Rutube и VK Video

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

📌 Мы убрали узкое место в сервисе обработки заказов

Производительность выросла на 40%.

Через три дня очередь встала в соседнем сервисе - который не справился с возросшим потоком. Инцидент. Разбор. Снова.

Локальная оптимизация дала локальный результат. Система просто сдвинула проблему.

Это структурный принцип, который работает и в технических, и в организационных системах.

Срезали команду на 20% - нагрузка перераспределилась на оставшихся. Ускорили один этап pipeline - следующий стал узким местом. Убрали ручную проверку - ошибки начали накапливаться дальше по процессу.

Системы не оптимизируются локально. Они перераспределяют нагрузку.

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

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

Прежде чем оптимизировать один элемент, стоит спросить: куда пойдет нагрузка, которую он сейчас поглощает?

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

@fokin_media

👀 «У нас огромный технический долг»

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

Но технический долг не возникает сам по себе.

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

Технический долг - это управленческий долг. Просто записанный в коде.

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

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

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

Технический долг начинается не с кода. Он начинается с планерки, где решили срезать угол.

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

@fokin_media

📌 Дима починил прод в 3 ночи

Директор написал благодарность в общий чат. Команда поставила огонечки.

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

Никто не заметил.

Это называется культура героизма - и она убивает системность.

Механизм простой. Героизм виден: человек спас ситуацию, есть драма, есть контраст до/после. Профилактика невидима: ничего не сломалось, значит, ничего и не было.

Компании неосознанно дрессируют команду на пожаротушение. Если хочешь признания - жди пожара и туши громко. Профилактика не монетизируется в аплодисменты.

Если в вашей команде регулярно появляются герои - это не комплимент людям. Это диагноз системе.

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

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

Иначе люди оптимизируются под то, что замечают.

#менеджмент #команда

@fokin_media