优先级:如何摆脱那些讨厌的错误? “产品人员-产品经理,产品设计师,UX设计人员,UX研究人员,业务分析师,开发人员,制造商和企业家 March 03 2019 真正 错误,功能积压,优先级划分,产品管理最佳做法,产品管理技能,产品路线图, 注意产品 介意产品有限公司 1489 产品管理 5.956

优先级:如何摆脱那些讨厌的错误?

通过 ON

作为产品顾问和培训师,我一遍又一遍地听到很多类似的问题。您可能会期望很多,并且经常在Twitter上讨论:“产品经理和产品负责人有什么区别?” “我应该如何管理路线图?” “产品经理需要知道如何编码吗?”

但是,除了这些热门话题之外,我认为还有一个问题更加一致:“我应该如何管理错误?”错误并不是科技界最性感的话题,但我们都知道了。因此,让我们谈谈如何处理他们。

一盎司的预防

我住在德克萨斯州–炎热的夏天和大量的蚊子的土地。您可能会说我们有一个错误问题!我们可以肯定地知道的一件事是,一旦您有了蚊子,几乎就不可能消除它们。在今年早些时候发现第一只蚊子时,您会知道随着季节的推移情况会越来越糟。所以我们非常重视预防–确保没有积水让幼虫生长,在无法阻止积水的地方进行预处理,并采取其他策略来避免初生蚊子。

这与软件有什么关系?管理错误就像管理蚊子一样–您应该首先避免让它们进入环境。而且,您越早在项目中放过一个漏洞,越可能发现越多的错误,并且清理它们的难度就越大。

这似乎是常识,但您有多少故事 几乎  已在迭代结束时完成,但只剩下几个错误需要修复?有人建议“好吧,让我们继续讲故事,并记录下一次迭代的错误。”有多少次? 不要这样! 如果在开发功能时某些功能无法正常工作,或者您刚刚构建的功能现在已经破坏了其他功能,则不是错误。它是未完成的代码。立即修复。 (显然,您可能会选择不修复某些极端情况,这可能是另一篇文章。)

没有魔术队列

我发现人们喜欢谈论错误,就像它们存在于另一个维度中一样,在其中进行操作不会损害其他任何东西。倾向于给bug赋予特殊的状态,在每次迭代中给它们分配特定的时间,或者在极端情况下,对错误修复的时间表设定一些错误的时间表(“所有报告的bug都在五天内修复”) 。

这里的问题是 机会成本。归根结底,错误只是另一项工作。您的团队花在修复错误上的任何时间都不花在处理路线图上的下一件事上。作为产品经理,我们应始终管理积压订单,以便 接下来最重要的事情 在列表的顶部。很多时候,您要处理的错误不如待办事项上的其他问题重要。通过处理优先级较低的错误,您正在推迟可以帮助您实现战略目标的更重要的工作。

另一面也是如此:有时候,下一个最重要的事情可能是五个或六个错误,这些错误确实需要修复,然后才能在脆弱的平台之上添加另一个功能。如果您生活在一个排长队的世界中,或者说您总是将团队20%的时间用于错误,那么您实际上会失去机会说:“本周,我们将解决这些困扰我们的错误,然后再进行处理。事情。”实际上,您的积压中可能会混合有错误和功能,但是最重要的是,您要有策略地,有意地进行优先级排序,而不要让错误的约束条件决定积压的比例。

那么您如何管理呢?实际上,我确实建议对错误进行优先排序,将优先级最高的错误放在顶部。这可以使诸如客户支持之类的角色保持整洁,这些角色定期添加到列表或添加其他信息。我可以讨论哪些错误真正造成了最大的痛苦,并进行相应的调整。然后,我确定路线图工作的优先级。一旦我在待办事项列表中列出了接下来的几件事,我就会查看我的主要错误并开始评估–这些错误中的任何一个是否比我列表顶部的错误具有更高的优先级?如果是,我确定它们应该适合的位置,并且我的优先积压工作已经完成。

估计或不估计

有时,我会与团队讨论您是否应该估计错误。与产品中的大多数事物一样,我的答案是, 这取决于。尽管这不取决于变化的情况,但更多取决于组织的理念。

人们通常使用三种方式来估计错误:

  1. 像您讲故事一样估算错误–通过复杂性为其提供故事点值,并将其纳入您的速度
  2. 给错误指定任意点值(3?),并在速度计算中使用它,知道有些实际上比分配的值大而有些小于指定的值
  3. 完全不要估计错误,也不要将它们纳入速度计算中

团队越在乎速度,估计辩论就越热情。特别是在开发团队要对其速度进行严格审查的组织中,关于如何获得漏洞“信用”的讨论变得更加重要。我不赞成一般地关注速度(同样,可能还涉及另一篇文章!),所以我倾向于偏向方法2或方法3。追求完美估计通常是徒劳的,但是如果您的现实是 要跟踪您团队的工作量,找到一些合理的数字并继续前进。如果遇到大型错误,而该错误最终需要重写系统的整个部分,则将其变成一个故事并适当地加以说明。因为正如我们前面所讨论的,错误只是积压工作中的另一项工作,因此您可以随意调用它!

为什么不组建Bug团队?

一些公司试图通过留出一部分预算并创建一个独立的“ Bug团队”(或更名为“维护团队”)来解决错误问题,其工作是修复错误并进行所有需要进行的繁琐平台维护即将发生。我认为,这是您处理错误的所有方法中绝对最糟糕的方法。

首先,您仍然没有处理机会成本,也没有给自己灵活性以优先处理下一个最重要的事情。有可能 感觉  就像您完全控制了积压的订单一样,因为这些错误不再被入侵。但实际上,这只是隐藏工作,仍然使您面临着错误的风险,而这些错误的重要性远不及这些团队成员在其他地方所做的工作重要。

第二, 没有人愿意在一个错误小组工作。整天清理别人的错误,永远不要在构建的东西上贴上自己的指纹,这没什么好玩的。对于开发团队来说,当他们知道实际上不需要修复该错误时,可以轻松地放过错误。最重要的是,很难激励一个团队的工作看起来并不积极地为产品愿景做出贡献。组建一个“轮换的错误小组”,其中几个常规的开发小组成员每个星期都专注于错误几个星期,这也不起作用。避免修复混乱的bug或真正缓慢地工作,这很容易,一个人知道如果您只能停顿足够长的时间,那很快就会成为别人的问题。一个可怕的概念。

错误不是特别的

所有关于错误的讨论实际上可以归结为一个主要概念: 错误并不特殊。 关于如何管理它们,如何计数或应该对谁进行处理,我们引起了很多争论,但是我们真正想要的是制造客户喜欢使用的产品。错误可能会阻止这种情况,但是构建错误的东西,糟糕的UX或制造难以访问的产品也可以。关注客户真正喜欢它的产品的真正需求,并修复使您无法实现目标的错误。