腾讯TAPD：系统设计全流程解构

腾讯TAPD官方简介，TAPD 是Tencent Agile Product Development的缩写，即：腾讯敏捷产品研发。提供贯穿敏捷研发生命周期的一站式服务，覆盖从产品概念形成、产品规划、需求分析、项目规划和跟踪、质量测试到构建发布、用户反馈跟踪的产品研发全生命周期。

此次本着学习的态度解构腾讯TAPD（专业版），我是从TAPD的页面和功能入手，逆向分析得到关键输出物和原始需求，以此深入学习项目管理系统的业务。

获得关键输出物后，本文是以正向设计的逻辑进行描述，还原从需求到原型的设计过程。本文按分析粒度大小，分为三部分：

1. 系统全局分析，分析粒度保持在模块管理，目的是获得系统的全局认识；
2. 系统详细分析，分析粒度变小，保持在增删改查功能的粒度，目的是获得全部系统用例；
3. 熟悉的系统原型设计，分析粒度变小，保持在页面和元件交互，目的是获得可交付的原型和标注。

一、系统全局分析

系统全局分析，分析粒度保持在模块管理，目的是获得系统的全局认识。

第一节是从业务的角度获取需求和用例，第二节是从系统的角度获取需求和用例，我称这个粒度为一级用例，第三节和第四节是在前两节的用例基础上分析主流程和对象。

1. 业务用例

在软件项目里，业务范围和系统范围是不同的。

业务范围指这个项目所涉及的所有客户业务，这些业务有没有计算机系统参与都是客观存在的。

系统范围是指软件将要实现的那些对应于业务功能的系统功能，从功能性需求来说系统范围是业务范围的一个子集，但是一些系统功能则会超出业务范围，例如操作日志，有没有操作日志并不影响业务目标的达成，客户也不一定会提出这个要求，但从系统角度出发，操作日志会使得系统更加健壮。

——来自《大象Thinking in UML》

在引入计算机系统之前，业务也一直跑得很顺畅，因此在初始阶段，不引入系统的角度，纯粹站在业务的角度，分析业务的主流程场景，获取业务用例。

获取业务用例需要分析出业务主角和用例，业务主角即参与到业务流程中的角色，例如项目经理、产品经理等。

用例即业务主角需要在业务流程中完成的事情，这里需要注意用例的粒度。我经过思考，系统全局分析阶段，建议使用管理一类事物的粒度，例如需求管理，这个粒度仅供参考。

开始获取业务用例，以下是一段项目实施过程的场景。

某一天，领导分配给项目经理一个新项目，于是，项目经理召集产品组长、设计组长、开发组长、测试组长简单同步一下项目信息，表示要启动该项目。

会后项目经理创建一个群聊，把项目成员拉到群聊中，同步项目信息。

开工前，项目经理简单制定了计划：产品经理收集需求，产品组长评估需求的优先级，并规划成多个迭代实施，确定迭代范围后，产品组长、设计组长、开发组长、测试组长分别进行人员安排。

确定迭代的需求范围后，接下来就是需求的流转，产品经理完成需求设计，UI设计师完成UI设计，开发工程师完成编码，测试工程师完成需求测试，最后产品经理验证需求并关闭需求。

测试工程师在测试的过程中会提出bug单，交由开发工程师进行修复。项目经理对每个迭代负责，在迭代过程中，每天组织晨会，使用需求看板同步进度。

在进度方面，项目经理会查看需求报表和bug报表跟进进度，并且每周会整理项目报告向上级汇报。最后保证迭代需求全部完成，即可结束本次迭代，然后开启下一次迭代。

基于以上场景，获取业务主角和提炼一级用例，如图1。

• 项目经理是项目的启动者，由他管理项目；在项目实施中对每个迭代负责，由他管理迭代；定期在需求看板上同步进度，由他管理需求看板；定期查看报表了解迭代数据，他需要查看报表；定期整理项目报告进行汇报，他需要管理项目报告。
• 产品经理是需求的提出者，且会进行需求设计，由他管理需求。
• 设计师是需求的设计者，参与需求的UI设计工作，属于需求中的一个步骤。
• 开发工程师是需求的代码实现者，参与需求的代码编码工作；当系统出现bug的时候，他需要参与bug的修复工作。
• 测试工程师是需求的测试者，参与需求的测试工作；当测试出bug的时候，会提出bug单，由他管理bug。注：在TAPD中使用“缺陷”来表示bug，后文也会沿用缺陷这个词。

