Revisiting the Product Spec

Revisiting the Product Spec

回顾产品规格

I think the product spec is long overdue for a renovation. Some would argue that Agile methods accomplish this by doing away with the spec altogether. I’ve written about some of the issues and limitations of Agile methods elsewhere, but in many respects I think they were on the right track.

我认为产品规格一直以来缺乏革新。有些人提出说通过完全废除产品规格,采用敏捷方法可以达到这个目的。关于这个观点,我也写过一些东西,并且也指出过敏捷方法的局限性,但是我认为在许多方面敏捷方法还是正确的。

But before we get ahead of ourselves, let’s start by discussing the problem to be solved.

但在超越我们自己之前,咱们先从讨论要解决的问题开始。

There is of course tremendous range among product specs, starting with what we call them (Product Requirements/PRD’s, Market Requirements/MRD’s, Business Requirements/BRD’s, Functional Specs/FSD, and more). The topics covered can vary greatly (these different documents were not intended to serve the same purposes, but over time they have merged and morphed and lost many of their original distinctions), the level of detail, and of course the quality of the spec itself. Even the form varies greatly – many use MS Word docs, but some use spreadsheets, some post the spec on a Wiki site, and others use one of the commercial requirements management tools.

仅仅从它们的名称(产品需求-PRD’s,市场需求――/MRD’s,商业需求-BRD’s,功能规格-FSD,等等)来看,产品规格就有一个极大的范围。各项要涵盖的主题、细节的程度以及说明本身的质量都有很大的不同(这些不同的文档有着不同的目的,但是随着时间的发展,它们被合并、变样,并且失去了它们许多原始的属性)。即使是形式也有着很大的不同-许多人用微软的word的doc格式,而有些人则用电子表格,还有人用wiki站点来发布说明,也有人用商业的需求管理工具。

I have seen a few truly good product specs, but much more often than not, most specs take too long to write, they are seldom read, they don’t provide the necessary detail, address the difficult questions, or contain the critical information they need to, and most importantly, it is all too easy for the mere existence of the spec to serve as a false indicator to management and the product team that everything is proceeding just fine.

我也看到过一些真正好的产品规格,但是大多数却不怎么样,大部分的说明书花了很多时间去写,但是却很少被阅读,它们没有提供必要的细节,确定不同的问题,或者包含需要的关键的信息,更重要的是,以这种形式存在的说明会被认为太容易,以至于会给管理者和产品团队传递一个错误的信号,一切开始就没问题了。

If you agree with me that the central responsibility of the product manager is to make sure that you deliver to the engineering team a product spec that describes a product that will be successful, then we have to acknowledge the weaknesses in the typical spec process and take a hard look at how products are defined.

如果你同意我的观点-产品经理的主要职责就是确信你发布给你的工程师团队的是一份能够描述产品为什么会成功的产品规格,那么我们不得不承认这种典型说明的不足,需要仔细琢磨产品是如何被定义的。

Here are what I consider the requirements for a good and useful product spec:

我认为一个好的,可用的产品规格应该包含:

– the spec must describe the full user experience – not just the product requirements but also the user interaction and visual design. By now hopefully everyone recognizes how closely intertwined the requirements are with the design.

– 说明必须描述完整的UE – 不但包括产品需求,而且也包括用户交互和视觉设计。希望每个人都能意识到需求和设计之间的关系多么密切。

– the spec must accurately represent the behavior of the software – and we need to acknowledge that words and pretty pictures are just too limited in their ability to describe this behavior.

– 说明必须明确地反映出软件的表现 – 我们需要承认文字和精美的图片在描述表现上是非常有限的。

– there are several critical consumers of the spec – engineering, QA, customer service, marketing, site operations, sales; as such, the spec needs to communicate the behavior of the product in a way that all of these groups get what they need.

– 说明有几类确切的客户 – 工程师、QA、客服、营销、网站运营、销售;就其本身而言,说明书需要以这些群体需要的方式来传达产品的表现。

– the spec will change – the rate of change should slow down dramatically once engineering gets started, but there will be decisions and issues that arise, and the spec should change to reflect the very latest decisions.

– 说明会改变 – 当工程已经一旦开始,那么改变的速度就要放慢,但是有决策和问题出现,这个说明就应该改变去反映最新的决策。

