请先不要讨论细节好吗

场景一：

项目经理接到一个新的项目，把大家叫到一起开会来介绍这个新的项目。首先，他介绍了这个项目是干什么用的。然后开始了下面的介绍。
“大家看，这个地方用户需要输入一个订单，这个订单呢，就是这么一个表”(说着画出了标的结构)“这个字段呢可能有些问题。。。。。。”

下面有一个人马上就说了：“可是我觉得叫这个名字怎么这么奇怪呢，是不是可以叫。。。”

之后，项目的介绍会陷入了讨论的“氛围”，一会研究表结构，一会觉得功能多，报价不合理。总之３个小时之后，出现了戏剧性的一幕：
项目经理：最后，房地产开发商就会察看这些单子。。。。。。
话还没说完，下面一个人问：这个项目和房地产开发商有什么关系？
项目经理：这个系统就是给他们用的阿！
那个人：啊？我们讨论的不是给零售连锁店用的阿！？

结果一个星期后，这个项目取消了。

场景二：

项目经理：这个功能需要修改一下，你看一下怎么修改比较好。
ＰＬ：嗯，如果这样的话，我需要增加一个表，然后字段会很麻烦。

很可惜得是，项目经理不熟悉数据库这个东西，两个人开始了争论表结构的开始。

场景三：

项目经理接到一个项目的意向书，客户写了１００个字的需求。他召开了一个会议，要大家从这１００个字里挖掘出更多的需求。于是乎，大家用了３个小时，讨论了架构，讨论了数据库，讨论了一切可以讨论的东西。

等回到座位，项目经理收到了客户的信，长达１４页的word文档，需求完全改变。

三个场景不是我胡编乱造的，都是我亲身经历的。

第一个场景中，最后那句话“啊？我们讨论的不是给零售连锁店用的阿！？”就是我问的。
第二个场景中，我是旁听者。
第三个场景中，我早就预计到结果，所以我没有浪费太多的体力。

请原谅我使用了“项目经理”这个词，这只是一个代号而已，别诬蔑了项目经理这个职位的名声。

为什么有那么多人就那么喜欢在一开始就一头扎入到细节中呢？

• 在项目还没有被确定的时候，就开始讨论架构，讨论数据库。
• 在客户的需求还没确定的时候，就开始讨论表结构。

在需求采集阶段，或者说需求磨合阶段，请不要过早讨论细节！细节的完善是一个漫长的过程，在这之前，我们要抛开细节，要先弄清楚客户想要什么，之后我们再去讨论细节，因为这些东西对于客户来说一点意义也没有。

身有同感，项目已经签下来了，但是，

客户说，“现在我们的业务部门都很忙，没有时间理你们， 你们先做一个版本出来吧，我想那个时候他们会更清楚，也好讨论”

老板说，“你们有什么困难尽管提，把项目计划做好，现在公司在规范项目管理”

我想，“做吧，就这样做，让程序员去干”。

程序员的坟墓

很好！原型开发，尽早出一个东西，再去客户那儿讨论需求！

不是坟墓，是历练。

要不要放手，还得看手下有没有这个能耐。当然，如果自己不懂，那还是别插手的好。

这是不是意味着你们公司缺少“中层”？或者说“中层”管理者实在太无能？

楼主说的是对的，项目所处的阶段但我觉得好像还没到需求采集吧，是项目立项定charter。把项目大的环境搞明白了，是内部项目还是外部项目，要实现些什么，目的是什么，有那些干系人，谁是sponsored，项目目标是什么，还有什么潜规则等。如果这些都没搞懂，就去做什么原型开发，是会死得很惨的。

第一个场景：
项目立项要定义项目范围。
范围的定义大体要说明主要功能需求，非功能需求，目标用户，软硬件环境，
而不是讨论设计问题。

第二个场景：
在问题还不明确的情况下，讨论解决问题方案，南辕北辙。

第三个场景：
同上。

总体上看：
这不是细节不细节的问题，是范围的问题、跑题的问题。上述这些内容也有是很多细节，是属于讨论范围内的细节。
开会之前没有明确好会议的内容、范围、目标。

不讨论细节?我认为这不可能,如果一个需求分析只是点到即止的话,到最后你会发现后期你会陷入无何止的改动当中,有很多是需求理解的问题.
我认为这不是讨论不讨论需求的问题,而是你们PM的问题,做为一个PM,没有很好的对于项目的把控能力,第一个场景,在问题没有表述清楚前就开始讨论.更让人惊异的是,居然下面的成员不知道是为什么行业的客户做的软件.每个行业都会有自己的特点.场景二,PM如果自己对于技术不是很了解,就放手让技术强的人去做,如果自己了解,就决定好了.场景三,需求是无止境的,可以在心里有估算,做到有的放矢,但是过人扩大需求就没有意义了.建议看一下Rod Johnson的 J2EE without EJB,不要产生幻影需求