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

Если спросить тимлида «сколько story points команда сделает в следующем спринте?», чаще всего ответ будет такой: «Ну, в прошлый раз было около 300, давай возьмём столько же». Потом выясняется, что двое уходят в отпуск, один новичок ещё не разогнался, а треть времени съедят баги. Спринт заканчивается авралом, задачи доделывают в последние два дня, и этот аврал попадает в статистику как «нормальная скорость команды». Следующий план строится уже на нём.

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

Постараюсь вкратце и по делу сугубо. Первое что сразу хочется сказать: спасибо автору!) За рамку: у кода есть цена написания и цена владения, и разъехались они в разные стороны. Также отдельно за то, что он сам оговаривает свои источники, про отчёты Veracode особенно честно. Бухгалтерию беру у него, а тезис ниже мой: следующая строчка счёта приходит не коду, а прогнозам. Нового уже от себя добавляю: перенос механизма с кода на дискурс и то, как выглядит цена владения не в новостях, а на примере моих двух обезличенных проектах.

Почему прогнозы об ИИ стали такими дешёвыми

«Создать дёшево, проверить дорого» не мой механизм. Автор показал его на мейнтейнерах открытых проектов, включая curl: отчёт о несуществующей уязвимости пишется за минуты и несколько центов, а проверять его живому человеку часы. Я механизм не открываю. Смотрю, докуда он дотягивается...

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

В комментариях к той статье справедливо возражали многие: проверка тоже дешевеет. Для кода так и есть = у него есть независимый якорь, ответ, который не зависит от мнения модели. У прогноза же якоря нет. Нет теста, который упадёт, если обещанное не наступит, и никто не платит за ошибку. Похоже, а точнее как показала практика многих, дёшево производить можно не только текст, но и безответственность.

Привет, Хабр! Меня зовут Завур, я фронтенд-разработчик в Selectel.

Сборка, тестирование и развертывание приложения — операции, которые приходится повторять при каждом изменении кодовой базы. С ростом проекта ручная сборка и деплой начинают отнимать время и приводят к ошибкам. Эту рутину убирает практика непрерывной интеграции и доставки (CI/CD).

Если вам нужен независимый сервер автоматизации, который не привязан к конкретной платформе, подойдет Jenkins — open-source инструмент с большой экосистемой плагинов и поддержкой практически любых технологий. Он может собирать проекты из любого Git-репозитория, запускать тесты, собирать Docker-образы и разворачивать приложения.

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

Я к вам пишу — чего же боле?
Агент все может написать.
Но за ошибки поневоле
Придется вам же отвечать.

(Письмо инженера Татьяны к вайбкодеру Евгению)

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

В феврале этого года я, Алекс Гусев, отдал Codex-агенту на переписывание @teqfw/di — библиотеку, которую разрабатывал с 2019 года и в которой годами выверял каждую строчку. Об этом я тогда написал на Хабре. С тех пор программный код вручную я больше не пишу. Не потому, что разучился. Просто теперь эту работу делают агенты.

Заодно из моей разработки почти исчезли Pull Requests. Я не перестал пользоваться GitHub и не отменил проверку результатов. Мне перестала быть нужна процедура, в которой кто-то готовит изменение кода, а я разбираюсь, принимать его или нет.

К этому я пришёл не сразу.

Хабы: Программирование, Разработка, Управление разработкой
Теги: надёжность, архитектура, спецификация, программирование, управление разработкой

Это первый из трёх постов серии «Надёжное программирование: от кода к технологии». В нём — главный тезис и три столпа. Во втором разберём оракульное смещение и эмпирику DORA, Veracode и FormAI-v2. В третьем — конечного аудитора, шкалу L0–L4 и практические рекомендации.

Привет, Хабр!

Я старший инженер-программист в Финаме и автор курса «LLM-разработчик» в Хекслете. Разговор пойдёт о практике LLM-разработки и о бытовых деталях: кому нужен RAG, обязательно ли связываться с большими моделями, каково на рынке LLM-разработки и как попасть в профессию — что уметь, как искать, сколько просить. Если лень читать — я всё это рассказал в видео. А этот материал — для тех, кто больше любит буквы, чем кино. 

Примерно в двадцать четвёртом году весь мир начал более или менее понимать, куда движется история с ИИ и как это можно применить. А в двадцать пятом — двадцать шестом в России тоже очухались: «Божечки, искусственный интеллект можно использовать!». Он, правда, не интеллект, но кого это волнует: все захотели использовать его в работе. 

Как — не знаем. Для чего — не знаем. Бизнес не очень понимает, что конкретно ему нужно — но нужно, потому что «это же революция, Джонни!». На самом деле, это и правда революция, но, как с любой революцией, нужно понимать как, для чего и куда её использовать.

