产品小团队

0.316字数 2298阅读 28437

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

去年底,蝉小队并入携程。那时我们有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有句名言,任何功能多拖几个版本,很可能产品经理自己就不想做了。因为前面几个版本已经验证出来这是无效需求了。

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

推荐阅读更多精彩内容