Monday, December 11th, 2017

Измеряя масштаб релиза

Published on Февраль 25, 2009 by   ·   Комментариев нет

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

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

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

Многие могут предположить, что когда мы приступили к планированию, первым, что решили обсудить, был вопрос, будет ли клиентская версия Windows 7 «крупным релизом» или нет. Я поместил словосочетание в кавычки потому, что, как оказалось, это не то, что можем решить именно мы, да и ответить на этот вопрос однозначно нельзя. Значение релиза зависит в первую очередь от того, как тот или иной пользователь воспринимает воплощенные в нем функции, а не в самих функциях. Как инженеры, планирующие продукт, мы заранее принимаем решение о количестве сотрудников, которые будут вести разработку, а также по поводу сроков релиза, но мы оставляет за пользователями право решать, является ли для него данный релиз «значительным», поскольку всем нравится иметь собственное мнение. В блоге, посвященном нашим серверным продуктам, мы рассказали о расписании и поделились своим мнением относительно масштаба релизов клиентской и серверной версий Windows 7.

Но как бы мы сами не позиционировали новую ОС, нашей единственной целью является осуществить потрясающий релиз Windows 7.

Среди пользователей бытует мнение, что крупный релиз — это релиз, в котором есть функции, созданные именно для них и по их желанию. Незначительный релиз не имеет таких функций. Поэтому нет ничего проще, чем спланировать крупный релиз — просто заложить в него важные для каждого пользователя функции (а принимая во внимание фактор производительности, в таком релизе не может быть лишних функций, даже если кому-то из пользователей они действительно нужны)! Как инженеры мы осознаем, что практически воплотить эту, казалось бы, простую идею невозможно, потому что буквально через раз встречается ситуация, в которой двум пользователям нужны совершенно противоположные функции. Пока я пишу эту статью, на мою почту приходят сообщения, что в Windows никому не нужны multitouch-возможности, при этом другие считают, что это именно то, чего не хватает Windows. Таким образом, всегда есть две противоположные точки зрения на одну и ту же вещь. Да и в комментариях к другим статьям это тоже видно.

Давайте оценим спектр значимости релиза среди различных групп пользователей: рядовых пользователей, разработчиков, партнеров, ИТ-специалистов и ИТ-экспертов.

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

Разработчики рассматривают релиз с другой точки зрения. Для разработчика релиз будет крупным, если он принес новые API, позволяющие использовать преимущества разрабатываемого ими программного обеспечения, поэтому разработчики тоже активны в принятии решений. С другой стороны, предыдущая версия продукта тоже могла принести много новых API, с которыми на сегодняшний день разработчики очень хорошо знакомы, поэтому все, что может понадобиться разработчикам — это увеличить производительность их приложений. В таком случае первый релиз будет крупный, а второй автоматически становится незначительным. Но если взглянуть на историю программного обеспечения, такие «незначительные» релизы перерастали в крупные — взять, к примеру, Windows 3.1, Office 4.2 или даже Windows XP SP2. В каждом из этих случаев для разработчиков релиз был «незначительным», при этом в глазах рынка релизы были «крупными». Причина, по которой разработчики используют новые API, заключена в желании провести черту между своими продуктами или сфокусировать усилия на новых функциях. То есть разработчикам не нужны новые API лишь потому, что они новые. В этом случае релиз будет крупным, если у разработчиков будет достаточно времени и желания, чтобы сделать ставку на новые API, которые позволят сфокусироваться на поистине важных (для разработчиков) задачах.

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

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

ИТ-эксперты — это те, кто осуществляют консультации, анализ и высказывают свою точку зрения на разрабатываемое нами программное обеспечение. Такие пользователи оценивают релиз с точки зрения «изменений». Серьезные изменения — крупный релиз. Серьезные изменения подразумевают изменения в архитектуре, какие имели место при переходе от Windows 9x к Windows 2000 — несмотря на то, что продукты были во многом схожи, в их глубинах крылось огромное количество фундаментальных отличий. Поэтому для различного рода аналитиков и редакторов новостных сайтов этот релиз был крупным. Серьезные изменения в интерфейсе также приводят к появлению обсуждений, да и видны они невооруженным глазом. Но любое из таких изменений часто рассматривается как отрициательное, нежели положительное. Архитектурные изменения на деле означают появление различного рода несовместимостей. Новый интерфейс требует переобучения и отказ от уже знакомого.

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

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

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

С нашей точки зрения мы собрали хорошую команду инженеров и составили грамотное расписание для создания клиентской версии Windows 7. Это делает продукт значительным, с какой бы стороны вы не посмотрели. Мы стараемся добиться того, чтобы Windows 7 стала поистине впечатляющей ОС.

Надеюсь, что данная статья помогла в некоторой степени увидеть и понять, что взгляды пользователя по поводу значимости релиза могут в корне отличаться в зависимости от того, какую группу он представляет.

Источник: http://blogs.msdn.com/e7ru/


Смотрите также:

Tags:

Readers Comments (Комментариев нет)




Да человек я, человек! =)

Exchange 2007

Проведение мониторинга Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 3)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Проведение мониторинга Exchange 2007 с помощью диспетчера System ... [+]

Практическое рассмотрение перехода с Exchange 2003 на Exchange 2007 (часть 1)

Введение В этой статье из нескольких частей я хочу показать вам процесс, который недавно использовал для перехода с существующей среды Exchange 2003 ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 2)

Если вы пропустили первую часть этой серии, пожалуйста, прочтите ее по ссылке Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (Часть ... [+]

Мониторинг Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 2)

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Мониторинг Exchange 2007 с помощью диспетчера System Center Operations ... [+]

Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 5)

Если вы пропустили предыдущие части этой серии статей, перейдите по ссылкам: Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 1) ... [+]

Установка и настройка Exchange 2007 из командной строки (Часть 3)

If you missed the previous parts in this article series please read: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 1)

Инструмент ExRCA Текущий выпуск инструмента предоставляется только в целях тестирования и оснащен 5 опциями: Тест подключения Outlook 2007 Autodiscover Тест подключения Outlook 2003 RPC ... [+]

Развертывание сервера Exchange 2007 Edge Transport (часть 5)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Развертывание сервера Exchange 2007 Edge Transport (часть 1) Развертывание ... [+]

Установка и настройка Exchange 2007 из командной строки (часть 2)

Если вы пропустили первую статью данного цикла, пожалуйста, перейдите по ссылке: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование интегрированных сценариев Using Exchange Server 2007 – часть 2: генерирование отчетов агента Transport AntiSpam Agent

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Использование интегрированных сценариев Using Exchange Server 2007 – часть ... [+]