艾伟也谈项目管理,谈软件协作:君子和而不同,小人同而不和

艾伟也谈项目管理,谈软件协作:君子和而不同,小人同而不和 我们知道现在的软件开发最大的问题就是变化,其实这也不是软件本身的问题,我更觉得是软件的特点。因为他不像建筑,画个建筑图,一般不会偏到哪里去。然而很多需要软件的人,他可能希望软件能达到什么目的,至于具体是什么样子,他自己也不知道。大部分都是看到一部分想起一部分,自己也不断的修正。这也是为什么最近敏捷大行其道。

我甚至服务过一个客户,做一个公园系统,为的是送一张免费的VIP卡给业主,最终目的是卖房子。

既然软件的需求是不固定,也就是不断变化,所以我们签合同的时候往往有两种方式:

1.固定价格

这种就是一开始让客户必须把需求定下来,然后估计时间,然后就是报价,我一直不懂这个价格是如何报的,很多就是先去客户那里调研一下,其实就是看一下这个客户好不好蒙,能蒙多少。然后就近可能的往高的报。然后整一份需求说明书,让客户签字,如果客户改需求,加钱加时间。要不就目前的功能你做了也没用,鸡肋,大部分客户咬着牙,加吧,谁让我们给他们分期付款,还付了定金呢,最终不欢而散,两败俱伤。

2. 按时间付价格

这种大部分出现在外包的项目中,就是客户找自己需要的工程师,按月付费,一般采用迭代式开发,增量式开发,客户考察的主要是质量和效率,如果达不到客户的要求,客户立即停止。这样看起来很美,但是效率却是一个不好衡量的东西,尤其是时间短的项目,很难看到效率,举个例子,同样是盖楼,一个打10米的地基,迅速盖到了三楼,可是另一个打了30米的地基,为的是盖30层的高楼,很显然,10米地基的楼房很快就出现人的眼前。这说明效率有时候有点“乱花渐欲迷人眼”。但这种方式,我们很多人5小时能干完的,非要8小时干完,为什么呢,因为5小时干完,客户也不一定提高报价。客户很难知道什么是真正的效率,从某种意义上说,抹杀了整个生产力。

两种方式,看似都有问题,但第二种比第一种对双方风险稍小。但第二种会抹杀整个行业的创新和积极性。

最近,看《论语》“君子和而不同,小人同而不和”就是说,君子内心所见略同,但其外在表现未必都一样,比如都为天下谋,有些人出仕做官,有些人则教书育人,这种“不同”可以致“和”;小人虽然嗜好相同,但因为各争私利,必然互起冲突,这种“同”反而导致了“不和”。

这突然让我想起软件项目的合作有何尝不是如此,很多时候,我们以为有了一份合同就可以,其实合同就是一份摆设。如果都按孔子的这个思想,软件合同其实就是要完成一件事情,具体要做成什么样,价格是否会变化,应该是在过程中不断协商,不断合作。如果一开始都说好不变,其实我们自己都知道,一定有一方会吃亏。就像有人说“中国人太多,炸死一半就好了”(此话出自在电梯偶遇某一个看似有文化的中年妇女),我就想难道那一半就一定不包括你?

所以,我们在软件写作过程,最好就是想尽一切办法,让自己和客户的合作更紧密一些,合同内容尽量少一些。

胡乱瞎写,愿各位斧正。

注:不希望看到评论只说别人文笔太差,而自己又不愿贡献文章的人。比如,很多项目经理老说别人不行,如果别人都行了,那你就是最不行的,你有别人没有的东西,这才是你存在的理由。

 

上一篇:MongoDB项目中常用方法


下一篇:项目之用户登录和访问权限的控制(6)