lo云中_管理云中的变更

lo云中

Let’s imagine a scenario that many of us secretly hope to achieve. You’re a bright developer with a good idea. You create a cloud-based app allowing your subscribers to send messages to each other and keep tabs on each other’s whereabouts every day. Did I say every day? No, you’re seriously smart and now you can track them in real-time all the time. Soon you have dozens of people…no, hundreds…wait! Now there are thousands of subscribers signing up daily.

让我们想象一下我们许多人暗中希望实现的方案。 您是一个聪明的开发人员，有个好主意。 您创建了一个基于云的应用程序，该应用程序使您的订户可以彼此发送消息，并且可以每天查看彼此的下落。 我每天都说吗？ 不，您非常聪明，现在您可以一直实时跟踪它们。 很快，您就会有数十个人……不，数百个人……等待！ 现在，每天有成千上万的用户注册。

You know it’s important to engage with your subscribers regularly and you learn more about them every day. You tweak the way they use the app and soon they’re sharing practically every aspect of their life with you. You’ve created a human behavior test lab and you’re pulling the strings! You’re able to spot trends in what they’re shopping for, where they’re shopping…even what they’re hungry for. At this moment!

您知道定期与订户互动非常重要，而且您每天都需要了解更多有关订户的信息。 您可以调整他们使用该应用程序的方式，很快他们就会与您分享生活中的各个方面。 您已经创建了一个人类行为测试实验室，并且正在努力！ 您可以发现购物趋势，购物趋势……甚至是他们渴望的趋势。 此时此刻！

Attempting to improve the app, you roll out a new version. But rather than appreciating your efforts to “help” them, your user community rebels and begins making disparaging remarks throughout their community postings and the blogosphere. Those free-loading subscribers who have never paid you a dime think they can drive the design and feel of your app!

尝试改进该应用程序，然后推出新版本。 但是，您的用户社区没有意识到您为“帮助”他们所做的努力，而是反抗并开始在他们的社区帖子和博客圈中发表贬低的言论。 那些从未向您支付一毛钱的免费订阅者认为，他们可以推动应用程序的设计和风格！

Okay, I’m obviously talking about Facebook here. Their recent rollout of new features to keep their app fresh generated many complaints and comments from their user community keeping them in the news. The adage about bad press being better than no press may apply to celebrities—but Silicon Valley is not Hollywood. While painful, Facebook’s change management trials are not unique and should be monitored closely by all cloud-based app designers and developers. There are lessons to be learned and those lessons have been taught in the IT industry for many years.

好吧，我在这里显然是在谈论Facebook。 他们最近推出了新功能以保持其应用程序的新鲜度，从而引起了许多用户社区的抱怨和评论，从而使他们成为新闻焦点。 关于坏新闻胜于没有新闻的格言可能适用于名人，但硅谷不是好莱坞。 尽管痛苦，但Facebook的变更管理试验并不是唯一的，应该由所有基于云的应用程序设计人员和开发人员密切监视。 有很多经验教训，这些经验已经在IT行业中教授了很多年。

更换管理层 (Change Management)

Definitions of Change Management vary depending on your perspective. Technical developers typically define change management as the discipline of managing change to technical objects (i.e. code, data, configuration parameters). Of course that’s a critical process and something all of us deal with when working with our apps. But the change management focus that Facebook and other cloud solution providers need to be concerned with is managing the customer’s experience and how they incorporate that change into their business.

变更管理的定义因您的观点而异。 技术开发人员通常将变更管理定义为管理对技术对象(即代码，数据，配置参数)进行变更的准则。 当然，这是一个关键的过程，我们所有人在使用我们的应用程序时都需要处理。 但是，Facebook和其他云解决方案提供商需要关注的变更管理重点是管理客户的体验以及他们如何将这种变更纳入其业务。

Adapting to change is generally difficult for everyone. Some amount of disruption is to be expected but you have to know how to manage expectations during the transition to change. Slipping in a new angry bird whenever you feel like it probably won’t give your customers much concern. But add a new page in the middle of the shopping cart checkout process and you could lose a lot of buyers. Change an accounting app in the middle of month-end or quarterly processing and you could lose a lot of subscribers.

每个人通常都很难适应变化。 预期会有一些破坏，但是您必须知道如何在变更过渡期间处理期望。 每当您感觉到一只新愤怒的小鸟可能不会给您的顾客带来太大的困扰时，他们都会穿上它。 但是，在购物车结帐流程的中间添加新页面，可能会失去很多买家。 在月末或季度处理的中间更改会计应用程序，可能会丢失很多订户。

