大型产研团队项目管理最佳实践：项目管理如何实现业界四倍人效？

飞书项目是面向复杂产研团队的专业的项目管理平台，提供了高度灵活地配置，为多种类型的项目管理提供可能性。针对需要为产品做增量迭代优化的产研团队，飞书项目全景视图、看板等多种视图模式和工作项关联、需求跟踪能力，支持把产研协同关键要素融入到飞书项目产品中，帮助团队高效落地产品研发实践。

背景

2016年9月上线后，抖音在短短几年内迅速成长为一款“国民级应用”，并仍然保持高速迭代。普通的项目经理，光是协调50人的产品、设计、研发、测试，给几十个上百个需求排期，都已焦头烂额；而在抖音，难度系数直接乘四。

项目经理，如何做到业界四倍人效，支撑国民级应用的“高速奔跑”？近日，飞书项目管理专家祁梦月在飞书“项目管理社区”的一次分享会上，透露了抖音项目经理的“秘籍”。

事实上，工具的割裂、复杂角色的参与和协同、以及新人的学习成本太高，几乎是所有公司管项目的难题。可行的思路，是构建一套所有人能上手的业务流程，充分提升“事”的效率，解放“人”的双手。

“我们的项目经理只负责两类事，一类是超大型复杂项目，比如抖音直播世界杯，另一类就是组织效能的提升。”祁梦月表示，当一个团队有了完善的流程和工具的支持，它可以实现“自运转”。

从1:50到1:200，从人力驱动到流程驱动

今天的分享话题是“如何做一名管理两百人团队的项目经理”？这个选题来自我们对业界的观察和对比。在互联网等行业中，项目经理这个职位和传统意义的项目经理是有些不同的。

除了以传统项目经理的定位驱动落地那些“临时的、独特的”项目之外，会更多地关注多个并行项目或者更多价值的持续交付，越来越关注整个团队日常工作的高效开展。

这里我们见过很不相同的实践。

有的团队，管理非常精细，一位项目经理会全力支持一个小规模的团队，比如一个scrum 团队，10人左右，那其实无论多细致的项目，都有项目经理支持，包括进度、上下游沟通、风险等等，都有，研发等其他角色需要项目经理支持的，也是每个项目上很具体的一些事情。

更常见的配比大约1:50，我们看到项目经理就不会看所有的具体项目了，会看一些重点的，也会看一些流程上的，组织上的事情，其实大家的思路会比较类似，流程建设的越完善，项目经理的视角会越高层。

在我们的实践中会做得更加极致一些，项目经理负责两种事情，一个是超复杂的大型专项，比如抖音直播世界杯；再一个，就是真正意义上组织的PMO，从组织视角去关注效能、及效能提升的相关建设。

相应的，在比较完善的流程和工具支持下，大型产研组织大部分具体的工作是可以靠团队自组织完成的。

小步快跑，不断向市场交付价值

进到具体的实践之前，大概向大家介绍下，大型产研团队做项目管理的大背景。

第一件事是把执行层面的事情拆细，变成我们常说的“需求”。业务内部的需求，不需要有跨业务线的依赖和影响，一般研发周期几天到两周能够搞定。这样在执行层面，大家的目标一致。这类规模的产研项目，每个业务线按照自己和上下游商定的流程执行即可。

但这里也有挑战，产研项目上的角色比较多，互相之间的配合也很紧密。同时两周几十个，团队层面看并行的也很多，且每个需求的进展也很快。对各角色是否能紧密配合提了更高的要求。

我们在一个需求里大概有这样一些角色。

相应的，有这么几个主要阶段。

那我们就逐一看一下这些角色的日常工作。

产品负责人

产品owner负责这个需求的成败，所以他会关注需求的完整计划、进展、卡点和不同需求可能有不同要求的流程分支。但他自己的专业工作是产品经理，输出产品方案，主要的精力并不会放在项目管理上。

因此我们需要有一个强有力的工具，让团队能够自组织的工作，让他能非常容易的知道所有相关的事情。

比如这里，产品owner可以通过这张节点流的图，看到这个需求有多少个环节，分别都是谁在负责，或是还没有安排，现在进行到哪里了，有哪些点已经逾期了，后续的计划是怎样的，有没有相关联的缺陷等等。

👆飞书项目通过可视化的节点流，将项目各阶段串联起来，项目进度、负责人一目了然。

