Agile *

За последние десятилетия у компаний появился внушительный набор управленческих инструментов. Waterfall, Scrum, Kanban, SAFe — каждый описан, стандартизирован, проверен на тысячах внедрений.

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

Всем привет, меня зовут Андрей Храмченков, и я занимаюсь проектным управлением в SENSE. В статье разберём, почему фреймворк не приживается именно в вашей компании и как перестроить внедрение, чтобы оно давало результаты вместо имитации работы.

В первой части статьи мы пришли к выводу, что само использование ИИ не ускоряет инженерную систему. Можно вырастить MAU LLM, потом MAU API, раздать людям кодинг-агентов и всё равно не увидеть изменений в Lead Time, Throughput и Defect Rate.

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

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

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

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

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

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

Добро пожаловать на борт. Физика процесса изменена, но внешне мы стоим на ногах.

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

Привет, Хабр! Меня зовут Марат Киньябулатов, я эксперт по гибким практикам и отвечаю за эффективность инженерных команд в ядре банка. В этой статье расскажу, какие гипотезы мы проверяли при внедрении ИИ, почему рост использования чатов и кодинг-агентов не равен росту скорости, какие метрики помогали отделять привычку от результата и как мы пришли к идее Agentic Engineering.

Меня зовут Дианова Анастасия, я — Lead Delivery Manager в Lenta Tech («Группа Лента»). Я отвечаю за скорость поставки новых фич в приложение для заказа продуктов онлайн. В статье расскажу, как мы переосмыслили роль Delivery Manager’а, когда столкнулись с жесткими ограничениями.

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

На оба вопроса у меня один ответ — все дело в процессах, детка.

В последние десятилетия ИТ-индустрия живет в парадигме «победившего Agile». Любое сомнение в его эффективности клеймится как приверженность «устаревшему водопаду». Однако при более глубоком анализе выясняется, что Agile — это не эволюция управления, а искусная маркетинговая надстройка, которая борется с вымышленными врагами и подменяет системное проектирование ритуальным ремесленничеством.

1. Битва с тенью: миф о «Водопаде»

Главный антагонист Agile — «Водопадная модель» (Waterfall) — в реальности никогда не существовал как общепринятая инженерная практика. Уинстон Ройс в своей статье 1970 года привел линейную схему как пример того, как делать не надо, сразу же предложив итерации и обратную связь.

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

Каждый ноет на ретро. Мы научились ныть так, что работать стало комфортнее и эффективнее. В статье расскажу, что нам помогло.

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

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

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

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

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

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

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

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

Все методологии управления проектами думают о процессе. Я попробовал поставить в центр человека — и получил первую версию продукта за 7 недель вместо пяти месяцев. Рассказываю, как.

Качество процесса ограничено качеством людей, которые этим процессом пользуются

Дело не в количестве регламентов. Небольшая команда может создавать продукт вовсе без них, а папка в Confluence ещё ни из одного джуна не сделала сеньора.

В ИТ намного важнее компетентность людей, чем наличие дцатого регламента. С работы над компетентностью и стоит начинать.

Об этом сегодня и поговорим 🙂

MS Project в 2026 году превратился в токсичный актив: блокировки, замороженные лицензии, серые схемы оплаты. Но прежде чем бежать, честно: если лицензия бессрочная и проекты не выходят за периметр, можно не дёргаться. А если риски перевесили привычку, разбираем 10 аналогов по классам задач (PPM, SDLC, трекеры), с реальной ценой миграции .mpp и честными минусами каждого, включая наш.

Рассмотрим методологию организации рабочих процессов, основанную на ответственности за результат, в противовес понятиям «рабочего времени», «ритуалов» и прочих весёлых забав

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

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

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

Redmine до сих пор делает своё дело — бесплатно, стабильно, на вашем железе. Если у вас 15 человек и настроенный процесс, возможно, менять ничего и не надо. А если упёрлись в плагины и человеко-часы — разбираем 10 альтернатив: с честными минусами, реальной ценой миграции и советом, как не перевезти в новую систему свои 25 кастомных статусов.

За последние несколько лет AI у меня, как и у многих моих коллег, стал одним из основных рабочих инструментов. И речь не только о том, чтобы иногда задать пару вопросов ChatGPT. AI инструменты сегодня способы приносить пользу продакт менеджеру и команде на каждом этапе жизненного цикла продукта — от появления идеи до его релиза в продакшн.

Недавно я завершила исследование, в рамках которого сравнивались два проекта по разработке продукта в сфере кибербезопасности. Один проект создавался без использования AI, второй — с активным использованием AI-инструментов на протяжении всего жизненного цикла продукта. Результат был следующий: суммарные трудозатраты (а, как следствие, и бюджет проекта) по второму проекту по сравнению с первым снизились на 36%.

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

Где именно AI может быть полезен в работе продакта сегодня?

Этап 1. Проверка гипотез и исследование рынка

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

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

В начале 2024 года я устроилась Senior Software Test Automation Engineer в финтех-стартап. После работы в большой стабильной корпорации это был настоящий вызов ― попасть в живой дышащий мир молодой продуктовой  компании, пытающейся занять своё место на рынке. Мне понравился продукт и привлекала возможность влиять на процессы, даже устанавливать новые.

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

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

Однако не всё было идеально, проблем тоже хватало, даже при том, что скорости релизов мы достигли прямо таки нереальной, обеспечивая при этом отличное качество. В этой компании существовала доселе не встречавшаяся мне структура ― инженерное комьюнити. В каждой дисциплине было своё. У инженеров по качеству ― QA Community. Польза его для процветания компании неочевидна при первом взгляде. Как человеку, который любит докопаться до причин всего на свете, мне было любопытно как это работает и почему. В том числе влекомая этом любопытством я спустя некоторое время выдвинула свою кандидатуру на должность очередного QA Community Lead. Да, должность выборная, как президенство, срок правления ― год, потом смена власти. Немного ранее выборов у нас сменился СТО и объявил, что теперь теперь избранный кандидат должен получить также апрув от него, а также он может оставаться на должности дольше, если нет возражений от комьюнити и/или СТО. Или пока не настанет импичмент, а такое тоже было в истории компании. 

Меня зовут Пелых Виталий, я корпоративный архитектор в «БКС Финтех». Разберу тему, которая звучит просто, но в крупных организациях регулярно «выстреливает» в неожиданных местах: как позиционировать архитектуру так, чтобы она помогала бизнесу и командам, а не превращалась в формальность или «бутылочное горлышко».

Сразу зафиксирую рамку. Под «позиционированием» я понимаю не место на оргсхеме, а то, как устроены правила принятия решений, кто за что отвечает и как мы удерживаем целостность ландшафта, не превращая архитектуру в узкое горлышко. По сути это про архитектурную способность (architecture capability) и архитектурное управление (architecture governance), встроенные в повседневный delivery.

Финтех — среда, где изменения идут непрерывно: продукты, регуляторка, каналы, интеграции. Поэтому архитектура здесь либо помогает меняться быстро и управляемо, либо становится тормозом и источником рисков. Дальше — как это устроено у нас: continuous architecture, около 75% архитектурных решений в командах, корпоративная архитектура как ограничение и контроль. И где у такого подхода границы и риски.