软件开发的最大风险及应对策略
今天早上为了支持一个项目组解决一个紧急的线上问题，被电话叫醒了。问题很快解决了，我的睡意也没有了，就准备把之前想写的《软件缺陷成因分析》的文章给写了。
当真正开始码字的时候发现思路还是不够清晰，就翻阅之前在印象笔记里面收藏的相关资料。在翻阅资料中无意中读到了一本非常好的电子书籍，据说是微软软件工程师的必读之书，作者具有30多年的软件开发经验，也是微软的员工。
英文名称 M.Wright's "HardCode" :A Decade of Hard-Won Lessons from MicroSoft，作者 Eric Brechner
中文名称《代码之殇》，翻译 林锋
在《代码之殇》的第一章Eric 提到了软件开发的精确估算根本不靠谱，项目经理只需要关注里程碑时间节点即可，关键要做好开发过程中的风险管理。
我看了很有共鸣，结合自己这么多年软件开发的经验，跟大家分享一下我的看法和理解。
软件开发最大风险：不能在承诺的时间把合格的软件交付给用户使用。
软件开发的过程本质上就是通过相关的方法和手段来化解和降低这个风险。
应对策略一：聚焦最必须的功能，关注让用户满意的最小功能集合。
我们需要集中优势兵力来降低这些必须功能按时交付的风险。因此，在做项目版本计划的时候，要把这些最核心的功能梳理确定下来，并与业务经理取得一致意见，有经验的业务经理一般都会同意这种处理方式。
事实上如果真坚持这么做，客户才是整正的大赢家。因为，他在期望的时间内得到了最想要的功能，同时软件质量也得到保证，而不是匆忙实现的、质量不可靠的垃圾。
在这里要给项目团队提醒的是，每个项目经理几乎都认同这个观点，但是在实际实施过程中还是会存在一些枯燥的但是必须完成的工作没有充分考虑到，从而导致项目发布的一再延期。这些工作包括部署环境的准备、非功能性指标的满足、测试代码的编写、发布脚本的准备等等。
应对策略二：关注关键里程碑时间节点，忽略具体开发任务的完成时间。
过分关注详细的每个开发任务的完成时间，会给项目经理造成错觉，丢失大局观，忽视对关键工作的风险管理。
事实上我们无法做到精确的估算。除非一个功能非常简单（比如只有10代码规模）或者代码从以前的模块中复制过来，否则几乎不可能精确估计到底需要多长时间。
因此，项目经理更多的关注点是如何充分调配资源，降低关键功能的实施风险，以保证里程碑目标的实现。
应对策略三：关注其他三类情况
1、过度劳累的开发人员
每个项目组内部肯定都会存在交付能力差别比较大的开发人员。项目经理往往喜欢把关键任务分配给开发效率高、质量有保证的开发人员。这样做本身没问题，但是一定要注意所分配的工作是否超负荷。
我们的一些开发人员很可爱，往往不会直接拒绝主管所分配的超负荷的开发任务，但是作为项目经理一定要有一个清晰的认识，否则由于超负荷而导致的延期交付、质量问题，损害的是整个团队和客户的利益。
2、时间不够、匆忙实现的功能。
这部分的功能如果是关键功能，一定要做好必要的review和相关的单元测试、功能测试。我们想当然的认为代码改动不大，风险较低的功能点，往往会给我们带来较大的灾难。
3、复杂的功能
这些复杂的功能，往往涉及的业务流程长、关联系统多。通常要动用2-3位高级开发人员花费几周时间来解决。根据我的经验，这些复杂的功能，经常在流程设计、在途数据处理等方面会存在问题，往往要在发布多个修订版本后，才能保证整个业务流程顺畅运行。
希望这篇短文能给你带来一点帮助，也欢迎关注我的公众号给我留言沟通。
《代码之殇》的免费电子PDF版本可以通过下面这个地址下载
http://www.infoq.com/cn/minibooks/i-m-wrights-hard-code
也开始点击“阅读原文”查看infoq网站对这本书的介绍。