图1 业务用例

2. 系统用例

得到业务用例后，虽然能看到业务主流程的雏形，但要完成系统的闭环还需要站在系统的角度去补充用例，例如系统权限管理的需求，业务用例中并没有体现出来。

系统用例也是需要获得角色和用例，这个阶段的用例粒度和上一步骤的业务用例保持一致，即管理一类事物。

开始获取系统用例，我站在系统的角度，从三个方向分析系统需求

1. 系统管理的需求；
2. 系统易用性的需求；
3. 系统扩展性的需求。

于是我列出了以下场景的需求：

• TAPD是一款SaaS产品，会服务多家公司的客户，所以需要创建一家公司才可使用系统；
• 每个系统都需要考虑权限管理，所以管理员需要维护组织架构和系统用户组权限，才能够管理公司成员的权限；项目经理需要维护项目用户组权限，才能够管理项目成员的权限；
• 每个用户需要注册、登录、修改密码等个人中心的功能；
• 在工作中，需要处理的事情散落在各页面，用户可以有一个工作台，集中展示个人相关的待办项；
• 用户可能关注很多项内容，最好能在一个页面展示用户感兴趣的内容概览，减少切换，提供可自定义的仪表盘；
• 每个需求会关联需求文档，以及项目过程中需要文档的共享协作，提供集中展示文档的功能；
• 用户想及时得到迭代、需求、缺陷的更新消息，方便跟进，提供消息通知功能；
• TAPD服务多家公司，那么各家公司的需求会存在差异性，需要做到很强的可配置化来支持差异化需求。

根据上述场景的需求，获取到系统一级用例，和业务用例合并到一起，如图2。

• 系统管理员，需要创建公司才能使用该系统，由他管理公司；需要维护组织架构，由他管理部门；需要控制公司成员的权限，由他管理系统用户组；需要配置系统以实现差异化的功能，由他管理系统配置。
• 项目经理，每个项目的成员不同，也需要进行权限管理，由他管理项目用户组。
• 每个用户，为了提高系统的可用性和易用性，引入工作台、仪表盘、文档管理、消息通知、个人中心。

图2 系统用例

3. 主流程分析

主流程就是按某种逻辑把用例组合起来，验证是否可以实现业务目标。得到主流程可以对系统有全局的认知，也能辅助后续的对象分析。

经过分析，主流程有三个分支，如图3。

管理公司主流程，主要是创建公司并邀请成员加入公司：

1. 系统管理员在管理公司模块创建公司并邀请成员；
2. 用户在个人中心模块注册账号并接受公司邀请；
3. 系统管理员在管理部门模块创建部门并关联成员；
4. 系统管理员在管理系统用户组模块创建系统用户组并关联成员；
5. 系统管理员配置一些系统参数。

项目实施主流程，主要是创建项目并邀请成员加入项目，然后在项目中创建迭代、需求、缺陷，最终完成需求和修复缺陷：

1. 项目经理在管理项目模块中创建项目并邀请成员；
2. 项目经理在管理项目用户组模块中创建项目用户组并关联成员；
3. 项目经理创建迭代和规划迭代；
4. 项目成员在需求管理模块中创建需求和完成需求；
5. 项目成员在缺陷管理模块中创建缺陷和修复缺陷；
6. 项目经理查看需求看板和报表跟进迭代进度；
7. 项目经理定期发布项目报告。

用户日常办公主流程，主要是用户日常登录系统后处理自己相关的工作：

1. 用户在个人中心模块进行登录进入系统；
2. 在工作台查看待办项并进行处理；
3. 在仪表板查看概况；
4. 在文档管理中创建文档；
5. 在消息通知中查看需求、缺陷更新等消息。

图3 主流程

4. 对象分析

神盾局特工第四季里有一个概念是虚拟数字世界：框架（Framework），看过的朋友就很容易理解：软件系统就是在计算机世界模拟现实世界，现实世界中的物体会映射成计算机世界里的对象。

这里使用面向对象分析方法（OOA），也是《大象Thinking in UML》中的分析步骤之一，意图是将现实世界中的物体映射成计算机世界中的对象，在系统中使用这些对象去解决需求。比如分析对象需要哪些属性和功能来解决需求，在后续的步骤会详细分析这些对象。

获取到主要的对象，还可以帮助我们对系统有整体的认知。从以上的用例和主流程中进行抽象，获得以下对象：

