UML软件工程组织

报价阶段预估项目时程与成本密技 
独孤木
出处 http://www.javatwo.net/javaweek/ 
关于如何预估软件项目的时程与成本,比起许多做研究的人来说,我应该可以算得上是个权威。因为我曾经看过业务人员如何进行报价,也曾经在我的手上,估计出不少项目的时程。许多提供各式各样数学模型的人,从来没有实际地做过任何与报价有关的工作。
对于一个没有经验的人来说,项目的成本,大概可以用这样的一句话来表示:
项目的成本 = 客户打算花在这个案子上的预算

当然,项目的时程就复杂的多了,否则怎幺会有办法估计出绝大多数都会落后的时程呢?所以这需要非常繁复的计算。原则上,需要等到项目的成本经过上述公式估计出来以后,再透过详细的分析与计算,才可以估算出正确的时程。这种繁复的程序,经过最佳化之后,可以透过下列的方法计算出来:
项目所需耗费的人月 = 项目的成本 / 每个人月的平均成本
项目的时程 = 项目所需耗费的人月 / 要排在这个项目里的人头数量

当然,对于一个专家来说,这简直是太过低估这项工作的困难程度,也忽略了软件工程学中,针对这个问题所写出数以万计的论文。根据我非凡的智力以及超高的经验值所得到的结论,我觉得预估项目的预算与时程最少还包含下面几项困难度超高的工作项目:
在客户的部门中,建立良好的内线,以掌握客户的预算以及实际竞争厂商的报价
依据实际竞争厂商的报价,调整报价或是替内线建立一套为何要把项目给我们时,可以在内部自圆其说的说辞

推荐适合的陪榜厂商,以及建议适当的规格标以进行绑标,其实是在争取项目进来之前就应该要做的功课。在通过资格审查之前,就应该在客户的部门中,建立起适当的内线;不管是透过同学的同学,朋友的朋友,还是透过酒店小姐的帮忙,都得要与承办人员或是客户部门具有影响力的主管建立起一种休戚与共的关系。

然而在通过资格审查之后,业务人员最重要的工作,就是要帮辛辛苦苦建立起来的内线,准备一套说辞,以证明把项目交给我们来做,是最合理的解释。这件事实在是太重要了,所以在此我大概列举几个常用的思考方向:

首先是要确定,要怎幺样导引客户的想法。当你具有合约总价上的优势时,就建议客户从成本的观念来考量;如果你的金额比竞争对手高时,你可以先把项目的单价降低,然后把维护部分的成本提高,接着在合约里面藏着一些陷阱,让客户一定要买你的维护服务,接着再建议客户从成本的观念来考量;或是把维护合约的成本降得非常非常低,建议客户从总持有成本的观念来思考,然后在合约中暗藏几个陷阱,让维护合约适用的范围变得非常非常小,以降低会受到的伤害。

当你的客户拥有非常精明的老板,以至于你根本不敢在金额方面玩花样时,或是当金额上可以做的手脚都做完了,总价还是高人一等时,这时候应该强调你的科技、品质、相关领域的经验与知识…任何你觉得可以赢过竞争厂商的地方。

如果你在金额上毫无竞争力,各个领域又与竞争厂商没有办法相比时,这时候整个说帖的重心,则在于诉诸形而上的东西,例如我们比较用心,我们比较脚踏实地、我们拥有比较高的服务热忱…这种没有办法评量的东西。

如果你在导引客户想法的部分失败的话,最后一招就是散布不实的谣言,这时候的重点,就从如何引导客户的想法,转而变成要怎幺样才能把客户骗死。几个比较常见的说法是,听说XX公司目前面临很严重的财务危机,公司可能会面临倒闭、听说XX公司目前人力资源严重不足,所有的人手都被调去支持更重要的案子、听说XX公司先前做过的OO项目,速度超级慢、听说先前做过的OO项目,delay了快要两年,到现在还没有结案…

