Выбор даты выпуска

Автор: Джоэл Сполски

Переводчик: Андрей Шкуропий

Вторник, 9 апреля 2002

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

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

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

Итак, очевиден следующий вопрос: как вы выбираете дату выпуска?

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

Пока!

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

Есть три подхода к решению этой задачи.

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

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

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

«А, мы просто делаем это все вручную с помощью программы BBEdit», сказали они мне. «Конечно, вручную обрабатываются тысячи страниц, но BBEdit имеет действительно классную функцию Поиска-с-Заменой…»

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

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

Определенные типы пользователей не желают быть «подопытными кроликами» в такой форме. Обычно люди, которые покупают программные продукты «не для полки» (off-the-shelf software), не хотят быть участниками Великого Эксперимента по Разработке; они хотят что-нибудь, предугадывающее их потребности. Для пользователя единственное, что может быть лучше быстрого отзыва разработчиков на запрос новых функциональных возможностей, – это когда они получают их немедленно, потому что эти функциональные возможности уже предусмотрены в программном продукте, так как он разрабатывался внимательно и прошел усиленное юзабилити- и бета-тестирование прежде чем был выпущен в свет. Если у вас большое количество платежеспособных пользователей (или вы хотите, чтобы их стало больше), предпочитайте менее частые выпуски.

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

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

Для больших программных платформ – операционных систем, компиляторов, веб-браузеров, СУБД – самая трудная часть процесса разработки – обеспечение совместимости с тысячами или миллионами существующих программных или аппаратных продуктов. Когда выходит новая версия Windows, вы очень редко слышите о проблемах обратной совместимости. Единственный способ, которым они могут этого достичь – проведение немеряного количества тестов, по сравнению с которыми создание Панамского канала – просто самоделка на один уикенд.

Почти все время типичного трехлетнего цикла между выпусками новых «старших» версий Windows тратится на занудные фазы интеграции и тестирования, а не на создание новых функций. Выпускать новые версии чаще, чем они это делают, просто нереально. И если они будут делать их чаще, это сведет людей с ума. Третьи стороны в разработке программного и аппаратного обеспечения просто поднимут бунт, если вынуждены будут снова тестировать множество маленьких релизов операционной системы. Для систем с миллионами пользователей и миллионами точек интеграции, предпочитайте редкие выпуски. Вы можете делать это также, как Apache: один релиз в начале Разбухания Интернета (Примеч. переводчика: Internet Bubble – печально известный кризис Интернет-компаний 1997–2000 гг.) и один релиз в конце. Прекрасно.

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

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

В английском оригинале статья называется