|
软件项目经理【广州】俱乐部 camer 2005-4-25，在听完2个小时的会议录音后整理成文，希望对大家有所启发。。。 ！简况： 2005－4－24（周日）下午,在中山二路昔士风西餐酒廊，有13位软件项目管理同仁参加了“软件需求管理困境突围”沙龙活动，他们是：zzroom，l1029，Precilla，风，凯文，camden，jenny，代先生，Camer，Richy，Libber，xueds和他的朋友。 ！基本成果： 活动中提出了以下需求管理方面的问题：
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
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。用户管理层角色与操作层角色的角度不同，对同一个功能的需求可能是冲突的，如果照顾了管理角色，这个系统就不适用，如果照顾了操作层，管理人员又可能不在验收上签字，怎么办？
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－ ！典型成果： 本次活动讨论了以上问题列表中的7个问题，问题编号为：1，2，18，19，20，21，25。讨论的思路如下：
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
1。如何真正的理解客户的需求?（一个很开放性的问题～：））
a.需要有行业专家的支持，不然不容易理解客户的真实需求
b.对需求调研人员需要很强的沟通、学习能力，特别是要会听，能够识别各种需求描述中的真实内容
c.不断的确认需求记录
d.要认真、准确、结构化的记录客户的需求
e.第一次进入一个行业，没有行业知识和背景，做行业项目的风险是很大的，很可能抓不住客户真正的需求
f.使用图形化的文档进行和客户交互，可以增加和客户的共识
g.......
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
2。需求总是在变化，用户今天看到你的需求说明书及演示界面认为不错，过了几天却提出要加入新需求，再过几天又加点东西，到最后这个软件与开始的那个版本相差很大，成了垃圾系统（不知道这么维护这个系统了～）？？
a.需要建立需求基线，双方都要签字认可，并尊重这个基线
b.如果做一个新的行业系统项目，出现这种情况的可能性很大（这叫交学费～）。
c.在发生这种情况的时候，应该适当的引导客户，有专业软件公司的判断，不能说加需求就很快的答应下来，即使答应下来，也不要轻易承诺实现的时间点，需要认真评估后，再答应具体的提交时间
d.如果在做需求过程中，需求能稳定到80％，发生以上情形的可能性会下降
e.需求的有效性非常重要：很可能第一次定义需求就已经出错了，要重视第一次需求的定义，讲究清晰、准确、无二义。
f.使用用例加图片的方式来编写需求说明书，可以提高需求确认的可能性，也会减少这种情况的发生
g......
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－ 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.......
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
小结一二三：
本次讨论的有效时间大约为1.5小时，每个问题讨论时间大约在15分钟左右，普遍感觉讨论时间太短，没有把问题讨论透，希望能有充分的时间来把具体的某个问题讨论透，可以把这些问题挂在bbs中组织讨论。。。 对于已经讨论的话题，已经有比较倾向性的看法，从某个人提出的问题来说，还是有不少的启示，也可以帮助提出问题的人出一些思路，或许不是所谓的专家权威的看法，也可能这些思路更加适用于具体的问题环境。。。：） 这次活动仅仅是需求沙龙系列的一个引子，他引出了软件项目在需求管理的种种困境，在需求管理这条路上，多数公司还有很长的路要走，我们会把这个系列持续的做下去，真正达到“大家帮助大家，共同提高”的效果。 －－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－ ！新的开始： 为了实际的推动俱乐部的步伐，在结束前还确定了下次活动的关键内容： 时间：2005年5月中旬的一个周日（具体时间待定，会及时更新）
地点：（待定，会及时更新）
组织人：王先生（ricky）email:richsky@tom.com
主讲人：Precilla和她的朋友
主题：思维导图讲座和互动?（链接主题“mindmanger的应用经验交流”。）
方式：主题互动讲座方式
说明：思维导图是整理思路等多方面上非常有用的工具，国外不少专业组织在研究和应用思维导图。。。。相关主题讨论将在本板块和广东板块展开 该次活动已经开始报名，报名方法：email到会员部libber@tom.com，报名内容：
－－－－－－－－－－－－－
会员编号：
姓名：
网名：
性别：
电话：
邮件：
msn/qq号码：
职位：
个人特点：
对该主题的想法：
感兴趣的PM话题：
－－－－－－－－－－－－－ 希望我们的活动能给您带来快乐和收获！
|
项目型组织
项目管理
工程项目
科技项目
资格认证
职业休闲
Re:[分享] SPM-GZ活动：需求管理，经典思路回顾～～
[回复于 2005/4/25]
此主题相关图片如下：
