项目需求管理专栏︱如何进行高效的项目需求管理

摘要

糟糕的需求管理流程(或者根本就没有)常常被认为是项目失败的首要原因。正如许多组织所发现的那样，审慎设计的项目管理流程可以有效地提高项目成功率，这些研究同时指出：混乱的产品需求的管理，也是项目失败的重要原因。由此产生一个问题，什么是需求管理？需求管理流程的好坏又如何造成项目的拖延和失败或者促进项目的发展与成功？

从身边的现象说起

作为互联网从业者，我想除了众所周知的「996」「35岁被优化」等老梗之外，另外为人所熟知的，就是产品经理和开发之间的矛盾了，由此诞生了「砍我可以砍需求不行」、「服务器又出故障了，该拿程序员祭天了」等其他相当知名的段子。产品经理和开发之间的矛盾由来已久，段子和故事不可胜数，但是深究原因，其实无外乎需求经常变更或是项目发生延期，换言之，就是对于项目缺乏有效的需求管理，而最终的后果，小到项目员工日夜加班，大到项目失败，甚至公司业务崩溃。很多人往往将这些被可以避免的问题归类于是其他难以避免的重大问题(资金不足，决策失误，市场变化，政策变化等等），毕竟以上问题是所有公司都有可能遭遇的问题，它们太过普遍以至于如果将这些问题作为原因的话，我们很难得出更多有意义的结论。

事实上，根据 PMI 进行的多项需求管理调查得出：糟糕的需求管理流程常常被认为是项目失败的首要原因。

很多甚至中小型公司(当然，也包括一些大型公司）根本就没有成型的需求管理体系，只是通过一些简单定义的工作规范和工作流程管理需求，有些连基本的管理规范都没有，完全取决于大家约定俗成的简单共识。正如许多组织所发现的那样，经过精密设计的项目管理流程可以有效地提高项目成功率。

同时这些研究也指出：混乱的产品需求的管理，也是项目失败的重要原因。

由此引发一系列问题：

即什么是需求管理？

需求管理流程又如何造成项目的拖延和失败或者促进项目的发展与成功？

以及我们应该通过怎样的方式管理需求？

这也是我们接下来将要进行详细讲解的三个主题：

当我们谈论需求管理时我们在谈论什么？

从需求定义重新出发

按照 PMI (项目管理协会，Project Management Institute) 对于产品需求的定义：需求是指产品所必须拥有的一项功能特性，这个特性一般用于解决客户的特定问题，或者是给客户带来额外的价值。

换言之，如果一个产品需求，或者说一个功能特性，既不能解决客户的问题，也不能给客户带来价值，那么我们很难认为这个需求是有意义的，即使这个需求涉及到管理层的伟大战略，产品的精妙构思，开发的毕生绝学和相关人员的通力合作，它也是失败的。

忽视客户真实想法和意图的情况并不鲜见，其中有些产品获得伟大的成功，但大多数成为众人皆知的笑柄。

苹果公司：Newton PDA，又称「乔布斯的终身噩梦」

福特公司：Edsel, 又称「马桶座圈之车」

雅达利：E.T 游戏, 又称「史上最垃圾的游戏」

这些产品之所以诞生，很多时候源于亨利·福特的一句话：

我不需要产品调研，如果我问我的客户他想要什么，他一定会回答「一辆更快的马车」。

显而易见，这些失败产品给客户提供的是「一辆更慢的牛车」；

要想像亨利·福特和乔布斯那样的天才一样洞察需求是相当困难的，但是设身处地地去理解客户的想法和诉求却并不复杂，只需要你有同理心和谦虚的态度。只有充分理解客户所关心的问题，才能创造出满足客户需要的产品。

所以，从这点来说，客户的需要并不完全等同于客户需求，只有产品设计者和相关从业者充分调研，充分了解了客户提出需要的背景和根源，才能足够清晰地定义出关键问题，而产品设计者针对该问题所设计的解决方案，才能被视为产品需求。

我们应该如何区分需求

我们已经初步了解和认识到什么是产品需求，接下来要做的是对需求分类。

我们之所以要区分需求，是因为任何一个产品需求，其业务背景、目标客户、需求来源、预期作用、重要程度、紧急程度都存在根本性的差别，而我们必须要将这些形形色色的需求纳入一个相对一致的分类体系，以期实现标准化的需求管理。简而言之，需求的分类源于我们对需求的管理方式。

那么如何区分需求呢，常见的分类标准又分别是哪些呢？

产品需求可能来源于许多不同的场景：譬如需要遵从行业标准和监管条例所产生的监管需求，以及源于用户业务问题和需要的业务需求，以及源于公司战略的市场需求和竞争需求等等。随着需求来源的不同，我们可以根据这些来源进行分类。

而更加标准的分类方式是根据需求是否满足特定目的(功能型）来区分：这种场景下，需求通常可以分为功能型需求和非功能需求。

功能型需求是那些用以处理产品所必须满足用户需求的功能特性，功能型需求是最基础也最核心的用户需求，功能型需求有时也被称为业务需求。这些需求描述了用户预期产品所能拥有的某些能力或功能，这些功能可以帮助客户自动化地完成某些任务，优化业务流程，推进客户业务的运营效率等等。一言以蔽之，功能型需求是产品的骨架、大脑和心脏，是产品之所以存在的根本原因。

非功能需求包括可用性需求，性能需求，可靠性需求和安全需求。非功能需求是产品所需要满足的重要属性，我们日常所说的技术需求也是一种非功能型需求。相比功能型需求，非功能需求重要性往往略逊一筹。但是在很多核心项目中，即使最终完成的产品已经满足所有业务需求，如果有一项或者几项关键非功能需求(性能需求)无法满足时，这个项目也仍然会被视为失败的项目。而随着用户规模的扩大，非功能型需求的重要性也在不断上升，例如淘宝、支付宝、微信，对于非功能型需求的重视不逊色于功能型需求：而正是因为这些产品极好地满足了非功能需求，保证了服务的可用性，响应的及时性，交易的可靠性和信息的安全性，才能获得更大的市场规模。简单来说，非功能需求是产品的血肉、神经和皮肤，是产品能经久不息的核心动力。

此外，还存许多不同的需求分类方法，比如基于卡诺模型的需求分类方法，比如基于紧急度和重要性的艾森豪威尔需求分类方法，每种需求方法都有其适用场景，而根据公司和项目实际情况不同，对需求的分类方式也由此存在差异，不存在一种最佳的需求分类方法，而现实往往比理想更多复杂，很多时候我们需要结合多种需求分类方式，重新构建一套完备的需求分类标准才能有效处理各种复杂需求。

但是无论如何，你需要谨记：需求分类的目的是为了便于需求管理，如果一个需求分类方法，有助于提高项目需求管理的效率，那它便是最好的需求分类方法。

产品需求的集合：产品范围 (Product Scope)

《项目管理知识体系手册》(PMBOK) 所定义的产品范围是指那些被定义为产品、服务和成果的一些特定功能和特性的集合。产品范围的是否完成取决于所包含的产品需求是否全部完成。

尽管我们已经力图在项目开始阶段就充分列举所需要的产品需求，但是需求的新增和变更仍然难以避免。

虽然不建议在产品范围的需求列表中加入此前未提及的新需求，但是如果缺少用户已提出的产品需求将致使最终产品无法满足用户预期。

需求管理为何重要

低效的需求管理流程(或者更常见的是，完全没有需求管理流程)被认为是项目失败的重要原因。特别地，产品范围蠕变和无法控制是是项目延期和成本超支的常见原因。

蠕变 (Creep) 这个专业名词来源于材料科学，我们可以参见维基百科的解释：

In materials science, creep (sometimes called cold flow) is the tendency of a solid material to move slowly or deform permanently under the influence of persistent mechanical stresses.

It can occur as a result of long-term exposure to high levels of stress that are still below the yield strength of the material.

Creep is more severe in materials that are subjected to heat for long periods and generally increases as they near their melting point.

在材料科学领域，蠕变 (有时称为冷流) 是固体材料在持久机械的影响下缓慢移动或永久变形的倾向应力。

蠕变的发生由于长期暴露在相对较高，但是低于材料的应力强度的高压力水平下 (因此不会立即发生形变)。

对于长时间受热的材料，蠕变效应往往更为显著，并且随着材料温度接近熔点而逐渐加强。

由此可见，蠕变是一种相对缓慢但是最终结果不可逆的应力过程，我们日常所说的「水滴石川」「铁杵成针」就可以理解为在相对更长的时间周期内效果相对显著的蠕变案例。

蠕变所描述缓慢但是不可逆的变化过程，也存在于需求管理的过程中。我们可以把蠕变的概念，推广到需求管理领域：随着时间不断推移，产品范围在持续的需求变更压力下，逐渐发生缓慢但是不可逆的过程，最终导致了整个产品范围和产品计划的巨大变更。

我们仍然用之前产品范围模型图来说明需求蠕变的过程

从实际情况来看，就和生活中的一切变化一样，需求变更无处不在，而且无法避免：所有需求都有来源、干系人、市场环境、业务流程、监管政策、技术条件，当需求的任意一项关键要素发生变更时，需求也必须随之改变。

在大多数场景下，这些要素的变化是细微且缓和的，不会超出需求管理系统的处理能力极限，只需稍微修改已经定义的产品范围和需求规约，但是随着时间的推移和变化的累积，需求乃至产品的蠕变最终发生。

而作为需求和产品范围蠕变的结果，当一个和最初设计和预想的功能特性有极大出入的项目和产品上线时，这样的项目和产品很难符合客户的需求，更遑论获得用户的认可和欢迎。

事实上，根据 IBM Rational 的项目经理调查报告 (Visitacion, 2003) IBM 的项目经理认为范围蠕变和需求质量的控制成效是项目成功与否的最关键要素。简而言之，软件项目的成功取决于对需求的深入理解和对变更的快速反应。

根据美国国家航空和航天局总部成本与经济分析处的项目成本统计数据显示，在需求流程上花费不到项目或项目总成本 5% 的项目经历了 80% 到 200% 的成本超支，而投资 8% 到 14% 的项目超支则普遍小于 60%。

美国宇航局的研究结论是，对需求管理流程的投资占到总项目成本的 8% 到 14% 时，所产生的项目，其成本超支(相比其他项目）要低得多。

所以，需求问题需要在项目生命周期的极早期阶段就得到处理，因为基于有问题的需求所产生的设计缺陷将导致在项目开发过程中 (甚至是项目上线阶段) 出现解决难度和处理成本都更高的业务问题。

在项目早期对需求管理过程的投入在项目的结束阶段最终收获回报，避免了在此过程中由于需求蠕变所引起的许多的设计问题和业务问题。

由于需求管理过程不尽人意，很多项目最终失败，延期或者超支完成。只有很少的项目可以被算作为成功完成：即在合理的时间范围和成本预算区间内完成了计划的产品需求。

然而项目的完成远非产品的终点，研究表明，在面向客户市场 (也就是商业端市场)，相关企业的最终交付产品中，只有 45% 的功能和特性是用户实际使用的。

换言之，即使很多公司和项目对需求的变更和处理有着相当高效的处理流程，由于对需求理解不够清晰，最终的产品仍然没有满足客户需求。

就像这幅流传甚广的图片所揭示的那样，不同的干系人对需求的理解存在偏差

图中文字依次为：

客户所阐释的需求

项目负责人理解的需求

系统分析师的设计

程序员完成的代码

商业顾问描述的产品

项目文档所记录的需求

产品的运维条件

客户被收取的费用

客户得到的产品支持

客户期望的产品

项目为什么会失败

汇总历年来各种项目调研报告的结果之后，我们可以得到以下失败原因，这些原因概括了我们在项目中所遇到的各种各种的问题。

需求蠕变：需求和产品范围蠕变

资源受限：有限的资源和人员分配

沟通不良：缺乏有效的沟通机制和习惯

反馈不足：闭门造车地处理需求，缺乏最终客户的参与和反馈

排期失准：基于过去经验估算项目时间地排期方式并不可靠

风险失控：缺乏必要的风险管理和控制机制

缺乏规划：缺乏明确和完善的需求规划和项目计划

目标过高：对项目预期过高，制订了不可完成的目标

管理失序：缺乏有效的项目管理流程

需求废弃：需求已经无法满足客户需求，或者不再具有可行性

我们可以将上述十个项目失败原因概括为四个维度：

计划管理

沟通协作

项目管理

需求管理

我们可以看到，这些失败原因有时不仅仅是因为在一个维度存在欠缺导致，很多时候是多个维度的不足协同发生作用，最终导致项目失败。而其中，我们最需要关心的维度就是计划管理和需求管理。

计划是产品的预期，需求则是产品的实体，而计划、沟通和项目都只是推动需求演化为产品过程中的工具和方法，是计划和需求管理的派生物。

如果工具不够好用，我们当然可以换个工具，这对我们的工作成果影响很小，但是如果计划和需求出现问题，那么现有的工作成果难免受到波及，很多时候已完成的产品都需要推倒重来。

卓越的计划管理，需要产品设计者有对客户、需求、产品和行业有着经年的积累和深入的理解，更需要惊人的远见和敏锐的嗅觉。要做好计划管理，不止需要经验，更需要天分。

相较之下，需求管理则有着更加一般化的处理方法：当产品经理和项目经理发现需求问题时，他们会提出并突出这些问题，他们会尝试优化需求管理流程来解决这些问题，他们会不断地吸取经验教训，把自己所学到的业务经验用于防止相似的需求问题重新发生。

这样的话，很多需求问题将在项目早期有效地被识别出来并得到解决，或在开发阶段得到根除。

标准化的需求管理

需求管理通常包括以下阶段：

需求规划

需求处理

需求验证

需求变更管理

以上环节又可以拆分为：

规划需求、收集需求、定义需求、精炼需求、组织需求、记录需求、测试需求，验证产品是否满足需求以及跟踪和控制需求的变更情况等详细步骤和环节。

P1: 需求规划

需求规划包括需求管理计划的制订、评审和批准环节。需求管理计划必须经过所有利益相关方/干系人(包括客户、用户、研发/设计团队领导/经理) 的评审，并且经过项目发起人和关键干系人批准。

「凡事预则立，不预则废」，就需求管理而言，在需求的整个生命周期中，需求规划阶段充当着最核心的作用，可以说需求规划的完善程度几乎决定了后续项目的成果与否。

现在有很多种需求规划模型和方法可供选择，我个人比较喜欢 Google 的 GIST 管理方法

GIST = Goals + Ideas + Steps + Tasks

基于 GIST 方法，我们需要完成以下四个环节：

管理层基于前景分析，竞争分析，战略分析等一系列商业和战略分析结果，制订业务目标

产品管理人员将业务目标初步分解为业务想法 (往往等价于产品需求) ，并分配给产品经理

产品经理将业务想法进一步拆分，依次得到需要设计和开发的业务环节 (等价于功能点)

项目经理、产品经理和相关人员基于具体的业务环节进行更进一步的分析和研究，依次得到各人员需要完成的具体任务，并相应进行分配。

具体任务是需求规划阶段的最小单位，不可再分。

P2: 需求处理

完成对于产品需求的整体规划之后，就应该进入需求处理阶段了。需求处理阶段可以细分为需求收集&需求探索、需求分析和需求定义环节。

结合 P1 所介绍的 GIST 方法，我们很容易发现需求的业务环节和任务分解过程和需求的收集、定义和分析过程是相关关联的。

换言之，需求的具体规划过程和需求处理过程往往是同步进行的。

Step1: 收集和探索

用户的某些需求可能被人熟知，而另外有一些需求可能无人知晓，但是前者不一定比后者更重要。

需求收集的目标是收集尽可能多的需求，最小化未知需求。需求收集的过程非常关键却又相当困难：尽管从用户反馈记录和相关文档中收集信息看起来毫不费力，但是获得准确无误而且组织有序的需求却并不容易。

这些信息可能通过多种方式 (例如，电子邮件，面对面访谈，电话留言，会议记录等) 收集，并以不同的形式 (例如，文本文档，电子表格或存储在数据库中) 呈现。对这些需求信息进行必要的梳理和组织，并确定需求优先级可能是一件相当耗时，繁琐到令人生畏的任务。

需求探索是基于已收集需求进行发散性的讨论，的目的是确认项目不同的利益相关方的需求和限制因素。该过程的结果是：最终在项目干系人间达成了对于用户所表达需求的共同认识。

Step2: 需求定义

需求定义是组织、记录、定义和优化需求的过程。需求定义文档 (Requirements Definition Documentation, RDD) 有时称为需求规约，也就是我们日常所指的产品需求文档。

经过批准的RDD ( 也称为需求基线) 是商定产品范围的文档。它被认为是业务用户 (有时由产品发起人代表) 和产品开发人员之间对于即将开发产品功能的具体规范。

与任何规范一样，RDD 必须记录详细，具体而微，并且必须由合适的项目干系人认可和一直遵守。尽管我们期望这些需求非常详细且被利益相关者充分理解，但这些需求必须仔细定义用户的实际需要，也就是用户预期产品拥有怎样的功能特性，而不是新产品将如何满足用户的现有需求。

开发人员需要充分地了解需求(用户的问题是什么) ，才可以设计出好的解决方案 (何修复用户的问题)

需求文档的标准模板需要充分定义功能型需求和非功能需求，功能约束和基本假设，这种模板是记录和报告需求的有力臂助。市场上有很多可商用的系统和软件可以用于需求的组织、优先级排序和报告。

工作分解结构 (Work Break-out Structure, WBS) 是标识所有产品可交付成果的常用工具。

WBS 对工作可交付成果的定义足够详细，便于轻松管理 (在成本、质量和进度方面) 可交付成果的每个部分。IEEE 标准 803-1998 软件需求规约的推荐实践(IEEE 1998) 有时也被用作软件项目中需求规约的模板。许多组织选择行业中常用的模板作为基准，并按照自身的实际需求对这些模板进行裁剪定制。

Step3: 需求分析

需求分析与需求收集和需求探索紧密相关。需求分析的目的在于发现未知需求，然后将未知需求转化为已知需求。那些在需求收集和需求探索阶段，用户未提及的需求往往可以通过需求分析挖掘出来。如果在项目早期就可以找到这些未知或者遗失的用户需求，对项目大有裨益，这帮助项目将需求变更所产生的成本影响最小化。

需求收集和探索的常用方法包括：

客户体验地图、头脑风暴、商业折纸、脉络设计、卡诺分析等

P3: 需求验证

需求验证是指确保所有已提及需求都被充分满足地过程。需求验证流程通常在项目的需求阶段执行，它包括对于在开发计划中如何满足需求的具体分析，以及用户验收测试 (User Acceptance Testing, UAT) 和有效性验证。

需求验证包括以下常用方法：

参与式行动研究（PAR）、时间感知研究、可用性报告、可用性测试、价值机会分析等

P4: 需求变更管理

需求变更管理 (Requirement Changes Management, RCM) 包含需求变更控制系统的具体实施、与前者相一致的集成项目变更控制系统以及变更(被批准的变更请求) 的实际实施机制。

需求变更管理常常和需求处理和需求验证同步进行，是需求管理的必要组件。

该环节的输入信息是需求管理计划，同时必须仔细定义 RCM 系统的关键部分：

首先是需求变更管理系统；

其次是作为控制和决策的主体的变更管理委员会；他们需求要处理变更请求；

RCM 流程的任何例外和限制；

以及任何可允许的其他偏差。

所有的变更请求，无论大小，不管由谁发起，都应当通过变更管委会。

各阶段的交付物

项目管理从业者惯于遵循那些拥有充分定义的输入信息和输出信息的业务流程。在将流程和模板实施到输出信息之前，他们倾向于寻找有效的输入信息和其他可以用于产出流程可交付物的工具和技术。流程的可交付成果应当得到充分的定义。

需求规划阶段的可交付成果是需求管理计划，由项目发起人和关键干系人评审和批准。

需求处理阶段的可交付成果是所有项目干系人对于需求的共识，RDD 是其共识的记录规范。

一份编写良好的 RDD 只有在它代表了关键项目干系人(包括项目发起人/用户和研发团队) 对于需求的共识时，才足够有效。而需求分析充当着极为关键的角色，要充分发挥需求分析的作用，需求分析师(或者产品经理) 必须精于收集信息，擅于探索需求，长于优先级排序和组织整理信息。

需求验证阶段的可交付成果是用户对于所有需求都得以满足的正式认可。

对于用户端场景，我们需要邀请具有代表性的用户参与测试和验证，并获取其使用反馈。

对于商业端场景，商业客户参与产品评审、测试和验证是需求验证成功的最佳保证。关键因素包括在需求流程中用户的尽早参与和充分协作。

需求变更管理的可交付成果是对所有人需求变更请求的妥善处理以及对于已批准需求的实施。

在项目一开始就识别出所有需求是相当罕见的，大多情况下都会存在需求变更请求。项目团队需要准备好处理突发的需求变更。一个广泛使用的变更控制系统和一个预先安排的拥有适当控制和决策权力的变更控制委员会对于有效的变更管理流程而言都是必要的。

高效的需求管理体系

如上所述，任何有效的需求管理流程必须包含四个必要环节：需求规划、需求处理、需求验证和需求变更管理。

其中任何一个环节都是必须的，需求管理系统帮助产品从业者确保相关项目干系人充分理解需求，在项目早期收集完整，在研发阶段得以处理，并在最终产品中得到满足。

我们前文已经列举了需求管理各阶段所涉及到的一些模型和方法，市场上有相当多的工具和技术可供选择：

用于组织和记录需求的系统/软件工具；

用于定义和梳理需求的模型和文档模板；

用户收集和探索需求的框架和模型；

用于需求测试和验证的方法和工具；

用于需求变更控制方法和工具；

对公司和组织而言，在构建标准化需求管理流程中，所使用的相关技术和工具，只要能满足相应阶段的需求管理目标，就可以视为高效需求管理体系的最佳实践。

如果没有采用标准化的需求管理体系，而仅仅其部分环节作为需求管理获得执行，同样有助于提升项目的效率，但是无助于充分解决项目中的所有需求问题。如上所述，需求管理体系的各环节是紧密关联的，如果缺失部分环节将会极大地影响其他环节的实际效果。

需求收集通常是一件极为耗时的活动，在很多项目中，需求收集往往占据 25% 的项目时间。然而，如果没有产出完整而准确的客户需求列表，前期的收集活动就变得徒劳无功。

即使如此，很多组织仍然只是将需求收集视为一项独立的活动，而非标准化的组织流程。为了提高效率，需求收集活动必须在有客户协助和与其他需要客户参与的需求活动，如需求探索和需求验证，相关联的背景下进行设计和执行。

综上所述，一个卓有成效的需求管理流程必须包含上述的四个需求管理环节，需求规划、需求处理、需求验证和需求变更管理，而且每个环节都需要关联具体的框架模型、工具方法、任务流和文档规范。（文章来源：遍历分形）

项目需求管理专栏︱如何进行高效的项目需求管理相关推荐

纯干货：如何高效的进行需求管理？
问题补充:我现在是一枚产品助理,主要是负责整理用户反馈的需求和问题.有时候整理起来会感觉有点乱.来问下大家的经验,有没有好的方法,工具或者方法? iamturing HUAWEI • 产品经理对于P ...
打造高效的项目团队，促进项目进度管理
项目管理是项目的管理者,在有限的资源约束下,运用系统的观点.方法和理论,对项目涉及的全部工作进行有效地管理.从项目的投资决策到项目结束的全过程进行计划.组织.指挥.协调.控制和评价,以实现项目的目标. ...
企企通X长青热能SRM项目成功上线，共同打造智能高效的数字化采购管理平台
近日,企企通携手亚洲最大燃具阀门制造商及出口商之一--长青热能科技(中山)有限公司(以下简称"长青热能")打造的数字化采购管理平台成功上线.为感谢企企通在公司采购数字化升级的道路上 ...
项目纪实--如何搭建一个高可用强一致性灵活元数据管理的数据平台实现高效可靠的数据分发等功能
项目纪实–大型数据平台系统构建背景:18年入职这家轻松的国企,在19年难得接(抢)到一个有意思的项目,开始定义还比较简单:写一个CMS用于近期某XX项目中发布数据,开始是找到别人被别婉拒后我主动给接 ...
PTC：需求管理是智能汽车高效创新的关键能力
产品开发过程中的需求管理,正在成为中国汽车工业高质量发展的关键能力.近年来,中国汽车工业进入了一个全新的发展阶段--汽车电动化和智能化带来了"以用户为中心"理念在汽车产品开发过程中 ...
软件项目需求变更频繁，如何做好有效的需求管理和规划
概述围绕项目需求变更频繁,如何做好有效的需求管理和规划,本文从背景.问题分析.解决措施.如何进行需求结构化管理?如何进行需求优先级管理?如何避免重要需求遗漏?几个方面进行了细致解答.全程干货. 背景 ...
解决创业型公司项目研发流程的痛点，如何做一个高效的项目团队管理？
现有项目管理流程痛点需求管理:由于迭代更新速度较快,需求没有进行有效的管理,即迭代完成后:迭代需求完成情况确认,是否有遗留或流转至下一个迭代再实现测试管理: 设计测试用例工作的缺失,多少因为需求理 ...
软件研发的项目经理都在用哪些好的设计和管理的软件工具？
软件研发是一个复杂而又有趣的过程,它涉及到多个阶段,如需求分析.设计.编码.测试.部署.维护等.在这个过程中,我们需要使用各种工具来帮助我们提高效率.保证质量.协作沟通.解决问题等.工具化是指将一些重 ...
比DOORS好用的需求管理系统有哪些？对比10大需求管理工具
本文我们主要盘点在不同项目情况下使用比较广泛的10大需求管理工具:1.Excel:2.在线文档:3.PingCode:4.Worktile:5.Doors:6.jira:7.Polarion:8.JA ...

项目需求管理专栏︱如何进行高效的项目需求管理

项目需求管理专栏︱如何进行高效的项目需求管理相关推荐

最新文章

热门文章