One of the primary benefits of cloud-based apps from a customer’s perspective is the low cost of entry for using a new app. Your goal is to build an app that is “sticky” so customers never want to leave–but poor change management is a sure way of losing stickiness and customers sending them to competing solutions.

从客户的角度来看，基于云的应用程序的主要优势之一是使用新应用程序的入门成本低。 您的目标是构建一个“粘性”的应用程序，使客户永远不想离开–但是糟糕的变更管理是一种确定的方式，可以避免丢失粘性并将客户发送给竞争解决方案。

云中的变更管理 (Change Management in the Cloud)

Prior to the cloud, solution providers facilitated change management by allowing their customer base to run different versions of the product—simple enough to do when customers managed their own servers and every customer had their own instance of the app. Customers were given lead times to plan for upgrades and prepare for business process changes, testing and training. Customers deployed product upgrades when their schedule permitted and paid for implementation teams to support them through the upgrade.

在使用云之前，解决方案提供商允许其客户群运行不同版本的产品，从而简化了变更管理，这非常简单，可以在客户管理自己的服务器并且每个客户都有自己的应用程序实例时进行。 为客户提供了交货时间，以计划升级并为业务流程变更，测试和培训做准备。 客户在时间表允许的情况下部署了产品升级，并支付了实施团队的费用来支持他们进行升级。

Your customers now push those upgrade activities and responsibilities back to you, the cloud solution provider. The cloud reduces the customer’s total cost of ownership and also reduces their control of the application—much to their annoyance. Unless you’re being very transparent with your upgrade schedule and plans (and few providers are), your customers have to react to changes rather than prepare for them proactively.

您的客户现在将这些升级活动和职责推还给您(云解决方案提供商)。 云降低了客户的总拥有成本，还减少了他们对应用程序的控制，这极大地困扰了他们。 除非您对升级计划和计划非常透明(很少有提供商)，否则您的客户必须对更改做出React，而不是主动为更改做准备。

The industry’s lack of focus on customer change management illustrates just how low the level of maturity is in the cloud computing industry. And even industry leaders are guilty of misdirecting change management efforts. I frequently use Google Apps in my business and at client sites. I’m surprised at how often new features or changes are released without me knowing they’re coming. More than once I’ve had spreadsheets with formulas stop working unexpectedly and then found out a new feature was released. I apologize to Google for picking on them (I don’t want my SEO shut off!) but that shows that even the behemoths of the industry haven’t yet figured this out.

该行业缺乏对客户变更管理的关注，这说明了云计算行业的成熟度多么低。 甚至行业领导者也对误导变更管理工作感到内gui。 我经常在公司和客户站点中使用Google Apps。 我对新功能或更改发布的频率感到惊讶，而我不知道它们即将发布。 我不止一次让带有公式的电子表格意外停止工作，然后发现发布了一项新功能。 我向Google道歉并选择了它们(我不希望我的SEO关闭！)但这表明，即使是行业的庞然大物，也尚未弄清楚。

将变更管理作为竞争优势 (Change Management as a Competitive Advantage)

I’m assuming your app doesn’t compete with Google (yet!) and that could be a point in your favor. Planning enhancements and upgrades around your customer base and their schedule would be a differentiating feature helping you stand out from your competition.

我假设您的应用程序无法与Google竞争(但！)，这可能是对您有利的一点。 围绕客户群以及他们的日程安排计划增强和升级将是一个与众不同的功能，可帮助您在竞争中脱颖而出。

Change Management from a business or customer perspective is the discipline of managing the introduction of new features or process changes to the users of your app or process. Customers and users must be prepared to use those new features before they are deployed. Communicating with your customers about the types of changes, letting them know why changes are coming and training them in the use of the changes are the first change management steps to take.

从业务或客户角度来看，变更管理是管理向您的应用程序或流程的用户引入新功能或流程变更的准则。 客户和用户必须准备好使用这些新功能，然后再进行部署。 与客户沟通有关变更类型的信息，让他们知道变更为什么会到来并培训他们使用变更是采取的第一个变更管理步骤。

A typical cloud app or service places all customers on the same instance. Introducing new features then means all customers get the features at the same time. There’s no early adopter customer trying out a beta-version prior to rollout to all customers. At least that’s been my experience. But does it have to be like that?

