项目管理中,一些问题如何去解决?
问题有如下
1。如何真正的理解客户的需求
2。需求总是在变化，用户今天看到你的需求说明书及演示界面认为不错，过了几天却提出要加入新需求，再过几天又加点东西，到最后这个软件与开始的那个版本相差很大，成了垃圾系统？？
3。每次的需求变更都是口头描述，没有形成文档，即使形成文档客户也不愿意在文档上签字？
4。由于甲方对软件不熟悉，所以某些需求并不是他们真正想要的，而公司由于不熟悉客户的业务，所以也无法对此做出正确的理解
5。甲方很多潜在的需求在项目进行初期不会提出来，但在中后期会提出来，如何处理？
6。需求说明书得不到及时的更新，导致理解的误差和工期的延误
7。需求说明书的具体需求描述不准确，怎么办？
8。项目初期公司提出的需求到中后期又作废，导致大量的无用功，而且需求也不能管理到位，怎么办？
9。如何有效的标识一个需求？
10。用户总是抱怨需求说明书看不懂，只看演示界面，最后验收对需求说明书不予认同？
11。需求调研过程中，客户不配合怎么办？
12。在什么时候建立需求基线比较合适？
13。需求稳定到什么程度可以开始后续阶段的开发？
14。在关于需求的沟通中，非面对面沟通导致需求失真，如何做？
15。客户对软件开发不熟悉，不能提供详细需求，怎么办？
16。需求频繁的变更，需求管理难度很大。。。
17。客户是用户的上级，用户对开发本项目有抵触情绪，在需求调研时不提任何需求，项目如何进行？
18。迭代式开发如何来控制需求变更，如何用面向对象方法来适应需求的变更（不要出现因为需求变更导致设计框架的变更）？
19。怎样对待需求变化后，项目计划、成本和产品竞争力、客户满意度之间的平衡？
20。软件项目的需求稳定度到底怎样？
21。对需求进行跟踪管理，管理的粒度到何种程度比较合适？控制到用例就够了吗？
22。需求变更来自公司高层，出尔反尔，无所适从？
23。新产品软件开发需求获得更加困难，怎样在不确定客户的情况下获取需求？
24。如何应对琐碎的、细节性的（比如不超过1个工作日，但是又频繁发生的客户变更要求）需求变更？
25。需求变更的审批流程很长，影响工期了，怎么办？
26。用户管理层角色与操作层角色的角度不同，对同一个功能的需求可能是冲突的，如果照顾了管理角色，这个系统就不适用，如果照顾了操作层，管理人员又可能不在验收上签字，怎么办？
结果:
1。如何真正的理解客户的需求?（一个很开放性的问题～：））
a.需要有行业专家的支持，不然不容易理解客户的真实需求
b.对需求调研人员需要很强的沟通、学习能力，特别是要会听，能够识别各种需求描述中的真实内容
c.不断的确认需求记录
d.要认真、准确、结构化的记录客户的需求
e.第一次进入一个行业，没有行业知识和背景，做行业项目的风险是很大的，很可能抓不住客户真正的需求
f.使用图形化的文档进行和客户交互，可以增加和客户的共识
g.......
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
2。需求总是在变化，用户今天看到你的需求说明书及演示界面认为不错，过了几天却提出要加入新需求，再过几天又加点东西，到最后这个软件与开始的那个版本相差很大，成了垃圾系统（不知道这么维护这个系统了～）？？
a.需要建立需求基线，双方都要签字认可，并尊重这个基线
b.如果做一个新的行业系统项目，出现这种情况的可能性很大（这叫交学费～）。
c.在发生这种情况的时候，应该适当的引导客户，有专业软件公司的判断，不能说加需求就很快的答应下来，即使答应下来，也不要轻易承诺实现的时间点，需要认真评估后，再答应具体的提交时间
d.如果在做需求过程中，需求能稳定到80％，发生以上情形的可能性会下降
e.需求的有效性非常重要：很可能第一次定义需求就已经出错了，要重视第一次需求的定义，讲究清晰、准确、无二义。
f.使用用例加图片的方式来编写需求说明书，可以提高需求确认的可能性，也会减少这种情况的发生
g......
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
3.每次的需求变更都是口头描述，没有形成文档，即使形成文档客户也不愿意在文档上签字？
a.这个方面需要由一个正式部门提出,并记录下来,并且通过一定的上级部门了解需求变更的资料,而不是有变更马上就去完成.
而是通过一次确认的过程.
b.加强需求变更流程管理,提高项目管理人员的水平.
18。迭代式开发如何来控制需求变更，如何用面向对象方法来适应需求的变更（不要出现因为需求变更导致设计框架的变更）？
a.要控制软件架构的稳定性，软件架构应该灵活的适应多数的变更,做这个架构要能够预见到大多数的变更
b.首先实现最底层，关联性大的功能和特性，建立基本的稳定架构
c.面向对象的设计的松耦合，强内聚的特性可以降低软件组件变更的可能性
d.迭代式开发是应对需求变更的一种好的方式，特别是XP开发方法（拥抱变化）
e.架构不稳定的情况下，需求变更导致的开发工作量、测试工作量是很难预期的
f.有不少稳定的软件架构模式（比如：MVC）可以相当程度的适应需求变更，有效使用设计模式，可以提高软件架构的稳定性，相当程度的适应软件需求的变更
g.......
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
19。怎样对待需求变化后，项目计划、成本和产品竞争力、客户满意度之间的平衡？
a.可以通过专家估计来评估成本，工期，满意度之间的关联关系
b.如果有历史度量数据库，将更好的量化需求变更和成本、进度、工作量之间的关系
c.不可能100％的答应客户需求变更请求，即使这样客户满意度也不一定高，老板也不答应 ：）
d.要分析变更的需求会影响哪些角色的利益，平衡各种涉众之间的冲突，不同方式的应对需求的变更，尽可能提高关键客户的满意度。
e.软件实现要适应客户企业的文化，才可以融入客户的环境，也可以提高客户满意度
f.在软件行业还没有像建筑行业那样为每个需求变更买单的行业惯例。
g.使用项目管理工具来计算需求变更导致的工期、成本、进度的影响
h.对于琐碎的需求变更，比如界面上的细微调整，在开发过程中需要适当的满足，否则会影响客户的配合度和满意度的
i........
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
20。软件项目的需求稳定度到底怎样？
a.需求在整个开发过程中都是在变化的，需求变更肯定会发生的
b.在开发初期，需求的稳定度大约在60～80％之间
c.客户在项目过程中也在逐步理解这个系统，所以需求也会演化
d.软件项目的需求稳定度低于传统建筑工程行业的需求稳定度
e.应该和客户达成这样的共识，在需求稳定到60～80％的程度，就可以进行下一步的开发工作，后续的按照变更管理流程来有效的管理变更。
f.在需求开发过程中，用完美主义的方式做是不行的，至少在中国多数的软件企业的项目开发（非产品开发）中是这样的
g.软件需求中的不同内容，变化频率是不同的，业务模型是最稳定的，业务流程相对稳定，业务表现（报表。。）是最容易变化的。
h.......
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
21。对需求进行跟踪管理，管理的粒度（单位）到何种程度比较合适？控制到用例就够了吗？
a.不要把需求的非常细节的内容作为需求项来管理，否则工作量非常大
b.对于细节的需求（比如界面上的按钮表现）可以用图形方式来表现。
c.如果用例分解的粒度适当，可以把用例作为需求项进行管理。
d......
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
25。需求变更的审批流程很长(比如一个月)，导致了工期的风险，怎么办？
a.如果对于大的项目，其中的变更审批流程长是很正常的，比如银行系统。应该适应客户的工作方式
b.如果有行业专家，可以很大程度的规避这种变更，没有行业专家，需求变更就会比较频繁，花在变更审批上的时间会很多。
c.在合同阶段建立约定，在一定程度上加快客户的变更审批流程
d.变更一定要在审批通过后才可以进行，否则就很可能返工
e.......
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－