求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
 
  
 
 
 
什么是“成功项目”:谈谈软件的价值
 

2011-1-27 作者:熊节 来源:网络

 
     聪明的读者大概注意到了,前后两个故事讲的是同一回事,同样的两个项目。现在我的问题来了:请问哪个项目是更成功的项目?

  这个问题并不容易回答——实际上它没有标准答案。站在很多软件企业的立场上,项目 A 是一个理想的成功项目:按时间、按成本完成预先约定的任务。请注意,我用了“理想的”这个词,稍后我还会解释这个有趣的词,因为实际上的软件项目往往没有那么理想。

  而如果换一个角度,站在客户的立场上呢?也许付钱购买软件的客户会有一些不同的想法。项目 B 从开始之后一个月便交付了第一个可工作的版本,从那时起客户就开始使用这个软件的部分功能,并且不断地把自己使用的感受反馈给开发团队。在真实的业务运营过程中,客户甚至发现了一种新的盈利模式,并进行了一次大规模的业务调整,这次调整的结果也直观地体现在软件项目中。虽然项目B的整体交付速率低于项目 A,但它提供的所有功能都是客户真正需要的,它们为客户提供实实在在的价值——更不用说,客户提前好几个月就开始使用这个软件。

  实际上,这是一篇关于软件价值的文章。和“成功项目”一样,对于“软件的价值”,不同的人也会有不同的定义。不过作为付钱购买软件的客户,他对于软件价值的定义是一目了然的:他能够从使用软件中创造多少价值,软件能够为他的业务提供多少价值,这就是软件的价值。或者说得更简明一点:

  软件价值源自使用
     这正是为什么很多客户青睐“项目 B”的原因——我并不打算声称所有客户都有同样的观点,稍后我也会举出反例,但至少支持这一观点的客户不在少数。因为他们处在一个残酷而快速变化的商业环境中:他们的供应商在变化,他们的客户在变化,他们所处的经济环境和政策环境也在变化。这一切的变化迫使他们的业务也要随之变化。更要命的是,今天这个经济全球化的时代是一个“快鱼吃慢鱼”的时代,客户迫切希望新的软件系统为他们带来竞争优势——哪怕这个软件系统尚未完成,只要能够投入使用。最后,客户对于新的软件系统究竟应该是什么样子并没有百分之百的把握,他们的想法往往要在真正使用软件之后才会浮现成型。几方面的因素加在一起,使得这些客户更愿意尽快开始使用软件、提出反馈、并不断完善软件,而不是提出一组需求、然后坐等几个月之后原封不动地拿到这些功能。

   一个真实的案例

  在 ThoughtWorks 的一个项目中,开发者们在项目开始之后一个月内就发布了第一个版本——只有一些简单的数据采集功能。在发布展示会上,发生了这样的对话……

  开发者:这是我们的第一个功能。我们从文本文件、Excel 数据表和遗留数据库采集数据,现在我们的数据库中有这些数据……(展示数据库结构)
客户:唔……有意思。要是你能做这样一个查询(写出查询要求),得到的结果可能会有用。
开发者:可是我们的界面上没有地方做这样的查询操作。
客户:啊,我不需要操作界面,只要每天深夜做一次查询,把报表发到我的信箱就可以了。
开发者:这样吗……另一个问题是,这需要花我们几天时间。
客户:不要紧,把别的任务往后放几天好了,我很想看到这份报表。
开发者:那好吧,下周我们就会开始提供这个报表。
猜猜结果怎么样?一周之后客户就开始每天接收这份报表,并根据报表内容做一些分析和决策。仅仅几个月之后,这份报表给客户带来的收益就已经超过了整个项目的投资——这时项目其他部分的开发甚至还没有完成。

  想想这个客户会怎么定义一个“成功的软件项目”?好吧,也许这个项目超过了预期的时间,也许投入了更多的人力,但这些并不意味着“项目失败”——只是付出更高的成本。关键在于,他投入的这些成本能够带来多大的收益,他的投资回报率是否划算。对于这个客户而言,如果项目能够随时给他提供可用的、能够创造最大价值的软件,能够随时让——就像故事中提到的——这种有价值的想法得以实现,这就是一个成功的项目。

  所以,亲爱的读者,请你忘记本文标题上出现的“敏捷”二字,我们在这里所说的不是别的,就是一种为客户创造最大化价值的软件开发方法。这样的方法有很多种,但它们有一个共同的特点:尽快、尽可能频繁地交付可以工作的软件,让客户尽快开始使用软件,从使用中创造价值、厘清思路、提出反馈。仍然以 ThoughtWorks 的项目为例,这些项目通常在启动开发阶段之后一个月内就会发布第一个版本,随后每一周或每两周发布一个新版本——每个版本都是一个可以工作的软件,每个版本都比前一个版本具有更丰富的功能,并且每个版本都包含客户认为迄今为止最有价值的那些功能。用软件开发的“黑话”,“开发下一个版本”的过程叫做“迭代”,这些开发方法最大的共同点就是“迭代式开发”——不是一股脑地交付全部功能,而是每次增加一点、渐进地交付最有价值的功能。

  软件开发的梦想与真实

  回到文章开始处的两个故事。我曾经说过,对于很多软件企业而言,项目 A 是一个“理想的”成功项目。那么,是什么让情况变得不那么理想?

  答案是一个所有软件开发者耳熟能详的词:需求变更。在真实的项目中,客户通常不会等到最后一天再照单全收整个项目,因为他知道自己的业务正在发生变化。这时需求变更就出现了,伴随着来回的扯皮和讨价还价。更糟的是,大量的需求变更发生在项目晚期——因为直到这时客户才真正看到、使用到这个软件,他的很多想法才真正浮现成型。随着这种“最后一分钟的需求变更”,项目超期、超出预算也就成了家常便饭。能够像项目A这样完工交付的,实在是凤毛麟角的幸运儿。

  为了对付需求变更这个噩梦,软件开发者们还发明了另一个词:变更控制。这个有趣的词暗示着:需求变更是一种“不好”的东西,是需要“控制”的东西。然而站在客户的角度上想想,他在亲身使用了软件之后提出的要求,难道不是最有价值的东西吗?把这种真正创造业务价值的要求“控制”起来,难道是合理的吗?

  在前面我也暗示过,并非所有的客户都一定青睐迭代式开发。那么,哪些软件项目不一定需要迭代式开发呢?从整篇文章的内容不难看出,如果客户的业务绝对不会变化,如果客户的需求巨细靡遗非常明确,如果客户不需要尽快开始使用软件以便收回成本,那么迭代式开发对他的帮助就会小得多。不过,如果读者认真思考的话,这样的例子也许并不多——也许比你最初认为的要少得多。一个很好的例子是“神州六号”火箭使用的计算机控制系统。还有多少这样的例子?读者不妨试着自己想想。

  如果我足够幸运的话,也许一些读者已经被这篇文章吊起了胃口:既然有这么好的软件开发方法,既然它能够为我们创造更大的价值,那还等什么呢,我们马上就动手吧。事情不会那么简单。为了让迭代式开发能够成为现实,为了确保尽快、尽可能频繁地交付,为了确保每次交付的都是最有价值的功能,我们——包括软件开发者、软件企业和客户——需要很多的改变。这里既有职责与权利的划分,也有开发过程和团队的重组,还有技术层面的实践指导。这些正是敏捷方法学所涵盖的内容。缺少了这些东西,“为客户创造最大价值”就只能成为一句空话。在后续的文章里,我们将结合 ThoughtWorks 的实践经验,逐步介绍敏捷方法的方方面面。

  9 条回复关注此讨论 回复

  果然 发表人 Li Cao 发表于 2007年3月28日 上午11时56分
