在前两篇文章中，我介绍了我们如何在Drift（Burndown）上构建自己的产品构建框架，并在第二篇文章中讨论了如何在自己的公司中实际实现Burndown框架。
现在，该谈谈有时感觉对流程而言是次要的事情了，这些实际上是使所有这些信息正确流动的关键。 那些东西是…
- 处理错误
- 处理产品积压
- 选择下一步优先事项
- 每周一次的完全透明更新
1-处理错误
我们认为错误应归工程团队所有。 因此，Github问题就是他们的住所。 当错误弹出时，团队中的任何人都可以创建Github问题。 如果是客户报告的错误，我们会在Github中给它一个红色的“ Bug”标签，并在报告该错误的对话中发布一个链接。 我们优先考虑这些错误。
根据一般经验，我们将大约20％的时间用于解决错误，而其他80％则用于新功能，基础架构工作以及对现有功能的改进。
- openBOM — BOM参与系统
- 每天拥有更多能量的20种小方法-Alexis Meads
- 战略生产力：如何完成出色的工作，尽情享受并精力充沛！
- 不工作-练习
- 尽管有添加，我该如何做：这是您可以从我的经验中学到的东西
当错误浮出水面时，这取决于工程师的判断力，需要立即予以注意，并且可能会稍有延迟。 这就是为什么Github中的“ Bug”标签如此重要的原因，因为它增加了针对付费客户的情况的可见性和紧迫性，如果该漏洞很严重，则可能会造成流失。
在实施Burndown的过程中，头几个月（每周一次）中，每个团队的产品经理都会与技术负责人坐下来，讨论他们团队拥有的Github存储库中的错误积压。 这样，项目经理和工程师可以就最重要的内容，原因保持一致，并随着时间的推移学会彼此信任。
随着Burndown原则和框架逐渐成为一种文化，并且由于PM相信工程师可以像他们一样拨打电话，因此不再需要每周召开一次会议。 现在，在每周开始时（通常在周末），技术负责人和工程师将解决Github问题，并找出他们计划在该周解决的最重要的错误。
由于Burndown不能在为期一周的艰苦周期中运行，因此不断引入错误，要求我们停止正在做的事情并立即解决，因此我们确保在出现问题时留有额外的能力来处理这些问题。它们可以并行进行。
2-管理您的产品积压
到现在为止，您可能想知道……您对积压了4、6和12个月的想法的积压怎么办？ 在哪里保存所有这些信息并组织起来？
根据积压的大小，用于实现Burndown框架的Trello板可能会从板最右边的太多列表中断开，这完全可以。 那就是我们发生的事情。 于是我们进化了。
现在，我们仅将主要产品Trello板用作我们确定范围和记录实际完成的微缩图的地方。 如果某个东西在那儿呆了一个月以上，并且不断被推销而从未完成，那意味着它不是最优先考虑的事情，而且很可能永远也不会。 因此，我们将该列表存档。
Burndown框架旨在让您专注于短期和近期内您可以做的最高杠杆工作。 除非您是一个规模较大，结构非常严密的组织，否则任何设计和确定范围的工作都需要3个月以上的时间，否则到您到达该时间时，它们通常都会发生巨大的变化。 我们的一个团队中有一位设计师比团队提前了3个多月，而最终，她所设计的大多数东西都没有成为现实，因为我们很快了解到我们想朝另一个方向发展。 没关系。 这就是我们注册使用Burndown的方式。 最糟糕的情况就是仅仅因为已经完成了这些设计就继续实施它们。 由于Burndown本质上是灵活的，因此它使我们可以轻松地说“不”，并采取另一种更有希望的做法。
如果您像我一样并且专注于客户发展，那么您仍然需要一个场所来组织您每周和每天获得的所有客户反馈。 我建议要么制作一个不同的Trello板来容纳所有这些想法和反馈，要么无限期地扩大Trello板的宽度，只要您每隔几周仔细检查一下并归档那些不与产品去向一致。
3-选择下一步优先级
确定要处理的下一个最重要列表的最佳方法是问问自己这个…
“为我们的客户提供最大价值并与我们的业务目标和重点保持一致的一件事是什么？”
回答这个问题应该可以为您提供长远来看可以最大程度地发挥作用，继续为客户增加价值的东西。 这个问题是加里·凯勒（Gary Keller）在他的书《一件事 》中提出的问题的衍生，这是“我现在可以做的一件事是使其他一切变得简单或不必要？”我们认为，漂移有助于我们专注于正确的事情。
我们还以主题方式组织公司即将到来的优先事项，将其放在一张幻灯片或一张列表中，并一遍又一遍地向团队重复。 在我们的例子中，示例列表看起来像这样……
- 保持产品稳定
- 推动更多注册
- 提高激活率
- 创新我们的聊天小部件
当我们问自己下一步可能要关注什么时，这为我们提供了所有参考指南。 如果您不能做直接受益于＃1的事情，那么就做一些会影响＃2的事情，依此类推。
4-每周一次的完全透明更新
由于Burndown框架会随着内部的微冲不断变化以适应客户的需求，需求和愿望而不断变化，因此确保团队步入正轨并具有里程碑意义非常重要。
这是我们周五在Drift上保持优先次序的方式，产品经理将与每个团队的技术负责人坐下来，并讨论即将到来的Trello板上的微型冲刺，持续约5-10分钟。 有时很明显，下一件最重要的事情是什么，我们马上就在同一页面上。 其他时间，对话中会提出好的观点，微冲刺/列表也会稍有变化，并作为下一周的重点。
然后，每个星期日晚上，产品经理都会撰写一份内部Wiki帖子，其中包含战术上的细目分类，其中Trello的列表将集中在接下来的一周以及它们为客户提供的价值上。 通常需要1-2个小时，但第二天早上让团队保持一致是值得的100％。 如果做得对，这是产品经理每周需要执行的唯一项目管理。
该帖子分为四个部分（每个产品团队分为每个部分）…
- 如果我们运送了我们计划运送的所有物品，我们将在周五发送给客户的公告
- 所发货物品的视觉/屏幕截图（来自Trello的HIGH LEVEL卡）
- 每个工程师和设计师所关注的细分
- 上周发货清单
内部职位（列表中的第一名）的顶部是针对Drift客户的书面声明。 该陈述的写法就好像是在周末结束时的星期五一样。 如果我们完成了计划要解决的所有微型冲刺，那么这正是我们将在本周末向客户宣布的内容。 这是我们的Web应用程序团队的一个示例…
然后，对于第2部分，我只是删除所有功能的屏幕快照，按团队分组。 我通常给它一个快速的标题，然后放一个完整的屏幕截图，像这样……
对于第3部分，我为每个工程师和设计师汇总了项目符号列表。 这样做的目的是简洁明了，并在整个星期中仅向公司中的每个人展示谁可以寻求任何具体的东西。 并记录每个工程师和设计师所说的是他们的优先事项。 通常，我会在每个星期结束时与团队成员进行快速的Slack检查，以听取他们的想法，并在必要时进行纠正。 在大多数情况下，项目经理应该已经了解了整个星期中发生的其他对话，每个工程师和设计师在做什么。 这是第三部分的示例…
第4部分是已发货和仍在进行中的简短清单。 这是供销售和成功团队查看已完成的工作和即将执行的工作的地方。 看起来像这样…
请记住，每个星期内可能会有2-4个微冲刺，完成后我们会立即发货。 这些每周签到和更新的方式可以确保每个人都对进展情况有所了解，并以切实的方式说出“我度过了一个富有成效的一周”，然后在周五出发。 周日更新中发布的内容不是“无论如何都必须执行”的列表。 有时会发生某些事情，而我们计划做的事情将不再进行，因为出现了更高的优先级，可以更好地影响我们当前的公司优先级/主题。
–
我们正在开始尝试一种新的沟通公司目标和产品优先级的方法，我可能会在下一篇文章中谈到。
请告诉我关于Burndown框架是否还有其他问题。 我相信我已经介绍了如何在您自己的公司中开展这项工作的所有必要方面，所以请让我知道您是否仍然认为通过评论无法回答问题。
