Volatility （易变的）当今世界的变化越来越多，越来越快，越来越不可预测。很多情况下，由于事件发生得太快，以至于我们没办法准确地判断其起因甚至其影响度；今天我们所在经历的疫情就是一个最好的例子：疾病的发生所引发的一连串变化（中国-全球，医疗资源危机-经济危机，民众对疫情观感的变化-各国应对疫情的政策变化）

Uncertainty（不确定性）历史上的任何一个时代所带来的经验已经无法为当今世界的所有变化提供参照。上个世纪的流感大爆发不能为这次新冠疫情提供任何的参考，甚至连十几年前非典的经验都不能全部被应用。

Complexity（复杂性）由于社会和科技发展速度及其成果的积累，各种问题的产生原因，其带来的影响和反应会受到更多不同因素的相互牵制，而这些相互牵制已经多到无法让人可以对这个问题有个全局观，因此想找到一个直接而明确的解决方案在很多情况下变得越来越不可能。

Ambiguity（模糊性）“放之四海而皆准”的原则已经越来越少。越来越多的东西或概念甚至连清晰地为之定义或划定边界都变得困难。非黑即白的判断标准也似乎越来越不适用，因此，对一个组织来说，比之前的任何一个时代都要为了应对这些模糊的问题而产生不同的判断准则，有的时候这些准则之间甚至是互相矛盾的，以致于有的时候会触动到组织内个人的价值观判断。因而每做一个决定都需要更强的勇气，敏感度以及敢于承担错误的胆量。

作为个人，如何更好地应对VUCA时代呢？

尝试理解变化，与不确定性（uncertainty）相处。

1.以不变应万变不是最合适的表述，用个不恰当的比喻，也许更像是激流下的水草，能随波而动，但根基扎实。所以关键是在于夯实自己的根基。不时地为自己按下暂停键，并看看周围。这样可以帮助你理解并发展出新的思考方式去应对任何一种改变。当然，投入更多的资源（不仅是金钱，更多的是时间和精力）去分析并不断加深对你所处的行业的认知，而且把这个变成你自己的一个优先要处理的事务。甚至，常和你的同行或客户保持必要的交流，这样，你不会落后于行业。多为自己做做复盘也是必要的，因为只有这样你才知道下次哪里可以做得更好。如果精力和能力允许的话，还可以多拿一些你所精力的事件来复盘和推演。这些都会让你对不同的事件有更多方面的认知，从而为以后可能会遇到的事件的不确定性奠定一个稳定的个人基础。

2. 用清晰来应对复杂性（Complexity）

越是复杂的问题越不能单打独斗，因此，对于团队的协作性要求就越高。任何时候，与人的沟通都必须清晰，有效，特别是对你的团队成员或者是合作伙伴。清晰的把你的想法沟通到位能帮助大家理解你的或者组织的方向。另外，清晰的沟通方式能促进团队协作的效率，使得工作的节奏能更快。

3. 以灵活性去抗衡模糊性（Ambiguity）

水至清则无鱼，只要有了鱼在浊水中的视线及灵活度，就能更好地在模糊地视野中找到正确地路径。计划要做好，但同时要做好Plan B或者留有变更的余地。多和不同的领域的人共同工作（你的eco system内的各种资源），通过这样增加工作的知识和经验会比只留在一个领域更丰富，可以在模糊的事实前获得更多的切入角度。鼓励金点子的分享，特别是对于有创造性的以及容错度高的点子，不妨做出一些奖励，这样能成为其它团队成员的榜样并形成正向的循环

我所理解的 Scrum 的目的在于两点：

适应变化。Scrum 的一个基本假设，就是外部需求模糊而难以理解。Scrum 对此的理念是：让客户直接看到半成品，他们才知道自己要什么。很多 Scrum 的原则都是围绕如何解决这个问题的：比如每个 Sprint 结束时由 Product Owner 为客户进行展示，又比如任务细化一般不超过一个 Sprint。理解了这一点，才会理解为什么 Scrum 似乎总在变化，因为需求总在变化。

快速迭代。Scrum 的另一个基本假设，是团队生存在一个快速变化且充满竞争的世界。如果自己一年半才能发布一个新版本，而竞争对手半年就能发布，那么几年之内，我们就会被对手甩得远远的。Scrum 对此的理念是：发布即 Milestone（里程碑），宁可每次发布二十个功能发布五次，也不要在内部搞五个 Milestone 然后一口气发布一百个功能。理解了这一点，才会理解为什么 Scrum 会认为发布时砍功能是一种正常情况而非一种失败。

Scrum 开发流程通常以 30 天(或者更短的一段时间)为一个阶段，由客户提供新产品的需求规格开始，开发团队与客户于每一个阶段开始时挑选该完成的规格部分，开发团队必须尽力于 30 天后交付成果，团队每天用 15 分钟开会检查每个成员的进度与计划，了解所遭遇的困难并设法排除。

实施流程的话，请看图，整个Scrum可以分为这样几个阶段：

1.产品经理整理出需求列表，做好优先级别，这些需求可以来自客户或者产品经理的判断

2.开个会，和研发团队一起讨论需求列表的工作量

3.研发团队确定要进行Sprint（冲刺开发）的任务，并确定有限级别

4.研发团队进入开发环节，这个期间可以让产品经理修改需求，但是不得延期或修改验收标准。Sprint期间每天要进行站会，汇报工作进展、问题和下一步计划

5.再开个会，和产品经理一起验收产品，并确定最终的可发布版本。

6.整个团队一起回顾项目，提出改进点，然后进入下一个Sprint