周五开需求讨论会，当讨论到其中一个需求功能点的时候我提出了这样一个问题：
这个需求在文档之中只表明了what，而没有说明who和why，所以我希望能够说明另外两个基本要素
在我开来，一般一个需求都包含三个基本要素what who why
what  是指这个需求的内容是什么
who   是指这个需求是由谁提出的
why   是指这个需求提出的目的是什么

当时我的老大在听完我的提问后，略为的思索（估计是认为我的问题是指这个需求是由哪个客户提出来的，为什么而提）了一下回答说："我们做的是产品而不是项目，希望你能够明白产品与项目之间的区别".当时由于在讨论会上，我们没有再这个问题上再过多久就缠下去。

会后老大找到我，并给我解释了一下项目和产品之间的区别：
项目：由客户提出具体的需求来，开发人员只需要根据客户的具体需求来实现就可以了，而且当开发过程遇到需求不明确的情况时可以直接询问客户得到具体的需求回复。
产品：客户提出一个模糊的需求，甚至是市场部或产品部自己挖据出一个模糊的需求，然后探索性的进行开发，在产品发布后给客户试用并让客户提出意见，客户通常的意见是他觉得哪块不好。而开发者就要自行寻找不好之处的解决方案，并且在下一个发布版本中实现出来，如果客户说好，那么意味解决方案是成功的，如果客户说不好，那么需要再次改进相关功能。总而言之，就是开发者需要替用户去揣摩他们想要什么，用户只会说好或者不好（就好像大家都说不好的windows，呵呵）。

这样看起来这样比较的话项目和产品在需求分析上的差别很大，甚至产品的需求都无法找到who和why了。其实不然，狭义的理解需求当然who和why这两个要素实际上是出于用户角度，但是从我们要实现的软件来说，一个具体实现的功能必然具备3w要素，不然是不可能被实现出来的。就拿上面的例子来说，那个需求功能点的提出者就是我们的老大，至于他提出的目的就是为了让用户使用起来更加方便顺手。

回到项目还是产品的标题上来，其实无论项目还是产品都是为了给最终用户提供一个可以工作的具体功能，那么只要是一个具体功能，它就必然满足需求的3W要素，只不过有些需求的提出者是最终用户，而有些需求的提出者有可能是市场人员、产品人员、甚至是开发人员。

最后加一点点小小的体会，曾经有一段时间，我为了做好开发，去察看了各种各样如何作何需求的资料，写过大大小小各种各样的需求文档，但是到了最后实现的过程中，总是能发现需求文档当中的种种不足。最终这种困惑是在接触agile之后给我解决的，其实需求文档的目的是为了通过沟通把具体的需求让开发人员知晓，不要出现我需要汽车你给我造出火车这样的问题出来。这里最重要的问题不是文档，而是让开发人员知道他具体要开发什么东西，至于文档只能当作再沟通当中为了辅助记忆的一个附加产物。而在现实过程中，我们往往使用文档进行沟通，因此在现实中我们往往能够感觉到文档的种种不足。结果为了解决这种不足，我们采取的方式是增加文档项，让需求文档变得越来越庞大，也越来越在难以维护，甚至需要各种各样的链接索引，甚至当需求发生变化时，我们发现维护文档的成本已经远远高于实现本身了。。。

所以我现在在讨论需求的时候以3w问题做为基础，弄清楚实现出的功能最终是什么样子（当然还有优先级啊之类的功能点属性），然后把一些难于记忆的要点做一些记录，这个记录甚至是没有格式的。然后做成卡片。。。。呵呵，也许你知道我要说什么了，你想的没错，就是它——Story Card