背景

钉钉工作台是什么？
工作台组件是什么？
工作台服务的用户是哪些？

工作台

钉钉移动端客户端中间的tab就是组织工作台。2020年5月份之前，组织工作台上只是罗列了应用的图标。用户的心智是在这里找到应用的入口，随即便离开工作台进入到应用内部。而钉钉工作台肩负着帮助组织提升协同效率、实现业务在线的使命。如何更好的发挥工作台的价值是我们持续思考的问题。

钉钉工作台有两大核心用户，一是应用提供方(ISV、钉钉一方应用业务团队)，二是组织用户。所以工作台既要帮助应用在工作台上更快捷的和用户交互，又要帮助组织用户更好的使用工作台实现数字化协同。

我们希望工作台不只是应用的入口，而是可以在工作台上直接透出更多业务属性并进行有效交互。我们希望和应用提供方一起，可以精准化、精细化的服务组织用户。组件开放是工作台尝试的第一步，也是工作台走向开放的一大步。

从2020年5月份开始，工作台携手各个应用，逐渐将一方应用的核心功能封装成业务组件提供给钉钉上的组织使用。业务组件包括考勤、审批、日志、待办、公告等。管理员可以将其设置显示到组织工作台上，方便用户直接在工作台上进行互动。

老版本工作台仅显示应用的图标：                 新版本工作台的业务组件，用户可直接互动：

组件使用数据表明，这些组件被很多组织安装到工作台。例如考勤组件，有近千万的组织安装。从显示考勤图标到展示考勤组件，工作台对考勤新增组织的贡献度也因此提升了8.7%。

用户

工作台的业务复杂性在于，它本身既是一个面向开放的平台，又是钉钉的一个面向组织用户的应用，同时也是面向钉钉应用运营的2个场(工作台和广场)之一。
对于开放，这里涉及到一方、二方、三方不同的开发者。不同的开发者有不同的特质，各方的应用也有不同的权限等级以及应用场景。
对于组织用户，有标准工作台的用户，也有定制工作台的用户，有管理员，也有普通员工。用户对标准工作台和定制工作台的使用期望存在差异，例如定制工作台用户可能不希望看到推荐的应用。管理员、老板、财务、员工等不同角色可能希望看到不同的工作台内容。因此在做方案时，需要整体考虑多方体验和权益。
对于场的运营，希望能通过工作台做到精准推荐。需要工作台能够沉淀场景化角色化的用户标签，以及为运营提供智能决策支持。

工作台简化用例图：

组件

工作台的组件按照权限场景可划分为三类：

全局组件通常由一方提供，实际也可以由一方授权ISV来提供。
可以是不具有业务属性的基础组件，可以是和一方应用关联的业务组件，也可以是和应用不关联的业务组件。
全局组件不需对用户进行安装授权，和一方应用一样，所有组织默认都有权限使用。
全局组件可应用于标准工作台、定制工作台、服务门户、广场等多渠道。

生态组件通常由ISV或者SI提供，实际也可以由一方商业化的业务来提供。
可以是不具有业务属性的基础组件，可以是和一方应用关联的业务组件，也可以是和应用不关联的业务组件。
和微应用关联的组件分为两类，可以随微应用同时授权，也可以在微应用内购。
不和微应用关联的组件可以由ISV或者SI提供授权(商业化链路)。
例如在定制工作台场景中，通常在设计器中只有SI服务商自己可见。当为用户定制工作台并发布后，授权给用户组织使用。
可用于标准工作台、定制工作台、服务门户等多渠道。

通常是具有研发能力的组织自研的私有组件，实际也可以由组织授权SI为自己专门定制。
可以是不具有业务属性的基础组件，或者是可以和应用关联或者不关联的业务组件。
可用于标准工作台、定制工作台、服务门户等渠道。

组件开放

组件开放服务的用户是谁？
要解决的用户问题是什么？
实现的用户价值是什么？

一个组件从设计、开发、销售、使用、维护的全过程，涉及到的角色包括组织工作台管理员、组织员工、开发者、运维人员、品的运营人员、工作台的技术支持等等。这里的核心链路有两个，一是组件的生产链路，二是组件的运营链路。
生产链路要解决的是生产力问题，如何帮助开发者或运维人员提高产能，缩短开发周期。而运营要解决的是消费问题，如何让组织管理员或员工可以更方便更快捷找到他们需要的品并开始有效的使用起来。
因此，生产力和运营力是平台需要提供的两种主要能力。

生产力

组件或工作台的生产者是谁？
自主开发和借助平台生产的区别是什么？
平台和生产者的边界怎么划分？

