《谷歌(谷歌(Google))和亚马逊(亚马逊(A

本书讲了什么

在软件行业中,我们把设计、打造、发布一款符合市场需求的软件称为交付(shipping)。一旦走上了软件交付之路,你将面临产品、方案、项目和工程管理各方面的挑战。本书讲的就是作者在谷歌和亚马逊的交付经验之谈。

《Shipping Greatness》

Ahthor: Chris Vander Mey

Pratical lessons on building and launching outstanding soft ware learned on the job at Google and Amazon

读者锅巴GG备注:由于原书结构过于合理,实在像是自己的读书笔记提纲,顾不再赘述,改为大段式总结结构

这是一本非常过瘾的书,它揭秘了卓越的产品是如何被“交付”的。
简单概括了七个特别值得关注的阶段,供团队按图索翼:
* 阶段一,确定正确的产品方向
* 阶段二,  尽可能清晰仔细的定义产品
* 阶段三, 设计用户体验
* 阶段四, 做基础的项目管理工作
* 阶段五, 开始测试
* 阶段六, 准备发布
* 阶段七, 正式发布
总结来说,其实是在此框架之上,致力于缩小项目范围、简化用户体验,提升推进速度。

明确你的产品使命

1.能够唤起人们的兴趣;

2.提供言之有物且能指明方向的原则;

3.适合印在T恤上;

第3章 赢在用户体验

3.1 了解各类设计角色:用户体验,用户界面,信息架构,视觉设计,用户体验研究......以及角色模型

用户体验UX

关注用户如何完成任务以及该如何优化向用户展现信息的方式

信息架构IA

专注于用户怎样才能接收到信息

用户界面UI

关注单个页面或品目的设计

视觉设计VisD

关于如何通过一种既赏心悦目、夺人眼球又清晰明了的方式来展示内容的一门学问

用户体验研究UXR

研究用户是如何看待你的产品的

角色模型Persona

3.2 了解如何评估设计

3.2.1 该用户界面要求用户完成的最重要的任务是什么?

三个问题

谁是最重要的用户?

这类用户必须完成的最重要的任务是什么?

这个任务在用户界面中是最重要且最简洁的部分吗?

3.2.2 这是最简单的解决方案吗?

要求越多,用户完成的能力和意愿就越低

《简单法则》

简化

隐藏

附加

3.2.3 信息是否组织得当?

最重要的客户类型最关注的信息应该最突出

信息的排列方式应该像报纸文章那样从标题到摘要一一排列

信息应该尽可能个性化且实时,也应该在合理的前提下尽可能详细

最常用的控件出现在最容易找到的地方

3.2.4 设计是否易用并且一目了然

1、定位

西方文化信息优先级

从左上角向右下角递减

2、视觉设计

3、惯例

3.2.5 标准是否一致

3.2.6 能否减少用户点击次数

3.3 了解如何与设计师沟通

1、以用户的口吻说话

2、以提问的方式建立共识

3、反复讲述业务目标,如果有些目标相互冲突,则反复讲述它们之间的相对优先级

4、用数据说话

5、提供一些竞争对手或类似体验中运作良好的案例

3.4 学会如何借助图画进行沟通

制作线框图的基本原则

只制作用户界面中相关部分的原型

总是使用完整的、经过适当编辑的文本

控制花在视觉设计上的时间

使用灰度色,不要使用其他颜色

预期你的线框图会发生很大改动

当心视觉花招

作者什么来头

Chris Vander Mey,Facebook产品经理,曾任谷歌高级产品经理、亚马逊技术产品开发经理和工程经理,他交付的软件正在被亿万人所使用。Chris曾多次带队在消费者或企业领域开发软件,其中包括亚马逊的实名制系统,也包括Google Maps。

Part One 交付卓越产品,步步为“赢”

  • 赢在“使命和策略”——寻找到正确的需求之后才有可能构建卓越的使命,策略映射了来自于市场压力之下,如何利用好公司的优势来争取目标用户的粗略计划,它是逐渐改进的,用来始终不偏不倚的聚焦在如何让自己的产品保持对目标用户更有吸引力的描述,阐明了客户、公司和竞争。如果满足你的需求目标并能获得公司内的支持,就应该可以开始讨论产品细节了。

  • 赢在“产品定义”——《精益创业》告诉我们,最小化可行产品的构建,并进行不断的定量反馈收集和分析,快速重复这个过程来定位客户的问题,并吸收成为功能特性,不臆想、不猜测,增加成功的可能性。

产品定义的十个过程:

  1. 撰写新闻稿
  2. 创建并不断更新FAQ文档
  3. 绘制线框图或流程图
  4. 撰写产品单页或十分钟的演示文稿
  5. 在FAQ文档中添加API文档
  6. 撰写功能规格文档
  7. 邀请设计团队和工程团队主管参与产品评审
  8. 找客户测试产品概念
  9. 命名、定价以及预测收益
    10.向管理层汇报

  • 赢在用户体验——用户体验不仅是产品的外观样式,它还是产品的使用方式。
  • 了解各类设计角色
    • 用户体验(UX/UE)关注的是用户如何完成任务以及如何优化用户展现信息的方式。
    • 用户体验设计师对信息架构尤为关注,不关心数据结构,只研究信息在界面中的呈现。
  • 用户界面(UI)是用户体验的旧称,它更关注单个页面或屏幕的设计、是用户体验的组成部分。
  • 视觉设计(VD)是关于如果通过一种既赏心悦目,夺人眼球又清晰明了的方式展示内容的学问。
  • 用户体验研究(UXR)是用户体验的一个特殊组成部分,它专注于研究用户是如何看待你的产品的。
角色模型(Persona)方法提供了设计团队、工程团队的评估设计框架。
  • 了解如何评估设计

    • 六个用户体验问题
      1. 该用户界面要求用户完成的最重要的任务是什么?
      2. 这是最简单的解决方案吗?
      3. 信息是否组织得当?
      4. 设计是否易用且一目了然?
      5. 标准是否一致?
      6. 能否减少用户点击次数?
  • 了解如何与设计师沟通

    1. 以用户的口吻说话
    2. 以提问的方式建立共识
    3. 反复讲述业务目标,如果有些目标互相冲突,则反复讲述他们之间的相对优先级
    4. 用数据说话
    5. 提供一些竞争对手或类似体验中运作良好的案例
  • 了解如何借助图画进行沟通——技能面

  • 赢在“项目管理”
  • 三项低成本的工作:

    1. 创建一张简单的计划表并持续维护
    • 如何拿到评估量?
      • 如果你不是工程经理,让工程经理去要评估量
      • 表面上接受评估结果
      • 认识到你的权力
      • 只跟踪剩余时间
      • 要求不考虑余量的评估
      • 每周一次在团队会议上评估各任务的剩余时间
    1. 跟踪Bug,观察燃尽图,计算实现零Bug率(ZBB)的日期
    2. 谨慎管理依赖
    • 如果去除它可以运转,那就去除它
    • 如果内部能构建,那就内部构建
    • 如果必须添加一个依赖,那就趁早添加
    • 如果必须添加一些依赖,那就依靠它的上一个已经构建的版本
    • 如果交付得早,被依赖伤害的可能性就小
  • 赢在“测试”
  • 遵循八个主要步骤
    1. 坚持测试驱动开发
    2. 围绕优秀的测试主管组建测试团队
    3. 亲自评审测试计划和测试用例
    4. 自动化测试
    5. 虔诚地推行内部试用(Dogfood)
    6. 开展找虫总动员
    7. 勤勉且有条例地处理Bug
    8. 任命可信测试者以构建最后一道防线
  • 赢在“量化”
  • 如何采集正确的量化数据且只采集正确的量化数据
    • 优秀的量化指标的五个关键特性
      1. 测量成本低廉
      2. 测量可靠且可重复检验
      3. 能频繁地测量,最好能实时测量
      4. 团队能够根据它做出明智的改变
      5. 专注于客户
  • 需要采集的三类量化数据
    • 目标进度
    • 经营绩效
    • 系统性能
  • 专注于目标本身,忽略细枝末节
  • 赢在发布——万事俱备,只欠发布
  • 确保发布质量的主要步骤
    1. 对改动说不
    2. 开启作战室
    3. 营造紧迫的气氛
    4. 核查发布清单
    5. 撰写博文
    6. 发布软件
    7. 亲自验证软件
    8. 应对发布带来的各种影响
建议,开始应该准备足够的剧本,应对各种情况,如:回退

产品定义

第4章 赢在项目管理

4.1 创建一张简单地计划表并持续维护

4.2 如何拿到评估量

1、如果你不是工程精力,那么让你的工程经理去要评估量

2、表面上接受评估结果

3、认识到你的权力

4、只跟踪剩余时间

5、要求不考虑余量的评估

6、每周一次在团队会议上评估各任务的剩余时间

4.3 跟踪BUG并创建BUG燃尽图

4.4 管理依赖

1、如果去除它也可以运转,那就去除它

2、如果内部能构建,那就内部构建

3、如果必须添加一个依赖,那就趁早添加

4、如果必须添加一些依赖,那就依靠它上一个已构建的版本

5、如果交付得早,被依赖伤害的可能性就小

第一部分 交付卓越产品,步步为“赢”

Part Two 掌握卓越技能,更胜一筹

  • 可以始终效率更高?
  • 可以沟通更清晰?
  • 可以更好的调节工作压力?
  • 工程团队更壮大?
  • 影响力更强?
  • 系统设计理解更深入?

目标:

  • 更精准的技术沟通,跨多个领域的深厚学识以及无畏的勇气

  • 提升效能和幸福感,推动交付

  • 胜在团队
    这个话题有点大,重点是如何找到并协调项目经理、产品经理、工程经理、设计主管等。

  • 胜在技术
    重点要了解基础的四个知识,4S:Server,Service,Speed和Scaling

  • 胜在沟通

    • 如何写好邮件
      基本原则:把重要的事情放在文章开头
  • 如何应对五种类型的会议

    1. 团队会议
    2. 站会
    3. 1对1
    4. 产品/工程/用户体验评审
    5. 头脑风暴
  • 胜在决策
    产品的骨架取决于团队的决策——你用它来做什么,怎么做?

  • 胜在从容

    • 如何平衡交付、质量和影响、团队三者关系
    • 如何应对随机情况
    • 在交付过程中如何管理精力
    • 如何把向上求援当成工具而非托词
    • 如何咽下狗屎三明治并生存下去
  • 再度启航
    能交付的软件就是最好的软件——完成后会发生什么?
    软件重来没有做完一说。
    反思

十大交付原则

1. 你不是来当老板的——团队主管是仆人,存在的目的就是伺候工程团队
2. 从用户角度出发
3. 用独特的方法解决很多人都有的大问题
4. 坏的消息就是好的消息(知道问题比不知道好)
5. 先寻求理解,再寻求被理解
6. 构建最简明可用的产品
7. 交付手中有的,而非脑中想的
8. 无法测量的东西也就无法提升
9. 不可能做完所有的工作,应该先做那些只有你能做的工作
10. 永远走在交付的康庄大道上

参考资料涉及方面

  • 产品定义
    《精益创业:新创企业的成长思维》
  • 驾驭管理
    《执行:如何完成任务的学问》
    《卓有成效的管理者》
    《谈判力》
    《学会改变》
  • 工程管理
    《人件》
  • 用户体验
    《写给大家看的设计书》
  • 指标
    《目标:简单而有效的常识管理》
  • 沟通
    《六顶思考帽》

想加入更多乐读创业社的活动,请访问网站→ http://ledu.club
或关注微信公众号选取:

ledu.jpg

1.撰写新闻稿;

a.产品命名;

b.发布时间;

c.目标客户;

d.解决了什么问题;

e.如何解决(务必简明扼要)

f.CEO的公开致辞

第5章 赢在测试

影响产品质量的8个步骤

5.1 坚持测试驱动开发

5.2 围绕优秀的测试主管组建测试团队

5.3 亲自评审测试计划和测试用例

测试用例包括

1、领域(模块)

2、严重性(优先级)

3、前置条件

4、需要执行的任务

5、后置条件

测试用例主要三块内容

1、用户体验

2、安全和隐私

3、依赖

5.4 自动化测试

自动化测试程序

5.5 推行内部试用

欲卖狗食,必先尝之

内部试用流程

1、计划一次内部试用发布会

2、使其他试用者能够方便地提交Bug报告

3、软件发布后应继续进行内部试用

4、让内部试用成为企业核心价值观

5.6 如何开展找虫总动员

“坏的消息就是好的消息“

5.7 准确且有条理地处理Bug

1、基于频率、严重性和解决成本对Bug进行分级

1)频率

2)严重性

