Концепцию минимально жизнеспособного продукта (minimally viable product, MVP) можно понимать по-разному. Некоторые считают, что речь идет об изделии, обладающем достаточными функциональными возможностями для того, чтобы оправдать его разработку. Программный код такого продукта функционален и демонстрирует то, что он, собственно, должен делать по замыслу разработчика. Такое решение можно использовать для выполнения определенной работы.

Есть и другая точка зрения, согласно которой изделие категории MVP всего-навсего указывает на то, что может появиться в будущем, если все пойдет хорошо. Иногда я теряюсь в догадках: какой из упомянутых точек зрения придерживается команда разработчиков Office 365? На свет появляются все новые приложения и функции, и я задаю себе вопрос: «Как же все это прошло тестирование?» Затем следует череда усовершенствований, и вот уже через пару месяцев код продукта лишь отдаленно напоминает то, с чем мы познакомились на начальном этапе. Если вы пользователь, пришедший из мира локально устанавливаемых продуктов, все это покажется вам очень странным.

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

Когда задумываешься над тем, как Microsoft выпускает программы для платформы Office 365, это тоже вызывает вопросы. Дело не только в том, что мы мечемся между выпусками обновлений. Сегодня все уже принимают как должное, что, когда мы подписываемся на ту или иную «облачную» услугу, обеспечивающие ее предоставление программные продукты обновляются, и нам приходится с этим мириться: так уж все устроено. Но теперь вопрос, похоже, состоит в том, чтобы разобраться в терминах, которыми представители Microsoft пользуются для описания доступности того или иного программного средства. Попробую изложить все это на языке, понятном сообществу пользователей локального программного обеспечения.

С тех самых пор, как специалисты Microsoft взялись за разработку корпоративного программного обеспечения, в частности Windows NT, они задействуют бета-версии программ, чтобы предоставить в распоряжение отдельных пользователей новые программные средства еще до выпуска окончательной версии. Одни группы продуктов работают с этими программами лучше, чем другие. Так, команда разработчиков Exchange уже давно реализует хорошо организованную программу TAP (Technology Adoption Program), предполагающую перевод сотен тысяч локальных почтовых ящиков в производственных сетях на новые версии Exchange еще до выпуска этих версий на рынок.

За прошедшие годы мы привыкли к тому, что значительные новые версии продуктов выходят приблизительно раз в три года. При этом жесткой зависимости точной даты выхода окончательной версии (released to manufacturing, RTM) таких решений, как Exchange, SharePoint или SQL, от зрелости соответствующего программного продукта или от стабильности его работы не отмечается. Понятно, что разработчики должны выйти на определенные показатели в отношении качества, но часто дата выпуска версии определяется соображениями маркетинга, такими как коллективное объявление «волны» серверов Office.

Разумеется, с позиций сегодняшнего дня концепция RTM выглядит безнадежно устаревшей. Если раньше «золотые» копии программных продуктов передавались в производственные помещения, где их переписывали на дискеты (именно такая радость, как перелив программного кода на жесткий диск компьютера с целого вороха дискет, ожидала тех, кто собирался устанавливать на своем компьютере продукт вроде Word for Windows), компакт-диски или DVD-диски, то сегодня текущие версии, скорее всего, загружаются с веб-сервера Microsoft. И тем не менее RTM остается важным этапом в жизненном цикле продукта, и вокруг него клиенты строят свои планы.

Как правило, приблизительно через год после достижения продуктом стадии RTM Microsoft выпускает первый пакет обновлений (service pack, SP1). Принято считать, что на данном этапе соображения безопасности уже не препятствуют развертыванию решения в производственных сетях. Ранее выявленные ошибки исправлены. Сотрудники прошли переподготовку. Сторонние поставщики обновили свои программы. Всеми овладевает согревающее душу ощущение комфорта, и жизнь приносит радость.

Однако в «облаке» классический цикл «бета-версия — RTM-версия — SP1-версия» не утвердился. На фоне неспешного процесса развертывания новых программных продуктов в локальных сетях «облако» реализует изменения с поистине головокружительной скоростью. Изменяются пользовательские интерфейсы, появляются новые приложения, функции исчезают или трансформируются. И вообще потребителям нужно «держать нос по ветру», если они хотят понять, что же, собственно, происходит.

