在公司所从事的工作并不会使我对软件开发风险这个概念有什么很深的感受，但经常在游走在各大技术网站，看了很多关于软件工程方面的书，风险管理却是被经常提起的一个重要概念。今天看了一篇文章，也说一下风险管理相关的话题。
1.不随意预测未知的需求而忽视当前的任务。
软件开发从需求获取分析到最后的向客户交付，满足实际的要求。往往是比较复杂的一个过程，经常因为客户需求的变更引起结构或者框架的改动，软件开发不同于一般的工程，有时候却是牵一发而动全身的情况。所以作为程序员或者是项目的领导，不能自以为是或者想当然自己实现的功能能正好满足客户的要求，因为客户他不是专业人员，不可能对他想要的描述的和软件逻辑上完全一样，变更时家常便饭，我们能够获知的，只能是目前用户提出的各项要求，我们无法猜测下一次会是什么，这个不是做规划或者计划就能做好的。无端的抱怨和猜测都解决不了问题。甚至更不可能去提前预测实现客户将来可能的要求，这样往往导致走很大的弯路，严重的情况导致项目整体失败。最现实的做法就是先用最直接的办法，实现已明确的需求。保持尽量的简单。
2.项目领导者的关键
做项目往往要在开始时进行人员的配置和安排。项目执行中更需要合理安排人员解决合适的问题。当领导者缺少调查，直接将任务派给一个组内成员时，这种做法往往是非常危险的，特别是在一个缺少及时沟通协调的组织内部。任务依赖关系越复杂，项目的成功率就越低。往往一个任务的解决不只是一个人员的问题。假设一名成员要完成一项任务，而他不能一个人在规定的时间内完成，需要2员工的帮助，而2员工对于这个任务首先要咨询3员工，因为有些关键涉及到其他模块，3员工认为这个模块要改动会涉及结构方面的问题，最好先找个专家之类的咨询一下。因为模块方面的改动并不是很要紧，所以3员工也没有过多的关注，还是做自己的事情，过了好些天，那名最开始的员工还是没开始动手。组织内的依赖关系比较复杂，缺少积极及时的沟通。到最后发现事情拖了很长时间。项目领导者才发现这个任务牵扯太多。发觉自己之前没有做够调查工作。
3.无时不在随机性风险
世事难料。在制定项目计划的时候，一定不能只做乐观的估计。更不能天真相信一切都会顺利。必须思考各种可能的风险，并且为这些风险留出合理的时间和后背资源。发现一种方案行不通时，一定要尽快另谋出路。程序员往往会高估自己的能力与效率，当我们在项目前期时，往往觉得不需要很多空余的时间，项目的过程应该不会碰到什么大的问题，但当我们自己经历时却遇到了难题。作为领导者我们应该经常树立一种风险意识，以最大的可行性标准来安排规划时间。
说风险管理，最重要的一点，我觉得不是经常性去看相关的书籍，怎样来根据书上的方法来保证项目的风险减低。最重要的首先要树立足够的风险意识。这个意识不是简单的去了解大概有什么问题会遇到，有多少难度。然后想方法去避免它。作为领导者，首先要有大局观，能够常常关注全局的风险，而不是局限于自己的思维定式，或者说经常站在不同的立场，角度思考问题，始终理性的思考和判断，不受一时一事的影响。最简单方法是：将这种意识经常实践，养成良好的习惯，经常自我反省，严格要求，以便更好的改进管理方法，提高管理水平。有时候小小的一部操作可能会导致全盘崩溃。所以始终记得去防范风险，这个是比较困难的，要逐步努力和实践。
作为普通程序员，我们经常想的是能不能做点技术难度很高的项目，这样自己就能学的多一点，我也经常这样去思考。当然这并不错误。程序员作为技术人员往往把重点放在自身技术水平上，某种程度上会导致视野狭
隘。作为技术人员，我们经常阅读技术书籍文章，了解软件工程的方方面面，【敏捷，XP，递增开发，某某模型，驱动测试开发，风险预测管理】等等。但我们经常缺少去深入的实践和分析。只是知道有这么一个概念，至于有多重要就没有好好思考过。当然很多程序员还轮不到去思考管理过程这些事情。毕竟很多程序员还是基础程序员，这是现实。但如果你准备将来从事这个行业并在实践中有所发展，我觉得就应该随时学习和实践，认真的去尝试和分析。不是看了书就好了。古人常说，学而不思则罔。我们要经常的思考遇到的问题和概念。并从多个角度来看待问题。最重要的是实践，积极的实践，所谓纸上得来终觉浅，绝知此事要躬行。就是这个道理，实践是艰辛的，但只要你的梦在那边，那就坚持下去吧。