这篇文章算是对我在上家公司期间使用腾讯TAPD协作平台的一些经验总结，供对TAPD感兴趣的童鞋参考使用。

1 前言

在笔者之前的工作经历中，产研团队使用腾讯的TAPD平台进行协作，经过一段时间的磨合后，效果比较明显，流程日趋规范，迭代的节奏感也把控得很好。今年6月初换了新工作，发现新公司内部也在推广TAPD，故撰写了本文，供领导参考借鉴。

2 团队角色定义

产品：需求收集、定义，原型和PRD制作，版本规划，产品验收，培训等
研发：需求实现
测试：需求测试
运维：系统上线以及日常运维
运营：使用已实现的功能/系统进行业务推广、运营

3 整体协作流程

3.1 创建项目组

公司内部一般都是以项目组为单位，如某个系统/产品，或者某个营销活动。

负责的项目经理（有时候是产品经理兼任，或者是研发经理兼职）以项目组为单位创建一个TAPD项目。

如果是典型的产品研发项目，建议使用功能最全的“敏捷开发全生命周期”模板（企业版TAPD才有这个模板）。

默认情况下，公司申请注册开通TAPD账号后会发现，只能用专业版。如果要使用更为强大的企业版，需要深度使用TAPD半年后才能提出申请升级版本。如果贵司有腾讯前员工，则可以直接提出申请使用企业版。如果你认识腾讯的前员工，对方愿意帮你推荐，那么你也可以直接申请到企业版。这里要特别感谢前公司的某同事，因为他的前企鹅员工身份，我才得以快速帮现在的公司申请到企业版。

3.2 调整项目组成员权限

如果为了限制项目组成员内不同角色成员在本项目内的操作权限，可以考虑对他们进行权限调整。

如：产品经理只能维护需求，不能创建任务；研发只能在需求下创建任务，没有其他模块权限。
先自定义用户组，然后修改项目成员在本项目内的所属用户组。

3.3 需求池的维护

由于产品经理会从市场、渠道、运营、用户等收集到很多改进的意见建议，为了有效管理，一般会维护一个需求池。

在以往，常见的需求维护方式是，用一个Excel管理起来，放到共享盘给大家编辑和查看。这种方式弊端很多，如协作很不方便，无法灵活直观调整需求等。

在TAPD中，产品经理一般是直接在具体项目中的“需求”栏下维护需求池，以故事Story的形式直观呈现。

根据实际需要，可以对需求进行简单分类（放在不同的子目录下），方便管理。

需求池比较关键的是明确好每个需求的优先级。只有高优先级的需求，才会优先进入迭代版本。

如果需求较为复杂，建议使用父子需求的方式来拆分story。使对父子需求的好处是，可对一个大的复杂需求进行集中管理。

需求点的描述没有很严格的规范，产品经理可以根据实际情况而定来撰写。也可以参考以下模板：

• 需求来源
• 需求背景
• 需求描述

如果要统一模板，项目管理员可以在后台配置好本项目默认的需求创建页内容模板。

3.4 规划迭代

根据想要实现的阶段性目标，产品经理从本项目的需求池中，挑选出高优先级的需求点，创建一个TAPD迭代版本（注意，此时的迭代版本内容还没最终定下来，需要与研发讨论评审后才能最终确定要做的功能点）。

一个迭代版本的周期（含测试）一般控制在2~3周。太短的话做不了多少事情，太长的话，容易出现拖延的现象，团队成员没有紧张感。

版本的规划，一般遵循MVP原则，即最小可行化的原则。一个版本只需要包含能跑通核心业务流程的最少功能需求，其他的功能属于锦上添花，一律到第一个版本上线运行后再考虑迭代加上。典型的例子是：某些后台配置功能，可以先用脚本或者配置文件实现，后续再做成可视化的界面配置功能。

MVP的好处是用最少的资源投入、最短的时间来验证需求的可行性。

如果需求非常明确、确认可行、资源充足、上线时间不紧迫，则不必遵循过于严格的MVP，可以考虑把功能细节规划得详细一点。

3.5 需求评审

