PingCode 产品怎么样？产品底层逻辑是什么样的？

Pingcode 作为国内首款主打智简研发理念的研发管理产品，经过 3 年时间的迭代与升级，累计发布 480 个版本，上线 7 款子产品（第 8 款子产品即将上线）。

PingCode 形成了涵盖项目管理 Project 、测试管理 Testhub、知识管理 Wiki、效能度量 Insight 、目标管理 Goals 等场景在内的 All-in-One 研发管理工具。

本篇文章，我们会重点来聊聊 PingCode 产品设计的底层逻辑。

分层设计体系

在企业数字化转型的时代，研发管理能力已经成为一家公司的核心竞争力，研发管理本身又是一个长链条的管理过程，包括管理侧的需求价值流和工程侧的研发工作流，其中涉及到大量的方法论和工具。

这就要求我们的产品从设计上需要考虑使得每个团队都能够快速的消除成员之间的隔阂，确保每个人都能够连接起来并访问需要的信息，为专注于业务价值而提供高效的决策。

Pingcode在产品设计上首先采用的是分层式设计体系，分为应用层、产品层、平台层：

1. 平台层：提供统一的数据模型平台，在此之上构建产品和连接应用

2. 产品层：提供矩阵式产品设计，方便团队进行灵活的构建以实现业务价值，同时每个子产品都采用统一的用户交互界面。

3. 应用层：开放式的接入整个研发工具链产品，实现数据的统一接入及能力的扩展

图 1 PingCode 平台化设计框架

1. 产品层设计

在研发管理过程中，我们需要关注的其实是两条流：管理侧的需求价值流和工程侧的研发工作流。我们的研发管理工具，其最终的价值在于让这两条流之间实现联动，自动完成状态的流转和信息的同步。

1. 管理侧的需求价值流：以需求特性为核心，贯穿需求、设计、开发、测试、发布等阶段。

2. 工程侧的研发工作流：以代码提交为线索，执行分支创建、代码提交、编译、扫描、测试、代码合并、部署、发布等活动。

1.1 业务场景矩阵化

PingCode 在产品层的设计上第一个特点是采用矩阵化的设计，每个子产品作为一个相对独立的模块，单独的解决某一方面的业务场景；

同时各个子产品之间又会相互关联，比如用户故事和测试用例、执行用例和缺陷、知识库的页面和工作项，工作项与目标之间都会互相关联，在一个平台之上实现数据的统一和协作的高效。

图 2 PingCode 基于矩阵化的产品设计

每个团队所面对的业务流程不同，采用的整个研发管理流程也不尽相同，矩阵化的产品设计可以保证每个团队只根据实际业务场景的需要，购买不同的子产品以保持开箱即用的产品使用体验。

图 3 按需购买产品

1.2 基于 Streamlines 的协同

PingCode 在产品层的设计上第二个特点是基于 Streamlines 的协同，要解决管理侧的需求价值流和工程侧的研发工作流之间联动，通常有两种解决方案：

基于单点产品和 Streamlines 的协同解决方案。

1. 基于单点产品的解决方案：团队中各个角色通常需要在不同的工具之间切换，各个工具之间的数据不能实现有效的流动。

2. 基于 Streamlines 的协同解决方案：团队中所有角色及利益方工作于统一的平台之上，每个环节产生的数据及有价值的信息都可以无缝的流动到下一个环节。

目前 PingCode 已经发布的产品包括了管理侧的每个业务环节，从团队目标开始，到产品路线图，收集用户的反馈以及进入到研发的迭代阶段最终通过测试发布上线。

工程侧的研发工作流通过无缝集成第三方工具，使得管理侧和工程侧产生的数据，都集中在一个统一的数据模型平台之上，实现两条流之间的联动及自动完成状态的流转和信息的同步。

图 4 基于 Streamlines 的协同价值流

2. 平台层设计

