先吐个槽抛块砖，希望能够抛砖引玉。
由于今天状态不佳，越写越乱，所以干脆把我的想法总结放前面吧，分割线后的内容如果觉得没营养可以忽略了，可以只针对这个主题讨论。
主题：现有的甲乙方合同制项目模式严重制约了软件开发活动的经济效益以及成功率，造成双输甚至多输的局面；
具体的，现有模式的弊端：
- 项目周期短与软件成熟过程慢的矛盾：
- 软件的开发过程有着固有的规律；有点篝火经验或农村长大的人应该都知道，引火阶段需要用少量易燃材料点起火苗，然后慢慢添柴，还要为它挡风以免吹灭，等火烧起来以后就可以添更多的柴，彻底烧起来以后就可以随便往里面扔什么柴，湿的都能着；
- 但是项目往往都是周期相对短的，往往一上来就要大干快上的，不给你机会去把火点旺就一堆柴火扔上去了，还没等各方面工作理顺，项目已经接近尾声了；
- 这种项目先天就是瀑布模型的，你想玩儿迭代？先把客户IT部门的各种评审会应付过去再说吧。
- 另外项目周期短、仓促，往往客户方也没有做好充分准备，需求部门配合力度不够导致需求不清晰，这个问题最要命；
- 合同制导致对抗而非合作：软件企业打标阶段不惜一切代价，什么都干吹什么都敢答应，拿到合同后开始偷工减料（派廉价劳动力充数）；另一面由于项目范围往往定义不清晰，客户觉得钱花出去了要物有所值，提需求毫无节制，要求大而全、灵活可配置，做个小MIS恨不得让你额外送个OA ERP；这种博弈最终没有赢家；
- 短期利益与长期利益的矛盾：项目一期一般是不赚钱的，二期三期才是收获期，不赚钱就投入资源不足，然后就做的不好，然后就没有然后了；
这样的结果就是甲乙双方很难以建立信任并形成长期稳定、高效的合作关系，软件公司抱怨客户难搞市场难做，客户又抱怨大量IT投入下去收效甚微，被我们骗了。
为什么会这么苦逼？我冥思苦想最后想到一个结论——企业IT项目建设是无法跳过业务咨询环节直接让开发团队上去干的，
试想，如果业务领域专家或行业咨询顾问如果能够与专业开发团队强强联手，发挥各自的专业优势，那么上面的问题是不是就迎刃而解了？
- 首先咨询师在咨询项目中其实就是在点火，他们在理清客户业务过程中为后续的合作打好了基础——信任加熟悉，
- 同时咨询项目的成果也为后续开发项目的范围确定提供了依据，范围就不会失控，
- 咨询师往往也兼职售前，而且是更优秀的售前，打标成功率和项目金额都会更高；
- 同时开发团队也可以弥补纯咨询项目假大空的问题，甚至可以在咨询项目过程中开发就介入进来开发原型、POC；
当然这个想法不是什么新的东西，只不过我觉得目前我们行业内咨询界和开发界还合作的非常不够，基本是各自为战——前者在忽悠客户、后者在对付客户，IT界的名声就是这么败下来的；
有些实力强的公司可以养得起咨询和开发团队，但据我近距离观察几次后发现，他们也仅仅是公司名字相同而已，呵呵。
现在是互联网时代了，我在想能否跨越公司、地域的限制，我们IT民工跟咨询金领组成一个所谓“自由人的自由联合”，
以一个个小创业团队的形式，互相取长补短进行合作，你打单来我编码，你收钱来我分钱，顺便把IT界的名声挽回一些些。
有人可能会问这跟现在的公司形式有什么区别，区别就在于公司太大，再好的公司就算是TW，具体到某个项目也难保水平不济，
大公司的品牌效应和光环早晚会褪去，最终被大量的Abc战队、Xyz工作室所取代。
结论部分就是这些，有点乱见谅啊，抛砖、抛砖呢。
==========================================================
回顾工作这11年，亲身参与过的、近距离观察过的、旁观了解过的大小项目也有几十个了，深切的感到软件开发这件事儿真的是成功都是偶然的阶段性的，失败却几乎难以避免。
我不知道时至今日国内全行业的软件项目的失败率是多少了（是否降到了50%以下），但从我经历过的项目来看成功率是非常之低的，
大概只有一个项目是取得了阶段性成功（开发1年后上线，虽稍有延期但基本实现了目标，然后每月一次发布不断上新功能修缺陷），
当然项目成功与失败也没有统一的标准，我之所以觉得这个项目成功主要是从结果看，除了当初的项目目标达成，另外参与项目的甲方的多个人员获得升迁，项目在甲方全司范围内被评为优秀项目，我们获得了二期、三期的合同，现在还在不断的开发升级。（我这个成功标准要求不低的，因为有大量的顺利开发完成的项目其实没什么人在用的）
从过程看的话，这个项目做得还是比较乱的，早期团队缺乏经验，管理、沟通、架构、设计、业务等都做得很不理想，这也造成了“成功只是阶段性的”，因为技术债积累过快，开发效率和质量急剧下降（已经无法靠加班来弥补），项目多次出现危机，人员流动率高进一步加剧了危机。
就是这样一个前期勉强可以称为成功的项目，估计一两年后也要从我的成功项目名录制被删除了。
况且前期的成功其实也有外部因素的帮忙——有一个很有手腕的甲方领导为项目营造了很好的环境，争取了很多资源，协调好了业务部门。因此这成功对于我们其实是偶然的，因为你不能指望以后的项目也都有这样的甲方领导帮忙，这不，刚刚听说那个领导已经离开客户公司了。
我算是一个喜欢反思的人吧，所以没事就琢磨这些经历过的项目，琢磨的模式就是：如果当初xxx，那么现在应该会yyy吧，
反思多了我发现，其实具体到项目过程中的事情（包括技术、业务、架构、管理等）都是相对可控的，尤其对于这个邮件组里的人，有足够的方法和工具去把事情做对、去用正确的方式做事，但是另一方面——做正确的事，我们似乎没有什么办法了。
何谓正确的事，我简单理解就是做客户真正需要的、有价值的软件。
说起来简单，但是这件事儿在企业软件领域非常的难，跟面相个人消费客户的软件相比，
难在几个方面：
- 首先管理很复杂：这就不用废话了
- 企业的业务复杂：这也不用废话了
- 企业应用领域的技术复杂：这里最不缺的就是概念、大词和各种五花八门的新技术，跟娱乐圈一样热闹；还有大量遗留系统需要集成；
