我曾在SOVO担任项目经理，项目关于SOVO内部信息共享与考勤。我们的工作一直受不断更变的需求所困扰。在最初的计划中，由于经验不足等原因，需求分析的工作不足。问题的在于初期的计划中根本没有考虑到公司的内部项目的需求会不断更变，导致项目的时间、范围、成本难以控制。虽然最后项目终于完成，但已大大超出了计划的成本，严格来说项目可以说失败了。
我们选择的系统开发语言是现在已经成熟的网站设计语言JSP(Java)+Servlet。采用基于 J2EE平台的MVC(模型(Model)-视图(View)-控制器(Controller))模式的应用架构框架---Structs+Spring架构, 主要是采用Servlet和JSP技术来实现的。而在数据库访问技术方面：应用程序采用JDBC连接数据库，并采用数据库连接池技术。连接池技术可以减少应用程序与数据库连接的时间，提高数据总体访问速度。数据库采用MicrosoftSQL2000，WEB服务器使用TOMCAT5.0，系统采用WINDOWS 2000 SERVER，开发软件为ECLIPSE 3.1。
本项目从2005年10月11日开始，计划在12月11日两个月时间完成项目。在任务分配方面采用两个经理，一为执行经理，主要负责需求分析，客户联系及相关的文档整理，二为技术经理，主要负责项目开发中的项目开发规范、采用技术、解决方案等技术问题。在开发前期的需求分析中，由于客户没有及时提供资料，导致需求分析时间延迟两个星期，故整个项目延迟两个星期。在执行经理进行需求分析的同时，技术经理也在进行新技术的学习与框架的架设，其他项目代码编写成员也作相关技术的学习。而美工则进行首页及二级页面的设计并确定客户的需求。
经过一个月时间的努力，完成了需求分析，系统概要设计，页面设计，框架也架设完。但由于在短时间未能灵活使用新技术原因，同时也因为部分小组人员的辞退，没有在计划的两个星期中完成代码编写工作，而用了三个星期。剩余的一个星期作相应的系统测试和调整。
最后由于期末项目组人员要进行备考，不得不停止项目最后开发阶段。直至2006年2月28日才重新进行开发。计划在2006年3月28日完成项目。前两个星期重新设计了一些功能模块和修复上一学期遗留下来的BUG。后两个星期是进行系统测试并修复相关的BUG。最终经过两次回归测试完成了整个项目。
无论用何种方法或模式开发IT项目，风险总是比较高的，这正是IT行业有高利润的原因。在众所周知的项目管理九大知识领域中，个人认为风险管理在每一个其他管理范围内都有体现。可以说项目经理的工作就是在与风险打交道。风险管理对项目的成功有很大作用。
风险管理过程的重要作用在于风险效率。这也是不该把风险管理看做是“附加内容”或“辅助内容”，不该把重点放在“实施风险管理是不是值得”这个问题上的主要原因。风险管理应该被看作是与项目管理融为一体的“内在内容”，贯穿于项目开发的每一个过程中，是对基本项目计划过程的扩大和完善。实施风险管理要考虑的关键问题是：在这种情况下，应该以何种方式正式实施多少风险管理才最合适?
在进行风险管理时，所选择的风险分析方式必须与寻求改善风险效率的机会相适应。通常要识别出应该把额外的资金或资源用在何处将会降低今后的风险和总预期成本。判别能够改善风险效率的基准计划或应急计划中潜在的变更是有效项目风险管理的主要目的。
为了做到完全有效，风险管理应该针对整个项目生命周期而不是项目管理的某个阶段。通过将风险管理纳入到项目整体管理中，就可以利用风险分析指导并丰富管理过程的所有阶段。软件项目的风险体现在以下四个方面：需求、技术、成本和进度。
按我对SOVO的实际情况来看，技术、成本和进度都是SOVO生存环境的一个优势。在目前这种气候下，项目风险管理只要把握好需求这个方面就能够达到利益最大化。
为什么这么说呢?正如我给文章定的题目，项目的风险管理是无可避免的。因为无论是做一个项目，还是干一件事情，都有风险的存在，这是不以人的意志为转移的一个客观存在的事实，只不过在实施过程中由于环境动态和时间动态等动态因素的影响，风险出现的几率也会随之变化，可能是增加，也可能是减少，风险可能会暴发，也可能只是一直潜伏，这是一个动态变化的过程。所以从逻辑上讲，风险最终会不会出现，会不会在我们的计划内，是只有到项目进行到那一步，事情发展到那一步才能最终确定。
但需要强调一点就是这只是理论逻辑，相对于实实在在的项目，活生生的事物，鲜明的例子来说，所谓的几率只是书本上的符号，逻辑只是教科书上的符号。
虽然说理论可以指导实践，可大多数人往往信奉眼见为实，经验指导实际操作。也就是说，比较起理论知识的冗长复杂和难于理解，人们更愿意直接去相信一些已经发生的事实和通俗易懂的简单道理。
风险的发生存在一定的几率，有的发生的几率大，有的发生的几率小。可以是大于99%几率会有风险，可以是小于1%的几率会有风险。在实际情况中，人往往可以凭借经验，综合考虑，根据外部环境的变量来预测推断项目实施进度过程中哪些风险基本可以忽略，而哪些风险是需要特别注意防范的。
就象任命一个项目经理，人们往往更愿意，更希望找到一个有类似项目工作经历的人来担当一样，其考虑的根本着眼点就在于风险，因为有过相似经历的情况下，首先在考虑项目计划时就能更全面周到老练。在市场经济环境下，顾主选择人才一个很重要的标准就是工作经历，只要你有经历和经验，就胜过那些只会吹嘘理论的书生。
事物的发展过程总是有一个阶段性的，经验并不能知道一切的实践。即使是SOVO，当组织规范发展到一定程度的时候，必然要回归到理论逻辑的学习阶段。重新开始一个新的经验积累。这时我们需要注意新的情况。
在项目生命周期的每个阶段都会有风险的存在，而每次应用风险分析技术都会包括：定义、集中、识别、结构、所有权、估计、评价、计划和管理九个阶段。同时在没个阶段进行风险管理的过程中，还应该注意以下几个问题。
1.风险管理过程的成本
与风险管理过程相关的成本会出现在资金或时间方面，但是机会成本可能更重要，而且机会成本在进行长期决策时发挥着重要作用。我们需要在固定的资源约束范围内工作，关键人员的时间会变得极其宝贵。用经济学术语来讲，风险管理过程涉及的所有人员(而不仅仅是风险管理过程的专业人员)每增加一个小时的边际成本，应该用花费这些时间完成其他工作所实现的最大价值来衡量。在项目运行的某一关键点上，所涉及人员的时间非常宝贵，可能是他们工资总成本的2倍、3倍甚至10倍，因此对这些人和时间的有效利用至关重要。风险管理过程本身即是一个高风险的项目。如果在基本执行过程中已经出现危机，此时试图增加风险管理过程的资源(包括对人员的更多支持，不只限于风险管理过程的专业人员)并非上策。给一个失控的项目增加人员如同“火上浇油”。
2.风险管理的正式程度
正式性不仅是指要编制许多正式文件，它的关键内涵是结构，理解这一点有助于我们有效利用时间。风险管理过程的效果很大程度上取决于它提出正确问题的能力，而正式性、规范化正是为了解决这个问题而提出来的。
3.风险管理的组织
高级管理层的支持，对于发挥风险管理过程的作用非常重要。风险管理过程应该反映高级管理层的需求和关注。所有相关经理人员，尤其是项目经理需要在早期阶段介入，保证相关的风险管理过程纳入到项目管理过程中去。理想的情况是在这个阶段任命项目经理，让他能够积极参与到这些任务中，在更加详细的设计与计划阶段之前确立风险管理过程的概念并阐明其作用。更多人员参与到任务中很有好处，这些人员包括组织职能部门中的个人、主要客户、主要承包商或分包商、潜在的合作伙伴以及设计和引入风险管理过程的顾问。
而在这次项目实施过程中，我们应该从以下几个方面进行风险管理的改进：
1、时间管控方面尚欠经验。在项目开发中为防止项目意外事件而导致拖延，故：
项目所需时间=项目预计时间*x (2
本项目由于没有作出此时间管控，而导致在项目意外时无法按时完成项目。
2、与客户联系不够。虽然在前期中频繁联系客户，也给客户留下比较好的印象，但在后期中就很少联系客户了，不能及时让客户了解项目进行的情况。
3、本项目采用的新技术比较多，在既要学习新技术又要开发项目的时候，质量难以保证。今后如涉及的新技术比较多的话，应争取更多的开发时间以保证项目质量;如项目比较急，应采用项目组比较熟悉的技术。
4、数据库设计是比较关键的一点，若设计不当，将为后来的业务层编写中带来许多问题。故前期因对数据库作充分的设计。
5、项目开发规范不足。如信息异常处理页面跳转方面不统一，格式化验证不统一，Ation层编写不统一，数据库连接统一，页面结构风格不统一。这些不仅影响了开发进的，同时也影响了系统的使用性与美观。在今后的开发中因制定开发规范。
6、项目开发前期项目组人员未能灵活运用VSS，导致项目组人员频频下载新版本后都要对项目进行一些代码的屏蔽才能够进行自身代码的测试。经过几个月的VSS使用，组员已经可以很好的使用VSS，也增加了些默契。
7、项目服务器上需要人工进行项目更新，若是项目组修复了BUG而未去更新服务器的话，而BUGFREE上又标记了修复，测试公司在服务器上看见该BUG未改会误会我们忽略该BUG。这种情况经常发生，也给我们和测试公司带来麻烦。在今后开发中，服务器因安装类似ANT 这种自动编译以保证服务器最新的项目版本。
8、每周一的项目会议效果比较好，不仅让组员了解整个项目的进度，也促进了人员之间的交流，让大家一起讨论项目中的问题与分享各自的成果、技术与看法。这种做法应继续维持下去。
9、项目组人员坐在一起开发效率远比各自在宿舍开发要高，特别是在星期六日，因其聚的时间比较长，故开发的时候应尽量坐在一起。
通过这次项目，使我认识到，如果不实施正式的风险管理过程，使之成为项目管理的一个常规方面，就无异于“商业自杀行为”。日益加剧的竞争，更加挑剔的顾客、技术开发和其他变革速度的加快、商业机会日益增加的复杂性和新奇性，都对管理的不确定性和项目风险系统的成功提出了更高的要求。如果等到“触发事件”(如主要项目的商业手段失误或未能赢得主要合同)出现以后才接受这些信息，就太令人遗憾了。
第一业务员网
·
业务员文摘频道
