Управление разработкой *

В продуктовой B2B-компании, где я отвечал за надёжность, поставили амбициозную цель: сократить цикл разработки (dev cycle time) на 20%. Забегая вперёд, скажу: к концу года цель достигли. Но уже через несколько месяцев после старта я смотрел на график инцидентов и не верил своим глазам: рост в два раза год к году.

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

Привет, меня зовут Дарья, я ИТ-бизнес-партнёр в банке. Часто при внедрении ИИ возникает вопрос: а нужно ли сначала стандартизировать процессы? Какой эффект это даст?

В моей статье ниже мы подробно разберем, почему при отсутствии единых правил агент вынужден восстанавливать контекст, а не контролировать результат. На примере агента, анализирующего квартальную отчётность, мы убедимся: хаотичная декомпозиция создаёт до 262 144 вариантов структуры, тогда как стандарт сводит проверку к типовому шаблону и в модельном расчёте сокращает объём входных токенов примерно на 73%.

Есть два способа лишиться контроля над собственным интернет-магазином.

Первый - это арендовать платформу (InSales, OpenCart, Битрикс, конструктор). Вы платите за тариф и приложения, а код, данные и правила здесь не ваши. Второй, менее очевидный - это заказать разработку «под ключ» и получить чёрный ящик, который знает только подрядчик. Формально код ваш, но тронуть его без той же команды нельзя. Лок-ин просто переехал с платформы на агентство.

Мы перевезли собственный магазин (fashion-бренд IWANT) с InSales на свой движок и на этом опыте собрали переиспользуемый пакет переезда. Один из принципов пакета, отдавать клиенту не «сайт», а agent-ready репозиторий: проект, устроенный так, что дорабатывать его можно самому через админку, силами AI-агента по инструкции в репозитории либо через нас. Ниже пишу что за этим стоит и где границы.

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

В компании «Первого Бита» для этого внедрили единый управленческий контур EvaTeam, поверх системы настроили аналитический HTML-дашборд. Через API он собирает данные, помогает находить слепые зоны и принимать управленческие решения на основе фактической загрузки команды.

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

AI уже вошёл в работу IT- команд. Доступы выдали, обучение провели, демо показали, и как будто активность в инструментах растёт. А Lead Time (время от взятия обязательств до прода), Throughput (сколько работы команда делает) меняются гораздо медленнее. Иногда не меняются вообще.

Сопротивление AI в такой ситуации полезно читать как диагностику системы. Оно показывает место, где команда ещё не договорилась: про цель, инструмент, ответственность, безопасность или поток работы.

«Всем привет! У нас изменения в регламенте!»
Если ваше утро начинается с такого сообщения на планерке или в чате — вряд ли его можно назвать добрым. Потому что первая реакция — «не надо!»

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

Ниже несколько приемов для тех, кто внедряет изменения и несколько шагов для тех, кто эти изменения переживает.

В течение почти трех десятилетий IBM была не просто техногигантом, а абсолютным монархом в мире интеллектуальной собственности. С 1993 по 2022 год корпорация неизменно занимала первое место по количеству патентов, полученных в США, создав вокруг себя мощнейшую «патентную стену». IBM называли «крестными отцом интеллектуальной собственности», поскольку другие IT-компании были вынуждены при запуске новых продуктов идти на поклон к «дону» и покупать лицензии, а иногда приобретать и сами охранные документы (так, например, поступил Марк Цукерберг в первые годы существования своего детища). Принцип IBM был прост — патентовать всё, что только можно: от летающих дронов-доставщиков кофе до иконок на сайтах. Лицензирование и продажа объектов интеллектуальной собственности приносило отнюдь не баснословные, но вполне приличные деньги ветерану Кремниевой долины. 

И тут у нового руководства IBM появилось видение и что-то пошло не по плану.

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

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

Привет! Я Владимир Крылов, продуктовый дизайнер и тимлид. В этой статье я поделюсь опытом проведения ретроспектив по методологии Squad Health Check, придуманной в Spotify. Расскажу, почему нам не подошел стандартный формат ретроспектив, в чём суть метода, какие темы для анализа проблем мы выбрали и к каким результатам в итоге пришли.

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

Быстрее адаптироваться к изменениям, разбирать реальные сценарии и лучше понимать собственную кодовую базу команде помогает регулярный обмен находками. Как его организовать? Давайте разбираться.

Ошибки в разработке неизбежны, но они помогают расти. Я Стас Иванкевич, техлид в команде разработки управляющего слоя Platform V DropApp в СберТехе. Наша команда придерживается простого принципа: не наступать на одни грабли дважды. Из каждой ошибки стараемся извлечь урок и больше её не повторять, а ещё лучше — учиться на ошибках других. Поэтому мы развиваем культуру открытого обсуждения ошибок и не закрываем глаза на возникающие сложности.

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

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