组件的生产者主要是ISV的开发人员。开发者研发一个组件大致经历如下过程：
在平台注册一个新组件->在本地IDE中开发组件->在IDE中调试测试->提交组件代码及组件配置->提交上架审批->灰度发布->全量发布->根据线上反馈调整需求计划->进入新迭代周期。

为方便理解，组件生产可简化为如下链路：

在组件研发周期中，平台和开发者如何合作呢，边界怎么划分呢？
这里可以参考成熟的PaaS和SaaS之间的划分。通常来说，PaaS是将软件开发、测试、运维的平台作为一种服务提供，而SaaS只需关注应用开发本身。结合工作台的业务特性，围绕如何降低工作台组件的开发、交付、运维成本方面的事情：

● 协议规范：组件设计规范、组件开发规范、组件接入规范、开发文档
标准化一方、二方、三方组件的设计和开发。

● 开发者工具：脚手架、Cli工具、组件接入校验、基础组件库
通过Cli工具减少开发者重复劳动、提升开发效率、规范开发流程develop workflow，并为Pro Code开发者提供标准的基础组件库。

● 插件上架审核：静态代码扫描、组件规范校验、自动审核、通知服务
通过审核工具落实组件接入规范，自动化提升审核效率。

● 开发者服务：文档开放、智能机器人、交流平台、答疑培训
通过一系列服务，降低开发者上手成本，提升开发者解决问题效率。

● 运维能力建设：监控告警能力、发布管理、数据能力
提升系统健壮性，降低开发者和ISV的运维成本。

这里还会涉及到很多细节，例如开发规范中的JSAPI权限分层，每一层API是多一个还是少一个，例如组件审核上是松一点还是紧一点，是全自动还是附加人工审核，例如组件代码扫描是到哪个质量程度，严格一些还是宽松一点，得反复在实践中摸索并和开发者保持共创，最终才能做出最适合工作台组件特有的规则来。

工作台的生产者，除了开发人员，还包括组织工作台的管理者或运营人员。一些有自运营能力的组织，例如百丽集团，有小组专门负责工作台的运营。他们认为工作台是应用的集合，用户基于工作台所提供的能力或服务完成日常业务事项。计划通过工作台品牌化、定制化、角色化运营达成提升工作及协同效率的目的。
这里需要平台提供工作台上各个组件使用数据，方便用户了解员工使用工作台的情况，针对性对工作台内容做调整，更好的对工作台做维护。

运营力

组件或工作台的运营者是谁？
运营面临的问题是什么？
平台可以做什么？

对于应用或组件的运营，他们的诉求是希望基于不同的用户画像，在合适的场景为用户提供合适的品、组品的推荐，提升用户发现及使用品的概率和效率，强调的是平台提供的客户角色与商品的精准匹配能力。
对于工作台，平台的运营小二希望促使上诉目的达成，提升转化率，产出爆款带动生态繁荣。

这里要解决的关键问题是：
● 精准识别用户
理解用户，可以精确描述用户画像
● 准确触达用户
角色化、场景化触达
● 触手可及
用户需要使用什么，随手可得

平台需要提供投放配置、资源位管理、策略服务、效果评估等能力。平台需要理解用户行为，沉淀用户标签体系。建设可投放资源位，既可以智能投放，又可以手动调整。

未来规划

我们希望工作台不只是应用入口，也不只是业务在工作台上的透出。我们希望可以携手生态伙伴，从工作台这个平台完成应用(组件)从设计、生产、销售、使用、维护的全过程，形成2场(工作台、广场)加3品(应用、组件、组品)的3+2一体化解决方案，进而更有效的促活生态，为钉钉上的组织服务。

3+2一体化方案：

工作台技术体系大图：

当前，服务层的设计态、管理态、运行态能力已经具备基础能力。通过设计态和管理态的能力开放，服务商可以为组织用户在工作台中进行布局、样式等的设计和搭建，组织管理员可以对工作台上组件的显示隐藏、排序、可见人员范围等进行设置管理，将工作台打造成千行千面、千人千面的数字化协同终端，从而达到企业品牌建设、文化宣传、业务运营等目的。

能力层，目前主要集中在开发工具、运维能力的建设，当前进行中的项目包括：

工作台开放的推进不是仅仅凭借工作台的几个人能完成，而是依靠工作台、开放平台、支付宝小程序、钉钉小程序、钉钉各业务团队以及生态伙伴的持续联合作战。立足当下，着眼未来，相信再经历几番真枪实弹的战役之后，工作台开放生态会迎来更加欣欣向荣的崭新局面。欢迎有兴趣的同学来一同探讨~~

相关资料：

钉钉开放平台的定制服务之路---前台搭建技术在亿级用户量产品的应用