才两天，这么多浏览量了，挺意外的。
写本文的目的主要思考一下工作中切实遇到的问题。
公司是大型网站，这几年发展很快，而一些基本方面却变化不大，越来越不适应敏捷开发，项目扩展，快速满足需求的特点。
包括：project目录结构，开发框架，构建过程，设计文档规范等等。 因此自己思考为什么炫目的前沿技术项目起了很多， 而很少人愿意进行这些很有挑战，但很有价值的重构项目？
本帖子就是自己思考的一点心得和体会。核心还是对于“拥抱变化”的认识，变革的价值，变革和风险的权衡等问题上。
1. 问题
我们的项目是大型网站，目前看还存在很多技术，过程问题，但变革和重构项目为什么很少人愿意做呢？ 思考ing
2. 分析
目前，前沿技术项目名称很炫，比如：云计算，分布式计算，分布式服务等，然而重构项目却比较朴实，技术领导给予的重视程度不够，KPI分量也比较轻，可能是大家做重构项目意愿较低的原因吧。
重构意味着要打破陈规，对现有项目动大手术。 要排以前的很多地雷，存在很大风险，容易出现A类故障. 而对重构项目的价值评估体系不够，KPI考核缺乏故障忍耐及变革奖励机制，因此架构师做重构项目的意愿不太高。
3. 对策
对重构项目可以按 必要性，紧迫性，风险性建立评估模型。 对高风险的重构项目，例如：数据模型变更，开发框架升级，核心产品架构重构等可以按等级给予豁免故障分，通过创新制度鼓励“拥抱变化”。 这一点需要向 Facebook 学习。
即便一些项目不存在风险，例如：开发过程优化，提升效率的工具优化等，其带来的研发效率的提高，成本的下降是非常巨大的。但价值评估不够，KPI比重不够。
因此在对前沿创新和研究项目给予同样重视的待遇下，对重构项目项目按必要性，紧迫性适当提高KPI分值，可以提高架构师启动重构项目的意愿。
4 重构项目评估模型
1） 必要性和经济效益：1-10
分值越大，代表经济价值越大，如生产效率的提高带来的人工成本，运营成本，硬件成本的降低。
2） 紧迫性：1-10
分值越大，代表越紧迫。这主要是衡量机会成本。例如：早6个月完成，就可以带来 6 个月成本的降低和价值。机会成本通常是IT公司比较会忽略的因素。
3） 风险豁免值：1-N ( N 为最大故障分 )
主要用来评估风险值，进而评估重构项目的风险豁免值。 用来鼓励软件工程师启动重构项目的意愿。
注：值范围： 1-100
当 故障分 < 风险豁免值 时，重构项目考核的 KPI 仍然可以保持正数，工程师的考核不会因为出现一定故障而导致绩效下降；
当 故障分 > 风险豁免值 时， 说明故障超出了可预先商定的容忍范围，会适当影响工程师的绩效。这样可以约束工程师加强重构项目的质量和风险控制。
5. 总结
工程师通常会比较专注做事，而不善于包装。因此，项目经理或技术领导应该辅导帮助，进行项目的价值评估，例如：采用一定模型，对项目的人工成本降低，开发，发布效率的提升等经济价值进行分析。