讲师介绍

淘系技术部 | 闲鱼技术部 | 鬼才

“闲鱼从零发展到过亿MAU的APP不同阶段的业务特点、核心问题以及针对性的优化，来阐述PMO视角项目管理、敏捷协同的演进思路与心得。“

郭歆伊（花名鬼才），负责闲鱼项目管理。先后在中国银联、网易和阿里等公司负责产品经理和项目经理工作。对数据产品设计、敏捷研发实践、技术品牌建设有丰富实战经验。主导两本Flutter书籍的出版。

   预期收益

希望在座（读者）朋友们可以通过本次的分享，在以下几个方面看到共鸣的同时，得到一些与以往不同的心得：

1、了解闲鱼在项目管理、工程效能视角上的特点及背后原因

2、发现闲鱼敏捷化走出的个性化演进之路

3、探究OKR在闲鱼与Scrum、DevOps的解构组合实践

4、展望闲鱼PMO对效能提升的策略、抓手与落地。

本次GIAC的分享，是基于年初在GOOGLE女性开发者大会的基础上，做了一些内容和迭代上的优化。经过5个小时的航班延误，能够成功身处深圳做分享很开心。会场里人均佩戴口罩，但交流热情不减。

   我眼中的闲鱼与思考

首先，大中台小前台。闲鱼作为一个独立创新型产品，和商品和交易和安全，和阿里的很多职能型团队有交叉关系。我作为小前台业务缺乏话语权和影响力。

第二，高增长无体系。我们的组织架构按照职能划分，保证执行效率强，大家更关注自己的目标而相应的不关注协同，缺少合力。

第三，高效率无质量。几年下来闲鱼做了很多事儿，其中有始无终的这有时候也是难免的，产品把需求做上线了业务运营没及时跟上；运营做活动摸到高产品判断不做持续投入。等等这种有人生没人养的现象也是有的。

思考下来，这三个问题本质上都是职能组织架构带来的客观现象，而在闲鱼团队作为一个弱矩阵的项目经理，无法改变这些客观情况的场景下，我怎么办？

   17年：定痛点、落策略

刚加入闲鱼，团队同学对项目管理这个岗位的认知和接受度怎样？我怎么去发现各个角色的痛点在哪儿？哪些是最先需要解决的？从哪个角度切入？我应该全面推进暴风骤雨还是一步步和风细雨改善？

这里面我的思考是：和同学们一起打场仗。通过这个过程让大家体会到我们是一个壕的战友。

这里面例子就不具体展示了——部分存在外部依赖的项目存在容易产生推诿、三不管地带的情况。这种生产关系的背景下，又往往伴随需求井喷任务重压力大、以及核心能力和目标存在gap等痛点。

这里面的思路，是建立一个反馈渠道形成激励，做客观的度量反馈。

在这里边去监控关键质量指标、导入晨会日报的协作、按需复盘总结、以及沉淀一套评价模型。这一套组合拳打下来，就是pmo非常好的抓手。把这套东西捋平了捋直了捋顺了，不需要每时每刻当监工。主要还是让这个机制本身可以run起来。最后这个项目从最初的持续交付delay，到最终卡住关键时间点顺利上线，并且质量达标。

   18-19年：业务域拓宽对敏捷的要求

18年，闲鱼又新增了多个业务域，包括租房、租赁、数码等等业务百花齐放，想改变带来高增长无体系、高效率无质量的背后的工作逻辑，如何破局？

有两位来自云效团队的非常资深的敏捷教练进入了我们的视野。我领着他们钻进来感受、碰撞，共同策划出一套适合闲鱼的定制化方案，用敏捷的协作模式替换原有的整体抛接式的职能竖井协作模式。那么我们这套敏捷的协作模式从定制化鱼塘项目组的试点，到按部就班一步一步的完成所有业务项目的切换，最终沉淀了一套闲鱼敏捷转型的过程。

怎么理解转型前后的变化呢。

