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

对我来说，软件项目的目标和风险管理是项目经理应该时时刻刻最关注的，你的价值很大程度体现在如何管理好项目风险，实现项目目标，这也是我写了几篇关于风险管理的文章的原因。

还是以一个实战的项目实例来回顾一下我是如何管理项目风险的，希望能起到抛砖引玉的作用。

项目背景:

去年五月份收到一个新的项目需求，是为监管机构开发一个基于外汇交易的外汇盯盘价。由于公司刚刚丢了一个大单，而这个新的需求是从新加坡拿到的一个新的大单，考虑到基于交易数据的盯盘价是今后金融界发展的趋势，所以公司高层对此特别重视，连CEO都亲自过问。可能迫于市场和监管机构的压力，我们的业务部门过度承诺在8月6号上线，可以说这个项目只许成功，不许失败，但是时间还是很紧的。

项目团队:

这个项目涉及到不少团队

业务(Content)部门: 从客户那里收集需求

两个业务分析(BA)部门 (一个是数据业务方向的BA，一个是技术方向的BA),: 把业务需求转成技术需求给开发团队，同时做数据的鉴定,为什么要有两个BA部门来参与，其实是有些政治原因的，之后再详谈。

两个开发团队:分别收集交易数据和核心的盯盘价开发，我们团队是在核心系统上面的开发团队，暂且成为团队A吧，另外一个开发团队是把场外交易数据通过主网络发给我们的核心系统来处理计算)，我称它为团队B

一个数据维护部门: 数据的鉴定以及数据上线后的日常维护

一个运维部门: 负责系统的安装和维护，如果需要手工修改数据，他们有权限上系统执行

还有一个业务部门的PM: 负责整体的进度和客户的沟通

我是负责核心系统开发的PM,主要负责我们核心系统的开发进度

由于资源有限，我们只争取到了两个开发人员，而且都不是全职的，各有50%多的时间能放到这个项目里，没有QA，两个开发人员其中一个做测试。

项目风险及预防:

从接到项目的时候我就判断出这是一个高风险的项目，为什么呢？理由如下

风险1. 时间紧资源少，我们仅有不到三个月的时间，但是我们这边的开发人员只有两个，而且都是工作经验不是很丰富的程序员，不是全职做这个项目

预防方案: 

1) 首先向领导申请调配资源，这样两个开发人员可以在项目开始的前几周先80%左右的时间做这个项目，保证加快初期的开发进度。

2) 其次把需求细分以便两个程序员可以并行开发没有关联性的子需求，互相留好接口再合并。

3) 资深开发人员做代码的review, 把握好大的架构方向和质量控制

风险2. 一个全新的数据和项目，两个开发团队以前没有做过类似的可供参考的数据以及项目，可以预见需求的变化风险比较大，因为业务部门的人可能也不大清楚应该做成什么样的，很多细节问题可能需要在做的过程中确认。而且技术的风险也不小，尤其是两个系统的结合可能会有问题。

预防方案: 

1) 一般我们都是按照BA的需求文档来做开发的，但是由于这个项目的特殊性和复杂性，我决定开发一起审查业务部门的初始需求和BA的需求，防止信息在经过多层之后的失真或者误解. 

2) 同时我们也审查业务部门发给团队B的需求，因为如果他们发给我们系统的数据有问题的话，那也会影响最终项目的成功, 我们要做到的就是理解整个端到端的数据流和技术，更好地预见现在还未知的风险. 

3) 把需求细分划分优先级，先把主要的需求实现，尽早让业务部门做数据验证反馈从而尽早地发现需求的问题，控制变更风险。同时有些不是很关键的需求如果在规定时间内完成不了也不会对项目造成致命的影响，比如说有个需求是如果今天没有交易的话，那么就把昨天的数据当成今天的数据计算结果，我们分析了将近一个月的数据，没有发生过这种现象，所以这个需求如果实在实现不了，影响也不太大，而且万一真的发生了，我们还可以快速的人工来更新数据。 

4) 争取能在正式上线前至少两周和团队B的系统联调进行端到端的数据的验证，尽早发现问题

5) 程序架构设计上尽量模块化，松耦合，这样能比较快速地响应需求的变化，不会牵一发而动全身。

