JavaScript must be enabled in order for you to see "WP Copy Data Protect" effect. However, it seems JavaScript is either disabled or not supported by your browser. To see full result of "WP Copy Data Protector", enable JavaScript by changing your browser options, then try again.

caoz谈能力成长 – 取舍之道

俞军老师说过特经典的一句话,优秀的产品经理,要学会做减法。

我们设计产品的时候,创业者,说真的,点子都很多,把设计,计划书拿出来一看,我产品这样这样,然后这样这样,以后还可以拓展为这样这样,聊天的时候突然灵光一现,对啊,我还可以把这个加上去。等等等等。

那,下面是个对比范例

用户真的需要这么多么?

很多时候,我们被自己创造的各种伪需求所麻醉,大家谈东西的时候往往流于自己的才能展示而忽略了事物的本质,比如说,公众号起名这个事情,很多人都有各种奇思妙想而忘记了最基本的诉求,容易识别和容易传播,所以很多特别有想法的名字其实识别度非常低,特别是一些认为用了谐音很有才华的那种名字,最不容易被人传播,因为大部分用户基于第一感都会输入错误。 这就是创业者以及很多工作者最容易犯的错误,想太多,而忽视了最基本的东西。

那么,做产品设计的时候,我们要不断问自己一些问题。

用户的核心诉求是什么,这个功能点设计是否满足用户的核心诉求?

如果没有这个功能会怎样,用户还会不会使用这个产品?

想明白这俩问题,可能80%的功能都是没必要的,当然你说锦上添花好不好,请别一上来就搞,时间成本是最大的成本,相信我,很多你以为精妙的设计可能毫无意义。

谈完产品谈用户

前几天说了,你做一个新项目,一个创业公司,你要知道一点,不可能讨好所有用户,苹果公司够大吧,人家都压根没打算讨好所有人,对不起,我就不出998人民币的特价款,买不起的选安卓去吧。 所以,即便有些需求是用户定义的,有些痛点是用户提出的,你也要甄别一下,这是不是你核心目标用户的需求,这是不是你核心目标用户的痛点。 有时候,你甚至要为了让某些用户更满意,而伤害另一批用户,这个决定你敢不敢做!有没有价值!

我的观点是,如果为了发展更多的用户而伤害核心用户,是得不偿失的,很多公司犯过这样的错误;而为了核心用户去伤害一些其他用户,很多时候是正确的,你不能指望面面俱到,让每个人都满意。

举个例子,有人跟我说要做高端社交平台,想法是通过一些社交平台让普通人也能参加高端社交场合,这需求听上去很不错啊,普通人也想去高端场所,参与高端活动啊,找一些资源以廉价的方式提供给普通人的一些参与方案。但我一听就玩意就不行,啥叫高端社交,你搞这个你认识门卫保安或者举办方,你几个人私下靠关系凑进去了也就算了,你想规模化商业化,你开毛玩笑,这玩意一旦规模起来高端社交肯定变味,高端用户一定会极大反感,最后一定是高端用户见你就躲,高端活动唯恐跟你发生关系,你剩下一批普通用户自娱自乐么?你以为取悦了更多人,高端社交强调的是什么,私密性!准入门槛!

理解核心用户的诉求,理解核心产品诉求,再来理解项目管理。

说个小公司,项目快启动的一种思考方式。

我跟员工说,能不能启动个啥项目,员工说,这个,需要做什么什么,什么什么,什么什么,工作量蛮大的,算算大概6个月吧。我说3个月我要它上线,别跟我说工作量多大,按照3个月上线给我做排期,也不难为你,你说的那些,不一定都要做,你自己研究一下,非核心的都扔后面去,做到哪些最基本的就能上线了。然后我们拉出来测试调整。后来员工一直给不出3个月的排期,好吧,我自己也有些无能,这个项目就不了了之了。但我说句心里话,要是搁十年前,这事我一个人,最多两个月就上线了。(2005年,cnzz第一个版本的所有核心代码,其实就我一个人写了两周你们信不信。当然,那啥,写的时候有一些早期积累。不过所谓的早期积累也是不到一个月的工作量。当然,那时候的版本和现在相比,其实功能挺单薄的。)

什么思路呢,就是你先排工期,基于工期去优化产品设计,决定取舍,不追求说第一个版本的完美度,但是追求效率,并且保证核心功能在第一个版本都能充分体现,线上再根据反馈快速迭代。 大部分公司的研发都是先定需求后定工期,如果你先定工期后定需求,你会发现,其实很多东西并不是非做不可的。

