需求管理
需求管理是在产品、系统或项目的整个生命周期中,对需求进行收集、记录、验证、优先级排序和追踪的结构化过程。
需求管理始于需求获取:通过访谈、工作坊或直接观察,了解客户、用户或内部利益相关方实际需要什么。需求收集完成后,需要进行记录、检查是否存在矛盾,并划分为功能性需求(系统必须做什么)和非功能性需求(例如安全性、性能或可用性)。之后才是优先级排序,通常采用MoSCoW方法,将需求分为必须实现、应该实现、可以实现和不予实现四类。
文档通常包括记录客户想要达成目标的业务需求文档(Lastenheft),以及描述供应商计划如何实现这些目标的技术规格说明书(Pflichtenheft)。需求追溯矩阵将每一项需求与其来源、状态以及后续用于确认其是否达成的测试用例关联起来。在敏捷项目中,产品待办列表(Product Backlog)通常承担这一角色,需求以用户故事的形式记录,并在各个迭代中不断细化和交付。
当项目进行中需求发生变化时,规范的变更管理流程就会启动:每一项变更都会经过评估,权衡其对成本和进度的影响,并在正式批准后才予以采纳。如果跳过这一步,就会出现范围蔓延(scope creep),即交付内容在没有相应调整预算或时间表的情况下逐步扩大。扎实的需求管理正是实现合理报价、清晰问责和可验证成果的前提。
实用示例
一家中型包装机械制造商正在规划新的订单处理软件。作为需求管理的一部分,项目团队访谈了销售、生产和发货部门共12名员工,收集到84项具体需求。通过MoSCoW方法进行优先级排序后,第一个版本保留了31项必须实现的需求,记录在一份18页的需求文档中。实施过程进行到一半时,一项与开票相关的需求发生变更,变更管理流程将其记录在需求追溯矩阵中,以便所有相关人员都能追溯到最初的需求。
Leanshift 如何提供帮助
需求管理与Kaizen的底层立场是一致的:在改善任何事物之前,都必须准确理解真正需要的是什么。细致地收集需求并持续追踪,能确保改善工作瞄准真正的目标,而不是在表面症状上打转。这种清晰性本身就是一项流程工作,它揭示出真正重要的东西,并为他人持续改善提供扎实的基础。
常见问题
需求管理与需求文档(如Lastenheft)之间有什么区别?
需求管理是一个持续的过程,而需求文档只是其中的一项产出。需求文档(Lastenheft)记录了客户想要达成的目标,而对应的技术规格说明书(Pflichtenheft)则描述了供应商将如何实现这些目标。
项目中的需求管理应该何时开始?
理想情况下应在概念或提案阶段、项目正式启动之前就开始。如果等到实施已经开始才厘清需求,就有可能导致代价高昂的返工和范围蔓延。
在Scrum等敏捷项目中,需求管理是如何进行的?
在Scrum等敏捷项目中,需求管理通过产品待办列表迭代进行,而不是依赖一次性文档。需求以用户故事的形式记录,持续进行优先级排序,并在各个迭代中不断细化和交付。