第一章 编程的精义
愚公移山项目，原始需求的产生：“惩山北之塞，出入之迂”
项目沟通基本方式：“聚室而谋曰”
项目目标： “毕力平险，指通豫南，达于汉阴”
可行方案：“扣石垦壤，箕畚运于渤海之尾”
项目中有三名技术人员和一名工程管理人员： “（愚公）率子孙荷担者三夫”
外加一名力量较弱但满腹激情的外协： “邻人京城氏之孀妻，有遗男， 始龀，跳往助之”
以上就是愚公移山整个工程的概况。接下来，愚公向智叟叙述了整个工程的编程实现：
“虽我之死，有子存焉”——IF条件语句
“子又生孙，孙又有子……子子孙孙，无穷匮也”——循环结构
作为优秀的程序分析师，愚公清楚明白由于“山不加增”，所以“何苦而不平”，因此这不会是一个死循环。
在愚公的论述中，我们看到了编程的根本：顺序、分支和循环，这，就是编程的精义了。
编程作为一种行为，我们只需要知道其逻辑方法就可以了。所谓编程实际上就是把一件事交给计算机去做，你只需要用“程序语言”描述 给计算机该如何完成这件事。
编程第一要务就是先把事情分析清楚，把事情先后的逻辑关系和依赖关系搞清楚，然后再去写代码实现。
记住：积极工作和勤于思考都要占时间。
第一个完成编程本质思考的人提出公式：程序 = 算法 + 结构，这个公式未提及代码，甚至可以说，在这个公式里，代码是不存在的，存在的只是思想。
算法是对一个程序的逻辑实现的描述，而结构是逻辑实现所依附的数据实体，开发人员只要将算法设计出来，把结构描述出来，剩下的就是劳力活了。
第二章 是懒人造就了方法
人的精力终归是有限的，提出新的“方法”，解决的是影响做事成效的根本问题。
程序 = 算法 + 结构 + 方法
在面向过程的开发中，“过程”是CPU提供的，“单元”则是编译器提供的机制，程序员无须（至少不是必须）再创造什么“方法”，就可以进行愚公式的开发工作了。
第三章 团队缺乏的不只是管理
三个人便可以构成团队，这样便有了团队的一些基本特性：主从，监督和责任。
做管理起码要能承担责任，这是最基本的素质。
从管理的角度来看，项目失败与否与项目经理的经验直接相关。
项目的成功是由两个方面来评估的：项目完成质量，项目完成时间。
项目工期的问题不能解决，就不能保证项目成功。只有经验更加丰富，才更有可能逼近“合理的工期”。在这之前，项目经理面临的就是失败，这个失败可能不是由项目经理本身的能力所决定，或者也不是由团队成员的工作决定，可能在一开始那份给客户的项目协议就签错了。
因此，项目经理是需要时间来成熟的。他需要机会来承受错误，而不是一开始就享受成功。
只有有了确定的团队模式，才能寻求相应的管理制度，并且才能把这样的制度实施在团队之上。
组织模式确定的同时，相应的制度也随之建立，很少有组织几年之后才来补制度的。
明确组织机构，既是团队的关键，也是我们思考问题的基础。
精简团队模型：R模型：
在保障这样一个组织机构模式的过程中，以下几点内容是需要注意的：
1. 如果项目针对直接客户，而且没有产品化的可能性（或必要性），那么可以将与市场（以及市场部门）相关的问题和角色先放一边。
2. 已经存在于开发团队中的成员，不适合在品质部门中兼任角色。
3.（在这个模型里）项目经理应致力于减少团队中开发角色与其他部门的沟通、必要时开发经理应该站在开发人员之前进行部门间的交互。
4. 品质部门、文档和培训部门以及客服部门应该主要由专职人员构成，尽管开发人员可以（或者经常会）参与文档、培训和客服的工作，但这也通常是他们最不能胜任的角色。
5. 这是中小型规模的公司和团队的参考组织机构模型，对大型团队并不适用。
在这个模型中，我们仍然看到一个至少由三个人构成的团队。其中，在开发经理和开发人员之间，既存在主从关系，也存在协作关系。而项目经理，则在团队中处于领导者、组织者和团队保障者的地位。
实际上，开发团队并不需要管理，或者说，在你还没有弄清楚状况之前，不要去管它。
协议并不能建立管理者与被管理者的信任，而只是确保了这种关系。
如果有一群开发人员像蚂蚁一样辛勤地工作着，那么，请先不要打扰他们。你应该跟随他们，看看他们是如何做的。发现规律，分析这个规律的价值，最后再尝试改变他们（的一些负面价值的规律）。
你已经确定了组织结构，确定了组织中的角色，还有一个团队的人，作为项目经理，你需要先分工。分工之前，那个团队只能算是一个没有组织与合作的群体。