可以看到这里团队是按照角色和流程来组织的，并不是按照职能部门汇报线组织，也不仅仅停留在像“开发中”这样较粗粒度的状态管理上，而是真正把一个需求铺开了，给到需要的人需要的信息。

一线研发、测试

一线研发、测试关注这么几件事：

1. 自己的任务：我今天来了要做那几件事，哪些已经到截止日期了，分别关联了哪些需求。这里要给他们一个地方很容易找到这些信息，帮助他们需要专注的时候专注。
2. 需求完整的上下文：我们希望一线人员也能做决策，那也得把做决策相关的信息让大家很容易找到。飞书需求群汇聚了这个需求所有的上下文、包括历史讨论和结论等等信息。

流程的流转：尤其对于研发，我们希望他的时间都花在最有价值的事情上，比如我写完代码了，最好能够流程自动流转。这里我们集成gitlab，把分支相关的信息一个同步到一个地方，再一个自动流转流程，减少流程的流程感。

业务负责人

业务负责人是视角最宏观的那个人。一个合格的业务负责人应该也是非常了解项目细节的，而不是纯粹的只是管理。

所以在具体的需求上，对于重要的需求他确实要进入细节了解，且还不是通过周会，不是通过临时打电话问下属这样的方式，而是随时掌握准确的信息。

那工具给到他的，当前的完整进展，人和事的对应，目前的卡点这些信息，且不一定是pc端，手机也可以。

项目经理/PMO

接下来是项目经理/PMO，刚才提到他会非常关注组织过程资产的沉淀，比如流程本身。

流程是不是该升级了，哪些不同类型的需求应该适配不同的流程，如何管理。

👆模板管理：管理不同类型的需求流程，飞书项目支持创建不同类型的流程类型，使用时可以一键复用。

话说回来，定好的流程，总有特例。

比如一个需求是否一定需要前、后、移动两端的研发所有角色？一个需求是否一定要数据埋点？都不一定，那我们可以通过工具上的角色和节点的配置，比如做技术重构，不需要UX，那就把UX 角色拿掉，那自然这个需求里相应的节点就会被裁剪掉。

👆流程裁剪：根据需求直接便捷裁剪修改流程

另一方面，组织层面也会通过数据来看组织运转的情况。这件事一般会由PMO 承担，工具层面帮助他把做这件事的成本降到最低。

最早没有工具的时候我们也做类似的度量，但是数据分析的坑都要踩，没有原始数据积累啦、多个平台数据口径对不上啦、分析一次要花一个月啦，都经历过。

现在，通过工具，团队日常工作的同时积累数据，同时在这个平台上分析，且实时能看到数据结果，也是大大提升了PMO 本人的工作效率。

这里一般会看以下两类数据：

质量分析：关注缺陷情况

研发团队负责人

最后一个角色是研发团队负责人，他会从他团队的视角看，我这个团队现在都接了什么事情，都从哪个业务线来的，尤其是中台团队，非常关注在不同业务线上的人力投入分布，作为未来对齐资源投入的参考之一，也会更多的和资源要求多的业务讨论价值，甚至参与业务讨论。同时也关注产品需求和技术需求的分布，留好资源做技术上的升级和稳定性建设。

另一个工具是人力甘特图，帮助团队负责人去看自己团队的每个人，工作负荷如何，分布是否合理。

定性与定量，需求价值验证

以上是需求里的角色，那么如何确保需求价值呢？这里多说一个和需求相关联的实践。

前面提过综合评审，是做之前大家讨论判断一下是否值得。那是不是真的判断对了么，需要后验。这里有两个角度：

1. 定性：偏主观的判断，参与这个需求的所有人，打个分，看看这个需求里有没有什么需要改进的地方。

1. 定量：做AB 测试，绝大部分需求都会有，无论是抖音的新功能是否被用户接受，还是推荐广告搜索的算法是否达到了相应的提升，都会通过AB 测试来证明。

用流程和工具串起整个团队

一句话总结一下就是，流程和工具串起整个团队，目标对齐后各业务线在执行层面拆成需求，每个需求按阶段、按角色、按流程自组织的运转。同时PMO 在组织层面做好沉淀，做好裁剪，做好改进。

这张图在各业务线里的实现已经挺不一样的了，但整体的思路还在，我刚才讲的这些角色，在这里都能找到。