Роль обратной связи при разработке Windows 7

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

В этом сообщении я хочу подвести черту под дискуссией о том, какие изменения были внесены в продукт по результатам изучения откликов и пожеланий в целом. Мы коротко остановимся на некоторых специфических нововведениях и в следующей статье вернемся к теме изменений и дополнений в RC-версии. На прошлой неделе из блога разработчиков IE вы узнали о том, что мы обновляем IE 8 в Windows 7. Тема обратной связи при этом также была затронута.

Разумеется, обратная связь с будущими пользователями Windows 7 начала налаживаться задолго до того, как мы приступили к написанию кода, — тысячи людей, не имеющих никакого отношения к Microsoft, повлияли на облик и возможности грядущей операционной системы. Мы убедились, что совсем небольшая группа пользователей оказывается в состоянии представить весьма широкий диапазон возможностей — как для выравнивания результатов, так и в для их поляризации. Разрабатывая требования к Windows 7, мы тесно взаимодействовали с производителями ПК, корпоративными клиентами, клиентами из сферы малого бизнеса, образовательной сферы, а также энтузиастами, техническими обозревателями, журналистами, "властителями дум" из индустриальных кругов и многими другими. Мы строили и выверяли "чертеж" операционной системы в соответствии с широчайшим спектром пожеланий всех этих людей и организаций. По мере создания прототипов программного кода, для получения наиболее целенаправленных и детализированных откликов мы использовали специфические инструменты, такие, как тесты на удобство использования, тесты на соответствие концептуальных моделей, тесты производительности и многое другое. Мы стремились как можно лучше выверить детали нашего "чертежа". Цель, которой мы стремились достичь столь беспрецедентным уровнем взаимодействия, состояла в приведении системы в соответствие с требованиями максимально широких слоев будущих пользователей Windows, хотя, конечно, буквально учесть мнения и пожелания каждого человека невозможно. Я надеюсь, в этой статье мне удастся дать представление об этом процессе с точки зрения инсайдера, рассказав об инструментах и технологиях, использованных нами, и собственно о размахе кампании сбора откликов.

В первые недели после открытия публичного доступа к бета-версии Windows 7 ее загрузили и установили более миллиона пользователей. Для любого бета-тестирования это громадная цифра. Мы понимаем, что многие установили Windows 7 из любопытства и ради удовольствия, но для нас это тем более ценно потому, что мы проделали огромную работу, направленную на улучшение качества операционной системы. Используя бета-версию, вы автоматически становитесь участником программы улучшения потребительских свойств системы (от англ. Customer Experience Improvement Program или CEIP), в ходе которой осуществляется анонимный сбор данных и предусмотрено получение откликов от пользователей, также с соблюдением всех условий анонимности. В окончательной версии Windows 7 (RTM) участие в этой программе будет добровольным. Просто используя Windows 7, вы уже помогаете нам в совершенствовании продукта — ваши сообщения обрабатываются и систематически изучаются. Вот посмотрите, на каком уровне всё это происходит:

• В пиковую неделю [после начала бета-тестирования] в январе мы получили около полумиллиона сообщений по системе обратной связи. Каждому из разработчиков придется изучить примерно по 500 штук! С момента начала использования Windows 7 прошло всего около 6 недель, но для многих система уже превратилась в старую знакомую.
• К настоящему времени от пользователей, зарегистрированных в системе MSDN/Technet/Connect, получено несколько сотен сообщений об ошибках, и нами уже подготовлены исправления, причем количество уже решенных проблем в процентном отношении бьет наши собственные рекорды, установленные в ходе всего цикла разработки операционных систем Windows.
• На сегодняшний день мы исправили около 2 тысяч ошибок в программном коде Windows, вызывавших зависания и сбои системы. И хотя многие пользователи очень довольны качеством Windows 7, мы стараемся сделать ее еще надежнее и безопаснее, исправляя ошибки, выявленные в ходе столь массового и всестороннего использования.
• К текущему моменту мы зарегистрировали около 10 миллионов подключений дополнительного оборудования к ПК с установленной Windows 7 и для 75% случаев оказалось достаточно драйверов, поставляемых вместе с системой (не потребовалось дополнительной загрузки из сети). Для остальных случаев загрузка необходимых драйверов осуществлялась через службу Windows Update или напрямую с сайта производителя оборудования. Нами отмечено использование около 2,8 миллионов уникальных идентификаторов образцов plug-and-play-оборудования.
• С момента открытия настоящего блога в августе 2008 года я получил более 2000 электронных посланий со всех уголков планеты, на которые уже ответил. Я чрезвычайно признателен всем участникам имевшего место обсуждения и изо всех сил постараюсь продолжать в том же духе.

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