3)修复成本

2、每天与开发主管和测试主管碰一次,评审新增的Bug

1)确定通用的Bug评判标准

2)先处理最严重的Bug

3)限定会议时长

4)只围绕频率、严重性和修复成本来讨论

5)讨论每个Bug的时间不要超过一分钟

3、不断施加压力以减少新的阻碍发布Bug出现

5.8 发挥可信测试者的作用

最佳实践

1.让企业用户签署保密协议并提供正确的联系方式

2.制作粗略的新手指导文档,其中包括已知问题的列表

3.创建一个包含整个工程团队的邮件组

4.让这些用户使用和工程师同样版本的试用产品

5.调研可信测试者

6.当产品更新时通知可信测试者们

5.9 思想火花:以新用户的方式来使用整个产品

有效交付过程的7个阶段

阶段一,确定正确的产品方向。好的产品一定要满足众多客户所共有的某个真实的需求。你的使命就是找到一种独特而有意义的方法去满足这一需求。

阶段二,尽可能清晰详细地定义产品。这个过程需要10个主要步骤,包括撰写新闻稿、创建并不断更新FAQ文档、撰写功能需求文档等。

阶段三,设计用户体验。你需要从用户的角度出发,和设计团队不断沟通、反复迭代,最终构建出良好、直观、简洁的用户体验。

