项目管理资源网

您的位置:项目管理资源网 >> IT通信项目管理

案例分析:软件项目的价值

2018/12/26 14:20:01 |  308次阅读 |  来源:网友转载   【已有0条评论】发表评论

够创造最大价值的软件,能够随时让——就像故事中提到的——这种有价值的想法得以实现,这就是一个成功的项目。

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

  2、软件开发的梦想与真实

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

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

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

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

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


    项目经理胜任力免费测评PMQ上线啦!快来测测你排多少名吧~

    http://www.leadge.com/pmqhd/index.html

“项目管理生根计划”
企业项目经理能力培养和落地发展方案下载>>

分享道


网站文章版权归原作者所有,如有认为侵权请联系我们,将于1个工作日内作出处理!
网友评论【 发表评论 0条 】
网友评论(共0 条评论)..
验证码: 点击刷新

请您注意护互联网安全的决定》及中华人民共和国其他各项有关法律法规或间接导致的民事或刑事法律责任
·您在项目管理资源网新闻评论发表的作品,项目管理资源网有权在网站内保留、转载、引用或者删除
·参与本评论即表明您已经阅读并接受上述条款