• 转型前
  

转型前，闲鱼以往的协同方式是围绕着端展开的。每个端每个版本指定一位同学担任PM，负责当前版本的主要协同工作。从而保证大多数同学的协同和沟通成本最少、效率更高。这端PM与横向的发布PM、技术PTM和我共同保证发布。按照N（N-1）/2的逻辑，协同的人少了，实际专注干活效率自然高了。

这里我们可以看到，协同机制匹配的项管流程。当初倒推的一个情况，对PRD的评审、甚至评审时间段作出明确的卡；整个版本的Backlog和兵力一目了然；风险识别后通过Aone做跟踪。整个是非常标准化，甚至是可以说是严苛的一个类似契约式的生产关系。

• 转型后
  

开头提到不同角色的痛点。

• Bu-head想了解业务目标完成情况的概况。
  
• 项目经理想拉通需求的流转，及时发现问题解决问题，保障项目顺利交付。
• 一线员工想聚焦在核心事务上，减少切换，早点把活干完干好。

如果缺少有效的方法和机制把大家工作很好的关联起来，就会出现个别团队非常高效，但组织整体效能低下的局面。

架构领域是有一句康威定律，说“产品的架构受制于产生这些设计的组织的沟通结构”。

现在，现在闲鱼每个“自组织的、跨职能的沟通团队”由10人左右组成，包括产品、设计、开发、运营。大家在团队内部进行频繁的、细粒度的沟通。对于团队外部呢，定义好接口人进行粗粒度的沟通。也符合高内聚，低耦合原则。像这样从具体到宏观，再从宏观到具体，不同角色一环扣着一环彼此牵扯，保持整体体感的清晰、实现2周发版的有节奏的小步快跑。这里面本身可以避免强加的0沟通，主动的去驱动全员寻找内在的用户价值动机。

通过这种协同方式的改变，完成业务目标朝战略对其、需求朝业务目标对齐、开发任务和交付朝着需求对其的一个上下有力支撑的体系。图上大家还可以看到我们用增项目的一个看板哈，每个人都会把自己的目光非常低成本的对应进去，紧密协作。在版本发布守护侧，业务节奏和发版班车节奏能够更灵活配合。过去围绕节奏的问题需要协作讨论，现在每个业务方按照规律匹配节奏就好。这里我们现在的目标是每周发版，正在想着这个方向努力哈。

   20-21年：“OKR+数据驱动+技术品牌”进一步拉升效能

作为独立业务，我们也在不断的反思：

• 今天我们是不是在闭门造车？
• 我们是否在正确的做事，是否在做正确的事？Do Things Right vs. Do Right Things？
• 怎么解决众口难调的人的问题？怎么解决需求井喷的事儿的问题？

在这个阶段，我的目标是更好的完成从技术视角到业务视角的转型，“业务PMO”+“产研交付PMO”都要抓。

闲鱼从去年6月早早开始了OKR的试点，到现在我们对OKR这个工具用到什么程度、到底怎么用的，拿出来和大家分享。

• OKR+战役
  

OKR与项目的结合。从PMP的五大过程组里横向看，无论是启动规划、执行监控还是收尾，整个过程中OKR都可以或重或轻的渗透进去，给到组织包括我们项目经理本身作为一个很好的抓手。

过去我们曾经面临过这样的现象，项目往往非常复杂，涉及的部门众多，让一个一号位更好的指挥整个战役，甚至需要考虑调整组织结构去加以保障。而OKR的好处是，可以暂时搁置争议，让大家首先取得O的共识，甚至可以多个一号位分别对不同的KR负责，确保咬和关系。

• “OKR+数据驱动”协同机制
  

OKR结合数据驱动项目管理DDD（data-driven-development），视角转到协同机制：

• 10人左右的自组织小闭环team，作为虚拟团队focus在核心用户价值和策略上；
• 实体特性团队——多以sprint为组织单位——关注效率质量体验和兵力最小化。
• 最终按照同一个逻辑收敛到head层面，关注核心OKR。