阶段四,做一些基础的项目管理工作。项目管理工作包括跟踪交付物的进展、指出问题以及控制项目范围。

阶段五,开始测试。你需要主导bug的处理并慎重决定哪些可以容忍出现在版本1而哪些又必须在发布之前修复掉。

阶段六,准备发布。不过在发布之前要清楚知道怎样才算成功,这就要求你建立一套衡量产品成败的指标。让团队利用剩余工时来把这些指标纳入监控并搭建产品状态面板。

最后,正式发布产品。发布一款卓越的产品可不只是上传一些文件到服务器上那么简单,你需要制订市场营销和公关方案,并在发布前仔细核查清单中的每一项内容。

2.创建并不断更新FAQ文档

第1章赢在使命和策略

3.绘制线框图或流程图

如何找到正确的需求

团队应该始终积极地去解决客户的问题,而不是紧盯竞争对手,被动地做出反应。我们学到必须专注于解决真正的客户问题。当把一个问题不断放大时,你覆盖的客户会不断增多,而问题的解决也会使更多人受益,这意味着你的潜在收益会更大,财富、名望、成功也就随之而来了。

4.撰写产品单页或10分钟的演示文稿;

a.产品名称

b.目标客户 数量有多少

c.解决了什么问题 这个问题对于目标客户来说有多大价值

