导读

“组织结构混乱”、“团队协作不透明”、“项目交付不及时”、“人员流动性大”……

创业公司成长迅速，业务蓬勃发展，团队不断扩张。这本是令人高兴的事情，却会给团队和项目管理带来不小的挑战。无论你是什么岗位，肯定都有属于你的小烦恼。

本期「TAPD经验谈」pick了创业公司中的敏捷研发管理老司机，有着十年项目管理经验的老司机，某金融科技公司原项目总监 莫敏 ，来给大家介绍他们团队实战过程中的填坑经验。

我叫莫敏，之前是某金融科技公司的项目总监，也是PMO负责人。

从BAT某大厂刚到这家公司时，我曾信心满满，觉得让我大展身手的机会终于来了，毕竟我的项目管理经验也还算丰富，帮新公司提升研发的效率和质量，简直是小case嘛~

却没想到，在创业公司做项目管理，就是一个不断打怪升级的过程，总是会面临接踵而来的挑战，其中也不乏一些难搞的大boss。

 公司进了个BAT出身的COO 

这家公司的研发团队最初是矩阵型组织架构，北京、上海和深圳都有研发部门，分别负责保险、金融和支付三个方面的开发工作，研发管理相互独立。

2016年底，公司引进了一位从BAT大厂来的COO，考虑到当前公司主要问题是欲望大于能力、战线铺得太开，而且资源也在各部门出现不同程度的浪费，业务和资源收缩势在必行。

COO决定使用职能化的组织架构解决这个问题，当然也包括了研发部的调整。

在历时三个月的组织调整后，200多人规模的研发部被调整为两大主线：业务线、基础线，业务线支撑公司业务，包括支付、地推系统和餐饮系统；基础线提供基础研发支撑，包括前端、测试、运维、中间件等。

因为这样一次组织架构的调整，新的问题开始暴露出来：

每个业务线的开发习惯和工具都不统一。

就像一个军团，大家用不一样的枪和弹匣，操练不一样的步伐，你要是调到我的团队，拿了我的配枪都不会用，相互配合起来就特别麻烦。

我想第一步先把大家的规范、流程、工具进行统一，但是业务线项目属于棕地项目（棕地项目，指好几年的老项目），原来的研发的习惯已经养成，要重新适应新的模式会比较困难。

这是我第一次觉得事情没那么简单，那段时间，我愁得掉了不少头发。

 小试牛刀:小范围推行协作工具

思来想去，我觉得凡事只要踏出第一步，就会好起来，那么我的第一步应该选择哪个项目呢？

就在我思考这个问题的时候，对敏捷和工具饶有兴趣的小邓同学（Web前端组组长）找到我，说：

“莫老师，你有什么比较好的项目管理工具推荐吗？”

“你先说说，你要解决什么问题？”我饶有兴趣地进行反问。

“我先说说我现在用的工具吧。”小邓同学继续说下去。

“JIRA工具不太好用，不好理解，为什么每次创建都是创建问题，再在里面选任务还是缺陷？”讲到这里，小邓同学有点沮丧。

“你再讲讲你的痛点吧”我继续问道。

“&……%&%&%*&%……%%”小邓同学倒豆子一样把问题说了一大堆。

哈哈，得来全不费功夫。

初步了解一下小邓同学的需求，他希望解决Web前端组面临三大方面的管理问题：

1）缺少一套直观管理工作过程的工具；

2）各项管理制度与流程上的空白；

3）缺乏人员的专业化分工与团队化管理，导致长期松散的“作坊”式结构。

第1项表现得尤为突出，因为眼前的日常工作要持续稳定地开展，长远的建设类工作也需要步步为营地推进。公司突如其来的革新，给小组及受命上任的管理者都带来了很大的挑战。

很长一段时间以来，Web前端组在计划、任务、执行无法得到清晰透明的体现，沟通/协作上也是极其原始低效的方式。要维持工作的有序开展，总是异常艰辛。

一套行之有效的研发过程管理协作工具，已显得迫在眉急、刻不容缓。然而尝试过各类工具/平台都不甚理想，总有一种“缺胳膊少腿“的感觉。

难怪小邓同学那段时间总是愁眉苦脸的。

经过研究，我对Web前端组采用了培训、工具导入、敏捷反馈、持续改进、逐级扩展 的方式，推行TAPD。

一开始用轻量化的前期使用【看板】功能，以月为单位对小组日常工作进行工作任务发布、检查项细化、成员关联、截止日期确定，文件关联，过程跟踪等，以评论进行过程沟通。

持续跟进使用28天之后，团队的习惯已经养成，每个人都会及时去流转自己的工作，团队使用热情高涨。

随着团队规模扩大以及对敏捷知识的了解，项目需要用更复杂的方式进行管理，我们尝试使用了【需求】【任务】，根据小组的特性进行了需求分组，使各种需求与任务有了归类，查看起来更直观。

同时导入了一些敏捷管理的专业知识，利用【甘特图】对资源与事项进展开启了全览视角，可视化使得团队Leader能做到更细致的把控与准确的决策。

后期把【wiki】与【文档】与使用了起来，并且跟各项功能进行关联使用。协作效率得到了质的改变。

几个月后，小邓同学向我反馈：使用以来感觉TAPD各项功能设计有着量身定制般的贴合，之前的困扰均能一一化解。它不光是一套工具能解决了现实问题，同时还能带来在协作/敏捷管理上的专业知识，从而提升专业度。

登堂入室：制定研发管理流程 