Несколько лет назад при работе над офисным пакетом — в то время телеметрия и обратная связь через всемирную сеть еще не были так хорошо отлажены — обсуждение будущих опций и функций программ можно было без преувеличения охарактеризовать как самое настоящее сражение. Схватки происходили в каждом кабинете, пока какая-то группа не сдавалась — от усталости, умственной или физической. Это был, если можно так выразиться, "адреналиновый способ создания программ". "Последний герой", человек с самой большой силой воли, или даром убеждения, или тот, кто мог заставить сотрудников с красными от перенапряжения глазами набивать код ночами напролет, оказывался в состоянии определять конечный вариант продукта, — какие свойства он будет иметь и как они будут реализованы. Процесс принятия решений превращался в борьбу за выживание. Уверен, многие из вас хорошо знакомы с такой методикой. Проблемы, с нею связанные, весьма велики, — многие жизненно важные функции программ плохо увязаны друг с другом (на уровне сценариев и/или архитектуры), продукт утрачивает внутреннюю логику, и, что важнее всего, — если по какой-то причине победитель не очень хорошо представляет себе нужды пользователей, они теряют интерес к программе.

На заре 90-х мы взялись за изучение опыта работы пользователей с программой Word и созданием инструментария для его телеметрии. Это происходило еще "до эпохи Интернета", поэтому была создана специальная версия продукта, и мы упросили добровольцев установить ее и помочь нам собрать необходимую информацию, для чего потребовалось огромное количество дискет. Затем мы проанализировали, какие функции наиболее востребованы публикой и как именно люди их используют. Мы с удивлением обнаружили, что таблицами пользуется намного больше людей, нежели мы предполагали, но с целями, далекими от собственно табличного представления данных. Мы выяснили, что в ходе проверки орфографии самый первый предложенный вариант из встроенного словаря, как правило, является самым подходящим (практически это привело к появлению автоматического исправления). Мы определили, что "советы дня" вообще никто не читает. Эти данные помогли нам решить, что же на самом деле необходимо исправить, каковыми окажутся последствия внесенных изменений, и определить направления дальнейшего совершенствования программ для обработки документов.

Вернемся к ситуации вокруг Windows 7 и сосредоточимся на том, как собранные отклики и телеметрия [далее, для краткости, просто "данные"] позволяют нам обосновывать принимаемые решения. Эти данные имеют различные формы, так же, как разнообразна оказываемая ими помощь. Я понимаю, что многих интересуют эти данные — насколько они репрезентативны, как с их помощью заставить людей пользоваться вещами, которыми они должны пользоваться, но не делают этого, и т.д. Данные — важный элемент в процессе принятия решения, но они не заменяют необходимости думать, формулировать задачи, достигаемые с помощью продукта, формирования лояльного сообщества пользователей, работы с экосистемой для того, чтобы Windows 7 стала, наконец, реальностью.

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

Мне представляется важным коротко остановиться на нескольких типах данных, помогающих нам принимать решения. Приведу здесь некоторые примеры.

