如何克服组织障碍，实现实时需求追踪性

开发者工具分享

已于 2023-09-22 22:42:57 修改

阅读量160

点赞数

分类专栏：需求管理指南文章标签：需求管理需求分析项目管理敏捷开发

于 2023-09-21 18:31:51 首次发布

本文链接：https://blog.csdn.net/weixin_44280696/article/details/133143096

版权

需求管理指南专栏收录该内容

43 篇文章 6 订阅

订阅专栏

一、实时需求追踪性

在孤立的工程团队和各种工具之间，实现产品需求的实时追踪，以满足行业标准，这是大多数产品开发组织面临的首要未解决问题。

一个主要的障碍在于，各个工程学科（包括系统、软件、硬件、电气、风险管理、验证和确认）都已适应了自身的流程和工具。当我们从整体上审视产品开发过程时，会发现各个独立的团队、工具以及数据使得从最初定义需求到开发和测试的整个流程的追踪变得非常困难。

因此，需求追踪变成了一个耗时、容易出错、令人沮丧的手动过程，而这种追踪通常在事实发生后进行。产品开发组织无法持续地追踪开发活动和变化以及如何回溯到用户和系统需求，这导致了遗漏需求、出现缺陷、需要重复劳动、产生延迟、收到审核警告信和超出预算等问题。

没有通用的平台

解决这种通用的流程问题的典型方法是强迫每个用户只使用一个平台并遵循同一种通用流程。这种方式适用于人力资源、销售和财务等标准的业务流程，但是在跨系统、软件、硬件、电气、风险管理、测试、验证和确认的工程学科中，每个学科都遵循不同的方法，并使用包括电子表格、桌面应用以及自行开发的应用程序等多种工具。每个工程学科都适应了自己的开发环境，他们都极力反抗任何改变这种情况的尝试。工程领导通常会让各个工程学科自行定义如何最有效地完成工作，并且不愿制定可能会对每个工程团队的绩效和士气产生负面影响的流程和工具。

除了标准化的组织障碍之外，目前甚至没有一个单一的平台能够替代这些众多的工具。一个单一的平台需要覆盖所有下列的软件类别，并处理在电子表格（例如Excel）、脚本、桌面应用以及自行开发的工具中的所有功能，包括需求管理、CAD、基于模型的系统工程（MBSE）、设计失效模式效应分析（DFMEA）/失效模式效应分析（FMEA）、软件任务管理、软件代码管理、自动化软件测试、硬件测试台工具、应用生命周期管理（ALM）、产品生命周期管理（PLM）等等。现有供应商试图创建一个共享的服务平台，以跨越所有这些软件类别并与最佳实践工具并驾齐驱，但这些努力进展缓慢。

二、如何在不强迫工程团队改变的情况下实现实时需求追踪性

那么一个组织如何在支持不同方法论、术语、字段和状态的最佳实践工具环境中实现实时追踪性呢？

答案是一个三步走的方法：

第一步、实时追踪模型

在整个产品开发过程中定义一个实时追踪模型，并制定关于跨最佳实践工具的可追踪数据元素的关系规则。下面展示的是一个 PingCode 在汽车电子领域中实现的标准需求的关系模型。所有必要的可追踪信息都被包括在内，并通过与工程团队使用的各种最佳实践工具的持续同步，实现实时追踪。

第二步、自适应数据字段映射

要实现实时追踪，需要与最佳实践工具（如示例中所示的那些）进行集成。典型的集成方式是将字段名称和状态标准化，以确保各个连接工具的一致性，但这并不能同时实现实时追踪的双重目标，同时也不需要改变每个工程团队的工作方式。另一种已经被验证过的方法是应用自适应数据字段映射，这样可以在不改变工程团队的字段和状态的同时，确保有一个一致的、广泛的、实时的追踪模型。这是通过强大的映射和标准化逻辑功能实现的，能够轻松处理每个工程团队采取的不同方法。