和马克思对话系统架构与软件项目风险

文/李智慧

 

 

通常软件项目风险包括：需求风险，技术风险，人员风险。其中需求风险包括需求理解错误风险，需求变更风险，项目周期风险；技术风险包括技术选型风险，架构设计风险，人员风险包括人员流动风险，人员技术经验风险。

对项目风险关注的一般说来是项目责任者，即项目经理，而项目经理对风险的控制主要是从管理手段着手，通过风险识别，风险评估，风险规避，风险控制等一系列手段达到风险管理的目的。可是风险之所以成为风险就在于风险的不确定性，你永远也不知道风险会在什么时候发生，风险会以何种形式出现，当你使用了所有的教科书上的风险管理手段以后，你发现你对已经发生的风险依然手足无措，既不能放弃项目，又没有完整的解决方案，只有硬着头皮，手忙脚乱的摸着石头过河，在每一个不眠之夜后祈祷新的一天不要再有新的风险发生。

那么真的没有一劳永逸的办法吗？难道项目经理就该注定被各种稀奇古怪的风险折磨的皮包骨头然后用担架抬走吗？我仰头问苍天，上帝回答说：“是的，没有一劳永逸的方法，那样人世间的游戏就太单调了，我丢不起那个脸。”于是项目经理只好为了上帝的脸面继续以泪洗面，痛苦挣扎。

可是这个世界除了上帝还有马克思，这个大胡子的德国人用英语说：“There is。。。。。”，我不耐烦的打断他“请用中文”，于是我听到了这样一段绕口令“任何事物都有主要矛盾和次要矛盾，任何矛盾都有主要方面和次要方面，当你把握了事物的主要矛盾的主要方面，你也就把握了事物的规律。”，一个叫尼采的家伙插话道：“这个时候，任何困难和风险都可以迎刃而解，上帝死了，你还活着”，“而且有滋有味”，我回头一看，说话的是葛优。

“那么我应该怎样进行项目风险管理，或者说项目风险管理的主要矛盾的主要方面是什么？”，我来了兴致，谦虚的请教。“是系统架构设计”马克思怕别人再打断他的话，连忙继续到“一个良好的系统架构可以有效控制风险并保证项目顺利进行。”

“那么什么样的系统架构算是良好的系统架构呢？”我紧追不舍。

马克思调整了一下语速慢慢说道：“第一，系统架构要将系统良好解耦，在横向上通过分层方式将系统分割为界面层、控制层、部署层、逻辑层、持久层，在纵向上将系统业务分解成独立的模块，每一个模块的每一个层面都不再互相耦合，它们只和系统架构耦合。第二，系统架构和业务模块的耦合应该是可配置的，业务扩展的时候，只需要修改配置文件就可以了。第三，架构应该是柔性的、自适应的、可扩展的，即架构自己也是解耦的。第四，系统架构设计要有完整的文档，使用UML描述并保持和架构变更的同步。第五，系统架构要易于理解和掌握，开发小组的每一个成员都要理解架构，至少一半的项目成员掌握架构实现的内部细节，当架构需要扩展维护的时候，这一半人每一个都能动手去修改它。”

“这样一个系统架构又是如何解决项目风险的呢？”我打破砂锅问到底。

“首先，这样的架构天然的支持迭代开发，任何一个业务模块开发完成，都可以配置到系统框架中，客户在任何时候都能看到一个可运行并持续壮大的系统，客户心里有底就不紧张了，他不紧张了，你的日子就好过了。”马克思说到这里，顿了一下继续到：“其次，由于模块是分层的并且解耦的，当需求变更的时候，影响只是局部的一小部分，即使是把界面层从浏览器变换成VB.NET胖客户界面这样的大动干戈，你都可以让你的JSP程序员突击一个晚上的VB.NET而从容应对，因为后台的逻辑不需要改变，那么需要的工作不过是把控件在VS里拖动一下罢了。同样分层并且灵活的架构也极易对应技术风险，当你的客户或老板为了赶时髦要你使用WebService代替EJB的时候，你只需要在部署层略做手脚就可以了。至于人员变动风险”马克思说到这里有些不屑一顾“架构是灵活易于掌握的并且文档丰富的，业务模块是独立并且松耦合的，没有人是不可代替的，甚至包括你。只要客户不离开，谁都可以离开。”“资本主义每个毛孔都。。。。。。。”我听的出神，没有回头看背后谁在窃窃私语。

“你说的这些并不复杂，在主流的框架技术上稍作调整组合就能达到你所谓的良好架构，为什么项目风险依然困扰着大多数项目管理者呢？”我想搬起上帝的石头砸马克思的脚。

马克思显得很从容：“Struts, Spring, Hibernate, Webservice, EJB, MVC, AOP, UML, Design Pattern。。。。。所有这些都是很好的，可是许多人不知道这些东西为什么是好的，精粹在哪里，只是跟风，别人用也就跟着用，却不能在实际项目中灵活应用，遇到非常规问题就缩手无策，甚至采用和这些框架技术思想向左的手段去处理，其结果只能是化神奇为腐朽，所谓的解决问题不过是带来更大的问题。”

“一般人他不告诉的。”我莞尔一笑，这次不用回头我就知道说话的是谁了。