小团队的精髓并不是牛逼的程序员（虽然这也很重要），精髓是对需求的冷静把控。
先对小团队作个定义： 产品+研发+UED少于10个人，就算是典型的小团队。
10-20人算是不典型的小团队。
100人以上算是大团队。
只计算产品研发人员，是因为运营部门通常和产品部门同步增长，当运营人员增多，需求增多，产品研发人员也会增多。而产品研发的效率是互联网公司的发动机。
“如果不是微信/微博这些巨型APP，高德地图/滴滴打车这些重后端的APP；O2O这些重运营的APP，其余的大多数APP都可以由小团队来完成。”
我这个观点是最近两三年形成的，2012年刚创业的时候还不会这么想。如果我们通过项目复盘，仔细厘一下浪费发生在哪里，你就会发现：
首先是方向上的浪费。比如没划清楚主干道在哪里，对不重要的分支进行投入；或者没划清楚产品边界在哪里，对注定失败的拓展进行投入。美其名曰“试错”。试错这件事情大家都会做，但对成功率的预判，对预设目标与投入资源的分寸把握，人和人的差距可以大到几十倍，产生的研发浪费可以大到三五倍。
其次是低价值需求的浪费。低价值需求分三种：
- 一是错误预判了用户需求，自以为聪明地研发主流用户并不在意的功能；
- 二是在试错过程中，没做到小步快走，在反响不确定的时候把功能做得过重；
- 三是抠细节体验抠出血，喝了“细节决定成败”这碗毒鸡汤。
所有的低价值需求都不影响成败，却造成大量的研发浪费。彻底消灭低价值需求是不可能的，只能控制它的比例。在一年的研发周期里，大多数产品的低价值需求在50%以上，也就是浪费了一半以上的时间。但以我的经验来看，控制比例在20%-30%是有可能做到的。
再次是产品经理level高低带来的浪费。好的产品经理，一是预判产品发展路线，提前推测出来产品可能的几条发展路线，提前做好规划，减少推翻重来的迭代次数。二是凡事都会考虑到研发成本，能复用的尽可能复用，能精简的尽可能精简。三是排期灵活，对优先级厘得特别清楚，很多低价值需求在降低优先级之后，拖着拖着自己就消失了。
最后，以上三点浪费如果能得到良好控制，所需程序员的人数大量减少，沟通成本随之大量减少，研发效率翻倍上升，就可以实现我说的，大多数APP由小团队来完成。
敲黑板，划重点：
“小团队的精髓并不是牛逼的程序员（虽然这也很重要），精髓是对需求的冷静把控。”
具备这个能力的人很少，所以产品经理扎堆的地方就跟养蛊一样。我曾经夸口说，只要由我带队，就能长期维持小团队，也是这个道理。
但我这个夸口经常被人喷，说你做产品不成功，没有说服力。
是这样的，无论产品成不成功，以上对成本浪费的分析都是逻辑成立的。最大的区别在于，产品发展起来以后，出于抗风险的考虑，每个位置都要有备份机制，团队数量×2，效率随之下降。像蝉小队那样长期3RD是不可能的——但6RD2PM2UI，还是典型的小团队配置。
产品发展起来，几千万融资到位以后，真正杀死小团队的不是业务成长，而是亢奋带来的需求膨胀。原本抠需求是因为穷，没钱请不起人，只能厉行节俭，现在“钱能解决的问题都不是问题”，为什么要斤斤计较呢？无论是创始人膨胀，还是投资人膨胀，都会急着证明“我们有更大的增长空间”，增长达不到（过高）预期，就会加功能甚至加业务线。在工作量增大的同时，核心产品现在有身份有架子了，不愿意长期在一线干活，要去做“更重要的事情”，哪怕心知肚明一流产品经理是何等的稀缺。
一系列连锁反应让曾经的精益创业变得笨重，但并非人人如此。
- 按照科技媒体的报道，Instagram被Facebook10亿刀收购的时候，仅13人。
- WhatsApp被Facebook50亿刀收购的时候，仅50人。
- 美国现象级应用Musical.ly做到千万日活的时候，据说整个上海团队(目前)不足100人。
这些案例，再加上我自己4年做7款APP、5个网站的经历，让我坚持认为小团队足够应对除了巨型APP、重后端APP、重运营APP之外的一切产品。
如果你能自始自终地“抠需求”，不会因为傲慢而膨胀。
所以，我夸口能长期维持小团队，相当于下定决心长期在一线做产品，死都不会脱离产品经理岗位；同时也会选择产品驱动的项目，产品本身就是核心竞争力。只要我对产品话事，就能将上述浪费降低到最小单位，也将产品经理降低到最少人数，从源头上把控好需求，奠定小团队的基础。至于产品成不成功，那就是产品玄学的领域了。
#专栏作家#
纯银V ，蝉游记创始人，人人都是产品经理专栏作家。前网易网站产品部总监。一个文艺加文笔好的产品经理。
本文原创发布于人人都是产品经理，未经许可，不得转载。