d.解决方案 这个解决方案类似线上有什么产品,为什么你的方案让竞争对手在长期内无法模仿

e.合适发布 主要的里程碑有哪些

f.团队背景(仅针对VC)

如何构建卓越的使命

卓越的使命需要完全符合以下三点要求:

能够唤起人们的兴趣。

提供言之有物且能指明方向的原则。

适合印在T恤上。

最后一个衷告:你需要的是一个能够反映代表性产品或服务的使命,而不是一个面面俱到的使命。

5.在FAQ中添加API文档

1.简介(使命和策略);

2.目标与非目标;(版本/功能 迭代)

p0 没有该功能无法展示

p1 没有该功能无法交付产品

p2 锦上添花的功能

3.用例或用户场景;(将用例转化为用户场景)

4.原型图或线框图;

5.API;

6.负载规划;

7.依赖;

8.FAQ和开放问题;

9.关键事件;

如何制订正确的策略

策略是指在竞争对手的压力下,利用公司独特的优势来争取目标用户的粗略计划。它只是一段用于说明对目标客户来说你的产品将如何长期保持比竞争对手更强的吸引力的话。简而言之,你需要阐明三件事:客户、公司和竞争。

当你开始思考公司、客户和竞争这三大问题时,需特别注意如何才能长期为客户提供比竞争对手更优质的产品。你需要深思远虑,因为要想取得商业上的成功就必须保持长期的竞争优势,否则竞争对手就会迅速模仿并推出一个和你的产品功能一样、价格却更低廉的新品牌来将你一举击溃。

6.撰写功能规范文档(PRD)

第2章赢在产品定义

7.邀请设计团队和工程师团队主管参与产品评审

产品定义过程主要分为10步:

8.找客户测试产品概念 (焦点小组)

第1步:撰写新闻稿

所谓新闻稿是指一篇向市场宣布将要推出新产品的通告,应该简单明了地传达关于产品的关键信息。新闻稿的媒体属性注定了它天生就更简洁、可读性更强且更关注真实的产品能给真实的用户带来什么价值。好的新闻稿包含六大要素:产品命名、发布时间、目标客户、解决了什么问题、如何解决、CEO的公开赞辞。

9.命名、定价以及预测收益

第2步:创建并不断更新FAQ文档

