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

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

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

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

Управление изменениями

Определения Управления изменениями варьируются в зависимости от вашей перспективы. Технические разработчики обычно определяют управление изменениями как дисциплину управления изменениями технических объектов (т. Е. Кода, данных, параметров конфигурации). Конечно, это критически важный процесс, с которым мы все сталкиваемся при работе с нашими приложениями. Но фокус управления изменениями, которым Facebook и другие поставщики облачных решений должны заниматься, — это управление опытом клиентов и то, как они включают эти изменения в свой бизнес.

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

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

Управление изменениями в облаке

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

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

Отсутствие в отрасли внимания к управлению изменениями клиентов показывает, насколько низок уровень зрелости в отрасли облачных вычислений. И даже лидеры отрасли виновны в неправильном направлении усилий по управлению изменениями. Я часто пользуюсь Службами Google в своем бизнесе и на клиентских сайтах. Я удивлен тем, как часто появляются новые функции или изменения, и я не знаю, что они появятся. Не раз у меня были таблицы с формулами, которые неожиданно перестали работать, а потом обнаружил, что появилась новая функция. Я извиняюсь перед Google за то, что выбрал их (я не хочу, чтобы мой SEO отключили!), Но это показывает, что даже бегемоты отрасли еще не поняли это.

Управление изменениями как конкурентное преимущество

Я предполагаю, что ваше приложение не конкурирует с Google (пока!), И это может быть точкой в ​​вашу пользу. Планирование улучшений и обновлений для вашей клиентской базы и их графика будет отличительной чертой, которая поможет вам выделиться среди конкурентов.

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

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

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

Сегментируйте ваших клиентов по ранним пользователям и дайте избранным скидку на ваше приложение, признавая важную роль, которую они играют в вашем процессе управления изменениями. Заставьте их чувствовать себя особенными и вознаградите их за обратную связь. Отправьте их по альтернативному URL во время пробного использования (при условии, что вы сможете успешно перенести их данные) и следите за их использованием и любыми проблемами с обслуживанием. Эта группа служит барометром для управления изменениями. Успешное развертывание и оценка их опыта будут иметь большое значение для прогнозирования воздействия новой версии на всю клиентскую базу.

Другой вариант — запускать несколько версий вашего приложения по разным URL-адресам. Возможно, у вас уже есть базовая и премиальная версии, которые можно использовать в качестве клиентских сегментов. Отправляйте каждый сегмент в свое приложение через отдельный URL-адрес и развертывайте только один сегмент за раз. Это дает вам возможность убедиться в эффективности вашего развертывания и определить, готов ли он к прайм-тайму. Конечно, в этом нет необходимости, если ваш процесс тестирования является пуленепробиваемым, и вы хорошо знаете своих клиентов… верно?

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

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

Мой опыт показал, что управление изменениями обычно считают тем, что делают только «большие» компании, и оно не является необходимым или практически невозможным для небольших фирм. Но опыт также показывает мне, что его часто игнорируют в компаниях независимо от размера. Правильно, Фейсбук? Нарушение обслуживания и потерю доверия еще более важно избегать в небольших компаниях, если они хотят стать более крупной компанией.

Как вы обновляете и разворачиваете свое приложение в современной среде? Это техническая или деловая активность, в которой участвует вся ваша команда? Мне интересно знать, как вы относитесь к управлению изменениями в своих приложениях и влияет ли устройство, на котором они развернуты, на вашу стратегию. Не стесняйтесь, пишите или комментируйте ниже. Что касается меня, я пойду онлайн, чтобы понять, что это за временная шкала.