在成功地帮助Web小组导入TAPD之后，我信心倍增，我决定把敏捷项目管理流程和TAPD辐射到更多的团队。

前面提到过的团队痛点：公司一开始也没有固化的项目管理制度与流程，每个团队都用其特有的项目管理方法、流程与工具在做事。

地推系统研发团队使用看板，小伍的团队使用JIRA和WIKI，而测试同学则使用禅道。项目管理水平大部分取决于Leader的个人能力。

所以开发团队会出现一个有趣的现象，开发同学早上在白板旁边开晨会，之后在WIKI里面看产品需求进行开发，然后打开禅道进行缺陷跟进并修复。

 “我的整个人都不好了。”开发同学说。

 “需求能否有个统一的地方安置，我团队的需求我都不好管理。”产品同学说。

“工具能不能别整这个多，切换来切换去，太麻烦了。”测试同学如是说。

在分析了这些痛点之后，我开始针对这些问题做下如下措施：

1)   敏捷与TAPD培训 

实施了敏捷项目管理培训与TAPD使用培训，覆盖了所有产品、研发和运营等相关人员。

2)   制定研发管理流程 

为了使研发部流程清晰、统一、有法可依，我制定了需求工作流，并在TAPD上将自定义流程配置出来，各个环节按照流程自运转。

产品需求管理流程

需求管理流程主要活动

 1   需求内审

1）需求收集：产品组获取用户需求之后，产品经理与需求提出方进行深入沟通，进一步识别需求，明确需求范围。

2）需求初稿：产品经验内部进行头脑风暴，出交互图，需求细节，定出需求初稿。

3）需求池管理：把需求初稿放入TAPD的需求池，对需求池的需求进行分类，并确定优先级。

P.S.优先级一定是按照业务的运营目标进行排序，保证业务价值最高的需求始终最优先被完成。

 2   需求预审

在TAPD里面对需求进行备注说明，对有疑问的地方提前沟通。提高需求会议的效率，带着问题来做需求澄清。

 3   需求评审

1）召开评审会议：产品经理负责召集所有分析和执行相关干系人参会。

产品阐述需求：产品经理阐述本版本的目标及需求，同时需要估评好此需求的业务价值，其他人员对需求提问。

研发PK需求：始终关注需求业务价值，保证业务价值高的需求排在最优先完成。

分配负责人：会上研发定出针对此需求的研发负责人，如果没有明确负责人，需要挂给研发Leader，会后由他进行分配。

需求定稿：会后产品经理修复需求的问题，邮件发各方进行确认，最终形成需求定稿。

2）模块设计图：研发需要对需求进行简单设计，输出模块设计图。

3）评估工作量：研发与测试分别评估工作量，最终汇总给产品经理，形成项目计划。

4）编写测试用例：测试会后开始编写测试用例。

 4   需求实现

1） 需求实现：需求按照项目计划进行研发，研发Leader把握研发进展，解决技术风险和问题。产品经理关注需求完成的输出点，和最后时间完成点，关注关键路径上的研发过程会导致延期的风险。

2）产品体验：产品经理关注在联调之后的可输出物，在此时间点邀请产品提出方进行产品体验，并整理体验问题，放在TAPD的评论中，推动研发修改体验问题。

3）转测试申请：体验问题修改完成之后，由研发提出转测试申请。

4）版本测试：测试人员开始进行测试，提BUG放在TAPD的【缺陷】模块中跟进，研发进行修复。测试完成在TAPD的【报表】输出测试报告，发文告知此次版本测试是否通过。

 5   需求发布

1）申请上线：产品收到测试报告之后，需要进行验收，根据TAPD输出的【报表】-【验收报告】当中，写明验收的结果，判断这次是否可以申请上线。

2）运维上线：如果可以上线，发起上线流程。上线步骤由测试提供，提交运维操作。

3）灰度发布：根据实际时间进行灰度发布。

4）收集反馈：上线后产品研发测试至少观察三小时数据变化和外部反馈。

 6   需求基线

1）基线管理：产品经理提交所有输出物到指定存放点，并知会配置管理员对其进行基线化操作，配置管理员对所有阶段纳入基线的工作产品进行审计，形成基线管理。

2）项目回顾：项目经理作为流程的执行者，严格遵循此流程进行项目工作推进，每次项目总结的时候，项目组成员都通过回顾过程的方式，来回顾流程当中执行地不到位的地方，持续改进。

因为是集体决议，所以项目组成员都认同并遵守此流程。

有了这些流程之后，大家步伐也一致了，使用了一样的枪支，怎么也像一支统一军纪的正规军了。

自从流程管理在研发部实行之后，我也收到了很多反馈。

改善最明显的前端和测试团队的Leader和我反馈说，他们能够更好地分析资源投入项目当中，原因有二：

1)   每个人团队使用的工具是一致的，人员调用再不需要重新适应新的团队运作模式和工具。

2)   TAPD的成员任务分配能可视化出来每个人的团队投入情况，到项目结束点就可以及时释放出来，资源利用率大大增强。

得到好评的我原以为，自此便可以高枕无忧，顺利走上人生巅峰。

然而，万万没想到，正如约束理论（Theory of Constraints，TOC）所说，解决一个瓶颈，还会出现新的瓶颈，后来陆续又有其他问题浮出水面，这一路似乎非要历经九九八十一难才能取得真经。

唉，说多了都是泪，我得打起精神，继续练功升级去了……

想开始高效协作，请前往TAPD官网（https://www.tapd.cn）