小团队与抠需求

11 评论 13907 浏览 62 收藏 7 分钟

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

先对小团队作个定义:产品+研发+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,蝉游记创始人,人人都是产品经理专栏作家。前网易网站产品部总监。一个文艺加文笔好的产品经理。

本文原创发布于人人都是产品经理,未经许可,不得转载。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
海报
评论
评论请登录
  1. 银神,什么时候出书,我要喝你这碗鸡汤

    来自广东 回复
  2. 确实,一昧的增加开发人数增加需求远远没有最初的小团队来的有效

    来自浙江 回复
  3. 大神就是大神,肺腑之言啊。

    来自广东 回复
  4. 自始自终地“抠需求”,不因为傲慢而膨胀。谢谢

    来自贵州 回复
  5. 团队只复制已有的产品,不去想自身真正的需求,既是在浪费时间,也是在浪费成本,更是浪费公司的生命。做的都是无谓的工作,到头来发现“没用”,刚上线或未上线其实就已经“死了”。

    来自北京 回复
  6. 我们也是个创业公司,公司业务是在一条完整的供应链上,根据供应链上角色的不同,划分为三个大的业务板块,但这三个业务板块又至少有上游和下游两个端,还有连接这条供应链的物流端,其中一个业务还打算内嵌一个周边类别的商城(有独立出来一个业务的趋向)。这样加起来有七八个端了吧,PM、UI、研发加起来也就10来人样子,PM感觉也没有话语权,基本按照老板的思路做,做的东西连我们自己都不能一时半会看懂,对于需求的把控,基本没有,业务都可以直接绕过产品直接去和研发聊,业务的题的需求从来都是今天或明天要很急之类的,上面压、下面做,不按流程,做的东西匆匆忙忙上,自己都感觉垃圾,然后还被反过来的说不行,老板会说你们不行(老板自己会去听一些课,觉得自己都比你懂一样),挖过来UC 10 年的PM,后面也觉得不行,干几个月让走了,自己感觉都活在一个混乱的世界,你们觉得这样的公司还有希望吗?实话说公司这个业务确实还是有前景。你们会觉得是谁的问题?

    来自日本 回复
    1. 同在小公司,和你们公司差不多的情况

      来自上海 回复
  7. 或者这么说,给我一个产品周期,我宁愿把50%的时间花在用户调研和需求精简上,把剩下的时间用作开发和运营;
    前期的需求把握,是明确方向,这能决定产品和公司未来很长时间的走向,后面不管执行(开发和运营)多么痛苦,只要方向大致正确,自会水到渠成;

    来自广东 回复
  8. 学习了

    来自上海 回复
  9. 非常认可最后一句话,作为一个产品,职责在于将产品打磨的精细,至于最后产品是否能成功,这有太多因素所导致,不能只看重结果,过程也非常重要,先将分内的事情做到精益求精

    来自湖北 回复
  10. 试错、浪费,之前我们的团队也遇到这种情况

    来自海南 回复