– there are a number of artifacts in the creation of a spec, such as lists of prioritized requirements, wireframes, and mock-ups, but there needs to be a single master representation of the spec, to minimize confusion, ambiguity and versionitis.

– 在创建产品规格中会有一定量的artifacts,例如需求优先级列表,线框和实物模型,但需要有一个单独的,规范的说明来表示,从而减少歧义、模棱两可和versionitis。

In my mind, there’s only one form of spec that can deliver on these requirements, and that is the high-fidelity prototype.

按照我的观点,仅有一种说明模式可以实现这个要求,那就是高保真原型。

The term “high-fidelity” refers to the fact that this should be a realistic representation of the proposed user experience. Except for the most trivial of user interfaces, I am not a fan of so-called “paper prototypes.” With the tools available today, it is now so quick, easy and inexpensive to create a high-fidelity prototype for most products that there is no reason not to do so. This is still a prototype, so it’s fine to fake (simulate) the back end processing and data, so long as the user experience is plausible.

高保真指的是能够对UE的一种真实体现。除了最微不足道的UI,我并不是所谓的“纸原型”的拥趸。利用今天可以利用的工具,能够非常快速、容易和廉价地为大多数的产品构建出一个高保真原型,因此,没有理由不这样去做。但这仍然只是一个原型,因此它可以很好的仿真(模仿)后台的过程和数据,只要这个UE是合理的就行。

Over the past few years, my own thinking has evolved here from just prototyping a few critical components of the user experience, to now I advocate prototyping virtually everything – all pages/screens, and all the major use cases. There will still be some error conditions and corner cases that don’t pay to prototype, but the benefits of having a high-fidelity representation of the product that the full product team can interact with to understand the product to be built are so great that they dwarf the incremental costs.

在过去的几年,我的想法也在逐渐发展,从仅仅是原型设计出UE的一些关键组件,到现在我几乎提倡原型设计一切 – 所有的页面/屏幕,和所有的主要用户用例。但仍然有一些误差和个例无法由原型完成,但是拥有一个可以让所有产品团队充分了解所构建的产品的高保真原型所带来的利益是如此的大,相对于增加的成本就微不足道了。

It is true that you will still need to supplement the prototype, as there are aspects of the proposed product’s behavior that are not easily represented in a prototype, such as the release requirements (e.g. reliability, performance, scalability) or platform delivery requirements (such as installation requirements, or the list of browser versions to be supported). Also useful as a supplement are use cases, describing the most important flows through the product.

事实上,你仍然需要补充这个原型,因为计划中的产品表现有许多方面是不太容易以原型的形式表现出来的,例如发布需求(如可靠性、性能、可扩展性)或者平台交付需求(如安装需求、或者能够支持的浏览器版本列表)。另外,把它作为一个用户用例也是有用的,通过产品描述最重要的流程。

There is still the question of how to best represent this supplementary material. What I really want is to annotate the prototype, but until that technology is readily available, I prefer using a Wiki or other form of Intranet site. The biggest reason is that everyone on the product team knows where to find the latest answers at any time, rather than having various random versions of documents floating around. It is also easy to post Q&A’s, set up automatic e-mail notifications whenever the spec is updated, and track the history of decisions.

还有一个问题就是如何更好地描述这个补充的事物。我现在想到的是对原型进行注解,但是那得等到这个技术能够易于使用,我现在只是用WIKI或者内部网的形式。最大的原因是产品团队中的每个人,在任何时候都知道在哪儿找到最新的回答,而不是到处泛滥的随意的各种各样文档的版本。这也很容易去发布Q&A,设置自动邮件提示,当说明有更新的时候,就能够追踪到决策的历史。

But the majority of the product spec should be the high-fidelity prototype, representing the functional requirements, the information architecture, the interaction design, and the visual design of the user experience.

但是产品规格的大多数应该是高保真原型,表现功能需求、信息构建、交互设计和UE的视觉设计。

In addition to meeting the requirements described above, the most important benefit in my view is that unlike a paper document, a high-fidelity prototype can be tested. You can put it in front of actual target users and ensure that they can figure out how to use your product (usability), and also determine if they care to use your product (desirability). You don’t actually have a spec worth handing over to engineering until your prototype passes these two tests. Doing this form of testing while you are in QA or Beta is far too late in the process.

