风险⽆处不在，⽽且⼏乎⽆可避免。作为项⽬经理，我们不能乞求谁会给我们⼀个安全的项⽬。事实上没有真正意义上的风险，项⽬注定是要失败的：全⽆风险的同时，它们也⼏乎全⽆价值。这些项⽬我们⼤可不以理会，给⾃⼰节省⼀点时间和精⼒，去做些真正有价值的事。正视⽆可避免的风险，加以适当的识别、分析、制定计划对其管理与应对，使项⽬能够更加好地达到⽬标。
  我曾在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、与客户联系不够。虽然在前期中频繁联系客户，也给客户留下⽐较好的印象，但在后期中就很少联系客户了，不能及时让客户了解项⽬进⾏的情况。
  3、本项⽬采⽤的新技术⽐较多，在既要学习新技术⼜要开发项⽬的时候，质量难以保证。今后如涉及的新技术⽐较多的话，应争取更多的开发时间以保证项⽬质量；如项⽬⽐较急，应采⽤项⽬组⽐较熟悉的技术。
  4、数据库设计是⽐较关键的⼀点，若设计不当，将为后来的业务层编写中带来许多问题。故前期因对数据库作充分的设计。
  5、项⽬开发规范不⾜。如信息异常处理页⾯跳转⽅⾯不统⼀，格式化验证不统⼀，Ation层编写不统⼀，数据库连接统⼀，页⾯结构风格不统⼀。这些不仅影响了开发进的，同时也影响了系统的使⽤性与美观。在今后的开发中因制定开发规范。
  6、项⽬开发前期项⽬组⼈员未能灵活运⽤VSS，导致项⽬组⼈员频频下载新版本后都要对项⽬进⾏⼀些代码的屏蔽才能够进⾏⾃⾝代码的测试。经过⼏个⽉的VSS使⽤，组员已经可以很好的使⽤VSS，也增加了些默契。
  7、项⽬服务器上需要⼈⼯进⾏项⽬更新，若是项⽬组修复了BUG⽽未去更新服务器的话，⽽BUGFRE
E上⼜标记了修复，测试公司在服务器上看见该BUG未改会误会我们忽略该BUG。这种情况经常发⽣，也给我们和测试公司带来⿇烦。在今后开发中，服务器因安装类似ANT 这种⾃动编译以保证服务器最新的项⽬版本。
  8、每周⼀的项⽬会议效果⽐较好，不仅让组员了解整个项⽬的进度，也促进了⼈员之间的交流，让⼤家⼀起讨论项⽬中的问题与分享各⾃的成果、技术与看法。这种做法应继续维持下去。
  9、项⽬组⼈员坐在⼀起开发效率远⽐各⾃在宿舍开发要⾼，特别是在星期六⽇，因其聚的时间⽐较长，故开发的时候应尽量坐在⼀起。　风险⽆处不在，⽽且⼏乎⽆可避免。作为项⽬经理，我们不能乞求谁会给我们⼀个安全的项⽬。事实上没
有真正意义上的风险，项⽬注定是要失败的：全⽆风险的同时，它们也⼏乎全⽆价值。这些项⽬我们⼤可不以理会，给⾃⼰节省⼀点时间和精⼒，去做些真正有价值的事。正视⽆可避免的风险，加以适当的识别、分析、制定计划对其管理与应对，使项⽬能够更加好地达到⽬标。
  我曾在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、与客户联系不够。虽然在前期中频繁联系客户，也给客户留下⽐较好的印象，但在后期中就很少联系客户了，不能及时让客户了解项⽬进⾏的情况。
  3、本项⽬采⽤的新技术⽐较多，在既要学习新技术⼜要开发项⽬的时候，质量难以保证。今后如涉及的新技术⽐较多的话，应争取更多的开发时间以保证项⽬质量；如项⽬⽐较急，应采⽤项⽬组⽐较熟悉的技术。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。