项目经理接到一个新的项目，把大家叫到一起开会来介绍这个新的项目。首先，他介绍了这个项目是干什么用的。然后开始了下面的介绍。
“大家看，这个地方用户需要输入一个订单，这个订单呢，就是这么一个表”(说着画出了标的结构)“这个字段呢可能有些问题。。。。。。”
下面有一个人马上就说了：“可是我觉得叫这个名字怎么这么奇怪呢，是不是可以叫。。。”
之后，项目的介绍会陷入了讨论的“氛围”，一会研究表结构，一会觉得功能多，报价不合理。总之３个小时之后，出现了戏剧性的一幕：
项目经理：最后，房地产开发商就会察看这些单子。。。。。。
话还没说完，下面一个人问：这个项目和房地产开发商有什么关系？
项目经理：这个系统就是给他们用的阿！
那个人：啊？我们讨论的不是给零售连锁店用的阿！？
结果一个星期后，这个项目取消了。
场景二：
项目经理：这个功能需要修改一下，你看一下怎么修改比较好。
ＰＬ：嗯，如果这样的话，我需要增加一个表，然后字段会很麻烦。
很可惜得是，项目经理不熟悉数据库这个东西，两个人开始了争论表结构的开始。
场景三：
项目经理接到一个项目的意向书，客户写了１００个字的需求。他召开了一个会议，要大家从这１００个字里挖掘出更多的需求。于是乎，大家用了３个小时，讨论了架构，讨论了数据库，讨论了一切可以讨论的东西。
等回到座位，项目经理收到了客户的信，长达１４页的word文档，需求完全改变。
三个场景不是我胡编乱造的，都是我亲身经历的。
第一个场景中，最后那句话“啊？我们讨论的不是给零售连锁店用的阿！？”就是我问的。
第二个场景中，我是旁听者。
第三个场景中，我早就预计到结果，所以我没有浪费太多的体力。
请原谅我使用了“项目经理”这个词，这只是一个代号而已，别诬蔑了项目经理这个职位的名声。
为什么有那么多人就那么喜欢在一开始就一头扎入到细节中呢？
- 在项目还没有被确定的时候，就开始讨论架构，讨论数据库。
- 在客户的需求还没确定的时候，就开始讨论表结构。
在需求采集阶段，或者说需求磨合阶段， 请不要过早讨论细节！细节的完善是一个漫长的过程，在这之前，我们要抛开细节，要先弄清楚客户想要什么，之后我们再去讨论细节，因为这些东西对于客户来说一点意义也没有。