《产品研发过程实践》(2)要做吗
作者:asky 日期:2007-04-29
首先先明确一个概念:什么是产品?我想这个问题令很多人很挠头,在我们(特别是高层主管们)需要融资的时候,任何项目都是产品,但是我们故意地忘记了不同客户之间所存在的惊人的需求不同性;在我们(特别是开发人员)需要放弃一个产品的时候,我们故意地不去想想该如何走下一步而只是看见他的不足;至于项目经理和产品经理,口中所说的,和心中所想的,很大可能上存在着不同,而且这一点随着他看了几本新书或者听到几个新观点,都在随时随地地发生着改变,这不是由于项目经理和产品经理具有的惊人的不真诚,而是首先因为他认为这个产品(或者项目)是他的孩子,他对他非常珍惜,其次在现实中,项目或者产品表现出来的越来越多令人烦恼的事情,不断冲击着项目经理的自信心。对此,我不想说太多太多的纯学术性的话(说实在话,这些话多少让我感觉有点隔靴搔痒,感觉什么都对,但是操作性不强)。我记得在2003年的年初,很多同事在一个京郊的度假村里就这个问题讨论了至少2个小时,结论是:是由A团队开发,但是可以由B团队独立实施部署的软件。这个定义当然是不完全的。但是这句话给我的印象非常深刻,他第一次比较可操作地指出了项目和产品的不同。也许有更好的定义。但是我在这两年中,一般都用这个来衡量自己所做的是项目,还是产品。
OK,说明白了产品,在我们进入正题之前,先讲一个小故事。
有一个故事,一个人想要砍树,于是他想到我需要一把斧子,于是开始兴致勃勃地开始制作斧子;然后发现需要铁,然后发现需要炼铁,需要一小块木头做为斧头的柄,同时为了告诉别人,这个斧头是自己的,于是开始在斧头上雕琢一些花纹,开始在木头上刻上自己的名字……最后,当这个哥们干着和砍树八杆子打不到的工作的时候,别人问他,你干什么呢?他回答说:“……”。如果你看见这个人,你会如何想,一定认为他思路涣散,这样的工作一事无成吧。但是我们自己呢?这种错误还少吗?
太多太多了,大家自己多少能够举出几个例子,在项目后期忘记项目初衷是什么的情况吧。产品成了一个典型的大而全的产品,什么功能都在里面,但是初始的时候我们仅仅想帮助用户解决一个小小的问题。我们倾向于做很多很多的事情,但是忘记了一点:系统越是庞大,出现错误的可能性越高,在用户还没有接受这个产品之前,添加过于得多的功能,无异于在要跑马拉松的时候,把所有的东西都背上。
产品首先要解决的问题是:这个产品值得做吗?需要我们去做吗?绝大多数产品的一个起因实际上很简单,是一个Idea(顺便说一句:判断一个人不是夸夸其谈的人也许不容易,但是符合以下这条,就一定是个胡扯的人:可以靠着Ideas成功。Ideas的确重要,但是只是成功的诸多要素中的一个,就象我们不能因为吃饭在人生中不可或缺,就说人生的全部意义在于吃饭一样。)或者一个两个重要客户提出的不足;或者是由于自己在研发过程中,发现某一种具备共性的东西,需要抽取出来。基本上我看见的起因就是这些了。我想应该没有人因为自豪感的驱动就开始做一个莫须有的产品吧。如果有的话,真的让我很佩服,在这个商业的社会中,具有超人的自豪感和自信心,总是让人敬佩的。
我们需要记住,任何功能或者Ideas都是有其合理性的,但是并不是我们在目前就需要做所有我们想到的产品的(比如至少我现在就不会去做一个业务代码生成器,首先因为这将直接干掉中国80%程序员的饭碗,其次我不认为目前我们对于业务系统就那么了解,并且我不认为所有的企业都需要按照一个IT人员的框架来规划自己的业务流程)。那么我们如何界定一个产品是否值得做呢?如果是我,我将会从以下着手进行分析(这在后面会一点一点介绍)。
当然,使用以下这些分析方法,并不能保证你的分析结果就一定正确(这一点谁也无法保证,如果谁说能够保证,那么只有两种可能,要么是他是一个真诚的白痴,要么就是惊人的不真诚),我更愿意把这些分析方式看成一种决策管道,由这些决策管道来辅助你搜集信息,有条理地进行决策。也就是所谓的决策方法和过程(插一句,我看过的关于最好的决策方面的书,是兰德公司的《决策》一书,大量的案例分析和决策原则,让2000年时候的我,受益匪浅。那本书是我在从上海飞北京的时候,在候机大厅中买的,当时让我如饥似渴地用了2天阅读完毕。我现在还能想起当时那种阅读的感觉,真的很美妙,很新奇,就象眼前打开了一扇门,发现了一个以前从来没有发现的好宝藏)。原因仅仅在于,无论哪种决策方法,都不会告诉你一些权重应该如何设定(也许有一些基本的数值的经验值,但是是否使用这个经验值或者前提条件是否成立,还是需要你主观的评价),于是很多决策方法,不过是你通过一定的决策手段,来达到自己的主观判断。之所以使用这些决策方法,只是为了在你做出决策的过程中,通过分析过程,来发现一些你原先没有考虑到的东西。其次,如果你向上级汇报或者申请更多资源的时候,请务必使用业界公共使用的决策方法,这将使得你看起来很专业,会为你期望的结果加上重重的一笔。
OK,说明白了产品,在我们进入正题之前,先讲一个小故事。
有一个故事,一个人想要砍树,于是他想到我需要一把斧子,于是开始兴致勃勃地开始制作斧子;然后发现需要铁,然后发现需要炼铁,需要一小块木头做为斧头的柄,同时为了告诉别人,这个斧头是自己的,于是开始在斧头上雕琢一些花纹,开始在木头上刻上自己的名字……最后,当这个哥们干着和砍树八杆子打不到的工作的时候,别人问他,你干什么呢?他回答说:“……”。如果你看见这个人,你会如何想,一定认为他思路涣散,这样的工作一事无成吧。但是我们自己呢?这种错误还少吗?
太多太多了,大家自己多少能够举出几个例子,在项目后期忘记项目初衷是什么的情况吧。产品成了一个典型的大而全的产品,什么功能都在里面,但是初始的时候我们仅仅想帮助用户解决一个小小的问题。我们倾向于做很多很多的事情,但是忘记了一点:系统越是庞大,出现错误的可能性越高,在用户还没有接受这个产品之前,添加过于得多的功能,无异于在要跑马拉松的时候,把所有的东西都背上。
产品首先要解决的问题是:这个产品值得做吗?需要我们去做吗?绝大多数产品的一个起因实际上很简单,是一个Idea(顺便说一句:判断一个人不是夸夸其谈的人也许不容易,但是符合以下这条,就一定是个胡扯的人:可以靠着Ideas成功。Ideas的确重要,但是只是成功的诸多要素中的一个,就象我们不能因为吃饭在人生中不可或缺,就说人生的全部意义在于吃饭一样。)或者一个两个重要客户提出的不足;或者是由于自己在研发过程中,发现某一种具备共性的东西,需要抽取出来。基本上我看见的起因就是这些了。我想应该没有人因为自豪感的驱动就开始做一个莫须有的产品吧。如果有的话,真的让我很佩服,在这个商业的社会中,具有超人的自豪感和自信心,总是让人敬佩的。
我们需要记住,任何功能或者Ideas都是有其合理性的,但是并不是我们在目前就需要做所有我们想到的产品的(比如至少我现在就不会去做一个业务代码生成器,首先因为这将直接干掉中国80%程序员的饭碗,其次我不认为目前我们对于业务系统就那么了解,并且我不认为所有的企业都需要按照一个IT人员的框架来规划自己的业务流程)。那么我们如何界定一个产品是否值得做呢?如果是我,我将会从以下着手进行分析(这在后面会一点一点介绍)。
当然,使用以下这些分析方法,并不能保证你的分析结果就一定正确(这一点谁也无法保证,如果谁说能够保证,那么只有两种可能,要么是他是一个真诚的白痴,要么就是惊人的不真诚),我更愿意把这些分析方式看成一种决策管道,由这些决策管道来辅助你搜集信息,有条理地进行决策。也就是所谓的决策方法和过程(插一句,我看过的关于最好的决策方面的书,是兰德公司的《决策》一书,大量的案例分析和决策原则,让2000年时候的我,受益匪浅。那本书是我在从上海飞北京的时候,在候机大厅中买的,当时让我如饥似渴地用了2天阅读完毕。我现在还能想起当时那种阅读的感觉,真的很美妙,很新奇,就象眼前打开了一扇门,发现了一个以前从来没有发现的好宝藏)。原因仅仅在于,无论哪种决策方法,都不会告诉你一些权重应该如何设定(也许有一些基本的数值的经验值,但是是否使用这个经验值或者前提条件是否成立,还是需要你主观的评价),于是很多决策方法,不过是你通过一定的决策手段,来达到自己的主观判断。之所以使用这些决策方法,只是为了在你做出决策的过程中,通过分析过程,来发现一些你原先没有考虑到的东西。其次,如果你向上级汇报或者申请更多资源的时候,请务必使用业界公共使用的决策方法,这将使得你看起来很专业,会为你期望的结果加上重重的一笔。
评论: 0 | 引用: 0 | 查看次数: 3934
发表评论
你没有权限发表评论!