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

«Разработчики больше не нужны»? Так читается вывод нового исследования Anthropic — ~400 000 реальных сессий Claude Code за полгода. По их данным, с AI-агентами выигрывает не тот, кто умеет кодить, а тот, кто разбирается в своём деле: у не-программистов 26% успеха против 30% у разработчиков, разница всего 4 пункта. Эксперт запускает в 2.4× больше действий агента и вчетверо чаще вытаскивает зависшую сессию. А вот с их выводом я не согласен. С цифрами вопросов нет — но вытащили из них не то. Эксперт-одиночка и правда соберёт прототип быстрее инженера. Только без инженера он не покроет это тестами, не заложит масштабирование и безопасность — и продукт ляжет при первой же нагрузке. Разбираю исследование по цифрам, рассказываю, где это сходится с тем, что я писал раньше, и почему рабочая связка одна: эксперт предметной области + инженер, который знает harness вокруг агентов.

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

Привет! Меня зовут Рома. С 2023 года я отвечаю за технику и архитектуру дизайн-системы в Туту, а с 2025 — возглавляю саму команду. 

За это время я понял: дизайн-система — это сложный и местами болезненный компромисс между кодом, дизайном и бизнесом. Написать гибкие компоненты и собрать UI-кит — лишь 20% успеха. Остальные 80% — это долгие детальные переговоры и поиск точек соприкосновения. Продуктовые команды тоже хотят делать качественный продукт, но их главный ресурс — время.

Есть ощущение, что аналитиков сейчас хоронят чаще, чем джунов. Логика простая: агент пишет код по двум абзацам из чата, значит, точные ТЗ не нужны, значит, и аналитик не нужен. Частично это правда. Есть аналитическая работа, которую я бы назвал механической: «опиши точно, чтобы разраб не переделывал». Для большинства feature-level задач эта часть действительно подешевела: на днях на работе прилетело очередное «слушай, тут чуть поменяем», и я переделал за пару часов между остальными задачами. Раньше это были два дня в стол. Но есть другая часть аналитики: «пойми, что вообще делать». Она никуда не денется. Так, я недавно построил не то. Быстро, дёшево, аккуратно. Не то.

Допустим, вы разработчик. Вам в Jira прилетает задача — сделать на странице пользователя кнопку «Дать денег». Вы делаете кнопку, она появляется на странице, нажимается, запрос уходит на бэк, бэк отвечает 200 OK. Технически все выполнено верно, но заказчик недоволен и вопрошает: «Я уже пять раз нажал на кнопку, почему деньги так и не пришли?».

И где-то между «в ТЗ было написано просто добавить кнопку» и «давайте срочно переделаем фичу до релиза, перепишем кнопку на тумблер и подрубим биллинг» возникает вопрос: кто виноват и почему именно аналитик?

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

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

Многие российские компании привыкли к 1С:УПП (Управление производственным предприятием) и активно ее использовали. Но весной 2026 года разработчики прекращают поддержку этой программы. Это значит, что больше не будет ни обновлений, ни исправлений багов, ни технической помощи от создателей.

В I квартале 2027 г. вендор не будет выпускать обновления 1С:УПП кроме тех, которые потребуются для сдачи отчетности за 2026 г. Законодательные изменения, которые вступят в силу с января 2027 г., поддерживаться в УПП не будут. С 1 апреля вендор приостановит любые консультации по конфигурации (письмо 1С №30064 от 09.12.2022).

Последнее время в опенсорсе много драмы: продолжаются споры о системах ИИ, позволяющих за минуту переписать проект и изменить его лицензию на разрешительную, и опенвошинге, когда доступный код выдают за открытый. Теперь на первые полосы вышла новая проблема — массовый наплыв пулл-реквестов, сгенерированных системами ИИ [ситуацию уже окрестили «слопмагеддоном»]. Обстановка дошла до того, что мейнтейнеры закрывают возможность участия в развитии открытых проектов. Мы в Beeline Cloud решили обсудить проблему и то, как быть контрибьютерам и мейнтейнерам в сложившейся ситуации.

