Telegram channel "FOKIN MEDIA | Опыт в IT" — @fokin_media

FOKIN MEDIA | Опыт в IT

8 Oct, 09:01

📌 Конфликт по вопросу - не конфликт с человеком

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

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

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

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

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

И есть практический довод. В организации вы встретитесь снова. Человек, с которым вы сегодня не сошлись, завтра окажется носителем нужной вам экспертизы или решением, от которого зависит ваш проект. Сжечь такой мост проще всего, а восстановить сложнее всего.

#менеджмент #коммуникации #карьера
@fokin_media

166 0 1 110

FOKIN MEDIA | Опыт в IT

6 Oct, 09:04

📌 Встреча решается до встречи

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

Это дает три эффекта.

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

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

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

У подхода есть границы, и их стоит держать в голове:

• это не закулисная сделка. Тезисы я не подгоняю под каждого и не раздаю разные обещания разным людям. Если после разговора меняется суть, то меняется для всех, и об этом знают все;

• нельзя ходить только к тем, кто и так согласен. Самый ценный разговор - с тем, от кого ждешь самого жесткого возражения;

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

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

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

#менеджмент #коммуникации #переговоры

@fokin_media

191 0 2 108

FOKIN MEDIA | Опыт в IT

1 Oct, 13:40

📌 Сбер подтвердил то, о чем я писал две недели назад

На этой неделе был на IT Analyst Meetup 2026 в Сбере, где спикерами были как сотрудники Сбера, так и приглашенные с других компаний. Две недели назад выходил пост про SDD и то, как хорошо в рамках данного подхода на цикл разработки ложится практика применения ИИ.
На конференции я увидел почти зеркальное отражение этой мысли - только в масштабе одного из крупнейших банков страны.

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

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

Суть в следующем: у многих складывается ощущение, что ИИ либо начнёт массово заменять людей, либо даст компании одного универсального бойца, который сам спроектирует, сам разработает, сам протестирует и сам выкатит готовое решение. Были показаны и реальные кейсы - когда условный «системный аналитик» в связке с продуктом в одиночку реализовал рабочее решение. Любопытно, но посмотрел бы я, как это внедрят в ядро банковской системы. В рамках R&D для проверки бизнес- или финансовой гипотезы - да, рабочий сценарий, и неплохой. Как практику для продакшена критичных систем - нет, не более.

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

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

#конференция #ИИ #системныйанализ
@fokin_media

285 0 6 4 119

FOKIN MEDIA | Опыт в IT

29 Sep, 09:41

255 0 2 2 124

FOKIN MEDIA | Опыт в IT

21 Sep, 21:31

306 0 4 117

FOKIN MEDIA | Опыт в IT

15 Sep, 09:16

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

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

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

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

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

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

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

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

FOKIN MEDIA | Опыт в IT

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

342 0 3 1 109

FOKIN MEDIA | Опыт в IT

10 Sep, 09:02

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

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

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

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

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

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

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

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

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

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

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

@fokin_media

368 0 3 1 125

FOKIN MEDIA | Опыт в IT

8 Sep, 09:01

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

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

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

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

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

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

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

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

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

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

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

@fokin_media

342 0 5 114

FOKIN MEDIA | Опыт в IT

3 Sep, 09:00

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

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

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

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

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

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

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

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

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

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

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

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

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

@fokin_media

327 0 1 119

FOKIN MEDIA | Опыт в IT

1 Sep, 09:01

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

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

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

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

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

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

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

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

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

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

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

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

@fokin_media

FOKIN MEDIA | Опыт в IT

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

311 0 4 1 112

FOKIN MEDIA | Опыт в IT

27 Aug, 09:04

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

Что общего у хороших системных аналитиков и хороших руководителей 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

327 0 3 2 115

FOKIN MEDIA | Опыт в IT

25 Aug, 09:00

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

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

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

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

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

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

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

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

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

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

@fokin_media

373 0 6 137

FOKIN MEDIA | Опыт в IT

20 Aug, 11:03

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

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

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

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

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

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

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

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

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

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

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

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

364 0 1 1 109

FOKIN MEDIA | Опыт в IT

17 Aug, 20:01

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

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

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

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

FOKIN MEDIA | Опыт в IT

🎯 Задача без владельца На стендапе задачу упомянули три раза. Все кивнули. Через неделю её никто не сделал. Кто виноват? Все. А значит - никто. Если у задачи нет конкретного владельца - она не будет сделана. Не потому что люди ленивые. Это называется диффузия ответственности: каждый человек в гру...

251 0 1 2 11

FOKIN MEDIA | Опыт в IT

6 Aug, 09:00

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

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

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

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

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

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

FOKIN MEDIA | Опыт в IT

🎯 Задача без владельца На стендапе задачу упомянули три раза. Все кивнули. Через неделю её никто не сделал. Кто виноват? Все. А значит - никто. Если у задачи нет конкретного владельца - она не будет сделана. Не потому что люди ленивые. Это называется диффузия ответственности: каждый человек в гру...

414 0 2 1 123

FOKIN MEDIA | Опыт в IT

30 Jul, 09:10

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

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

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

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

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

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

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

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

Астанов Эмиль Мурадович aka apaem - Системный аналитик

Астанов Эмиль Мурадович aka apaem.

433 0 4 1 148

FOKIN MEDIA | Опыт в IT

28 Jul, 10:53

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

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

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

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

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

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

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

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

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

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

@fokin_media

357 0 3 1 141

FOKIN MEDIA | Опыт в IT

7 Jul, 12:59

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

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

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

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

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

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

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

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

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

@fokin_media

Закон Гудхарта

Закон

327 0 3 1 117

FOKIN MEDIA | Опыт в IT

2 Jul, 18:05

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

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

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

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

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

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

— YouTube
— Rutube
— VK видео

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

436 0 1 1 249

FOKIN MEDIA | Опыт в IT

1 Jul, 09:56

🎙 Уже завтра в 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

369 0 3 1 150

Купить живой трафик

Ваш канал уже есть в каталоге?

TGStat Bot

FOKIN MEDIA | Опыт в IT

Channel's geo and language

Category

FOKIN MEDIA | Опыт в IT

FOKIN MEDIA | Опыт в IT

FOKIN MEDIA | Опыт в IT

FOKIN MEDIA | Опыт в IT

FOKIN MEDIA | Опыт в IT

FOKIN MEDIA | Опыт в IT

FOKIN MEDIA | Опыт в IT

FOKIN MEDIA | Опыт в IT

FOKIN MEDIA | Опыт в IT

FOKIN MEDIA | Опыт в IT

FOKIN MEDIA | Опыт в IT

FOKIN MEDIA | Опыт в IT

FOKIN MEDIA | Опыт в IT

FOKIN MEDIA | Опыт в IT

FOKIN MEDIA | Опыт в IT

FOKIN MEDIA | Опыт в IT

FOKIN MEDIA | Опыт в IT

FOKIN MEDIA | Опыт в IT

FOKIN MEDIA | Опыт в IT

FOKIN MEDIA | Опыт в IT

1 311

Popular in the channel

Site language

Купить живой трафик

Ваш канал уже есть в каталоге?

TGStat Bot

FOKIN MEDIA | Опыт в IT

Channel's geo and language

Category

1 311

Popular in the channel