Проект Goodman

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

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

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

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

Избегайте конца квартала

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

Мне довелось участвовать в одном проекте, в котором выпуск нового релиза был запланирован на пятницу 31 марта 2000 г. Этот релиз был ключевой целью девятимесячного периода работы компании (такой срок является предельным для отдельно взятого релиза). За две недели до срока выпуска релиза наш владелец продукта отправился в отпуск со своими детьми школьного возраста. Находясь в Диснейленде, он доблестно пытался решить по телефону несколько очень важных для нас вопросов. Однако его отсутствие пришлось на критический момент, и нам так и не удалось завершить определенную работу в последней итерации перед выпуском крупного релиза.

После возвращения владельца продукта мы смогли решить все оставшиеся вопросы в течение более короткой однонедельной итерации. Это отодвинуло дату выпуска релиза с 31 марта на 7 апреля. Хотя задержка на одну неделю не кажется критической для проекта со сроком выполнения девять месяцев, на практике она привела к переносу поставки продукта с одного квартала на другой, а это имело огромное значение для публичной компании. Из-за того, что плановая поставка нескольких сотен копий, намеченная на 31 марта, не состоялась, выручку от продаж и обновлений уже нельзя было признать в первом квартале. С таким же успехом эту поставку можно было осуществить 30 июня, а не 7 апреля.

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