产品经理核心技能修炼如何做好产品需求管理
⇨⇦
管理产品需求是一项重要的产品经理基本功，如何管理产品需求清单，让产品开发变得仅仅有条？本着＂拒绝纸上谈兵＂的初衷，我想总结一下我的答案，以下6招优化产品需求清单，让你＂轻装上阵＂。
大部分产品经理都很忙，为了完成任务而疲于奔命，是生活的常态。产品需求清单就像一个＂杂物箱＂，写满了点子、用户故事、功能需求、bug……只要是和产品有关的，统统往里装。任务一来，先写到产品需求清单里，有什么不对吗？
没时间整理产品需求清单，也是一个问题。清单越来越长，分不清轻重缓急。许多产品经理告诉ProductPlan，他们的产品需求清单就像＂无底洞＂，不知从何下手。
产品需求清单应该长啥样？为什么要区分优先级？让我们退一步想：为什么产品经理要用产品需求清单？
理想状态下，产品需求清单的内容包括：产品团队下一步要完成的、与产品相关的任务；完成以上任务后，需要关注的事项（在一定时间范围内）。但是，事实上，产品需求清单的内容不止于此。许多其他的任务占据了太多空间，让清单的管理变得困难重重。
这就是区分优先等级的原因。产品需求列表要做到结构明确，重点突出，而不是成为一个＂杂物箱＂。如果有人和你说：＂把XX丢到产品需求列表里。＂但没有人觉得这不合理的话，那么你的产品需求列表已经沦陷了。
ProductPlan（作者所在产品团队）专注于优化产品经理的工作，使之井井有条，符合战略愿景。我们发现除了产品路线图的问题，混乱的产品需求列表也是工作效率、成果的致命伤。
下面，就让我们来了解一下6条优化的方法。
将下一次迭代的内容＂置顶＂
把下一次迭代的内容＂置顶＂，把下一个迭代的内容，作为清单的优先处理事项，避免时间表混乱。
这样一来，优先处理事项就有了明确的时间表——下一个迭代就要做。
当然，首先，你要有一套机制，用来决定下一次迭代做什么，我会在下文加以阐述。
剔除优先级低的任务
把＂优先级1＂和＂优先级2＂的任务纳入产品需求清单，其他的另外归类（比如纳入＂长期任务＂）。就是这么简单粗暴。
假如，经过多轮头脑风暴，产品团队列举了20种可行的产品创意。显然，短期之内，这20种创意不可能全部实现。那怎么办？区分优先级别！
选出最好的2至4个，拆解为小任务，安排团队成员完成。
至于其他的创意，可以先记下来，但不要纳入产品需求清单（更不用说产品路线图了）。产品需求清单要尽可能简明扼要、现实可行。
列出下一次迭代要做的事（优先级1），接下来几个月要做的事（优先级2），就足够了。
如何处理＂优先级2＂的任务？请见下文。
创建其他任务清单
把真正紧急、有战略价值的任务纳入产品需求清单，把其他不那么紧急的事项另外归类，会让整个清单更具针对性、更具战略价值。那些把清单越写越长的产品经理——他们不知道该把非紧急事项记在哪——使用清单自然困难重重，也更有可能遗漏重要任务。请记住这句话！
创建其他的清单非常必要，比如＂好点子＂清单，＂长期任务＂清单。
创建任务价值打分系统
ProductPlan的产品路线图App内置加权打分功能，在时间、预算、人力资源有限的情况下，产品经理需要对每个任务的战略价值打分，利用有限的资源，创造最大的价值。
管理产品需求清单时，ProductPlan打分的指标有三个：用户价值、营收、成本。
把任务分为三个优先级：优先级1、优先级2、长期任务。＂优先级1＂的任务下一次迭代要完成，＂优先级2＂的任务接下来三个月要完成，剩下的都属于＂长期任务＂。
每一个任务为什么会在清单上，在哪里，都一目了然；向利益干系人、其他团队解释时，也会事半功倍。
创建任务成本（时间、人力等）管理系统
记住完成每一项任务所需的时间。这一点很重要。不仅要知道总的开发时长，还要知道每一位开发员工所需的时间。把时长（小时、天、半天）转化为积分。比如，一个积分代表一天。完成某个用户故事的编程工作，是一个1积分的任务，也就是要花1天的时间。
这样一来，产品需求清单变得一目了然，用全局的眼光安排时间和人员，也变得更简单（不再纠结于时间单位的转化、人数的安排）。
注意事项1：估计任务积分时，要有全局观。例如，修复某个bug可能只是一个0.5积分的任务，也就是要花半天的时间。
但是，这只包括识别和修复bug的时间，不包括测试时间，也就是编写和运行自动化测试的时间。所以，估计任务积分时，最好保守一些，宁可高估，不可低估。
注意事项2：同一个任务，对不同的员工来说，所需时间不一定相同。
请记住，每一个产品团队都是独一无二的，不论是技能、特长，还是短板。在计划时，产品需求列表的重要性不言而喻。如果某一个任务，只有一两位开发人员有能力做，分配任务时更要小心，不要让别的任务干扰了他们的工作。
定期更新
产品需求清单是活的，不是死的——任务优先级是可变的。
如果你遵循以上5条建议，每一次迭代结束，产品需求清单就会更新一次，＂优先级2＂的任务就会升格为＂优先级1＂的任务。
此时，产品需求清单上的每一项任务都有特定的战略意义。当你打开清单，判断任务优先级是否有变动——不论出于何种原因（竞争对手情报、用户请求、bug紧急修复）——一切都清晰明了。
最重要的是，你不再胡乱猜测，而是开始系统性地做决定。