• Программа улучшения потребительских свойств системы (CEIP). CEIP обеспечивает полный набор данных телеметрии, собираемый с вашего ПК, передаваемых в дальнейшем в Microsoft без использования конфиденциальной информации о вас и вашем оборудовании, и на добровольной основе. В бета-версии, как я уже говорил, CEIP включена по умолчанию. В конечной версии, разумеется, она будет по умолчанию выключена и включится только по указанию пользователя. В ходе бета-тестирования мы наблюдаем, как используются новые возможности, как пользователи настраивают под себя систему, какие команды выполняются и, в общем, как пользователи работают с Windows 7. Вы могли убедиться, что мы использовали для работы над Windows 7 собранные с помощью Windows Vista данные, такие, как разрешение экрана или количество учетных записей пользователей на одном компьютере. Существует множество позиций для измерения и оценки. Важным элементом цикла разработки продукта является уверенность, что все новые возможности снабжены инструментарием, позволяющим оценить их использование в процессе бета-тестирования и в дальнейшем.
• Телеметрия. Она тесно связана с CEIP на программном уровне, но мы рассматриваем результаты ее работы несколько шире. Это должно быть понятно из того, как мы рассматриваем вопрос о производительности или разнообразии поддерживаемых устройств. Хорошим примером может служить обсуждение поддержки высоких значений DPI. В ходе бета-тестирования мы сможем увидеть, как изменяется время загрузки системы в зависимости от количества обнаруживаемых устройств, корректно ли они определяются и многое другое. Важная задача телеметрии состоит в том, чтобы определить, как часто происходит сбой или зависание — это поможет нам нащупать пути решения проблемы. Благодаря ей мы можем определять ПО, вызывающее сбои или зависания, и координировать усилия по исправлению ситуации. Она также помогает нам сосредоточиться на преимуществах, получаемых в результате исправлений — устранение ошибки, затрагивающей множество пользователей, или широко используемое оборудование, или популярную программу, может иметь более высокий приоритет. Располагая необходимыми данными, мы можем точнее оценивать риски и определять приоритеты.
• Тесты, основанные на сценариях использования. В ходе разработки той или иной функции мы используем наши образцы и прототипы (кода, документа, изображения) и создаем модель ее использования и/или внедрения пользователями, а также предполагаем, как они станут эти функции оценивать. Например, на раннем этапе планирования Windows 7 мы создали полностью рабочий прототип усовершенствованной панели задач. С его помощью мы могли изучать реакции различных типов пользователей, в зависимости от их опыта работы, знакомства с различными версиями Windows, а также приверженцев конкурирующих платформ, ИТ-профессионалов и конечных потребителей на разнообразные проработанные сценарии выполнения задач. Это позволило нам куда более тщательно проанализировать свойства этого модуля. Но, со всеми своими результатами, эти тесты не смогли отменить необходимость принятия решения, хотя и послужили прочным основанием такового.
• Исследование аспектов производительности. По мере продвижения к бета-версии программный код становился все более похожим на то, что будет представлено публике, и мы приступили к отработке сценариев, максимально приближенных к действительности, которые позволили нам выверять программную основу Windows 7. Мы назвали этот этап "бенчмаркингом" (benchmarking), отработкой аспектов производительности, — потому, что мы довольно часто создаем новый продукт, стараясь сделать его более быстрым, нежели предыдущие версии. Например, мы исследуем, сколько времени уходит на операцию превращения локального принтера в устройство общего доступа "старым добрым" способом и как быстро можно выполнить такое же действие с использованием новой функции Windows 7 — HomeGroup (домашние группы). Мы сравниваем скорость подключения к беспроводной сети с шифрованием по протоколу WPA и без него. Таких тестов у нас довольно много, поскольку нам важно убедиться, что мы, во-первых, добились определенного прогресса в реализации каких-то функций и, во-вторых, нужно ли нам соответствующим образом дополнить документацию и/или усовершенствовать встроенную систему помощи пользователям.

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

