Одна из самых веских причин составить подробный план состоит в том, что он дает вам основание для сокращения числа функций. Если не получается уложиться в срок, реализовав функцию «споем вместе» MP3-чата, предложенную Бобом, можно отказаться от этой функции, не обижая Боба.

Вот мои основные правила для цикла выпуска программного продукта:

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

2. Составить список функциональных возможностей и отсортировать их по приоритету.

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

Следуя этим правилам, вы вскоре обнаружите, что вас не огорчило исключение функций. Скорее всего, они были чем-то вроде балласта. А если они действительно важны, можно реализовать их в следующей версии программы. Это как редактирование. Если хотите написать блестящую статью из 750 слов, напишите 1500 слов, а затем вычеркните лишние.

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

Возникает естественный вопрос: как назначить дату выпуска?

Вполне вероятно, что у вас есть внешние ограничения. Фондовая биржа переходит с обычных дробей на десятичные в такой-то день, и если программа не будет готова к этому сроку, ваша фирма погорит, а вас самого отвезут в доки и пристрелят. Или, к примеру, скоро выйдет очередная версия ядра Linux с новой оригинальной системой фильтрации пакетов; ее установят все ваши клиенты, а ваше приложение с ней не работает. Ладно, в таких ситуациях определить дату выпуска легко. Дальше можете не читать. Лучше пойдите на кухню и приготовьте вкусный обед для своих близких.

Все, пока!

Но как выбрать дату выпуска всем нам, остальным?

Есть три возможных подхода.

1. Частые небольшие релизы. Это подход «экстремального программирования», наиболее пригодный для проектов с небольшой командой разработчиков и малым количеством клиентов, таких как разработка для внутренних потребностей фирмы.

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

3. Каждые 3-5 лет. Это типично для гигантских программных систем и платформ, которые являются целыми мирами сами по себе. В эту категорию попадают операционные системы, .Net, Oracle и, по некоторым причинам, Mozilla. В данном случае количество разработчиков может измеряться тысячами (над одним лишь инсталлятором VS.Net работало 50 человек), и очень велико влияние на поставки других программных продуктов, которые не должны пострадать.

Вот несколько факторов, которые нужно учитывать, принимая решение относительно частоты релизов ПО.

При коротких сроках поставки вы быстро узнаете реакцию клиентов на ваш продукт. Иногда лучше всего работать с клиентом так: показать ему программу, дать возможность поработать и сразу включить высказанные пожелания в очередную сборку, которую вы даете клиенту на следующий же день. Не нужно целый год разрабатывать сложную систему с огромным количеством функций, которыми никто не пользуется, потому что вы будете заниматься только тем, о чем вас просят клиенты. Когда количество клиентов невелико, делайте частые выпуски небольшого объема. Объем каждого выпуска — минимальный кусок кода, выполняющий что-то полезное.

Несколько лет назад мне пришлось разрабатывать систему управления веб-контентом для MTV. Из задания следовало, что система должна использовать базу данных и шаблоны, обеспечивая документооборот, чтобы бесплатные внештатные корреспонденты MTV из колледжей по всей стране могли вводить информацию о клубах, магазинах звукозаписей, радиостанциях и концертах. Я спросил: «А как ваш сайт устроен сейчас?»

«Да мы просто делаем все вручную с помощью BBEdit, — ответили мне. -Конечно, приходится обрабатывать тысячи страниц, но в BBEdit есть прекрасная функция глобального поиска и замены...»

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

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

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