这个思路历史上是来自日本的精益生产,在80年代的时候,made in japan以廉价质优产品快速打入北美,攻陷欧美市场,那时候日本厂家如何思考的呢,北美和欧洲都是我琢磨一个产品要做什么,然后计算成本,然后按照利润率,计算售价,然后标价出去卖。日本人把这个颠覆掉了,我要打败你,我先计算这个东西我准备卖多少钱,然后计算利润率,回推成本,然后我设计这个产品,我基于这个成本去做,没用的我砍掉,能裁剪的都裁剪,但保留强大的核心功能不能比你差,然后做出来产品,比对手便宜30%-50%,一下子把美国厂商打蒙了。这是成本反推的设计思路,在互联网时代,时间成本是最大的成本,所以,我们要以工期来反推设计,裁剪需求。

下面说技术的取舍之道

因为我做过统计,对这个比较熟,有个朋友当时要做个统计系统,他们员工做了几个月还没搞定,我就过去瞅瞅,一瞅就发现问题了,啥问题呢?为了根本不存在的需求较劲呢。

我们在做技术的时候,有时候产品给出的需求,只是一个使用说明,对于一些边界条件并不明确,而边界条件这玩意,对技术设计的复杂度和开发难度影响极大,极大,极大,极大。

实际上,技术人员应该明白应用场景的边界在哪里,有针对性的取舍,这样技术方案就可以变得简单,研发成本就会极大降低。

案例说话

无论是百度,谷歌,还是阿里,你去搜索的时候,你都不可能靠翻页遍历所有结果,翻到一定页数,就不给翻了,这就是边界条件。如果程序员非要较劲给出所有搜索结果的查询和排序,这就要命了,谷歌都做不到。 而潜台词是,其实真正的用户并不关心也不太会翻到七八十页去找结果。除非搜索结果很少才需要遍历,搜索结果很多的情况下给出权值最高的top列表即可,至于所有满足搜索条件的数字,其实只是一个系统估算值,根本没有去遍历搜索。

再拿统计说事,比如你是一个网站的站长,你要看网站的来源

如果这个来源是你特定的广告载体,你可以标注出来单独统计。

如果不是,你会去关心超过top 200的来源么?真的不会,站长只会关注最前面带给自己流量的网站和网页,不会关心一些奇怪的只有一两个点击的那些奇怪的来源,所以,站长不关心的数据,系统需要保存么?

理解这个思路,很多开发就简单了,至少你技术有限的情况下可以把很多看上去很复杂的项目搞定了。

允许不完美,允许设置一些边界条件,一定范围内降低准确度,存储量,来减少复杂度,这样开发效率就会极大提升,开发成本就会极大下降。

这个现象有多普遍呢?根据我的观察,开发人员做无用功,为不存在的需求而打拼得非常非常普遍,而这可能是很多公司老板,主管都不清楚的隐形成本。

再说典型场景,比如一些排名服务,你排第二,第三,第五,当然名次都很重要,但是你排50251,50252,50255, 这个具体数字对你重要么?告诉你排在50000-51000之间是不是就可以了? 很多技术设计如果稍微变通一下,复杂度就会极大降低。

2004年做一统,2005年做cnzz,我的开发时间都特别短,当然产品问题也不少,但没阻碍它们先后成为中国互联网统计平台的no.1。这事我做过总结,那时候我的技术水平实在不咋样,当然现在也没好太多,能做得快,而且在当时市场上表现力还不错,并不是因为我技术有多好,而是因为懂得取舍。这一点是很多大公司的程序员的盲区,所以他们用了几十倍甚至上百倍的代价,做同样的东西。

简单总结

1,从产品层面,对需求做裁剪,好的产品经理要会做减法,点子多,但落实起来,要围绕核心,初期不要过于复杂,有需要可以上线后根据用户反馈迭代。

2, 从用户层面,不要试图讨好所有人,要明确核心用户群体的诉求,有所取舍,让一部分人惊喜,另一部分人离开,比平庸四处讨巧的产品可能更好。很多优秀的互联网产品,都很固执和执拗,他们潜台词就是,不喜欢我的用户,我其实也不打算服务你们。

3,从技术层面,要理解需求,基于需求和研发的的难点设计边界条件,将需求简化,在满足用户核心诉求的前提下允许一定程度的不完美,允许一定程度的不精确。这样对研发效率的提升和运维成本的下降是惊人的。

一个不懂得取舍的系统,往往里面90%的数据和信息是在需求层面毫无意义的,有机会我会找一些案例出来,这样的真的见过很多。

本文来自公众号:caoz的梦呓
如有问题,请联系邮箱:980456099@qq.com

未经允许不得转载:财神见习社 » caoz谈能力成长 – 取舍之道

赞 (0) 打赏

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