软件项目管理之范围管理

软件项目管理之范围管理

软件项目不可避免的一个问题就是项目范围的不断更新。大部分项目没法在一开始的时候就把项目的范围定义得非常清楚，或者说定好之后就不再更改的。项目范围的更改既然是软件项目中不可避免的事情， 那么管理好项目范围就成为软件项目管理中比较重要的一方面，即要让客户明明白白我们的范围也要让项目中的开发，测试，BA 等等在范围的理解上一致.
项目范围文档：
a) 项目经理自己或是项目经理指定一个专员维护一个文档专门记录项目范围，包括项目中的每个UC 或是Tickets 是在哪个阶段做，这个项目分几个阶段， 每个UC(Tickets) 都由哪几个开发人员，那几个测试人员来负责，哪几个成员负责Review 等。
b) 此文档还记录这个项目中有哪些是原来打算做，现在不做了的功能范围，或是所有人都已达成共识，作为Know Issue 再后期阶段做或是以后项目做或是在维护阶段做的范围。
c) 此文档还记录着一些UC (Tickets) 相关的一些备注，比如说对于这个UC 我们跟客户沟通过，结论是什么等等信息。
d) 此文档还记录着开发的完成情况，比如说让开发填一个状态一旦他们完成所有的Coding,UT and IT 工作。
e) 项目经理和 whole Team 随时可以查看这个文档，来确认自己理解的范围是不是跟整个项目的范围一致。

项目范围的变更：
a) 一旦客户提出范围变更包括增加或是减少功能，首先将新增加的功能记录在项目范围文档中，且指定某个或多个专员对其进行分析。
b) 新增加功能的范围对当前已经做好功能有没有影响，新功能有几个solutions, 每个solutions 需要多少effort 去coding, UT,IT ST 和写文档时间包括更新测试计划，测试cases， 设计文档，详细设计文档等时间.
c) 分析对于现有Schedule 有哪些影响，哪些资源来做这个新增加的功能比较合适。
d) 如果新功能加到现在项目中，那么新的timeline 是什么， 有没有新的dependency , 给客户的target date 又是哪天。
e) 更新完schedule 之后，自己内部whole team review ， 有comments就改，确保内部达成一致意见之后发给客户确定。
f) 如果客户没有意见，一切好办；如果客户有疑问，就需要解释为什么我们更新的schedule 是这样的。
g) 等最终确认新增加的功能加在当前的项目中时，要相应的更新WBS，FP， cost 等等相关文档。
h) 确认了的信息一定要通知到项目中的所有相关人员，确保所有相关人员在范围理解上的一致。

当然在项目的后期阶段不建议变更项目范围，即使要变也一定要告诉客户，这样做都有哪些风险一条一条的列出来给客户看。