离岸开发-进行风险管理

什么时候需要风险的管理？任何时候。

很多人做项目是保持的乐观的状态来作：这个简单，弄一弄就行了；那个不难，找个人做就行了。

有这么一句话：思想上轻视敌人，战术上重视敌人。

没错，我们可以保持乐观的状态来做项目，但是战术上则千万不能乐观。正所谓：生于忧患，死于安乐。

当一个项目开始的时候，除了明确工作内容之外，首先就要去找风险。其实每个项目都有风险，就看你能不能找的到。
找到了，那么风险造成的损失就会降低；找不到，那么在后期，这个风险随时可以造成一个大麻烦。

我们曾经做过一个项目，这个项目的特点是谁都没有掌握业务逻辑。因为我们要在一个既存的系统上做该修开发，而这个既存的系统又是如此复杂，我们没有掌握，onshore也没有掌握，就连有些功能客户也搞不明白。

于是我们就开始开发了。我们做影响分析，做设计，写代码，测试。过程是辛苦的，结果也是痛苦的：最终在产品环境出现了5个bug。

当然onshore不会满意，客户也不会满意。但是我们已经尽力了。

这里面出现的最大问题就是我们没有进行有效的风险管理。

其实offshore也是人，并非一个个都是天才，面对如此复杂的系统，在有限的时间内，完成大规模的改修开发是非常困难的。

我们最初应该就去分析这个风险，如果能识别出来这个风险，那么要报告上去，报告给谁呢？报告给所有负责的人：领导，onshore，甚至是客户。

目前这个风险就是：没有谁真正掌握这个系统。如果以当前的成本，当前的期限，最后难免会有bug。我们最终需要的结论是：

如果客户能接受，那么我们就做。否则，就需要增加成本和时间。

如果客户不能增加成本和时间，但是还要保证质量，那么onshore是否有什么方法避免这个风险，例如找个专家。
如果onshore也没有办法，那么领导是否有办法，如果增加人手，加班，当然最后这个项目利润会降低。
如果领导也没有办法，那我们也没有办法了，总之风险已经共享给所有有责任的人了，大家都了解这个风险，如果风险仍然不能规避，那我们就需要承担这个风险，责任者也就不单单是开发人员了，领导，onshore，客户，都会分担一部分责任。

在之后的项目，我们学会了风险管理。项目一开始，我们就会创建一个管理风险的文件。
后来的一个项目，同样是我们谁都不会的系统，我们只是掌握了皮毛，要进行开发的话，可以参考既存的一些功能。但是内在的实现，是否会有问题就很难把握了。

这个项目一开始，我们就分析到了这个风险，并且及时的把这个风险与onshore共享了。
onshore通常来说不会拒绝这种积极的态度，他们和我们一起想规避风险的办法。最后决定使用用户提供的数据在用户环境测试。如果用户提供的测试数据测试没问题，我们就认为我们的开发没问题。

onshore把这个风险和方案向客户进行了说明，客户也表示理解，同意了这种方式。
当然，这个项目进行的过程中，也有一些其他的风险，我们都及时发现，并且分析规避方法。最终，我们得以顺利的完成这个项目。

不过，风险管理是要修筑一个铜墙铁壁来保护自己的利益吗？

例如有一个项目，offshore考虑到了各种风险，每种风险都与onshore进行了说明。最后的效果就是不管出任何问题，责任都是onshore的。

这种风险意识与自我保护好是好，但是从onshore的角度来看，与offshore的合作太累了，最重要的是offshore体现出的价值太小了。

不要只是把风险管理当成是保护伞，同时思考、提出解决方案才是正确的方式。

风险管理，是一种有效的保护措施，保护了自己，保护了项目，保护了自己团队和onshore之间的信任关系。