请先不要讨论细节好吗
场景一：
项目经理接到一个新的项目，把大家叫到一起开会来介绍这个新的项目。首先，他介绍了这个项目是干什么用的。然后开始了下面的介绍。
“大家看，这个地方用户需要输入一个订单，这个订单呢，就是这么一个表”(说着画出了标的结构)“这个字段呢可能有些问题。。。。。。”
下面有一个人马上就说了：“可是我觉得叫这个名字怎么这么奇怪呢，是不是可以叫。。。”
之后，项目的介绍会陷入了讨论的“氛围”，一会研究表结构，一会觉得功能多，报价不合理。总之３个小时之后，出现了戏剧性的一幕：
项目经理：最后，房地产开发商就会察看这些单子。。。。。。
话还没说完，下面一个人问：这个项目和房地产开发商有什么关系？
项目经理：这个系统就是给他们用的阿！
那个人：啊？我们讨论的不是给零售连锁店用的阿！？
结果一个星期后，这个项目取消了。
场景二：
项目经理：这个功能需要修改一下，你看一下怎么修改比较好。
ＰＬ：嗯，如果这样的话，我需要增加一个表，然后字段会很麻烦。
很可惜得是，项目经理不熟悉数据库这个东西，两个人开始了争论表结构的开始。
场景三：
项目经理接到一个项目的意向书，客户写了１００个字的需求。他召开了一个会议，要大家从这１００个字里挖掘出更多的需求。于是乎，大家用了３个小时，讨论了架构，讨论了数据库，讨论了一切可以讨论的东西。
等回到座位，项目经理收到了客户的信，长达１４页的word文档，需求完全改变。
三个场景不是我胡编乱造的，都是我亲身经历的。
第一个场景中，最后那句话“啊？我们讨论的不是给零售连锁店用的阿！？”就是我问的。
第二个场景中，我是旁听者。
第三个场景中，我早就预计到结果，所以我没有浪费太多的体力。
请原谅我使用了“项目经理”这个词，这只是一个代号而已，别诬蔑了项目经理这个职位的名声。
为什么有那么多人就那么喜欢在一开始就一头扎入到细节中呢？
在项目还没有被确定的时候，就开始讨论架构，讨论数据库。在客户的需求还没确定的时候，就开始讨论表结构。
在需求采集阶段，或者说需求磨合阶段，请不要过早讨论细节！细节的完善是一个漫长的过程，在这之前，我们要抛开细节，要先弄清楚客户想要什么，之后我们再去讨论细节，因为这些东西对于客户来说一点意义也没有。 4 楼 lurena 2008-07-15 kimmking 写道程序员的坟墓
不是坟墓，是历练。
5 楼 yiding_he 2008-07-16 要不要放手，还得看手下有没有这个能耐。当然，如果自己不懂，那还是别插手的好。 6 楼 metaphy 2008-07-16 引用在需求采集阶段，或者说需求磨合阶段，请不要过早讨论细节！细节的完善是一个漫长的过程，在这之前，我们要抛开细节，要先弄清楚客户想要什么，之后我们再去讨论细节，因为这些东西对于客户来说一点意义也没有。
这是不是意味着你们公司缺少“中层”？或者说“中层”管理者实在太无能？ 7 楼 gdzer 2008-07-18 楼主说的是对的，项目所处的阶段但我觉得好像还没到需求采集吧，是项目立项定charter。把项目大的环境搞明白了，是内部项目还是外部项目，要实现些什么，目的是什么，有那些干系人，谁是sponsored，项目目标是什么，还有什么潜规则等。如果这些都没搞懂，就去做什么原型开发，是会死得很惨的。
8 楼 Godlikeme 2008-07-19 第一个场景：
项目立项要定义项目范围。
范围的定义大体要说明主要功能需求，非功能需求，目标用户，软硬件环境，
而不是讨论设计问题。
第二个场景：
在问题还不明确的情况下，讨论解决问题方案，南辕北辙。
第三个场景：
同上。
总体上看：
这不是细节不细节的问题，是范围的问题、跑题的问题。上述这些内容也有是很多细节，是属于讨论范围内的细节。
开会之前没有明确好会议的内容、范围、目标。
9 楼 jimmy.shine 2008-07-21 不讨论细节?我认为这不可能,如果一个需求分析只是点到即止的话,到最后你会发现后期你会陷入无何止的改动当中,有很多是需求理解的问题.
我认为这不是讨论不讨论需求的问题,而是你们PM的问题,做为一个PM,没有很好的对于项目的把控能力,第一个场景,在问题没有表述清楚前就开始讨论.更让人惊异的是,居然下面的成员不知道是为什么行业的客户做的软件.每个行业都会有自己的特点.场景二,PM如果自己对于技术不是很了解,就放手让技术强的人去做,如果自己了解,就决定好了.场景三,需求是无止境的,可以在心里有估算,做到有的放矢,但是过人扩大需求就没有意义了.建议看一下Rod Johnson的 J2EE without EJB,不要产生幻影需求 10 楼 hyhongyong 2008-07-23 jimmy.shine 写道不讨论细节?我认为这不可能,如果一个需求分析只是点到即止的话,到最后你会发现后期你会陷入无何止的改动当中,有很多是需求理解的问题.
我认为这不是讨论不讨论需求的问题,而是你们PM的问题,做为一个PM,没有很好的对于项目的把控能力,第一个场景,在问题没有表述清楚前就开始讨论.更让人惊异的是,居然下面的成员不知道是为什么行业的客户做的软件.每个行业都会有自己的特点.场景二,PM如果自己对于技术不是很了解,就放手让技术强的人去做,如果自己了解,就决定好了.场景三,需求是无止境的,可以在心里有估算,做到有的放矢,但是过人扩大需求就没有意义了.建议看一下Rod Johnson的 J2EE without EJB,不要产生幻影需求
至少在项目目标都不明确的时候，不要讨论细节问题吧？ 11 楼 easyroom 2008-07-23 我觉得楼主说的“细节”有问题吧。应该是太早考虑实现了
应该先把需求缕清。而且，需求一定要注意细节。 12 楼 protti 2008-07-23 jimmy.shine 写道不讨论细节?我认为这不可能,如果一个需求分析只是点到即止的话,到最后你会发现后期你会陷入无何止的改动当中,有很多是需求理解的问题.
我认为这不是讨论不讨论需求的问题,而是你们PM的问题,做为一个PM,没有很好的对于项目的把控能力,第一个场景,在问题没有表述清楚前就开始讨论.更让人惊异的是,居然下面的成员不知道是为什么行业的客户做的软件.每个行业都会有自己的特点.场景二,PM如果自己对于技术不是很了解,就放手让技术强的人去做,如果自己了解,就决定好了.场景三,需求是无止境的,可以在心里有估算,做到有的放矢,但是过人扩大需求就没有意义了.建议看一下Rod Johnson的 J2EE without EJB,不要产生幻影需求
同意你的观点 13 楼 hszhl 2008-07-24 这是有关客户的需求解决过程的讨论,我现在小结的一般过程是:
客户提出需求 -> 开发方分析与理解需求 -> 程序设计[部署,数据表设计,server component引用,编码等等]->解决需求
分析与理解需求是前提,程序设计是关键;
系统的使用好坏归根结蒂是设计问题! 14 楼 younggun 2008-07-26 我没有从LZ的经验中看出他们公司的软件过程是怎么样的，对于一个商业的项目，不仅仅是涉及到IT部门，还包括到市场、销售、操作、HR等业务部门，对于这些跨部门的软件开发，如果没有一套软件过程来约束，而仅仅是靠PM、TL单方面的讨论，稍微复杂一些的项目马上就会出现无头苍蝇的情况。 15 楼 sslaowan 2008-07-26 protti 写道jimmy.shine 写道不讨论细节?我认为这不可能,如果一个需求分析只是点到即止的话,到最后你会发现后期你会陷入无何止的改动当中,有很多是需求理解的问题.
我认为这不是讨论不讨论需求的问题,而是你们PM的问题,做为一个PM,没有很好的对于项目的把控能力,第一个场景,在问题没有表述清楚前就开始讨论.更让人惊异的是,居然下面的成员不知道是为什么行业的客户做的软件.每个行业都会有自己的特点.场景二,PM如果自己对于技术不是很了解,就放手让技术强的人去做,如果自己了解,就决定好了.场景三,需求是无止境的,可以在心里有估算,做到有的放矢,但是过人扩大需求就没有意义了.建议看一下Rod Johnson的 J2EE without EJB,不要产生幻影需求
同意你的观点
人家说的是不要先讨论细节。 16 楼 sslaowan 2008-07-26 做了三年项目，我现在对这个问题的理解是：
PM总得安排点事情要大家做，比如第三个场景
那就讨论吧，反正也没啥害处
我经常遇到这样的Leader
也经常避免做这样的Leader 17 楼 Else 2008-07-29 领导水平的问题
严重同意sslaowan 18 楼 Else 2008-07-29 会议组织者应该控制会议的议题,不要让它跑题,我们现在开会老是跑题,而且越跑越远,拉都城拉不住住 19 楼 guooo 2008-07-29 支持,不过技术人员要讨论的时候,难免会落入俗套,从程序实现的角度去考虑问题,这也是程序开发人员需要改进的地方,站在什么角度,就希望从什么角度去考虑问题,而不能固封在技术的圈子里面,若干年后我们只能死在技术里面,因为技术更新太快了. 20 楼 ayis 2008-07-31 kimmking 写道lurena 写道身有同感，项目已经签下来了，但是，
客户说，“现在我们的业务部门都很忙，没有时间理你们， 你们先做一个版本出来吧，我想那个时候他们会更清楚，也好讨论”
老板说，“你们有什么困难尽管提，把项目计划做好，现在公司在规范项目管理”
我想，“做吧，就这样做，让程序员去干”。
程序员的坟墓
所以说需求分析很重要 21 楼 mingli1223 2008-08-01 需求阶段,永远别谈技术.....不能什么事都拿来谈.该项定好的就事先定好......你一句,我一嘴,啥时完哦 22 楼 hcongqi 2008-08-02 metaphy 写道引用在需求采集阶段，或者说需求磨合阶段，请不要过早讨论细节！细节的完善是一个漫长的过程，在这之前，我们要抛开细节，要先弄清楚客户想要什么，之后我们再去讨论细节，因为这些东西对于客户来说一点意义也没有。
这是不是意味着你们公司缺少“中层”？或者说“中层”管理者实在太无能？
有理，我们需求都是项目经理做完，剩下的是细节交给我们解决 23 楼 gzstyxb 2008-08-03 ayis 写道kimmking 写道lurena 写道身有同感，项目已经签下来了，但是，
客户说，“现在我们的业务部门都很忙，没有时间理你们， 你们先做一个版本出来吧，我想那个时候他们会更清楚，也好讨论”
老板说，“你们有什么困难尽管提，把项目计划做好，现在公司在规范项目管理”
我想，“做吧，就这样做，让程序员去干”。
程序员的坟墓
所以说需求分析很重要
同意，需求很重要。要先弄明白用户干什么，然后把自己的理解和用户沟通，确认是否理解正确，尽量杜绝理解偏差。需求这个事情我感觉也不一定是做的愈细愈好，有个度。然后才是内部讨论怎么实现，确定系统架构。接下来，细节问题，考虑到国情，必然是在前进中磨合，磨合中前进。