部分团队会有一个需求初审的环节，即，产品找研发leader或者研发的开发人员，小范围先过一遍需求，主要是可行性的问题。初审的好处？避免浪费大家的时间，尤其是研发和测试的时间，技术人员都不喜欢整天开会，如果需求本身不够完善、可行性有问题，则可以在小范围内做好拦截处理。

如果不是特别复杂、庞大的需求，也可以不用此环节，直接进入正式审批环节。

正式的需求评审环节，研发（含UI设计部门）和测试部门都得参加。

研发有权拒绝做某些需求，如果认为不合理的话。研发也可以要求将某些功能优先级降低，挪到下个版本来实现。

产品根据评审的反馈，对迭代版本做出适当的修改。

评审通过后，迭代版本即确认定稿。

3.6 研发排期和实现

研发部门根据需求的复杂度和现有资源情况，召集研发内部的讨论会（非必须，如不是很复杂的功能版本，也可以在需求评审会结束后当场就快速分配好任务）。

研发内部创建、分配和认领好任务（指定处理人）。

任务的处理人一般需要给出以下信息：

• 预估工时
• 预计开始
• 预计结束

研发leader要检查和协调研发成员的工时分配，避免出现衔接不上的问题。

注意：建议项目经理在 项目设置 > 其他设置 > 可选功能 中修改工时单位为“人日”。

研发leader根据总体的工时估算，给出此迭代版本研发完成的预计日期。

进入研发阶段后，一般不允许修改需求，不过减需求是允许的（只能减不能加）。如果是不涉及到主流程、核心功能实现的小改动，如改个简单的字段，改个图标，一般是允许的（实际上在研发过程中，这类变动也很常见）。特殊情形做特殊处理，只是一般建议需求发生较大改动时，放到下个版本实现，不要影响到当前的迭代版本。如果真的出现重大变动不得不做的，那就需要领导介入来决定。实际上，已经进入研发阶段，需求还出现重大变动，那就是产品经理的责任了。

日常情况下，研发在TAPD的个人工作台就可以看到自己的待办/任务。

研发根据实际情况更新需求/任务的进度，如修改其状态。

3.7 测试用例与测试环节

参加完需求评审会议后，需求已经定稿，则测试部门可以开始安排人员撰写测试用例。

一般来说，测试部门需要在研发实现功能之前完成测试用例准备。

根据研发部门给出的预计完成时间，测试部门需要给出具体的测试排期起始时间。正常来说，研发完成后，测试应该立即投入测试资源，不过也得看测试部门本身的资源安排。

如果使用的是企业版TAPD，则具备测试模块功能，测试人员可以直接在TAPD上记录测试用例、记录bug。

如果使用专业版的TAPD，则只能简单做Bug登记，没有较全的测试用例功能。

典型的TAPD测试管理流程可以参考：
1、编写测试用例，用例关联到需求点
2、创建测试计划，指定待测需求点，加载关联的用例
3、执行测试用例
4、如果用例未通过，则关联记录缺陷，并把缺陷流转给负责的研发
5、研发收到缺陷，修复后，更新缺陷状态并流转给测试进行确认
6、测试人员确认是否修复了缺陷

研发在提测之前，需要进行必要的自测，确保提测代码的质量。如果研发提测的版本有很多问题，如基本的流程都无法跑通，则测试可以直接打回测试申请，让研发修改完善后再次提测。

3.8 测试环境产品验收

测试部门完成所有测试后，产品经理介入，在测试环境进行一次验收，核对是否与原始需求一致。

如果不一致，则让测试提交bug给研发继续修改。如果验收通过，则测试部门发起上线申请。

3.9 上线

如果公司有专职的运维团队，上线一般都是测试发起、运维负责上线。

3.10生产环境产品验收

上线完成后，测试部门和产品经理都要介入，在生产环境验收一遍需求。

如果生产环境验收与预期不一致，则考虑紧急修复再上线一个修复版本，或者是小问题不影响核心业务流程跑通 ，可以放到下个版本一起修复改进。

如果较为紧急，但是又无法短时间内修复，则考虑将生产环境回滚到上一个版本。

3.11运营接收

通知运营部门接收上线的新功能。如有必要，产品经理需要对运营进行培训。

4 常见问题

4.1 上线时间节点问题

一个版本的实现，通常有如下预期的时间节点：

• 产品想要的上线日期
• 研发排期能够实现的日期
• 测试部门答应能够测完的日期

