这篇文章用来总结一下2013,同时也分享一下我对中国IT项目现状的一些看法。
我先从项目说起。这里的项目主要是指的软件开发项目。我们分别从项目中的甲方和乙方谈谈,看看这两者对于项目、对应IT的认识和观点。
甲方观点
这是个很简单的事情
“不就建几个表的事情吗?,怎么让你说的那么复杂!?”--现在甲方都知道什么事表了
我们的需求很明白!就这“两页纸”
“已经很明确了,领导就是这个意思,开始弄吧!”-- 确实是“很明确”
“还不清楚啊?我们其实就是要个ERP!” -- 厉害了,3个月要开发一个ERP
合同金额一定可以再少一些
“便宜点吧!没问题的!”--砍价吧,总会有乙方的
项目一定会在合同规定的时间内,用很低的成本,较高的效率完成
“这事交给你们我放心!好好干!”--乙方其实真的不好干啊
通用手段 --“拖”字绝
“先等等吧,领导最近忙啊!”
“不急啊,我们有些东西还没想清楚!”
“最后一次,最后一次了,改完就给你们打款!”
“真的是最后一次了!”
我是“甲方”,我是“爷”
“我们的需求变更是合理的啊!”
“我们这是细化啊!不可能一步到位啊!”
“别废话了,合同都签了,赶紧干活!”--不能问太多,因为甲方很忙
乙方观点
为了节约成本,大量使用应届生、外包、转包等现象时有发生
为项目失败埋下了隐患
虚构自己的项目经验、人员水平
为了拉到项目,“虚构现实”
有合同就签
“没办法啊,不签项目,这么多人等着吃饭呢!”
“签吧,走一步是一步,实在不行尾款不要了!”
需求变更是最头疼的问题
因为领导的意见“太明确了”,导致变更成了一个填不满的黑洞
不是乙方不懂“需求变更控制”,真是没法控制
合同前期我忍,合同后期我撤
很多时候当“孙子”确实不容易,一直到忍无可忍的时候乙方就会选择退出
上面是一个现实情况的简单重现,我们从解决问题的角度出发,看看怎么来减少或避免项目失败。
解决办法
首先,甲方要足够重视项目。依据我的经验,一个项目的成败在很大程度取决于“一把手”是否真的重视!我这里说的“成功”是指一个项目满足了用户的大部分需求、并真正的投入使用、改善或提高了甲方的工作效率。与此同时乙方要安排合适的人员参与项目、并积极学习甲方的业务知识。
第二点,甲乙双方都要认识到软件项目和传统的项目有很大的区别。让甲方花100万去采购硬件失败的几率是零,但是如果是100万的软件项目,是否成功要依赖双方的通力合作。软件项目依赖于需求是否明确、管理及开发人员的水平和经验、项目的规模和复杂程度、乙方对甲方需求的了解程度等等。
第三点,避免中国式的项目需求。很多时候甲方项目负责人(接洽人)的职位比较低,在沟通的过程中他并不能(也不会)站在更高的层次上去思考问题,这就给双方带来了麻烦。比如一个项目经理负责接洽,初次审核是科长,第二次审核是处长,最后验收时又跑出来个局长,这就很要命!每次都站在一个更高的层次是去考虑问题,带来是无穷尽的需求变更,甚至是对项目致命的摧毁。基于这种现象,双方都要尽最大努力让最关键的人物尽早出现,避免需求黑洞的出现。
第四点,双方最好都按“分段交付”的规则来监控项目,这里也可以说是“里程碑”式的规则。甲方千万不要当甩手掌柜,定期评审项目能及时的发现问题并改正,避免在deadline时dead掉,用milestone确保双方都在正确的路上行进--其实milestone就是我们的指路牌。
第五点,关于“需求变更”。“需求变更”是一个令人头疼的问题,他给参与项目的人员带来的痛苦只有经历过的人才能体会的到。但是这是一个没人能够回避的问题。
约定甲方和乙方的是合同,但是如果完全按照合同约定的需求去实现软件,估计项目不会真正的成功。我们要找到一个合适的平衡点来协调“需求变更”。甲方要尽可能的在项目初期把需求细化,比如:让尽可能多的人员参与到需求调研中;使用“头脑风暴”的方式提出需求;基本需求确定后让相关部门的负责人确认签字;找到合适的乙方,听取乙方的建议;对于乙方来说也是一样,要引导甲方尽可能的完善需求。用一句话概况一下“前期多说,后期少变,避免说变就变”!
第六点,关于“后期维护”。这里我主要谈谈“后期维护”对乙方的好处。首先,它可以让项目更加完美,更加贴近用户习惯。其次,它可以让乙方和甲方保持良好的沟通并改善双方的关系。最后,它可以给乙方带来下一个项目。所以乙方要足够重视“后期维护”,不要让它成为合同里的一句空话!
以上是我的肤浅认识,如有不妥之处,还请大家多多指教,谢了!