Как мы уже отмечали, бета-тестирование Windows 7 приносит с собой новый уровень обратной связи, особенно это касается объемов поступающей информации и ее разнообразия. Если вы остановитесь на минутку и представите себе, какое количество сообщений необходимо просто прочесть нашим сотрудникам, вы поймете, что даже приведение их в порядок (каталогизирование, распределение по категориям, разметка), не говоря уже об ответах (около 40 результатов отсылки через "Отправить сведения в Microsoft" в неделю, не считая внутренней корреспонденции), занимает уйму времени.

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

Принятие таких решений входит в обязанность ведущих специалистов, координаторов процесса создания программ (в простонародье программнного менеджера от англ. program management, далее — PM). РМ не должен запираться в кабинете и зацикливаться на собственном мнении по той или иной проблеме. На самом деле, они вдумчиво собирают и анализируют факты, различные точки зрения, и работают над тем, чтобы предложить наиболее оптимальное решение в каждой из возникающих коллизий. Их роль состоит в том, чтобы каждый голос был услышан, каждая точка зрения учтена, чтобы дизайнеры, программисты, маркетологи, сотрудники службы поддержки пользователей, тестировщики, и все остальные работали вместе. Их задача — систематическое и синтетическое представление всех возможных позиций.

Множество факторов необходимо учесть, чтобы понять, в чем состоит наилучший выбор:

