有感于产品经理的技术意识

下午头回参加了UCDChina厦门分舵的活动,主讲是4399的CTO, caoz大湿。
内容大约是这样的。当然以下内容加进了个人理解。

产品经理是提需求的。需求提了,技术常说,我实现不了,或是很难实现。点解?问题在于阐述问题上。

产品经理的东西是文档,我要做一个某某列表功能,这个列表里要有啥啥啥。但工程师要把它转成代码前,要有数据库设计。而数据库设计的前提,就是理解产品经理给出的文档里,都讲了哪些东西,这些东西在哪些地方应用到,甚至于,将来会在什么地方应用到,应用的频度是多少。因为这些场景中对于这些对象的使用,反映到最终的代码里,可能是天差地别的。

下午举了一个feed的推拉的例子。如果我在大学期间,我只能提出拉的方法。而在什么情况下提出“推”的方案呢?场景不同了。在大学期间我接触到的数据无比之小,几个人,几十人使用的网络工具而已,用拉的方案完全可以解决问题。但如果这个数字放大为几百万呢?技术场景不同,于是才有了“推”,甚至于“推拉结合”的方案来。
在产品的角度看来,似乎只需要提出“用户登录之后看到我和好友的Feed”这一句话即可,但如果能考虑到这个功能的应用场景:名人可能有数百万的用户,这百万的用户中,有20%在当天是有登录的。30%是当周有登录一次的。这样细分,技术面就能提出更合理的解决方案来。

下午又举出一个例子,是搜索用户的。通过用户名来搜索用户。
这个搜索框里填的是什么?根据什么条件来搜索?在new.my.4399.com只提供了按用户名的前缀来查找的方式。好吧,如果你懂得SQL,你会知道,我可以用LIKE %username%,这样来搜索啊。但如果把用户的数量放大到一个亿呢?facebook可是有5亿的用户哦。这时候需要产品和技术来协商,是不是真的要“非常模糊”地搜索。我需要满足到什么层面的需求就OK了。换句话说,如果技术不能解决的事儿,产品设计上能不能做调整。

嗯,还有,下午还拿了小鱼的全文搜索来说事儿。讲第三方的全文搜索引擎。还好小鱼已经改用sphinx的,不然就糗大了。

其实下午讲的产品,还是有点偏技术面。包括冗余、反范式、NoSQL的应用,这些技术上的东西,实际都是在特定的应用场景下会发生的事情。单纯的编码人员的确会难以判断应用场景,从而使用“最懒”“最容易实现”的方式。结果很可能是,在产品经理提出修改的时候,或是用户量增长、流量增长的时候,这时候工程师就犯难了。因为产品、技术双方没有充分沟通好,我们做的产品,是怎样的一个东西,都有哪些人在什么环境下使用的。

caoz推荐产品人员去和技术沟通,查看他们设计出来的数据结构是什么样的。但我更推荐技术人员去学习产品运营的知识。个人觉得产品、运营方面的知识,比一堆鸟语描述的算法、堆栈、缓存、索引神马的相比,实在是容易多了。

麻婆说过,不想当CEO的程序员不是好产品经理。名言啊。

Copyright © 2011. All Rights Reserved.

发表评论

电子邮件地址不会被公开。 必填项已用*标注