至于需求说明书等相关文档是基本的，也是必要的。

对于老板来说，从成本/收益考虑出发，也会赞成这样做，充分榨取剩余价值，“最好一个人搞定一个项目”-----是嘛。
我们公司就是这样，参照公司已有类似的成功项目案例，一个项目经理，再配上一个半个（因为没法保证他时刻为项目可用）的开发人员，也就是说一个半人搞定一个项目。

作项目，不要有太多抱怨，针对实际问题，提出解决问题的方法，这才是项目 经理的价值所在。

个人看法,欢迎讨论.

项目真正的文档要有三个至关重要：
需求分析说明书
概要设计说明书
详细设计说明书

　　Camer忽略了一个前提：我接手项目的时候是从需求调研开始的。
　　在我接手这个项目之前，合同已经签订，项目建议书和项目计划都已经提交给用户了。由于在合同签订时，用户就已经认可了项目建议书，这份项目建议书包含了项目的需求规格和技术方案，我在这个基础上编写需求说明书和技术预研报告。提交技术预研报，只是为了在文档的继承关系方面对用户有个交代，这样做相信rawbeer能够理解，所以后来用户提出要做“系统预案”就觉得多余了。
　　我在这个项目中，确实出了问题，由于是第一次与这家客户接触，习惯性地忽略了一些事情，没有很好地向用户交代项目开发流程，我认为这样的流程在我接手之前就已经跟用户交代清楚了。后来在用户提出要“系统预案”时，我发现了问题，但用户却不肯在这个方面进行交流。

　　如mkopen所言，在做项目的过程中，应该先定义好需求说明书的格式，并得到用户的认可。项目的开发有多少文档需要与用户交流，其格式要求等等，应该被包含交给用户的项目计划中，获得用户的认可。

　　在这个案例中，我在做的是软件需求说明书(SRS)，与rawbeer说的需求规格说明书和jamesvon说的项目说明书应该不同。

　　Ruddyli所说的需求反覆，确实是需求调研过程中常见的问题，足见沟通的重要性。但我遇到的问题则是另类。
　　这个项目有它的特殊性，在第一周完成需求的第一个版本后，在主要功能需求方面已经与用户达成了共识，后面所做的工作只是表述方式的问题。文档也确实是按照标准做的，本人从98年开始参照国标实施项目，自认为能够迅速、准确地把握需求和文档，而且这个项目是我在这家公司上手的第一个项目，在标准化方面特别地重视。可惜公司对项目管理和开发规范几乎一无所知，领导们虽然认可我这段时间的工作，但并不认可标准化。我本来有意把这个项目做成一个样板，结果却失败了，很是郁闷。
　　由于手上还有其它的工作，加上已经带团多年，现在要做需求说明书这么具体的工作，心里有点抵触情绪，因此隔了3周才与用户沟通。前面说到，主要功能需求在第一周就与用户达成了共识，在变更方面倒没有什么风险，但确实给用户留下了不好的印象。

　　Cncaigs说的沟通记录是必要的，但就一般而言，软件公司应该更清楚记录的重要性，因此做记录的通常是开发方，然后不定期地要求用户签字确认。
　　做过不少项目，需求的反复修订和确认确实是必要的，也研究过对日项目的开发流程和文档，确实做得很细，有好多是值得引用和借鉴的。

　　Hexapod说客户提出的软件需求说明书有些时候就是要难为你，有点过分。但我遇到的客户确实是这样的情况，很有趣，他们的IT部门有2个人，这2个人在比谁挑出来的问题多、谁把开发方问倒谁就牛。他们倒不是没有具体参与合同签订阶段，但却是另一种搞法：纠缠于文字和文法，连纪要也要字斟句酌。
　　我也认为，通过其它的协调手段可能可以更好地解决问题。
　　做这个项目时，我倒是得到了公司内部的理解，同情hexapod。

　　和用户闹到这种地步，沟通方面确实出现了问题。在这期间，公司共承接了这家客户三个项目的开发任务，公司从老板、销售、部门经理到项目经理，都感到与客户的沟通非常困难。但沟通是项目经理的职责，不应该成为项目出现状况的合理理由。

　　zzy0043：(
　　严重不同意一个半人搞定一个项目体现项目经理价值的说法。但国内的很多软件公司确实就是这样，这家公司就是。项目经理、软件设计师、程序员，经常都混为一体的，这就是专业化程度不高的结果，这是项目管理的悲哀呀。

　　在需求阶段，需求说明书确实应该尽可能做透做细，用户重视需求，这是好事，一旦这个需求文档获得用户的肯定，那后期需求的变更就会很少，这对项目来说绝对是天大的好事。
　　如果用户根本不重视需求，需求轻轻松松就通过了，那后面的苦日子就长了，可能就是无休无止的需求变更。
　　但用户重视应该是需求的实质内容，而不应该仅仅停留在文字表面，这就是我苦恼之处。dukeli，这样一份需求文档，确实做得很费劲，不过没有被公司Fire，而是我把自己给Fire了。

有问题，找IT项目管理http://IT.mypm.net
上海的PM牵起手：http://SH.mypm.net