请选择 进入手机版 | 继续访问电脑版

项管先锋论坛

 找回密码
 立即注册

QQ登录

只需一步,快速开始

查看: 1415|回复: 0

软件价值源自使用

[复制链接]

210

主题

210

帖子

903

积分

超级版主

Rank: 8Rank: 8

积分
903
发表于 2016-7-11 15:02:57 | 显示全部楼层 |阅读模式
来自:网络

5 s( W* {0 |+ f4 H" x5 M( K. y- N! e! C  x3 b* H$ F

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

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

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

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

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

  一个真实的案例

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

  开发者:这是我们的第一个功能。我们从文本文件、Excel 数据表和遗留数据库采集数据,现在我们的数据库中有这些数据……(展示数据库结构) 6 u9 J2 G+ c) b! R* n1 A
客户:唔……有意思。要是你能做这样一个查询(写出查询要求),得到的结果可能会有用。 ; ?+ c3 @' K4 {( t
开发者:可是我们的界面上没有地方做这样的查询操作。
' x$ J* v% h  Z' m客户:啊,我不需要操作界面,只要每天深夜做一次查询,把报表发到我的信箱就可以了。
- W2 z. z# \% g0 t" {开发者:这样吗……另一个问题是,这需要花我们几天时间。 * U9 a6 N2 g( x) |+ M
客户:不要紧,把别的任务往后放几天好了,我很想看到这份报表。 ! I/ ?: z* L6 h; g/ W
开发者:那好吧,下周我们就会开始提供这个报表。
2 A- q* M1 n( y- q猜猜结果怎么样?一周之后客户就开始每天接收这份报表,并根据报表内容做一些分析和决策。仅仅几个月之后,这份报表给客户带来的收益就已经超过了整个项目的投资——这时项目其他部分的开发甚至还没有完成。

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

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

软件开发的梦想与真实

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

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

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

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

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

  9 条回复关注此讨论 回复

  果然 发表人 Li Cao 发表于 2007年3月28日 上午11时56分 2 C- X6 W6 [- H5 m% \* T
软件价值源自使用 发表人 胡 键 发表于 2007年3月28日 下午7时15分 ; b$ X) S+ e& @" ]8 g% I/ ]) _
能否介绍一下,敏捷在产品研发中的经验? 发表人 Cao BaoZhen 发表于 2007年3月28日 下午10时39分 ' ]: E5 a+ C3 T% U% L+ i7 i  g
Re: 能否介绍一下,敏捷在产品研发中的经验? 发表人 Xiong Jeff 发表于 2007年3月29日 下午11时25分               
项目经理3 K1 }& B5 v# T* C( T
交流最重要 发表人 张 风南 发表于 2007年3月29日 上午4时54分 9 x$ q0 i3 Q1 ]4 p3 O3 j# R
Good 发表人 Hailong Zhang 发表于 2007年3月29日 上午5时35分 + ]4 y$ u- ^: ~5 z8 _6 p# |5 ^
有个问题想交流一下 发表人 liu df 发表于 2007年4月1日 上午1时2分
8 Q4 j5 a3 e# z, @Re: 有个问题想交流一下 发表人 zhu pan 发表于 2007年4月1日 上午7时49分
; o: U0 i0 n# S$ t8 h1 g商务上的问题 发表人 ke cake 发表于 2007年4月21日 下午7时31分 3 C& t8 g9 S7 d' ?7 V& I, d" ]
按日期倒序排列 9 ]( b" V2 N8 G) g% z1 `0 c$ X* y
返回顶部 / y5 |% ^2 \4 q  P* M8 v
果然
- U7 M9 J1 h& ^& Z( W$ n: n7 h6 [2007年3月28日 上午11时56分 发表人 Li Cao

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

回复& {1 {3 e- |: z' B- G0 L) X* E* P
软件价值源自使用
- y& A4 F. w' f/ b- J3 s2007年3月28日 下午7时15分 发表人 胡 键

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

回复( r8 a, ^/ O8 z
能否介绍一下,敏捷在产品研发中的经验?
$ w- j1 {- |) K2007年3月28日 下午10时39分 发表人 Cao BaoZhen

  能否介绍一下,敏捷在产品研发中的经验?& e1 {$ @9 }. D7 v4 Y/ o+ k. B
产品研发的每个版本都用固定的需求,而敏捷需要的是变化。% ?8 k; M2 V. b" p& d: q
敏捷中哪些地方可以引用到产品研发中呢?

回复+ T# k4 j; f& h" y; E
交流最重要
+ t8 e; I: p. x& ~0 n) r2007年3月29日 上午4时54分 发表人 张 风南

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

回复
0 W# f6 |, w: k4 E; }4 OGood6 F+ P* x4 P/ p2 m& n3 @: ~& T- J1 x
2007年3月29日 上午5时35分 发表人 Hailong Zhang

挺不错的文章

回复
8 i* |) z3 V* D! |Re: 能否介绍一下,敏捷在产品研发中的经验?
; M1 \: e& T" h: i& |. e3 g2007年3月29日 下午11时25分 发表人 Xiong Jeff

  能否介绍一下,敏捷在产品研发中的经验?. g* J# a; `. [3 c( ]6 H0 A; F
产品研发的每个版本都用固定的需求,而敏捷需要的是变化。
6 g9 K( L/ A+ U敏捷中哪些地方可以引用到产品研发中呢?

  关于产品研发中的敏捷经验,请看敏捷中国的相关讨论:6 n, X) B3 P4 Y* J: t, G4 K
groups.google.com/group/agilechina/browse_threa...

回复5 [; l$ k  d& i  ?9 Y& L5 b
有个问题想交流一下
: [& o( C* I7 L7 d& c3 K* ^2007年4月1日 上午1时2分 发表人 liu df

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

回复
) T+ x- z, b/ }8 N% WRe: 有个问题想交流一下) ~* G. q3 W5 H0 Q& u3 O7 i
2007年4月1日 上午7时49分 发表人 zhu pan

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

回复4 x! S, E0 K* f6 q
商务上的问题, Q) ~* i& u3 Z' }
2007年4月21日 下午7时31分 发表人 ke cake

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


) p7 L2 E$ G, X1 f( {7 N
3 d+ _" D8 f# \- @% V$ A
: |7 I% w9 \5 c; }
* U& s6 a# z1 h3 `
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

小黑屋|手机版|Archiver|项管先锋论坛  

GMT+8, 2020-8-15 19:08 , Processed in 0.080734 second(s), 23 queries .

Powered by Discuz! X3.4

Copyright © 2001-2020, Tencent Cloud.

快速回复 返回顶部 返回列表