大家好，先自报家门，我是PingCode CTO。
关于竞品的比较是个容易动怒的话题，大家都是屁股决定脑袋，没有理性分析，全是猜忌和动机论。PingCode 从来不想陷入竞品口水仗，我们也从来不敢号称比对手效率提升68%。而且，我们真心也是蛮认同研发管理领域，走在市场前列的几家，都是良心之作。
以 PingCode 为例，在2021年入选36氪企服点评-软件项目管理榜前三，今年百度指数已经和一些近十年的老产品一致，这是用户使用和搜索行为决定的。在产品体验、完善度和商业化几方面，我们和几家产品都在引领研发管理这个细分赛道。
这是真心话，没有偏颇。言归正传，既然被邀请来答，就要诚意满满的回答好这个问题，这里我们不涉及其他友商，只谈谈我们自己在产品上的想法和规划，欢迎大家在评论区讨论、建议。
PingCode 作为国内首款主打智简研发理念的研发管理产品，在与 Worktile 品牌拆分后的3年多时间里，我们迭代与升级累计发布480个版本，上线7款子产品（第8款子产品即将上线）。
PingCode形成了涵盖项目管理 Project 、测试管理 Testhub、知识管理 Wiki、效能度量 Insight 、目标管理 Goals 等场景在内的 All-in-One 研发管理工具。
本篇文章，我们会重点来聊聊 PingCode 产品设计的底层逻辑。
在企业数字化转型的时代，研发管理能力已经成为一家公司的核心竞争力，研发管理本身又是一个长链条的管理过程，包括管理侧的需求价值流和工程侧的研发工作流，其中涉及到大量的方法论和工具。
这就要求我们的产品从设计上需要考虑使得每个团队都能够快速的消除成员之间的隔阂，确保每个人都能够连接起来并访问需要的信息，为专注于业务价值而提供高效的决策。
PingCode在产品设计上首先采用的是分层式设计体系，分为应用层、产品层、平台层：
在研发管理过程中，我们需要关注的其实是两条流：管理侧的需求价值流和工程侧的研发工作流。我们的研发管理工具，其最终的价值在于让这两条流之间实现联动，自动完成状态的流转和信息的同步。
PingCode 在产品层的设计上第一个特点是采用矩阵化的设计，每个子产品作为一个相对独立的模块，单独的解决某一方面的业务场景；
同时各个子产品之间又会相互关联，比如用户故事和测试用例、执行用例和缺陷、知识库的页面和工作项，工作项与目标之间都会互相关联，在一个平台之上实现数据的统一和协作的高效。
每个团队所面对的业务流程不同，采用的整个研发管理流程也不尽相同，矩阵化的产品设计可以保证每个团队只根据实际业务场景的需要，购买不同的子产品以保持开箱即用的产品使用体验。
PingCode 在产品层的设计上第二个特点是基于 Streamlines 的协同，要解决管理侧的需求价值流和工程侧的研发工作流之间联动，通常有两种解决方案：
基于单点产品和 Streamlines 的协同解决方案。
目前 PingCode 已经发布的产品包括了管理侧的每个业务环节，从团队目标开始，到产品路线图，收集用户的反馈以及进入到研发的迭代阶段最终通过测试发布上线。
工程侧的研发工作流通过无缝集成第三方工具，使得管理侧和工程侧产生的数据，都集中在一个统一的数据模型平台之上，实现两条流之间的联动及自动完成状态的流转和信息的同步。
PingCode 平台层的设计，使得所有的子产品、应用市场的应用以及第三方服务集成应用，都能够构建在一个统一数据模型的平台之上， 而在这个统一平台的背后有四个核心的技术支撑：自动化、数据洞察、协作和可扩展，我们称之为 AICE 模型。
基于AICE 模型的平台层是整个 PingCode 产品设计的基础，在此之上构建的各个子产品，以及连接的各种研发场景的应用，都会基于 AICE 去实现。
构建在平台层中的自动化引擎为整个 PingCode 产品线的自动化实现提供支撑，帮助用户专注于那些创造性的工作，频繁且复杂的手工性的操作交由自动化引擎实现，并且在自动化引擎之上开发了自动化工作流产品 Flow。
在 Flow 中用户可以通过以下3个概念随意组合他们想要的自动化工作流，如有这样一个工作流“当用户在 GitHub 上提交代码时，判断对应的工作项状态是否为完成状态，改变工作项的状态，发送通知给相关人员”：
整个自动化工作流的工作原理可以用如下表达式表示：
Flow 中创建自动执行重复性任务的工作流可以有多种选择，针对不同的自动化业务场景，选择不同的工作流流类型，目前 Flow 支持三种工作流：
为了方便用户更快的开始自动化工作，PingCode 内置了大量的自动化流模板，通过这些模板可以快速创建一个工作流并应用于团队中。
在今天的软件开发领域，研发效能是一个不可忽视的话题，从互联网大厂道中小腰部企业，都在重视研发效能的提升。
大厂们希望通过研发效能实现持续的研发能力提升以应对日益复杂的产品开发，中小腰部企业也希望通过研发效能实现弯道超车，充分发挥后来者居上的优势。
PingCode 在平台层面上已经充分考虑了研发效能的问题，保证用户在使用 PingCode 产品中产生的数据，以及使用第三方研发产品产生的数据，通过平台的 BI 引擎进行清洗加工，提炼出有价值的信息，进而为用户的业务决策提供依据。
在设计研发效能度量体系时，我们着重从如下几个方面来考察：
在平台层设计好研发度量的指标体系，以及提供数据度量分析的能力之后，只能算是在研发效能领域万里长征走完第一步，接下来还需要在产品层面提供如何展示报表，最终形成完整的研发效能度量体系。
因为研发效能度量的过程不仅仅只是一个数据报表的展示过程，而实际上我们要做的是把数据转化为信息，然后将信息转化为知识，这样才可以让用户进行分析和洞察。
下图为我们研发效能度量产品 PingCode Insight：
PingCode 平台中提供的协作技术，为上层的产品中实现团队成员之间高效协作提供支持，让团队成员能够步调一致的进行工作。
在 PingCode Wiki中，当多人同时编辑同一个页面时，可以看到当前页面有哪些协作者参与以及每个协作者正在操作的位置，实时同步每个协作者输入的内容，以便高效的进行协作。
协作性的体现不仅仅在于团队内部成员之间要高效协作，与团队外部相关利益方的协作也至关重要，在整个研发研发链条上，不应该只有内部的产研角色，外部客户、合作方也是整个链条上非常重要的环节。
PingCode 在平台层设计用户体系时充分考虑了这种场景，用户可以分为两大类：
如下图为内测中的unlicensed用户访问外部的工单Portal，不用进入系统即可与团队内部成员进行沟通：
PingCode 在底层设计上就充分考虑了未来产品的扩展能力，可以非常方便的扩展产品功能，以及接入第三方产品的能力，让团队能够专注于快速的解决业务问题。
目前 PingCode 应用市场中已经有20多款应用，这些应用大体可以分为三类：
未来还会考虑开放整个应用市场的开发能力，提供相应的Sandbox模型以及Toolkit帮助用户更加轻松地在应用市场中开发自己的应用。
用户还可以通过 PingCode REST API 对当前团队中正在使用的其他研发工具进行接入，实现 PingCode 和其他产品的数据互通，包括开发、构建、发布等数据。
这些过程数据在与 PingCode 进行接入后，不仅可以使得过程数据与 PingCode 中的工作项连接起来，更好的协同一致的工作，同时这些数据还可以作为研发效能度量的数据来源，以提供更有洞察力的研发效能指标。
可扩展性作为一个贯穿于 PingCode 所有产品的能力，除了通过应用市场和 REST API 能够对 PingCode 进行扩展之外，在每个单点子产品上同样也具有扩展能力。
如在自动化产品 Flow 中，除了内置的系统连接器以及一些产品连接器外，还可以通过基于 HTTP Webhook 作为触发器/动作，这样也可以通过 HTTP 的方式连接起 PingCode 和其他研发工具。
以上就是关于现阶段PingCode的一些介绍，以及未来的一些想法。欢迎所有对协作有想法、有需求、有心得的交流提交给我们。
国内企业级市场，充满了巨大的机会和挑战，我们更愿意将时间和心力投入到用户的反馈和建议，接地气的理解协作场景的种种需求，与其将口水浪费在嘴仗、抹黑竞品、将费用投入给百度，不如踏实做好每个用户在乎的细节。
