需求梳理会（Product Backlog Refinement Meeting）在Scrum框架中都没有正式的“名份”，只是在2020年《Scrum指南》的Product backlog中有提及：“Product Backlog Refinement是将 Product Backlog 条目分解并进一步定义为更小更精确的行为。这是一项持续进行的活动，为Product Backlog 条目增添细节，例如描述、优先顺序和规模”，不过在Scrum Alliance官网上对 Product Backlog Refinement有更详细的描述。（https://resources.scrumalliance.org/Article/product-backlog-refinement）
需求梳理会作为正式迭代开始前的准备仪式，对迭代成功与否起到关键作用，所以即使“名份”不高，但是我们必须十分重视，这里我们为大家总结了一份需求梳理会的最佳实践干货集，希望能对你的需求梳理会有所启发，大家也可以根据团队的实际情况进行调整运用。
话说：不想做产品经理的程序猿不是好厨师，这几年随着产品经理这个岗位的火热，越来越多的程序猿、设计师、项目经理等专业人士转型去做产品经理。
做专业技术出身的人，往往会养成一种思维习惯，看问题的角度也会形成惯性，我们把这种思维习惯叫做工程师思维。
Read more →
该引导用户习惯，还是顺应用户的习惯？ 这是很多产品汪纠结的问题。
不要轻易挑战用户的习惯，否则会被用户打脸！除非你的改版、“创新”带来的用户价值足够大。
第三部分 把握用户的心理
本文转载自虎嗅网，虎嗅根据点点网CEO许朝军的博客内容，把腾讯张小龙关于《微信背后的产品观》现场分享实录呈现给大家。这个系列共有三个部分，本文是第三部分。前文请点击：张小龙的微信产品思维（上）；张小龙的微信产品思维（中）
Read more →
第二部分 满足用户的贪嗔痴
本文转载自虎嗅网，虎嗅根据点点网CEO许朝军的博客内容，把腾讯张小龙关于《微信背后的产品观》现场分享实录呈现给大家。这个系列共有三个部分，本文是第二部分。阅读前文请点击：张小龙的微信产品思维（上）
Read more →
第一部分 简单就是美
本文转载自虎嗅网，虎嗅根据点点网CEO许朝军的博客内容，把腾讯张小龙关于《微信背后的产品观》现场分享实录呈现给大家。这个系列共有三个部分，本文是第一部分。
在产品经理的金字塔中，占据塔尖10%的都具备下述特点中的几条，而塔尖1%的产品经理则具备以下所有品质。
视野开阔: 塔尖1%的产品经理思维不会被今天或当今市场环境中可以获取的资源所限制。他们会描绘出颠覆性的大机遇，并为抓住这些机遇而制定具体计划。
交流: 1%产品经理的提议是无法反驳或忽略的。他们会恰到好处地使用可以得到的数据，但也会利用偏好、信念以及激将法等让掌权者乖乖拿出经费、资金或其他资源并不再加以阻挠。
Read more →
敏捷开发里边有很多地方需要多次进行优先级排序，本文将探讨其不同的应用场景，及其关系。
值得注意的一点是，敏捷开发中有无数的“自相似性”，比如估算，每年、每月乃至每天人们都在潜移默化地估计自己的任务；又如计划，也是每年每月每天都有成文或不成文的计划；而发布，也是每个故事自成单元，而又与其他的故事构成每月的交付，进而形成几个月的大版本交付……
由于这些自相似的活动颗粒度不同，一定不要认为只要做一次就可以了，也不要认为用一种方法做就可以了。要就具体活动思考这一活动的目标是什么，以及如何才能更好地达成这一目标。
Read more →
由于我对估算和计划是在太感兴趣了，因此每当我看见有人在博客或者消息组里面宣称“估算是在浪费时间！别再做了！”我都会十分留意。有趣的是，这些针对估算和计划的争论从来都不会来自那些我们为他们开发产品或者系统的那些人，因为他们都明白估算和计划的意义（以及错误的估算和计划带来的痛苦）。
让我们来仔细想想那个观点。在你的人生当中，有多少件事情是你完全没用做计划的？我估计你会为婚礼做计划，为搬到另外一个城市做计划，为假期出行做计划，或者为任何你事先没有打算做计划的这类事情做计划。
假设你打算第一次去意大利旅行。你可能会计划去哪些城市，每个城市要呆多久，预算是多少等等。现在假设你打算第一百次要回去你长大的故乡，你也会进行计划——尽管你计划的内容是决定你不需要做任何计划。
计划，是一种考虑将来的行为。有时候，将来是存在着风险以及不确定因素的。在这些情况下，我们需要比对可预知的将来（如第一百次回故乡）做更多的计划。当未来是可预测的时候，我们要做的计划可能只是花费几个毫秒来决定我们并不需要做更深入的计划。
当然，一个软件项目远没有那么简单。
那么估算呢？我们真的需要估算吗？答案是肯定的。因为估算是计划的前提条件，你不可能在没用做任何估算之前就做计划，就算这些估算是非正式的或者是隐式的。当我在写这篇文章的时候，我还在飞往加州的飞机上。在登机之前，我决定去ATM机取一些现金，因为我估计在稍后我需要一些现金。然后我又估算了一下数额，大概200美金就足够了。在这个例子中，估算所花费的时间还不到一秒钟，我甚至都还没有意识到，它就已经发生了。
当一位Product Owner 说：“我希望加入这个特性，而不是那个”的时候，他其实已经在为每一项特性所需要的时间做估算了，虽然这是一种隐式的估算（或者叫做猜测好了）。当一位程序员决定在下班之前修复一个BUG，而不是开始做一个新的用户故事的时候，其实他也进行了一次隐式的估算，而他估算的是在到下班之前的这段时间里，他刚好有足够的时间完成这个BUG的修复工作。
有的团队说：“我们不会进行估算的，我们只会把所有用户故事定义成同样的大小”，但是他们却没有意识到其实他们已经是在进行估算了。在这里，他们所估算的是一个用户故事要和其他用户故事的大小相同。其实，我认为要令所有用户故事大小相同，比要估算在大小一定范围内的大小不一的用户故事更困难。
其实，尽管你没有意识到，但是在不知不觉中你已经进行估算了。那些在博客和消息组里面说估算是浪费时间的人，正是忽略了这种估算的存在。
但是，这种随意的，下意识的估算足够吗？如果团队进行正式的估算会不会更好呢？
也许吧，但是并不是所有情况都适用。团队只有在深入调查后需要采取不同的行动的情况下才有必要进一步深入估计，否则就应该适可而止了。当然，如果进一步的计划能够让团队作出更好的决定（对交付日期更有信心，或者更好地为功能排列优先级等等），那么就应该进一步估算及计划。
举个例子，我们最近在给一个网站添加对我们的敏捷估算和计划的eLearning功能的支持。我没有询问负责这个功能的程序员完成该功能所需要的时间，但是我仍然能够有一个大致的概念知道需要多久能够完成。因为我和他已经在一起工作很久了，我对他的工作效率非常清楚。进一步地追问并不会为这个项目带来任何改变。
从上述可见，估算和计划是必须的。因为它们可以（而且应该）是轻量级的。如果进一步的估算不能让你做出更好的决定，那么你目前的计划就是足够了的。
1.让整个小组参与。
特定活动的主要职责可能会落在某个人或者某个分组身上，例如确定需求的优先级主要是产品所有者的职责。但是，在最求可能具有高价值的项目时，要让整个小组 参与进来并做出承诺。例如，我们可以在一条建议中看到这一点，这条建议就是虽然可能很明显只有1~2个特定的小组成员会处理正在估计的故事或任务，但整个 小组做出的估计才是最好的。小组成员分担的职责越多，小组可以共享的成功也就越多。
2.在不同层次上进行规划。(产品Backlog->Spring Backlog->任务->每日计划)
不要错误地认为发布计划会让迭代计划没有用，反过来也一样。发布计划、迭代计划和每日计划分别以不同的精度覆盖了不同的时间范围，而且各有其特定的用途。
3.使用不同度量单位，让对规模和持续时间的估计保持独立。(规模和工作量的关系，故事点)
让对规模和持续时间的估计保持清晰区别的最佳方法是使用不会造成混淆的独立度量单位。使用故事点来估计规模，再使用速度把规模转换到持续时间是完成这一工作的好办法。
4.用功能或者日期来体现不确定性。
没有哪个计划是必然发生的。要确定您制定的任何发布计划中都包含对不确定性的体现。如果新功能的量是固定的，就把不确定性表示为一个日期范围（“我们会在 第三季度完成”或者“我们会在7~10次迭代中完成”）。如果日期是固定的，就需要表示在要交付的确切功能上的不确定性（“我们将在12月31日完成，产 品至少会包含这些新功能，最多可能只会再包含那些新功能”）。不确定性较大的时候，就使用较大的单位（例如迭代、月，季后是季度）。
5.经常重规划。(滚动计划)
利用每次新迭代开始的时候评估当前发布的关联度。如果发布计划是根据过时的信息或现在被证实为错误的假设制定，就更新它。使用重规划的机会来保证项目总是瞄准着向公司交付最大的价值。
6.跟踪进度并沟通。
有许多利益相关者会对项目的进度很敢兴趣。通过经常发布有关小组进展的简单而易于理解的指示器来让他们了解进度。耗散图和其它让人一眼就能看明白的项目进度指示器是最好的。
7.承认学习的重要性。
由于项目既是向产品增加新能力，也是产生新的知识，所以必须更新计划来包含这些新知识。随着我们更多地了解客户的需要，会把新功能增加到项目中。随着我们更多地了解我们使用的技术或我们合作的情况，会调整对进度率的期望和希望采用的方法。
8.规划具有适当规模的功能。(故事点的粒度问题，短周期迭代)
在不久的将来（接下来几次迭代中）就要增加的功能应该分解成相对较小的用户故事–通常就是需要1~2天，最多不超过10天的事项。我们最善于估计规模处于 一个数量级内的工作。让用户故事都处于这一范围内，可以让我们在估计和规划中付出的工作量和得到的准确度达到最佳的组合。它还可以提供足够小的用户故事， 让大多数小组合一在一次迭代中完成。当然，在较长时间的项目中，使用小用户故事会很费事。为了平衡这个影响，如果您要建立的发布计划覆盖的时间范围超过了 未来的 2~3个月，也许可以编写一些更大型的故事（称为史诗）或者使用主题，来对时间更遥远的工作进行估计，从而避免过于提前把大故事分解成小故事。
9.确定功能优先级。(计划安排之基本，规模和优先级)
按照让项目总价值最高的顺序来处理功能。确定优先级时除了考虑功能的价值和成本，还要考虑它能带来的学习效果以及开发它能够减少的风险。可以在早期消除一 个显著的风险的可能性，往往就足以保证先开发某个功能的合理性。与之相似，如果开发特定的功能可以让小组获得大量有关产品或他们开发它的工作的知识，也应 该考虑尽早开发这个功能。
10.把估计和计划建立在事实上
只要有可能，就把您的估计和计划建立在现实的基础上。确实，有些时候在某些公司中会需要在没有什么事实根据的情况下对类似速度之类的事做出估计。但是，只 要有可能，就应该根据事实的测量值建立估计和计划。这同样适于一个功能完成了多少的问题。很容易知道一个功能完成了0%的时候（我们还没有开始处理它）， 也相当容易知道我们已经完成了100%的时候（产品所有者的所有满意条件测试都通过了）。在这两者之间就很难度量了–这项任务完成了50%还是 60%？由于这个问题太困难，最好还是坚持您所知道的：0%或100%。
11.保留一些松弛度。(项目进度和人员缓冲)
尤其是在规划一次迭代的时候，不要规划用掉所有小组成员100%。就像公路达到100%容量的时候完全停滞一样，如果将所有人的时间都规划成满负荷工作，开发小组的进度也会减慢。
12.通过前瞻规划协调做个小组。
在涉及多个开发小组测项目中，应该通过滚动前瞻规划来协调他们的工作。通过前瞻和把特定功能分配到即将来到的特定迭代，可以规划和调节小组间的依赖。
