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