各方需要协商好大家能够接受的日期，安排好资源，并跟好进度。

4.2 资源问题

如果研发和测试能够明确估算出时间，则资源的占用是很清晰的。举个例子，在TAPD上，某个研发人员参与了多个项目，他为每个项目下的需求/任务都填写了预估的工时，则在TAPD上可以直观看出这个研发人员的资源利用率，研发leader可以很方便地知道这个人近期是否还有余力做其他项目，而不是凭感觉安排任务。

“估算工时”有时候是一个玄学问题，真枪实弹做过几个项目的人都知道。例如，研发人员有两种常见的倾向，一种是过于乐观（“这个东西不算太复杂，估计两三天可以弄完”），常见于新手，另一种是喜欢留很多缓冲时间的（“这个东西没那么简单的，估计一周吧，我得研究研究”），一般的老手都喜欢这么干。作为产品或者说项目负责人，如果不能较为准确把控整个项目的所需工时，那他也无法和上级汇报，管理好老板的预期（“说好的两周搞定，你们拖了一个月？”）。虽然敏捷理念里面有一些更高级的估算方法，如用“规模”、“故事点”来评估，不过从我经历过的团队和项目来看，这些都太高大上了，用“工时”还是大家相对能接受的估算方式。

4.3 例会问题

敏捷实践中，一般推崇每日例会，每天早上固定时间，各个部门/项目组限制在15分钟内开一个站立会议，每个人简短发言，总结：

1. 昨天完成了什么任务
2. 今天准备做什么任务
3. 遇到什么困难需要反馈

根据实际项目的体验，每天早会很难坚持，容易流于形式，普遍也有抵触心理。但是，改为一周两次早会，则大家相对不那么抵触（如周一和周四）。而且，加上一些小机制，如迟到的人发红包，可以让早会显得不那么呆板严肃。

早会的意义在于：

1. 发现问题：很多人有问题喜欢默默解决或者直接绕过去，不喜欢提出来讨论，等到隐藏不住了才提出来（如研发遇到技术难题），容易影响到项目进度。
2. 同步进度：项目组内每个人做的事情不一样，有可能会有依赖关系（如前端依赖后端提供接口），如果没有及时同步，会有信息滞后的问题，导致项目延迟

不管你信不信，职场上的问题，大部分都是沟通不善造成的。例如老板对员工预期太高，或者是项目成员捂着问题不上报项目经理。面对面的站会，是一种很好的沟通机制，定期反馈，及时发现问题，确保项目能如期完成。

对于紧急项目，在冲刺阶段，则建议每天必须举行早会，让大家有紧迫感。

早会经营得好的话，会形成一个仪式感，大家知道自己要做什么，目标是什么。

4.4 关于迭代的节奏

一般来说，产品经理的需求要提前一个版本准备好。即，当研发和测试在实现1.0.0时，产品经理需要开始准备1.0.1，当研发完成当前版本后，如果没有太多调试排bug的任务，则可以立即评审1.0.1。控制好迭代节奏后，就不会出现研发资源闲置的问题。

4.5 关于工时估算问题

研发和测试会分别给出自己预计的实现时间，研发leader和测试leader需要检查和监督成员的估算时间，避免有人预估比实际耗时所需多很多的时间。

4.6 需求对接问题

原则上需求都要经过评审（尤其是需要研发leader知晓），产品不能私下找研发直接增加或者大幅度修改需求。

研发只和产品对接，研发不接受业务部门直接提出的改动需求。

4.7 测试排期问题

根据笔者以往的经验来看，如果项目较为紧急，功能较为复杂，更需要注意给测试留出足够的时间，不然上线后会有很多问题。需求评审完成后，测试部门需要充分评估并给出自己的排期。

4.8 迭代的进度条问题

默认情况下，迭代的进度条是基于迭代内所有工作的关闭进度。

4.9 TAPD点击打开新页面问题

可能你也早就发现了，TAPD的大部分链接都是在新页面打开的，这会造成浏览器同时开十几个页面的壮观现象，榨干你的内存。。。如果你用谷歌浏览器的话，建议安装一个叫做Open Self Tab的扩展程序，限制TAPD系统内的链接只能在当前页面打开。