Agile: оценка и планирование проектов

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

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

Проект Goodman

Команда проекта Goodman работала над первой версией коммерческого приложения для корпораций. В течение первых трех лет компания предполагала продать не более 5000 лицензий на программу. Вместе с тем продукт был дорогим, со средней ценой $50 000 на пользователя. Разработчиков, общая численность которых составляла 18 человек, разбили на две скоординированно работающие команды. Ожидалось, что выполнение проекта Goodman займет один год, однако предварительный релиз планировали передать небольшому числу клиентов через шесть месяцев.

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

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

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