Microsoft Teams as a Platform(微软团队平台)

2020年成为#WFH(在家工作)的一年，对于许多组织来说，这也是微软团队成为“工作”的主要场所的转折点。这加速了团队从仅仅是连接人类的通信工具演变为许多类型的业务应用程序的基础服务层。

将团队作为平台的概念与微软的Power Platform技术套件有何不同，这是我最近一直在思考的问题。在这篇文章中，我将首先回顾团队起源的相对较短的历史。然后，我将研究最近发布的功能如何将应用程序带入团队的前沿。最后，我想谈一谈作为微软更广泛战略的一部分，团队可能的未来。

回顾大约10年前，微软的实时通信和即时消息工具似乎正在经历一个无穷无尽的更名周期：从OCS到Lync，再到Skype for Business。呈现给最终用户的核心功能集似乎没有产品品牌发展得那么快。在更广泛的层面上，组织内信息工作者的通信活动通常仍在Outlook的收件箱中进行，不同的服务器(如SharePoint和Dynamics CRM)都打包了各自的功能，以便向其他用户发布短消息。

Skype团队只需成为Office Group服务的最终用户应用程序即可。否则它为什么会存在？#Office365 pic.twitter.com/pTU6sXexHd。

-Jukka Niiranen#ForwardForever(@jukkan)2016年9月6日。

4年前，当当时被称为“Skype团队”的第一批图片开始泄露时，我们已经在等待微软创造出比另一个在线会议工具更雄心勃勃的东西。办公团队已经开始在MS云中的不同地方出现，但它们主要是一个技术构造，没有合理的UX供普通人接近。即使是Dynamics CRM也有自己的解决方案，尝试将Office 365组中与帐户或商机等记录相关联的讨论、日历、笔记、文档和团队成员整合在一起：

我记得曾与我们的CRM客户进行过多次讨论，在那里我试图引导人们远离部署此组解决方案。相反，我想鼓励他们等待一些更精致的东西，我知道这些东西迟早会上路的。

据报道，微软对收购Slake的计划相当认真，因此有一种明显的现实危险，那就是另一个“Yammer时刻”可能会发生。回想起来，微软决定继续投资于构建自己的产品，而不是试图将像Slake这样的现有服务改造到他们现有的软件产品中，这对双方来说都是一件好事。

我会争辩说，微软从那时起在他们的商业软件堆栈中一直遵循的这种“建立在购买之上”的战略是BizApps特别成功的关键因素。它使微软从仅仅追逐Salesforce这样的CRM竞争对手，转向与Power Platform重新定义商业应用程序的竞争环境。收购公司并将它们捆绑成“X云”与设计自己的软件堆栈作为真正的平台之间有着截然不同的区别。

最初，微软团队(Microsoft Teams)产品的第一个版本于2017年春季正式上市，主要集中在三个方面：

从业务应用的角度来看，在2018年秋季发布第一个集成功能的预览版之前，你并不能做太多事情来将团队与Dynamics 365联系起来。特别是，团队提供的集成文件共享体验几乎就像许多CRM专业人员的圣杯，可以修复SharePoint集成故事中缺乏任何安全模型同步的明显漏洞。下面的路线图图像显示了2年前有关团队和Dynamics 365如何集成的计划：

#MSDyn365 CE App for#MicrosoftTeams的公共预览版将于下个月发布，GA将于年底发布，Dynamic->；Teams UI功能稍后推出。Pic.twitter.com/q2x55skcJ0。

-Jukka Niiranen#ForwardForever(@jukkan)2018年9月26日。

路线图上的最后一项仍未交付，即Dynamics 365记录表中团队对话的可见性。在我看来，为什么微软没有更优先地实现这一点，这似乎是一个迹象，表明微软团队如今是如何被定位为所有信息工作的主要用户界面的。MS可能更希望一切都从团队内部开始。您将记录选项卡固定到频道中，在团队讨论中显示记录预览，通过机器人界面与记录交互，等等。只要团队是所有工作都在其下进行的大伞。

