项目接手的时候是从需求调研开始的，我们公司的需求调研工作由项目经理自己做。
　　原来的项目建议书把需求与技术方案揉在一起了，我把它拆分成需求说明书和技术预研报告，用了一周的时间完成了，并且就主要功能需求与用户达成了共识。
　　用户提出了修改意见：软件系统的部分功能需要进行修改和补充，需求说明书的表述中存在概念不清、描述不够准确、说明书中图示不够充分等问题。同时，由于项目的流程与第三方有关，用户提出要根据第三方的不同流程
接口，提供不同的文件做成两份需求说明书。

　　画图用了3周的时间，我几乎把界面设计都做完了，再次提交给用户，用户认为系统功能的描述还需要进一步细化。

　　又花了一周时间，由于用户对技术预研报告没表示出兴趣，在需求调研阶段讨论技术方案意义也不大，这次没有提交技术预研报告。用户不认可，要求编写“系统预案”。

　　“系统预案”是什么东东？经简单沟通，我理解用户要求的“系统预案”应该是系统的解决方案。
　　但我认为现在再回头编写解决方案，是没有意义的，因此，开始着手分析系统结构，并以用户能够理解的方式描述了系统的工作流程和数据流，又用了一周的时间。
　　结果，用户很高兴看到工作流程和数据流分析，但他要的不是这个东西，还是强调要编写“系统预案”，内容应该包含技术预研报告中有关系统实现技术讨论的相关内容。

　　用户要的“系统预案”究竟是什么东东？
　　过了几天，我把技术预研与需求分析合并成一份文档——“系统预案”，再次提交给用户。
　　文档还是不符合用户的要求！这回用户火了，也把问题说明白了，他们认为：需求说明书是开发方为用户代拟的项目需求，开发方应该根据需求说明书编写“系统预案”，并征求用户的意见，在“系统预案”经开发者和用户
共同确认后，作为软件开发和设计的基础，以及软件测试与验收的标准；需求说明书不符合用户对软件系统的要求。“系统预案”缺少关于软件系统的全面描述，没有全面表达开发方对软件系统的理解。

　　我也火了，多少年来做项目管理，没有亲自编写过需求说明书了，已经耐住性子写了这么多，还没有得到用户的认可。更可恶的是，用户对所有的文字，连纪要也要字斟句酌。
　　接着，我发给他们GB8567和GB9385，提出处理意见：在计算机软件工程中，如果开发方与用户没有专门的约定，可以认定用户默认遵循开发方的软件开发流程和文档规范。如果开发方没有成形的软件开发流程和
文档规范，双方应该遵循相应的国家标准。
　　后面比较过分，我坚持在需求分析阶段，只编制软件需求说明书，以保证用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。除此以外，向用户提供其它任何文档都不是必要的。

　　这么多年的工作经验，我很清楚接下来要冷静处理，还是按照用户的要求出了两套两份文档，再由老板出面协调。
　　用户和老板说：一份需求说明书要做一个多月，你们的成本是这样核算的吗？
　　我和老板说：你用项目经理的成本聘我，就是让我写需求文档的吗？

建议你们在项目刚开始的时候就和客户先确定最终要提交什么文档给他们，否则最后很难缠的，我们有的客户连我们项目管理文档都想要！

当承接一个项目时，你一个项目经理是否对这个项目有一个整体计划呢？比如项目的工作量、进度、成本、需要的资源等，如果有的话，把这份计划给你的老板看，告诉老板如果不在项目调研阶段就成立项目组的话，这个项目如
果不能成功完成，就不是我的责任，我想如果老板还坚持不成立项目组的话，你就没必要在这里做英雄了。如果一个项目经理从自身都不注重管理、不注重计划的话，那么老板也是跟着你糊涂，管理、文化又从何来呢？

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

流水的性质，不流满坑穴，是不会再往前流。

－－－－－－－－戒盈祈愿－－－－－－－－