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

Привет, Хабр! Меня зовут Дмитрий, руковожу отделом рекламы и продвижения в Аспро. Мы запускаем интернет-магазины и развиваем систему управления бизнесом Аспро.Cloud.

Команда обычно тратит месяцы на проектирование и запуск. А за неделю до релиза выясняется, что не работает форма оплаты, сайт не проходит по мобильной версии или у него нет обязательных документов. Типовой чеклист запуска ограничивается дизайном, а техническую приемку и новые требования РКН он не покрывает. Есть и отдельная тема: поисковая выдача.

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

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

Когда Atlassian объявила о завершении продаж Opsgenie, я сначала отреагировал как нормальный инженер: решил ничего не переписывать. Потом календарь напомнил, что нормальность имеет срок действия. Продажи Opsgenie прекратились 4 июня 2025 года, а поддержка завершится 5 апреля 2027 года. После этого сервис станет недоступен, а немигрированные данные будут удалены. Это не слух из рабочего чата, а официальная позиция Atlassian (условия и даты завершения Opsgenie).

Предлагаемый путь ведёт прежде всего в Jira Service Management, причём Atlassian описывает автоматизированную миграцию данных и конфигурации (официальная страница миграции). Для многих компаний это разумный маршрут. В моём случае требование было другим: сохранить существующую self-hosted Jira, не превращать замену on-call инструмента в миграцию всей сервисной модели и получить контроль над данными, интеграциями и deployment.

Я посмотрел альтернативы. Ближе всего по общей идее оказался OpsKnight: проект позиционирует себя как open-source self-hosted платформу для incident response, on-call, routing и status pages (официальный сайт OpsKnight). На бумаге соседство было почти семейным. Но мой набор требований включал автоматическое создание задач именно в нашей Jira, Slack и eXpress, прозрачную передачу L2 в L3, русский и английский интерфейс, простое развёртывание и предсказуемое поведение в небольшом внутреннем контуре. В моём тестировании OpsKnight с этим набором не совпал и не дал нужной уверенности. Это не универсальный вердикт проекту, а описание моего опыта и моей планки риска.

Пошаговое руководство по внедрению Claude Team и Claude Code в команду: подготовка инфраструктуры, настройка, мониторинг, метрики и лучшие практики использования AI в разработке.

Правило из CLAUDE.md агент забывает на длинной сессии - это текст, а не механизм. Я разобрал слои дисциплины Claude Code и прибил критичные правила хуками: три гейта, после которых коммит без свежего зеленого прогона тестов не проходит, правка теста поднимает флаг, а завершить работу с грязными тестами нельзя. Под катом механика хуков, код всех трех гейтов с живыми прогонами и эксперимент, где гейт пересилил прямую инструкцию пользователя.

Агент проходит все проверки и сносит то, что трогать было нельзя. Промпт это не лечит — лечит среда вокруг модели. В ноябре я начал собирать такую среду и называл её просто фабрикой разработки. Меньше чем за год из неё выросло почти десять конвейеров, а у занятия, оказывается, есть название: harness engineering. Рассказываю, как оно росло, и показываю схему и скелет в github.

Человек, чей SeaBIOS бутил ваши виртуалки с 2010 года, сегодня единолично решает судьбу прошивки ваших 3D-принтеров. У Klipper один мейнтейнер, один открытый issue — табличка «трекер закрыт» — и сотни висящих PR. Snapmaker переписал 20% кодовой базы, потому что занести тулченджер в апстрим просто некуда. Разбираю на фактах, как устроен governance де-факто стандарта прошивок для FDM — и во что его отсутствие обходится вендорам, контрибьюторам и вам.

В начале июля я объявил весь код своего проекта легаси. Не модуль — всё: код, архитектуру, документацию. Месяц до этого проект — джоб‑маркетплейс для синих воротничков: мобильное приложение, web, AI‑ассистент — делала команда. Люди сильные, каждый уже работал с LLM‑агентами; не было другого — методологии работы с агентами. Агент пишет код быстрее человека — и энтропию порождает быстрее: все ветки в main, решения только в чате, документация врёт, персональные данные оседают в access‑логах. Каждый исполнитель локально прав, система в целом не работает. Код, который страшно трогать, появился у нас раньше, чем первый работающий флоу. Я остановил всё и начал заново — один.

В начале 2026 года я запустил опрос в отделе: «Какими ИИ-инструментами вы пользуетесь?» Из 20 опрошенных только 3 человека пробовали ИИ-агентов в работе. Большинство технической команды — это хардкорные МЛ-щики, которые создают системы поиска патологий на медицинских снимках, а не просто дергают API ChatGPT с нужным промптом.

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

