Промышленный цикл исследований

Мы вкладываем средства в научные исследования, которые могут и не давать Microsoft немедленной выгоды, однако позволяют компании получать дополнительные компетенции в долгосрочной перспективе. Рассказывает Томас Бол, ведущий исследователь и менеджер группы Research in Software Engineering (RiSE) в Microsoft Research.

Когда больше 14 лет назад я стал руководителем исследовательского подразделения Microsoft (Microsoft Research, MSR), я произнес перед его новыми сотрудниками такую речь:

«Как и научно-исследовательские институты, MSR дает вам свободу вести свои собственные исследования, расширяя границы научного знания. Однако здесь у вас есть еще и дополнительная задача — способствовать экономическому росту Microsoft. Для этого вам необходимо будет соотносить свои научные интересы с интересами компании, особенно когда вы начнете расти по служебной лестнице».

Все эти слова так же верны сегодня, как и тогда, когда я присоединился к MSR 17 лет назад. Они хорошо отражают цели MSR: двигать вперед науку, не забывая о развитии нашей компании.

Для описания работы MSR я использую модель под названием «Промышленный цикл исследований» (The Industrial Research Cycle). Исследователи могут свободно выбирать проблемы в своей области и заниматься ими (левая сторона схемы) для продвижения науки. Но после завершения общего анализа своей темы на них возлагается обязанность заняться специализацией тех исследований, которые, как они считают, могут принести выгоду компании (правая сторона). В идеале проблемы и решения, которыми сотрудник занимается в левой половине цикла, в конечном счете должны приводить к экономическому росту компании в правой половине. Кроме того, на правой стороне модели ученый проверяет свои научные выкладки, масштабирует полученные результаты и знакомится с новыми направлениями работы, которыми сможет заняться на следующей фазе цикла. На протяжении своей карьеры исследователь неоднократно меняет сторону модели.

Долговременные результаты

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

Формы долгосрочных преимуществ хорошо видны на графике «результативности» (Impact). Результативность для научного сообщества указана по оси Х. По оси Y указана результативность для компании Microsoft (см. врез). Степень результативности зависит от площади фигуры под графиком. Форма графика результативности изменяется со временем — как на протяжении промышленного цикла исследований, так и в зависимости от карьерного роста исследователя.

На этапе исследования фигура результативности на графике, как правило, горизонтальна, потому что исследователь прежде всего работает на научное сообщество. На этапе специализации форма фигуры результативности чаще всего вертикальна и опирается на фундамент, заложенный во время этапа исследований.

При том что мы поощряем активные публикации наших исследователей, MSR не гонится за количеством работ — нас прежде всего интересует их качество.

Партнеры и производственный процесс

MSR вкладывает средства в научные исследования, которые могут и не давать Microsoft немедленной выгоды, однако позволяют компании получать дополнительные компетенции в долгосрочном периоде. На схеме «Долгосрочный план» (Long-term play) видно, что превращение результатов научных исследований в бизнес-результат часто требует координации усилий на протяжении длительного срока.

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

Автоматическое выявление дефектов и проверка качества драйверов

В конце 1999 г. Срирам Раджамани (Sriram Rajamani) запустил в MSR проект SLAM, посвященный поиску новых подходов к автоматическому поиску дефектов кода в драйверах устройств. В 2002 г. была создана группа проверки качества драйверов Windows, куда вошли также Байрон Кук (Byron Cook), Джейкоб Лихтенберг (Jakob Lichtenberg) и Владимир Левин. Вместе они разработали инструмент под названием Static Driver Verifier (SDV) на основе подсистемы SLAM. Первая версия SDV была встроена в Windows в 2004 г. На протяжении последующего десятилетия MSR трижды совершенствовала и заменяла базовую подсистему анализа SDV (можете ознакомиться с отчетами о SLAM2, YOGI и Corral). Этим занимались разные группы исследователей, которые тесно сотрудничали с группой проверки качества драйверов. Среди них были Элла Боунимова (Ella Bounimova), Адитья Нори (Aditya Nori), Рахул Кумар (Rahul Kumar), Шаз Кадир (Shaz Qadeer), Акаш Лал (Akash Lal) и Шувенду Лахири (Shuvendu Lahiri).