• 管理公司主流程：公司、部门、系统用户组；
• 项目实施主流程：项目、项目用户组、迭代、需求白板、报表、项目报告、需求、缺陷；
• 用户办公主流程：用户、工作台、仪表盘、文档、消息。

将以上对象，按照相关性进行分类，并简单梳理对象之间的关系，即一对一、一对多、多对多。

此处的对象关系图主要用于了解系统全局，所以对象之间关系和图例没有很标准，如图4。

图4 对象图

二、系统详细分析

系统详细分析，分析粒度变小，保持在增删改查功能的粒度，目的是获得全部系统用例。

• 第一节，把系统全局分析里的用例进行细化，即用例流程分析，可以发现基本的二级用例；
• 第二节，搜集所有的二级用例，即在流程中体现的功能以外，再补充必要的其他二级用例；
• 第三节，为了满足高可配置化，还需要引入配置对象，例如项目模板；
• 第四节，我称为三级用例，主要是找到配置对象的用例，例如创建项目模板，以满足配置需求。

1. 用例流程分析

用例流程就是用例的实现方式，是常用的需求细化方法，即细化上述一级用例的粒度。流程分析的目的是可以从中发现下级用例，现在开始分析流程。

1）管理公司流程，如图5左一

• 系统管理员：①创建公司，②创建部门，③创建系统用户组，④系统配置，⑤邀请成员加入公司；
• 用户：⑥注册账号，⑦接受邀请加入公司。

2）管理项目流程，如图5左二

• 项目经理：①创建项目，②创建项目用户组，③邀请成员加入项目；
• 用户：④已是公司成员的用户可自动加入项目，⑤未加入公司的用户需要注册后接受邀请加入公司和项目。

3）管理迭代流程，如图5左三

项目经理：①创建迭代，②规划迭代，③跟进迭代进度，④完成迭代。

图5 管理公司、项目、迭代流程

4）管理需求流程，如图6

• 产品经理：①创建需求，②设计需求，⑧需求验收通过可关闭需求，否则回退给开发工程师；
• UI设计师：③UI设计，⑦设计验收通过流传给产品经理验收，否则回退给开发工程师；
• 开发工程师：④代码开发；
• 测试工程师：⑤测试，⑥测试通过流转给UI设计师验收，否则回退给开发工程师。

图6 管理需求流程

5）管理缺陷流程，如图7左一

• 测试工程师：①创建缺陷，③缺陷验收通过可关闭缺陷，否则回退给开发工程师；
• 开发工程师：②修复缺陷。

6）报表流程，如图7左二

项目经理：①查询项目、迭代中的需求和缺陷报表，②保存报表，③导出报表。

7）需求看板流程，如图7左三

项目经理：①查询迭代的需求白板，②移动需求状态。

8）项目报告流程，如图7左四

项目经理：①创建项目报告，②保存草稿，③发送项目报告。

图7 缺陷、报表、需求看板、项目报告流程

9）工作台流程，如图8左一

用户：①查看待办项，②查看已办项。

10）仪表盘流程如图8左二

用户：①编辑仪表盘内容，②编辑仪表盘布局。

11）文档流程，如图8左三

用户：①创建文档，②保存文档，③邀请协作者。

12）消息流程，如图8左四

• 系统：①触发发送消息；
• 用户：②查看消息。

图8 工作台、仪表盘、文档、消息流程

2. 二级用例

完成流程分析后，已经获得一部分细化的二级用例，但对于整个系统的闭环还是不够的，这节就补充完善二级用例。

现在获取的用例粒度，保持在主要对象的增删改查即可。

获取二级用例从两个角度分析。

一是从上述的流程中进行提取用例；二是专注分析的对象，然后围绕该对象设想一些场景以获得需求，例如删除、导出、打印、批量处理等在流程中找不到的需求。

开始获取二级用例。

1）管理公司二级用例，如图9

• 公司，补全增查改、注销公司，和关联成员的用例：邀请成员、查看成员、移除成员；
• 部门，补全增查改删，和关联成员的用例：成员加入部门、查看成员、成员移出部门；
• 系统用户组，补全增查改删、配置权限，和关联成员的用例：成员加入用户组、查看成员、成员移出用户组。

图9 管理公司二级用例

2）管理项目二级用例，如图10

