前段时间一个 Github 项目把互联网公司的加班文化推上了风口浪尖，不可否认，最近这十年，国内互联网的发展速度赶上甚至超过了硅谷，为了加速发展，国内很多公司采用了“拼工时”的做法，天天加班，却忽略了最最应该关注的研发效能。

可以回想一下，你的团队是不是也面临着下面的问题？

1. 研发团队人不少，大家也很辛苦，但产品发布常常延期，上线后产品问题频发。

2. 开发提测质量不好，大量压力聚集到测试，导致代码返工率极高。

3. 开发人员疲于应付业务，没有精力或者兴趣去精进技术，工作效率低。

这其实就是团队的研发效能出现了问题。

你所处在的研发团队

这里我列举三种可以看见的研发团队

第一种：

项目从0到1，系统或产品都没有搭建完成，团队的开发资源都在这个项目周期中。开发到一半可能因为业务或领导的决定改变方向，最终花了几个月时间可能整个项目没有任何结果或只有半成品。

这样的研发方式：传统研发模式

第二种：

团队项目进入到1.0后的版本，项目团队以产品线为中心，将产品经理所匹配的前端、后台、安卓、IOS等为一小组。项目2周一版本，碰着大需求的时候就3周一版本。但一定要保证版本迭代的方式落地项目，而不是一次性几个月才上线一个完整的项目。

这样的研发方式：敏捷开发scrum

第三种：

团队项目有1.0之后的版本，也有从0到1的版本。因此团队以产品经理为中心，开发匹配在一起后，以1-4周的时间范围内为版本时间。另外0到1的项目呢，开发人员all in在这个这里，导致没办法继续做迭代的工作。

这个第三种有点像第一和第二种的结合

这样的研发方式：四不像

你是哪一种？

如何提升团队研发效能

互联网产品因为产品的需求面临用户，或则是线下的业务。需求本身会不停地变换或调整到最好的方式，按传统的方式从需求调研、原型设计、评审、文档、设计、研发，这样的流程需要大量的文档、以及项目审核时间，当审核结束后我们才能进入开发。并且开发的时间周期也是非常长的。导致互联网研发中，其实很多需求都可能已经过时了，但我们仍然在研发中的尴尬局面。

瀑布型工作流程也会导致团队产生容易敌对的关系，比如产品说：“研发他们做不了”，研发说：“产品他们老是变”，互相的责任推卸影响团的士气。

虽然瀑布流的逻辑非常严谨，但开发、产品人员都能了解到它的缺陷。团队内部都会反问自己：“是否应该更应该合理的遵守流程，输出更详细的文档？”

但是却越严格，导致结果团的沟通问题越来越大

所以，在当研发有2-3个以上的时候，突破传统开发瀑布流的方式。可以将有效的增加团队人员的参与感，从需求调研到项目结束每个人都能够完整的感受到项目的成就与失败感。

以人为沟通的“敏捷开发”

敏捷开发的意义是将人的沟通为切入，将团队的概念引入。以产品经理为主导将开发、设计人员关联在一起。固定的每日站会、每周评审、每月复盘，产品经理为切入点带动起来整个项目。

当然敏捷开发的好处是必须要规定1-4周为一个版本。每个周期叫做spring，一旦定下来了就不能更改，简单称呼为：小步快跑、快速迭代。

真正的“敏捷开发”流程到底是什么样的

敏捷开发后我们的研发流程大致如下，下面以CORNERSTONE敏捷开发工具为例:

一. 项目启动

1.1 需求收集

CORNERSTONE为需求生命周期搭建流程，可以自定义更改按收集、评审、排期、设计、开发、发布设立多个阶段，在不同阶段把任务分发给产品、设计或者开发人员，让需求完成无缝衔接。这个阶段其实是产品经理最擅长的领域，即为什么要做这个项目？

在这个阶段，对于负责项目的产品经理来说，需要输出的是需求文档及原型，这是你用来打动老板的基础，也是需要与涉及项目团队成员沟通需求的基础。