Привет, Хабр! Меня зовут Аркадий Озеров, менеджер в ИТ-команде Россельхозбанка, и я продолжаю делится историей роста своей команды. Мы выросли с 7 до 25 человек, а я продолжал управлять так же, как раньше. И это превратилось в проблему.  Как не утонуть в хаосе при росте команды в 4 раза? 

Привет, Хабр! На связи – редакция ICL Services. В этом году нам исполняется 20 лет, и за этот период произошло много интересного. Кто-то знает нас как Fujitsu Russia GDC, и будут правы – ведь некогда мы действительно входили в состав крупной международной группы, выполняя проекты для зарубежных заказчиков.

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

Мы запускаем триптих статей о людях, которые видели все – тех, кто пришел в компанию на заре её становления. Это наши «динозавры» — сотрудники, чей стаж перевалил за 15 лет. Их истории — это не просто рассказы о работе, а живая летопись компании, сотканная из заграничных командировок, огромного креатива, сложных международных проектов и удивительных встреч.

Наш первый герой — Петр Сапаркин, руководитель направления разработки ПО. За его плечами путь от «зеленого» разработчика до лидера команды из 300+ специалистов, по сей день работающей со всемирно известными корпорациями из разных отраслей бизнеса. Это рассказ о том, как карьерный тупик может обернуться судьбоносным витком, а случайный звонок — открыть дверь в мир глобального ИТ.

Искусственный интеллект уже ускорил написание кода, а способность систем безопасно принимать изменения осталась прежней. Отсюда – аккуратные пулл-реквесты, зелёные тесты и инциденты, которые проявляются только в продакшене. В статье разбираем, где возникает этот разрыв и какие инженерные guardrails помогают удержать скорость без роста хрупкости.

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

Это 2 часть материала про переход, 1 часть про самые распространенные заблуждения и ошибочные представления о системе 1С:ERP в статье https://habr.com/ru/companies/infostart/articles/1051952/

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

Мультимодельная оркестрация – модная: вместо одной модели дёргаешь несколько разом, а отдельная модель-судья сводит их ответы в один. OpenRouter продаёт это под именем Fusion, Sakana AI – под именем Fugu, и обещание у обоих одно: связка обходит любую одиночную модель. Я решил проверить на реальных рабочих задачах – и первое место действительно занял оркестратор, обойдя и Claude, и GPT, и Gemini поодиночке.

Звучит как слайд из презентации вендора – примерно это и написала про свой Fusion команда OpenRouter. Но у меня остались логи всех 541 API-вызова: токены, деньги, время. И они портят красивую картинку. Например, 68% всех денег внутри Fusion уходит на один-единственный Claude Opus – выходит, за качество я доплачиваю больше чем вдвое, по сути, за обёртку вокруг модели, которую мог вызвать напрямую.

Дальше – по логам: как Fusion устроен изнутри, какие модели он дёргает на самом деле, где оркестрация реально бьёт одиночную модель, где сливает ей, и окупается ли она своих денег и полутора минут на ответ.

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

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

Эта статья как раз про этот переход: от разовых LLM-находок к skills, agents и инструменту, который помогает доставлять их до команды.

Хабр, привет! Меня зовут Андрей Пронин, я руководитель «бирюзовой» студии заказной разработки ProninTeam и наставник на курсе по управлению командой разработки в Яндекс Практикуме.

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

В апреле 2026 года глава Google Сундар Пичаи сказал, что 75% нового кода Google сгенерировано AI. Динамика: 25% в начале 2024 года, 50% к концу 2025 года, 75% к апрелю 2026 года.

Согласно Sonar 2026 State of Code Developer Survey, 96% разработчиков не доверяют функциональной корректности AI-кода полностью. 95% тратят время на его проверку, тестирование и исправление, а 38% считают такое ревью более трудоемким, чем проверку кода, написанного человеком. Генерация кода подешевела, контроль за ним - нет.

Thoughtworks в Technology Radar vol. 34 (апрель 2026) ввел термин codebase cognitive debt - разрыв в понимании между человеком и кодовой базой, который растет по мере того, как AI генерирует все больший объем кода.

Узкое место производственного процесса сместилось с написания спецификаций и кода на постановку задачи AI (intent) и контроль генерации (review): что именно должна делать система, в каких границах и кто проверяет, что AI-агент сделал именно это. Код производится быстрее, чем кто-либо успевает подтвердить его соответствие требованиям. Качество, стабильность и сопровождаемость держатся на том, кто и как организует постановку и проверку. Это зона ответственности архитектуры.

Квалификация архитектора смещается от проектирования общих и детальных архитектурных решений к владению контекстом системы, спецификациями и AI-платформой.

В этой статье я, Алексей Соболеков, архитектор решений, разберу изменение роли архитектора в агентной разработке. Я прошел три модели архитектурного процесса.