（二）专家点评

潘东，上海交通大学计算机软件专业的博士，现任神州数码金融软件公司的副总经理，主管公司的项目交付。曾任神州数码项目管理部总经理，具有丰富的项目管理经验。

潘东点评：这个案例表面上看是作者无法确项目的需求，但深层的问题是项目没有明确的“客户”（因为案例的信息不全，这点仅仅是推测）。之所以如此推断，是案例中始终没有明确提及有“谁”在“提出”需求，或者项目是给“谁”开发的？

如果客户是“谁”是明确的，作者“写需求文档”的过程，就应该是分析和整理“客户”需求的过程，而不是按自己的“思想体系”创造需求的过程。

到底该由“谁”提需求呢？一般而言，应用软件由最终用户提出业务需求，软件产品由产品经理进行产品定义。不管怎样，由项目组“自己”为“客户”定义需求都是不太妥当的，这有点像裁缝按自己的尺寸给客户作衣服。

（三）项目管理者联盟网友分析

分析1：要管理好你的需求    作者：潘谦

感觉你的项目还没有开始完全进入项目的状态。
文中所说的很多问题都是需求分析的问题，很多你的工作现在明显都在需求分析的过程，还没有清楚的知道客户的真正需求，这不是RUP的问题，而是RUP要求首先实现的客户基本需求，再此基础上迭代实现的增加需求。
第一，还是因该彻底的分析你的客户需要的是什么功能。
很多时候客户不断的变化，是正常的，首先你要去发掘客户的真实需求是什么，一般来说可以通过快速原型和客户不断沟通来做到的。
我觉得如果对于你来说没有时间作原型，就尽量确定最基础的需求是那些。而且必须得到客户的确认。然后你再开始作用例设计-〉类设计。
第二，管理顾客的需求
客户的需求不断变化，但是不是每次客户的需求都要立刻对应的，RUP的好处就在于你往往可以把那些变化的需求放到下一个迭达中去。这样不会影响你这回迭代的开发
 
分析2：管理问题更多些、特殊情况可把领导的需求当作客户的需求、开发的步骤和图要根据实际需要来定    作者：globemobile

根据你说的情况，这只能叫做几个相关不相关的人以一种不好的方式在做一件事，而不是项目组在做项目。
这不是RUP 开发的迭代过程，管理问题更多些。
需求为什么由间接领导来定呢，是否其他项目的需求也是由领导来定的。如果是，则你们公司一定有办法把自己的需求推销给客户，那么你可以把领导的需求当作客户的需求。但是沟通要更加充分一些，不要今天一句、明天一点，那样永不成型。
另外两个人在写什么文档呢，是需求、还是可行性分析、还是规划、还是设计呢。
还有，开发的过程中需要的步骤和图要根据实际需要来定，不要根据书本来定。
 
分析3：用好方法    作者：天羽

作需求的时候就是这样的，很多的想法一时间不能描述清楚，慢慢的时间过去了，反而清晰起来，不断地往上面添加，但是这里有一个风险，就是思路不清。最后功能全部写出来了，逻辑上却变得格外的复杂，或不可实现。
建议你用MindManager来梳理一下功能流，看看他的走向是怎么样的。我不知道你们的文档的要求是怎么样的，但是MindManager确实能够帮助你的领导看清楚他有时间就过来改动的功能们到底是怎样关联在一起的。有了这样的图，也许你也能够理解他的目标，你的领导也能够理清思绪。
 
分析4：需求管理与项目目标    作者：孙先平

在这个项目里，老板实际上变成了客户（我怀疑最终满足了这个客户，项目的结果可能就是玩完了），要做好这个客户的管理；
另外项目的目标是什么？看起来，好象没有谁对这个项目负责，你只是个做文档的，有一点需要提醒的是：你需要明白老板认为你是谁，如果老板默认你为项目经理，那你目前状况和以后的情况都是比较糟糕的！如果没有，你只有建议权，那就当是一个学习的机会吧！ 

分析5：需求本身就是一个项目    作者：孙先平

如果有必要,你可以把需求当作一个项目在做,只不过它与另一项目交织在一起而已.没有人一开始就完全将需求弄得清楚,否则项目管理也没有意味了!
重要的是,你需要将需求中的关键点找出来,这样你不会在做到最后才发现,原来......后悔已经来不及了!
就这个案例本身不是一个简单的需求问题,是个管理问题,尽管大家在此讨论时不会给出一个一定有效的方子,但是至少可以理一下思路,明确可能存在问题的地方,然后再对症下药!
各位提到的需求明确或管理需求,追根究底,还在于管理流程要理顺!那个间接领导时不时要"灵感"突发,你有什么办法控制? 

分析6：可以这样想    作者：牛小林

