PingCode产品底层逻辑具体是什么样的

草帽路飞UU

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


　　分层设计体系

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

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

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

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

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

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



1.产品层设计

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

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

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

　　1.1业务场景矩阵化

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

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




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



1.2基于Streamlines的协同

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

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

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

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

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

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



2.平台层设计

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

察、协作和可扩展，我们称之为AICE模型。




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

　　2.1Automation自动化

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

工作流产品Flow。

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

关人员”：

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

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

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

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




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

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

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

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

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



2.2Insights数据洞察

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

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

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

而为用户的业务决策提供依据。

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

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

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

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




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

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

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



2.3Collaboration协作

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

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




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

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

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

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

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



3.4Extensibility可扩展

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

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

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

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

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

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




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

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

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

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

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

效能指标。




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

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



4.总结

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

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

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

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