PingCode 平台层的设计，使得所有的子产品、应用市场的应用以及第三方服务集成应用，都能够构建在一个统一数据模型的平台之上， 而在这个统一平台的背后有四个核心的技术支撑：自动化、数据洞察、协作和可扩展，我们称之为 AICE 模型。

图 5 PingCode 平台层的 AICE 模型

基于 AICE 模型的平台层是整个 PingCode 产品设计的基础，在此之上构建的各个子产品，以及连接的各种研发场景的应用，都会基于 AICE 去实现。

2.1 Automation 自动化

构建在平台层中的自动化引擎为整个 PingCode 产品线的自动化实现提供支撑，帮助用户专注于那些创造性的工作，频繁且复杂的手工性的操作交由自动化引擎实现，并且在自动化引擎之上开发了自动化工作流产品 Flow。

在 Flow 中用户可以通过以下 3 个概念随意组合他们想要的自动化工作流，如有这样一个工作流“当用户在 GitHub 上提交代码时，判断对应的工作项状态是否为完成状态，改变工作项的状态，发送通知给相关人员”：

1. Trigger：触发器是指启动自动化工作流的一个事件。如当用户在 GitHub 上提交代码时就是这个工作流的触发器。

2. Action：动作是指在触发器时发生后执行的任务，每个流可以包含一个或多个动作，具体取决于完成特定流所需的操作。如改变工作项的状态、发送通知给相关人员等都属于动作。

3. Condition：条件指示工作流根据在流中设置的预定逻辑执行动作， 如果满足某些条件，则会完成一个或多个任务。如判断对应的工作项状态是否为完成状态。

整个自动化工作流的工作原理可以用如下表达式表示：

When ...(Trigger)... If ...(Condition)... Then ...(Action)...

图 6 PingCode Flow 业务场景示例

Flow 中创建自动执行重复性任务的工作流可以有多种选择，针对不同的自动化业务场景，选择不同的工作流流类型，目前 Flow 支持三种工作流：

1. 自动化流：通过特定事件触发的自动化工作流，如创建工作项、提交代码、发布评论等事件。

2. 计划流：通过预设的时间定期执行的工作流，如每日上报未解决的缺陷等。

3. 即时流：通过点击按钮运行的工作流，解决重复性的工作，如每次点击时给团队成员发送提醒等。

为了方便用户更快的开始自动化工作，PingCode 内置了大量的自动化流模板，通过这些模板可以快速创建一个工作流并应用于团队中。

图 7 PingCode Flow 内置自动化流模板

2.2 Insights 数据洞察

在今天的软件开发领域，研发效能是一个不可忽视的话题，从互联网大厂道中小腰部企业，都在重视研发效能的提升。

大厂们希望通过研发效能实现持续的研发能力提升以应对日益复杂的产品开发，中小腰部企业也希望通过研发效能实现弯道超车，充分发挥后来者居上的优势。

PingCode 在平台层面上已经充分考虑了研发效能的问题，保证用户在使用 PingCode 产品中产生的数据，以及使用第三方研发产品产生的数据，通过平台的 BI 引擎进行清洗加工，提炼出有价值的信息，进而为用户的业务决策提供依据。

在设计研发效能度量体系时，我们着重从如下几个方面来考察：

1. 交付效率：促进端到端、尽快的交付，用最短的时间顺畅地交付用户价值

2. 交付质量：促进端到端高质量交付，避免不必要的错误和返工

3. 交付能力：建设卓越的工程能力，实现持续交付

图 8 PingCode 研发效能度量体系设计

在平台层设计好研发度量的指标体系，以及提供数据度量分析的能力之后，只能算是在研发效能领域万里长征走完第一步，接下来还需要在产品层面提供如何展示报表，最终形成完整的研发效能度量体系。

因为研发效能度量的过程不仅仅只是一个数据报表的展示过程，而实际上我们要做的是把数据转化为信息，然后将信息转化为知识，这样才可以让用户进行分析和洞察。

下图为我们研发效能度量产品 PingCode Insight：

