FOKIN MEDIA | Опыт в IT

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@fokin_media

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

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

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

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

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

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

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

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

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

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

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

@fokin_media

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

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

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

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

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

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

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

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

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

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

@fokin_media

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

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

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

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

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

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

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

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

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

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

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

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

@fokin_media

👀 Разработчик сделал именно то, что написано в ТЗ

Бизнес получил не то, что хотел.

Кто виноват?

Никто. В этом вся проблема.

Есть структурный принцип, который я видел в каждом достаточно большом проекте: при каждой передаче требований теряется контекст. Бизнес формулирует задачу → аналитик интерпретирует → разработчик читает ТЗ → тестировщик проверяет по критериям приёмки.

На каждом шаге что-то теряется и что-то добавляется. Не потому что люди плохо работают. А потому что устная и письменная передача информации по своей природе искажает.

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

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

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

Требование проходит через людей, как испорченный телефон. Только в конце не смеются.

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

@fokin_media

📌 Планка, которую не видно снаружи

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

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

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

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

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

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

Проблема начинается, когда ощущение «недостаточно» не мотивирует, а изматывает. Когда оно звучит как обвинение, а не как навигация.

Тогда полезно напомнить себе: планка существует, чтобы расти. Не чтобы страдать.

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

@fokin_media

📌 Готовность - это не чувство. Это решение.

Много лет назад я отказался от выступления на конференции. Не потому что не мог - потому что «еще не готов».

Знакомое ощущение?

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

Потом я понял: готовность - это ловушка.

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

Готовность не приходит до действия. Она приходит во время.

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

Готовность - это не чувство. Это решение.

Человек, который ждет готовности, - ждет бесконечно. Человек, который объявляет себя готовым, - начинает двигаться.

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

#карьера #мышление

@fokin_media

📌 Незаменимость - это не достижение

За годы в разных командах наблюдал один и тот же сценарий.

Человек вырос в крутого специалиста. Знает систему лучше всех. Закрывает задачи быстро и без ошибок. Хочет двигаться дальше - сменить роль, попробовать другое направление.

Ему говорят: «Подожди. Ты сейчас незаменим. Найдем замену - поговорим.»

Замену не находят год. Два. Три.

Это не злой умысел. Это структурная ловушка.

Чем лучше ты делаешь свою текущую работу - тем сложнее из нее уйти.

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

Выход из ловушки один: сделать себя заменимым.

- Передавать знания
- Документировать процессы
- Растить тех, кто сможет взять твою работу

Это воспринимается как щедрость. На самом деле это единственный способ двигаться вперед. Пока ты незаменим - ты не свободен.

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

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

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

@fokin_media

👀 Есть человек, к которому идут с настоящими вопросами

Не к тимлиду. Не к архитектору. К Андрею.

Андрей - middle. Без статуса, без отдельного кабинета, без приставки senior в должности. Но когда что-то идет не так - люди идут к Андрею. Когда нужно быстро разобраться - к Андрею. Когда вообще не знаешь, кого спросить, - к Андрею.

Это называется неформальный авторитет. И он сильнее формального.

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

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

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

Это проигрышная стратегия.

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

Найдите Андрея в своей команде. И работайте с ним, а не вокруг него.

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

@fokin_media

🎯 Разработчик снова не успел. Но это не ложь.

- Сколько займет задача?
- Три дня.
- Прошло три дня.
- Ну... наверное еще два.

Знакомо? Это не обман и не лень. Это planning fallacy - когнитивный баг, который Канеман и Тверски описали еще в 1979 году.

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

Мы не врем. Мы описываем мир, которого не существует.

Канеман и Тверски попросили студентов оценить время на дипломные работы. Оптимистичный прогноз - в среднем 27 дней. С учетом прошлого опыта - 48 дней. Фактический результат - 55 дней.

И самое важное: знание об этой ошибке не помогает её избежать. Люди продолжают занижать оценки, даже когда понимают механизм.

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

Как компенсировать:
- Спросить «сколько времени заняли последние три похожие задачи?» - это называется reference class forecasting
- Добавить буфер на уровне процесса, а не просить человека «оценить честнее»
- Считать оценку стартовой точкой, а не обещанием

Буфер - это не недоверие к разработчику. Это признание, что когнитивные баги есть у всех нас.

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

@fokin_media