积压管理的失落艺术 “产品人员-产品经理,产品设计师,UX设计人员,UX研究人员,业务分析师,开发人员,制造商和企业家 July 07 2020 真正 一致性,产品待办事项列表,产品所有者,产品要求,要求,Scrum,团队一致性, 注意产品 介意产品有限公司 1374 Ferenc Horvath在Unsplash上​​拍摄的照片 产品管理 5.496

积压管理的失落艺术

通过 ON

产品管理仍是一门年轻的学科,我们使用的方法一直在发展。当前在产品社区中,诸如产品发现,基于主题的路线图以及结果与输出之类的话题都非常流行,这是正确的。这些都有助于推动我们的技术进步,并使团队能够解决正确的问题并创造成功的产品。

最近,关于产品经理和产品负责人之间区别的争论也很多。有人认为产品负责人是内部的,而产品经理是外部的。其他,例如 梅利莎·佩里(Melissa Perri) 说产品管理是工作,产品所有者是Scrum团队中扮演的角色。

产品经理确实应该扮演产品负责人的角色。但是,在参加为期两天的课程并获得CSPO或PSPO身份的同时,您可能会为产品所有者的角色做好一些准备,但很多方面并没有教您。它不会教您如何定义产品策略,如何创建产品消息,如何定价,推出或淘汰产品等等。 马蒂·卡根(Marty Cagan)说的差不多 back in 2016.

当然,与没有几年产品管理经验并获得认证的人相比,具有几年产品管理经验的人的职位恰好是“产品负责人”。如Martin Eriksson所述,缺乏对产品职务的一致使用无济于事, 经验丰富的产品负责人应该真正改变其职称.

但是,似乎对产品负责人的角色和认证不屑一顾,也许是因为它们没有让您做我上面提到的所有事情。许多人认为认证没有价值或只有很少的价值,或者仅值得拥有以确保您通过求职申请的关键字检查的简历。

我最常用的报价之一来自 彼得·德鲁克:

做正确的事比做正确的事更重要

但是,本着敏捷宣言的精神,它’s not that we don’t 做正确的事,只是我们更看重“做正确的事”。但是,也许有些团队并没有那么平衡,因为多年来,我看到许多团队没有非常有效地实施敏捷方法。这将影响团队实现这些预期成果的能力,并影响他们希望对KPI和OKR产生的影响。

待办事项反模式

具体而言,尽管经常将产品经理提升为产品所有者,但我发现积压管理方面存在许多不良做法…产品所有者角色的关键职责,而许多产品经理似乎并没有完全掌握这些职责。

积压的时间很长

积压的项目太多,难以管理,无法确定优先次序,也难以理解。很长时间以来,有很多项目都在积压中。它们可能曾经很重要,但现在可能不重要。定期修剪您的积压订单,并删除那些从未引起团队注意的长期存在的物品。如果他们真的很重要,他们会回来的。

将每个想法添加到待办事项中

您的团队正在处理的待办事项不应包含任何人曾经拥有的所有想法。您也不应添加每个客户请求;您对“我’将其添加到待办事项列表中”是一个空洞的承诺,从长远来看,它将影响您的信誉。您的待办事项应仅包含您有信心在短期内解决的事情。您需要跟踪其他内容,但要确保将策略,想法和反馈与执行分开。

战略调整

定期查看您的积压订单,以了解其如何与您的策略保持一致。它提供了路线图上的内容吗?创建新的积压项目时问自己一个问题。确保团队了解您的前进方向。这将鼓励好的和相关的想法,并进一步鼓励他们积极主动。否则,如果他们所有的想法都没有付诸实施或被清除,那么团队将变得动力不足,并且不鼓励他们在未来做出贡献。与客户围绕战略进行讨论也是一种在有理有据的情况下对他们的要求说“不”的方式,同时获得您对未来方向的投入和支持。

传送要求

当需求在计划会议之前从任何地方魔术般地出现在待办事项的顶部时,这意味着团队没有做好准备,您也没有为成功做好准备。当然,计划和优先级可以改变,但是当每一个需求总是无处不在时,这意味着没有计划,没有路线图,没有一致性,并且团队也不了解他们正在努力的目标。

团队不看积压

如果您的团队是第一次在精炼或规划会议中讨论要求时才知道,那么这不是一个好兆头。这可能意味着他们对产品的投资不如应有的那样,或者太忙于交付功能而无法考虑下一步的目标以及他们要实现的目标。一个明显的迹象是,由于团队忙于当前的工作迭代而跳过了优化会议。

产品负责人“拥有”积压的商品

需要注意的另一个迹象是产品所有者(PO)过于积压了待办事项。 PO可能拥有优先权,但这是 团队的 积压,应鼓励所有人做出贡献–仅举一个例子,PO过度保护的迹象可能是团队抱怨高水平的技术债务,但没有积压–实际上,它们是“不允许”在待办事项中包含重要细节的。

让团队参与产品发现会议并直接与用户联系也很重要。他们将学习并做出更多贡献,但是在评估团队的能力,速度和运输代码时,这通常不会发生–即基于产出而不是结果。

错误的详细程度

如果您的需求是从没有描述/故事,没有接受标准的占位符开始的,并且以某种方式弥补了积压并以几乎没有细节的状态进入了开发阶段,那么团队真的应该退缩。但是如果团队 不是 往后推,那么成功的机会是有限的。

估算(如果有的话)可能不可靠,您的计划将无效,团队也不太可能提供预测结果。当这种情况反复发生时,就会失去动力,并且也可能对支持,销售和市场营销等其他团队产生连锁反应。

但是,您也可以走到另一个极端,细节太多,定义得太早,而且变得如此规范,以至于团队几乎没有进行课程修正或创造的空间。最好有一个   backlog, 投资 在用户故事(或其他形式)中使用 3 C’s (card, conversation &确认)方法。

最后的想法

我个人认为几年前参加CSPO课程非常有价值。我已经有很多经验,但是当我的团队刚接触敏捷时,它就教会了我关于产品负责人的角色,因此非常值得。尽管我已经从Mike Cohn,Roman Pichler和Kenneth Rubin等人那里读了很多书,但我学到了一些新知识,可以立即在办公室使用。–真实衡量任何培训课程的价值。

这些课程可能不会使所有人受益,但会评估您如何扮演产品负责人的角色,并从团队和您的同行那里获得一些反馈。如果您认为自己有改进的余地,请考虑一下,因为不仅可以从中受益,而且您的团队,产品和客户也可以受益。