小团队与抠需求

2017-01-06 10:07:00

小团队的精髓并不是牛逼的程序员（虽然这也很重要），精髓是对需求的冷静把控。

先对小团队作个定义：产品+研发+UED少于10个人，就算是典型的小团队。

10-20人算是不典型的小团队。

100人以上算是大团队。

只计算产品研发人员，是因为运营部门通常和产品部门同步增长，当运营人员增多，需求增多，产品研发人员也会增多。而产品研发的效率是互联网公司的发动机。

“如果不是微信/微博这些巨型APP，高德地图/滴滴打车这些重后端的APP；O2O这些重运营的APP，其余的大多数APP都可以由小团队来完成。”

我这个观点是最近两三年形成的，2012年刚创业的时候还不会这么想。如果我们通过项目复盘，仔细厘一下浪费发生在哪里，你就会发现：

首先是方向上的浪费。比如没划清楚主干道在哪里，对不重要的分支进行投入；或者没划清楚产品边界在哪里，对注定失败的拓展进行投入。美其名曰“试错”。试错这件事情大家都会做，但对成功率的预判，对预设目标与投入资源的分寸把握，人和人的差距可以大到几十倍，产生的研发浪费可以大到三五倍。

其次是低价值需求的浪费。低价值需求分三种：

一是错误预判了用户需求，自以为聪明地研发主流用户并不在意的功能；
二是在试错过程中，没做到小步快走，在反响不确定的时候把功能做得过重；
三是抠细节体验抠出血，喝了“细节决定成败”这碗毒鸡汤。

所有的低价值需求都不影响成败，却造成大量的研发浪费。彻底消灭低价值需求是不可能的，只能控制它的比例。在一年的研发周期里，大多数产品的低价值需求在50%以上，也就是浪费了一半以上的时间。但以我的经验来看，控制比例在20%-30%是有可能做到的。

再次是产品经理level高低带来的浪费。好的产品经理，一是预判产品发展路线，提前推测出来产品可能的几条发展路线，提前做好规划，减少推翻重来的迭代次数。二是凡事都会考虑到研发成本，能复用的尽可能复用，能精简的尽可能精简。三是排期灵活，对优先级厘得特别清楚，很多低价值需求在降低优先级之后，拖着拖着自己就消失了。

最后，以上三点浪费如果能得到良好控制，所需程序员的人数大量减少，沟通成本随之大量减少，研发效率翻倍上升，就可以实现我说的，大多数APP由小团队来完成。

敲黑板，划重点：

“小团队的精髓并不是牛逼的程序员（虽然这也很重要），精髓是对需求的冷静把控。”

具备这个能力的人很少，所以产品经理扎堆的地方就跟养蛊一样。我曾经夸口说，只要由我带队，就能长期维持小团队，也是这个道理。

但我这个夸口经常被人喷，说你做产品不成功，没有说服力。

是这样的，无论产品成不成功，以上对成本浪费的分析都是逻辑成立的。最大的区别在于，产品发展起来以后，出于抗风险的考虑，每个位置都要有备份机制，团队数量×2，效率随之下降。像蝉小队那样长期3RD是不可能的——但6RD2PM2UI，还是典型的小团队配置。

产品发展起来，几千万融资到位以后，真正杀死小团队的不是业务成长，而是亢奋带来的需求膨胀。原本抠需求是因为穷，没钱请不起人，只能厉行节俭，现在“钱能解决的问题都不是问题”，为什么要斤斤计较呢？无论是创始人膨胀，还是投资人膨胀，都会急着证明“我们有更大的增长空间”，增长达不到（过高）预期，就会加功能甚至加业务线。在工作量增大的同时，核心产品现在有身份有架子了，不愿意长期在一线干活，要去做“更重要的事情”，哪怕心知肚明一流产品经理是何等的稀缺。

一系列连锁反应让曾经的精益创业变得笨重，但并非人人如此。