飞书项目是面向复杂产研团队的专业的项目管理平台,提供了高度灵活地配置,为多种类型的项目管理提供可能性。针对需要为产品做增量迭代优化的产研团队,飞书项目全景视图、看板等多种视图模式和工作项关联、需求跟踪能力,支持把产研协同关键要素融入到飞书项目产品中,帮助团队高效落地产品研发实践。
背景
2016年9月上线后,抖音在短短几年内迅速成长为一款“国民级应用”,并仍然保持高速迭代。普通的项目经理,光是协调50人的产品、设计、研发、测试,给几十个上百个需求排期,都已焦头烂额;而在抖音,难度系数直接乘四。
项目经理,如何做到业界四倍人效,支撑国民级应用的“高速奔跑”?近日,飞书项目管理专家祁梦月在飞书“项目管理社区”的一次分享会上,透露了抖音项目经理的“秘籍”。
事实上,工具的割裂、复杂角色的参与和协同、以及新人的学习成本太高,几乎是所有公司管项目的难题。可行的思路,是构建一套所有人能上手的业务流程,充分提升“事”的效率,解放“人”的双手。
“我们的项目经理只负责两类事,一类是超大型复杂项目,比如抖音直播世界杯,另一类就是组织效能的提升。”祁梦月表示,当一个团队有了完善的流程和工具的支持,它可以实现“自运转”。
从1:50到1:200,从人力驱动到流程驱动
今天的分享话题是“如何做一名管理两百人团队的项目经理”?这个选题来自我们对业界的观察和对比。在互联网等行业中,项目经理这个职位和传统意义的项目经理是有些不同的。
除了以传统项目经理的定位驱动落地那些“临时的、独特的”项目之外,会更多地关注多个并行项目或者更多价值的持续交付,越来越关注整个团队日常工作的高效开展。
这里我们见过很不相同的实践。
有的团队,管理非常精细,一位项目经理会全力支持一个小规模的团队,比如一个scrum 团队,10人左右,那其实无论多细致的项目,都有项目经理支持,包括进度、上下游沟通、风险等等,都有,研发等其他角色需要项目经理支持的,也是每个项目上很具体的一些事情。
更常见的配比大约1:50,我们看到项目经理就不会看所有的具体项目了,会看一些重点的,也会看一些流程上的,组织上的事情,其实大家的思路会比较类似,流程建设的越完善,项目经理的视角会越高层。
在我们的实践中会做得更加极致一些,项目经理负责两种事情,一个是超复杂的大型专项,比如抖音直播世界杯;再一个,就是真正意义上组织的PMO,从组织视角去关注效能、及效能提升的相关建设。
相应的,在比较完善的流程和工具支持下,大型产研组织大部分具体的工作是可以靠团队自组织完成的。
小步快跑,不断向市场交付价值
进到具体的实践之前,大概向大家介绍下,大型产研团队做项目管理的大背景。
第一件事是把执行层面的事情拆细,变成我们常说的“需求”。业务内部的需求,不需要有跨业务线的依赖和影响,一般研发周期几天到两周能够搞定。这样在执行层面,大家的目标一致。这类规模的产研项目,每个业务线按照自己和上下游商定的流程执行即可。
但这里也有挑战,产研项目上的角色比较多,互相之间的配合也很紧密。同时两周几十个,团队层面看并行的也很多,且每个需求的进展也很快。对各角色是否能紧密配合提了更高的要求。
我们在一个需求里大概有这样一些角色。
相应的,有这么几个主要阶段。
那我们就逐一看一下这些角色的日常工作。
产品负责人
产品owner负责这个需求的成败,所以他会关注需求的完整计划、进展、卡点和不同需求可能有不同要求的流程分支。但他自己的专业工作是产品经理,输出产品方案,主要的精力并不会放在项目管理上。
因此我们需要有一个强有力的工具,让团队能够自组织的工作,让他能非常容易的知道所有相关的事情。
比如这里,产品owner可以通过这张节点流的图,看到这个需求有多少个环节,分别都是谁在负责,或是还没有安排,现在进行到哪里了,有哪些点已经逾期了,后续的计划是怎样的,有没有相关联的缺陷等等。
👆飞书项目通过可视化的节点流,将项目各阶段串联起来,项目进度、负责人一目了然。
可以看到这里团队是按照角色和流程来组织的,并不是按照职能部门汇报线组织,也不仅仅停留在像“开发中”这样较粗粒度的状态管理上,而是真正把一个需求铺开了,给到需要的人需要的信息。
一线研发、测试
一线研发、测试关注这么几件事:
- 自己的任务:我今天来了要做那几件事,哪些已经到截止日期了,分别关联了哪些需求。这里要给他们一个地方很容易找到这些信息,帮助他们需要专注的时候专注。
- 需求完整的上下文:我们希望一线人员也能做决策,那也得把做决策相关的信息让大家很容易找到。飞书需求群汇聚了这个需求所有的上下文、包括历史讨论和结论等等信息。
流程的流转:尤其对于研发,我们希望他的时间都花在最有价值的事情上,比如我写完代码了,最好能够流程自动流转。这里我们集成gitlab,把分支相关的信息一个同步到一个地方,再一个自动流转流程,减少流程的流程感。
业务负责人
业务负责人是视角最宏观的那个人。一个合格的业务负责人应该也是非常了解项目细节的,而不是纯粹的只是管理。
所以在具体的需求上,对于重要的需求他确实要进入细节了解,且还不是通过周会,不是通过临时打电话问下属这样的方式,而是随时掌握准确的信息。
那工具给到他的,当前的完整进展,人和事的对应,目前的卡点这些信息,且不一定是pc端,手机也可以。
项目经理/PMO
接下来是项目经理/PMO,刚才提到他会非常关注组织过程资产的沉淀,比如流程本身。
流程是不是该升级了,哪些不同类型的需求应该适配不同的流程,如何管理。
👆模板管理:管理不同类型的需求流程,飞书项目支持创建不同类型的流程类型,使用时可以一键复用。
话说回来,定好的流程,总有特例。
比如一个需求是否一定需要前、后、移动两端的研发所有角色?一个需求是否一定要数据埋点?都不一定,那我们可以通过工具上的角色和节点的配置,比如做技术重构,不需要UX,那就把UX 角色拿掉,那自然这个需求里相应的节点就会被裁剪掉。
👆流程裁剪:根据需求直接便捷裁剪修改流程
另一方面,组织层面也会通过数据来看组织运转的情况。这件事一般会由PMO 承担,工具层面帮助他把做这件事的成本降到最低。
最早没有工具的时候我们也做类似的度量,但是数据分析的坑都要踩,没有原始数据积累啦、多个平台数据口径对不上啦、分析一次要花一个月啦,都经历过。
现在,通过工具,团队日常工作的同时积累数据,同时在这个平台上分析,且实时能看到数据结果,也是大大提升了PMO 本人的工作效率。
这里一般会看以下两类数据:
质量分析:关注缺陷情况
研发团队负责人
最后一个角色是研发团队负责人,他会从他团队的视角看,我这个团队现在都接了什么事情,都从哪个业务线来的,尤其是中台团队,非常关注在不同业务线上的人力投入分布,作为未来对齐资源投入的参考之一,也会更多的和资源要求多的业务讨论价值,甚至参与业务讨论。同时也关注产品需求和技术需求的分布,留好资源做技术上的升级和稳定性建设。
另一个工具是人力甘特图,帮助团队负责人去看自己团队的每个人,工作负荷如何,分布是否合理。
定性与定量,需求价值验证
以上是需求里的角色,那么如何确保需求价值呢?这里多说一个和需求相关联的实践。
前面提过综合评审,是做之前大家讨论判断一下是否值得。那是不是真的判断对了么,需要后验。这里有两个角度:
- 定性:偏主观的判断,参与这个需求的所有人,打个分,看看这个需求里有没有什么需要改进的地方。
- 定量:做AB 测试,绝大部分需求都会有,无论是抖音的新功能是否被用户接受,还是推荐广告搜索的算法是否达到了相应的提升,都会通过AB 测试来证明。
用流程和工具串起整个团队
一句话总结一下就是,流程和工具串起整个团队,目标对齐后各业务线在执行层面拆成需求,每个需求按阶段、按角色、按流程自组织的运转。同时PMO 在组织层面做好沉淀,做好裁剪,做好改进。
这张图在各业务线里的实现已经挺不一样的了,但整体的思路还在,我刚才讲的这些角色,在这里都能找到。