迭代

michael's picture

为什么说在当下快速迭代是伪命题?

在这个“万众创新,全民创业”的时代,一种大跃进的情绪充斥在投资者和创业者中间,进而传递到技术部门。我听到最多的一句话就是,‘你赶紧开发出来吧,否则这个点子就被别人做出来了’。无论是我们自己的项目还是客户的项目,可能都有这个问题。当有声音说‘我们还是设计好再开发吧’的时候,我们马上就会听到另外一个声音‘哎呀,先做好,然后再迭代呗’。迭代,多高大上的词啊,高大上怎么会错呢。

但实践下来,我看到程序员们不是在迭代,而是在天天救火(debug),当然有人会称这种工作叫“迭代”,因为功能还是天天在修改的啊。但有经验的工程师或项目经理也或者是产品经理请回忆一下,一个本来计划3个月的项目,最后是如何做了一年的呢?这一年的时间里面,是不是在粗糙的漏洞百出的产品或网站出来之后才真正进行思考的呢?如果一开始就说你的项目需要一年,对方能接受吗?有了这样的糟糕的经验,投资者还敢去做下一个IT项目了吗?

以“迭代”为借口,省去了设计与架构的做法是非常可怕的。会浪费投资者的钱和机会成本,浪费开发人员的时间,损伤整个项目团队的士气,如果是一个项目公司,还会大大伤害公司的口碑,甚至造成人才的流失。

如果开始的时候我们没有设计,或过于粗糙的设计,程序员做了一把椅子出来,但实际上你要的是一个长凳,然后怎样呢?迭代?!Come on,一把椅子变成一个长凳,就算成功了,我想还不如直接做一把椅子。我也见到过有一个客户,为了节约成本,找了两次soho,做出来了2个产品,外表看起来像那么回事,但他承认都有致命的bug,而程序员已经放弃了。我对他说,你这个预算没有考虑到架构和设计的成本,我也放弃,我不想浪费我们彼此的生命,活着是为了做出一些能够用的东西,我的精力和时间不是用来浪费的,哪怕你付钱给我,我也不会接受这种浪费。

一个做了一年的痛苦的项目,实际是因为要把一把椅子迭代成一个长凳的痛苦过程,但如果一开始设计好了长凳,可能只要3个月,一切都妥妥的。省下来的时间价值多少钱呢?

 

 

 

 

更多
michael's picture

为什么说Drupal更适合MVP(最小化可行产品)开发

昨天去参加了在漕河泾移动互联网经验分享会,感觉收获挺多的,尤其是V部落的创始人的演讲。说到MVP(最小化可行产品)开发,其核心思想是,开发产品时先做出一个简单的原型——最小化可行产品(Minimum Viable Product, MVP),然后通过测试并收集用户的反馈,快速迭代,不断修正产品,最终适应市场的需求。演讲者说道了他们的产品开发的心路历程,首先想了很多东西,然后发现很多东西客户并不喜欢,因为能够触及客户痛点的问题你可能并没有解决好,于是从1.0到3.0的过程就是一个做减法的过程,想想dropbox、facebook、google、Uber这些成功的创业原型,他们的商业模式都是从解决简单的一个单一的痛点开始的,所以都十分有效,而他们后来加上去的很多产品和功能都表现平平,可见精益创业是一个非常有效的方法。

那这种方法为什么说更加适合用drupal来开发产品原型呢?原因就是Drupal不是一个CMS(内容管理系统),而是一个CMF(内容管理框架),既然MVP要求你不停的去迭代,那么drupal就比joomla更加适合,因为drupal的module一般都不直接解决一个商业问题,而是解决了商业问题的一个步骤,用这些步骤你就可以构建一个商业问题的解决方案,或者说Drupal更加灵活,既是现有的框架又可以专业的灵活的构建,比如很多人推崇的OpenAtrium就是通过很多Drupal中已经存在的module搭建的。

创业这几年来,我们从来也没有成功的跟一个非精益创业的客户成功合作过,比如一个客户上来就跟我们说,我要做一个淘宝+微博+QQ的平台,我们说做不了,他说不是很简单吗?我们有钱,但有钱真的就可以任性吗?多少企业巨人投资过很多项目也都失败了啊,比如百度的有啊,比如谷歌的wave,比如施乐投资的PC,你必须解决一个痛点,不能说目前啥好做做啥,这是对自己不负责啊。

有点扯远了,总的来说,你要想迭代出一个优秀的原型,Drupal真的很适合啊。

 

更多
订阅 RSS - 迭代