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

12 评论 1.4万 浏览 70 收藏 33 分钟

编辑导语:腾讯TAPD,即腾讯敏捷产品研发,是常用的项目管理工具。那么,具体到设计层面,我们可以如何认知这款工具?本篇文章里,作者从系统全局、详细分析、原型设计三方面对腾讯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,后文也会沿用缺陷这个词。

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

图1 业务用例

2. 系统用例

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

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

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

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

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

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

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

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

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

图2 系统用例

3. 主流程分析

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

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

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

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

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

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

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

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

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

图3 主流程

4. 对象分析

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

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

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

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

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

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

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

图4 对象图

二、系统详细分析

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

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

1. 用例流程分析

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

1)管理公司流程,如图5左一

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

2)管理项目流程,如图5左二

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

3)管理迭代流程,如图5左三

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

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

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

4)管理需求流程,如图6

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

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

图6 管理需求流程

5)管理缺陷流程,如图7左一

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

6)报表流程,如图7左二

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

7)需求看板流程,如图7左三

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

8)项目报告流程,如图7左四

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

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

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

9)工作台流程,如图8左一

用户:①查看待办项,②查看已办项。

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

用户:①编辑仪表盘内容,②编辑仪表盘布局。

11)文档流程,如图8左三

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

12)消息流程,如图8左四

  • 系统:①触发发送消息;
  • 用户:②查看消息。

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

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

2. 二级用例

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

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

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

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

开始获取二级用例。

1)管理公司二级用例,如图9

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

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

图9 管理公司二级用例

2)管理项目二级用例,如图10

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

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

图10 管理项目二级用例

3)用户办公二级用例,如图11

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

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

图11 用户办公二级用例

3. 补充对象

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

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

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

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

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

图12 补充对象

4. 三级用例

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

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

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

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

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

图13 补充对象的三级用例

三、系统原型设计

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

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

1. 功能清单

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

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

1)导航设计

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

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

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

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

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

图14 导航菜单

2)功能清单

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

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

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

2. 原型设计

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

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

1)对象属性

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

① 基础信息

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

② 人员相关属性

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

③ 时间相关属性

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

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

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

2)原型设计

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

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

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

【尾巴】

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

感谢阅读。

 

本文由 @王世翔 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
1人打赏
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 想问下楼主几年经验?太强了,膜拜学习。。我刚好是做相关产品,自愧不如啊

    来自北京 回复
    1. 谢谢支持。稍微多干了几年,第七个年头了,还需加油,年轻的你早点有你自己的产品设计流程,就能追更高层次的知识。共勉!

      来自广东 回复
  2. 腾讯文档无法查看

    来自山东 回复
    1. 我在没登录腾讯文档的情况下,依然是可以打开腾讯文档里的内容的。

      来自广东 回复
  3. 看完您的文章,也去看下了下蓝湖地址分析的很完整,也很专业,UML的建模语言使用的也很灵活.个人觉得在框架、结构层的交互方面还是有空间的;组件的使用,产品交互模式的统一等.为什么这个项目没有配备交互设计师呢.

    来自广东 回复
    1. 不是很理解你的意思?腾讯的TAPD已经上线好几年了,应该是有交互设计师的吧。我只是用我的思路在分析它,学习它。

      来自广东 回复
  4. 对于我来说真是理清了整个产品设计的关键思路,感谢作者。

    来自四川 回复
    1. 开心,我也因此理清了思路。

      来自广东 回复
  5. 茅塞顿开

    来自重庆 回复
    1. 很开心能引起你的思考。

      来自广东 回复
  6. 写的好棒!把画原型之前的规划路线写的非常清楚!建议整篇背诵

    来自北京 回复
    1. 很开心得到你的认可。

      来自广东 回复