描述：有时候看似笨拙而浪费时间的撰写需求方法，反而是最省力的。正所谓“磨刀不误砍柴工”。
很多初级产品经理往往会产生这样一个错觉，这个需求已经很明确了，甚至都是常识性的一些东西，不需要逐字逐句的将每个按钮的具体含义、数据来源、交互逻辑、权限控制逻辑写在需求中了。或者为了所谓的敏捷开发，只需要口头跟所有的研发和测试说清即可。短期内看似提高了效率，而下文将列举几种场景是会导致这样做出的需求是在降低团队整体的效能。
当我们在做一个需求时，是需要保持很高的专注度和思维敏感度的。而此时，倘若在插入一或多个需求进来，将如何处理？我们可以按照紧急程度和重要程度将需求归类（重要且紧急、重要不紧急、紧急不重要、不重要不紧急），并且进行优先级排序。
但是此时我们的思维其实是已经碎片化，当一天内大脑进行“多线程”工作时，我们就需要把每个版本的需求尽可能详尽的写出来，以防止被打断思路后需要很多的回想时间。
场景二：多次反复修改需求
无论是初级产品经理还是资深产品经理，需求大多数情况下不会一次性尽善尽美。都是需要在和产品团队其他成员、研发部门、测试部门、业务部门进行多次的沟通，输出符合当前业务需求最合理的方案。即使需求写的“尽善尽美”，在开发过程中，也可能会因为一些未知因素导致需求的变更。
这个时候，不仅是需求中的每个细节都要详细描述，最好是有较为清晰的变更记录，包括变更内容，变更原因等。不然很可能发生这个需求改过后一段时间，就忘记了当初为什么要这样改（尴尬脸）。
场景三：团队中增加新人
这个应该是最好理解的一个场景。需要注意的是，团队中增加新人包括常见的招聘新人、其他部门转移过来的人，还有本来不在项目中的人（没有听过评审）新加入这个项目。为了新人能快速上手工作，需求当然是要以写给“白痴”的标准来。
下面是两个反面的例子，我在做需求时，已经尽力以“白痴”的标准去描述需求，但还是会有一些意想不到的小插曲。
案例A：在做一个积分商城后台需求的时候，由于需求反复改了几次，和业务部门沟通以前有些写好的需求在此版本中不做了。按照我的习惯会用一个灰色遮罩将不需要的功能遮住而不是直接删除，因为这样可以记录下来这个需求演变的过程，再次启用的时候也方便查找。我没有对灰色遮罩的含义进行说明，就对研发和测试人员造成了困扰，这个在我的认知中属于“常识性”的规则，现在已经被打破了。所以在之后的需求版本中，我会做一个全局说明，特别标明一些标注的含义。
案例B：在进行一个需求描述的时候，涉及到两类商品的金额，我的需求描述中是显示“A类商品的金额+B类商品的金额”，我想表达的含义是显示两个金额中间用+分隔，但是研发将两个金额相加显示。这个案例给了我一个经验，写的需求的时候自己要多读，看看是否有歧义句的可能，并且在写完规则后有一个举例，就会降低歧义的可能性。
凡事无绝对，如果有一些特殊情况，也不用执着于“白痴”般的需求。方法不是目的，结果才是目的。能够快速高质量的将需求完成上线才是最终目的。只是别忘了在上线后，将产品文档补充完整，也是对自己需求的严谨性做的再一次检验。
