人们总是十分的自大而骄傲，这绝对是个致命伤!很多的人都不能准确的、有意识的做到对于风险的掌控。项目经理博客 在项目开发中总难免存在着十分多的风险，事情也绝对不会有一帆风顺的。我们不能准确的知道这个风险会什么时候到来，就好象我们不会准确的知道什么时候会地震一样，但是，基于这些风险可能对项目造成的重大影响，我们不得不硬着头皮去考虑它，预测它，即便很多时候不准确，但却十分必须!
风险管理算是个大项，它体现的细节的思考又可以分各种情况，有人员的、成本的、临时变动需求的、未预测或无法预测异常的、技术瓶颈或有其他瓶颈的、时间、效率和精力的…考虑各种各样在项目可能会有变动的点，这些地方需要额外加以注意，它们往往隐藏着足以致命的风险。作为一个项目的领导者，必须要对这些风险进行一定的掌控，以期把这些风险带来的损失降到最低。
一个真有作为的人一定是一个能战胜自己的人，能战胜自己的人也一定是一个谦虚而谨慎的人。作为领导者，团队中最有作为的人，一定要保有足够的谦虚和谨慎，才能担当重任!一个领导者在执行风险管理的时候，如果没有足够的谦虚和谨慎，那么这个风险评估也是华而不实的，甚至会带来一种盲目的期望。
当然，个人领导者的工作经验也十分必要，不过也不能过分依赖，而导致一种经验主义!一个工作经验丰富的领导者，能很快的发现项目中存在的普遍问题，能快速的分析工作业务中所发生的问题，能更加准确的评估风险，以及风险的后继影响。
需求总是第一步要执行的，首先还得从确认需求开始，一个需求都不明确的项目，成功被执行的概率，凭借着运气也只能是40%左右。开始一个需求非常不明确的项目，领导者不仅需要承担风险，而且会在讨论和修改需求方面浪费很多的人力和时间，甚至会让团队的工作激情打了折扣，往往会发生项目正式开展之时就已经疲惫了的状况。事实证明在项目实施之前，确认需求文档这个步骤是不能缺少的，并且需求文档首先要由领导者起草，领导者和特定的人员(例如有专门的需求分析人员和客户)沟通，共同完成需求草案，需求需要解决这么几个问题：1、项目名称，2、项目目标，3、项目团队和分工(成熟的团队可以略过)，4、项目面向的客户是谁?谁需要验收?(这也是质量管理的一部分)5、客户需要什么?是否已经描述清楚用户的需求，能否指导后期开发，6、定义项目性质、小大、成本或者其他术语解释…草案需要开发工程师签字，领导者签字，客户签字，老板签字。至此，需求草案才能说是正式的需求文档。其中，领导者在需求确认之前，就需要做好风险的评估，例如，是否有技术瓶颈，和开发工程师协商，解决将花费多少的时间和精力;用户需求是否合理，成本、效率、时间之间是否会有冲突;团队是否可靠团结，情况是否良好;需求是否还有没有关注的地方，还有遗漏的地方，客户是否已经描述清楚，等等。
在开发过程中，也需要无时无刻的注意对于风险的掌控，有了一开始需求的确认，需求的变动风险就变得相对可控，这个时候关键还是对于异常风险的掌控。项目中一些未知的问题，不知道哪天就冒出来了，可能就需要浪费几天的时间，几个的人力去处理它，例如在做完项目进度规划之后，突然高层说需要开会讨论一些事情，那么这时，你的进度掌控就已经开始存在风险了，你需要提高警惕了，你需要考虑这个风险会有多大的影响，发生的频率是多少，是否可控，可控的话，如何处理，是每次安排进度把进度提前安排，还是临时的重排进度?思考这些，就是你风险管理的过程。对于异常情况的处理，就是针对风险的一种管理!
开发结束了，风险依然存在，软件生命周期的末端还需要维护和升级。以前的架构造成后期维护困难，拖了维护效率和提高了维护成本，这个时候要怎么办，前期的风险评估如果到位了，那么这些风险也将是可控的…你肯定已经有点解决方案了!
使用一种新技术，确实能提高工作效率和执行效率，但是同时也意味着你的手下需要时间和精力去学习这种新的东西，要娴熟的使用某种东西是需要心力和时间的，首先，你的手下会不会愿意花精力去学，能不能够学会，学会需要多久，如果你仍然决定使用技术，那么说明你得承担这个风险，如果你控制不好，很可能，你的人员会流失，你的项目会中断。反之，长期不更新技术，不去尝试新的东西，你的手下也会觉得乏味，长期处于精神疲劳的状态，你很可能也会面临以上的风险。
总之，保有谦虚而谨慎的心态，不要试图放过任何一个小细节，那个细枝末节里就酝酿了一个又一个致命的风险，你要常常提醒自己"做最坏打算!"。当然，最最最坏的打算就也是天塌下来嘛，这点革命乐观精神还是要有的，毕竟风险只能预测和评估，不能避免!