因此，缺乏深度的双向整合并不意味着没有对所涉及的产品进行投资。它可以简单地反映正在构建的新愿景，通过调整许多现有服务来形成一个整体，其目标是大于其各部分的总和。

举个例子，如果你看看微软的任务管理故事，你会看到来自不同应用程序的功能和数据，比如To Do、Planner和Outlook Tasks/标记的电子邮件，目前正被折叠到一个中心位置，这就是团队的任务应用程序。作为通用构造的任务不一定需要由单个数据库完全控制，但是它们非常需要在团队定位的“团队工作中心”中进行逻辑表示。

展望未来，当新的应用程序出现在MS云产品组合中，并且它们需要向用户提供任务管理功能时，合乎逻辑的集成点将是团队。对于活动提要类型的功能，产品开发的选择甚至更加明确：选择搭乘团队，而不是发明另一个短消息流。

超越了简单地将团队与产品X、Y和Z集成在一起，我们现在看到了一种模式的兴起，在这种模式下，应用程序是专门为团队使用而构建的。当然，通过开发定制的Web服务和使用SDK，这在很长一段时间内都是可能的。现在出现了许多特性，它们将特别围绕无代码/低代码的团队展开平台故事。

微软列表应用程序是第一个正式上市的应用程序，它为用户提供了一个超低的门槛，让用户可以通过可配置的现成UI在单个表格中处理数据。当通过团队访问时，列表数据获得了另一个特殊维度：关于列表项的讨论。这与前面提到的集成为Dynamics 365记录提供的使用模式基本相同。

在微软列表的新封面下，是SharePoint列表中熟悉的技术。如果我们只检查UI层，那么它实际上与一种名为Airtable的流行的无代码服务有惊人的相似之处。如此之多，以至于指责微软简单地抄袭竞争对手的视觉和核心功能似乎并不完全没有道理。

通过比较这两个产品，我们可以对这些工具的目标市场定位有一定的了解。简单列表本身并不是一个特别独特的功能，而是团队协作功能和数据共享的简便性将这些表转变为您所说的真正的应用程序。顺便说一句，就在本周，Airtable宣布，他们正在构建一个完整的平台，其中的应用程序提供基于JavaScript的可扩展性，一个共享应用程序的市场，执行业务逻辑的自动化，最后是一个跨环境(“基础”)传输数据的同步服务。

围绕半结构化数据(如列表和Excel样式表)的协作场景可以被视为一种入门药物。它们允许将基于电子邮件或纸张的手动流程转变为数字流程可能是什么样子的快速初稿。如果自动化上述过程确实有明显的商业利益，那么对更复杂的应用程序功能的需求很快就会开始从用户群中浮现出来。因此，协作平台应该提供一条明显的途径，将这些预构建的应用程序体验发展成更高级的无代码/低代码应用程序。

如果Microsoft List等同于团队上下文中的Excel表，那么Project Oakdale/“CDS Lite”可以被视为将SQL Server引入团队。现在，很明显，微软并不打算用团队内置的功能来真正取代Excel或SQL。他们只需要介绍那些从团队协作角度看有意义的部分。

Microsoft List与真正的Excel工作簿的功能相去甚远，但它可以在协作场景中提供比那些单独的.xlsx文件更多的价值。类似地，即将在团队中构建Power Apps的CDS版本远不及Dynamic365等支持企业CRM系统的服务(或SQL提供的原始功能)强大。尽管如此，在每个团队中都可以找到CDS，并且使用它的受众比Power Apps公民开发工具希望获得的受众要多得多-这些因素可以真正使CDS成为主流服务，Microsoft 365云中的大多数信息工作者都会与其交互。

在Project Oakdale中定义CDS数据模型的体验将与Power Apps制造商所经历的道路非常不同-更不用说XRM老手了。事实上，您很容易将表格设计和行条目UX误认为是Microsoft列表而不是CDS。这突出了一个并不是所有Power Platform专家都掌握的关键方面：对于MS来说，这个“CDS Lite”并不是决定将Full Power Platform的哪些高级功能免费提供给团队的后学者，而是关于如何最好地将CDS的企业CRM功能简化为团队用户可以自己采用的新产品。

