第36节
主要讨论了在项目开始之前的一些准备步骤和流程。作者强调了需求识别的重要性，并提出需求是与用户共同完成的“发现”过程，而不仅仅是收集他们的意见。需求在某种程度上应该保持抽象，因为需求不等同于架构或设计。作者还提到了一个词汇表的维护，这是为了消除歧义，并确保大家对需求有共同的理解。此外，项目的需求文档应该在内网上公开，这样所有的相关人员都可以访问、查阅，提出他们的意见和建议。
第37节
这一节为我们提供了一个新的思考方式，那就是如果面对一个看似无法解决的问题，我们应该转变思路，尝试去找问题的本质，看看能否通过重新定义需求来使这个问题消失。
第38节
鼓励我们在遇到重复问题时，尽快解决，我们可以通过快速构建原型、迭代，并寻求更好的解决方案。
第39节
关于编写规范的问题，作者警告我们不要对开发者设置过度严格的规定。过于详细的规定可能会限制开发者的创新能力。
第40节
提醒我们要对先前设定的限制有所认识，并努力不让自己被陷入细节，陷入微不足道的部分而无法全面观察问题。也不能盲目地运用所有的技术，而是应该根据实际需求来选择最合适的。