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

【引言】

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

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

获得关键输出物后，本文是以正向设计的逻辑进行描述，还原从需求到原型的设计过程。本文按分析粒度大小，分为三部分：第一部分是系统全局分析，分析粒度保持在模块管理，目的是获得系统的全局认识；第二部分是系统详细分析，分析粒度变小，保持在增删改查功能的粒度，目的是获得全部系统用例；第三部分是熟悉的系统原型设计，分析粒度变小，保持在页面和元件交互，目的是获得可交付的原型和标注。

（一）系统全局分析

系统全局分析，分析粒度保持在模块管理，目的是获得系统的全局认识。第一节是从业务的角度获取需求和用例，第二节是从系统的角度获取需求和用例，我称这个粒度为一级用例，第三节和第四节是在前两节的用例基础上分析主流程和对象。

1.1、业务用例

在软件项目里，业务范围和系统范围是不同的。业务范围指这个项目所涉及的所有客户业务系统功能清单，这些业务有没有计算机系统参与都是客观存在的。系统范围是指软件将要实现的那些对应于业务功能的系统功能，从功能性需求来说系统范围是业务范围的一个子集，但是一些系统功能则会超出业务范围，例如操作日志，有没有操作日志并不影响业务目标的达成，客户也不一定会提出这个要求，但从系统角度出发，操作日志会使得系统更加健壮。——来自《大象 in UML》

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

获取业务用例需要分析出业务主角和用例，业务主角即参与到业务流程中的角色，例如项目经理、产品经理等。用例即业务主角需要在业务流程中完成的事情，这里需要注意用例的粒度，我经过思考系统功能清单，系统全局分析阶段，建议使用管理一类事物的粒度，例如需求管理，这个粒度仅供参考。

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

某一天，领导分配给项目经理一个新项目，于是，项目经理召集产品组长、设计组长、开发组长、测试组长简单同步一下项目信息，表示要启动该项目。会后项目经理创建一个群聊，把项目成员拉到群聊中，同步项目信息。

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

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

测试工程师在测试的过程中会提出bug单，交由开发工程师进行修复。

项目经理对每个迭代负责，在迭代过程中，每天组织晨会，使用需求看板同步进度。在进度方面，项目经理会查看需求报表和bug报表跟进进度，并且每周会整理项目报告向上级汇报。最后保证迭代需求全部完成，即可结束本次迭代，然后开启下一次迭代。

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

图1 业务用例

1.2、系统用例

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

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

开始获取系统用例，我站在系统的角度，从三个方向分析系统需求，①系统管理的需求，②系统易用性的需求，③系统扩展性的需求。于是我列出了以下场景的需求：

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

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

图2 系统用例

1.3、主流程分析

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

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

图3 主流程

1.4、对象分析

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

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

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

将以上对象，按照相关性进行分类，并简单梳理对象之间的关系，即一对一、一对多、多对多。此处的对象关系图主要用于了解系统全局，所以对象之间关系和图例没有很标准，如图4。

图4 对象图

（二）系统详细分析

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

2.1、用例流程分析

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

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

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

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

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

4、管理需求流程，如图6。

图6 管理需求流程

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

6、报表流程，如图7左二。

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

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

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

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

10、仪表盘流程如图8左二。

11、文档流程，如图8左三。

12、消息流程，如图8左四。

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

2.2、二级用例

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

现在获取的用例粒度，保持在主要对象的增删改查即可。获取二级用例从两个角度分析。一是从上述的流程中进行提取用例；二是专注分析的对象，然后围绕该对象设想一些场景以获得需求，例如删除、导出、打印、批量处理等在流程中找不到的需求。开始获取二级用例。

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

图9 管理公司二级用例

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

图10 管理项目二级用例

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

图11 用户办公二级用例

2.3、补充对象

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

TAPD提供的是SaaS服务，使用一套系统服务所有客户，就需要提供强大的配置化功能，以满足不同客户的个性化需求。从之前获取到的对象进行分析，聚焦每个对象的场景，得到以下对象有强烈的可配置化需求，并提取补充对象，如图12。

图12 补充对象

2.4、三级用例

得到补充对象后，就继续分析以上对象的用例，这样就完成该粒度层次的分析。三级用例粒度是补充对象的增查改删，例如创建项目模板，是创建补充对象供上级对象调用，达到配置的目标。该粒度的用例比较有规律，大概有创建、查询、编辑、 删除、复制、排序、启用、默认等功能。如图13，列出了补充对象的用例。

图13 补充对象的三级用例

（三）系统原型设计

系统原型设计，分析粒度变小，保持在页面和元件交互，目的是获得可交付的原型和标注。在原型设计前，需要梳理功能清单，一来可以展示系统的全貌，二来可以了解工作量和分配各模块的执行人。

3.1、功能清单

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

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

3.1.1、导航设计

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

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

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

图14 导航菜单

3.1.2、功能清单

在导航菜单的框架下，按模块填充二级用例和三级用例。例如需求管理的常规功能（二级用例）放在需求模块中，而需求的配置功能（三级用例）放在项目设置的需求设置中，如图15。完整功能清单写在腾讯文档，请访问。

图15 功能清单

3.2、原型设计

不知道各位是否有这样的困扰，在原型设计时会有这样的卡顿，例如查询列表页要展示什么字段，创建页要展示什么字段，就有被打断的感觉。因此建议在开始原型设计之前，先根据对象的场景，分析对象的属性。我个人习惯是先分析对象属性再画详细的原型，这样是比较顺畅的。

3.2.1、对象属性

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

1、基础信息

2、人员相关属性：创建人、处理人、开发人员、抄送人。

3、时间相关属性：创建时间、预计开始时间、预计结束时间、最后修改时间、完成时间。

可以看出，属性很多，靠自己想是行不通的，这也是分析行业系统的价值，把行业系统常用的对象和属性学来，也就入门这项业务了。其他主要对象的属性写在腾讯文档，请访问。

3.2.2、原型设计

最后进行原型设计，并进行文字标注，补充业务规则和交互规则等。做PC web网页设计时，这里推荐 UI组件，记住常用的组件，会提高写标注的效率。为了体会TAPD的规则和交互，我也简单还原了TAPD的标注，原型放在蓝湖，请访问。

【尾巴】

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

感谢阅读，如果觉得有所收获，请帮忙转发给更多朋友，或者点赞和收藏，哈哈，谢谢。

以上为用户投稿陆作网整理发布，希望对大家有所帮助！

• 上一篇： 工程项目管理系统
• 下一篇： 云erp转型启示录（13家云ERP谁能扛起用户大旗）