最近和朋友吃饭，讨论到软件测试方面的问题，这位仁兄也是经验不足，像我抱怨好不容易按照之前评审的需求写完Case,现在又变更这么多需求，又得重新梳理需求写Case。其实参与过项目研发的人员都非常清楚，项目一旦启动，需求变更也会随之而来，需求变更是无法避免的。
不瞒大家，像博纳移动这么强大的研发团队，在项目启动之后变更需求也是常事。就拿最近V-3.4万能考勤开发过程的事情来说吧。万能考勤有个导出排班表的功能，排班表是以EXCEL形式展示的，这里涉及到排班表成员排列顺序的问题，当初原型评审时候，评审会议参与人员也都没有提到这个关于成员排序的详细需求，然后开发就默认按照创建班长时选择成员的顺序来展示了。待这个功能已经收尾的阶段，广州团队的产品经理突然提出，希望排班表导出后成员的排列顺序能由操作人员自己去选择。像遇到这种情况，这种需求是否需要直接加入当前Sprint计划呢？那么我们应该怎样来处理项目中出现的变更需求呢？最好的办法是建立一套正规的程序对项目的变更进行有效的控制。
参与项目这么长时间，结合平时的处理情况，我也总结了一下：
（1）评估变更对项目的影响：如果属于变更需求，进行分析，变更会对项目成本、进度、质量等因素产生哪些影响；
（2）设计变更的备选方案：列出几种可能的变更处理方案，比如说非常紧急的变更需求马上批准，而对项目影响较少的变更可以稍后再处理；
（3）提出变更申请：正式提出书面的变更申请需求；
（4）征求项目干系人的意见:所有与变更有关的项目干系人；
（5）提交相关项目管理人员，批准或者否则项目变更；
（6）追踪变更的实施情况:变更批准后，我们需求跟踪变更的执行情况，并且要记录在案。
网友评论