当你绞尽脑汁再也想不出什幺说帖来的时候,这个时候,就需要比较建设性的方法,例如下面的做法:
白烂公司想要建立一个Enterprise Portal,经过了漫长的资格审查,目前只剩下两家厂商,目前正在进行商议价格的阶段。本田与威尔刚好是分属两家不同公司的业务员,只是白烂公司不知道的是,本田的高中同学,刚好是威尔的大学同学。在双方共同朋友的签线之下,本田安排了一个秘密的会面。

本田:听说你们正在标白烂公司的Enterprise Portal。
威尔:嗯哼。
本田:我知道你们最少已经花了三十万去巴结他们课长,老实说,我们也花了五十万在他们部经理上。不过我知道我们的报价会比你高,我们技术能力又比你们差…
威尔:所以呢?我们会得标啊。
本田:我知道他们的预算是一千五百万,他们现在收了我们的钱,却想玩两手策略,把总价压下去;他们一方面,拿你们的价钱,来压我们的价钱;一方面,又拿我们的价钱,来压你们的价钱。
威尔:你们可以不要降价啊?
本田:现在景气这幺差,实在是赔本也想做。我知道他们的课长想这样搞下去,他想要用七百万成交,老实说,这对你们来说没有赚头;我们也没赚头。
威尔:你有什幺建议?
本田:你们先前报价一千三百万,我们现在则是报出了一千两百万,我看他们还想继续玩下去。花了那幺多钱买关系,结果两家公司斗下去,却都赚不了什幺钱,这一点意义也没有。我今天找你,是想建议我们两家公司合作。要嘛,我们不降价,这个案子给你们,然后你们付我们一百五十万顾问费还是咨询费,名目我们可以再商量,我们找合作的公司开发票给你们;不然就是我们用九百万当你们的下包商;再不然这个案子我们来做,看你们要抽多少。你觉得怎幺样?
……

与竞争厂商商量好,大家把合约价格拉高之后,就会有可以操作的地方。当然前提是要能够一网打尽全部进入安全名单中的厂商,以及客户拥有不做不行的压力。个中运用之巧妙,就存乎一心了。

关于如何为项目进行报价,有些人会倾向于采用将工作先进行详细的切割,将每项工作的人月列出来以后,加上一定的缓冲,再加上一定的毛利,才进行报价。这种成本毛利定价法,已经被新一代的行销观念改变了,这也算一种典范转移(paradigm shift)。也就是说,我们应该针对客户对于产品价值的认知,而非成本来进行报价,如果客户对于产品价值毫无概念,那就应该想尽办法把客户骗死。如果客户有三千万的预算,只报一千万根本就是一种罪恶,这会降低资本社会财富重分配的速度。

当然,当项目真正要发包时,还会有许多场面话得要交代。也就是说,要从客户愿意支付的价格,来反向推导出运用成本毛利法的各项工作。因为所有的客户都只想付你每个人工作的工钱,不虚报人月,根本没赚头。
客户的信息人员通常会要求提供更详细的项目规划,例如会要求提供工作说明书(Statement of Work, SOW),还是要求细部的项目时程规划,总会有还没有被收买的使用者,会想了解估价的基础与方法…
这就是项目经理可以发挥效用的地方了。通常他有两个选择:
依据科学的方法与先前项目统计资料的分析,以数学模型提供一个较为精确的预测。
随他高兴,随便乱估。

在台湾做项目,关于项目范围的叙述,通常都十分模糊。要拿着这幺模糊的说明预测未来是不可能的事情。如果能够精确预测未来的人就会去买股票,当华伦巴菲特第二就好了,不用当项目经理。依据统计,本书读者刚好可以预测未来的机率应该是趋近于零,所以第一种方法可以不用考虑。
更不用提大部分的公司根本就没有收集任何项目统计资料,以及要以数学模式预测未来,得要做多少苦工了。

真正的聪明人会采取第二种方法。只是要唬烂,还是得要有唬烂的技巧,以便在被老板质问时,可以找到一个适当的替死鬼。以下我会针对项目经理在估计的过程里,常用的流程进行细部的介绍。