От эмпирической программной инженерии к инструментам для разработки

В 2004 г. я взял на работу в MSR Начи Нагаппана (Nachi Nagappan), чтобы он возглавил ведущиеся в Редмонде исследования в области эмпирической программной инженерии. На протяжении пяти лет Начи и его коллеги Брендан Мерфи (Brendan Murphy), Яцек Червонка (Jacek Czerwonka), Кристиан Берд (Christian Bird) и Томас Циммерман (Thomas Zimmermann) исследовали ключевые проблемы, препятствующие повышению качества ПО и эффективности разработчиков. Для этого они анализировали истории версий продуктов, базы данных о неполадках и другие источники.

Для анализа этих проблем в масштабе всей компании к Начи, Брендану и Яцеку присоединился Вольфрам Шулте (Wolfram Schulte). Вместе они создали CODEMINE — аналитическую платформу для сбора и анализа данных рабочих процессов Microsoft в области программной инженерии. Этот проект под кодовым названием SWEPT начался приблизительно в 2009 г. и был завершен около 2013 г., пролив свет на множество проблем разработки ПО, актуальных для самых разных продуктов Microsoft. Платформа CODEMINE позволила создать новую группу Средств программной инженерии, которая сейчас занимается переводом нашей компании на облачную инфраструктуру программной инженерии.

Уроки информатики

Относительно недавно, в 2011 г., в MSR был запущен проект Touch Develop (www.touchdevelop.com). Перед его участниками стояла задача сделать возможным написание программ для смартфонов на самих смартфонах. Неожиданно этот проект оказался востребован в системе школьного образования — учителя обнаружили, что детям очень нравится программировать свои смартфоны, чтобы те реагировали на события окружающей среды.

В результате совместно с BBC мы разработали небольшие компьютерные устройства с простой в обращении платформой для написания кода (основанной на Touch Develop). В 2016 г. был выпущен миллион таких устройств, названных micro:bits, — такого тиража хватило, чтобы обеспечить ими всех пятиклассников в Великобритании. Опираясь на опыт с micro:bits BBC, Microsoft сегодня разрабатывает новую платформу программирования, которую можно использовать для обучения школьников.

Координация масштабного решения масштабных проблем

Сегодня лишь несколько компаний занимаются проектированием распределенных систем в планетарном масштабе. Такие системы уже построили Amazon, Facebook, Google и Microsoft и теперь оптимизируют их с целью повышения производительности, надежности, доступности, безопасности и конфиденциальности. Microsoft Azure — одна из таких систем. Она предлагает вычислительные службы, услуги по хранению данных и сетевому подключению, а также взаимодействует с растущим числом мобильных устройств и конечных точек «Интернета вещей».

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

Вот четыре новых масштабных проекта, связанных с облаком, в которых участвует группа RiSE (группа по исследованиям в области программной инженерии):

• Язык программирования P меняет подход программистов Microsoft к проектированию крупных асинхронных систем. Язык P был использован для разработки драйверов USB 3.0 в Windows, а также сервисов Microsoft Azure.
• Проект Everest («Эверест»)— создание полной высокопроизводительной, стандартизированной и сертифицированной версии экосистемы HTTPS, от API HTTPS до таких криптографических алгоритмов, как RSA и AES.
• Проект Parade («Парад»)— параллелизация большого класса на первый взгляд последовательных приложений: для этого зависимые друг от друга компоненты запускаются одновременно с использованием символических значений. Результаты этого проекта уже приводят к значительному росту производительности популярных алгоритмов машинного обучения и обработки больших данных.
• Проект Premonition («Предупреждение») нацелен на обнаружение патогенных организмов до того, как они вызовут вспышки заболеваний. Для этого создаются новые технологии, способные в автономном режиме обнаруживать, собирать и численно анализировать патогены, переносимые с кровью москитами.

Участие в нашем цикле исследований

Чем бы вы ни занимались — исследованиями широкого профиля или специализацией конкретных решений, — работать в исследовательском подразделении Microsoft невероятно интересно. Если вы хотите присоединиться к нашим ученым, посетите страницу вакансий.