Глава 35. Agile и водопад: когда методология является инструментом, а не религией

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

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

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

— Гибкие? — переспросил Алексей, и внутри у него что-то насторожилось.

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

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

Когда он рассказал команде о новом проекте, реакция была предсказуемой.

— Опять банк, — поморщился Денис, и в его голосе прозвучала усталость. — Мы уже проходили это с «ПромРитейлом». Помните, чем закончилось? Половину работы переделали, сроки сдвинули, заказчик остался недоволен.

— Этот банк другой, — ответил Алексей, хотя сам в это не очень верил. — Они хотят работать гибко. Понимают, что требования будут меняться.

— Гибко? — Денис покачал головой. — Гибко — это когда мы делаем, а они потом говорят: «А мы передумали». И всё летит в тартарары.

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

— А архитектура? — добавил Павел, и его голос прозвучал глухо. — Если требования плывут, я не могу спроектировать устойчивую систему. Я буду строить на песке.

Алексей слушал их и понимал, что они правы. Классический подход, который они использовали годами, предполагал чёткое техническое задание, зафиксированные требования, последовательные этапы. Сначала анализ, потом проектирование, потом разработка, потом тестирование, потом сдача. Этот подход назывался «водопад». И он отлично работал там, где требования были стабильны, а заказчик знал, чего хочет. Но здесь ситуация была другой.

Он вспомнил про гибкие методологии. Agile, Scrum, Kanban. Когда-то он читал про них, но относился скептически. Ему казалось, что это модные слова для стартапов, а не для серьёзных проектов. Но сейчас, глядя на растерянные лица команды, он понял: пришло время попробовать.

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

— Это как? — спросила Лена.

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

— То есть мы будем всё время переделывать? — ужаснулся Денис.

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

— А если он захочет изменить то, что мы уже сделали? — спросил Павел.

— Тогда мы это изменим. Быстро. Потому что у нас будет работающая версия, а не гора документов.

Команда молчала. Люди переглядывались, и в их глазах читалось сомнение. Они привыкли к порядку, к структуре, к ясности. А то, что предлагал Алексей, казалось им хаосом.

— Я не уверен, — сказал наконец Денис. — Мы можем потерять контроль.

— А что мы теряем сейчас? — спросил Алексей. — Мы теряем время, пытаясь предугадать, чего хочет заказчик. Мы теряем силы, переделывая работу. Мы теряем веру в то, что делаем. Может, стоит попробовать другой путь?

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

***

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

— Может, мы делаем неправильно? — спросила она на третий день. — Может, надо было зафиксировать требования и работать по плану?

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

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

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

— О, а я думал, это будет по-другому, — сказал он, и в его голосе прозвучала искренняя радость. — Давайте вот здесь поправим, и будет идеально.

Правки заняли два дня. Два дня, а не два месяца. И на следующем демо заказчик снова удивился, снова что-то поправил, и снова остался доволен.

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

Алексей слушал и чувствовал, как внутри что-то отпускает. Он боялся, что Agile не сработает. Что команда не примет новый подход. Что заказчик окажется капризным и неблагодарным. Но реальность оказалась лучше страхов.

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

Денис перестал нервничать. Он понял, что даже без чёткого ТЗ можно двигаться вперёд, если есть обратная связь. Катя научилась не привязываться к макетам и не воспринимать правки как личную обиду. Павел нашёл способ проектировать архитектуру так, чтобы её можно было менять без разрушения. Даже Сергей, скептически относившийся к любым методологиям, признал, что «в этом что-то есть».

***

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

Заказчик прислал новые требования. Они противоречили тому, что было сделано раньше. Не просто уточняли или дополняли, а ломали логику. Денис вскипел. Катя растерялась. Павел мрачно заметил, что придётся переделывать половину архитектуры.

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

Алексей чувствовал, как внутри нарастает паника. Он понимал, что Agile - не волшебная таблетка. Он не отменяет хаос, не решает всех проблем. Он просто даёт инструмент для работы в условиях неопределённости. Но и у этого инструмента есть пределы.

Он собрал команду и заказчика на экстренную встречу.

— Уважаемые коллеги, — начал он, стараясь, чтобы голос звучал спокойно. — Мы столкнулись с ситуацией, когда новые требования противоречат старым. Это нормально. Рынок меняется, и вы меняетесь вместе с ним. Но нам нужно понять, что для вас важнее: скорость или стабильность? Гибкость или предсказуемость?

Заказчик задумался. Потом его представитель сказал:

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

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

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

— Ветров, я не верил, что вы справитесь. Думал, что этот банк вас сломает. А вы не только справились, но и перевыполнили план. Как?

— Мы попробовали Agile, — ответил Алексей. — И он сработал. Потому что мы не пытались предугадать будущее. Мы просто делали маленькие шаги и смотрели, куда они нас ведут.

— А я думал, Agile — это для стартапов. Для тех, кто не умеет планировать.

— Agile — это для тех, кто умеет меняться. Планировать тоже нужно. Но план ведь не догма. Это карта, которую можно уточнять по ходу.

***

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

«AGILE - НЕ ПРО СКОРОСТЬ, А ПРО ГИБКОСТЬ.
НЕ ПРО ОТСУТСТВИЕ ПЛАНА, А ПРО УМЕНИЕ ЕГО МЕНЯТЬ.
СПРИНТЫ - НАШИ МАЛЕНЬКИЕ ШАГИ К БОЛЬШОЙ ЦЕЛИ.
ДЕМО - НАШИ ВСТРЕЧИ С РЕАЛЬНОСТЬЮ.
РЕТРОСПЕКТИВЫ - НАШИ УРОКИ.
МЫ НЕ СТРОИМ НА ВЕКА, МЫ СТРОИМ ТО, ЧТО НУЖНО СЕЙЧАС».

Ночью кто-то дописал внизу: «Я раньше думал, что Agile — это модное слово для ленивых. А теперь вижу: это способ не сойти с ума в мире, где всё меняется каждую минуту. Денис». А рядом, другим почерком: «Я боялась, что мы потеряем контроль. Оказалось, что контроль - это способность быстро реагировать на изменения. Катя». И ещё одна приписка, кривоватая, почти незаметная: «Водопад тоже нужен. Для мостов, например. Но для банков лучше Agile. Павел».

Алексей, увидев эти надписи утром, стоял перед флипчартом несколько минут. Он думал о том, что Agile — это не религия. Это инструмент. И как любой инструмент, он требует умения. Нельзя просто сказать «мы работаем по Agile» и ждать чуда. Нужно понимать, когда он подходит, а когда нет. Нужно уметь применять его там, где он работает, и не бояться использовать другие подходы там, где они лучше. Водопад — это не устаревшая методология. Это надёжный способ построить мост, спроектировать самолёт, запустить завод. Agile — это способ создать что-то новое в условиях неопределённости. И мудрость команды в том, чтобы выбрать правильный инструмент для каждой задачи. В этом и был их главный урок. Не в том, чтобы превозносить Agile или ругать Waterfall. А в том, чтобы понимать, что мир сложнее любых методологий. И что настоящая гибкость — это не следование правилам, а умение их нарушать, когда это нужно. Осознанно. С уважением к тому, что было сделано раньше. И с открытостью к тому, что будет завтра.