实践情况总结以上问题都是在项目中出现过的相关问题 ， 应该具有一定的代表性 。在项目管理或日常工作中 ， 很多时候并不是我们解决问题能力差 ， 更多的时候是发现不了问题或发现不了引起问题的根源因素 。项目计划和管理中的多个问题都是通过整个项目团队的复盘总结 ， 开发过程的评审 ， 项目经理自查等多种方式发现的 。
1.通过与业务用户的多次沟通确认项目版本的范围 。
项目一般会提前2-3周同用户讨论下个版本的具体用户需求 ， 所以作为用户接口的技术管理部一般会提前一个月收集各个事业部的相关业务需求 ， 这样才能够保证项目的各个版本很好的迭代起来 。对于收集到的用户需求 ， 根据需求的重要性和紧急程度确认各个需求的优先级别 ， 同时每个需求都还会附加上业务期望的解决和上线时间 。
在第一次讨论完成后 ， 项目组会组织BA ， 架构和项目经理共同开会讨论用户需求信息 ， 项目组内部讨论一般会根据该功能实现后可能的使用频度 ， 实现的工作量 ， 实现该功能对系统已有功能的影响等多个方面对用户需求进行讨论和规模工作量的初步估计 ， 给出一个具体的项目周期和范围的几对可选值 。如1个月可以实现前6个需求 ， 2个月可以实现前十个需求 ， 同时对那些暂时使用频度不会很高 ， 对系统的增值价值不高的需求提出自己的意见 。
有了这些基础信息后再组织和用户的第二次业务讨论 ， 这个时候用户基本可以从几对可选值中选择可以满足自己的安排 。如果存在很多个功能优先级都很高 ， 又对解决期限有强烈要求的时候 ， 这时候产品经理就会考虑在项目人力资源上的多投入来满足用户的需求 。
这里通过项目多个版本实践 ， 强调的几点是：
1)一些用户提出很紧急的需求对整个用户群或系统来说并不紧急 ， 如一些业务管理员的操作新需求 ， 这些功能基本上一个月才使用几次 ， 使用人数在1/1000以下 ， 所以花费较大的人力资源实现这种需求对整个系统的增值并不高 。一般这种需求即使用户优先级高 ， IT通过讨论后也会降低其优先级 。
2)如果用户需求存在对系统的核心模块重大改造时 ， 一般会延期实现或考虑替代方案 ， 如项目在系统管理和工作流模块 ， 经过多次的系统测试 ， 回归测试和验收测试才运行稳定 ， 如果用户提出的新需求对这块存在重大改造 ， 那对整个系统引起的风险是相当高的 。
3)在项目范围确定中存在了需求挖掘过程 ， IT协助用户将点的需求扩展为面的需求 。如项目的V4.1版本用户提出了在齐套清单功能上 ， 增加对清单内容表格的搜索功能 ， 这个功能后期转化为了对整个系统的GRID都支持模糊搜索 。
通过这种方式确认出来的项目范围和项目周期就和用户很好的达成了一致 ， 保证了后续计划和执行阶段工作的顺利开展 。
2.不断地对估算方法进行总结和实践以提高估算准确性
对于专家法估算 ， 困扰项目的一个主要问题是如何把用例复杂度估计的准确点 ， 因为在估算时候WBS的工作包基本上都会分解到1个用例的粒度 ， 但很明显的是各个用例的复杂度是明显不同的 ， 组织级在用例复杂度上面根据基本流+扩展流+业务规则的流总数来进行的定义 。由于第一次估算时候软件需求还没有出来 ， 因此问题转化为了如何较准确的确认清楚软件需求的流总数 ， 这个数据的估算难度相当大 ， 更多的只要依赖专家的经验 。

以上关于本文的内容，仅作参考！温馨提示：如遇健康、疾病相关的问题，请您及时就医或请专业人士给予相关指导!

• 网站优化的步骤和技巧 网站seo怎么做成效最大
• 数据库性能优化方法 oracle性能调优总结
• 内网ip查询的两种方法 内网ip怎么查手机
• 简单随机抽样的三种方法 excel随机抽样怎么操作
• word设置自动连续页的方法 word如何删除某一页的页码
• 考研英语几小时
• 盘点那些会预示破财的梦
• 孩子可以维系家庭情感吗 孩子对于家庭的重要
• 什么是奶嘴男 给奶嘴男断奶的方法有什么
• 婆媳吵架丈夫应该怎么办 如何解决婆媳的矛盾