Если вы выпустите худосочную коммерческую программу просто для того, чтобы выставить что-нибудь на обозрение и «получать отзывы пользователей», то, услышав от них, что «программа мало что умеет», решите, что все в порядке — это же лишь версия 1.0. Но когда через четыре месяца вы выпустите версию 2.0, все будут думать: «Та жалкая программа? Я что, должен заново оценивать ее каждые четыре месяца, чтобы выяснить, стала она лучше или нет?» И еще пять лет кряду люди будут помнить свое первое впечатление от версии 1.0, а переубедить их практически невозможно. Вспомните, что случилось с несчастной Marimba. Они создали компанию с неограниченным венчурным капиталом во времена сверхэнергичной рекламной кампании Java, переманив ключевых разработчиков из команды Java фирмы Sun. Их генеральный директор Ким Полиз (Kim Polese) была непревзойденнът пиарщиком; когда она продавала Java, Дэнни Хиллис (Danny Hillis) сочинял для нее речи о том, что Java — это следующий этап развития человечества; Джордж Гилдер (George Gilder) писал захватывающие статьи о том, как Java полностью перевернет саму природу человеческой цивилизации. Монотеизм показался бы жалкой тенью по сравнению с той верой в Java, к которой нас призывали. Полиз на такое способна. Так что когда вышла Marimba Castanet, ее незаслуженная слава была беспрецедентной, но написана она... всего за четыре месяца. Загрузив ее, все увидели — надо же! — окно со списком, которое скачивало программы. (А чего еще хотеть от четырех месяцев разработки?) Большой облом. Разочарование было таким плотным, что его можно было резать ножом. Да и сейчас, через несколько лет, на вопрос «что такое Castanet?» любой ответит, что это окно со списком, которое скачивает программы. Вряд ли кто-то потрудился еще раз оценить ее, а ведь код Marimba писали еще шесть лет; уверен, что теперь это крутейшая программа, — но, по правде говоря, кому это интересно? Открою маленький секрет: наша стратегия для CityDesk — не допустить массивного пиара до выпуска версии 2.0. Это и будет та версия, которая произведет на всех впечатление. А пока что мы ведем тихий партизанский маркетинг, и тот, кто на нее наткнется, обнаружит, что это классная программа, которая решает многие его проблемы, но Арнольду Тойнби (Arnold Toynbee) не придется ничего переписывать.

Для коммерческого ПО процесс разработки, прототипирования, интеграции, исправления ошибок, полного цикла альфа— и бета-тестирования, создания документации и так далее обычно длится 6-9 месяцев. Фактически, если вы захотите каждый год делать полный новый выпуск, у вас остается меньше 3 месяцев на разработку нового кода. Ежегодно обновляемое программное обеспечение обычно не воспринимается как обладающее достаточным для новой версии числом новых функциональных возможностей. (Corel PhotoPaint и Intuit Quickbooks — наглядные тому примеры; каждый год выпускаются их новые «большие» версии, приобретение которых редко бывает оправданным.) В результате многие пользователи привыкают пропускать каждый второй релиз. Едва ли вы хотите, чтобы у ваших пользователей сложилась подобная привычка. Если вы растянете план до года-полутора между выпусками, то получите шесть месяцев на создание новых функциональных возможностей вместо трех, в результате клиент может оказаться более склонным к обновлению своей версии.

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

Для больших программных платформ — операционных систем, компиляторов, веб-браузеров, СУБД — наибольшую трудность в разработке составляет обеспечение совместимости с тысячами и даже миллионами существующих программных или аппаратных продуктов. При выходе новой версии Windows проблемы обратной совместимости крайне редки. Достигается это ценой безумного объема тестирования, в сравнении с которым Панамский канал — просто самоделка на один уикенд. В обычном трехлетнем цикле выпуска основных версий Windows большая часть времени тратится на утомительные этапы интеграции и тестирования, а не на создание новых функций. Выпускать новые версии чаще нереально, люди просто сойдут с ума. Сторонние разработчики программного и аппаратного обеспечения забастуют, если им придется тестировать множество маленьких релизов операционной системы. Для систем с миллионами пользователей и миллионами точек интеграции предпочтительнее редкие выпуски. Поступайте, как Apache: один релиз в начале интернетпузыря, и один — в конце. Идеально.

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

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

И последнее. Если ваша программа поставляется как веб-сервис, вроде eBay или PayPal, то, теоретически, ничто не мешает вам часто выпускать версии с небольшими изменениями, хотя, возможно, это и не лучший вариант. Помните главное правило юзабилити: приложение удобно, если оно ведет себя так, как того ожидает пользователь. Если каждую неделю что-то менять, приложение будет не столь предсказуемым, и, следовательно, не таким удобным. (И не рассчитывайте на надоедливую надпись «Внимание! Интерфейс изменился!» — ее никто не читает.) С позиции юзабилити лучше выпускать новые версии реже, вводя сразу целый пакет модификаций, изменяющих внешний вид сайта на непривычный, — так пользователи интуитивно поймут, что все существенно изменилось и нужно проявлять осторожность.