ASK MO第48期 | 如何打造狼性团队？

先说一下什么叫狼性团队?

狼是群体性动物，由头狼带领，在动物界里有极强的目标性和执行力，遇到猎物能通过各种方法紧追不舍，把猎物逼到死角，然后杀死。

所以很多公司，希望自己的团队像狼一样有这种特性——攻无不克，战无不胜。

典型的狼性团队有华为和阿里。

华为的“胜则举杯相庆，败则拼死相救”很好地诠释了什么叫华为的狼性；而作为互联网公司的阿里则用“一张图，一场战，一颗心”来诠释什么是阿里的狼性。

这句话我解释一下。

“一张图”，说的是战略地图，我们用同一张战略地图，来清晰地告诉整个团队，我们的目标是什么？为了达成这个目标，会有一系列的战略，团队不仅要知道目标，还要知道怎么达成这个目标。

“一场战”，说的是把团队看作战友，大家一起出生入死，每一个人都是兄弟，不抛弃，不放弃，共同吃喝，共同成长，同时给团队放到外部激烈的竞争环境，而不是把团队当作温室里的花朵。

“一颗心”，说的是团队要齐心协力，共同完成目标，而不是你走你的阳光道，我过我的独木桥。

狼是吃肉的，不是给个青菜萝卜，或剩菜剩饭，就能培养有战斗力的狼，那只能把狼慢慢驯化成听话的狗。

所以，具体的做法是：我们应当先把团队组织变成跨职能的团队，然后设立共同的目标，共同要背负的业务KPI指标，团队要吃喝一起，团建一起，要一嗓子能够叫呼唤到任何一位战友。最后，团队需要公开的，透明的，即时的激励，达成目标之后，每个努力过的人都能分到业务带给大家的利润。这样才能打造合格的狼性团队。而不仅仅是口号。

初级产品经理的目标是：

打磨用户体验

高级产品经理的目标应该是：

要不ROI大于1

（盈利）

要不符合老板/投资人的期望

（产品可以不盈利，但有其他目标要完成）

这是大部分的产品的目标，到了今年互联网寒冬，融资难，绝大部分产品只有ROI大于1才能活下去。

ROI=收入/成本

目标的核心就在于，如何降低成本？提高收入？

（篇幅有限、仅简单介绍）

1. 降低成本

大部分互联网产品成本主要在于人力成本、开发成本，买量成本（增长）；

- 人力成本降低：如针对社招员工，用三个人的工资请两个人干三个人的活；针对基础执行工作均使用实习生；使用外包等；

- 开发成本降低：如建设大中台降低重复做轮子；找开源代码；接外部SDK；外包等；

- 买量成本降低比较难，尤其买到一定量级后；一方面尽可能拓展买量来源，另一方面优化素材、综合优化投放策略，做大量实验；先不展开。

2. 收入提升

收入=DAU*arpu值

-如何提高DAU？提升新增、提高留存。

- 如何提高arpu值？互联网主要的变现手段有：

① 广告；

② 电商；

③ 直播；

④ 增值服务；

⑤ 金融信贷。

（篇幅有限，均先不展开，望体谅，部分会在下面提到）

3. 符合老板/投资人的期望

有些产品的目标未必要自身实现盈利，可能是为公司一些战略服务，也可能是用于做高估值、从资本市场上赚钱，各种可能性都有。做这种产品的产品经理就要深刻理解老板/投资人的期望去完成。

总之，初级产品经理考虑的只是一个“点”，就是产品要被用户喜欢；高级产品经理考虑的是一个“面”，就是我们产品怎么持续创造价值。这个价值可以是有形价值，可以是无形价值。

问得好，过程改进团队顾名思义，通过改进过程来提升效率。所以过程改进并不局限于敏捷过程，而是由非常有经验的咨询专家，通过调研和分析的手段，发现因为过程而出现的效率或质量问题，并实际落地闭环。

举个例子：

腾讯游戏有个部门，叫做游戏安全中心，这个部门主要的职责是打击游戏外挂，绩效可以概括为三个字：快，准，狠。

“快”，是指在游戏玩家使用外挂到把玩家踢出游戏，要求时间最短。

“准”，是指不能把那些没有使用外挂，但手速比较快的玩家误认为是外挂给踢了，要把误踢率降到最低。

“狠”，是指对于重复使用外挂的玩家，惩罚力量要大，永久封掉游戏帐号。

其中体现得比较集中的问题，是在“准”的方面。在这种判断玩家是否使用外挂的策略脚本上容易出问题，导致误踢率很高。

莫老师的改进过程是：

1. 了解安全中心的打击外挂策略，了解系统是怎么运作的；

2. 分析最近的误踢事故，了解清楚共性问题；

3. 通过组织事故回溯会议，通过使用根因分析方法，和专家一起分析根本原因和解决方案；

4. 发现解决方案分为长期解决方案和短期解决方案，拟定两个方案的负责人和解决时间。

我们发现，安全中心的踢人脚本很多情况是由于人为疏忽导致的，而在脚本发布的时候，并没有复核机制，所以我们在短期方案当中加入了人工复核机制，但是考虑到人工的效率问题，我们在长期方案当中加入了自动复核。通过这两个方案来平衡质量与效率。

我之所以说这个案例，是想说，我们在进行过程改进的时候，不要拿着锤子就去找钉子，而是要找到问题的根本原因，通过自己所学到的不同的知识，工具，解决不同的问题，从而真正有效地解决组织的问题。

如果真的没有办法做到自动化测试，我这里倒是有个办法，我们可以先在回归测试上做到自动化。

因为一般我们的核心业务流程是比较少得会做改动的（如果经常改就糟糕了），所以不能全面自动化测试，那么至少核心业务能保证了。每次发开发完之后，跑一下自动化，保证核心业务不受影响，如果影响了，马上修改，尽早解决问题。

另外，进行微服务化架构也是可以让问题尽可能地在单个模块被发现，业务之间进行解耦，通过接口进行通信，并把系统错误日志建立好，这样出了问题马上能发现是哪个服务出现了问题，马上修改，尽早解决问题。

40人团队不太合适敏捷开发，拿晨会举例：

1、这个圈子太大，没有办法听清对方的说话；

2、团队太大，单个人的信息对于大多数人来说并无关系，听到无用的信息太多，会觉得浪费时间；

3、晨会时间太长，每个人一分钟，一个站会就是40分钟，没人受得了。

最后的结果就是晨会取消。

回顾会议就更加，本来10几个人的回顾会议就要120分钟了，这是有效会议的极限了，40个人开一下午会议？开什么玩笑，最后回顾会议也觉得太形式，取消了。

可想而知，最后又变成敏捷的锅了。敏捷就是那么形式，是个干垃圾。

那怎么做呢？

如果40个人的团队，现在在开发过程当中没有任何问题，大家都觉得挺好，我觉得没有必要转成敏捷开发。

如果要求快速试错，价值交付，可以尝试使用敏捷开发。

那么，先要做的事情是，业务是不是能解耦？系统是不是能解耦？业务解耦是基础，只有业务解耦了，系统才能解耦，系统解耦之后，团队才能解耦。目标是把团队拆分成10人以上的跨职能团队，这样团队运作起来效率比较高。

总之，这是一个长期的过程，需要不断地投入精力，并且有坚定不移的信念，转型才能成功。

祝好运。