• 项目，补全增查改、结束项目，和关联成员的用例：邀请成员、查看成员、移除成员；
• 项目用户组，补全增查改删、配置权限，和关联成员的用例：成员加入用户组、查看成员、成员移出用户组；
• 迭代，补全增查改、关闭迭代、规划迭代，和导出需求：导出迭代；
• 需求，补全增查改删，还需考虑需求的日常操作：移动需求、复制需求、关联父/子需求、关联迭代、流转需求、导出需求、导入需求、打印需求、分享需求、关注需求，以及批量操作需求：批量编辑需求、批量状态流转、批量移动、批量复制、批量删除、批量修改父需求、批量分享；
• 缺陷，补全增查改删，还需考虑缺陷的日常操作：移动缺陷、复制缺陷、关联迭代、关联需求、流转缺陷、导出缺陷、导入缺陷、打印缺陷、分享缺陷、关注缺陷，以及批量操作需求：批量编辑缺陷、批量状态流转、批量移动、批量复制、批量删除、批量分享；
• 需求白板，支持两种查看方式：查看迭代需求状态、查看人员的迭代需求状态；
• 报表，支持查看需求报表、查看缺陷报表、保存报表、导出报表；
• 项目报告，补全增查改删、保存草稿、复制项目报告。

图10 管理项目二级用例

3）用户办公二级用例，如图11

• 用户，支持用户的常规操作：注册、登录、退出登录、修改密码、找回密码、查看个人详情、编辑资料、注销账户，以及和公司的关联关系：接受公司邀请、退出公司、切换公司；
• 工作台，支持查询我的待办、查询我的已办、查询我创建的、查询我关注的、查询最近浏览的、全局查询；
• 仪表盘，可查看工作卡片、查看迭代概览卡片、查看需求卡片、查看缺陷卡片、查看报表卡片，以及配置卡片：添加卡片、编辑卡片布局、删除卡片、卡片内容设置
• 文档，补全增查改删，以及考虑文档的日常操作：发布到项目、邀请协作者、移动、复制、上传、下载、关注、分享，还有批量操作需求：批量删除、批量移动文件夹；
• 消息，支持自动触发并发送消息、消息提醒、查看消息、删除消息。

图11 用户办公二级用例

3. 补充对象

以上的二级用例，基本已经解决业务的需求，业务可以闭环流转了。但还需要考虑一些非功能性需求，例如系统的配置需求、安全需求等。

TAPD提供的是SaaS服务，使用一套系统服务所有客户，就需要提供强大的配置化功能，以满足不同客户的个性化需求。

从之前获取到的对象进行分析，聚焦每个对象的场景，得到以下对象有强烈的可配置化需求，并提取补充对象，如图12。

• 项目，①每个项目都有大量的配置内容，为了简化创建项目的设置工作，引入项目模板；②查询项目列表时，根据需要进行自定义可展示的字段，引入列表显示字段；
• 迭代，①创建迭代时，不同迭代类型的字段项可能不同，引入创建页模板；②在创建页模板中添加的字段需要维护，引入自定义字段；③查询迭代列表时，可以按条件快速过滤数据和自定义展示字段，引入列表视图；
• 需求，①创建需求时，不同需求类型的字段项可能不同，引入创建页模板；②在创建页模板中添加的字段需要维护，引入自定义字段；③不同需求类型的工作流可能不同，引入工作流；④工作流中的状态需要维护，引入状态；⑤创建需求时，将创建页模板和工作流组合在一起，引入需求类别；⑥查询需求列表时，可以按条件快速过滤数据和自定义展示字段，引入列表视图；
• 缺陷，①创建缺陷时，不同缺陷类型的字段项可能不同，引入创建页模板；②在创建页模板中添加的字段需要维护，引入自定义字段；③不同缺陷类型的工作流可能不同，引入工作流；④工作流中的状态需要维护，引入状态；⑤查询缺陷列表时，可以按条件快速过滤数据和自定义展示字段，引入列表视图；
• 项目报告，①创建项目报告时，需要展示的内容是有规律的，只是时间范围不同，为简化发布项目报告，引入项目报告模板；
• 仪表盘，①用户想自定义个性化的仪表盘，引入卡片；
• 消息，①配置消息的触发条件，引入消息事件。

图12 补充对象

4. 三级用例

得到补充对象后，就继续分析以上对象的用例，这样就完成该粒度层次的分析。

三级用例粒度是补充对象的增查改删，例如创建项目模板，是创建补充对象供上级对象调用，达到配置的目标。

该粒度的用例比较有规律，大概有创建、查询、编辑、 删除、复制、排序、启用、默认等功能。

如图13，列出了补充对象的用例。

图13 补充对象的三级用例

三、系统原型设计