Жизненный цикл продуктов Office 365 начинается с предварительного знакомства, когда доступ к новым программам предоставляется избранным клиентам. Данный этап напоминает фазу бета-тестирования локальных программных систем в том смысле, что в обоих случаях разработчики имеют одно и то же намерение: обнаружить ошибки и убедиться, что продукт функционирует стабильно. Некоторые программные продукты (такие, как Delve) задерживаются на стадии предварительного знакомства на протяжении нескольких месяцев, тогда как другие буквально «проскакивают» этот этап за несколько недель.

Следующий шаг — первый выпуск (First Release). Клиент соглашается на допуск к программному продукту всех своих пользователей или какой-то их части до того, как это смогут сделать другие потребители. Данный шаг дает корпорации Microsoft возможность приобщить к программному средству большее число пользователей и в то же время позволяет клиентам опробовать новые функции на несколько недель раньше всех остальных. До того момента, когда такое приложение, как ориентированный на управление заданиями Office 365 Planner, станет достоянием общественности, в него можно внести множество изменений.

Еще одно осложнение проистекает из того факта, что Microsoft публикует объявления о новых возможностях примерно в то же время, когда программный код выходит на стадию первого выпуска. Если следовать логике текста, можно заключить, что та или иная новая функция появится, что называется, вот-вот. Но на самом деле может оказаться, что данное средство станет доступным пользователю лишь по прошествии нескольких месяцев. И этот факт не может изменить даже целый ворох живописнейших снимков экранов. Сказанное в полной мере относится к недавнему объявлению о продукте Office 365 Admin Center. Всякий, кто попытался поработать с новым интерфейсом, скажет вам, что это изделие функционирует медленно, допускает сбои и оставляет желать лучшего в отношении функциональности. Но о его выпуске было объявлено, и это замечательно.

В конечном итоге специалисты, ответственные за работу тех или иных функций, приходят к выводу, что код готов, программный продукт включается в версию Standard Release of Office 365 и становится общедоступным (Generally Available).

В переводе на язык пользователей локальных систем этап First Release будет эквивалентен этапу RTM, а стадия Standard Release — стадии SP1, поскольку клиенты, подключившиеся к процессу на стадии First Release, выполняют тестирование программного обеспечения. Они хотят убедиться в том, что его использование безопасно и продукт работает хорошо, до того, как на это отважится подавляющее большинство потребителей.

И здесь я перехожу к «обкатке» (flighting); этот термин используется для описания развертывания программных обновлений в рамках платформы Office 365. Различные группы разработчиков «выбрасывают» программное обеспечение в различные сроки и различным клиентам. Это побочное следствие работы с состоящими из множества клиентов кругами пользователей, сорганизованными на региональной основе. Результирующий эффект состоит в том, что ваш клиент может применять не то программное обеспечение, которое использует другой клиент в другом регионе Office 365, и это при том, что вы оба, казалось бы, работаете с одной и той же версией.

Хотя мы можем проводить аналогии между процессом бета-RTM-SP1 в мире локальных продуктов и циклом Preview-First Release-General Availability в «облаке», сопоставление лихорадочного «вбрасывания» в систему Office 365 решений, когда они кажутся незавершенными, с размеренным выпуском различных версий локальных продуктов невозможно. Данную мысль прекрасно иллюстрируют группы Office 365. Эта фантастическая концепция с превосходным набором функциональных возможностей была загублена в первые дни ее существования, поскольку была реализована со множеством «дыр». Позднее некоторые из них были залатаны, тогда как другие, скажем функция мягкого удаления (soft-delete capability), так и не были воплощены. Похоже, что в «облаке» идея срочности взяла верх над идеей качества. Сегодня все делается ради того, чтобы оказаться на шаг впереди конкурента.

Получить представление о циклах выпуска и освоить незнакомую терминологию, применяемую в среде Office 365, наверное, не самая насущная задача администраторов, которым требуется перенести рабочую нагрузку с локального оборудования в «облако». Однако в данной ситуации, как часто бывает в нашей жизни, чем лучше вы будете ориентироваться в деталях, тем меньше вероятность того, что вас застигнут врасплох. Понимание смысла терминов и ясное представление о том, когда можно ждать появления новых программных средств, — это как раз и есть такие детали.