在软件开发的外包过程中,从RFP(Request For Proposal)的制作、开发商的选定,到上线,售后服务位置,有很多应该注意的地方。
定律之23:
无中生有的RFP
据说,想要让软件开发外包顺利进行的话,制作合适的RFP是很重要的。
也向那些IT成熟度不高的中小企业 要求 提供RFP。但是,能够制作出合适的 RFP的能力是IT技术者的最高能力之一,外行根本就搞不了。这是无中生有的一个典型的例子。
- 最终目标很明确,赚更多的钱。有必要的话,用具体数字来表示也可以。
- 但是,怎么才能赚更多的钱呢?不知道。就算知道,也是和IT没有直接关系的业务形式
- 就算想要和IT塔上关系,但是从哪里开始怎么应用才可以呢?不知道。
- 就算知道可以应用的范围,但是也无法把他具体表现为系统的功能。
- 就算知道系统的功能,但是不知道怎么才能跟开发商说明清楚。
定律之24:
顾问吃霸王餐,开发商自私自利
据说,应该把制作RFP或者是到概要设计为止的工程,和具体的开发系统的工程,分开签约才对。
可是呢,在前者,顾问留下墙上画饼,纸上谈兵的厚厚的文件后拍屁股走人。在后者,开发商看到设计书之后直接说“这个无法实现”,结果就自作主张的重新设计起来。
定律之25:
评价提案书时,根本和RFP的内容毫无关系
提案书的说明会,已经变成了PowerPoint的竞技大赛了。虽然 新手对 那些对提案内容很敬仰,但是刚刚跳槽过来的老手,却发现在上一个公司也看到过完全一样的画面。(当然,这不是讥讽。这是一个用来表明开发商的信息共有化或组件再利用水平的一个指标)
当然,经营者(那些对选定开发商具有决定权的人)不会被画面随迷惑,而是重视提案内容。但是,那个内容如何解决了RFP的要求呢,则没有什么兴趣。
感兴趣的部分是,“围绕贵公司的经营环境”,或者是“怎么打败对手”等等,提案书里面的煽情的部分而已(经营者能理解的只有这个部分)。
了解这一点的开发商,在提案书里面大量的使用这些煽情的内容,而具体的提案内容则只有“因此,交给我们公司开发绝对没有问题”这一行而已。当然,这些煽情的内容也不是开发商自己调查、理解的东西,而是仅仅把商业杂志的内容变成PowerPoint的图像而已。
定律之26:
有多少开发商,就有多少“标准”
定律之27:
服务器的数量,与开发商的数量成正比
开发商提供了多种提案内容,但是经营者的判断标准只有一个,那就是报价。因此,不同的项目就有不同的开发商来担任。
这些开发商,都有自己公司的软件开发标准。虽然在提案书里面应该提到会使用这些标准,但是根本没有重视这些细枝末节的 经营者 。结果,公司里面出现了标准泛滥的现象。各种各样的OS和中间件的存在也是同样的理由。
另外,要是使用了现有的服务器来开发系统的话,那么和其它公司开发的现有系统冲突调整很麻烦。因此,就会临时准备一台开发用的新服务器。一般来说这台服务器在系统上线后就会被撤销,但是直接就当作正式服务器上线(升级一下)的情况反倒是常态。因此,在IT部门里林立着大量的服务器。
定律之28:
2423法则(作者不明)
当初,签订的内容是两个功能2份 费用。随着开发的进行,增加了越来越多的新要求。开发商为新增的功能希望得到4份费用,但是客户这边认为属于式样解释的范围,只肯付2份的费用。争执的结果,开发商拿到2份的费用,开发了3个功能的系统出来。
开发商收到2份费用,却开发了3个功能的系统,因此还有1份费用的不满。而客户这边要求的4个功能只完成了3个,还有1个功能的不满。这样两者就都可以算是公平交易。
定律之29:
加强管理的话,私自交易就会增加
为了避免产生式样变更时的麻烦,双方都指定一个负责人。就算是有很微小的变更也要署名签字才行。
但是,客户这边的人觉得向负责人汇报情况很麻烦,而开发商这边的人对项目经理汇报也感到很麻烦。这样,这两个人的私下交易终于成立了。用经费吃一顿之后,交易成功。
定律之30:
客户最信任开发商的时候,就是在测试阶段
由客户来精心准备测试数据是非常少见的。
仅仅是把上个月的数据发过来,然后测试结果而已。因此,基本不会去检查数据是否有问题。仅仅在测试的时候,客户是相信开发商不会犯错误的。
正因为信任,才会有背叛。因此更要加强 SLA(服务品质协议 )的条件,提出赔偿条款的内容。
原文链接: hhttp://www.atmarkit.co.jp/im/cits/serial/murphy/05/01.html
版权归原作者所有,转载请包含原文链接
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/378235/viewspace-701073/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/378235/viewspace-701073/