风险3. 涉及的团队多，跨英国，新加坡，北京，印度，沟通成本高，尤其是我们团队A和团队B以前没有合作过，互相对对方的系统也不大了解

预防方案:

1) 由于两个开发团队和数据维护部门都在北京，而BA一个在新加坡一个在伦敦，如果BA W能来北京的话，那么将提高我们的沟通效率，最后他申请来到北京工作一个多月直到数据上线没问题之后才离开

2) 以前的项目一般都是BA代替开发团队参加，对于这个项目，我主动要求我们团队也加入到他们每周一次的会议里保持项目的透明度 

3) 由于团队B和我们在一个办公室，我们主动和团队B建立起了联系，BA发给我们的需求我们都刨根问题地和团队B确认他们业务逻辑上为什么要这样做，技术上是怎么实现的

4) 由于团队B需要把他们收集的数据发到核心网络里，而他们并没有这方面的经验，但是我认识其他的开发团队有比较丰富的数据接入经验，我给他们介绍了专家帮助他们更好地了解了技术的难度和风险

风险4. 测试系统和测试网络的不稳定

预防方案:

1) Escalate 给高层，在有问题的情况下，争取网络维护团队的最高优先级的支持。以前出问题的时候可能等几天才给我们调查解决问题，现在基本上能在当天反应解决了

2) 调用内部的机器来做虚拟机，可以不影响内部的开发和测试

3) 正式发布给客户前两周装到production 机器，把数据设为对客户不可见，这样保证有两周的时间能在很稳定的环境在做数据的端到端验证

风险5. 两个BA，其中一个BA (我称他为P)是我们核心系统的BA，以前所有核心系统的需求都经过他发过来，另外一个BA (我称他为W)是专门做盯盘价的数据的BA。从流程上来说需求是这样走的 

团队A业务需求: 业务部门->BA W->BA P->核心系统开发

团队B业务需求: 业务部门->后台源数据开发

这样看来其实BA P的存在是降低了整个项目的效率，所以并没有太多存在的价值，而且他们是在伦敦，其他的团队都在北京和新加坡，所以从沟通上来说也是多了一层。

预防方案: 这个就属于政治层面的风险了，不大好处理。我当时采用的方法就是逐渐把BA P边缘化，和他们两个BA约定好一个需求模板，这样的话BA W的就能直接写我们开发熟悉的需求方式，同时由于BA P在伦敦，正好利用时间差我们有理由直接和BA W讨论需求，不过我们会把BA P放在cc list里保证项目的透明度，最后BA P也意识到自己的作用有限主动放弃了这个项目。

项目过程及总结:

到快上线的前一天，我们发现没法处理交易被取消的情况，这个问题在几周的数据验证中没有发现是因为出现的次数很少，仅有的一两次可能也被BA忽略了因为有时候算出来的最终结果也能对的上，前期的内部测试阶段由于我们自己模拟的数据没有按照真实的数据格式来发所以没有发现，这是由于对上游发过来的数据格式理解的不够深刻导致的。

我们两个开发团队赶紧讨论解决方案，最后决定由我们团队来修改处理逻辑，但是其实我们对这个修改不是很有信心能在一天之内上线，而且也没有经过真实数据的验证。所以和业务部门商量之后还是决定在测试系统上经过周三的真实数据验证上线，而在之前我们和团队B来进行模拟的端到端的数据测试。然后在上线的当天，我们监控每一笔的交易，一旦发现有取消交易的情况，马上手动修改系统内部缓存的数据，果然发现了一笔这样的情况被我们及时的修改，谢天谢地最终的数据正确的发布了，CEO也发来了贺电。这个教训比较深刻，我们由于时间紧没有和团队B在上线前做联调，完全依靠真实数据来验证真个逻辑，而有时候某种业务场景并不一定每天都发生的。如果项目能够重来一次的话，我想我们会更加加强两个开发团队之间的知识共享和合作，比如我们也给团队B介绍我们的系统特点，同时安排好时间测试每种业务场景，如果项目时间很紧，我们可以每个业务场景选择一两个例子来测试

另外你不需要成为所有领域的专家，这也是不现实的，但是你得认识专家，知道有问题的时候找谁能快速的定位和解决问题