Джоэл о программном обеспечении

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


Joel on Software - Выбор даты выпуска

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

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

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

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

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

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

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

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

  • Отсекать низкоприоритетные возможности каждый раз, когда вы замечаете, что сроки выпуска сползают с выбранной даты



    • Если вы сделаете все, как следует, то вскоре обнаружите, что вы не жалеете о тех возможностях, которые отсекаете. Они обычно являются бессмысленными. Если они были так важны для вас, то можете реализовать их в следующей версии программы. Это как редактирование в журналистике. Если вы хотите написать выдающийся очерк из 750 слов, начните с очерка из 1500 слов, а потом отредактируйте его.

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

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

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

    Пока!

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

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

  • Частые небольшие релизы. Это подход Экстремального Программирования, и он наиболее подходит для проектов с небольшой командой разработчиков и с малым количеством клиентов, таких как домашняя IT-разработка.

  • Каждые 12–18 месяцев. Это обычно программные продукты «в упаковке», такие как настольные приложения и т.д., у которых большие команды разработчиков и тысячи или миллионы пользователей.

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

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

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

    Несколько лет назад меня назначили на разработку системы управления веб-содержимым для 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), она была, наверное, самым раскрученным продуктом в истории, но разработчики работали над ней всего… четыре месяца. Мы все скачали ее и увидели что – тадам! – это было окно со списком, которое скачивало программы. (А чего вы ожидали от четырех месяцев разработки?). Большой облом. Разочарование было таким жирным, что вы могли его намазывать на хлеб вместо масла. И сейчас, через шесть лет, спроси у кого угодно, что такое Кастаньет, и вам скажут, что это окно со списком, которое скачивает программы. Едва ли кто-нибудь побеспокоился переоценить ее, и код Маримбы должен был переписываться шесть лет; я уверен, что сейчас это самая крутая программа, но, если по-честному, у кого было время это узнать? Скажу вам маленький секрет: наша стратегия для CityDesk – избежать массивного пиара до выпуска версии 2.0. Это будет та версия, о которой все на Земле должны получить первое впечатление. А пока что мы будем вести тихий партизанский маркетинг, и любой из тех людей, кто на нее наткнется, обнаружит, что это весьма нехилая программа, которая решает многие их проблемы, но Арнольду Тойнби не потребуется ничего переписывать (Примеч. переводчика: Arnold Toynbee – автор нескольких книг по истории цивилизации).

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

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

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

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

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

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

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



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


    Джоель Спольски - основатель Fog Creek Software, небольшой компании по
    разработке программного обеспечения, расположенной в Нью-Йорке.
    Окончил Йельский Университет, работал программистом и управляющим в
    Microsoft, Viacom и Juno.

    Содержимое этих страниц представляет собой мнение одного человека.
    Всё содержимое Copyright ©1999-2005  by Joel Spolsky. All Rights Reserved.

    FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky



    Содержание раздела