除了满足上面提到的需求描述外,我认为最重要的利益就是高保真原型不像纸的文档那样不可被测试。你可以把它呈现在现实的目标用户面前,确保他们能够大致理解如何使用你的产品(可用性),也能够判断出他们是否喜欢用你的产品(渴望度)。直到你的原型经过这两项测试才值得交给你的工程师们。但是,如果你已经进入QA或者beta测试时,再去做这些测试就为时已晚了。

I can promise you that if you give this a try, and create a high-fidelity prototype of the proposed functionality and user experience, then your product team will absolutely love this. Engineers are the immediate winners as they finally get a spec that effectively and unambiguously describes the product they need to build, and that they can refer to at any time when they’re confused about how something is supposed to behave. The job of QA is similarly easier as they now know what should happen when they test the actual product. Marketing, sales, and customer support will love being able to learn the product much earlier in the cycle. You’ll also find that your execs will love it too as they can describe what you’re doing (and demo the prototype) to investors, board members, and partners much more effectively than any PowerPoint deck can do.

如果你期望一试,创建一个计划中的功能和UE的高保真原型,那么我敢保证你的产品团队绝对会喜欢的。工程师们是最直接的受益者,因为他们最后得到的是一个有效并且清晰地用来描述他们要开发的产品的说明,当他们对期望的产品表现迷惑的时候,他们能够以此作为参考。QA的工作也是这样容易,因为他们知道现在测试的这个真实的产品发生了什么。营销、销售和客户支持也能够很容易地在这个周期里更容易地知道产品。你会发现你的执行层也会喜欢它,因为它们能够向你的投资人、董事会成员和合作伙伴描述你将要做什么(演示这个原型),这要比任何PPT都将有效。

But wait, there’s more.

但是等等,还有一些。

The biggest surprise for most teams is that creating a spec this way will typically significantly reduce time to market. Yep. I realize this may sound counter-intuitive, but to understand why the total time to market is faster, you have to look a little deeper at what almost always happens in a software project. Because the typical spec is so poor (incomplete, ambiguous, and especially untested), and so few of the hard questions and critical details are actually addressed and resolved, it is during the engineering phase that the team is forced to tackle these issues, and either there is tremendous churn (the specs keep changing resulting in delays and frustration in engineering) or the engineers just make assumptions as best they can, and the product that ships is a mess and one or more update releases are required before you actually get something useful to your customers.  In either case, the time to market is longer than it should be.

对于大部分的团队来说,最大的惊喜就是创建了一个说明,而这个说明大大缩短了进入市场的时间。是的。我知道这听起来是不可理解的,但是要知道进入市场的总时间为什么会快一些,你必须对在一个软件项目里会发生什么看的更深一些。因为典型的说明是乏味的(不完全、不清晰、尤其是它是未验证的),因此,那些尖锐的问题和重要的细节很少被明确标注和解决,在整个研发阶段,研发团队被迫去应对这些事务,或是一种极大的不安(说明一直在变,导致研发延期和有了挫折感)或者工程师们只能假设他们能够做好,这个交付的产品却是一团糟,在你实际向你的客户交付一些东西之前不得不一次次改变发布时间。无论出现那种情况,上市的时间都要比原计划的要长。

So I truly hope on your next product you’ll try this out. Rather than spend weeks working on a 50-page Word document that few will read and is impossible to test, work with your designer to create a prototype of the product you are proposing. Then show that prototype to target users, as well as your product team. You’ll end up iterating several times (better now than after engineering spends months building a bad product!), but when you get the recipe right, use that prototype as the basis for the spec you deliver to engineering and see what happens.

因此,我真的希望你在你的下一个产品中尝试一下。与其花数周的时间做一份50页的几乎不被阅读和不可能测试的word文档,还不如和你的设计人员一起构建一个你所要做的产品的原型出来。然后把这个原型展示给你的目标用户,就像给你的产品团队看一样。你最后会调整几次(这要比工程师们花几个月时间做一个糟糕的产品好的多),但是当你得到这个正确的秘诀,用原型作为你要交给工程师的产品规格的基础,看看会发生什么吧。

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

0 条评论

发表我的观点

取消

  • 昵称 *
  • 邮箱 *
  • 网址