8年前，我做软件产品的开发的工作，软件开发是一项复杂度很高的工作。像Windows操作系统，是分散在全球大大小小的很多公司，几万人，经过很多年的研发，密切协作才共同开发完成。因为它的规模大、风险高、强调合作，致使软件开发这件事情就成了一个非常需要统筹规划，逐步实施的一个工程。
软件工程的开发模型大致有两种方式：第一种是瀑布型开发模型，即：概要设计-详细设计-代码实施-测试-部署，这几个步骤，然后针对这几个步骤划定工期，逐步实施。
- 概要设计主要是确定需求，拆解功能，划分模块（这阶段极像少儿编程中的项目分析，画思维导图）；
- 详细设计是针对本模块，要计划通过什么样的技术一步步做出来（这阶段极像少儿编程中的角色动画分析，画流程图）；
- 代码实施就是按照概设、详设，编写代码，做出功能。
- 测试：就是验证软件是否符合设计，调试缺陷的过程。
- 部署：就是上线，开始使用。
瀑布型开发模式是一个非常成熟的项目管理方式，对于需求变化不大，进度、人员可控时非常适合。但是这种方式也比较理想化，在现实中，经常后期会有需求更改，后期风险前期预估不足，进度不可控，人员调配不可控等等事情发生，导致项目失败或延期。
随着行业的发展，出现了一种原型迭代开发模型。即我先做出一个实现关键功能的原型出来，根据这个原型进行评审-修改-再完善，进入下一个迭代周期，把完善好的再作为原型进行开发。整个过程形成螺旋形上升，逐渐完善的开发周期，直至项目完成。
这种开发模型的好处在于，即使后期发生大的需求变更，也不会因为前期规划不足导致返工。不会因为过程中的风险，导致项目失败或延期。
其实两种开发方式都可以完成项目，但是理念的不一样，进而做事情的方式不一样。有意思的是，现在在生活中或者工作中，也存在着这两种理念风格，两种风格理念决定着做事情的方式也不相同。
瀑布模型和迭代模型，两种模型不是零和博弈，非对即错，而是可以相互融合，互相支撑的综合体。
迭代的模型在工作、生活的过程中都是普遍存在的，这种发展方式更像是自然界中的进化论，事情的推进和走向，可能都不是在开始就决定的，是随着事情的推进而演化的，我们也都希望这种演化朝着好的方向去发展。
所以逐步形成自己做事情的思路：考虑要推进一件事情的时候，首先考虑这件事情的靠谱度，如果不靠谱，则需要再积累，把各种因素都往概率高的方向推进，直到靠谱度达到自己的预期；如果凭自己经验判断此事情在6成-8成左右（根据个人性格），这件事情就可以做起来了。
在事情做起来了，就可以努力把事情向自己期望的方向推进。
在事情发展的过程中，在行动落实的时候，可以采取规划-计划-实施-反思-调整这样的瀑布模型来做事情。这样善于把事情做好，把关键点做好。
在事情发展的过程中，肯定会有困难，有问题产生，这是客观规律。重要的是对待问题的方式，我们要把问题和困难当做事情的一部分。现接受自己现在的自己，然后提升自己的能力，努力把问题解决掉，通过反思，不要在发生类似的问题，然后迎接下一个阶段。
通过这样的螺旋迭代，逐步完美的模型，推进事情发展。