Планирование, отслеживание и контроль
В первых двух статьях я рассказывал, как мы в команде ИИ-автоматизации строили внутреннюю платформу для клиентской поддержки. И все было успешно.
Но в какой-то момент прогресс практически остановился.
Сначала я думал, что проблема в моделях, качестве промптов или архитектуре агентов. Но причина оказалась совсем в другом — в подходе к автоматизации. Сейчас расскажу, в чем именно.
Как планировать ресурсы и балансировать нагрузки в облаке? Многие привыкли думать о нем как о каком‑то бесконечном ресурсе — нажал на кнопку, и через несколько секунд виртуальная машина готова. Но это ощущение безграничности, на самом деле, результат большой работы.
Привет, Хабр! Я — Анастасия Стоянова, менеджер эксплуатации K2 Cloud. В этой статье вас ждёт:
— рассказ о физической и виртуальной инфраструктуре;
— пояснение, почему ВМ ≠ сервер;
— описание цикла capacity management с расчетом потребности по трендам, целевым запасом под рост, закупкой и вводом новых мощностей, сверкой плана с фактическим потреблением;
— механизмы помогающие пережить пики нагрузки;
— и многое другое.
Привет! Меня зовут Елена Сухова, я руковожу Центром роботизации бизнес-процессов в БКС. В отличие от многих подобных центров в финансовых организациях у нас очень маленький коллектив – всего 4 человека. Тем не менее, уже 5 лет мы успешно роботизируем процессы в компании и намерены заниматься этим и дальше. Сейчас у нас в эксплуатации больше 40 роботов, которые экономят около 30 тысяч человеко-часов в год, и ещё десяток в разных стадиях разработки.
В этой статье я расскажу, какие правила и решения позволяют нам сопровождать этот парк, не забывая о разработке новых роботов и общем развитии.
У нас в компании давно живёт странная двойственность. Я как руководитель смотрю на проект сроками, вехами и деньгами. Разработчик смотрит на него колонкой «в работе». Это два разных языка, и переводчиком обычно работает статус-митинг на сорок минут, после которого никто не стал умнее.
Мы пришли к схеме, где OpenProject остаётся инструментом верхнего уровня, а канбан-доска — рабочим местом команды. У нас в роли доски PLANKA: self-hosted, с OIDC через Authentik, живёт на нашем же контуре. Ниже — как это устроено и, что важнее, где эта конструкция ломается. Я специально не буду обещать, что всё это собирается за вечер.
К началу июля я выгорел. Первую версию я дебажил несколько недель и в какой‑то момент понял, что в 47 раз запускать симулятор я не готов. Наклепал скриншотов, сложил в папочку, показал Клоду и сказал: «Шурши и не булькай». Сам собирать вайбовую лампу дачную лампу из того что нашел в гараже.
Вернулся через 2 часа. В браузере полностью заполненная форма App Store Connect и синенькая кнопка «Отправить на проверку». Нажал. Все сработало — первая версия приложения ушла на проверку в эпл.
Сколько бы мне потребовалось времени, чтобы на работе организовать отправку приложения в стор? Я сидел и честно говоря был «поражен». ИИ управлял браузером, разобрался интерфейсе сайта, и нормально заполнил поля, о существовании которых я даже не думал.
Через неделю я загружал следующую версию и решил сравнить, сколько времени на это уходит у меня самого. Не вышло вообще. Apple сыпала ошибками и душила всем чем могла: скриншоты определенного размера и формата, какие‑то подпункты, поля, про которые я не знал. Я считаю, что терпение это моя сильная сторона и его хватило на +‑ на 24 минуты. Потом я позвал Клода, у него весь процесс занял 10 минут.
Вот после этого мне и захотелось рассказать историю целиком.
Почти каждый основатель SaaS или мобильного приложения в какой-то момент приходит к одной и той же мысли: «Может, проблема не в продукте, а просто о нас пока никто не знает?»
Именно с этой идеей разработчик фитнес-приложения GainFrame решил всерьез протестировать платное продвижение. За три месяца он потратил $5674 на рекламу в Apple Search Ads, TikTok и Reddit. Первые результаты выглядели отлично: установки росли, пробных подписок становилось все больше, графики уверенно шли вверх.
Но когда пришло время считать деньги, выяснилось, что почти каждая новая продажа приносит убыток.
Когда я прочёл о том, что Андрей Карпати больше не пишет код руками, а перешёл на агентное программирование, я, честно говоря призадумался. Скажи об этом кто-то другой, пропустил бы мимо ушей, но именно его слова стали сигналом - в своей работе, и в группе разработчиков придётся что-то менять. Как известно, личный пример - лучший способ убедить коллектив и повести за собой, поэтому пришлось пробовать.
Первой же пробой пера стал вовсе не Todo-app, а самый что ни на есть хардкорный энтерпрайз. Задача - создать полноценный аналог интеграционной шины CellWorks MBX. Это ключевой элемент автоматизации завода по производству полупроводников: она связывает в единое целое MES-систему и сотню единиц технологического оборудования. Мы как раз начинали перенос легаси-стека с PA-RISC-серверов на x64, и вопрос портирования старого транспорта стоял остро.
Вторым проектом стала имитационная модель этого производства. Нет-нет, это не аналог factorio, в ней ни намёка на 3D или игровые механики. Это симулятор реального цеха: с моделями оборудования, технологическими маршрутами, реальным незавершённым производством, производственным планом на годы вперёд (при желании). Эта модель отвечает на вопрос: какую продукцию и в какой срок я потенциально смогу выпустить, если запущу в работу вот столько-то сырья, и оборудование не встанет надолго из-за поломки или отсутствия материалов. Результат превзошёл ожидания. Софт, который раньше создавался большими коллективами, благодаря ИИ и open-source, теперь можно создавать практически в одиночку, и активно внедрять в реальное производство!
Всем привет! Меня зовут Олег Джулаев, я автор Projecto.
Этот материал больше не о том, что классические блоги и инфосайты вымирают как класс, а о том, что с этим делать бизнесу и обычным пользователям. Сразу обозначу: никакой рекламы GEO/AEO и чего-то ещё в таком духе не будет. Просто взгляд со стороны – с высоты пройденного пути и опыта.
Веб как живой организм. Сеть постоянно меняется: сайты и сервисы адаптируются к потребностям пользователей, а сами пользователи вынуждены свыкаться с трендами и изменениями в сайтах или сервисах… Яндекс Музыке отдельный пламенный привет! Получается круговорот.
Для танго вроде нужны двое, но ИИ буквально всё изменил, поставив привычный ритм изменений с ног на голову. Это и не хорошо, и не плохо. Но имеем то, что имеем…
Система прошла приёмку, но первая реальная нагрузка разогнала p99, исчерпала пул соединений и увеличила счёт за облако.
Разбираем пять ошибок в нефункциональных требованиях и способы превратить их в измеримые ограничения ещё до выхода в прод.
Привет, на связи Рома Миронов из Авито. Я бывший — хотя бывших не бывает — фронтендер, а сейчас тим- и техлид. Ковыряю AI и больше ничем не занимаюсь — кроме команды, конечно :) В этой статье расскажу, почему фронтенд пока не умер, какие задачи уже можно отдавать агентам, где они красиво ошибаются и почему сначала от AI становится больнее, а не легче.
Кодинг-агенты — отличный инструмент, пока проект помещается в контекстное окно. Но чем дальше в лес, тем толще партизаны: с ростом кодовой базы начинается деградация контекста, потеря архитектурных решений, “саботаж” инструкций и другие неприятности.
В статье я предлагаю простой файловый подход, помогающий сохранить знания о проекте вне контекстного окна, сделать поведение агента более предсказуемым, а разработку контролируемой. Разберём, как организовать постоянную память и управляющий слой проекта, какие принципы действительно работают и где проходят границы такого подхода.
Показатели каждой новой версии LLM моделей стабильно превышают предыдущие, но при этом они не отвечают на вопрос: какой cli агент лучше использовать при разработке. Я решил попробовать сравнить три агента Codex, Claude Code и Kimi на одной реальной задаче в одинаковых стартовых условиях, чтобы посмотреть чем реально отличаются результаты их работы. И результат меня удивил.
Заказчик уверен, что объяснил задачу. Команда уверена, что поняла её правильно. На демо выясняется, что все говорили о разном.
Разбираем, где в цепочке поставки теряется смысл и какие практики помогают обнаружить искажения до начала разработки.
Что делать, если:
• всю продуктовую разработку разместили в одном Jira-проекте, рассчитывая на «единообразие любой ценой»;
• у бэклога и процессов нет явного владельца;
• команды работают над крупным омниканальным продуктом со сквозными интеграциями и зависимостями;
• релизы взаимозависимы, классический Scrum не подходит, а переход на Waterfall никто не хочет даже обсуждать;
• методология приоритизации целей существует, но применяется только эпизодически;
• приоритеты обсуждаются раз в квартал, а затем команды самостоятельно ищут ресурсы для кросс-командных доработок.
В статье я расскажу, что происходит, когда множество продуктовых и сервисных команд ведут бэклоги в одном Jira-проекте, и как выстроить сквозную приоритизацию с минимальными изменениями существующей системы.
Промпты, документация и skills сами по себе не передают ИИ‑агенту инженерный опыт. Рассказываю, как мы выстроили работу через декомпозицию, эталонные реализации, few‑shot и постепенное доверие к тестам — без вайбкодинга и автономной генерации тысяч строк кода.
Под моей прошлой статьёй (про Scrum, который натягивают на всё подряд) читатель описал ситуацию, от которой у меня знакомо заныло под ложечкой. Пересказываю по памяти и анонимно: «У нас под предлогом адаптации отвалились оценки и демо. Команда называет это гибкостью. И теперь нечем показать бизнесу, что разработка вообще работает».
Если убрать эмоции, это самый частый вопрос, который я слышу после «какой фреймворк выбрать»: чем доказывать, что разработка работает, когда привычную витрину (оценки, графики сгорания, демо) разобрали? Я тогда пообещал в комментариях, что следующая статья будет об этом. Выполняю.
И сразу договоримся на берегу, чтобы не было ложных ожиданий. Это не манифест «долой story points». Скорее наоборот: я story points люблю, пользуюсь ими и на нескольких местах работы сам же их и внедрял. Но люблю я их как инструмент с понятной задачей, а не как подорожник, который прикладывают к любой ране в надежде, что само заживёт. Разговор впереди вообще не про оценки. Он про прозрачность: что видит бизнес, когда смотрит на вашу разработку. И почему «мы стали гибкими» так часто на деле означает «нас теперь не видно».
Прошлая статья была про структуру (как собрать несколько команд вокруг одного продукта), чтобы они не мешали друг другу. Эта — про видимость: что показывать бизнесу вместо театра оценок, чтобы вашему слову верили. Потому что оно сбывается. Всё из практики: департаменты до восьми команд, квартальные обещания, свои шишки. Цифры в примерах иллюстративные: честность мне дороже красивого графика.
Привет, Хаброжители! Сегодня мы хотим рассказать вам побольше о нашем новинке: «Метрики программной архитектуры. Кейсы, повышающие качество ПО».
Это не монография, а сборник из десяти самостоятельных глав от десяти архитекторов (Форд, Фарли, Лилиенталь, Вудс, Роза и другие), объединённых темой измерения качества архитектуры. Единой теории в книге нет, но есть рабочий код, формулы и параметры оценки, которые можно перенести в проект сразу — от DORA-метрик и фитнес-функций до GQM-подхода.
Еще в 22-м году я рассказывал, как за довольно небольшой промежуток времени мы смогли ворваться в ТОП-3 финтех-приложений для малого и среднего бизнеса. С тех пор уже состоялось новое исследование MarksWebb 24-го года, в котором мы стали лучшими. В мае текущего года мы стали серебряными призерами — с колоссальным отрывом от всех остальных преследователей.
На связи Кирилл Маканков, iOS-разработчик из ПСБ.
В новой статье я хотел бы рассказать о тех системных изменениях, которые мы целенаправленно продолжаем вносить в процессы разработки, чтобы достичь этих почётных званий. Статья будет полезна:
1. руководителям всех направлений разработки, так как показывает, где и как находить неэффективные процессы, и, самое главное, — как радикально повышать их эффективность;
2. архитекторам программного обеспечения, так как именно они ответственны за эффективность процессов разработки;
3. рядовым разработчикам, так как показывает эффективные процессы, которые позволяют меньшими затратами получать существенно большие результаты и тем самым выдерживать конкуренцию на современном рынке.
Адаптация разработки в Spec Kit от GitHub на основе спецификаций (Spec-Driven Development) под репозиторий в Cursor – без универсальной командной строки инструмента, с той же дисциплиной: сначала согласовать спецификацию, затем реализовать
Лет 6 назад я мог убить вечер в документации или в исходниках фреймворка ради одного метода. Докапывался до ядра, находил способ заменить 15 строк на 3 и ходил довольный неделю. Это был спорт: я знаю платформу глубже, чем ее среднестатистический разработчик.
Сейчас я пишу агенту: подними xhprof на дев-стенде, прогони сценарий оформления заказа, агрегируй, покажи топ виновников. И иду наливать кофе