需求管理和变更控制的经验

申请免费试用、咨询电话：400-8352-114

　　软件工程里的许多问题，诸如缺陷及资源运用不当，都是源于需求的不确定。在90年代，我曾在美国一个拥有数千员工的公司里从事大型软件开发工作。该软件主要是卖给汽车修复厂用的，它可估算出修复汽车的零件及劳力两项费用，甚至还可以找到提供新零件及旧零件的厂家。软件的的复杂度相当地高，要界定什么样的界面和功能是最适合市场的着实不易。所以，需求一变再变。在聊天时有个同事戏称：“需求变更乃万恶之源!”其他的人纷纷响应。当时，所有的需求都是写在Word文档里的，那些文档不是放在一个共享的服务器里，就是交由负责编写程序的人员管理。虽然没用什么管理平台及工具，但在团队成员的配合和默契下，一切事情都有序地在进展着。项目管理者联盟

　　但有一天产品经理换了个新的，一切事情似乎就全改变了。新的产品经理原是某汽车修复厂的经理，他对修汽车及车厂管理有不少的经验，但对软件的开发是很不懂的。很快地下列问题出现了：PgMp.mypm.net

　　(一)需求描述不清楚，导致开发任务的时间估算误差可到100%，甚至200%;项目管理论坛

　　(二)优先及全由产品经理决定，有时不太重要的任务先做了，重要的反倒后做;

　　(三)需求变更一再发生，并且当某需求变更了，它的连锁反应会冲击其他的部分，许多缺陷因此产生了。training.mypm.net

　　我们几个资深人员分析整个过程，发现造成问题的原因是这样的：项目管理者联盟

　　(一)我们的现有需求文档管理太乱，通常是找不到所要的版本。就算是找到要的文档，常常也没法找到要的那段内容。bbs.mypm.net

　　(二)可判断任务优先级的因素颇多，可以是在商业层面或技术层面，每人的视角不同，公说公有理，婆说婆有理。blog.mypm.net

　　(三)需求文档、代码、测试用例及其他的工件(artifacts)之间应是相关联的，但在系统中我们无法从其中任一个工件找到其他的工件。项目管理者联盟

　　由于文档不全，这位新的产品经理很难在短时间内对整个系统有个概括性的了解。当他和资深人员沟通产品设计理念及历史缘由时，资深人员也没能明确地回答他的问题，这导致需求设计不完善，优先级也有误。找到原因后，我们想既然需求变更这一头凶猛野兽是杀不死的，那我们所能做的大概也就是将这兽关在笼子里，使它温驯点。 为解决这问题，我们建立了以下的体制。项目管理者联盟

　　(一)细化需求的时间估算 – 我们将需求分解到程序员能清楚估算出完成时间的小单位，原则上每单位是可以让一个程序员及一个测试人员在二至十天内做完，而且每个单位都有个编号。bbs.mypm.net

　　(二)使用版本控制系统管理需求文档 – 所有需求文档全保存在一中枢版本控制系统里。项目管理者联盟

　　(三)将需求分组并设优先级 – 所有的需求单位按照不同的版本区分开来，每个需求单位都有个优先级。

       (四)建立工件之间的关联性 – 将程序及测试用例与相对应的需求单位连接上，明确地写上需求编号。training.mypm.net

　　(五)建立评审团队 – 当需求产生或变更时，产品经理及干系人要一起评审，通过后才做更改。项目管理论坛