该帖子同步发自：(xianggll的博客  访问该博客)

前段时间读了《与熊共舞》这本书，对风险管理的理解更加深刻了，今天想记录一下对软件项目的风险管理的经验教训与认识。

软件开发项目的复杂性使得在开发过程中面临各种风险，而我们越早能预知这种风险的就越能增加项目的成功概率。项目风险我觉得分为共性与独特性，共性就是一系列的项目可能都会面临的风险，比如人员变动的风险，需求变化的风险，技术的风险，开发环境的风险。而独特性则是由于每个项目的需求不同以及技术实现不同所产生的不同的风险。

总的来说我们应该建立一种标准的风险管理方法，维护一个风险管理跟踪表，积累项目的经验同时把组织的经验持续地更新到风险管理方案里，为后来的项目开发人员防止类似的问题做参考

举几个实际的项目例子来说明。

项目一: 由于客户需求驱动的系统负载均衡项目

背景: 我们有一个产品是对几个交易所的同一只股票数据做增值计算，比如三个交易所的股票信息集合到一个合成的数据里，同时排列最好的买卖价格，数据更新是比较快的。原来我们是在一个虚拟机上实现了将近300多个股票的业务。当时的技术实现是允许数据部门的维护人员可以手动添加新的股票到一个源数据里面然后我们的系统会自动创建合成增值数据。但是没想到有一天数据部门的人员突然加了将近2000的新的股票进来，超过了系统的负载从而影响了现有数据的更新，由于数据的重要性以及影响的范围客户给我们提了最高级别的ticket，我们当时马上把新加的股票回滚以恢复到初始的稳定状态，先保证现有数据的安全。

问题是解决了，但是由于新的数据对客户的重要性，业务部门给我们很大压力要求尽快能把新的数据加进来，同时反馈到我们上几级的老板给对我们施压。这是一个业务驱动的技术改进项目，我不敢怠慢赶紧召集开发和架构师进行技术分析，最终的决定是再加一台虚拟机把程序复制一份过去能承受新加的2000多个新股票(这些新股票的活跃度比原来300多降了不少)，同时为了防止以后数据部门手动添加造成类似问题，我们决定通过自动化技术手段来限制负载而不是靠流程来告诉他们不能添加多于多少的数据，因为人是不靠谱的(这也是一个风险管理的方法，人操作本身就是有风险，不能指望每个人都能100%按照你的某些人口头或者书面约定好的流程来操作，为了减少人为操作失误的风险，我们可以通过技术的手段来对他们的操作做限制，最起码我们可以保护现有的数据不出问题). 就这样我们承诺在一个月的时间上线新的数据，开发工作有条不紊的进行中，一切看起来似乎很顺利，然而由于这个项目的特殊性，我们必须保证在承诺的时间做完系统的负载均衡同时上线新的数据，这时候对我们来说最大的风险就是没法按时交付。我当时考虑到负载均衡本身的技术实现我们是有经验的，风险比较小。但是我们采用的新的技术手段其实以前没有用过，虽然看起来本身的实现不大复杂，但如果这个技术出问题的话会导致整个项目的延时交付，最终我们可能都得吃不了兜着走。当时我的分析是我们承受不了这个技术方案出问题的风险，那么我们就得提前考虑有何预防措施。我们的最终底线是把新数据上线，其实防止数据部门手动修改人为出错只是一个系统健壮性的内部需求，那么我们的预防措施就是让数据部门先手动把这些数据源先在我们的上游系统里创建好，一旦我们的自动化技术方案有问题，也可以通过手工的方式先把新数据上线。

果然，我的担心变成是现实，在我们承诺交付日的前一周，自动化技术方案由于平台的一个隐藏bug没法实现, 解决这个bug需要几个月的时间，我们果断采用备选方案从而保证了及时交付了新的数据，客户和业务部门都比较满意，然后我们再和平台开发部门的同事讨论如何解决系统的bug和时间表，同时和数据部门的同事约定好在一定时间内不能添加多于多少个新的股票，当然这时候以及没有那么大的压力了。

有时候最大的风险就是项目延时，我们需要分析项目关键路径上的每一个点出问题的概率以及影响和有何提前预防措施，这样的话才能更好地把控项目进度，同时我们也需要了解项目成功的最重要的目标是什么,这也和<与熊共舞>里面经典的飞机场系统的例子很类似

同时我也谈谈这个项目的教训，我们的负载均衡和自动化技术方案当时是串行进行的，现在回过头来想想其实我们可以把开发分成两部分独立开来让两个开发人员同时进行的, 这样的话能更早的暴露问题，减少延时交互的风险

接下来再讲讲其他的例子以及针对项目的风险的管理原则及一般的对策