【IT168 技术文章】

    “系统思考”源于彼得·圣吉所著的《第五项修炼-学习型组织的艺术与实务》一书，彼得·圣吉所说的第五项修炼指的就是：系统思考，什么是系统思考?系统思考是对影响系统行为的力量和相互关系进行思考的方式。简单的说，就是用系统的、整体的、全局的思维方式而不是细节的、片面的、局部的思维方式去思考解决工作生活中遇到的问题。

    一个系统是一个能够被感觉到的整体。系统元素彼此联系、相互影响。一台计算机是一个系统，一家企业是一个系统，一个社会也是一个系统，小到微观粒子，大到宏观宇宙，都是一个相互影响、彼此联系的一个系统整体，都有其运行的内在规律。面向对象语言所描述的：Everything is Object。我们是否也可以说：Everything is a System?-网络文摘

    正如书中的序言所说：“系统思考是一扇重新看世界的窗”，那么，我们是否可以用“系统思考”的观点来重新审视软件开发过程，从而找一种更为合适的敏捷开发之路呢?

    的确，在贯穿一个软件项目从需求、开发、实施、维护以至终结的整个生命周期中，我们可以很清楚地看到，客户单位、软件开发商、开发程序员、实施维护人员、使用者等等构成了一个相互影响、彼此联系的系统整体，项目的成功并非只取决于某一部分组成人员(尤其是程序员)的努力，这一点相信广大同仁都有同感。

    看到这里，也许很多同仁会认为，这些问题更多是属于项目管理的范畴，应该从项目管理的角度来解决问题，而不是技术、开发架构所能解决的。果真如此吗?

    下面是在项目开发中很普遍的情况：

    l 需求调查阶段：用户提不出明确的需求，“照xx系统做一个就行“。

    l 开发组用调查、参考、揣摩、想象等等手段，完成需求分析和系统设计，和用户交流，用户：“行，先按这个做吧，以后不对的地方再改!”。

    l 于是，开发组开始了或短暂(一般都短不了)，或漫长的工作，完成了系统的编码开发。好像一切顺利，胜利在望了!(不，恶梦才刚刚开始。。。)

    l 实施阶段，恶梦真的开始了，用户的需求大爆发、各种各样的、奇怪的要求纷纷出笼，“这不是我们要的功能。。。”，“应该这样这样做。。。”，怎么办，改吧，加班吧。。。，

    While( 用户要求 > 0)

    {

    If(项目组.能力 < 用户要求)

    {

    If(公司不能招人 || 无法招到合适的人)

    项目组。加班

    }

    用户需求 -= 项目组。工作

    If(开发组崩溃)

    Break;

    }

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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