民意调查

民意调查的重点,在于项目经理需要把所有的工作先区分出来。也就是说,项目经理得要知道要完成一个项目,所有的工作项目应该是什幺。原则上如果连工作项目也不清楚,抄抄前人的智能也就差不多了。
等到每个工作都区分出来了,接着就是要帮每项工作找个替死鬼,要他们提供时程的预估。接着把民意调查的结果纪录下来。这里需要特别注意的是,要确定每项工作都要最少找到一个人愿意提供估计的数据。下面这个例子就是一个不好的例子:

布鲁斯:莱西,你认为这个案子的系统分析要花几个月?
灵犬莱西:汪汪汪。
布鲁斯记录了,系统分析:三个月…
十个月后:
吉娜:布鲁斯,为什幺你们预估系统分析要花三个月,可是光系统分析,就花了十个月?这到底是谁估的?怎幺会差这幺多?
布鲁斯:…(这个莱西,我要把你烤成肉干来吃…)这个嘛…
正确的做法是:
布鲁斯:赛门,你认为这个案子的系统分析要花几个月?
赛门:嗯…我想,最少要三个月…五个月好了。
布鲁斯记录了,系统分析:六个月…
三天后:
吉娜:为什幺你们预估系统分析要花六个月,怎幺会要这幺多的时间?
布鲁斯:这个是赛门估计出来的,为了怕出现什幺状况,我再加上一些buffer。如果你觉得不妥,你要不要跟赛门谈谈…
十个月后:
吉娜:为什幺你们预估系统分析要花六个月,最后却花了十个月现在还看不到一个影?
布鲁斯:这个是赛门估计出来的,他一开始预估五个月,我还已经加了一个月的buffer,可是现在看起来,还是不够,当然,这不是赛门不努力,也不是我们没有好好掌握,实在是一开始就太乐观了…
吉娜:赛门,你这个数字到底是怎幺估出来的?…

透过民意调查法,一方面可以让项目成员享受参与项目的乐趣。如果工作顺利完成,这当然是你领导有方才可以顺利达成任务;如果工作延迟了,最少你还有一个替死鬼可以推卸责任。当然,这个替死鬼再预估时间时,多半也是自由心证抓出来的。

加权计算

民意调查完了以后,其实有两个动作要做,第一个就是加权计算。
所有的预估都会有误差,根据科学的统计,误差的大小,跟你一辈子会踩到多少次狗屎成反比。原则上狗屎运越好的人,误差就越小。只是这些误差,是随机地分布在不同项目之中。

也就是因为这个原因,让项目的估计非常的不准确。这也就是我们为什幺要加权计算的原因。因为事情总是有出乎意料的可能,所以通常我们会为每个工作项目,预估一定的buffer。再加上我们对于项目成员的了解,就会加上一定的权重,例如:Steven所估出来的时间,需要乘以2倍;Andy所估出来的时间,需要乘以3倍;Joyce所估出来的时间,则是要乘以0.8倍…
除此之外,我们通常会针对技术上的难度,以及各种风险系数,定出一定的权重,再加上使用者可能变更的项目,再乘以一个权重。
这个方法的重点,在于所有的权数是你自由心证,随便高兴就自行判断出来的。也就是说全部都是依据你个人的经验,以及上天赐予的灵感,加上奇怪的政策规定形成的公式所计算出来的。

在经过项目成员自由心证的预估,再乘上一个自由心证的权重之后,通常这时候你会得到一个被放大许多倍的时程。这就是为什幺通常我们会需要讨价还价的原因。不过在进一步探讨市场买卖的喊价法之前,我们应该先看看综合现在这两种方法的变形:超人估计法。

超人估计法

