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%的数据和信息是在需求层面毫无意义的,有机会我会找一些案例出来,这样的真的见过很多。
- 转载请注明来源:IT学习网 网址:http://www.t086.com/ 向您的朋友推荐此文章
- 特别声明: 本站除部分特别声明禁止转载的专稿外的其他文章可以自由转载,但请务必注明出处和原始作者。文章版权归文章原始作者所有。对于被本站转载文章的个人和网站,我们表示深深的谢意。如果本站转载的文章有版权问题请联系我们,我们会尽快予以更正。