К вам может прийти CEO и сказать: «Мы хотим везде использовать искусственный интеллект: внедряем его в разработку, в CI/CD, в оценку, в код-ревью, в постановку задач, в работу с ассистентами». И во всех этих историях действительно можно применить ИИ, вплоть до того, чтобы гендиректор мог себе заказать кофе при помощи чат-ботика.

Год назад я копировал файлы в чат с нейросетью по одному. Сейчас агенты читают проект сами через MCP‑сервер, и месяц наблюдений за ними удивил сильнее, чем вся предыдущая работа: почему текстовое дерево дороже JSON, почему папку build нельзя пропускать по имени, как спрятать пароль и не сломать код, и что агент делает с контекстом, когда его никто не контролирует.

Дежурные оттягивали звонок как можно дольше. Сервис частично не работает, дежурный это видит, понимает, что сам может не справиться, и всё равно не звонит. Пробует ещё одно действие, потом ещё одно, ждёт.

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

Что произойдет, если AI‑программист будет получать контекст не из собственного чата, а из функциональной и архитектурной модели проекта?

ERP‑Tools совместно с Cursor пилят сайт и документируют систему.

Codey ведёт задачу от Jira до работающей фичи. Рассказываем, как устроена наша мультиагентная AI-система и почему для внедрения AI в разработку одной сильной модели мало: нужны чёткие требования, подготовленные проекты и измеримые проверки.

Я уже писала, как мне хочется среди всего этого технического многообразия рассказывать о людях из IT. Сегодняшняя история — о человеке, который умеет задавать правильный темп системам и людям. Наш Technical Project Manager Олег Скуратович, который прошёл путь от Senior SQL-разработчика и тимлида до проектного управления, по вечерам (неожиданно) становится за дирижёрский пульт и руководит хором в протестантской церкви.

У нас получился интересный разговор без сценариев из «Severance» о том, почему «правильная нота, спетая в неправильное время — это фальшь» как в музыке, так и в релизах, чем проверка акустики зала похожа на pre-production verification, почему 20 сильных «звёзд» в одной команде сами по себе никогда не станут работающим ансамблем.

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

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

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

Если в пути импорта в CLAUDE.md есть пробел, Claude Code обрывает путь на нём, файл не грузится, а ошибки нет. Так у меня ни разу не загрузились два общих справочника, на которые ссылался CLAUDE.md. Я собрал пустой проект, разложил по файлам кодовые слова и спрашивал агента, какие слова он видит, запретив ему читать файлы. Вышло, что ссылка на документ в CLAUDE.md ещё не значит, что агент его прочтёт: у каждого способа ссылки свои правила загрузки.

Привет! Меня зовут Анна, я архитектор Naumen Project Ruler. Я отвечаю за то, как устроена система: чтобы она соответствовала методологиям проектного управления, но при этом не оставалась «теорией из учебника». Мы проектируем Project Ruler достаточно гибким, чтобы он встраивался в реальные процессы разных компаний и учитывал разные подходы к управлению.

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

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

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

От Железа к собственным VST плагинам

Я музыкант без навыков программирования. Продал свой железный сетап, не нашёл плагинов для живой игры и начал делать их сам с Claude Code. Рассказываю, как появились собственные синтезаторы и графовый движок и почему главным в работе с ИИ оказались правила, а не промпты.

Недавно в блоге издательства БХВ вышла статья, что в ИТ-литературе надо больше внимания уделять темам построения команд, управления людьми и разработкой продуктов (продакт‑ и тайм-менеджменту). На наш взгляд, это хорошее начинание, ведь книги по «чистому ИТ» очень быстро устаревают, а вот про ведение бизнес-процессов и личностный рост специалистов — тема почти вечная. Книга Дианы Монталион «Изучаем системное мышление» — перевод Learning Systems Thinking, вышедшей в O’Reilly, как раз в этой струе.

В первой части мы рассмотрели теорию, лежащую в основе концепции луковой архитектуры. Теперь предлагаю рассмотреть практическое применение. Будет МНОГО кода.

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

В этом году я попробовал максимально автоматизировать эту работу. Получились три последовательных подхода, собственный YAML-оркестратор, внешний workflow на Dify с Tavily и офис AI-сотрудников с распределённой ответственностью. SEO оставалось задачей, для которой последовательно менялось устройство оркестрации.

Пять человек, шесть спринтов и AI-ассистент для продавцов маркетплейса. Архитектура, интеграции, тестирование, автономные ответы — всё хочется уместить в квартал. Как понять, что план выполним, а не просто красиво выглядит на доске?

На учебном кейсе разбираю, как свести объём работ с возможностями команды, пересчитать доступное время по ролям после замены backend-разработчика на QA и связать этапы запуска с зависимостями, резервом и критериями успеха. Внутри — исходная доска, расчёты и вариант доработки квартального плана.