Posts

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

Мы прошли путь от первых пользователей LLM-инструментов до массового использования чатов и кодинг-агентов. На дашбордах всё выглядело правильно: люди заходили, пробовали, возвращались, приносили примеры, показывали демо, техлиды учили команды. Метрики потока при этом долго не двигались. Lead Time не снижался системно. Throughput не рос так, чтобы это было видно на уровне инженерной организации. Defect Rate не давал уверенного сигнала, что качество стало лучше. Эта статья — большая версия двух моих постов на Habr: части 1 про рост использования и метрики результата и части 2 про Agentic Engineering и AI-first команды. Здесь я собираю логику целиком: от первых LLM-чатов до следующего слоя измерения, который оказался важнее обычного дашборда внедрения. ...

Agentic Engineering не начинается с оргчарта. Он начинается с момента, когда команда видит полный путь задачи и умеет безопасно отдавать часть работы агентам. Красивая картинка AI-native команды — 2–3 человека, E2E-ответственность, агенты в инженерном процессе, быстрый путь от идеи до продакшена. В большой организации эта картинка сразу встречает годовые цели, бюджеты, стратегические проекты, регуляторные контуры и уже собранные команды. В этой статье — три безопасных маршрута, которые можно запускать внутри текущей структуры: агентизировать нудный run-процесс, выделить 2–3 агентных практиков или собрать микро-юниты внутри команды. ...

Баги — неизбежная часть разработки. В MetaMap мы внедрили Zero Bug Policy и за месяц сократили бэклог с 77 до 18 багов. 60 багов из 77 до старта не имели даже примерной даты исправления. Через месяц таких осталось 11. Главный результат — не красивая цифра. Support и CSM получили реальные сроки для клиентов, разработчики — ясные правила, клиенты — предсказуемость. Проблема: баги по принципу «кто громче» ...

TL;DR: эффективная команда делает три вещи: Достигает бизнес-целей Сохраняет психологическую безопасность и мотивацию людей Предсказуемо доводит работу до результата через стабильные flow-метрики Три вершины. Один треугольник. Исходная история Две финтех-команды три месяца параллельно строили системы управления лимитами. Одна — для кредитных карт, другая — для текущих счетов. В каждой команде 7–8 человек, стоимость — около $100K в месяц с учётом полной нагрузки на инженерную команду. На квартальном ревью выяснилось: 70% функциональности пересекается. ...

Когда смотришь на реальные данные потока, быстро появляется знакомая картина: часть задач заметно стареет, отдельные элементы уже давно вышли за разумные сроки и фактически застряли. Так мы приходим к одной из самых полезных и недооценённых flow-метрик: WIP Aging. WIP Aging показывает, сколько времени элемент работы уже находится в процессе и всё ещё не завершён. Это ранний сигнал проблем в потоке: команда видит, где работа застревает, до того, как задержка сорвёт сроки доставки. ...

Прогнозировать сроки по Throughput проще, чем кажется. Нужна история завершённых элементов, понятные WIP-лимиты и честное отношение к вероятности. Хороший прогноз звучит так: «с вероятностью 50% закончим за 39 дней, с вероятностью 85% — за 50 дней». Это честнее для команды и полезнее для стейкхолдеров, чем дата «ровно через 6 недель». Это продолжение статьи про Throughput как метрику потока. База по метрике остаётся в первой части. Здесь — как превратить историю завершённых элементов в прогноз, вокруг которого можно принимать решения. ...

Русская версия подготовлена на основе моей статьи на Хабре: «Throughput: как научиться перестать гадать сроки и начать их предсказывать через симуляцию Monte-Carlo». Throughput — базовая метрика, с которой начинается разговор о предсказуемости команды. Сначала нужно научиться читать сам поток: по периодам, вариативности и типам работы. Прогнозирование через Monte Carlo — следующий шаг, которому посвящена отдельная статья. Преамбула Заходишь убитый в пятницу в бар. Заказываешь пивной сет. Официант обдумывает в голове: “За последний час у нас было приготовлено 12 заказов, сейчас в работе 4 заказа, новый сет будет пятый в очереди”, а потом информирует нас: “Ваш заказ подадут через 20–25 минут.” ...

Русская версия подготовлена на основе моей статьи на Хабре: «5 причин, почему ваши Story Points не работают (и что делать)». За семь лет воркшопов по Story Points я вижу одну и ту же картину: команды изучают технику, пробуют её несколько спринтов, затем постепенно скатываются к старым привычкам. На маленьком масштабе — одна команда, максимум три — Story Points выглядят отличным подходом. На текущем масштабе у меня совсем другая оптика: 47 команд, около 400 человек в IT; 60% используют Story Points, 40% живут без них. Самое интересное — эти 60% используют их каждый по-своему. Во всяких FAANG про Story Points почти ничего не слышали: максимум всплывают размеры в футболках. ...

(Опыт AI-based fintech KYC SaaS-стартапа для LATAM и Африки) Типичная боль: Sales, Product и Engineering говорят на разных языках Наш SaaS-стартап работал на быстро растущих fintech-рынках LATAM и Африки. Там скорость и compliance были вопросом выживания. Большинство стартапов живёт на венчурные деньги с ограниченным runway, поэтому каждый месяц задержки в доставке ценности означает потерянных клиентов, регуляторные риски и более длинный путь к самоокупаемости. Значит, команда должна быть очень бережливой и точной в выборе работы. ...