原则上这个方法就是综合了民意调查法与加权计算的特性。民主的国家中,凡是有投票权的人,都觉得他参与了改变世界的过程。使用民意调查法,可以让被问到的人有参与感。问题是公司通常不是一个民主的世界,从老板通常不是透过选举选出来的就知道了。老板通常会有特别信赖的人,就跟政府首长特别喜欢征询专家学者的意见一样,这些人通常是老板下决定时的信息来源。这些人通常具有超人一等的能力,可以用超光速绕着地球飞行,由于头发无法承受这幺高速飞行摩擦,所以头通常会变得秃秃的。我们可以简单地将这些人归类为『超人』。

对于超人来说,估计时程这个问题,可以从他们超凡的X光眼睛中,洞察宇宙的奥秘,所以可以预知未来。(不要问我X光跟预测未来有什幺关系。)只是项目经理通常会由于经验的驱使,将超人与平凡人的能力差异列入考量。这时候的争论,通常在于超人的力气到底等于几个凡夫俗子加起来的结果。

超人:因为我是超人,我会使用光速飞行,所以我想这个项目,如果我来做应该只要三个月就可以做完了。
布鲁斯:超人,这是因为你的力气太大了,所以我觉得你不可以用你的标准来看这个平凡的世界。我想我们最少应该要乘以四倍,我会预估十二个月才可以完工。
吉娜:布鲁斯,你还是高估了一般凡人的能力,我觉得乘以五倍差不多。
这时候的问题,通常在于到底一个超人等于多少个凡人这样无用的争论上。实际上,超人通常只是提出一个根本不可能的下限,让大家自己往上加码。此外,通常因为超人忙着拯救世界,所以通常不会有空来参与这个项目的开发。所以项目还是会如预期地delay。

讨价还价

所有预估的时程,都会需要经历这个过程。典型的例子如下:
布鲁斯:系统分析需要六个月?
吉娜:可是客户要在十个月内上线啊,六个月的系统分析根本不可能。布鲁斯,为什幺你们预估系统分析要花六个月,怎幺会要这幺多的时间?
布鲁斯:这是赛门估出来的啊,我不可能不保留一点buffer?
吉娜:我多给你半个人,我请史壮花百分之五十的时间帮忙你,四个月内做完。
布鲁斯:不可能,最少需要五个月。
吉娜:我请史壮这段时间全力帮忙你,可是你要确定把他的时间盯好。不要让他去忙其它的事情。现在你有两个全职的人了,我想这样应该可以在三个月内做完。
布鲁斯:还是不可能,史壮这幺忙,我绝对不相信他可以full time support。为了保险,我觉得最少还是需要四个半月。
吉娜:你要给他们压力啊,一定要把他们的生产力都挤出来。无论如何,一定要在四个月内完成。
布鲁斯:好吧。我试试看。
这种事情做多了,其实也就明白了。通常在一开始预估schedule时,就会先保留一部份的buffer,等着让老板来砍。这种讨价还价的行为一旦形成习惯,就会变得是每次估计时程,都要上演的戏码。其实就跟台湾人在夜市买卖东西差不多。

最后调整

不管先前怎幺讨价还价,最后还是得要依据客户的预算,进行最后的调整。例如项目的报价,依据计算,要花七百五十万;可是客户只有五百万的预算。该怎幺办?
一个方法是改变项目的范围。这种事情大部分的业务员通常是不会去做的,因为良好的客户关系,是维系在业务员退让的多寡之上;另一个好方法,则是运用政治上的压力,逼迫项目经理,修改预测,就可以完成最后的调整。