软件价值源自使用 发表人 胡 键 发表于 2007年3月28日 下午7时15分
能否介绍一下,敏捷在产品研发中的经验? 发表人 Cao BaoZhen 发表于 2007年3月28日 下午10时39分
Re: 能否介绍一下,敏捷在产品研发中的经验? 发表人 Xiong Jeff 发表于 2007年3月29日 下午11时25分
交流最重要 发表人 张 风南 发表于 2007年3月29日 上午4时54分
Good 发表人 Hailong Zhang 发表于 2007年3月29日 上午5时35分
有个问题想交流一下 发表人 liu df 发表于 2007年4月1日 上午1时2分
Re: 有个问题想交流一下 发表人 zhu pan 发表于 2007年4月1日 上午7时49分
商务上的问题 发表人 ke cake 发表于 2007年4月21日 下午7时31分
按日期倒序排列
返回顶部
果然
2007年3月28日 上午11时56分 发表人 Li Cao

  成功的项目就是能赚到钱的项目——双赢

回复
软件价值源自使用
2007年3月28日 下午7时15分 发表人 胡 键

  “软件价值源自使用”,这句话说得太好了。

回复
能否介绍一下,敏捷在产品研发中的经验?
2007年3月28日 下午10时39分 发表人 Cao BaoZhen

  能否介绍一下,敏捷在产品研发中的经验?
产品研发的每个版本都用固定的需求,而敏捷需要的是变化。
敏捷中哪些地方可以引用到产品研发中呢?

回复
交流最重要
2007年3月29日 上午4时54分 发表人 张 风南

写的不错,期待以后的文章~

回复
Good
2007年3月29日 上午5时35分 发表人 Hailong Zhang

挺不错的文章

回复
Re: 能否介绍一下,敏捷在产品研发中的经验?
2007年3月29日 下午11时25分 发表人 Xiong Jeff

  能否介绍一下,敏捷在产品研发中的经验?
产品研发的每个版本都用固定的需求,而敏捷需要的是变化。
敏捷中哪些地方可以引用到产品研发中呢?

  关于产品研发中的敏捷经验,请看敏捷中国的相关讨论:
groups.google.com/group/agilechina/browse_threa...

回复
有个问题想交流一下
2007年4月1日 上午1时2分 发表人 liu df

文章中提高的客户互动当然是理想的(针对客户的),但是忽略了一点:开发团队的利益。
从中国目前的项目实施上来说,基本上都是系统上线验收后才付费的。呵呵,这样看来,如果客户的需求不断变化,那么就始终无法验收了,那么开发团队的成本如何维持呢。希望能够就这个实际问题的解决方案探讨一下,否则话题就有些流于理想了。

回复
Re: 有个问题想交流一下
2007年4月1日 上午7时49分 发表人 zhu pan

  这个我也想搞清楚,用户的需求变更可能是无尽的,但是money不可能无尽地给,什么时候结束迭代呢?

回复
商务上的问题
2007年4月21日 下午7时31分 发表人 ke cake

  如果项目的需求频繁变更,企业如何保证能够从项目中盈利?商务合同该如何签?



如何有效地进行项目沟通
如何进行项目计划及质量管理
IT项目风险管理案例和应对之道
组建高效快速研发团队的必要
一个甲方项目经理的自白
TFS使用指南


软件项目管理
软件开发项目管理
研发项目管理
高级项目管理实战
敏捷项目管理实践
项目风险管理

相关咨询服务
建立项目管理规范


中国银行 IT外包项目管理
北京软件项目管理
某电子软件中心 项目外包管理
某电信服务商 项目外包管理
富士 软件外包项目管理与进度
Schneider 项目管理+软件质量
中国电信 软件项目管理