回答一些问题在产品的所有权

你曾经工作在一个团队中,你觉得每个人都告诉你要做什么,每个人都相互冲突的需求,和他们一样,他们不断在改变主意吗?你感到的压力从一件事转移到另一个,回来。项目经理看起来筋疲力尽试图管理所有这些依赖项,决策者和其他项目经理。产品所有者的责任是为了提供一个清晰的和简单的Scrum团队更好地管理责任。当然,挑战仍然存在,但至少你有保护Scrum框架以有序和结构化的方式取得进展。这是产品所有权的梦想。,这是一个消息我们大力推类,材料,和评估。产品负责人的想法实际上拥有产品允许团队遵循他们的愿景和方向。它减少了复杂性通过提供一个单一的、集中的人决定了团队的工作是有价值的,什么不是。他们要负责团队交付的价值和利益攸关方看到这在每个Sprint。 If the investors in the team do not like the direction then they can provide feedback. If the team and the Product Owner do not take that feedback they can, ultimately remove funding, etc. But we hope that making progress, and transparent value means that this rarely happens. Additions to the Scrum Guide in 2020 of the Product Goal and more clarity on planning made the focus on value and outcomes even more explicit.

但是很多人产品的内部和外部社区发现产品负责人的想法具有挑战性和有许多合理的关切诸如“一个人怎么能做出亚博一百送一百所有的决定的产品?”,“不是这力量剥夺团队?在规模”、“这是如何工作的?”、“这个人叫什么?”,和其他问题,注重团队之间的关系,客户和其他利益相关者。

让我们花一些时间来回顾这些担忧,并试着回答,或者至少给我看来看到产品的所有权在100年代的组织。

怎么能一个人做所有的决定的产品?

构建现代产品是一个复杂的工作。设计思维的融合、业务知识、技术知识、市场背景,甚至决定复杂的法律和监管要求。对于复杂的产品,对一个人什么都知道是不可能的。但这是产品所有权的力量,不知道一切的能力但能够提出问题,做出决定基于一个清晰的愿景,结果产品的想法。从我的经验,最好的产品的人不是最博学的但是是最好奇的好主意的原因。他们形状上下文的理解为什么团队有资助,专注。他们挑战的利益相关者包括河马(高薪的人意见)根据上下文来证明他们的立场的原因。他们关注结果,开车去衡量事件可以帮助塑造他们的工作的方向。他们也非常关心产品服务的人。最终产品所有者需要自己的产品的愿景,能够将这一愿景转化为明确的目标,然后,通过与Scrum团队合作成为渐进步骤中所描述的“疾跑”目标。 And the people who fund the Scrum Team have to be OK with the Product Owner taking charge of the vision. Of course, they get input, but they have to trust the Product Owner to be championing the vision they have paid for. If they do not trust that person then they have to become the Product Owner.

不是产品所有权的剥夺权力Scrum团队?

有一个神话,产品所有者是唯一人洽谈客户,使产品决策,理解业务。在最有效的Scrum团队每个人都与这个问题需要每个人负责了解客户、业务和环境所使用的产品。没有产品所有者瓶颈。是的,产品所有者将周围的护栏产品的方向,但他们不能也不应该做每一个决定交付产品所需的目标。这意味着Scrum团队一起工作来发现需求,了解用户,欣赏人资助工作的欲望,和需要做的产品目标或挑战其相关性。他们与产品所有者合作,确保他们的工作是在必要时支持他们的视力提问和挑战。

肮脏的事实是,有时工作不是最有效的与团队成员工作的地区,他们没有先验知识,但Scrum的伟大之处是每个人一起工作包括产品所有者帮助转移知识和提供更好的支持。并且经常缺乏先验知识可以帮助问的问题应该问挑战现状,找到独特的创新的解决方案。有时天真,天真的人做的工作实际上是一种机会,而不是一个问题。但只会这样如果团队是错误操作在一个“安全”的地方,说“我不知道”是鼓励和支持。

这个人叫什么?他们的工作职位是什么?

我认为有一些讽刺的想成为敏捷的组织也要固定职位定义了明确的职业道路和技能列表。当然敏捷组织的目标是有一组人有一些技能,也愿意学习,做其他的事情,能够外出工作的舒适区。不过,我很欣赏,人们需要职位,薪资结构,和推广模型。所以应该执行产品负责人的岗位职责的人被称为产品负责人吗?

他们可以,但是很明显,产品所有者Scrum指南中描述不足以定义他们的工作或提供的描述他们的职业道路。最终职位是定义的组织,它可以是产品经理,产品所有者,业务分析师,索赔经理,运营经理首席医疗项目的支持,或其他人。我甚至见过一个兽医在动物医院的职责是使用Scrum。工作的重要组成部分并不是标题但职责和经常报告结构。产品所有者将会发现更容易完成他们的工作,如果他们的职责描述产品/结果/价值流/服务/平台(等)拥有。他们也会发现它更容易做他们的工作的人是否真的,真的,真的关心这个产品是有效和基金工作的人报告。所以在许多IT组织的情况下这意味着做产品所有权的人应该报告业务使用系统。当然,也有例子,因为利益相关者的数量做相反的事情是很重要的,但总的来说,明确报告线产品所有者可以获得更多的关注和更多的成功。

你还需要一个产品所有者如果你没有得到一个产品?

2020年更新Scrum指导的定义产品非常灵活。

一个产品是一个车辆交付价值。它有一个清晰的边界,利益相关者,定义良好的用户或客户。一个产品可能是一个服务,物理产品或更抽象的东西。

所以技术上只要工作有一个明确的边界,利益相关者可以测量和价值,显然,任何产品。成功的关键是明确加上一个清晰的理解客户和访问。越与客户和不清楚的界限,越难有人使用Scrum,从而难以实现产品负责人的职责。

许多组织的现实是,他们使用Scrum项目。工作的项目是一个集合,为许多客户提供服务,和产品所有者实际上是一个项目经理或业务分析师的工作。Scrum仍然可以交付价值在这些情况下,可以成为一个伟大的工具,更好的规划工作,确保进展更频繁,甚至获得更好的利益相关方参与。然而,你正在失去利益创新或者至少出站顾客价值创新。同时,经常在这些情况下,团队是一个更大的计划的一部分,跨团队的依赖关系。这导致在得到真正的挑战,以价值为导向的工作。这也意味着有一个巨大的开销需要确保每个团队不打破其他团队的工作,或等待太长时间工作。集成变得复杂。联系提供一些想法如何更好地调整团队,还描述了需要只有一个产品负责人。然而,挑战与复杂的项目和使用Scrum大于我在这里可以处理的了的。

底线是,即使在产品是一个非常松散的情况下举行了现实,产品负责人的岗位职责的力量适用。简化决策,要有一个清晰的愿景,定义一个产品的目标,关注价值在决定下一步要做什么,时刻让事情透明,这样每个人包括利益相关者可以提供输入使航向修正。

我只触及表面的产品所有权的挑战,但简单的想法可以为团队提供更清晰和焦点。如果做得正确,产品所有权也可以成为一个伟大的导师和教练对于一个组织变得更加的结果和以客户为中心。