Когда в зависимости обнаруживают уязвимость, очевидное решение — поднять её минимально допустимую версию во всех библиотеках, которые ее используют. Тогда пакетный менеджер не подтянет уязвимую версию даже при новой установке. Сет Ларсон из Python Software Foundation предлагает не делать этого автоматически. По его мнению метаданные библиотеки должны описывать только совместимость, а контроль безопасности сборки оставаться на стороне приложения.

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

В последнее время мы все чаще начали слышать о Product Operating Model. Это не новый фреймворк, а организационная модель управления компанией, которая определяет, как создаются и развиваются продукты, принимаются продуктовые решения, распределяется ответственность между командами и оцениваются результаты их работы. Исчезнет ли традиционный Scrum, всем ли нужно переходить на POM, почему вообще появился этот подход и какие роли он выделяет - в статье.

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

Но есть компании, которые освоили концепцию продуктового разработчика. Такой человек сфокусирован не только на закрытии задач по ТЗ, а еще стремится донести дополнительную пользу и глубоко погрузиться в бизнес. Где-то говорят про T-shaped специалиста, где-то уже — про M-shaped. Мы решили разобраться в этой роли с точки зрения более-менее прикладного контекста через опыт людей, в чьих командах такие специалисты либо уже есть, либо внедряются.

Привет, Хабр! Меня зовут Андрей Квапил, я основатель Ænix — мы делаем открытую облачную платформу Cozystack и помогаем компаниям строить инфраструктуру. Мы полностью удалённая компания: 15 человек, несколько команд (две reliability-команды, команда разработки, маркетинг, бэкофис и т.д.), живем в разных часовых поясах. Поначалу мы жили в GitHub Projects, но когнда начали расти, резко упёрлись в ограничения текущих процессов: задачи размазаны по доскам и чатам, на утреннем синке половина времени уходит на выяснение «а что там у нас вообще в работе», незапланированная работа съедает весь день и нигде отдельно не видна.

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

Привет! Я Александр Субботин, руководитель отдела разработки Content AI.

За четыре года в этой роли я провел больше 50 собеседований, собрал 8 команд и несколько раз разруливал ситуации, когда топ-менеджмент считал, что команда демотивирована и с этим надо что-то сделать. Спойлер: в 90% случаев проблема была не в мотивации.

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

В предыдущей статье о ГОЭЛРО я писал о программе «А»: прежде чем строить новые мощности, план предусматривал восстановление и реконструкцию существовавшего энергохозяйства. Сначала вернуть основанию работоспособность — и лишь затем возводить на нём новое. Исторически эта часть плана действительно называлась программой «А»; такое описание приводит, в частности, Минэнерго России.

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

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

По обе стороны баррикады спор обычно формулируют одинаково: кто должен диктовать автоматизацию — бизнес или ИТ?

Я всё больше думаю, что это неправильный вопрос.

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

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

Меня зовут Юра Ашуров, я тимлид в Точка Банк. В статье расскажу, почему не стоит начинать расследование с профайлера и какие метрики помогают сузить область поиска. Всё это — на примере двух реальных кейсов с высоконагруженными проектами.

Всем привет! С вами на связи Евгений Певцов, эксперт по качеству данных группы развития методологии из МТС. Около года назад мои коллеги уже рассказывали, зачем нам потребовались формализованные соглашения об обмене данными и какую проблему они должны были решить.

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

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

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

Хорошие показатели пилота еще не означают, что внедрение окупится после масштабирования. На INFOSTART CIO CAMP 2026 ИТ-руководители обсудят реальные затраты, ошибки и результаты ИИ-проектов - в том числе тех, которые пришлось остановить.

У большинства историй о внедрении искусственного интеллекта есть презентационная версия: компания определила задачу, команда нашла решение, показатели улучшились, появился экономический эффект.

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

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

Всем привет! Меня зовут Егор Гурин и я разработчик в компании MTC Web Services. Работаю в стриме, который занимается разработкой контактного центра МТС. Практически любые обращения клиентов в компанию, будь то неработающий интернет или вопрос по заказу в интернет-магазине, проходят через нас. 

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

В этом материале я поделюсь инструментами, которые помогли наладить процессы в нашей команде в рамках методологии Document Driven Development, — возможно, вам она знакома под такими терминами как design-first или API-first. Покажу, как в удобной форме описывать контракты с помощью TypeSpec, использовать мокирующие сервера не дожидаясь реализации серверной, а еще — расскажу про инструмент кодогенерации на Go и автотесты с помощью Schemathesis.