小团队与抠需求

作者: 纯银V | 来源:发表于2017-01-05 23:29 被阅读7297次

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

10-20人也算是小团队。

100人以上算是大团队。

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

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

如果我们通过项目复盘,仔细厘一下研发浪费发生在哪里,你就会发现:

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

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

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

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

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

敲黑板,划重点:“小团队的精髓并不是牛逼的程序员,而是对需求的冷静把控。”具备这个能力的人很少,所以产品经理越多项目越乱,PM扎堆的地方就跟养蛊一样。我曾经夸口说,只要由我带队,就能长期维持小团队,也是这个道理。

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

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

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

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

按照科技媒体的报道,Instagram被Facebook 10亿刀收购的时候,仅13人。

WhatsApp被Facebook 190亿刀收购的时候,仅50人。

美国现象级应用Musical.ly做到千万日活的时候,据说整个上海团队(目前)不足100人。

我自己身体力行小团队战术,四年来维持一支6人的产品研发团队,总体输出可以与低效率的20人团队相比。由于对运营需求的控制良好,这6个人足够为超过30人的运营团队提供支持。以上的明星案例+亲身实践,证明了小团队的长期可行性。

如果你能自始自终地“抠需求”,不会因为傲慢而膨胀。

所以,我夸口能长期维持小团队,相当于下定决心在一线做产品,死都不会脱离产品经理岗位。同时也会选择产品驱动的项目,产品本身就是核心竞争力。只要我对产品话事,就能将上述浪费降低到最小单位,也将产品经理降低到最少人数,从源头上抓稳需求,奠定小团队的基础。至于产品成不成功,那就是产品玄学的领域了。

相关文章

  • 小团队与抠需求

    先对小团队作个定义:产品+研发+UED少于10个人,就算是典型的小团队。 10-20人也算是小团队。 100人以上...

  • 2020-03-11复盘:

    今日完成: 1. 与开发和测试团队完成中港的五个小需求的需求的需求评审: ①派车单发送 ②邮件内容改善 ③预览按钮...

  • 小团队如何管理需求列表

    什么是需求 需求是在创建一个新的或改变一个现存的产品时,确定新产品的目的、范围、定义和功能时所要做的所有工作。 产...

  • 一个新团队需求会后待解决的问题

    今天又是一天的会,发现了以下问题 1、不是团队负责的需求在团队内讲了 2、大需求讲了好多,小需求来不及讲 3、pr...

  • 用户研究的价值何在?

    前段日子团队在做A项目,产品给出需求后,交互根据PRD设计出demo,最后与开发团队评审时,开发提出:这个项目与之...

  • 跨团队协作

    后端产品,使用的业务部门较多时,就涉及到跨团队协作,跨团队协作的目的,有以下几种: 1、实现整体需求与分工需求:大...

  • 一个需求做多少,怎么确定?|日X:87

    突然顿悟到,不管是在大团队还是小团队,确定不大部分普通需求(类似数据迁移和系统升级这类的需求不算)的范围和该做多少...

  • vol.20深入剖解产品经理基本逻辑:需求分析

    1 收集需求 简历需求池 : 我想和大家分享一下产品经理工作中的基本逻辑:需求分析。 很多小团队粗糙的做需求分析,...

  • “小抠”妈妈

    我的妈妈是个“小抠”!没错,就是“抠搜”的“抠”。 在小学的时候,她就让我写一篇作文《我的妈妈》,上初中也说过,上...

  • 漫修

    抠脚大汉,小苦瓜,哈哈

网友评论

    本文标题:小团队与抠需求

    本文链接:https://www.haomeiwen.com/subject/dazzvttx.html