Привет, Хабр! На связи Егор Лаптев — QA Fullstack Java в SENSE на проекте крупного российского банка.

End-to-end тесты UI проверяют только то, что видно на экране: кнопка нажалась, форма открылась, данные отобразились. Но в распределённых системах значительная часть бизнес-логики уходит за кадр — в асинхронные события, которые летят через Kafka. Если событие не дошло до топика или пришло с неверным payload, пользователь этого не увидит, а бизнес-процесс сломается.

В этой статье расскажу, как мы научились проверять Kafka-события прямо в автотестах — без Kafka UI, kcat и обёрточных сервисов, одной зависимостью и так, чтобы это работало в корпоративной сети с SSL. Покажу архитектуру коннектора, разберу три основных проблемы (SSL-сертификаты, конфликты consumer group и асинхронные тайминги), и поделюсь моделью работы инженера в связке с AI-агентом.

Кому будет полезно: QA-инженерам и специалистам по автоматизации, которые тестируют распределённые системы и хотят проверять Kafka-события прямо в автотестах; и инженерам, которым интересна практическая модель работы в связке с AI-агентом — как она ускоряет разработку тестовой инфраструктуры.

Привет, это снова Марк. В прошлой статье я разбирался, как небольшой компании получить собственный корпоративный мессенджер: рассказал немножко про варианты, выбрал Matrix/Element и развернул его в облаке, спрятав за WireGuard VPN. 

Сегодня решил продолжить строить компактную self-hosted-инфраструктуру и добавить поверх того же контура следующий обязательный сервис — собственный Git.

Расширенная версия моего кейноута на ISC.AI 2026 в Пекине. Фреймворк и инструмент открыты — берите, ломайте и присылайте мне, что найдёте.

Однажды я зашёл в компанию через неделю после крупного падения и попросил показать постмортем. Мне показали — с гордостью. Таймлайн поминутно, five whys, аккуратный список action items, owner напротив каждого, разослано по всем спискам. Красиво. «Видите, мы серьёзно подошли».

Я задал один вопрос: а постмортем по прошлому такому же падению — где? Нашли. Открыли. Те же action items. Слово в слово. С прошлого раза не закрыт ни один.

То есть полгода назад уже собирались, уже всё проанализировали, уже назначили ответственных — и ничего не сделали. А потом упало снова, по той же причине, и они снова собрались, снова проанализировали, снова назначили. С тем же результатом, который будет и в следующий раз.

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

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

Привет, Хабр! На связи Наталья Воронько из РТЛабс. Я RTE Аналитической Платформы и ЕЛК, а в прошлом — руководитель проектов и функциональный руководитель. Сегодня хочу поделиться своим взглядом на новую редакцию PMBOK® Guide от Project Management Institute (PMI).

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

Официального русского перевода PMBOK® Guide 8^th edition у меня нет. Я читала английскую версию, поэтому некоторые термины могут отличаться от будущего официального перевода. Для точности буду указывать в скобках оригинальные названия и термины.

Ссылки на информацию о Стандарте и на другие источники института PMI буду прикладывать, но открываются они только с помощью VPN.

Привет, Хабр! На связи Екатерина Серикова и Глеб Дмитриев, мы QA-инженеры в команде Авито Sales. В этой статье мы расскажем, как выстроили процесс обеспечения качества в Распродаже, где сроки нельзя сдвигать, а нагрузка на корчасть почти 2 млн RPM, а цена бага очень высока.

Это не история про «идеальный процесс». Она скорее про рабочую систему, которая помогает не сгореть команде и не терять качество, когда QA в проекте один, а разработчиков восемь.

Распродажа на Авито, где 120 млн пользователей, — это всегда высоконагруженные сценарии без права на ошибку. Поэтому в статье мы объясняем, почему важно подключать QA ещё на этапе идеи, а не тестирования. Перекладывание какой части задач на разработку только ускоряет общий процесс? Что можно скормить ИИ, а что следует выполнять самим? Для чего разделять Seller и Buyer контуры?

Здесь всё на личном опыте, по делу и понятно.

Всем привет! Я Светлана Забирова, лид аналитики в Центре разработки и машинного обучения компании «Инфосистемы Джет». В ИТ работаю уже больше десяти лет, из них половину – в заказной разработке.

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

