微软 MS. Project 的产品逻辑：「象与骑象人」的博弈
预计阅读时间：17 分钟
导语
这篇文章的灵感来源于 6 月下旬的一个周六的晚上，我因为要准备内部培训要用的 PPT，做 research 时无意中发现了一件让我「认知失调」的事情，然后就开启了探索之旅。
这件「认知失调」的事情简单来说是这样的：在加起来使用 Microsoft Project （后续简称 MSP）软件两年的经验中，我一直认为这会是一个被不同用户群体（尤其是项目经理/产品经理）广泛使用的项目管理类软件，不仅是因为它在工作场合中和主流的微软办公软件共享同一种「语境」，也因为它用户体验做的非常出色。
于是我在准备 PPT 的时候，特地调研了几个做产品经理的朋友，想了解他们是如何进行项目管理的，以及在使用 MSP 过程中遇到的最大的挑战是什么。
让我觉得意外的回答是———他们几乎都表示微软的 MSP 他们虽略有耳闻，但目前公司通用的项目管理软件里并无 MSP 的存在。他们在用的软件大多数都是独立做项目软件的公司开发的，例如 Tower，Trello，Worklite…
于是我开始思考一个问题：这些大中型企业为什么在办公「语境」都是 Windows + Office 365 全家桶的情况下，唯独针对于项目管理（Project Management）却弃用了微软家族呢？
我写到这里的时候有点担心是不是我自己个人的主观爱好（偏见）导致了我对这款软件的误判断，特意去查了下行业的权威机构研究过后得出的数据。
代码界有一句我很喜欢的名言：「Talk is cheap，show me the code」（空谈无益，秀代码）
我们先通过一组数据来看看 MSP 的用户体验到底做的如何。
Forrester Consulting 在 2018 年 3 月份公布的 Total Economic Impact™ study 的研究表明：通过对微软现有的大客户（500 强企业）的访谈和财务分析和对比这些客户在使用 MSP 前后的数据，得出了以下结论:
387% return on investment. （387% 的投资回报率）
Net present value of $3.4 million. （净现值为 340 万美元）
Reduction of 83% in overtime costs. （减少了 83% 的加班成本）
我个人对于第 1 点和第 2 点没什么感觉，但是对于 Forrester 提到的第 3 点倒是体会的非常之深刻。
B612 光谱：Forrester 公司是一家独立的技术和市场调研公司，针对技术给业务和客户所带来的影响提供务实和具有前瞻性的建议。在业界，Forrester 公司已经被公认为思想的领导者和可信赖的咨询商。
在使用 MSP 后，我几乎没有因为项目汇报（Project Reporting）头疼过，类似于演示项目进度/资源情况的 PPT，项目各个环节的成本分析，展示项目进度和未来规划的 Gantt Chart 等，也没有再单独花时间做过。
于是在准备 PPT 的基础上，斜杠去研究了下 MSP 的发展史和微软在内部对它的战略定位，顺着这条线去做探索的时候，意外的发现了一些有趣的收获和洞察。在此以写稿的方式，与你分享。
用「微观视角」去观察「宏观战略」的好处是在于，你对商业逻辑的理解不再是纸上谈兵，而是深入到了真实的竞技场里的血与尘中。
正文由两个部分组成：
Part 1：期待的是你可以通过「了解」MSP 这款软件，去深度「理解」微软在做一款工具类软件的产品逻辑。
Part 2：从 MSP 这款产品的商业逻辑去「洞察」微软这两年一直在布局的办公自动化未来的画像：「没有孤岛，没有限制，只有连接。」
下面正文要开始了。
1.0 一张项目管理软件的产品思维导图
1.1 先来听听MSP的自我介绍
首先我们来看看现在官网是怎么介绍这款软件的。微软官方在 MSP 众多功能中，只选择了以下 3 点在官网首页进行说明：
项目管理：Microsoft Project 有助于轻松执行项目，内置的模板和熟悉的日程安排工具可提高项目经理和团队的工作效率。
项目组合：评估和优化项目组合以设置业务目标计划的优先级并获得所期望的结果。
资源管理：深入探索资源的使用方式以及如何使用集成工具进行协作。通过简化的任务和时间管理，团队可从任意位置输入更新，从而提供更好的执行监督。
我来用更简练的句子来概括下：
MSP 是微软自主研发的一款项目管理工具软件，它凝集了许多成熟的项目管理现代理论和方法。项目经理可以通过 MSP 内置的工具实现项目进度、成本的控制、分析和预测，使资源得到有效利用，提高效率，完成项目。
我去官方查了下，这款软件的价格也因为满足的企业的规模不同和用户需求的多样性，被分为了以下几个版本和价格（如下图）。
不难看出，Cloud-based solution 的 Project Online 在价格上要远远便宜于On-premise solution 的 Project Software。
而如果你点开 MSP 在微软官网上的主页，也会发现微软用了大量的版面在推广 Project Online，而并非独立的安装在电脑端的 Project Software。
这两者最大的区别是：Project Online 目前是 base 在 SharePoint Online 上，与 Office 365 具有相同的数据备份和保留策略。但 Project Software 是「本地解决方案」。
举个更形象的例子：Project Online 就像是随时同步无缝衔接于各个苹果设备的上的 iCloud（只要用同一个账号登录即可），但是 Project Software 是笔记本电脑的「本地 C 盘」。
这是不是很奇怪，微软从现任 CEO 萨提亚·纳德拉（Satya Nadella）2014 年上任开始不是早就已经 cloud-first 了吗？为什么 MSP 要分为两个模式去发展？ 让我们把镜头转个方向，去回看下 MSP 的童年，或许会发现一些线索。
1.2 极简成长史和重要里程碑
我在整理 MSP 的极简成长史时，甄选了具有「突破关键功能」的版本的作为 Key Milestone，如下：
1990：第一个基于 Windows 系统环境的 Project 1.0 发布，这被标记 Windows 的第一版本。
1992：Project 3.0 for Windows发布，在当年美国 PC Magazine杂志组织的评比中，被推荐为最佳软件。
1993：在1991年，首个麦金塔版本发布。于1993年发布的Project 4.0 for Mac。此后微软停止开发Project for Mac。
2010：Microsoft Project 2010 SP1 其实可以代表 Office 2010 系列在用户体验上质的飞跃。在这个版本上首次采用了用户现在非常熟悉的微软 Office Fluent 用户界面和直观设计，大大提升了用户体验和使用效率。
2013：第一个集成了 Modern UI-based 设计，并且引入了 Microsoft Account 和 OneDrive。 Reporting 的功能首次出现，包含图示化报告，可以在报告中比较不同的项目、制作仪表板和导出可视化报告。
2016：最后一个支持Windows 7和Windows 8的 MSP. 微软在这个版本中首次将「Reporting」作为一个独立模块。 Office 365 Project Time Reporter IOS 应用正式登上历史舞台，通过这个应用团队成员可提交时间表并报告通过 Project Online 跟踪的任务进度。
2019：2019 在功能上和 2016 区别不大，MSP 2019 只能在 Win 10 上运行。
从上面这个时间轴，不难看出，微软是在 2010 SP1 这个版本中将整个产品的用户体验进行了升级，而「云服务」的引入则是在 2013 年才完成。
从另一个角度也可以「反证」这一点—— 我去查了下 MSP 服务器的进化史（梳理如下）：
2000 – Project Central
2002 – Project Server 2002
2003 – Office Project Server 2003
2007 – Office Project Server 2007
2010 – Project Server 2010
2013 – Project Server 2013
2013 - Project Online（关键里程碑：云）
2016 - Project Server 2016/Project Online
2019 - Project Server 2019/Project Online
B612 光谱：「Project Server」是微软自 2000 年以来推出的一款项目管理服务器解决方案。它使用 Microsoft SharePoint 作为基础，并支持来自 Microsoft Project 的接口作为客户端应用程序，或通过 web 浏览器连接到它的 Project Web App (PWA) 组件，以实现数据同步。
其实 MSP 的极简成长史里，我们依次能看到的成长路径是：Project Sever 到 SharePoint Server → Office Fluent 用户界面（微软团队改善用户体验的关键节点）→ 集成化的 M.S. Account（战略转移到云服务的前提）→ Project Online 成为 Office 365 的成员（为未来办公自动化布局的前提）。
终于在 2013 年，MSP 正式告别了童年，在高速飞驰的 Azure（微软云）列车上有了自己的一席之地。接下来，这趟飞驰的列车便会带领着 MSP 把它的竞争者远远的甩在身后。
1.3 MSP的「产品逻辑」
在学习一款产品的时候，我非常推荐你去 deep dive 的深挖一款产品背后的逻辑。不管是微软现在广受好评的数据分析软件 PowerBI，还是刚起步没多久便大获赞誉的 MS. Team，又或者现在刚开始在微软舞台上崭露头角的 MS. Flow，都有各自的一套底层逻辑，并通过层层赋能的形式实现它对最终用户的价值。
MSP 也不例外，在做 research 的过程中我意外的发现它的使用逻辑主要还是基于项目管理业界最通识最基本的模型：PMBOK。
B612 光谱：「PMBOK」是 Project Management Body Of Knowledge 的缩写，指项目管理知识体系的意思，是美国项目管理协会（PMI）对项目管理所需的知识、技能和工具进行的概括性描述，项目管理领域最权威的「新华字典」。
PMBOK 将项目管理从宏观角度分为四个环节：启动（Initiate）→ 准备（Prepare）→ 执行 & 监控 （Execute & Control）→ 收尾（Close）。
而 MSP 的作用主要是体现在「执行和监控」（Execute & Control）这一环节，具体如下图所示。
此外，MSP 的核心功能几乎是围绕着「执行和监控」阶段的需求进行架构的。 看上去复杂度极高的 MSP ，其实核心功能只有 5 个，分别是：
WBS：创建 WBS（Work Breakdown Structure）是把项目工作按阶段可交付成果分解成较小的，更易于管理的组成部分的过程。
Resource：计划资源，并将所需的资源分配给活动，资源的分配是建立在 WBS 基础上的。
Gantt Chart：通过条状图来显示项目，进度，和其他时间相关的系统进展的内在关系随着时间进展的情况。（很多目视化管理都是基于甘特图去做的）。
Cost：预估成本，分析成本，和确定项目支出。一般来说是基于 WBS 对项目的所有工作任务的时间和预算进行运算。
Reporting：项目汇报是项目实施过程中到达某一节点时，是指项目经理将项目的开发成果给团队或者用户进行展示的工作。
而就像我画的 MSP 在项目「Execute & Control」阶段的 Roadmap 一样（下图），它的每一个核心功能与其他核心功能之间，甚至于其他核心功能的「下级子功能」之间都是有紧密关联的。
从图 3 不难发现，数据之间互为嵌套关系，而整体的数据嵌套逻辑和连接方式也遵循项目管理思维模型在「Execute & Control」的内部循环结构：Planning and Resource Allocation → Task & Control → Reporting → Review，接着再回到 Planning and Resource Allocation。*具体请参考图 2 中间在「Execute & Control」中间的循环 Loop。
1.4 如果一个项目经理拥有「产品思维」
我之前写过一遍文章深度的讨论过项目思维和产品思维的不同，MSP 作为一个项目管理类软件，它的产品逻辑是 building 在项目管理思维模型之上的。
但是微软在做整个产品的用户体验时，还是很大程度上体现了「产品思维」，而并非是「项目思维」。所以从 MSP 的视角，非常适合去深度聊一聊产品思维和项目思维的「囚徒困境」。 对于项目经理来说，ta 每天的生活很多时候都是一张张 to-do list，但如果微软在做这款产品的时候，只想着「我们做这款产品是为了让一个项目经理更高效的完成一天的工作」——— 这个就是我说的「项目思维」——— 认为关注产出是第一优先级。 那么 MSP 不过是变成了完成一张张 to-do list 的「订书机」。
项目团队被一种等待交付的心态所培养，那么在这样的环境下，项目能否成功很大程度上取决于「是否预先制定好了产品要求，设定了具有一个个节点的日程表，以及按照这些日期完成了交付。」
总的来说，「项目思维」的重点在于交付（delivery），交付完成则意味着完成了产出（output），主要的衡量标准就是时间轴和日程表。
但相反的，「产品思维」并不关注产出（output），而是关注结果（outcome）。
在任何团队中灌输一种植根于「产品思维」的文化，都会围绕产品、项目和团队创造一个长期、可持续的环境（我不否认打磨出一个产品是避免不了项目计划、评估、交付和输出的，尤其是考虑到 ROI），但产品思维是追求以最高的质量和出色的用户体验去交付产品的。
这样说还是有点抽象，我来举个具体的例子。
如果你站在微软的产品经理的角度去思考，你会听到用户的「意识-骑象人」在说，ta 想拥有一款可以让手头的项目有条不紊的按时完成的软件。但其实用户的「潜意识-大象」在说：
如果这是一款能够自动跟踪项目进度的工具，再多带一些 AI 功能那就更好了。如果项目进度有异常，可以自动发邮件给所有的相关方。
由于经常要给相关方（客户或者内部组织）汇报项目进展，那么这款软件最好可以自动生成 & 定制化各种项目报告。
因为办公室的软件基本上都是微软系列（O365 + Windows），最好在 MSP 内部就可以直接调用 PowerPoint 生成 PPT，或者可以直接调用 Excel 生成数据库，数据可以直接去 PowerBI 里去 run。
等等...
所以 MSP 并没有直接回答用户（骑象人）的「意识」———去成为一个 to-do list 的订书机，而是读懂了用户（大象）的「潜意识」里想说的话。 于是微软的产品经理从 2016 年开始布局 Project Online (cloud Version) 实现与手机移动端 Project Time Reporter App 的无缝衔接、实现自动化 reporting 的功能、深度整合进 MS. Planner 与 MS. Team 这款沟通类软件，与它们共享数据和资源、甚至实现了对 PowerBI 的接口开放———这些都是以「产品思维」作为基石，用工具作为载体去呈现的。
综上所说，我想用一句话来概括下对 MSP 产品思维的理解：“ MSP 是「项目思维」的降维体现，而「产品思维」是最终用户潜意识的地图。”
写到这里，我有一个问题想问你：微软的项目经理是靠什么能读懂用户的「潜意识-大象」的？
我想说肯定不是靠微软食堂的饭菜特别好吃，对吧。写到这里我真的有点饿。
在做 research 的过程中查阅到了一份普华永道关于 PM 相关的研究，这份研究一针见血的指明了「项目失败的最主要原因」，排名前 3 的分别是：
Projects that fail due to "breakdown in communications".由于“沟通”出现了问题而失败。
Projects that fail due to lack of planning, resources, and activities.由于缺乏计划、资源和活动而失败。
Project duration less than one year.项目定义的交付周期太短，在一年内就结束了。
如果我是微软的 MSP 的产品经理，这份行业研究报告我肯定要反复研究好几遍，以保证我在数据上的「认知」是跟得上行业「共识」的。
但如果只记得关注和分析数据，并不等于听懂了用户的「潜意识-大象」说的语言。因为数据只是共识，但是做产品需要的是在共识的基础上「共情」。
梁宁有一次在湖畔大学的演讲中讲过这么一段话，对我启发很深，她说：「我们需要有理性才能知道别人在哪一个点跟我们共情，才能知道我们所交付的产品，到底会触达用户情绪的哪个点。而共情的力量在我们这个社会中，是远远大于共识的。」
在这里共情指的是什么呢，其实就是指同理心（empathy）。
用户的情绪和感受汇集成了「用户体验」，而用户对于产品的反馈也会作用于产品经理的情绪和感受。产品经理在收集了足够多的反馈后，会在这种投射的基础上以产品作为载体，再去影响用户的思维和行动。
而「同理心」在中间形成了桥梁去连接主体和客体，在二者之间来回穿梭，探索动力的起承转合。最终，二者博弈之后的结果再以「产品」为载体交付给最终用户，形成了「产品价值」。
MSP 在 2013 年之后的成长路径是令人惊喜的，它不再是一头只听得懂意识的大象了。它在现任 CEO 纳德拉上台后，慢慢的成长为了一头具有同理心，并且可以听得懂骑象人语言的大象。
而这不仅仅是 MSP 的转变，也是微软企业文化的巨变。
2.0 微软的未来：没有「数据」是一座孤岛
在 PPT 结尾的时候，我曾经抛出过一个问题：如果你是微软的产品经理，接下来你要做什么？（先独立思考下，再去看下文。）
我想做个大胆的假设，可以总结为以下两点：
逐步淘汰 MSP 本地桌面软件。实现方式：通过价格差异，慢慢的去培养用户流量转移到 Project Online 版；
深度集成 Azure，更换 MSP 目前的数据服务平台，让 MSP 不再作为项目管理软件的「独立景观」，而是成为未来办公软件里的「混合景观」：无数种组合，无限种场景。
接下来，我会向你演示是如何推导出这个结论的。
2.1 「语境」变了，用户场景也随之变化
过去几年，由于大环境发生了变化，我们从 PC 电脑时代过渡到了移动互联网时代。与此同时，企业「语境」下对项目的定义也发生了很大变化。
由时间表和里程碑组成的大型、正式的项目（包含固定的日期和可供分配的资源）仍然是常见的。但与此同时，由小团队组成，可能工作几个小时或几天，或临时的、短期的项目也变得多了起来。
尤其是后者，在互联网公司和创业公司变得越来越常见。这种情形描述起来就类似于：每个人都是项目经理，每个人都在从事多个项目，每个人都有工作之外甚至都会有由兴趣小组自发形成的项目（例如我们 T.G.F. 翻译组之类的>_<）。
试想如果只能在 Windows 系统上使用 MSP，那便是和未来的办公场景形成了冲突。加上微软在 Project Online 和 MSP 桌面软件之间如此之大的定价差异，不难看出微软是在做流量转移。
所以，这里的结论对应第 1 个假设：微软会通过价格差异的方式逐步淘汰 MSP 桌面本地软件，慢慢的去培养用户转移到 Project Online 版。
2.2 MSP不再是「独立景观」
在做 research 的时候发现了一个很有趣的现象：虽然 Project Online 目前实际上是建立在 SharePoint Online 之上的，但微软正在创建的未来的 Project 的新服务是建立在 Common Data service for Apps（CDS） 平台之上的，也就是说 SharePoint 在不久的将来会被这个新的数据平台所取代。
而 CDS 恰好是建立在 Dynamics 365 之上的，PowerBI 也是 based on Dynamics 365，所以说 Dynamics 365 开始作为基础架构串起了跨平台的数据库，并正式成为了微软新的生命线。 那么问题又来了：什么叫 Dynamics 365？之前一直在说 Office 365，这个 Dynamic 365 难不成是 O365 的升级版？
为了更好的理解这个问题，我去补了下今年 5 月 6 日举办的微软 Build 2019 开发者大会，这场一年一度的大会上微软给出的信息量是巨大的，和我们今天这篇文章主题有关也恰好是 Build 2019 的重头戏—— Dynamics 365。
微软 CEO 萨提亚·纳德拉（Satya Nadella）在 Build 大会上更新了微软的全新平台架构：「以 Azure 为基础，支撑起 Microsoft 365、Microsoft Dynamics 365 & Power Platform 和 Microsoft Gaming 三大平台。」
这三驾马车之一，就有刚刚提到的未来 MSP 的数据平台：Dynamics 365。
Dynamics 365 的功能比较复杂，结合微软官方的描述，允许我用简单的话来概括下：
它建立在微软的心脏「Azure」之上，按需订阅、可以实现快速部署和灵活扩展、无需 IT 升级维护。
打通了与 Microsoft Azure、Office 365、HoloLens 等微软平台、服务和产品之间的联系。
通过数据、智能、应用、设备之间的无缝衔接，成为了一个能广泛覆盖各行各业、不同应用场景，并且真正融入人工智能、物联网、混合现实等高科技的「云商业平台」。
Dynamics 365 的出现在微软整个商业史上是具有里程碑作用的，它是目前「地球」上首个打破传统，将 CRM（客户关系管理）和 ERP（企业资源计划）功能融为一体的 SaaS 级应用（下面这张图用了比较形象的图片描绘出了它的无限种可能性）：
此外，Build 2019 大会上纳德拉公布的另一个数据让我有点惊讶，他表示：「9 成的 500 强企业都在使用 Dynamics 365 & Power Platform。」
在你刚刚了解过 Dynamics 365 到底是做什么的后，会发现这是一个非常恐怖的数据。
这个数据意味着微软让在商业帝国里最有话语权的 450 个企业之间的数据不再是「孤岛」，可以通过无限种组合被挖掘、分析、重组、延展、赋能。
我开始明白 MSP 为什么要弃用之前的生命线 SharePoint 了。
因为 Dynamics 365 和 SharePoint 两者之间最大的区别是：Dynamics 365 是一个开放并且联动的数据平台，它会破除自身企业与其它企业之间的「孤岛」问题。
构建在 Common Data Service 允许 MSP 的数据从「多个源」集成，集成后便可以实现跨场景的使用。
最常见的，例如在 MS. Flow 和 PowerBI 中使用；例如被集成进 MS. Planner，而恰好因为 Planner 可以被集成进 MS. Team，所以 MSP 之前一直缺失的「即时沟通」功能之后不需要再独立开发了，因为它在别的产品的应用场景里已经被完成了，MSP 只需要和拥有「即时沟通」功能的软件进行「连接」就好。
而做出这样改变根本的原因是由于「产品使用的场景发生了变化」。
未来的企业之间项目与项目之间，项目与项目成员之间的组合越来越多样化和「去中心化」。在语境发生大的变化后，用户情绪被触发的场景也发生了变化，所以微软要为新的场景去调整战略。
还记得导读里问的那个问题吗？———为什么 MSP 并没有像其它 Office 办公软件一样成为互联网公司产品/项目经理的首选。
其实答案在这里已经找到了：因为 MSP 的桌面版只支持本地管理，不符合现代互联网公司的办公语境。而微软对 Project Online 的数据服务平台的转移和整合目前是 ongoing 的状态，还未完成。
以上，对应前面第 2 个假设：让 MSP 不再作为项目管理软件的「独立景观」，而是成为未来办公软件里的「混合景观」——无数种组合，无限种场景。
2.3 微软的「道」
文章的标题里我提到了 MSP 的产品逻辑是「象与骑象人」的角色博弈。这个标题其实也是目前我对于微软的产品之「道」的抽象解读。
它有两层意思：
第一层是指产品经理和用户之间的博弈其实是「象与骑象人」角色之间的博弈。是潜意识和意识的博弈。
第二层是站在更高的维度思考后得出的结论：纳德拉上任后带领微软进行转型的战略，也是纳德拉这位「骑象人」和微软这头「大象」之间的博弈。
纳德拉在他自己的传记《刷新》这本书的核心理念可以被概括为，他认为人类实现自我刷新需要三个步骤：
拥抱同理心。
培养无所不学的求知欲。
建立成长型思维。
在我看来，对于一个企业来说难度最大的是「拥抱同理心」，不仅仅是因为商业世界的现实和残酷，更多的是「同理心」在企业中是个很难被量化的品质。 纳德拉在书中提到过一个观点，我读的时候挺感动的，他说：
在这样一个科技驱动、人工智能驱动的时代，同理心变得比任何时候都珍贵。创意固然重要，但是同理心更重要，应该被放在最核心的位置。
纳德拉希望将同理心置于所追求的一切中心———从发布的产品到新开拓的市场，再到员工、客户和合作伙伴。这可能也是为什么在他上任后，便宣布微软的新使命是「赋能全球每一人、每一个组织，帮助他们成就不凡」。
无法否认的是坎坷的个人经历塑造了纳德拉超乎常人的同理心，而他将这种心理学概念延伸发挥到了管理学中并不仅仅是因为他拥有这样的品质，而是因为他的「选择」。
比起一个人说了什么，他选择去做了什么是更重要的。或者说，只有通过他做的事情，你才会理解他说的到底是什么。
将「同理心」深深扎根与微软的转型文化中的纳德拉到底只是说说而已，还是真的奉行它作为「第一原则」，只要看今日微软的变化即可。
纳德拉上任的 5 年来（2014 年到 2019 年至今），我也慢慢的从学生时代只用过 PPT、Excel、Word 到工作后用微软全家桶（MS. Team, Flow, PowerBI, MSP 等），几乎是一步步看着纳德拉这个骑象人如何将微软这头大象一点点驯服的。
「驯服」的方法其实很简单：微软转型的成功是文化的成功。因为一家企业成功或失败，是其现行文化的滞后反应。
回想起在微软上任 CEO 史蒂夫·鲍尔默（Steve Ballmer）时代，微软高管的 Tim O’Brien 曾把当时微软的文化比作「狗咬狗」，他说：「就像是一群被狮子追赶的人。为了活命，你不必成为跑得最快的，你只需要比最慢的人跑得快就够了。」
但微软运气很好，就像 IBM 在绝望之际请来了郭士纳；微软跌入谷底时纳德拉从内部员工变成了 CEO；哪吒也在夕阳下海滩边遇见了敖丙与他一起踢毽子。
纳德拉上任后，在微软内部大力推广文化转型，「选择」将同理心置于微软所追求的一切的中心。以此作为桥梁，微软终于听懂了大象（用户）的语言。终于在 2019 年微软重新成为全世界市值第一的公司，回到了浪潮之巅。
纳德拉这位骑象人「驯服」的不仅仅是微软这只大象，而是一直存在于商业世界里「理性」与「感性」的囚徒困境。他「选择」了后者，是因为他「选择」去深入到真实竞技场的血与尘中去战斗。
也是因为他明白，商业世界里的故事可以演变出万千种可能性，唯一不变的，是「人性」贯穿始终。
结语
之前在写 OneNote 的那篇文章，我在总结的时候写过一段话，是这么说的：
微软的边界正变得前所未有的模糊，它越来越像「水」，你感受不到它的存在，但又深知，水之润下无孔不入。
同时，微软的边界也变得越来越清晰，它用无形的水，汇聚成了「护城河」，利用自身强大的资源优势，为护城河里的内部生态赋能
在看完 Build 2019 开发者大会和写完微软在 MSP 背后的产品逻辑后，越来越觉得现在的微软不仅仅是在赋能了，它其实在连接———「没有孤岛，没有限制，只有连接。」
而在思考完 MSP 的产品逻辑后，最让我自己触动的一点是：
微软其实并不是商业规则这个 Game 的赢家，是它转型背后所代表的「文化信仰」赢了。
是在理性与感性之中选择看见人性的「产品思维」赢了。
是人类的「同理心」赢了。
- End -
Last updated