这并不意味着微软团队应该只被视为微软将Power Platform扩展到大众中的一种机制，通过“降低它”来实现。如果团队的应用程序平台故事像它应该的那样发展，那么它对企业业务应用程序开发也应该有明显的好处。

消息传递、通知、任务管理、文档或群组成员资格等功能并不是Power Platform工具非常擅长的。由于历史原因，一直需要将独立功能构建到XRM中，以满足业务应用程序场景中的这些类型的常见需求。对于正在创建的未来几代应用程序，很容易看到将这些非核心功能卸载到更适合管理它们的平台上的好处-这意味着团队。

即使团队提供的功能集不能涵盖原生Dynamics 365功能的所有深度业务逻辑集成，也无关紧要。归根结底，这不是为了支持记录系统的传统，而是鼓励新的低代码场景，这些场景将在平台上产生100倍以上的应用程序。

操作系统的概念我们中的许多人可能会追溯到个人计算机时代的起源，即使操作系统的存在时间当然比IBM PC要长得多。就知名度和商业成果而言，Windows是操作系统领域的第一个巨大成功，塑造了微软大约30年的命运。随之而来的是移动计算时代，Android&；iOS取代了运行移动计算的设备数量。微软不再希望重新夺回这一地位，因此他们决定接管计算领域的另一个层面：(商业)应用云。

Azure一直被称为“世界的计算机”，这确实提供了一些视角，让我们了解自PC时代以来计算概念是如何演变的。不过，Azure不是大多数人会直接与之互动的东西。为了在未来几十年中保持相关性，微软也需要在终端用户的头脑中存在。现在Windows已经成为现代计算堆栈中可选的一部分，在高于传统操作系统但仍低于单个应用程序的水平上获得足够强大的立足点将是相当关键的。一个跨越商业世界中人们正在使用的所有设备的平台。

团队现在是微软可以支配的最接近的东西，它可以转变为一种OS风格的结构，将全球相当一部分的信息工作者联系在一起。当然，与Windows的光辉岁月完全不同，但我们应该期待看到微软采取非常有意识的步骤，以推动团队变得更像操作系统的目标。用户与大量应用程序交互的地方，与这些应用程序共享其工作上下文的地方，各种应用程序之间交换数据的“服务总线”，最后是用于通知和消息传递的统一通信通道。

要实现这种类型的转变，协作工具成为人们今天在#WFH办公室使用的大量其他应用和服务的真正重心，还有很长的路要走。就我个人而言，我不能忍受MS团队内容嵌入到用户身上的多任务限制，我更喜欢一个单独的浏览器选项卡集合来自由切换。尽管如此，对用户产生的认知负荷并不是每个人的理想工作方式，这并不是完全疯狂的。这意味着组织需要寻找通过团队等公共信息工作中心优化员工体验的方法。

新帖子：#平台战略能帮助@MicrosoftTeams赢得这场漫长的游戏吗？Https://t.co/1SUgtj0pHT我的观点：我一直在寻找数字工作场所的重心。球队还没有到达那里，但正朝着正确的方向…前进。#协作#团队聊天#集成#cio pic.twitter.com/JCCFGlYLhT。

-Dion Hinchcliffe(@dhinchcliffe)2020年9月8日。

Dion Hinchcliffe写了一篇关于微软与团队的平台战略的出色分析，其中他谈到将团队视为工作的操作系统。虽然确实很难让客户组织中协作工具的当前所有者接受团队的业务应用程序方面的需求(特别是现在有了#WFH热潮及其意想不到的需求)，但当时机成熟时，无论是从技术能力方面还是从组织目标来看，观点都可能会发生变化。就像MS CRM基础发展成为当今称为Power Platform的更广泛的低代码应用程序平台的关键要素一样，协作工具和业务应用程序之间的障碍不应该被认为是一成不变的。