Scrumcn_product_owner

产品负责人需要克服的普遍挑战

在选择早期产品负责人的时候,有许多潜在的隐患。以下是在项目早期最常遇到的问题以及如何解决他们的建议。

产品负责人授权别人决策,但是他们往往凌驾于决策者之上。

 

为了安排好新的任务功能,一些产品负责人会授权别人为产品的某个部分做决定。另一些产品负责人会选择某个业务分析人员做系统某个部分的“功能负责人”。这些方法都行之有效,因为通过这样做,产品负责人就能够花更多的时间集中精力去做那些难以授权别人去做的事情。

 

 

产品负责人说决策权已经授权别人了,但是他自己又继续批准或者有时候甚至改变别人的决策,那么问题就发生了。在授权之前,项目负责人应该确信他们真的愿意授权别人做决策,而不会事后批评。因为做sprints的时候,时间是固定的、有限的,在其压力之下,Scrum团队推进项目进度的速度往往会比在他们转型之前快得多。不可避免地,一些在授权范围内做的决策在后来会发现是错误的,这些错的地方需要重新回头纠正。然而,我们想要避免的是项目负责人一边说:“问Dave吧,系统的这个部分是他管的”,但是一边他又凌驾于Dave的决策之上。

我建议新的产品负责人,当他们工作超负荷的时候,能通过授权别人给自己取得一些自由的时间,授权程度可以直至感觉自己的工作负荷舒适为宜。你会很惊讶并且很愉快地发现,这么做的结果是并没有什么重要的决策需要重大修改。但是,你有时候也会发现,如果是你自己做得话,有些决策会和他不一样。通常,在这种情况下最好的选择就是像我们刚学驾驶的时候学的:如果车子开始打滑,那将方向盘转向车子打滑的方向。不要费大力气改变这样的决策(当然前提是这个决策不是非常的糟糕),允许这个决策保持到Sprint结束;然后再决定是否需要改变它。在改变一个决策的成本和产品backlog所有其他有价值的工作之间进行比较时,你就能知道这个决策并不是那么糟糕。

产品负责人对团队强迫过甚

产品负责人往往感到有压力,需要向公司提交有经济价值的成果;为了这个目标,更快提交更多功能的产品是一个方向。就像我曾经说过的,我不反对产品负责人在项目开始的时候宣称:“我们需要做个更小、更好用并且比其他竞争者更省钱的产品,我们需要比上一个产品少用三个星期来完成它。”面临一个有挑战性的目标,只要这个团队同时能有适当的自由度达成这个目标,就会做得最好。但是,如果总是催促强迫团队,每个sprint都是如此,那么问题就会产生。“六个月之内完成这件伟大的事情”是个很困难的目标,但是它在很多方面还不如13个为期两周的“我要更多!更多!更多!” 的sprint有紧迫感。如果你的团队中产品负责人用前面这种方法推进团队的项目任务,那么ScrumMaster应该让项目负责人停止催促强迫,并和他一起为团队制定长期的目标,同时保证团队能有相应的自由度来达成这些目标。

 

产品负责人总想降低品质

试图在一个很难完成的期限内提交一系列本身很有挑战性的功能的时候,降低品质是个非常诱人的决定。这能在短期内看上去似乎达成了项目初始制定的目标。但是最终,如果当产品发布之后发现:比往常更多的BUG,进度速率降低,以及客户吵着要产品能像他们想要的那样运行,那么这个降低品质的代价就显而易见了。

 

Ken Schwaber曾经说过,质量是“公司的资产”(2006)。所以,除了行政总裁,没有谁有权牺牲质量来换取一个短期的目标,比如赶上之前设想的发布日期。降低质量的决定有可能是正确的;不过在我不了解整个的情况下,我无法告诉你不这样做会如何。但是,这样的决定要尽可能让组织的高层来做,因为只有有了这样的透明度,才不会有人会对日后看见的那些之前就几乎肯定会产生的负面影响表示吃惊。

 

 

有时候,在组织中选择懂得这些知识的产品负责人很难,因为季度报告总是组织最关心的。打消降低质量的企图是ScrumMaster的工作。ScrumMaster不需要在与其相左的意见刚出来的时候就压制它,但是,他们得让大家注意到做这样的决策会降低质量。

 

 

时间是站在ScrumMaster一边的。如果ScrumMaster能做到让大家注意到某个决定会降低质量,他的反对应该会在最终赢得胜利。“记得吗?在做Gouda项目的时候,我是如何告诉你们降低版本1的质量会损害到版本2的开发?” ScrumMaster说,“这样吧,这是两个项目的比较图,可以看到版本2开发的时候速度明显慢,而我们还多了两个经验丰富的人手。那是因为我们在开发版本1的时候遗留了许多BUG(这儿有个图显示这一点),因为团队在当时觉得没时间来好好清理他们写的代码。在有些模块,他们甚至跳过了自动单元测试。比较发布后六个月内发现的缺陷数目,单元测试和没单元测试的区别还是非常明显的。我们现在这个项目的结果如何就看你们这次怎么做了,我想你们知道我的意见。

我们的产品负责人和团队身处不同的城市

越来越多的项目开发是通过远程的团队进行的,这点越来越普遍。在这种情况下,团队成员和项目负责人都要频繁地沟通,任务繁重。我曾经和许多远程产品负责人共事过,只要如下几点做到了,工作会非常成功:

 

 

l 始终保持对项目的参与

 

l 同团队建立联系

 

l 执行你所任角色的所有惯常任务

 

l 产品负责人保证每天在某些时段能接听团队成员所有的来电,下班之后也要有一段时间能这样做。

 

l 就算当时自己没空,也要写邮件回应或者打电话去。