随着产品方案的不断细化,各种问题也层出不穷,我会迅速把这些问题记到一个内部FAQ文档中并尽我所能回答提问者。创建并维护FAQ文档有两大好处。第一,它能节省你大量回复邮件的时间,还能抵御一些内部责难。第二,当你的客户支持团队和科技写作团队开始整理所有面向公众的内容时,FAQ将是一个很有价值的资源

10.向管理层汇报

第3步:绘制线框图和流程图

在FAQ中撰写问题答案时,你会发现其中一些答案用流程图或线框图来表述会更好一些,尤其是涉及用户体验(UX)的细节时。流程图可以帮助你准确地解释用户工作流和系统交互相关问题,简要线框图则可以帮助你具象化产品各环节的用户体验。

用户体验

第4步:撰写产品单页和制作10分钟的演示文稿

这两份文档所需包含的五个要素:

产品名称。

目标客户数量有多少。

解决了什么问题。

这个问题对于目标客户来说有多大价值。

解决方案。

何时交付。主要的里程碑有哪些?

团队背景(仅针对VC)。

1.了解各类角色

UX:  用户如何完成任务,如何优化向用户展现信息的方式;

IA: 页面上最重要的信息是什么,用户怎么样才能接收信息;

VD: 可视化展示内容

UXR:研究用户如何看待你的产品

第5步:在FAQ中增加API文档

API文档可以说明你的团队如何与其他团队协作、外部开发者如何使用这套系统以及你需要存储什么数据。预先定义清楚API还有个好处,它可以帮助你搭建由这些API构成的面向服务的体系架构(SOA)。因此预先撰写API文档对每个人都有很大帮助。

2.各类角色的职责:

UX: 1.把握多个目标之间的平衡,清洗传达给设计团队;

2.清洗阐述业务目标,以及优先级;

3.知道最重要客户是谁?最重要任务是什么?

IA: 1.用户最关注的信息最应该突出;

2.信息排列方式应该向报纸那样清晰;

3.信息个性化且实时;

4.最常用的空间出现在最容易找到的地方;

VD:1.定位;

2.视觉设计;

3.惯例:不违背设计语言;

UXR:1.标准是否一致;

2.能否减少用户点击次数

第6步:撰写功能规格文档

它是用来详细描述用户应该如何体验产品的文档。它不包含系统在后台如何运行之类的技术细节,这类细节应该包含在工程主管撰写的技术规格或设计文档中。功能规格文档包含以下九个内容块:

简介。它说明了为什么要做这个产品以及做些什么,每个新进入项目的成员都可以从中了解到必要的背景信息。

目标与非目标。你需要将产品方向细化成不同目标,每个目标都应保持清晰简洁并将它们按优先级排列。

用例或用户场景。用例是指用简要的语句来描述那些用户必须执行的操作,用户场景则是指用叙述故事的方式来描述用户是如何体验产品的。

原型图或线框图。将这些图粘贴到功能说明中,它们是用户场景的重要补充。

API。如果你还没写API文档,那就现在写,不过前提是已征得工程团队的同意。

负载规划。负载规划是指对未来一段时间内用户的使用量进行粗略估计并制订应对计划。

依赖。你需要将全部依赖方及其负责人列出来,如果有应急方案也一并列出来。

FAQ和开放问题。你可以直接将FAQ和开放问题的链接地址放入功能文档中,也可以把内容复制过来。

关键事件。你最好能列出主要事件的达成时间,如特性完成时间、可信测试者版发布时间。

3.如何与设计师沟通:

1.以用户的口吻说话;

2.以提问的方式建立共识;

3.反复讲述业务目标,如有目标相互冲突,阐述优先级;

4.用数据说话;

5.提供竞争对手/体验良好的案例;

第7步:找出边界情况并得到团队认可

你的团队将开始寻找边界情况或者极端情况,即极少出现的产品行为或场景。不要抱怨这个看似繁琐的事情,如果不找出所有边界和极端情况,你就无法采取应对措施。

项目管理

第8步:客户测试

去找一批现存的或潜在的客户,向他们介绍你的产品设想和原型,并听听他们的反馈。这个测试可以避免你做出一个没人想用的产品或者遗漏一些核心功能。

1.创建一张简单的计划表持续维护

只需要包含任务列表和每个任务的工程量评估

·剩余开发人/日,编码测试时间,发布时间

·任务分配

·任务分解

本文由糖果派对电玩城发布于最新报道,转载请注明出处:《谷歌(谷歌(Google))和亚马逊(亚马逊(A

您可能还会对下面的文章感兴趣: