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

Почему всё, что не Agile, плохо продается

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

Звучит скучно, да? И никого это не зажигает. А теперь другой сценарий: «Давайте откинем старые методы, забудем про скучные процессы, начнем быстро делать прототипы и доставлять ценность через неделю!»

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

Эджайл — это не про свободу, это про ответственность

Многие менеджеры смотрят на Agile и думают: «Вот — кайф! Можно делать что угодно, и никто ничего не скажет. Документация? А зачем? У нас же Agile! Процессы? Какие процессы? У нас свобода!» И это первая ошибка.

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

Почему в Agile всё часто идет не по плану

Agile в руках неопытной команды — это как спорткар в руках человека, который только вчера получил права. 

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

То же самое с Agile: методология не работает без опыта. Нужно не просто знать, как писать код или делать продукт. Нужно понимать, когда создание продукта по методу «быстро и грязно» — это нормально, а когда это же «быстро и грязно» обернется адовым рефакторингом через три месяца.

Как понять, когда «быстро и грязно» = «чисто и прибыльно» 

Вот тут и начинается самое интересное. Чтобы нарушать правила (делать «быстро и грязно»), надо сначала стать экспертом в этих самых правилах. А на это нужно потратить годы, чтобы сначала делать всё как положено. Только тогда придет понимание, где можно схалтурить, а где — нельзя.

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

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

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

Agile — это ответственность и дисциплина. Но как случилось так, что идея гибкости, нацеленной на результат, превратилась в бесконечные стендапы и ритуалы ради галочки? Причина в том, что многие компании стали больше подражать Agile, чем внедрять его суть. Это как строить картонный макет самолета в надежде, что он полетит и довезет пассажиров из точки А в точку Б в целости и сохранности.

Смерть Agile: как культ гибкости привел к хаосу

Что общего у Agile и искусственного интеллекта? Джуны их обожают, мидлы используют как инструмент, а сеньоры смотрят на всё это с отвращением, потому что слишком много времени уходит на то, чтобы достичь приемлемого уровня качества. 

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

Давайте разберем, почему Agile мертв (ну или почти), кто виноват и что с этим делать.

Культ Agile: зачем строить самолет, если можно сделать его макет

Помните историю про карго-культ? Островитяне, увидев, как самолеты привозят блага, начали строить макеты взлетных полос и деревянные радиовышки в надежде, что грузовые самолеты прилетят к ним и привезут продукты. В Agile та же история: люди повторяют ритуалы, не понимая сути.

Стендапы, стори-поинты, диаграммы сгорания задач — всё это давно превратилось в механические действия, которые не дают результата. Зачем команде из пяти человек считать задачи в стори-поинтах? Нужны ли ежедневные ретроспективы? Почему на запуск MVP уходит месяц планирования? Ответ один: потому что никто толком не понимает, как работает Agile.

Мифы об Agile: что вы делаете не так

Миф №1: Отсутствие документации — это ОК

Люди читают «Agile Manifesto» и видят: «Отношения важнее документации». И всё — документацию можно не писать, главное, чтобы все друг друга любили. Но это не так. Отсутствие документации создает хаос. Без описания процессов и продукта вы получите три созвона по 3 часа вместо одной выполненной задачи.

Расстрою половину менеджеров, но хорошая документация нужна. Она экономит время, нервы и деньги.

Миф №2: Игнорирование процессов — это ОК

Agile не про то, чтобы делать всё на лету. Это про то, чтобы быстро адаптироваться к изменениям. Если вы сразу садитесь писать код, не спроектировав архитектуру, то получите хаос. Настоящий Agile — это когда планирование и имплементация идут рука об руку.

Я долгое время занимался «факап-менеджментом», и в 80% случаев причина того, что в компании хаос — это нарушение этих самых процессов. Например, начать разработку кода без Product Vision, отложить архитектурное планирование, не создавать промежуточные спецификации по особо сложным функциям и т. д. А потом сидеть, хлопать глазками и удивляться: «Ой, а у нас тут функция так спроектирована, что с добавлением каждого нового пользователя нагрузка на серверы растет с геометрической прогрессией и проект придется закрыть после 100-го клиента». И это реальный случай из практики, а не детские страшилки на ночь. 

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

Миф №3: Долгое планирование — это ОК

Если на согласование запуска уходит месяц, то компания играет в Agile, а не реализует его.

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

Миф №4: Agile-ритуалы без результата — это ОК

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

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

Зачем стартапу с пятью людьми стори-поинты? Чтобы что? Чтобы показать инвесторам, что мы «в Agile»? Такие стори-поинты на показ приводят к трате времени и денег инвесторов, а не к результатам. Командам нужно больше действовать, а не тратить время на ритуалы.

В чем настоящая суть Agile

Истина №1: Agile — это прямая работа с клиентом

Если продакт-менеджер по каким-то причинам не может дойти до клиента и спросить о жизни — это не Agile. Без взаимодействия с рынком вы создаете продукт «в никуда». 

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

Истина №2: Результат важнее процесса

Agile — это не про идеальные ретро и отчеты. Это про реальный результат. Команда должна понимать, зачем она делает ту или иную задачу. Если этого понимания нет, все процессы бесполезны. 

Истина №3: Гибкость требует дисциплины

Гибкость — это не про хаос. Гибкость — это не про вседозволенность. Это про способность быстро адаптироваться, сохраняя качество. А это возможно только с компетентной, опытной, дисциплинированной командой, которая знает свои роли и задачи.

Три кита Agile

Есть три компонента, без которых не сработает Agile:

• компетентность,

• дисциплина,

• доверие.

Нарушение каждого пункта — путь к хаосу и сливу инвесторского бюджета. 

Agile не работает без экспертов

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

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

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

Agile не работает без дисциплины

Делать продукт (как и бизнес) — на самом деле, достаточно скучный процесс. Нужно каждый день делать огромное количество скучных вещей, которые тем не менее не просто важны, а «внезапно важны».

В чем веселье следить за бюджетом? Да ваще ерунда. В чем веселье планировать задачи на ближайшие две недели? В чем веселье сначала проектировать задачу, а потом только реализовывать? В чем кайф делать то, что нужно, когда у тебя нет настроения, и делать дело, когда нет результата? Почему мы делаем скучные задачи по рефакторингу, когда есть классная задача по внедрению ИИ? 

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

Agile не работает без доверия

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

Гибкость требует доверия. Если вы абсолютно не доверяете своей команде, то дело либо в вашей системе отбора кандидатов (увольняйте HR), либо в выстроенной системе (увольняйте операционного директора), либо в вашей голове (сходите к психотерапевту).

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

Почему Agile работает только в стартапах

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

В корпорациях Agile часто превращается в пародию. Процессы громоздкие, цели размытые, команды разрозненные. Вместо гибкости появляются ритуалы ради ритуалов: бесконечные созвоны, стори-поинты и диаграммы сгорания задач. Это не Agile, а его имитация.

Заключение

Agile — это не модный тренд, а инструмент, который работает только в правильных руках.

Agile — это дисциплина, ответственность и понимание конечной цели. Без этого гибкость превращается в хаос.

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

Хотите работать в Agile? Начните с честности: зачем вам это нужно? Готовы ли вы инвестировать время и деньги в обучение команды, адаптацию процессов и честную обратную связь? Если ответа нет, то, возможно, вам подойдет что-то другое. И это нормально.