软件行业里有一本名著叫《人月神话》，其中提到两个非常重要的概念：本质复杂度（Essential Complexity）和偶然复杂度（Accident Complexity）本质复杂度就是解决一个问题时，无论怎么做都必须要做的事，而偶然复杂度是因为选用的做事方法不当，而导致要多做的事。大部分程序员忙碌解决的问题，都不是程序问题，而是由偶然复杂度导致的问题。
在软件行业发展过程中，积累了大量的最佳时机可以减少程序员在日常工作中由于偶然复杂度导致工作量倍增。但这些最近实践往往零散，如何建立体系化的思维以系统的提升工作效率呢？
问题思考框架：
现状目标实现路径软件开发是为实现用户需求，在接到产品经理的功能特性时，我们可以按照如下的思路与原则来思考。 现状
接到软件开发需求，现状是什么？
目标
为什么要做这个特性，它会给用户带来怎样的价值？什么样的用户会用到这个特性，他们在什么场景下使用，他们又会怎样使用它？实现路径
达成这个目的是否有其它手段？是不是一定要开发一个系统？这个特性上线之后，怎么衡量它的有效性？而在这个思考框架之下，我们可以不断的应用如下几个原则 以终为始； 任务分解； 沟通反馈； 自动化。 其中 以始为终是针对目标，任务分解，沟通反馈，自动化是针对实现路径。 以始为终： 对做软件的人来说，我们应该把“终”定位成做一个对用户有价值的软件，能够为别人带来价值，自己的价值才能体现出来。
最佳实践一 在日常工作中，我们在布置任务的时候通常由于任务安排人与任务负责人在对任务完成的定义上理解不一致，导致任务最终交付的时候存在巨大的偏差。如何解决这个问题呢？ DoD：（Definition of Done）定义完成 而在软件开发中，我可以按照如下的套路对各个阶段的完成进行定义： 特性开发完成，表示开发人员经过了需求澄清、功能设计、编写代码、单元测试，通过了测试人员的验收，确保代码处于一个可部署的状态，相关文档已经编写完毕。 开发完成，表示开发人员编写好功能代码，编写好单元测试代码，编写好集成测试代码，测试可以通过，代码通过了代码风格检查、测试覆盖率检查。 另外为了便于检查与实际应用，我们可以指定一个DoD的清单。清单是由一个个的检查项组成的，用来检查我们的工作完成情况。
