纯银：产品小团队

大清早的，看了左耳朵耗子的《开发团队的效率》，一百万个赞同。从产品经理的角度来说说“产品小团队”。

去年底，蝉小队并入携程。那时我们有 3RD/2PM/1UI，产品团队一共 6 个人，做蝉游记/蝉游画报/蝉游攻略这 3 款产品。后面两款很快停止维护。

就在最近的6-7 月，我同时做携程周末大版本迭代，生辰大版本迭代，蝉游记小版本迭代，即将发布的玩票新 App，刚刚立项的正式新 App (全套原型定稿)，一共 5 款产品，你猜猜蝉小队的产品团队增加到几个人？

7 个人，上周刚来了一位 Ruby 工程师。

携程其他部门的人跟我说，太羡慕蝉小队的研发速度了。我们的产品团队人数多 3 倍，速度慢 3 倍。

你没听错，3X3=9 倍。

说说我的看法。

1、

我打死不加产品经理，就我和策策两个人。两个人不仅可以同时推进以上 5 个项目，策策还在搞自己的玩票 App 原型，我还在帮另外两三个友商友情重构产品原型(产品性饥渴)。

大家都知道，品相好的产品汪数量极少。一旦产品汪的需求不够精炼，从根子上就摧毁了整个项目研发效率。所以我不加人，我和策策自己扛，加班就加班。

不仅如此，我俩还兼职做所有产品的 QA 呢。

2、

UI 设计师，一个就够了。

以前我设过 2 位 UI 设计师，很快发现喂不饱……总是有人闲着没事干，我还得为他们专门想点任务出来做。而且 2 位 UI 设计师必然有主有次，谁是主谁是次呢？在超级扁平化的蝉小队，我很不愿意设主次之分。

后来一位 UI 离职，我索性不补人了，另一位 UI 顶住……她果然就顶住了。蝉小队特别适合独立，傲娇的人，也就是和我个性相似的人。

我知道很多缺氧傻逼这时要嚷嚷起来了，黑心老板压榨员工。你妈逼，我司 UI 妹子几乎从来不加班。

缺氧傻逼继续嚷嚷，上班时间排得太满，不给员工学习充电的时间。

你知道新浪微博有一个功能叫“拖黑”吗？

3、

基本上，1 后端/1iOS/1Android 客户端的研发配置就够了。

因为后端太重要，不希望 Quake 是唯一瓶颈，所以近期又有一位 Ruby 工程师加入。

iOS 工程师兼 H5 与 Web 端研发，Android 工程师同时也会 iOS 研发。

研发速度像风一样快。

携程其他部门的产品汪向我吐槽，说我改一个列表页，就要通知 4 位工程师，他妈的我只是改一个列表页的信息展示方式啊。4 位工程师都得我来通知到位，解释清楚，漏任何一个人，上线出了问题就让我背黑锅。他妈的我只是调一下列表页的显示顺序和内容元素啊。

这件事情在蝉小队怎么处理呢？我把一条任务写在 Tower 上，指派给 iOS 工程师，然后他 QQ 群里跟后端工程师说一声，几小时后 API 改好，iOS 工程师也很快改好，在 Tower 上勾掉任务，通知我去测试。当天内解决。

这时候很多缺氧傻逼又要嚷起来了，舍不得花钱加人，黑心老板压榨员工。你妈逼，我司工程师最近一年加班的天数估计不到 2 周。

从我对携程团队的观察来看(我一直当自己是雇佣兵而非携程员工)，这并不是工程师能力的问题，而是技术管理风格导致。携程也有很多很好的工程 师，但分工一旦细致起来，你只做模块A，他只做模块B，大大束缚了工程师的发挥。人数增加首先大大提升了沟通成本，其次大大拉低了责任心，因为“共同负 责”嘛，总能找到推诿的理由，也时常被猪队友气得撒手不管。

4、

熟悉我的人都知道，我坚持 PM 兼任 QA，也就是不设专职 QA。

我自己创业 3 年多，身体力行，产品只出过一次上线后紧急打补丁的大 bug (注册环节测漏掉了)，Crash 率低于 iOS 端千分之一，Android 端千分之三。

这件事说起来太细，总之，我证明这是能做到的。少一个 QA 环节，增加的故障率是能容忍的，却大大减少了沟通成本。

但 QA 在大公司是必须的，携程主 App 的稳定性完全依赖于 QA 来保障，PM 兼 QA，也只是在体量不到千万的独立 App 才能实现。

缺氧傻逼继续嚷，黑心老板压榨员工……等等，这家伙自己就是老板兼 PM？好吧，不可能再找到另一个像你这样自虐的人了。

第一，我司另一只产品汪策策也兼 QA，所有产品由我和他轮流测试两次。第二，很多人想学习我的产品能力，为什么不能同时学习我这种“一肩背”的产品态度呢？何必叶公好龙。

5、

一边写这篇文章，系统一边弹新浪微博的评论消息。有不少反对意见，说小团队不是万能的，不能解决所有问题。

这不是废话吗……

对于不到百万日活，不算特别大研发量的中小产品来说，小团队是最佳配置。

走小团队的路数，有三个前提。首先得有一两个热爱小团队的核心人员来驱动，比如我和 Quake，比如左耳朵耗子。

其次，这样的核心成员对进度管理得有实权，能容忍磨合过程中，短时间的进度损失。比如我曾经把整个项目停下来一两个月，工程师学习新的开发语言。

最后，还得控制好产品需求，如果根子上出了问题，就别谈什么效率了。做什么都是错的。

我在微博多次发表和效率有关的几个观点，罗里吧嗦的，最后重复一次吧。

任何产品，至少 50% 的需求对成败是无影响的。包括错误的方向，错误的设计，以及并没有错但是然并卵，仅仅是设计者自我陶醉的细节。我做了 8 年产品经理，还是只能将有效需求控制在 50% 这个比例上，其他人更是可想而知。多做有效需求，少做无效需求，研发效率翻着倍地提升。

我还有一个“少两成”理论，即工程师的研发时间永远都应该比产品经理(第一稿)的需求少两成，逼着他去精简需求，挑出最重要最紧急的需求来，即 便对我这样的老手也是如此。就在昨天，我还哭丧着脸跟工程师说，好好好，赶档期，这个功能先不做，那几个功能压到 1.1 版本，胸口跟插了两刀一样痛……

但这是对的。

Quake 有句名言，任何功能多拖几个版本，很可能产品经理自己就不想做了。因为前面几个版本已经验证出来这是无效需求了。

总之，提高效率的终极方案是“砍需求，砍人头，控制版本节奏”。砍需求减少无效研发，砍人头减少沟通成本，而版本循序渐进，分批验证设计更加是 金科玉律。“再招几个人”的应对思路总归是下下策，解决一时的进度，却带来长久的内耗。产品团队人招得越多，则研发效率越低，产品经理扎堆更是无人可破的 黑魔法，中招必死，死相难看。