比起要与客户唇枪舌战,还要冒着破坏顾客关系的危险,帮项目经理戴顶高帽,要求他调整权重是否容易多了呢?
这就得要回归到刚才的步骤了。只是这一次,就是真刀实枪的厮杀了。
本田:我觉得这个案子的risk factor不应该这幺高。
布鲁斯:怎幺可能!我们从没做过J2EE的案子。
本田:我知道你们一定可以的,你们技术能力这幺强,一定没问题的。
布鲁斯(接了一顶高帽,有苦在心里口难开,尝试最后的防御):依照公司的规定,这个风险系数得要标到2。
吉娜:这样吧,布鲁斯,你可以先派一个程序设计师去接受Sun的训练啊。等他回来时,再教其它的人嘛。这样你觉得是否就可以接受本田的建议。
布鲁斯(好啊,本田你已经把老板这一票给骗走了,我干嘛做坏人。):我个人是觉得不妥,不过如果本田坚持的话,我觉得风险系数可以调到1。
吉娜:这样还差多少?
本田:这样我们的报价是六百万。
吉娜:本田,六百万应该可以去试试看了。
本田:承办人跟我打包票,他们部门今年就只编五百万的预算。听说他们公司最近可能会有缩减预算的方案。现在不抢下来,可能就没机会了。
吉娜:本田,我觉得你还是要试试看。Anyway,布鲁斯,测试真的要这幺久吗?可不可以用2个人,半个月就做完了?
布鲁斯(又要讨价还价了。这些笨蛋,每次都砍测试的时间):我觉得这样风险很高…
吉娜:你们可以把工作好好规划一下啊,要work smart,不是要work hard。我想依照你们这个team的能力,应该没问题。
布鲁斯(又收了一顶高帽,这些人到底知不知道他们在讲什幺?):我觉得还是不妥。
本田:吉娜,这样我们会接不到这个案子喔。布鲁斯,可不可以再考虑还有没有什幺可以精简的地方?
布鲁斯:唉,测试一个月已经不够了,不然就把implementation的时间再缩两个礼拜好了。不过我要事先声明喔,这一点,我还要跟programmer谈谈看。
本田:这样应该可以去谈谈看了。
吉娜:大家可以达成共识,这样子是最好不过了。本田,如果需要的话,我去跟他们部门协理谈一谈。我真的觉得应该可以以六百万成交。

基本上在这样的会议里,业务抱持的基本理念是:
如果降低售价,就可以顺利成交
项目经理抱持的理念则是:
反对到底,任何让步都要有老板背书
高阶主管抱持的理念则是:
如果可以提高售价,降低开发成本,我手上的股票选择权就会更值钱。
三方角力的结果,通常就是一个莫名其妙,没什幺道理的金额与时间。所以报给客户以后,通常还需要进行下一个步骤:『议价』。

议价

原则上要解读一份报价单与要找算命先生解释你的面相差不多,通常需要有专业人士的说明,才能看的出里面的玄机;然而你永远不知道这些专业人士,什幺时候是在唬你,只是想从你的口袋里面,多赚一些钞票。除非你自己也是专业人士,可以看得出来。然而依据机率来说,这样的可能性蛮低的。所以客户通常能做的,就是顺着你的话,找出语病,随便乱砍一通。

然而由于项目经理也是透过民意调查法,估计出项目的时程与成本。可是在与客户沟通时,通常提供原始估计的team member并不会出席。毕竟议价这是仅限高阶主管所从事的休闲娱乐,所以通常就得要想尽办法交叉运用下面几种方法,唬烂到底。

废话连篇法:

运用这个方法,通常是为了将故事从某一阶段,过渡到另外一个阶段时,所需要的发语词。通常不具任何意义,可是可以拖延时间,制造膀胱的压力,进而促成共识的达成。典型的废话包含:
一天工作八个小时
一个礼拜休息两天
(复述报价单,仿佛客户看不懂中文)一个人月是20万,所以六个人月是120万…
品质是非常重要的…

莫名其妙推论法:

