产品经理的42个原则-原则27-hort, Standardized Cycle Times Drive Predictabilit:短的,标准周期时间驱动预测!

I’ve found predictability to be more important than high productivity

我发现预测性比高生产力更重要

Every product manager wants to be the bearer of good news, sharing details of on-time product releases packed with high value features. Too often, however, product managers bear news of yet another late release or the feature that had to be scoped out. When customers, partners, and internal constituents lose confidence in a development organization’s ability to consistently deliver promised functionality, the inevitable outcome is micromanagement and second-guessing of the product organization. With over a decade of product management experience, using both waterfall and agile methodologies, I’ve found predictability to be more important than high productivity. Knowing that what gets prioritized and accepted into a development cycle gets released into production on time, every time.

每个产品经理都想成为好消息的传播者,这个好消息就是分享准时发布的高价值产品特征的细节。然而,产品经理经常要忍受看到另一个推迟的版本或不得不限定范围的特征延迟的消息。当客户、合作伙伴和内部成员对开发组织持续交付所承诺的功能的能力失去信心时,不可避免的结果就是对产品组织进行微观管理和事后批评。我有超过十年的产品管理经验,使用过瀑布模式和敏捷方法,我发现可预测性比高生产力更重要。知道什么会推动在开发周期中被优先考虑和接受的内容每次都按时发布到成品中。

Predictability means dependent organizations.

可预测性意味着依赖组织。

Internal and external—can plan with confidence (and without feeling the need to backseat drive the product organization). Business executives will choose slightly less functionality in exchange for higher predictability almost every time. Like many product development organizations, my current organization struggled in the past with releasing the committed scope of functionality on schedule. Over the past few years, however, we’ve released on time and in-scope 90+ percent of the time.

内部和外部——可以有信心地进行计划(而且不会让产品组织处于次要地位)。企业高管几乎每次都会选择较少的功能,以换取更高的可预测性。与许多产品开发组织一样,我目前的组织过去一直在努力于按期发布交付范围内的功能。然而,在过去的几年里,我们90%以上的时间都是按时发布的。

How did we calculate the 90 percent success metric?

我们如何计算90%的成功度?

We looked back at actual release dates vs. planned release dates, and also looked at cases where a feature accepted into a sprint (using Scrum as our development approach) wasn’t production ready. Exceptions existed in less than 10 percent of cases—a dramatic improvement from our level of predictability when we were following three to six month waterfall development cycles.

我们回顾了实际的发布日期和计划的发布日期,并研究了在sprint中已确定的特征(我们使用Scrum作为开发方法),而这些特征没有做好生产准备的情况。例外情况只存在于不到10%的情况中——这与我们跟踪3到6个月的瀑布开发周期时的可预测性相比有了显著的提高。

The switch to agile development (Scrum specifically) was a major factor in achieving this high level of predictability. Under the hood of Scrum, however, it has been our refinement of development cycle times that has had the most impact. We started with very tight cycles—two weeks—but found we were consistently late. We bumped up to three weeks per sprint but still found it difficult to achieve predictability. Development cycles that are too short don’t leave sufficient time for QA and refinement. We ultimately settled on a standardized four-week cycle, with one week in between sprints for planning, enabling nine to ten major releases per calendar year. (Note that four-week cycles are working weeks, not calendar weeks, allowing holidays to be taken into account on a sprint-by-sprint basis.)

转向敏捷开发(特别是Scrum)是实现这种高可预测性的一个主要因素。然而,在Scrum的基础上,我们对开发周期时间的改进影响最大。我们开始于紧张的周期——两周——但发现我们总是会晚。于是,我们把每一次sprint的时间增加到三周,但仍然发现很难实现可预测性。太短的开发周期没有为QA和细化留出足够的时间。我们最终确定了一个标准化的周期-四周,在计划sprint上有一个星期,这样能够每日历年发布9到10个主要版本。(请注意,4周的周期是工作周,而不是日历周,允许在每次sprint的基础上考虑到假期。) 

One Week and Four Week Sprint Why did a standardized, four-week sprint cycle have such an impact?

为什么一个标准化的、为期四周的sprint周期会产生如此大的影响?

Both “standardized” and “four week” are important. By standardizing on a cycle, our product management, engineering, and QA teams have found a rhythm—a natural feel for what can be accomplished in a four-week cycle. Four weeks has proven effective because it is long enough for significant progress on features, but short enough to be estimated accurately. Four weeks is also short enough from a business perspective that the risk of mid-sprint executive overrides (changes in priorities) is minimized. We’ve been able to avoid this problem altogether. The most significant challenge with three to six month waterfall cycles is estimating the work—like many companies, we simply couldn’t achieve sufficient accuracy in estimation over such a long cycle, resulting in low predictability.

“标准化”和“四周”都很重要。通过对一个周期进行标准化,我们的产品管理、工程师和QA团队找到了一种节奏——一种在四周周期内可以完成的事情的自然感觉。四个星期已经被证明是有效的,因为它足够长,可以在特征上取得重大进展,同时又足够短,可以准确估计。从商业角度来看,4周的时间也足够短,可以将sprint中段执行重写(更改优先级)的风险降至最低。我们已经完全避免了这个问题。而在3到6个月的瀑布周期中,最重要的挑战是评估工作——就像许多公司一样,在如此长的周期中,我们无法获得足够的评估准确性,导致了低可预测性。

I noted above that predictability is more important than high productivity.

我在上面提到过,可预测性比高生产力更重要。

The hidden gem here is that predictability, in our experience, drives higher productivity because as the product teams deliver consistently, confidence in the ability to delivery grows—and the teams are prepared to take on more each sprint cycle. By focusing first on predictability we have ultimately achieved higher productivity.

这里隐藏的精华是,在我们的经验中,可预测性驱动更高的生产力,因为随着产品团队的持续交付,对交付能力的信心会增长,以及团队准备在每个sprint周期中会承担更多。通过首先关注可预测性,我们最终实现了更高的生产率。

What product manager would argue with that outcome?

产品经理会对这个结果提出异议吗?



分享到QQ 分享到微信 分享到微博

0 条评论

发表我的观点

取消

  • 昵称 *
  • 邮箱 *
  • 网址