需求开发是描述清楚用户想要什么（What），设计是决定如何实现需求（How），所以，描述需求只能说明What，而不是How。

之前的文章曾经讲过有些项目组的负责人在写描述需求的时候会担心只写What会导致开发结果不可控，所以，他们会如何实现需求都会写出来。如果项目负责人能力很强，懂设计，这样可能会得到他想要的结果，但是，却不利于开发人员从软件专业出发提出更好的解决方案。

实际上，对于一个成熟的开发人员来说，只要他正确地理解用户的需求，他就能够开发出满足用户需求的产品。除非他没有理解用户的动机。

用户需求或者说用户的期望和要求其实只是表相，这些期望和要求其实都是为了解决用户的痛点、难点、困难的，所以开发人员要理解用户的处境、顾虑、背景等，才知道用户为什么提出这些需求，从而也能过站在用户的角度考虑如何却去实现它。

如果开发人员不了解用户的动机，只看用户给出的需求（表象），就有可能给出错误的解决方案，开发出不满足用户要求的产品，解决不了用户的问题。

就像欧亨利小说中的老板娘一样。

故事背景是在18世纪。有个男人天天都到一家小面包店里买两个隔夜的陈面包，除了陈面包以外，他从来没有买过别的东西。时间一长，面包店的老板娘开始注意这个男人，从开始的同情、怜悯，到后来对他产生好感。当男人又来买面包时，老板娘鼓起勇气，乘男人不注意，快速地在面包里面塞了一块黄油……第二天，男人一早就出现在小店，发疯似地向女店主狂吼：“谁让你在面包里面加黄油的？一年了，我每天都加班到半夜，这幅设计图本来今天就可以完工了，谁让你在面包里面加黄油的！”

原来，那个男人是把陈面包用作橡皮擦来修改设计图纸的。这个老板娘知道用户的需求（需要陈面包），但是却搞不知道用户的动机（用作橡皮擦），结果好心做了坏事。

所以，如果项目负责人把用户的动机给开发人员讲清楚，开发人员是能够正确理解需求，给出正确的解决方案的。如果再加上项目负责人去参与需求规格说明和设计说明的评审，
确保开发人员对需求的理解和实现方案是正确的，那么他可以放心地在需求文档中只讲What不讲How了。

这正是：

不要担心设计错，不能得来对结果

了解用户何动机，开发人员不会错

来源：老丛讲桌