1.2 项目启动会

在立项会上顺利从老板那里获得资源后，项目可以真正开始启动了，这时就需要召开一个项目启动会，将项目涉及的各个团队召集到一起，给大家讲一个充满想象力的美好故事，让大家为了这个目标而努力。

那么，具体需要做哪些呢：

1. 明确项目要做什么，其实在这个环节，就是给各团队的同学讲为什么要做这个项目，这个项目能解决什么问题，带来什么样的收益，用项目价值去打动各团队一起努力比老板说必须做这个理由更有说服力和感染力，也会让所有人全心全意去为项目努力付出

2. 明确各团队的职责，即为了这个项目需要做哪些功能的新增或对现有功能的优化。

3. 明确时间节点，即针对于上面提到的功能或优化，各团队开发、测试以及联调的时间节点，明确时间节点可以保证项目可以在计划的时间内完成。

4. 明确项目干系人：项目负责人、技术负责人、测试负责人，在遇到问题时可以找到对应负责人沟通。

在CORNERSTONE里，可以同时并行管理多个项目。每个项目清晰明确可见责任⼈、任务状态、优先级、类别、时间等多维度信息，帮助企业快速⾼效的对项⽬进⾏全周期管理。

1.3 需求讨论及需求分析

作为产品经理，你可能是某一个项目的负责人，也可能是项目相关团队的产品经理。

无论哪一个，你都需要针对自己团队负责的任务进行需求整理，与自己团队的开发、交互视觉设计、测试确认需求、评估需求。CORNERSTONE讨论功能可供团队成员互相交流,共享信息,解决自己在工作中遇到的各种问题。

二. 项目执行与监控

2.1 项目执行

需求确认、工时评估完成后，正式进入项目执行阶段，由相关成员进行开发、设计及测试。CORNERSTONE的甘特图功能可方便管理者弄清项目的剩余时间，评估工作进度，调整工作任务，更好地把握项目的整体。

2.2 站立会、周会

每日站立会以及周会是保证项目正常进行的手段之一，通过每天的站立会沟通，确认团队成员是否遇到了问题，针对问题进行及时沟通与解决，保证项目可以正常进行。

如果项目时间较长，通过周会可以统计周期内好的现象以及遇到的问题，通过会议总结，让各团队了解当前项目进度以及遇到的阻碍。

2.3 联调

联调往往是跨团队项目需要考虑的问题，只要项目涉及的团队大于两个，就需要进行项目联调，保证各自团队负责的功能模块不会因为新的需求出现问题。CORNERSTONE针对这一需求，提供了全局报表（项目进度）。方便管理者了解项目分布、进度计划、质量风险等，并从中获取客观的实时数据，帮助管理人员分析、评估项目，全面了解组合内项目状况，以便作出及时决策。

2.4 项目监控

项目监控，是保证项目进度，保证项目可以在规定时间内保质按时上线。CORNERSTONE中管理者可根据项目创建情况，可实时更新项目状态，预警项目风险。简单来说就是：对项目风险的管理——遇到项目风险如何处理，如何解决。

项目风险的可能性有很多，比如开发的delay、测试出现严重bug、业务需求方在项目进展过程中频繁变更需求导致工时无限延长等等。

CORNERSTONE在可视化的平台活动图上，任意自定义不同纬度统计卡⽚，可⼤⼤⽅便项⽬经理全⾯掌握项⽬进度和团队表现，了解每位成员⼯作产出与⼯时，提前化解潜在⻛险；同时⽀持⼀键分享卡⽚内容。

三. 项目收尾

结束是新的开始，项目也好、产品也好，只要没有死，就一定还会有新的开始。

在产品的生命周期中，包含着无数个项目，这其中有好的项目也有不好的项目。

每一次的项目上线或收尾，都需要对项目进行一次复盘和回顾，发现项目过程中的优点与不足，优点继续保持，不足找到解决方案，在下一次项目中尽可能的避免。