第七章：在项目开始之前
在项目开始前，要确定你的各种需求。
36、需求之坑
在项目开始前，你需要充分了解项目的各种需求，找到真正的需求。需求是对需要完成的某件事情的陈述。一下陈述是好需求：
- 只有指定人员才能查看员工档案。
- 汽缸盖的温度不能超过临界值，该值因引擎而异。
- 编辑器将突显关键词，这些关键词根据正在编辑的文件的类型确定。
同时学习用户一样的思考，深入用户需求，为自己的项目找好需求。
建立需求文档，制订报告模板，为项目范围增加限制，以防止项目的范围的增大。
使用项目词汇表，确保各个员工的代码编写不会发生冲突。
37、解开不可能解开的谜题
面对看似不可能解决的问题，一定要转换思路，不要受任何先人之见影响。
不要在盒子外面思考，要找到盒子。有时你会发现，自己在处理的问题比你以为的要难得多，总会感觉一定有更容易的方法。
这时你可以退回一步，问问自己：有更容易的方法吗你是在解决真正的问题，还是被外围的技术问题转移了注意力这件事情为什么是一个问题是什么使它如此难以解决它必须以这种方式完成吗很多时候，对需求的重新诠释能让整个问题全部消失— 就像戈尔迪斯结。
38、等你准备好
当你遇到一个反复让你疑虑的问题，需要注意它，给自己时间去理解，之后它可能就会变成某种更坚实的东西。
对于某些东西，我们可能不愿意轻易做出承诺，总希望再等等，更多意见的提出。但这很可能是一种拖延，怎么区分是有效的等待还是拖延的接口呢？我们应该快速地构建原型，并进行推延，可能很快我们就找到了更好的解决方案。
39、规范陷阱
写规范是一项重要的职责，但问题是很多人可能会陷在这里，不断地增加规范项。
我们可以做这样一个尝试，写一份简单的描述，告诉别人怎样系鞋带。这可能是一份并不能帮助他人的描述，因为对有些事情“做”胜于“描述”。
因为无意识的行为更快，考虑规范反而会拖慢进度。对待开发文档也一样，不要编写过于详细的规范。因为很可能开发者在思考某个问题时会想到两种不同方案，经过简单对比，选择一个更优的那个。
但面对严格的规范文档，一步步思考，这更可能束缚开发者的发挥。
40、圆圈与箭头
设计文档里的圆圈和箭头用来解释他们指代的作用，但这还有可能是推翻我们原先设定的证据。
感觉这个是承接上一节的内容，不要被以前的假设和设计所限制，留有一定的弹性空间。
我们相信，盲目地采用任何技术，而不把他们放进你的开发实践和能力的语境中，这样的处理日后可能会让你后悔。不要迷信工具以及各种方法学，注重实效的程序员会批判地看待他们，并从中提取精华，融合成每个月都在变得更好的一套工作习惯。
标签：需求,项目,小工,规范,问题,程序员,可能,文档,修炼 From： https://www.cnblogs.com/JJTyyds/p/17007575.html