• Что мы собираемся предпринять? На самом высоком уровне, главный вопрос — как это должно работать? Иногда кажется, что все идет наперекосяк. Такое ощущение возникало у нас, когда мы наблюдали неимоверное количество сбоев и зависаний системы на стадии, предшествующей бета-версии. Собственно говоря, дискутировать тут особо не о чем: если крушение происходит с каким-то очевидным постоянством, подтверждаемым телеметрией, необходимо это исправить. Если у пользователя система все время "падает" и "виснет", исправление необходимо. Однако, не менее важно понять, как часто возникает проблема, и в чем ее причина — в самом программном коде Windows, в неправильно написанном производителем оборудования драйвере, в сторонней программе, — в каждой из этих ситуаций решение может быть различным. Если дело касается взаимодействия пользователя с системой, то вопрос "что предпринять?" состоит из двух частей. Во-первых, существует известный "идеальный" результат, к которому следует стремиться, во-вторых — информация о том, как разные пользователи с разным опытом (или мнениями) представляют себе процесс его достижения. Например, когда мы ведем речь о так называемых домашних группах (HomeGroup) и пароле для доступа к их ресурсам, на нас обрушивается лавина вариантов того, как это должно работать (и кстати, мы кое-что там переделаем в соответствии с полученными откликами). Конечно, у нас имеются прототипы и спецификации, на наш процесс разработки обладает достаточным запасом гибкости, и стопроцентная предопределенность в нашем случае отсутствует, — так же, как, например, в строительном деле, когда, несмотря на наличие готовых чертежей, по желанию заказчика в проект может вноситься масса изменений уже на этапе непосредственного строительства. Кроме того, всегда есть участки, где вроде бы все прекрасно работает, но, тем не менее, у нас имеется вариант, предусматривающий доводку и шлифовку.
• Что мы будем с этого иметь? Предположим, мы решаем, что некая функция будет работать иначе, нежели предполагалось раньше. Получим ли мы вдвое лучший результат? Или выигрыш будет всего 5%? Заметит ли это кто-нибудь? Такие моменты всегда служат камнем преткновения. Те, кто настаивает на изменениях, безусловно, убеждены: "Если изменений не внести, можно считать эту функцию нереализованной". Это особенно ярко проявляется в случаях, когда нужно добиться "заметности" чего-то. Некоторым кажется, что для вящей "обнаруживаемости" необходимо вывесить это что-то посередине и на самом видном месте. Масса предложений поступает в связи с гипотетической необходимостью непременно сделать какую-то функцию настраиваемой. Конечно, все это просто здорово, но наряду с очевидными преимуществами такого подхода столь же очевидно возрастает сложность системы, появляются новые термины, бегунки, промежуточные интерфейсы и прочий белый шум, только мешающий продуктивной работе и целостному восприятию. Иногда важно взглянуть на вероятное усовершенствование, исходя из более широкой перспективы, например, как часто потребуется что-то настраивать и скольким пользователям вообще придет в голову этим заниматься. Нередко случается, что наши сотрудники, недолго думая, проецируют собственные поведенческие шаблоны на остальных: "Абсолютно все делают это!"
• Насколько критическими окажутся изменения? На ранней стадии проектирования мы вносим множество поправок в программный код — добавляем блоки, меняем архитектуру, передвигаем, меняем местами и т.д. Это происходит не только волей неволей, но и потому, что в процессе разработки так или иначе возникают ситуации, когда необходимо вернуться в отправной точке и все начать сначала. Мы создаем спецификации и планируем функции (сценарии, прототипы и т.п.), поскольку хорошо понимаем: чем дальше продвинулся проект, тем труднее и дороже обходятся попытки что-либо изменить. Поджимает время и цена возрастает — особенно тяжело даются серьезные изменения на поздних стадиях, потому что усилия не ограничиваются одной только инженерной стороной дела. Поэтому, планируя изменения, мы должны очень хорошо представлять себе, насколько они значительны и каково окажется их воздействие на систему в целом. Иногда изменение предполагает написание большого блока программного кода, а много кода — это всегда немалый риск. Но чаще всего дело не в количестве строк кода, а в том, что изменения кода необходимо увязать с другими участками — в то время как кажется, что мы имеем дело с простым логическим ветвлением "если/то", на самом деле все обстоит значительно сложнее. На протяжении долгих лет многие твердили о так называемом компонентном или модульном представлении и других способах проектирования систем в надежде уменьшить влияние вносимых изменений, и, конечно, Windows — многоуровневая система. Но реальность такова, что даже в системе с очень четким разделением уровней нельзя надеяться, что сделанное на самом нижнем уровне изменение никак не затронет остальные уровни. Такая псевдо-незащищенность предусмотрена нами для того, чтобы сохранить совместимость, обеспечить стабильность, производительность и надежность.
• Каково соотношение стоимости изменения и выгоды от него? Изменение означает, что что-то будет сделано иначе. Меняя что-то, мы ожидаем, что пользователи отреагируют на это. Зачастую мы внедряем изменения обдуманно и осторожно — это видно по интерфейсу пользователя, модели интеграции драйверов и т.п. Имея дело с продуманными, постепенными изменениями, люди получают возможность подготовиться к ним, а мы предоставляем для этого соответствующие инструментарии. Мы получаем массу комментариев, в которых затрагивается тема стоимости перемен. Нередко автор абстрагируется от возможной выгоды от перемен и концентрируется на изменении как таковом. Конечно, в таком случае изменение далеко не всегда полезно. Многие сообщения об ошибках содержат требования такого типа: "в 3 предыдущих версиях мы терпели эту проблему, но в Windows 7 это, наконец, должно быть исправлено!" Отслеживая историю Windows, мы отдаем себе отчет в том, что некоторые аспекты поведения системы, в частности, ее API, порядок вывода сообщений или семантика отнюдь не идеальны. Но их радикальное изменение повлечет за собой усложнение системы, вопросы несовместимости и другие проблемы, что для рядовых пользователей сведет на нет все потенциальные преимущества. Некоторым кажется, что решение оставить всё как есть "тянет нас назад", но чаще всего оказывается по-настоящему недальновидным именно спешить с изменениями. Привычное поведение системы, касается это программных интерфейсов или графической оболочки, обусловлено существующим де-факто "социальным контрактом" и существенной частью работы над окончательной версией является уверенность, что мы располагаем прозрачной и сбалансированной концепцией "цена изменения — преимущество". При этом мы понимаем — разные люди обладают разными представлениями об этом уравнении.
• Какова важность той или иной проблемы в масштабе всей системы? Очевидно, что все решения должны приниматься, исходя из перспектив системы в целом. Каждая версия представляет определенный набор ключевых усовершенствований и принципов, которые, собственно, и определяют новизну версии. По определению это означает, что в каждой версии какие-то аспекты претерпевают бОльшие, а какие-то — меньшие трансформации, а что-то не меняется вообще. Другими словами, какие-то части системы активно дорабатываются для соответствия целям и задачам новой версии, а какие-то остаются "стабильными" от версии к версии. Это значит, что некоторые вещи, которые вы хотели бы увидеть обновленными, не изменятся, поскольку просто находятся в той области продукта, которую мы не перелопачиваем в ходе работы над Windows 7. Как мы уже говорили, при конструировании Windows 7 мы очень много сделали для увеличения производительности системы. Кроме планирования сценариев и измерений, мы уделили серьёзное внимание тем участкам системы, которые необходимо было изменить с тем, чтобы продвинуться дальше по намеченному пути. Но те участки, где выигрыш в производительности мог оказаться не столь значительным для того, чтобы служить оправданием для перемен, остались прежними. Мы придерживались этой стратегии на протяжении всего цикла создания системы, по мере того, как получали соответствующие данные от телеметрии.
• Как изменения повлияют на безопасность, надежность, производительность, совместимость, возможности локализации, доступность, программируемость, управляемость, настраиваемость и т.д.? Список всевозможных "-остей", которые система должна обеспечивать, поистине безграничен. Наши сотрудники проходят постоянное обучение и оттачивают свои навыки в достижении поставленных целей, и я могу без ложной скромности заявить — нами проделана огромная работа, и достоинства новой версии — превосходное тому доказательство. В нашей команде есть люди, чья деятельность целиком посвящена вопросам профессионального совершенствования сотрудников. Мы должны быть уверены, что всегда делаем все от нас зависящее для того, чтобы создать превосходный продукт. Работа по соотнесению предполагаемых и/или возможных изменений с перечисленными требованиями к системе — масштабная задача и важная часть наших исследований. Иногда мы замечаем, что то или иное изменение слишком сконцентрировано на одной из возможностей, которая связана с некоторыми другими — например, несложно обеспечить настраиваемость какого-либо параметра, но необходимо позаботиться, чтобы конфигурирование стало доступным и для администраторов, и для обычных пользователей, и для производителей ПК. Такого рода сложности присущи множеству сценариев использования, развертывания и управления парком компьютеров. Многие считают, что мы особенно перестраховываемся в тех областях, где изменения затрагивают аспекты поведения системы, которые никогда не менялись. Иногда правильным решением является оставить все как есть, чтобы обеспечить устойчивость и постоянство характеристик рассматриваемой подсистемы. Мы знаем, что отказ от одного от старых вариантов в пользу новшества, которое с таким нетерпением ожидается, просто перезапускает таймер новых ожиданий, потому что меняется абсолютно все — потребности, перспективы, да и сами люди.

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

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

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

Налаживание обратной связи и управление этапами разработки Windows — та деятельность, к которой мы подходим наиболее ответственным образом. Внутри компании идет непрекращающаяся дискуссия о том, что недопустимо почивать на лаврах, о необходимости непрерывного обучения для того, чтобы наилучшим образом выполнять нашу работу. В этом заключается и наша личная цель — сделать Windows еще лучше, понять, как сделать ее лучше. Безусловно, проблема выбора правильных решений будет и впредь вставать перед нами. Как и все остальные, кто трудится над продуктом, мы понимаем: наша главная задача — приложить все силы к тому, чтобы мы могли с полной уверенностью заявить, — мы создаём лучшую Windows 7, которую способны создать.

Стивен Синофски (Steven Sinofsky),
старший вице-президент Windows and Windows Live Engineering Group


Источник: http://blogs.msdn.com/e7ru
Перевод: Galaxer