反向工作

原文网址

文章链结 Working Backwards


这篇文章是 2006 年的文章,这篇文章可以说是亚马逊2002年的“平台化”的实践版本。当时贝佐斯寄出一份内部通告,彻底改变亚马逊公司的组织。这份通告大致包含以下要点:( 参考科技岛读一文 – 亚马逊并购 Whole Foods 的三大优势 )

  1. 所有团队未来流通资料与功能,必须一律需透过服务介面(service interface)
  2. 所有团队之间沟通也必须透过这些介面
  3. 除了这些介面之外,不准有其他流程间的沟通:例如不准贴连结、看彼此的资料库、分享储存或是开后门(back door)等,只准透过介面彼此呼叫资料
  4. 介面用什么技术都可以
  5. 所有介面必须从底层设计为可以“外部化”(externalizable),也就是说介面必须能够开放给外部开发者使用
  6. 谁不照做就开除

从 Working Backwards 这篇文章中更可以证实亚马逊独特的产品开发文化

原文摘要

在亚马逊上使用的细粒度服务方法中,服务不仅代表软体架构,还代表组织结构。 这些服务有一个强大的所有权模式,结合小团队规模是为了使创新变得非常容易。 从某种意义上说,你可以把这些服务看作是一个大公司内部的小公司。 每一项服务都需要强烈关注他们的客户是谁,不管他们是外部人员还是内部人员。 为了确保服务满足客户的需求(而不是更多) ,我们使用一个叫做”反向工作”的流程,在这个流程中,你从你的客户开始,然后向后工作,直到你达到最小的技术要求,以满足你试图达到的目标。 我们的目标是通过一个持续的、明确的客户关注点来实现简单化。

产品定义过程向后推进: 我们首先编写发布时需要的文件(新闻稿和常见问题) ,然后致力于更接近实现的文件。

反向工作产品定义过程的全部内容就是充实这个概念,并对我们最终将要开发的产品进行清晰的思考。 它通常有四个步骤:

  1. 从发布新闻稿开始。
  2. 写一份常见问题的文件
  3. 定义客户体验。
  4. 编写用户手册。

一旦我们经历了建立新闻稿、常见问题、模型和用户手册的过程之后,令人惊讶的是,你计划建立的内容是如此的清晰。 我们将有一套文件,我们可以用来向亚马逊内部的其他团队解释新产品。 我们知道,在这一点上,整个团队对于我们将要开发的产品有着共同的愿景。

心得

亚马逊的开发流程真正落实了 – 以终为始

对 UX 或是产品管理线上课程有兴趣可参考 http://bit.ly/sns-ux

♥欢迎关注 Soft & Share 微博

发表评论

Powered by WordPress.com.

Up ↑

%d 博主赞过: