Анализируй и проектируй
Система прошла приёмку, но первая реальная нагрузка разогнала p99, исчерпала пул соединений и увеличила счёт за облако.
Разбираем пять ошибок в нефункциональных требованиях и способы превратить их в измеримые ограничения ещё до выхода в прод.
Последний раз я тут писал в 2010 году )). С тех пор многое изменилось и вся моя тогдашняя писанина теперь в чердаке. И заново ее публиковать не вижу смысла.
Если вы системный аналитик, то знакомы с ситуацией, когда приходит бизнес с очередной хотелкой. Начинаете задавать вопросы, получаете ответы, потом еще, и еще. Через несколько встреч у вас набор разных заметок, записок, писем, страниц в Confluence. Если используете современный подходи и используете Чат-бот - то и несколько чатов. А когда одновременно несколько проектов, то все это превращается в мешанину.
И вот, под девизом "Хватит это терпеть" с помощью ИИ-агента в IDE родилось приложение DocGen, или AI-ассистент системного аналитика.
Расскажу, как я сделал своего ассистента, с какими проблемами столкнулся и что получилось.
Три месяца я строил одну и ту же контент-машину для AI/tech-канала тремя способами: вручную с ChatGPT, в n8n и на Python через Claude Code. В статье — архитектура из трёх пайплайнов, реальные тайминги из production-логов, миграция с SubMagic на собственный постпроцесс за один день и практический чек-лист, который поможет выбрать между ассистентом, визуальным конструктором и собственным ИИ-агентом.
Мы решили поручить анализ данных ChatGPT. И быстро поняли, что проблема вовсе не в модели. Оказалось, что LLM может красиво объяснять, но не должна считать. Ошибка была не в промпте, а в архитектуре системы.
В статье рассказываю, почему мы разделили код и ИИ, как избавились от галлюцинаций в аналитике и почему теперь модель объясняет результаты, а не пытается их вычислять.
В статье про юридический техдолг я писал, что он копится незаметно и вылезает через искажённые данные. Теперь покажу, как это выглядит вблизи: одно булево поле в схеме, 142 записи, и система, которая полгода уверенно сообщала неправду.
Мы делаем платформу защиты авторских прав. Дальний конец процесса - взыскание денег по выигранному суду через приставов. Это конвейер: запросили исполнительный лист, получили, отправили, вручили, возбудили производство, дальше либо деньги, либо обжалование бездействия.
Внутри: почему спор «отказ - статус или событие» решил один запрос к проду, три мины Mongoose, найденные на ревью, и регрессия, прилетевшая через двадцать часов после релиза.
Почему API-First уже недостаточно и что меняется, когда SDD строится на .md-файлах и обязательном участии агентов?
В агентном SDD спецификация становится не пояснением к коду, а рабочим контекстом, из которого агент строит план, тесты и реализацию. Это ускоряет разработку — и одновременно увеличивает цену неоднозначности. Разбираем, как превратить .md из документации в управляемый контракт.
Продолжаю серию статей о том, почему корпоративная автоматизация проваливается ещё до начала разработки.
Это третья статья. В первой мы говорили о праве ИТ остановить инициативу, если бизнес не определил проблему и владельца результата. Во второй – о том, как связать требования с проверяемой бизнес-ценностью.
Теперь – о самом неприятном: что происходит, когда риск видели все, решение не принял никто, а виновным после провала назначили руководителя проекта.
В статье – реальный кейс миграции производственных данных, девять месяцев задержки, потерянные деньги, разбор границ ответственности РП и практический инструмент – карта решений.
«Ты же видел риск. Почему не остановил?»
И главный вопрос для спора: обязан ли РП остановить проект, если видит серьёзный риск, но не обладает полномочиями устранить его причину?
Я давно работаю инженером и когда узнал про ТРИЗ очень заинтересовался. Изучив все приемы пришел к выводу - а ведь не надо даже в наше время уже сидеть и долго мыслить над проблемами разработки ведь все основные шаблоны уже описаны. А ведь каждый шаблон это фактически выход из определенной ситуации и проблемы. В начале я сделал приложение в котором с начало показывается название приема и скрыто его значение. По типу приложения для заучивания слов. Но это мне показалось не очень интересным и скучным, поэтому долго я им не прозанимался и вскоре забыл про него.
Вторая жизнь у приложения появилась после идеи сделать по 50 задач на каждый прием и решать их тем самым запоминая шаблон на опыте. Дальше неачались несколько дней мучения клоуда чат джпт на бесплатных тарифах. Они генерили мне для каждого приема по 50 задач. Кстати дисписк не очень справлялся с этой задачей, поэтому и не был использован.
И вот через несколько дней появилось мое приложение. Ну а теперь подробней о нем.
Когда-то я всерьез занялся изучением темы согласий на рекламу и обнаружил, что Федеральная антимонопольная служба (ФАС) ведет открытый реестр дел. Это супер ценные данные для меня как исследователя, но они совсем не структурированы и анализировать их можно только вручную перечитывая каждое дело. Меня это не очень устроило, поэтому я сделал общедоступную карту дел ФАС и хочу рассказать о том, как она работает. Надеюсь, кому-то будет полезным.
От проблем PostgreSQL к скорости ClickHouse. Рассказываем, как переработали архитектуру кеширования для AI-тестов, чтобы выполнять более 2 млн запросов и обрабатывать 20 млрд записей в день, сохранив среднюю задержку поиска элементов на уровне 250 мс.
Я оценил доработку учётной системы в 300 часов, заказчик ответил, что это очень много. Я для него посчитал тот же объём тремя независимыми способами: снизу вверх по пользовательским действиям, через функциональные точки с отраслевыми показателями производительности ISBSG и через COCOMO II. Результат оказался обратным ожидаемому.
Webhook часто воспринимают как простой механизм доставки уведомлений: пришло событие — обработали — вернули 200. На практике именно в этом месте возникают проблемы с двойными начислениями, потерянными событиями и некорректными состояниями данных.
В статье разбираем, какие вопросы должен учитывать системный аналитик при описании требований к webhook‑интеграциям и почему надёжность начинается ещё на этапе проектирования.
Основной сценарий описан, критерии приёмки согласованы, задача ушла в разработку. Проблемы начинаются позже, когда выясняется, что граничные значения, переходы между состояниями и поведение при ошибках каждый участник команды понял по-своему. Разберём, как мышление тестировщика помогает аналитику находить такие пробелы ещё до разработки и формулировать требования, которые одинаково понимает вся команда.
Большинство пилотов с ИИ-агентами не доходят до продакшена по одной причине — у агента нет памяти. Каждая новая сессия начинается с нуля — пользователь заново объясняет контекст, задачи и историю. На демо это терпимо, но в реальной работе быстро становится ясно: без персистентной памяти это не ассистент, а дорогой калькулятор.
Рассказал, как решить эту проблему. Материал будет полезен ML-инженерам и backend-разработчикам, которые сейчас затаскивают ИИ-агентов в продакшен, а также техлидам и архитекторам, которые проектируют такие системы.
Это вторая статья практической серии, продолжающей тему материала «Автоматизировать бардак нельзя навести порядок». Ранее мы ставили диагноз...
Мы перешли в опытно-промышленную эксплуатацию. Контуры работали, пользователи были подключены, подразделения собирали потребность не в Excel, а в единой системе. На управляющем комитете я именно об этом и рассказывал.
Спонсор выслушал и спросил: а что скажут закупщики? Им легче стало работать?
У меня не было хорошего ответа.
Мне понадобилось разобраться, что происходит на большом проекте внедрения: почему сроки едут и куда девается ресурс. Разработку вела внешняя команда, живьём я её не вёл и контекста не имел — на руках были только следы: трекер, вики, гит, списания времени.
Начал я с самого очевидного — померить, кто из аналитиков сколько делает. Провозился неприлично долго, получил красивые графики и всё выбросил. Дальше — почему выбросил и что нашлось, когда я перестал смотреть на людей.
Сразу оговорюсь про две вещи. Первая: это не статья про оценку эффективности сотрудников, скорее наоборот — про то, почему у меня не получилось её написать.
Вторая — про сам кейс. Он тяжёлый. Спринт вдвое больше собственного лимита, треть незавершёнки без движения месяцами, задачи с семнадцатью сменами исполнителя. Нормальным этот проект не был, и типичным я его не выдаю. Полезен он ровно этим: в здоровой команде все описанные ниже эффекты тоже есть, но дают процентов пять и потому не видны. Здесь они дают триста и становятся различимы. Это стенд, а не образец, и интересен тут метод, а не кейс.
Осваивая разработку с помощью AI-агентов, я написал веб-приложение для собственной ежедневной работы. Проект получился довольно сложным: с динамическим обновлением интерфейса и поиском, модальными окнами, автосохранением, интеграциями с внешними системами, модулями машинного обучения, текстовым анализом, фоновыми задачами и автоматическим деплоем. Объём кода составил около 150 000 строк, из которых примерно 120 000 написаны на Rust, а остальные - на TypeScript и Terraform.
Весь этот код сгенерировали агенты - в основном Claude Code и частично Cursor. За редкими исключениями я почти не открывал и не читал исходные файлы.
В процессе разработки я начал замечать странности. Когда в терминале мелькнула правка 4000-й строки в одном файле, я решил посмотреть на код ближе. Выяснилось, что слой доступа к данным разросся до 6000 строк. С каждой новой функцией он продолжал расти. В коде каждого запроса, чтения или записи повторялись настройка HTTP-запроса, кодирование и декодирование JSON. В итоге весь слой доступа к данным оказался в одном файле на 17 155 строк Rust.
Привет, меня зовут Юрий Черепов, я технический лидер системной аналитики в Альфа-Банке. Однажды на внутреннем «митапе» для аналитиков, где мы обсуждали, как AI применять в работе аналитика мне задали вопрос «Не делает ли AI людей «слабее»? Не приведёт ли использование AI к деградации профессиональных навыков? Мы ему всё делегируем и разучимся думать сами»
Вопрос хороший. Хочется разобраться, что происходит и в какое будущее всё движется. Но сначала я бы хотел окунуться в прошлое.
Большие наборы приемочных сценариев часто создают ложное ощущение контроля: тесты проходят, отчёты зелёные, но команда всё равно может пропустить важный переход в логике системы.
В статье разбираем, как превратить разрозненные сценарии в управляемую модель покрытия — через состояния, переходы и явные правила изменения системы. Такой подход помогает аналитикам находить пробелы ещё на этапе проектирования, а не после появления проблем в рабочей среде.
В распределённых системах генерация уникальных ID быстро становится архитектурной задачей: центральная база создаёт узкое место, а переход на UUID может оказаться невозможным из-за унаследованного кода. Разберём рабочий подход с отдельным сервисом, диапазонами идентификаторов и защитой от потери ID при сбоях.