今天参加操作系统评估，最大的感受是关于“体系化”，当身在自己项目中时，不太容易觉察到，作为一个局外人去认真观察时，却能发现不少有意思的东西。
首先，咱们面临的大多系统都是“复杂”系统，复杂系统在于，系统的输入输出不是简单的因果关系，输入A便能确定的得到答案B，因为系统是复杂的，各种相关因素互相影响，当我们面临这样一个复杂系统时，考虑问题就不得不用系统思维去整盘考虑了。
举例说明下，有了很多改进模型后，我们便很容易落入一自己的的改进细节中，比如，需求实例化，需求体系化等很多需求环节的改进。比如，质量内建的考虑，比如，测试策略的考虑，我们列举除了很多改进点，也做了不少努力，可我们做的事情是真正有效的么？我们能拍着胸脯说，做了这些改进，我们的产品，我们的项目就变好了吗？
这里的问题究竟出在哪里？
当我们思考这个问题的时候，就需要思考一下，我们的改进的目的是什么？所有的事情围绕着一个什么样的目标达成？所以，我们需要关注“价值”，需要和实际的项目痛点结合，定义出我们的改进目标，并根据改进目标进行一些根因分析，目前阻碍我们目标达成的是什么原因？通过一些系统的改进策划，比如，从深度故障复盘开始，深挖项目的质量痛点，找出根因，问题究竟是出现在哪一个具体的环节，是管理流程的缺失？还是技术手段的不够完善，亦或是测试策略的不够完备？找出根因，再根据具体问题去制定相应的改进措施。改进措施是否有效，就需要引进一些度量来给予反馈，从这条脉络下来，我们就会去考虑度量体系的一系列原则、数据、指标的建立和运用。并根据度量的结果来实时调整我们的改进措施。包括我们的需求体系化，代码质量评估体系，代码架构评估体系，CI体系等，都是相同的套路了，从问题出发，想清楚要解决什么样的问题，再谈具体的方法和实践，并根据度量持续改进我们的方法和实践。
这期间，还有一个非常重要的基础，“透明化”，项目的每一位成员都能看到相同的信息，所有的目标、改进进展、度量数据透明化，才能真正落到实处，由项目牵动，制定项目级改进目标，并由团队做强有力的支撑。比如，DOD，我们有团队级、项目级、Release级，不同层级的DOD，这些规范并不是一个页面，而是真正用于指导我们工作的规则，一开始也许我们的DOD可以很少，但我们通过不断的努力不断拓展我们的DOD，这也是团队和项目的能力提升的一个表现。
总体来说，体系化是我们复杂系统改进的一个非常重要的东西，需要时时透过表象找出问题背后的根因，再去针对性的做改进，全局的把控会显得更加的重要。