По заданному контексту ИИ хорошо справляются с кодом, миграциями, OpenAPI, сценариями и документацией. Но агентная разработка быстро начинает буксовать, если входной артефакт остается большой постановкой в Confluence, Word или Jira без строгой структуры и трассировки. Модель теряет важные условия, смешивает уровни детализации, дублирует требования или додумывает недостающие связи.

ИИ не будет работать лучше, если аналитики просто «начнут промптить». Задача решается уровнем выше: требования должны стать инженерным артефактом. То есть относиться к требованиям нужно так же, как разработчики относятся к коду.

Спецификация должна жить в том же рабочем процессе, где живет код. Даже если физически код и требования находятся в разных репозиториях.

Мы решили проверить подход на одном из пилотных проектов, где было все: аналитика, архитектура, backend/frontend-разработка, тестирование и DevOps.

Как мы перевели аналитику из Confluence/Word в SDD-контур и что из этого получилось, рассказываю под катом.

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

MAGNIT TECH — это технологическое ядро крупнейшей розничной сети страны. Более 5 000 инженеров, аналитиков и продуктовых команд разрабатывают, поддерживают и масштабируют свыше 260 ИТ-продуктов и проектов, а также 800 информационных систем — от алгоритмов прогнозирования спроса в 33 000 магазинах до касс самообслуживания с собственным ПО. 

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

Под моей прошлой статьей про КТЗ – коэффициент токсичности задачи (вот она) – был комментарий, на который я сначала не обратил особого внимания. Смысл такой: все, что вы описываете – это результат некачественной работы аналитика и руководителя. Их работу свалили на программиста и назвали методом.

Неприятнее всего, что человек прав. Фиксируй договоренности, проверяй готовность задачи, не отменяй проработку требований, возвращай сырое заказчику – это азбука ремесла. Этому учат на любом курсе по управлению. Любой аналитик с опытом прочитает и скажет: спасибо, кэп.

Только через пару недель после той статьи у меня случилась история, которая показала кое-что неприятное. Я знаю все эти правила. И задача все равно вернулась трижды, хотя на входе мой собственный фильтр поставил ей низший балл.

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

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

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

Несколько месяцев назад в публичном пространстве появилась история, которую в engineering-сообществе стали называть поучительной. Команда AWS использовала внутренний AI-инструмент Kira для ускорения работы. Kira предложила джуниорам сценарий: переразверни продакшн-слой. Инженеры согласились. Следующие шесть часов весь AWS не работал. После разбора полётов компания объявила новое правило: финальный апрув на изменения, предложенные агентом, должен давать сениор-инженер.

На первый взгляд, решение логичное. На второй, уже менее. Если агент генерирует изменения в темпе, к которому люди не привыкли, один сениор превращается в бутылочное горлышко для бесконечного потока PR. Это не решение проблемы. Это антипаттерн, оформленный как процесс.

История AWS точно формулирует главный вызов 2025-2026 годов: AI научился быстро писать код, но индустрия пока не научилась с такой же скоростью его доставлять, проверять и принимать решения о нём. Данные, собранные в рамках масштабного исследования State of AI4SDLC, это подтверждают.

На Хабре есть серия статей, касающаяся заблуждений программистов о, казалось бы, простых вещах: о времени, почтовых адресах, именах и даже дверях. Я недавно пообщался с ребятами, пилящими медицинский софт, и решил собрать набор таких же заблуждений, только применительно к врачебному делу. А чтобы было чуть интереснее, собрал это в виде истории, которой позавидует любой индийский фильм или турецкий сериал.

Итак, перед нами молодой джун Игорь (здесь и далее все имена и фамилии вымышлены), который работает в компании, разрабатывающей софт для больниц. Его только что отправили разгребать легаси-код для ПО, установленного во множестве родильных домов. Одновременно в больницу поступила Елена Соколова, благополучно беременная двойней - будущий кармический спутник Игоря. Но не в романтическом смысле - просто благодаря Елене наш Игорь пройдет через множество Edge-случаев...