图 9 PingCode Insight 研发效能产品

2.3 Collaboration 协作

PingCode 平台中提供的协作技术，为上层的产品中实现团队成员之间高效协作提供支持，让团队成员能够步调一致的进行工作。

在 PingCode Wiki 中，当多人同时编辑同一个页面时，可以看到当前页面有哪些协作者参与以及每个协作者正在操作的位置，实时同步每个协作者输入的内容，以便高效的进行协作。

图 10 PingCode Wiki 多人协同编辑示例

协作性的体现不仅仅在于团队内部成员之间要高效协作，与团队外部相关利益方的协作也至关重要，在整个研发研发链条上，不应该只有内部的产研角色，外部客户、合作方也是整个链条上非常重要的环节。

PingCode 在平台层设计用户体系时充分考虑了这种场景，用户可以分为两大类：

1. licensed：团队内部用户，可以进入系统内部使用产品

2. unlicensed：外部客户或合作方，不用进入系统内部，通过提供的 Portal 功能与内部成员交互

如下图为内测中的 unlicensed 用户访问外部的工单 Portal，不用进入系统即可与团队内部成员进行沟通：

图 11 PingCode Ship 产品外部 Portal

3.1 Extensibility 可扩展

Pingcode 在底层设计上就充分考虑了未来产品的扩展能力，可以非常方便的扩展产品功能，以及接入第三方产品的能力，让团队能够专注于快速的解决业务问题。

目前 PingCode 应用市场中已经有 20 多款应用，这些应用大体可以分为三类：

1. 功能扩展：扩展现有产品的功能，使其能够适配团队的业务场景，如 Commit ID、提醒反馈等

2. 独立应用：作为可以独立使用的应用存在，解决某一个单点的业务场景，如待办、甘特图等

3. 第三方接入：作为 PingCode 和 开发生态链中其他产品的连接，使其能够更好的协同一致的工作，如 GitHub、Jenkins Plugin、GitLab 等

未来还会考虑开放整个应用市场的开发能力，提供相应的 Sandbox 模型以及 Toolkit 帮助用户更加轻松地在应用市场中开发自己的应用。

图 12 PingCode 应用市场

用户还可以通过 PingCode REST API 对当前团队中正在使用的其他研发工具进行接入，实现 PingCode 和其他产品的数据互通，包括开发、构建、发布等数据。

1. 开发 Development：发送代码托管平台中的数据到 PingCode

2. 构建 Build：发送构建记录到 PingCode

3. 发布 Release：发送环境和部署数据到 PingCode

这些过程数据在与 PingCode 进行接入后，不仅可以使得过程数据与 PingCode 中的工作项连接起来，更好的协同一致的工作，同时这些数据还可以作为研发效能度量的数据来源，以提供更有洞察力的研发效能指标。

图 13 PingCode REST API

可扩展性作为一个贯穿于 PingCode 所有产品的能力，除了通过应用市场和 REST API 能够对 PingCode 进行扩展之外，在每个单点子产品上同样也具有扩展能力。

如在自动化产品 Flow 中，除了内置的系统连接器以及一些产品连接器外，还可以通过基于 HTTP Webhook 作为触发器/动作，这样也可以通过 HTTP 的方式连接起 PingCode 和其他研发工具。

图 14 PingCode Flow 产品中 HTTP 连接器

4. 总结

本篇文章中我们从整体上探讨了 PingCode 的产品设计底层逻辑，分为平台层、产品层和应用层。

应用层通过应用市场和第三方集成接入，实现产品的能力扩展；

产品层采用矩阵化的设计以及基于 Streamlines 的协同设计，确保管理侧的需求价值流和工程侧的研发工作流之间的数据连接和信息同步，并提供统一的用户交互界面；

平台层提供了 AICE 模型：自动化 Automation、数据洞察 Insights、协作 Collaboration 和可扩展 Extensibility，以及统一数据模型，为平台层之上的产品层和应用层提供支撑。