典型的云应用程序或服务会将所有客户置于同一实例上。 这样，引入新功能就意味着所有客户都将同时获得这些功能。 没有早期采用者的客户在向所有客户推出之前试用Beta版。 至少那是我的经验。 但是一定要那样吗？

A potential next step in maturity for the cloud would be a more disciplined approach to software deployments and change management. I realize cost is a consideration and maintaining one instance of an app or service for all subscribers is cheaper than multiple versions. But there are options.

云计算成熟度方面的下一步可能是对软件部署和变更管理采用更严格的方法。 我意识到成本是一个考虑因素，为所有订阅者维护一个应用程序或服务的实例要比多个版本便宜。 但是有选择。

Segment your customers into early adopters and give a select few a price break on your app acknowledging the important role they play in your change management process. Make them feel special and reward them for their feedback. Send them to an alternative URL during the trial (assuming you can port their data successfully) and monitor their usage and any service issues. This group serves as a barometer for change management. Deploying successfully and gauging their experience would go a long way towards forecasting the impact of a new release on your entire customer base.

将您的客户细分为早期采用者，并在您的应用程序上选择几个价格优惠措施，以确认他们在变更管理过程中扮演的重要角色。 让他们感到特别，并奖励他们的反馈。 在试用期间将它们发送到备用URL(假设您可以成功移植其数据)，并监视其使用情况和任何服务问题。 该小组是变更管理的晴雨表。 成功部署并评估他们的经验将有助于预测新版本对整个客户群的影响。

Another option would be to run multiple versions of your app at different URL’s. You may already have basic and premium versions that can be used as customer segments. Send each segment to your app through a different URL and deploy to only one segment at a time. That gives you a chance to witness the impact of your deployment and determine if it’s ready for prime time. Of course, this is all unnecessary if your testing process is bullet proof and you know your customers intimately…right?

另一个选择是在不同的URL上运行应用程序的多个版本。 您可能已经具有可用作客户群的基本版本和高级版本。 通过不同的网址将每个细分发送到您的应用，并且一次仅部署到一个细分。 这使您有机会目睹部署的影响并确定是否已准备就绪。 当然，如果您的测试过程是防弹的并且您非常了解您的客户，那么这一切都是不必要的……对吗？

I understand the cost of supporting multiple versions of your app may be an issue. But wouldn’t you want to find out early whether your changes caused customers to greet your new app with open arms or flee to your competition? Wouldn’t that investment be worth it to prevent customer flight if things go wrong?

我了解支持您的应用的多个版本的费用可能是个问题。 但是，您是否不希望早日发现更改是否导致客户张开双臂迎接您的新应用程序或逃脱竞争呢？ 如果出了问题，这笔投资是否值得防止客户外逃？

Communicating to your customers throughout your development cycle and convincing them of the need for change is an important part of not only change management but also customer relationship management. It’s not all about how well you know your customers. It also about them knowing and TRUSTING you. Change management is a technique you employ to build and demonstrate that trust.

在整个开发周期中与客户沟通并说服他们对变更的需求，不仅是变更管理的重要组成部分，也是客户关系管理的重要组成部分。 这不仅关乎您对客户的了解程度。 这也与他们了解并信任您有关。 变更管理是您用来建立和证明信任的一种技术。

My experience has shown that change management is usually considered something that only “big” companies do and isn’t necessary or feasible for small firms. But experience also shows me that it’s often ignored at companies regardless of size. Right, Facebook? Disruption of service and loss of trust is even more critical to avoid in small companies if they want to grow to be a larger company.

我的经验表明，变更管理通常被视为只有“大”公司才能做的事情，而对于小公司来说则是不必要或不可行的。 但是经验也告诉我，无论规模大小，公司通常都会忽略它。 对吧，Facebook？ 对于小公司来说，如果要成长为一家大公司，那么避免服务中断和失去信任就显得尤为重要。

How do you upgrade and deploy your app in today’s environment? Is it considered a technical activity or a business activity that involves your entire team? I’m interested in knowing how you’re addressing change management with your apps and if the device on which they’re deployed impacts your strategy. Feel free to email or comment below. As for me, I’m going online to understand what this Timeline thing is.

您如何在当今的环境中升级和部署您的应用程序？ 它是涉及整个团队的技术活动还是业务活动？ 我很想知道您如何通过应用程序解决变更管理，以及部署这些应用程序的设备是否会影响您的策略。 请随时在下面发送电子邮件或发表评论。 对于我来说，我将上网了解时间轴是什么。

翻译自: https://www.sitepoint.com/managing-change-in-the-cloud/

lo云中