我看过运用这个方法最神奇的一个案子,项目经理将所需要花费的成本,与某个很荒谬的指针结合在一起。原则上就是不知所云,完全悖离我们所认知的逻辑而言。这个方法的强大之处,在于客户的思路会完全的短路,就可以重新设定任意宰割了。
客户:我有看到你们依照每项功能,整理出一个功能的单价出来,可不可以请你解释一下,每个功能的单价是怎幺计算出来的。
天才经理:原则上呢,我是依据RFQ上每个功能叙述的字数,乘以一个我特有的数字计算出来的。所以你看,这个功能总共有30个字,一个字一万,所以要做这个功能总共要花30万。
客户(陷入极度的震惊与混淆,看着天才经理认真的表情,认为他不是开玩笑的):嗯……这个理论有没有什幺根据?
天才经理:这是经过长久的统计与计算,整理出来的结果。
客户(他不会是讲真的吧?):嗯…我想请问一下,如果我们修改RFQ上的文字,算法还是一样吗?
天才经理:这就要用change request的方法来计算了。原则上就是改一字或删一字都是一个字会影响总价一万。因为这表示你的需求不明确,项目开始后有可能会再赶过。头一次采用这种强大的方法,我想我们可以针对change request的部分特别打个折扣。
客户(我真的遇到一个疯子!):嗯…嗯…我再跟你联络。

真理法:

当客户有任何疑问时,重复说明一次自己的解释,然后强调一次这就是真理。真理,是不辩自明的。
客户:我有看到你们依照每项功能,整理出一个功能的单价出来,可不可以请你解释一下,每个功能的单价是怎幺计算出来的。
天才经理:这是经过专家学者,审慎的评估研究之后,整理出来的结果。
客户:我想我讲的不够明确,我可不可以知道你们到底是怎幺样进行评估的?
天才经理:我想我讲的不够清楚,这是经过专家学者,依据我们公司多年数据的统计分析,帮我们计算出非常复杂的公式之后,再经过审慎的评估研究,所整理出来的结果。
客户:我只是想知道他们到底是依据什幺标准,是怎幺样来进行评估的?
天才经理:我想她们就是依据我们公司多年数据的统计分析,帮我们整理出非常复杂的公式之后,再把相关的数字代进去,所计算出来的结果。
真理法与废话连篇法的差异在于废话连篇法所用的字句,通常还会有些不同,只是一堆陈腔滥调就是了;真理法则是同样的冷饭,一路炒到底。直到客户完全放弃抵抗为止。

公式法:

公式法跟莫名其妙推论法的差异在于,公式法所引用的公式,是确实存在的。可是由于实际上的估计,根本不是建立在数学模型上的结果。所以若不是依据结果编一个假的模型出来,就是根本只要声称采用这个模型即可。
客户:我有看到你们依照每项功能,整理出一个功能的单价出来,可不可以请你解释一下,每个功能的单价是怎幺计算出来的。
天才经理:这是透过function point计算出来的结果。当然,每个计算的过程我没有列在这里。如果你有需要,我可以列出来给你。(你要真的要,我回家编一份给你就是了。)
客户(终于遇到一个专家):不用了。不用了。你还需要我们提供进一步的澄清吗?
这个方法的好处,在于大部分客户只要听到一个理论上的名词,就会兴起一股崇敬之意。通常不会有人想要了解,数字是怎幺样推论出来的。况且如果客户真正需要你提供详细数字的时候,随便编也可以编出唬烂的数字来。
这个方法的另外一个好处是,在于一般人对于科学的信仰。越是信仰科学的人,越不知道怎幺样去与科学争辩。所以采取这个方法,通常会遇到比较小的阻力。

小结:
通常这几种方法交叉运用以后,客户的脑袋也被混淆的差不多了。所以通常就会往下一步推进。客户通常在此时会施出撒手鐗,不管三七二十一,直接砍掉报价的一定百分比。通常会留一些给承办人做业绩,留一些给采购做业绩。

结语

经历了这幺复杂的过程以后,难怪大部份的项目,都难以逃脱预算超出规划,还是时程严重落后的命运。当然啦,一开始的估计错误,通常还不足以这幺严重的拖延进度与消化预算,一定要与更多的错误的决策结合在一起,才能够达成这幺强而有力的效果。在把这本书的篇幅耗光之前,我会努力地找寻各式各样的偏见与答案。 
 

版权所有:UML软件工程组织