关于需求管理的经验我觉得可以读一下WT CEO王涛的这篇文章（产品需求管理经验分享），相信你会有所收获。而关于需求管理工具的选择方法以及推荐，我们将在下面聊到。也因为并不知道其他团队关于需求管理工具的具体需求，所以这里就以我自身的需求和对需求管理工具了解来进行简单推荐，希望能带给大家一定的参考：

在进入正题之前，我们先聊点有用的废话。

一、为什么需要需求管理工具

需求管理主要是进行需求的条目化管理、需求跟踪、需求基线管理以及需求变更的管理。其中，由于需求建立到需求维护这个过程是双向的，需求一旦变多或复杂，双向溯源的关联关系也会变得非常复杂，所以我们就必须借助工具进行管理。

但当前一些需求管理工具，存在两个比较明显的问题：一是当下大部分项目管理工具并不支持做需求管理的一些重要功能；二是需求内容管理工具和需求过程管理工具割裂。造成无法对需求的完整生命周期进行追踪，最后造成需求失控的后果。

需求失控的后果： 需求以失控的状态进入软件过程，从源头上失去了项目的质量保证； 需求范围界定不清，使项目缺乏计划性，导致成本、研制周期失控； 需求变更失控，使组织处于被动反应式的环境中，项目组成为救火队； 需求管理不当，导致项目延期、士气低落，增加了项目的失败风险；  ……

所以就当前管理工具存在的主要问题而言，一个好的需求管理工具除了能满足基础的需求管理、具备自定义能力（满足不同团队的个性化需求）、拥有丰富的场景模板之外（满足日常工作的便捷化需求），还应该具备需求全生命周期的管理的能力。

因为全生命周期管理的好处在于，市场人员在发现需求后能自动流转到下个环节，不对产品、研发人员造成干扰；产品开发进度的把控和查看都变得非常便捷，市场人员也不必天天骚扰技术人员问进度；需求变更的情况能快速的通知到各个环节，避免浪费时间和成本等等。

二、国内外有哪些不错的需求管理工具？

国内PingCode、禅道，国外Jira、visual studio online、gitlab等都是我觉得还不错的产品。但是国外出来Jira本地化版本停售的事件，所以中小企业这里并不太建议国外产品。

三、面对各有特色的工具要如何选？

第一步、要明确需求，考虑部署方式和未来需求的扩展空间，就是说你要用这个需求管理工具干什么？最终想要达到什么目标？未来发展可能会增加哪些工具？

第二步、评估预算，不差钱的企业基本即可忽略这环

第三步、选择口碑好有成功案例最佳实践的软件

四、如果让我选择一款需求管理工具，我会选择什么？

综合上面说到的几点，且利益相关，我司的PingCode就是我的选择了。

选择理由:

1、满足研发全生命周期管理要求，个性化、模板丰富都做的不错

2、对标Jira（这里不得不感叹国外Sass发展真的不错），PingCode功能与产品组合方面和Jira相比已经没有明显差距，而且也比较符合国人的使用习惯（这里是一份两者对比PPT，有兴趣的同学也可以看看）

3、完整支持标准的 Scrum 敏捷开发流程,能够帮助像我们这样想敏捷转型的团队更好落地

4、具有25人以下团队免费版本（这对预算有限的中小团队/初创企业来说是个很不错的消息）

从使用体验上来说，它也是不错的选择：

1、需求池管理

我们都知道，在产品研发过程中，需求管理的一大难点就在于建立需求池并将其与业务体系关联起来。

我们团队利用PingCode，汇集了用户、市场人员、售前、客服等不同渠道的用户故事或缺陷，以史诗、特性和用户故事的三级管理方式进行管理，不仅与业务体系建立起直接连接，也使复杂业务场景中的产品待办事项通过建立一种树形的结构而显得更加直观。

我们的市场人员通过PingCode详细描述需求的不同属性

我们通过这三个层级建立需求的优先级，从而快速筛选出那些矛盾，与产品方向不相符的需求

2、需求追踪

在需求进行的过程中，可以通过概览页面，实时查看当前需求的进度，待办列表的燃尽情况或者用户故事点的燃尽情况。同时，用户故事、缺陷、任务等工作项也都提供全景视图，以可视化方式统计开发和工时数据， 方便我们对研发工作做出及时调整和优化。 

这对于负责人进度掌控或者是汇报来说都是特别舒服的事。

除视图之外，PingCode还预置多种关联关系，让团队成员能更清晰了解工作项之间的联系，判断问题来源和阻碍。 并且工作项评论支持插入代码片段和工作项， 被提及工作项将被自动添加至关联标签页等等。

3、迭代计划管理

在这个阶段，一般来说，最主要的需求是任务的基本属性（如优先级）设置，待办事项拆解、任务指派到负责人，任务状态，开始完成时间等等，而这些在PingCode来说是属于基础的东西，也不多讲。

对比Jira来说，迭代规划阶段PingCode最大的优点是能让项目任务信息更详细的展示，操作的便捷性也有一定优势。

而在迭代开发过程中，通过PingCode,我们团队的每个开发人员可以自行领取相应的开发任务进行编码实现，通过与代码托管平台和CI/CD系统集成，也可以在开发面板上看到每个任务的进展状态。

4、需求变更

据国外不完全统计，几乎40％的需求至少要变更一次，大约10％的需求变更两次甚至更多。所以产品负责人需要一个好的方式来管理这些需求以及变更记录。另外，合理地复用需求也可以极大地减少返工并提高团队的生产力。

就比如，我们通过PingCode对当前迭代所完成的工作成果进行演示，其他成员可以提出反馈建议，评审完成后进入到迭代回顾会议，在回顾会议上成员-起讨论当前迭代做的好的、做的不好的以及改进计划，同时记录在迭代回顾板上

通过[活动]能看到一个需求的所有变更记录，通过关联功能和以前的需求建立起联系。还有Wiki，我们能够找到以往任何时候的产品文档、设计文档、迭代回顾记录等历史信息，从而达到复用的目的。

OK，相信通过上面的介绍，无论是哪一款工具不错，还是如何选择适合自己的需求管理工具，大家都有了一定的想法，所以这里就不再赘述。最后，但也只是建议先试用。一个产品好不好用，产品本身是一个方面，双方的切合度也是非常重要的一环。

欢迎大家试用我司产品PingCode

文／不及物动词