您的位置:软件测试 > 软件项目管理 > 成本管理 >
报价阶段预估项目时程与成本密技
作者:网络转载 发布时间:[ 2013/5/14 15:54:52 ] 推荐标签:

后调整

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

比起要与客户唇枪舌战,还要冒着破坏顾客关系的危险,帮项目经理戴顶高帽,要求他调整权重是否容易多了呢?
这得要回归到刚才的步骤了。只是这一次,是真刀实枪的厮杀了。
本田:我觉得这个案子的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计算出来的结果。当然,每个计算的过程我没有列在这里。如果你有需要,我可以列出来给你。(你要真的要,我回家编一份给你是了。)
客户(终于遇到一个专家):不用了。不用了。你还需要我们提供进一步的澄清吗?
这个方法的好处,在于大部分客户只要听到一个理论上的名词,会兴起一股崇敬之意。通常不会有人想要了解,数字是怎幺样推论出来的。况且如果客户真正需要你提供详细数字的时候,随便编也可以编出唬烂的数字来。
这个方法的另外一个好处是,在于一般人对于科学的信仰。越是信仰科学的人,越不知道怎幺样去与科学争辩。所以采取这个方法,通常会遇到比较小的阻力。

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

结语

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

上一页123下一页
软件测试工具 | 联系我们 | 投诉建议 | 诚聘英才 | 申请使用列表 | 网站地图
沪ICP备07036474 2003-2017 版权所有 上海泽众软件科技有限公司 Shanghai ZeZhong Software Co.,Ltd