散文精选网产品需求管理的工具？
我们平常有在用redmine，主要用于提交bug以及追踪bug解决进度，也用于提交优先级比较高、工作量又不大的产品优化需求。缺点：组内成员无法针对某个问题展开讨论，且不支持将图片直接贴在问题描述区。confluence是充当需求管理和知识积累的工具。做知识积累还算可以，但是做需求管理，缺点是不能及时追踪问题的处理进度、无法对问题标注优先级，也就是confluence是存放需求池的好工具，但是对需求管理整个过程却不是最佳的选择。日事清管理工具弥补了这两个软件的不足，方便跟踪问题的处理进度、可标注问题的优先级、可将问题指派给某人，将任务层层分解，日事清看板功能将工作一目了然的呈现。
延伸阅读
产品管理中的需求优先级如何排序？
有这样一个问题，题目是：假设现在你负责一个产品的设计，请注意这个前提，现在有若干个需求列在这里，请排一下顺序。
A、市场合作伙伴给你提供的需求，要求你产品做某种改进以便他们推广，这样可以给你带来每天不少的流量，对用户的影响未知； B、销售部门给你的需求，要求产品做某种改进以满足广告主的期望，对用户可能会有少许不利影响；
C、某个知名的产品设计大师，行业内公认的领袖级人物，在公开的博客或私下里跟你说的，他认为用户所需要的功能；
E、客户服务反馈过来的信息，很多用户提出的一种需要。
F、市场调研公司发出的报告，通过调查问卷获得的用户需求。
产品经理工作中打交道最多的就是需求了。每天的纷杂事务中，大多数工作都是在处理各种各样的需求。当我们面对纷繁复杂的世界，我们要想使自己更清醒，更加超然脱俗的把事情做好，就必须要做出取舍。产品管理中，我们需要同样的道理，来对待它。
产品是一整套固化的解决方案，其本质就是用来解决目标用户的需求。在互联网产品管理过程中，对待需求优先级的判定和管理，个人认为有如下三个原则。
1、客户需求优先级高于用户需求。从某种角度来看，客户是一种特殊的用户类型。这种“用户”他为产品买单，在产品应用上，有更大的话语权。利用自身的资源、技术和竞争优势，满足客户更多的需求，以实现互联网产品的增值，这本身就是互联网产品经营的方向。因此客户需求的优先级是要高于普通用户需求的。当然有一种情况需要特别说明，当客户需求和用户需求产生冲突的时候，我们要考虑的就不仅仅是优先级的问题了，而是在满足需求和解决矛盾的过程中，产品的价值是否得到了体现，是否是一个可持续发展的选择。
2、确定的需求优先级高于不确定的需求。一个需求的提出，其背后往往代表了若干人等的产品诉求。对于这样的诉求，我们是否清楚来龙去脉，是否有足够的调研数据以证明其真实性，是否符合产品的战略发展规划，是否有潜在的风险尚未考虑到…当一个需求的方方面面都是确定的，都有初步的论证和思考之后，才是动手去响应的好时机。俗话说，谋定而后动，就是这个理。当然也有人说互联网讲究的是兵贵神速，什么都考虑清楚了，黄花菜都凉了。这话也是有道理的，做互联网产品必须是小布快跑，否则肯定落后，但是这与要做明确的需求并不矛盾，只是对产品经理有了更高的要求–既要准，也要快！
3、响应需求必须考虑投入产出比，算成本帐。在有限的资源条件下，要优先处理投入少，收益大的需求。而对于响应代价太大，而效果评估不高的需求，要敢于舍弃。只有这样，才能轻装上阵，在有限的条件下，做出出色的产品来。
结合上述三个原则，回头再看这道题，答案就应该清晰不少。
需求A、B都属于不确定的需求，哪怕再诱人，都不能轻举妄动。要“发回重审”或协助完善需求，把需求明确了再来谈优先级。
需求C貌似金玉良言，不过再知名的产品专家，也不能一下子就能洞悉先机。毛泽东同志说过，没有调查就没有发言权。因此，需求C也是不确定的需求，听听就好了，千万别盲目崇拜。
需求E是确定的客户需求，这是毫无疑问的。
需求F是基本确定的用户需求，前提是该调查问卷时针对产品做的有效调查问卷。
需求管理包含哪3个主要活动？
需求管理是一种用于查找、记录、组织和跟踪系统需求变更的系统化方法，可用于获取、组织和记录系统需求并使客户和项目团队在系统需求变更上保持一致。有效的需求管理在于维护清晰明确的需求阐述、每种需求类型所适用的属性，以及与其他需求和其他项目工作之间的可追踪性。
需求管理活动包括：
(1)定义需求基线。
(2)评审需求变更并评估每项需求变更对软件产品的影响从而决定是否实施它。
(3)以一种可控制的方式将需求变更融人当前的软件项目。
(4)让当前的项目计划和需求保持一致。
(5)估计变更所产生的影响并在此基础上协商新的约定。
(6)实现通过需求可跟踪对应的设计、源代码和测试用例。
(7)在整个项目过程中跟踪需求状态及其变更情况。
产品经理如何管理需求方预期？
产品经理在管理需求方的预期是必须要做到需求挖掘、需求的匹配和需求的安排必须要合理。
了解公司的业务是需求挖掘的大前提，只有结合公司的业务发展方向和商业模式才能判断需求能不能做，需要查看自己行业所处的发展阶段是否适合这个需求，也要有计划的安排需求开发。
如何进行产品功能需求优先级管理——抓大放小？
作为产品经理的你，洋洋洒洒的整理完产品的功能列表，长舒一口气，看，爷的产品多强大，规划了这么多牛掰闪闪的功能;作为交互设计师的你，头晕眼花的画完产品的原型和流程，暗自窃喜道，看，咱的流程多细致，梳理了那么多特殊情况和可能性;作为视觉设计师的你，设计了好多个华丽丽的界面，你为每一个页面进行了精心的雕琢，期待用户见到每一个页面都竖起大拇指说这个界面真漂亮;作为开发人员的你，搭建完框架之后，发现每个模块都有评审时漏掉的细节，一个模块一个模块的赶进度，导致你精疲力尽力不从心。 其实，在一个产品里，并不是所有的功能都那么重要的，如果产品经理只是交付一个功能列表，而不做需求优先级设定的话，产品可能沦为没有主心骨的产品，交互设计师设计的时候，不确定主要任务是什么;视觉设计师设计的的时候，不确定哪些界面和模块要提供更精致的设计;开发人员开发的时候，不知道哪些功能该设定更高的开发优先级，于是就会形成大家都在搅浆糊的状态，可能因为某些弱弱的分支流程的复杂性，导致开发人员花了大量的时间去攻克难题;可能因为某个不那么重要的设置界面中，UI增加了复杂的转场效果，导致开发人员搞到头破血流;可能因为开发人员捡着简单的功能先做，导致复杂的重要功能到最后才被草草攻克，一堆bug。别在抱怨各个角色不给力什么的了，想想自己的需求的分析是否到位，是否给你的需求排排等级，哪些对解决产品的商业价值+用户价值有最大的帮助，优先实现它，不重要的，不着急的，可以次优先级实现。
