⑴ 软件测试之需求管理有哪些难点
每一位产品负责人、项目经理或业务分析师都需要了解需求管理的重要性。无论是传统项目管理还是敏捷软件开发，成功或失败的基础都取决于需求管理。 需求管理的方法不仅应用在敏捷研发或传统项目管理之中，还适用于金融，制造，建筑，能源，电信等其他行业。 有分析师报告称，需求管理不善导致项目失败的比率高达71%。与技术缺陷、超出时间期限或管理变革失败等原因相比较，需求管理不善的后果更加严重，是项目失败的最主要原因。 因此，在管理需求范围和定义需求的工作中，团队经常会花费会很大精力避免出错。但是在实际的需求实施过程中仍然存在许多问题。 随着项目与业务的复杂性逐渐增加，需求管理不再是简单地管理需求文档，记录相关信息。如今，需求管理中更重要的是要使团队（包括利益相关者）与项目目标保持同步，并构建正确的需求，保证团队顺利实施研发。 在本文中，我们将讨论产品负责人、项目经理和业务分析师在需求管理中面临的几个难点。 01、 什么是需求管理 需求管理就是要识别所有产品和服务的需求，以支持市场的职能。是一套流程，在市场中，一套策划，执行，控制和监督产品的设计，价格，促销，分销的流程，目的是通过满足组织和个人的需要而带来业务 02、 需求池 需求管理难点之一是建立需求池并将其与业务体系关联起来。需求只有与业务使用场景相结合时才有价值。产品负责人也可以将需求按照业务体系进行组织管理，使团队成员能够更好地理解需求。 什么是需求池？ 需求池是一种集中存储需求的方法，将未规划的，未开发的，评审中的和已规划的等不同状态的需求集中管理。需求池充当需求的唯一来源，方便产品负责人（包括利益相关者）查询浏览。 需求信息如果不集中管理，会非常影响团队协作。而仅依赖文档和电子表格也无法解决这个问题，长期维护文档会打断团队成员手头的研发工作，因为通常文档版本很多，不容易快速确定需求的变更、审批、实施进度等最新信息。 03、 变更需求产生的影响 在实际业务中，需求不仅仅是文字记录，而是结构化的信息，具有多个依赖和引用关系。更改一个需求会产生对其他需求，包括史诗，特性，用户故事，任务，缺陷或测试用例的一系列影响。 业务需求和项目复杂度逐渐增加，在研发过程中变更需求会产生怎样的影响，现在也变得不好确认，包括对相关需求和目标用户的案例也要进行调整。 因此，产品负责人手动维护表格或使用文档，很难有效率地管理数百项需求以及变更。 04、 建立需求标准 产品负责人或项目经理面临的另一个难点是：客户或利益相关者会频繁变更需求。客户提出了一系列需求，无论是否确认了需求文档，他们随时都会想要变更需求。 如果项目需求范围发生变化，新的需求可能会增加成本预算，甚至导致项目计划重新安排。团队很有可能会面临预算超支或返工。 频繁变更需求的主要原因在于：需求文档编写和确认过程中，利益相关者没有完全参与进来。如果团队要遵循标准化的需求制定方案，利益相关者应预先确认需求变更的可控范围，团队才能以此进行工作量和成本推算。 05、 版本管理 在项目进行过程中，客户与利益相关者的一些需求变更没有办法避免。几乎40％的需求至少要变更一次，大约10％的需求变更两次甚至更多。 因此，产品负责人需要一个好的方式来管理这些需求以及变更记录。让团队成员可以明确了解，在每个版本中需要做哪些新功能或优化。另外，合理地复用需求也可以极大地减少返工并提高团队的生产力。 现在一些团队仍然在使用Word和Excel进行需求管理，它们没办法解决项目实施过程中的复杂问题。团队需要功能更强大的需求管理工具来进行改善和提高。 如果使用优秀的需求管理工具，如Jira、PingCode等，那么就可以轻松解决所有上述问题。 上文内容不用于商业目的，如涉及知识产权问题，请权利人联系我，我们将立即处理
⑵ PM如何做好需求管理和版本规划
不管是个人还是公司，在每一年或者季度都会有目标、方向上的规划。其实产品也是一样，也是需要目标作为方向的指导。 不管是做一个项目，还是做个产品，明确知悉「目标」，并且以「目标」为最终导向来分解各个阶段目标，朝着方向努力，正如黑夜中向着光明的那一盏灯，即使道路曲折但只要有方向，就不会迷失。 产品的目标，分为［长远目标］和［短期目标］： 产品的长远目标，是与产品定位和战略挂钩的，产品最终给用户呈现的是一个什么东西，能给用户解决什么问题。 短期目标，则可以理解为长远目标的拆分，可按时间拆分季度目标、月目标，或者再细颗粒度拆分为版本目标，在考虑短期目标时需要确保方向是在长期目标范围之内的。 这点相信很多的pm在工作过程中也是知道的，所以不展开细讲，写在这里，只是强调“目标”的重要作用，不管在分析一个需求还是在做规划的时候，都需要有杆“目标”秤，时不时去思考，讯问自己：这符合目前的目标吗？对完成目标有意义作用吗？pm的工作不但是对产品需求进行挖掘分析、产品设计，而且更多的时间需要花在版本/需求管理上，所以，想重点来讲讲关于版本管理和需求管理的一些工作经验分享。 什么时候需要开始版本的管理？如何进行管理？版本前和版本后具体需要做些什么？想必是具体的疑惑点，结合自己的工作经验和总结，个人总结了产品版本规划的流程规范，具体可以看下图：为确保版本开发资源的衔接性，版本开发需要进入并行状态才不会产生资源的闲置。当一个版本开发完毕后，就要立马开展下一个版本的开发，因此，在上一个版本的开发完毕前就要完成新版本的需求设计任务。 一般来说，在完成一个版本的需求分析（包括原型制作、需求评审、需求文档编写）并成功递交给开发后，就要开始新版本的规划任务了。 1、版本目标的确定：在这个版本需要处理哪些模块的功能或者重点支撑哪个用户 2、版本规划书：具体要做什么功能，涉及到哪些端，一般一个版本是大功能＋小功能＋众多bug 3、版本规划会议（部门内部会议，确定版本，确定资源分配）：众人拾柴火焰高，个人的力量与想法毕竟有限，而且技术、运营在版本上也会有自身的计划和想法，因此需要一起来评审规划的版本计划，让各方了解计划要做些什么，也提前准备和进行时间评估。版本中管理，在我理解，其实就是一个需求管理的过程。 许多同学会问：那么每个版本到底要做些什么需求呢？来源在哪？我个人觉得，管理好需求，就是规划版本的来源了。 需求可以分为未挖掘的需求、待规划的需求、规划开发中的需求，来源包括外部用户反馈、同事反馈、内部领导、运营团队、项目团队以及竞品中分析的需求，自己的产品研究得出的想法等等。 那么根据需求类型也可将需求管理总结为三点：1、用户反馈的记录管理 ；2、需求池的管理 3、当前开发任务的跟踪 针对以上3个方面的，我总结了3个层面的列表管理清单（需求池的建立及管理工具，有很多，excel、X-mind、trello 、oBridge、禅道，最适合也最直观的个人还是会使用excel）： 用户反馈列表，收集各种吐槽、优化建议、新创意idea（用户的任何一个反馈，都不能放过。从中挖掘，或许会有新的想法和创意） 使用说明： 只要是有产品的反馈，不管大小，都需要记录下来，最原始最直接的反馈，往往是很多pm会不重视。 及时针对反馈进行等级标注，致命问题需要及时排入版本或者紧急修复，也可锻炼pm的敏锐性。需求特性列表，需求记录及日常管理的清单列表，我会统称为需求池子（这三个清单中最为重要的） 使用说明： 这个清单有两个用途： (1)对目前开发中的需求进行进度跟踪，包括需求分析的进度和开发的进度，哪些需求还在UI设计阶段，哪个端已开发完毕等等，在一个列表中能看得很清楚。具体要看公司对pm的定位，有些公司会将pm的职责定位为项目管理者。 (2)是作为需求池子，对待规划的需求进行管理、分派解决版本，即为确定哪个需求在哪个版本中处理 这个清单，是需要团队中的每个人进行及时更新、维护的，因此规范非常重要。 一般来说，录入需求池是由pm来负责，包括优先级、来源、类型等内容的确定（黄色区域）。在做每个版本的规划前，需要把即将要在下一个版本作的功能需求更新到该清单中（一般是在开完版本规划部门会议，并且得到大家认可无误后更新）。 开发团队、设计团队则对目前该需求的状态进行更新维护（红色区域）。更新时间一般是在每周五部门例会前进行更新，例会时会根据状态进行工作核对。并且在周一分配工作任务时，也可结合清单来进行分配。自己在每天的体验产品方面遇到的bug及优化点（这个列表，是锻炼自己要保持对产品使用频率） 使用说明： 这个清单其实是给自己记录来用的。作为合格的pm是需要每天来用自己设计的产品，从用户的角度去体验产品，从中发现需要改善的地方。因此就给自己制定了这个清单。另外也想聊聊，关于pm的日常工作。传言产品经理需要掌握的技能很多，能画得了原型，分析得了市场，谈得了需求，也能协调得了产品生命周期各环节的工作。我也想分享下，自己作为产品经理的日常： 1、每日产品体验 （Bug List) 每天需要处理关于产品的很多杂乱事项，但每天我也会至少留半小时的时候，对自己的产品以及竞品反复体验，并且记下体验过程中得出来的需求点。这一点能保持作为pm的产品触觉，也能让自己回归为用户去体验、思考产品。 2、用户反馈收集与反复查看（Feadback List） 每天定期查看产品的用户反馈后台，自建渠道包括用户群，社交媒体是否有用户投诉反馈，清楚问题之后记下需求点，若是属于bug或者急需解决的需求，立刻反映给开发解决，若是属于不紧急的需求，则列入版本迭代规划中。 3、数据分析（可行性低，b端产品） 4、每日站会，了解目前阶段情况，统筹与识别风险 每天会组织团队开10分钟左右的站立式会议，主题很明确，每人发言将昨天自己工作的内容和今天计划要做的事情，具体涉及到需要协调、沟通的，会议后再具体进行，在不耽误大家的工作时间情况下，是了解目前进度的很好的方式。
⑶ 如何做好需求管理
大多产品经理都是从管理需求的工作做起，负责产品的定义，并检验研发出的产品是否符合最初的产品定义。这要求产品经理培养自己一定的需求管理能力。一般来说，产品需求管理包含以下工作内容：
1）需求收集，包括被动和主动的需求收集，其中主动的需求收集要求掌握需求收集的途径和方法，产品创意需要统一纳入到需求收集的范围；
2）需求分析，通过需求分析的层级模型，透彻地分析需求背后的用户问题和痛点，用户的需求场景，必要时还需要通过一些简单的原型确保准确地理解用户需求；
3）需求分发，不是所有需求都要纳入到下一个产品版本，成熟的需求管理团队能够发现高价值的中长期需求，在需求分发环节将其纳入到产品规划；
4）需求实现，该阶段的责任主体是产品开发团队，产品经理需要确保产品开发的各个阶段没有偏离自己的产品概念；
5）需求验证，包括产品经理对产品的验证，还包括产品经理主导的用户验证。
总的来说，产品需求管理能力培养的目标是发现价值需求，形成能够获得市场成功的产品概念，以指引产品研发团队顺利研发出让用户满意的产品。
⑷ 需求管理主要包括什么
需求管理主要包括1.确定需求变更控制过程。制定一个选择，分析和决策需求变更的过程，所有的需求变更都应遵循这个过程。2.进行需求变更影响分析。评估每项需求变更，以确定它对项目计划安排和其他需求的影响，明确与变更相关的任务，并评估完成这些任务所需要的工作量。这些分析将有助于需求变更控制部门做出更好的决策。3.建立需求基准版本和需求控制版本文档。确定需求基准，这是项目各方对需求达成共识时的一个快照，之后的需求变更遵循变更控制过程即可。每个版本的需求规格说明都是独立说明，以避免将底稿和基准或新旧版本相混淆。4.维护需求变更的历史记录，将需求变更情况写成文档，记录变更日期，原因，负责人，版本号等内容，及时通知到项目开发所涉及的人员，为了尽量减少困难，冲突，误传，应指定专人来负责更新需求。5.跟踪每项需求的状态。可以把每一项需求的状态属性（如建议的，已通过的，已实施的或已验证的等）保存在数据库中，这样可以在任何时候得到每个状态类的需求数量。6.衡量需求稳定性。可以定期把需求变更（添加，修改，删除）数量和原始需求数量进行比较，过多的需求变更是一个报警信号，如果需求蟀达到50%，则意味着项目的基本需求并未真正弄清楚，这个项目应该取消。
⑸ 有什么好的需求管理工具
在这里我给大家推荐个灵活实用、专业性很强的需求管理软件（oBridge）
oBridge为企业带来以下效益：
通过快速记录和共享需求，确保用户需求都得到处置
帮助用户进行设计和测试覆盖分析，提高产品质量
通过变更影响分析，帮助用户评估变更工作量，有效控制项目边界
基于条目存储，提高复用效率，为企业需求量化管理打好基础
通过需求快速生成工作任务，合理复用需求数据
需求管理系统（oBridge）功能导航
项目功能列表
需求管理需求管理支持版本化、条目化 管理文档和需求条目，支持自定义需求流程、数据权限控制、需求多层次关联、需求生成工作任务、建立需求跟踪矩阵、自动标记变更影响、自定义报表样式，可输出到WORD和EXCEL，支持离线数据交换。
产品管理产品管理支持多个产品集中管理，可分版本进行管理，支持规划产品版本路线和模块，可指派到具体项目中进行落实，支持查看产品的详细信息。
⑹ 需求管理的目标是什么
1.需求管理的目标软件的需求管理包括在工程进展过程小维持需求一致性和精确性的所苟活动。需求管理需要完成的任务包括；明确系统的需求并达成共识；建立不同需求之间的关联；根据不同需求设计相应的解决办法；对系统需求进行优化，提出设计的方案；监控和解决可能们现的问题以及需要做出的改变；控制不同层次开发任务的开展；监控开发者可能出现的重复等，其目的是为使需求管理实现如下目标：(1)确定各方对需求的一致理解。(2)管理和控制需求的变更。(3)从需求到最终产品的双向跟踪，保持产品和活动与软件需求的一致。2.需求管理的原则在需求管理的过程中，所产生的直接效益或许并不太明显，也或许要日后才能体现，但是无序的、没有经过精心策划的需求管理是不可能产生效益的。因此，在需求管理中、开发组织成该定义项目组执行督理他们需求的步骤，为了需求管理产生效益应该强调以下几个方面的内容：(1)控制对需求基线的变动。(2)保持项目计划与需求的一致。(3)建议、处理、协商、通告新的需求和变更给有关的功能域的方法。(4)控制特种需求文档和单个需求版本的情况。(5)管理需求和联系链之间的联系或管理单个需求和其他项目可交付品之间的依赖关系。(6)分析已建议变动的影响应遵循的步骤。(7)跟踪基线中需求的状态。(8)需求状态跟踪利报告过程。可以在一个需求管理中包含所有的内容。也可以根据需求管理情况来进行删减。
⑺ 如何做好需求管理系列（1）—— 做什么和不做什么
如何做好需求管理系列（1）—— 做什么和不做什么
序：需求管理源于业务需要，始于需求挖掘，继而需求分析，需求定义，需求验证。周而复始。
因为用户需求（业务需要）是无限的，所以经过产品经理整理、分析所形成的“产品需求”也是种类各异且数量众多的。因此，对于一名产品经理而言，有效的进行产品需求的管理是非常重要的。在本系列文章中，我将与你分享“优先级判断”、“如何挖掘需求”、“如何定义需求”、“如何验证需求”，这四个方面的相关经验。
对于产品需求优先级的管理，普遍采用 四象限定位法 ，其中以需求的急需性作为横轴，需求的重要性作为纵轴；四个象限分别为：
“四象限定位法”的优点是充分利用了消费者的需求特征层次。其缺点也相当明显，由于仅从需求的重要性和急需性考虑，需求划分的粒度过大，仅适用初步筛选，无法对 产品需求优先级进行量化。
接下来，我将同大家分享 产品需求优先级量化模型 ，在开始之前，先进行一些预备知识的铺垫。首先，我们来定义“重要性”，我们认为，当某个功能可以明确解决用户的某个特定需求或者某个功能可以为用户提供前所未有的服务时，该需求的 重要性为高。 然后，有别于单一时间维度的“急需性”，我们尝试使用“可行性”来替代四象限定位法中的“急需性”。“可行性”即在有限的 资源和时间内 是否可以达成预期目标。
明确了“重要性”和“可行性”的定以后，我们开始使用需求优先级量化模型，模型的使用分为三个步骤：
以某社区电商某个版本的需求为例，来讲解 需求优先级量化模型 的建立：
Step 1 列出采集到的用户需求
将4个主要需求填入表单，形成如下表格。
Step 2 填写“重要性”和“可行性”权重表
为了正确的填写权重表，我们需要对需求（目标）进行逐条分析，评估其重要性及可行性。当我们面对复杂或者难以判断权重的需求时，我们可以使用中位数3来表示该需求的权重。因为有了中位数作为基准，确认其他需求的重要性和可行性也更加容易。下面，我们来逐条分析这四条需求，并完成需求权重表的填写。
“增加独立访客”，可使用电商的黄金公式——销售总额 ＝ 流量 x 转化率 x 客单价，进行分析。流量对销售总额有着重要影响，经过几个版本的推广，流量作为重要因素但非决定性因素存在，其重要性为4；在拥有一定体量的前提下，继续获得新增用户的难度是很高的，其可行性为2。
“提高访客的购买金额”，在流量和转化率趋于稳定的前提下，提高访客的购买金额（客单价）将成为接下来工作的重点，其重要性为5；可行性方面，通过采用精确推荐、捆绑销售等手段可以实现客单价增高的目标，其可行性为4。
“增加页面中商品展示区域”，从已有经验来看用户访问页面深度基本呈正态分布，增加商品的展示区域对网站各方面数据的帮助可能比较有限，其重要性为1。相比需要借助其他渠道才能获取的新用户，完成商品展示区域的扩大其可行性要高一些，这里记为3。
“收录更多的商品”，收录的产品数量是否会对网站产生影响是一个未知数，于是我们将这个需求的重要性和可行性均记为3，用中位数来表示难以判断的情况。
经过以上分析，将分析结果填入表格中，形成如下表格。
请记住这个非常重要的公式 ：版本周期内的可用资源数 ＝ 需求数量 x 权重中位数 。以本文中的需求为例，版本周期内的可用资源数 ＝ 4（需求数）x 3（权重中位数）＝ 12。
接下来，我们计算该版本中四个需求的重要性总和可行性总和，我们会发现，重要性总和：4 + 5 + 1 + 3 = 13；可行性总和：2 + 4 + 3 + 3 = 12；当前版本的重要性总和 > 可行性总和，意味着我们必须对四个需求做出合理的取舍才能保证，在既定的迭代周期内实现版本价值最大化。
然后，按照重要性和可行性的维度对需求进行划分， 我们将需求分为：核心需求，有价值的需求（辅助需求），可忽略的需求 。将权重表中的数据填入可行性-重要性坐标系，完成需求量化。
观察需求分布统计图，我们可以得出以下结论：
最后，“需求优先级量化模型”的使用，有如下几点说明：
如果，你对本文介绍的“需求优先级量化模型”的使用有任何疑问或者对需求管理方面有独到的见解，欢迎在评论区与我互动，谢谢你的阅读。
-EOF-
⑻ 需求变更与版本管理
这里的版本号指的是产品的版本号，对应的也是文档的版本号。 版本号：a.b.c a为大版本号，产品重大版本更新时可以申请升级大版本号 b为小版本号，产品普通版本更新时升级小版本号 c为方案版本号，产品方案在内部讨论时的版本号 记录每次修改的修改日期、修改人、修改内容提要，审核人。每次做需求变更的时候都需要有新的文档（修改原来的文档也不是特别麻烦的事情），产品经理不能口头改需求，再小的需求修改都要有文档。
⑼ 如何做好需求控制
当开发人员做了一个已经被取消的功能，你能想想他有多沮丧；当测试人员按照老的测试案例去测试新的需求规格的开发结果时，他可能要抓狂。出现了这些情况，都是因为需求的版本控制出现了问题。说到需求的版本管理，是不是就是需求文档放到配置库就可以了呢？答案是——不仅仅如此。因为需求有它的特殊性，有它分析和管理的特殊要求，所以在实际的工作中的需求版本我们考虑更多层次：对整个文档进行版本的管理是最基础的。当谈及最新版本时，项目团队的成员“应该”都知道它指的是哪个版本的文档，比如说2.1版。应该上面加引号是有用意的，因为实际的情况是每个人往往都是指向自己的机器上的文档版本，以为是最新版本。需求条目的版本是什么意思呢？需求条目的版本表示了对每个需求对象进行更细粒度的控制。需求文档里面有若干条需求组成，两个需求我嫩大版本之间可能是几个需求项发生了变化，有时候我们需要更清楚的知道某条关键的需求，何人何时创建，何人何时做出何种修改，并且能够知道修改的开始和结束的状态，并且显示出其中的差异，最好能可以自动的回退到某个历史状态。这些工作中的需求，实际上都体现了对需求条目层次上版本管理的要求。今天，越来越多的公司采用迭代或增量开发模式。为了降低风险，将开发过程分为多个增量部分可以加快整个开发过程。那每个阶段结束后，是不是要将整个项目的文档做一个快照呢？通常是需要的，那此时的项目基线也就是我们这里说的需求体系的版本。需求体系的版本包含自需求而来的多个相关文档，此时的版本管理不仅应将这些文档打上统一的基线，并且将该组文档之间的追踪关系也进行基线化的管理。对文档之间的追踪关系也进行基线化的管理意味着什么呢？项目的每一个阶段，需求文档会有不同，那需求文档之间追踪关系也会有不同。那当我们记录下项目每个阶段的需求文档及其追踪关系的版本后，在日后的工作中，我们可以回溯到以前的某个需求版本，并能够按照当时的项目追踪关系，追踪分析当时的分析设计结果，实现对整个需求体系的掌握，能够更好的理解，利用以至复用已完成的工作成果。