系统原型设计，分析粒度变小，保持在页面和元件交互，目的是获得可交付的原型和标注。

在原型设计前，需要梳理功能清单，一来可以展示系统的全貌，二来可以了解工作量和分配各模块的执行人。

1. 功能清单

功能清单就是把系统内容和用例按某种展现逻辑组织起来，而这种展示逻辑就是导航设计，所以在列功能清单前先进行导航设计，然后把用例放置到相应的的导航菜单中，即可完成功能清单。

在完成功能清单后，即完成产品规划的部分，就可以按模块分配给多名产品经理，设计各个模块。

1）导航设计

参考三个主流程，管理公司、项目实施、用户日常办公。

可以发现，用户日常办公的功能使用频率最高，因此工作台、文档、消息、个人中心，放在一级导航的位置，仪表盘和工作台的性质比较相似，仪表盘合并到工作台菜单下，并且仪表盘是概览卡片的聚合页，可以充当登录系统后的首页。

在项目实施主流程中，迭代、需求、缺陷等都归属于某个项目下，所以项目是一级导航，流程中的其他模块，迭代、需求、缺陷、需求白板、报表、文档、设置就放在项目下的二级导航，还有一个项目报告，就合并到报表中。

公司管理也放置在一级导航中。如图14。

图14 导航菜单

2）功能清单

在导航菜单的框架下，按模块填充二级用例和三级用例。例如需求管理的常规功能（二级用例）放在需求模块中，而需求的配置功能（三级用例）放在项目设置的需求设置中，如图15。

完整功能清单写在腾讯文档，请访问https://docs.qq.com/sheet/DQXR1dndQY3B1c2Z4。

2. 原型设计

不知道各位是否有这样的困扰，在原型设计时会有这样的卡顿，例如查询列表页要展示什么字段、创建页要展示什么字段，就有被打断的感觉。

因此建议在开始原型设计之前，先根据对象的场景，分析对象的属性。我个人习惯是先分析对象属性再画详细的原型，这样是比较顺畅的。

1）对象属性

分析对象属性，并不是轻松的过程，每个属性都有针对的场景。这里用“需求”这个对象举例。

① 基础信息

• ID，需求的唯一标识；
• 标题，需求的标题，用于概括需求内容，方便查找；
• 描述，需求的详细描述，例如描述需求背景、解决方案等；
• 业务价值，指实现需求后的价值有多大，在规划迭代时优先实现业务价值高的；
• 优先级，指需求的优先级，在规划迭代时优先实现优先级高的需求；
• 规模，指需求的工作量，预测需要多少工时可以完成；
• 项目，需求所属哪个项目；
• 迭代，需求所属哪个迭代；
• 版本，需求所属哪个版本；
• 模块，需求所属哪个模块；
• 需求分类，用户可自定义需求分类，用于区分不同类型的需求，例如用户需求、代码优化需求；
• 需求类别，不同的需求类别的配置项不同，即需求创建页和工作流程不同，需求可以选择使用哪个需求类别的配置；
• 父需求，需求的父需求是哪个；
• 子需求，需求的子需求是哪些；
• 缺陷，需求下关联哪些缺陷；
• 状态，需求流转的状态，例如需求设计、开发、测试等状态；
• 评论，处理人可以在需求下进行评论留言；
• 附件，用于上传需求规格说明书。

② 人员相关属性

创建人、处理人、开发人员、抄送人。

③ 时间相关属性

创建时间、预计开始时间、预计结束时间、最后修改时间、完成时间。

可以看出，属性很多，靠自己想是行不通的，这也是分析行业系统的价值，把行业系统常用的对象和属性学来，也就入门这项业务了。

其他主要对象的属性写在腾讯文档，请访问https://docs.qq.com/sheet/DQUlqa2JnR2puWUZm。

2）原型设计

最后进行原型设计，并进行文字标注，补充业务规则和交互规则等。

做PC web网页设计时，这里推荐Element UI组件，记住常用的组件，会提高写标注的效率。

为了体会TAPD的规则和交互，我也简单还原了TAPD的标注，原型放在蓝湖，请访问https://lanhuapp.com/url/iXUNq。

【尾巴】

各位看官，由于是在现成的系统上进行分解推导，因此会存在一些上帝视角，有些用例和对象出现的逻辑没有那么顺畅，请大家见谅。另外，这些逻辑不顺畅的点，可能就是此类系统的行业知识，当你见过之后，也就认识和学习了这个行业的业务知识。

感谢阅读。

本文作者 @王世翔 

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！