风险管理（Risk Management），
是指通过对风险的认识、衡量和分析，
选择最有效的方式，主动地、有目的地、有计划地处理风险，
以最小成本争取获得最大安全保证的管理方法。
因此，管理风险不仅仅是一个安全生产问题，
还包括识别风险、评估风险和处理风险，
涉及财务、安全、生产、设备、物流、技术等多个方面，
是一套完整的方案，也是一个系统工程。
软件项目也需要进行风险管理。
要辩识风险，评估它们出现的概率及产生的影响，
然后建立一个规划来管理风险。
软件项目的风险主要体现在以下几个方面，
需求，技术，成本，进度。
需求不清，需求范围不明，技术细节的不确定性，
项目投入远超预算，以及不能按时交付，等等，
都是软件项目中常见的风险。
软件开发者如果仅从编码角度来看，很难有效的规避这些风险，
甚至对这些风险是无能为力的。
这就要求开发者们具备项目的全局观，从整个项目的角度看待问题。
下文我们介绍一些常见的控制点，
在这些控制点上多费些心思，可能会产生立竿见影的效果。
需求
在进行开发之前，首先要明确的是，需求是不可能不变的，
只是变化的形式不是我们通常想象的那样。
“现在让我们做这个，后来让我们做那个”，这其实是一种错觉。
产生这种错觉的原因是，我们一开始就没有理解清楚“为什么要做”。
一旦理解了需求的动机，就会发现需求从不会以截然不同的方式进行变更。
需求发生变更的方式是，更加细化，以及包含更多的场景（功能爆炸）。
开发者之所以能明显感受到需求不同是因为，
需求的细化和功能爆炸，是随着开发活动的执行而不断进展的。
因此，为了尽可能的避免这类风险，
应该在开发活动早期，尽可能的把需求细节考虑清楚，
多找几个人进行需求评审，也不要因为偷懒或者假敏捷，漏掉重要的详细设计。
这对防止需求在开发过程中发生变化，帮助非常大。
做好这一步，软件项目才能有一个良好的开端。
没有确定需求细节，就急于进行开发，那么结果必然是无法预期的。
估算
有很多软件项目工期是倒排的，指的是管理者已经事先向别人承诺了发布时间，
然后按照开发节奏，倒推某件事应该在什么时候做完。
这样显然是有问题的，但是有时候也无法避免。
人们可能会认为，在工期倒排的项目中，让开发者评估完成时间是没有意义的，
其实不然，因为就算不被要求，开发者也应该对工作量有所感知。
最起码对自己需要加多少班心知肚明。
另一方面，如果意识到不论怎么加班都无法完成时，一定要有所表现，不能默默接受。
至少应该反馈给技术负责人，这是一件无法完成的任务，
请求增加开发资源，或者删减需求。
当然发起请求跟请求被答应是两码事。
所以，重要的是向上汇报，让别人知道。
有些项目只是人为营造了紧迫感而已，目的是缩减开发成本，
那些真正紧急的项目，负责人是不会看着肯定无法完成而不管的。
自测
对自己开发的功能进行完整自测，是专业性的体现。
自测可以帮助我们更好的做好以下两件事。
（1）更好的理清需求
一个场景只有自己测过，才能有信心在用户遇到它的时候不出问题。
因此，测试的过程，就是不断的具体化用户使用场景的过程。
通过测试，我们能对需求进行最彻底的理解和补充。
（2）对进度了若指掌
通过自测，我们可以对功能点的完成程度更有把握，
要知道，一个充满功能缺陷的软件，其实在用户看来就是尚未完成的。
所以，把功能写完而期望其他人帮自己发现缺陷，这种做法本身就是高估了完成情况。
此外，自测和自动化测试其实是不同的，
自测不一定是自动化的，自动化测试也可以在非自测时由别人来做。
自测时可以灵活采用各种测试方法。
变更
软件开发项目后期，经常会遇到一些新的情况，
这些新情况，简称变更，可能会产生一系列的影响。
包括后期对需求的补充，包括发生了某些计划之外的事情，等等。
这时候及时将变更的影响范围，通知项目的所有参与者是很重要的，
软件开发不是考试，完全没有缓和余地的项目非常少见，
大部分项目都能做出一些让步，
项目本来也就是用尽可能少的资源尽可能有效的完成任务的一种实践活动罢了。
所以，我们不要默默接受某些变更，而是要让加班事出有因。
有很多新人，在遇到变更时，会选择沉默，
生怕别人认为是自己技术问题导致的延期，
这是一种归因错误。
个人的技术虽然很重要，但是要想按计划完成项目，
就得尊重当前项目中所有参与者的技术水平。
如何利用资源，显然比如何迫使人们完成能力之外的事情更重要。
积极的向上沟通，能更早的得到管理者的帮助，
及时调整时间，增加人手，
完不成项目管理者也有责任，不要把责任都揽到自己身上。
发布
在项目收尾阶段，要么已经离截止日期非常近了，要么项目已经延期，
如果上文提到的中控制方法，进展足够顺利的话，
可能这时候能稍微好过一些。
但即使控制的再好，收尾阶段的开发节奏也容易被打乱，
这是因为大部分项目直到收尾阶段才开始考虑取舍问题。
实际上，取舍问题应及早考虑，事情总有轻重缓急，尽早列出任务的优先级。
此外，在发布阶段还容易做出明显不符合软件规律的荒唐事，
比如为了按时发布软件，有人可能会建议先把软件发布，然后再修复缺陷。
我承认，在某些极端情况下，这也不失为一个行之有效的办法。
但是，要谨防给出这个建议的同事，他能否承担缺陷造成的损失，
有些人只是说说而已，结果最后的损失还是由开发者团队承担。
那么，这种情况下，我们应当学会为自己的行为负责，对不合理的建议说不。
结语
软件项目的风险管理是一个很宽的话题，也是一门很深的学问，
本文只是粗浅的进行了一些探讨，
主要包含了自己在软件开发过程中的体会和感触。
在风险控制点上的一些建议，是我多年踩坑经验的总结，
在执行过程中，也发现确实能有效的避免典型问题。
当然我知道只做这些还是远远不够的，
不妨存疑于来日方长，
不断积累和学习，一起成为更成熟更专业的软件开发者吧。