这里面PMO扮演着至关重要的角色，需要每月、每周的维度拉通对OKR的对齐。

• “OKR+数据驱动”流程
  

而在相关流程的层面上，管理手段上建议善用Key Path、信息指数和进度这几个度量衡。怎么用、用到什么程度，这个结合管理者，一号位的用法。

• 严防“为了OKR而OKR“
  

• 技术品牌：进一步拉高效能
  

同时我本人还负责了技术品牌项目的一号位，通过不断拉升团队的技术影响力，催生出更多关注我们对我们感兴趣的开发者，从而孕育出更大规模的团队。上图可以看到一些具体的信息。包括我们聚焦的选题、方向、开拓的渠道以及探索的多种形态。

提到技术品牌不能绕开Flutter。Google Flutter广受业内瞩目，闲鱼团队可以说第一时间看见了Flutter并且积极与Flutter团队建立联系，成为国内首个Flutter共建的团队、也是最大规模上线Flutter的产品。我们于今年、去年分别出版了两本Flutter书籍，现已经冲到京东技术新书排行榜榜首，大家如果感兴趣也欢迎购买。

   效果及大图

闲鱼的效率稳定位于同级团队前30%，吞吐率和交付周期均位于前列。这个结果不意味着就很好了，相比于当前的结果我们更看重的是未来的趋势，更深进去持续不断的分析数据追求用户价值才能撬动整体的组织效能。

团队在往更高的ROI，更高的目标达成方向努力！

   聊聊心得

五年下来，一路成长一路荆棘、一路磨练一路风雨。这里借用傅高义老师《*时代》中的“三论”来跟大家分享近期我的心得。

• “猫论”
  

上图中我罗列了部分项目管理方法。无论新老、无论来源，我认为项目管理方法不存在真正意义上的好坏优劣，适合当前组织现阶段的，能够解决关键问题的，就是值得尝试的。没有一个“大而全”或者“特效药”的方法可以一直提升组织效能。PMO的工作需要关注网状系统解构，也需要随着业务适时变化。明确当前组织特点和业务核心问题才是选型的根本，不符合当下的流程再领先也没用。转型的过程需要不短的周期和成本、PMO需要给自己做好心理建设。这个过程就像想要练出腹肌，需要一个撕裂的过程，才会长成更大块的肌肉。

• “摸论“

古德哈特定律带给我们的教训就是：明智的决策者既不能迷信指标，也不能固守教条，需要具有前瞻性与博弈思维。

• “不争论“
  

• 一旦我们自己知道了一件事情，就会很难想象不知道它的时候是什么样子。PMO日常是处在一个网状协作，不是重复和机械式的工作。我们不能只靠定性或者只靠定量。我认为作为一个PMO应该要具备知道自己不知道的思维，多去挖掘自己不知道的领域，而不是局限在我有哪些项目管理的经验，我熟悉哪方面的项目管理工作。只有自己能具备多角度看项目的思维+对应的知识储备，才能更全面的分析项目的管理特点/难点/成功点/失败点，制定更合适有效的项目管理策略。
• PMO的工作忌讳“一刀切”：只focus“显性化”会导致远离一线同学、远离地面；而如果每天埋头于茫茫多的需求评审、站会中又会缺失对全局的把控力。抬头望天和脚踏实地结合起来。不要过于争论一件事情、钻牛角尖，投更多时间去思考业务理解。
• Sooner、Safer，非常重要的是也要一起Happier。

   道阻且长，心力要强

提高交付用户价值的效率，解放生产力。这是一个巨大的话题，涉及到思路转变、工具迭代、数据驱动等等。未来要走的路还很长很长，而最妙的就是，我们就在其中经历和见证。

以上是我的分享，主要覆盖闲鱼敏捷化转型、OKR应用实践等内容。希望可以对大家有所启发。