我不太懂软件研发的项目经理，但是，可以明确的是：
你们的公司对这个项目不是很重视，或者人力资源不是很充足，或者还没有下定决心来投入。
但是，这对你并不是坏处，这对你应该来说是机会：
1．如果这时个重点项目，或者人力充足的话，不会你刚刚参加工作就能从事这样的岗位。
2．在这种情况，领导对项目目前的进展不抱太大的期待（请原谅我直言）。所以，即使项目出现问题，你也会得到谅解的，除非有人想整你，但是你刚到公司这基本上不可能。
3．这可能是你来公司后不可多得的机会去施展你的才能，让公司认识你的潜力和价值。也是你获得实践经验的大好时机。其实，公司是怎么认识你的，不就是看你做的每一件事情吗？不就是看你的做事态度吗？
4．不要对领导的意见抱有抵触的情绪，你所了解的东西，和你的视角相对会有很多的局限，你的领导往往会有更多要关注的东西，他也不一定会有时间给你讲清楚。你要学会站在他的位置思考，多请示，汇报，多思考。
剩下的事情，我认为相对就要简单的多，就是两个“谦虚谨慎”和“不耻下问”。

分析7：干系人分析是关键。    作者：郑承满

1．客户是谁？用户是谁？先将这两个问题解决了，找到关键干系人，就知道跟谁沟通，向谁汇报，对谁负责。
2．关注WBS，解决的问题可以先粗后细，先开始做WBS,在需求上面在细化下去(大目标先定)，先将工作包做清楚了
在开始写你要写的东西。
3．将计划与执行进行跟踪，将所有的人工作纳入计划中来，变无序为有序。

分析8：管理问题还是个人经验问题？    作者：赵昊彤

说句直来直去的话，这个问题根本不是什么奇怪的问题，在中国目前小软件企业中，这种问题太常见了。
这就是典型的“不规范的公司＋无经验的员工”所产生出来的现象！
据楼主说，这是一个5人的开发组，那么这么小的一个团队，如果一定认为是管理问题，我觉得有点上升得太高了。这么少的几个人，如果在工作方式和沟通上都出现了问题，我觉得主要还要归咎于项目组每个人的工作经验和工作态度，包括你们的那个间接领导。
当然，具体的情况我不清楚，不能在这里给出什么具体的建议，但是作为项目的管理者——那个间接领导——至少要先在项目组内部统一对项目的认识、项目的迫切程度、项目的时间要求、项目的重要性等基本信息，否则从何谈起说大家在做一个项目呢？
作为项目的成员之一——楼主——至少要主动和领导以及项目成员沟通，对自己手头的工作有一个基本的认识，在这个基础至少再提出自己的合理化建议，并说服领导或者征得领导的同意然后再开展工作。
我觉得目前的问题根本不是什么项目管理问题，也不是什么RUP过程的问题，这些还都谈不到呢，根本的问题是你们还没有形成一个项目团队，没有形成一个项目内部管理体系（哪怕是很简单的，比如项目例会、项目日报、项目过程管理等）。
这就是一个小公司，自身不具备成型的OSSP，人员经验又不足，也不具备基本的PDSP，自然就会发生这种现象。
还是先从提高楼主自身的工作经验来出发吧，别考虑太多了。
 
分析9：这种做法很普遍    作者：duanlj 

从LZ透漏的信息的来看，这个项目合同额肯定不高，就说项目不大，你的疑惑大概很多人都碰到过，一般小公司小项目大致是这么做的。
你所说的间接领导，他可能就是对这个项目的需求最清楚的一个，不直到让你开工之前给你讲过一些相关的需求和行业知识没有，这样的项目这样的做法，经验就显得很重要，如果是我，我不会安排刚毕业的来做需求文档。
所以阿，多和你说的间接领导沟通，争取他对你的理解的斧正，抱怨是没有用的，不要完全按照书上的东西办事，事实证明这样的做法也是可以成功的。 

分析10：如何确定需求    作者：lingjie

对于需求确定来说本来就是一件很难的事情。特别是工程性项目。不知道楼主所说的项目是属于哪种，看了全文个人认为应该属于研发性的项目，而研发性的项目需求前期确定一开始就需要有一个需求调研和立项的过程。如果说你的公司连需求都没有调研过，没有立项过，那这个项目到底要做什么就没有人知道了。对于写需求文档那都是在调研以及立项文档中都已经确定了的。你要写的是详细的需求规格说明书，并不是你自己凭空可以想出来的。
你应该做好与领导的沟通，详细的确定需求再写说明书。这样就不会出现不知道写什么好了。
就你的描述，这个项目的团队也还没有形成。根本称不上是项目组。
楼主可以借这个项目提高自己这方面的能力，个人认为对你并没有什么坏处。但需要注意的是不要一味的抱怨，应该好好思考一下你该怎么做。