l 经过漫长的煎熬，用户疲惫了。开发组接近崩溃的边缘，大家都熬不下去了，项目结束了。那恶梦醒了吗?天亮了吗?不，新的恶梦又开始了。原来的项目组人员纷纷离职，新来的菜鸟面对着一堆残缺的文档，如同甲骨文一样的代码，维护变成了考古，用户的电话不断，Boss还兴致勃勃地签了第二个、第三个合同。。。

    这一幕在大大小小的软件公司频频上演，相信大家已经非常熟悉，如果你当了项目经理，要怎么解决呢?

    l 规范需求，比如每一项需求都要用户签字认可，没有的需求就不做，这样就不会出现需求泛滥的情况。

    (理论上正确，可执行难度非常大，你不能期望每个用户都是专家，他们往往只是看到真正的系统以后，才有自己的想法，如果没有出现的需求就不做的话，Boss就跟你急了：我签个合同容易吗我?)

    l 规范项目管理，严格代码规范执行，要求文档和代码编写同步等等。

    (也不错，可Boss招的程序员都是些菜鸟，该死的微软升级又太快了，AJAX、WWF等等，光培训就要好长时间，能把代码写出来，实现功能就不错了，代码规范。。文档。。。，等等再说吧)

    也许，有朋友会说：“在我们公司一切都非常规范，开发流程，团队等等都很好，你说的这种情况根本不存在的”，如果是这样的话，我们可以恭喜他了。问题是，目前真正做得规范的公司又有多少呢?当你不能改变环境的时候，你只能改变自己。

    回到开始的话题，我们尝试用“系统思考”的观点来分析一下：

    在系统思考的领域，最重要、最有用的洞察力是能看到一再重复发生的结构形态：系统基模，少数的系统基模覆盖了大部分的管理问题。它的目的是重新调整我们的认知，以便让我们看到结构的运作，以及结构中杠杆点。 - 《第五项修炼》

    我们不难看出，上述问题是一种典型的“舍本逐未”的基模，症结就是项目开发的制品-软件系统本身，常规的软件架构无法实现：在用户需求不定时，即时生成系统，与客户进行交互，使用户需求最终得到确定，在用户需求变化时，即时修改、即时实现，做到“即插即用”、“即改即用”。当软件已经设计定型以后，所出现的问题，不得不采用增加功能、打补丁等等形式去解决，只能部分缓解问题。

    因此，我认为结构中的杠杆解，应该是在于软件系统的本身，在于能否实现一种敏捷的开发架构，

    l 在用户需求不定时，即时生成系统，与客户进行交互，使用户需求最终得到确定，在用户需求变化时，即时修改、即时实现。

    l 不需要编码，实现对系统功能的调整和添加，做到“即改即用、即插即用“，降低系统的维护升级成本。

    l 用户通过简单培训，即可完成相对简单的功能修改和新业务应用开发。

    l 封装了开发必须的基本模块，将复杂的技术实现封装到模块里，将代码的编写工作降低到最小，只需要写必须的代码。开发人员只需要基本的Net入门知识，即可完成系统的开发。

    l 系统提供灵活的接口，可以根据项目需要添加所需的新功能模块。

    l 系统自己可以生成必要的设计、维护文档，降低项目开发、维护的文档要求，使项目管理工作简化，成本降低。