《谷歌和亚马逊如何做产品》阅读笔记

Posted on | In , | |

Abstract：比较完整地介绍了 PM 工作的流程和经验，算是PM 入门级的书籍。

Main Points：软件交付

  • 亚马逊和谷歌如何交付软件：按照项目流程顺序，包括用户需求研究、用户体验设计、项目管理、测试、发布
  • 团队主管带领团队成功交付所需要的技术积累、最佳实践、技能

Mindnote

Part1 交付卓越产品，步步为“赢”

框定了研究范围和对象，

Chapter1 赢在使命和策略

使命：能够唤起兴趣 + 指明方向 + 适合印在T恤上

策略：在竞争对手的压力下，利用公司独特优势来争取目标用户的粗略计划。

Google Talk：使人与人之间在任何地点均能通过任何终端沟通。

必须想清楚：如何长期为客户提供比竞争对手更优质的产品（长期的竞争优势）。否则，竞争对手会迅速模仿一个跟你一模一样而价格更低的新产品打败你。

Chapter2 产品定义

产品定义

  • 撰写公开稿：使各方了解产品
  • 创建并不断更新FAQ文档：记录争议点和重要细节
  • 绘制流程图和线框图
  • 撰写产品单页或10min演示文稿：写给老板、投资人看的
  • 写API文档
  • PRD
  • 邀请设计和技术来参与产品评审：找出边界情况
  • 找客户测试产品概念
  • 命名、定价和收益

收益模型

  • 1.估算买家总体市场规模
  • 2.预估市场规模的增速：市场规模扩大时，销售规模也随之扩大
  • 3.估算你的目标市场占总体市场的比率
  • 4.估算通过市场推广你能触碰到的用户规模
  • 5.预估触碰触碰的人中有多少会转化成产品用户
  • 6.找到其他新用户增长渠道并加入到模型中
  • 7.将产品定价乘以每个时期的用户数 = 收益；若产品是付费订阅类，还可预估一个续费率然后计算利润

用户体验（UX）：关注用户如何完成任务和如何优化向用户展现信息的方式

  • 信息架构（IA）：研究信息如何在用户界面中呈现，而不关心底层数据结构

视觉设计（Visual Design）：根据既定的信息架构美化界面

用户体验研究（UXR）：研究用户如何看待产品

  • 通过研究获得关于产品成败的统计显著性数据
  • 但不提供解决方案

6个用户体验问题

  • 该用户界面要求用户完成的最重要的任务是什么?
  • 这是最筒单的解决方案吗?
  • 信息是否组织得当?
  • 设计是否易用且一目了然?
  • 标准是否一致?
  • 能否减少用户点击次数?

如何与设计师沟通

  • 1.以用户的口吻说话
  • 2.以提问的方式建立共识
  • 3.反复讲述业务目标，若有些目标相互冲突，则反复江苏它们之间的相对优先级

Chapter4 项目管理

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

  • 包含：任务列表 + 每个任务的工程评估量（即完成所需时间）
  • 将任务按优先级顺序分配

2.跟踪BUG，观察燃尽图，计算实现零bug率的日期

  • 反映bug数量随时间变化情况图，可预测产品何时能够交付
  • 需要为不同严重等级的bug各绘制一条曲线
  • bug修复率：当修复率 < 1 时，即每天修复的bug数量超过发现的bug数量时，才能 确定bug的具体规模并精准预测发布日期

bug燃尽图

3.谨慎管理你的依赖：最小化可能由依赖引发的风险

  • 如果去除它也可以运转，那就去除它
  • 如果内部能构建没救内部 构建
  • 如果必须添加一个依赖，那就趁早添加
  • 如果必须添加一些 依赖，那就依靠它上一个已构建的版本
  • 如果交付的早，被依赖伤害的可能性就小

Chapter5 测试

检查测试用例是否包含以下描述性要素

  • 领域：描述哪部分用户 体验将被测试
  • 严重性：定义若测试失败，你将会将此归为哪个级别的bug，通常1~4级
  • 前置条件：指定测试人员在测试前必须做的事，比如测试购物车中信用卡验证过程，前置条件应该是用户已登录、购物车已添加货品、送货地址已填写，然后测试才能开始
  • 需执行的任务：任务由多个步骤组成，是测试的主要内容。任何步骤失败测试都失败。
  • 后置条件：描述应用程序在任务执行完毕后所处的状态。以上一个例子为例，后置条件可能是用户看到一个包含确认编号的确认页面，同时信用卡会在10秒内扣除相应的金额。

测试用例表格：

测试用例表格

若时间不够宽裕，可每轮测试只执行高严重性的测试用例。

关键评审内容：

  • 1.关键用户体验
  • 2.安全和隐私
  • 3.依赖：一定要严格测试一些非内部构建的数据库、第三方服务和软件

自动化测试：

  • 搭建一套独立于产品代码的测试系统，事半功倍，大大节省人力

推行内部试用：

  • 观点：
    • 欲卖狗食，必先食之
    • 强制性试用
    • 悬赏奖励发现bug的人（T恤之类的奖励很吸引人）
  • 实践操作：
    • 计划一次内部试用发布
    • 使其他使用者能方便地提交bug报告
    • 让内部试用成为团队文化
    • 软件发布后应继续进行内部试用

准确且有条理地处理bug

  • 基于频率、严重性、解决成本对bug分级
  • 每天与开发和测试主管碰一次，评审新增bug
  • 不断施压以减少bug出现

bug评审会议

  • 确定通用的bug评判标准：比如我的大学同学遇到这个bug后我会因此羞愧吗？遇到这个bug后会对它们产生持久伤害吗
  • 先处理最严重的bug
  • 限定会议时长：若会议超出时长则将剩下的安排在明天继续讨论
  • 只围绕频率、严重性、修复成本来讨论
  • 讨论每个bug的世界不要超过一分钟：避免过于细节的讨论，没人喜欢处理bug这件事

发挥可信测试者的作用

  • 可信测试者：产品发布前的试用用户
  • 操作实践：
    • 签署保密协议：主要保证你有权在产品中使用来自客户的改进建议
    • 制作粗略的新手指南文档
    • 创建一个包含整个工程团队的邮件组：让工程团队尽可能接近用户
    • 让用户使用与工程师同版本的试用产品
    • 调研可信测试者：做问卷调研
    • 通知可信测试者产品新版本

以新用户的方式来使用整个产品

Chapter6 量化

一个优秀的量化指标需具备的5个关键特点：

  • 测量成本低廉
  • 测量可靠且可重复检验
  • 能频繁测量，最好能实时测量
  • 团队能根据它做出明智的改变：能够知道在一个量化数据发生变化后知道该做些什么
  • 专注于客户：尽可能选取贴近客户的数据和指标，尽可能测量客户体验的末端（如软件启动量 优于 下载量，因为下载量只反映产品营销做得如何，但启动量反映用户参与度和增长情况）

执行力指标：零bug到达如期（反映开发进度，可实时更新，为团队指明方向）

三类需要跟踪的关键量化指标：

  • 1.目标进度：反映目标的完成进度
    • 比如：7天活跃用户数（有时比日均用户数更合理，因为你很少会做一个预期用户每天使用的产品），30天活跃用户数，利润，注册量，下载量，安装量
  • 2.经营绩效：反映产品问题在哪里以及如何提升用户体验，通常以比率表示
    • 比如：转化率、参与度；7天平均发帖量，7天用户平均停留时间
    • 避免虚荣指标：即总是在增长的指标，因为它们不会帮助你发现产品的问题在哪儿
  • 3.系统性能：性能指标，说明产品的实时健康度
    • 比如：99.9%平均延迟、每秒请求数、并发用户数、每秒下单数、其他基于时间的指标
    • 从统计过程控制（SPC，Statistical Process Control）视角考察性能指标

专注于目标本身，忽略细枝末节

  • 几乎所有的指标都可以通过一些巧妙的手法进行操纵。以之前举过的发布日期这个例子为例，为了将发布日期提前，我们可以将更多Bug归到“不影响发布”这一类去，也可以简单地终止测试(表面上看还是一个“双赢”的做法)。

Chapter7 发布

几个主要的发布步骤确保发布质量：

1.对改动说不

  • “发布手中有的（即使不完美），而非脑中想的”，否则永远完成不了交付
  • 通过核查团队是否对目前的产品抱有自豪感来确定产品是否可以发布
  • 建立一个发布后第一时间（IPL，immediately post-launch）修改的需求清单：认知到有些改动不一定要在发布前完成；这样做可以让团队更有信心，因为他们知道他们顾虑的东西会很快被解决
  • 对改动说不的主要原因：几乎所有对代码的改动 都会引发新的风险，如引入新bug或重新引入老bug（回归bug）
  • 可以维护一套发布分支：则有两个需要并行维护的分支（开发分支+发布分支），打算发布的版本在发布分支上，新特性的开发则在开发分支上进行；当出现安全、隐私或重大性能问题时可以基于发布分支短时间开发一个“热修补补丁”

2.开启作战室

  • 效率，可以每日例会，紧迫气氛
  • 狗屎三明治：当给员工反馈时，可以先表扬他们（第一片面包），再给他们一些难以完成的挑战（狗屎 夹心），最后提醒他们你有多么看好他们的能力（第二片面包）

3.营造紧迫的气氛

4.核查发布清单

  • 发布清单：确保软件发布中所有需要跟进的事项都被有序安排且被详细描述
  • 清单项：领域，事项，负责人，状态，预期完成时间，参考信息

5.撰写博文

  • 阐述你的使命、目标可和和你能解决的问题

6.发布软件

  • 实验性框架：部署实验发布版测试新特性
  • 不要选择在周五或临近假期发布：若要改bug，则会让员工和自己牺牲假期时间

7.亲自验证软件

  • 一轮验证：版本验证测试（BVT，Build Verification Test）
    • 一般在新版本发布后进行
    • 目的：确保推送到生产服务器上的版本是正确的，且所有配置文件都已推送成功并安装正确
  • 二轮验证：以新用户的身份亲自体验整个产品，确保所有功能都能正常使用，有些功能常会出现问题，如注册流程、上传数据、搜索、表单提交 …

8.应对发布后带来的各种影响

  • 应对回滚：
    • 回滚：指把软件撤回到预发布状态
    • 只要成功回滚，没有对用户产生明显伤害，就还没失败
    • 最好的防守是制定周详的撤退计划
    • 若可回滚，则撤回对产品的改动，从容地修复问题，然后再试一次
  • 处理产品危机
    • 比如网站被瞬间大规模的流量冲垮，安全漏洞，隐私侵害，定价事故
    • 建立有效的沟通渠道
    • 不要惊慌 —— 评估影响范围
    • 尝试回滚
    • 推迟任何产品推广计划
    • 知会相关方
    • 知会用户社区
    • 保持BUG的更新
    • 危机收尾：撰写事故调查报告（发生了什么？谁受到了影响？问题是何时出现、何时解决？为什么会发生这个事情？如何防止问题的再次发生？）
  • 演示产品：
    • 必须简洁，不超过 10 min
    • 强调使命
    • 以讲故事的方式
  • 应对媒体
  • 庆祝发布：
    • 感谢整个团队
    • 公开嘉奖要谨慎，防止打击其他团队的信心

危机事故调查报告示例：

危机事故调查报告示例1

危机2

Part2 掌握卓越技能，更胜一筹

Chapter8 胜在团队

雇佣主管

Key：组建一个杰出的团队

优秀的人总是聚集在一起工作。

雇佣PM至关重要：雇佣错误的PM会让整个团队痛不欲生，就像有一把撒了盐的刀每天捅一次工程团队的集体肾脏。这个错误的人选会将产品带向糟糕的方向，会欺上瞒下，会拖延任务，或者虽然完成得很快但质量奇差，还会引发工程团队内部的极大焦虑。不消说，你一定要谨慎地选择，宁可不雇，也不能雇佣错误的PM。

软件业务的四种角色：

  • 1.项目集经理：比PM更少关注业务，比项目经理更少关注项目的技术 角色；key function是黏合和润滑整个团队
  • 2.PM：侧重软件业务；做除了写工程代码之外的任何事
    • MBA出身的PM：专注品牌管理、定价、市场 进入策略等
  • 3.项目经理：排定项目计划和协调团队
  • 4.工程经理

雇佣主管的5个原则：

  • 1.雇佣比你聪明的人
    • 核查简历
    • 绩点
    • 关键加分项：实际推出过很多产品
  • 2.雇佣懂得自己不是来当老板的人
  • 3.雇佣表达清晰、言之有物的人
  • 4.雇佣习惯用数据说话的人
  • 5.雇佣充满活力的人

用数据说话实例：

data

收购公司

收购一家公司的目的：

  • 知识产权：需要计算是自己研发的成本低还是收购别人的成本低，计算出可接受的收购额；必须检查让一个未来不会涉足这个业务 的高级工程师去检查这家公司的代码质量和架构
  • 人才：关键人才，好的雇员，多余人才
  • 客户：客户转移的过程可能会流失
  • 防御（让别人没法买它或让它不再跟自己竞争）

收购建议：

  • 将你的团队的部分人员调入他们团队：商业文化、商业实践的感染；确保新老团队紧密融合；调入最优秀的主管很有利
  • 计划整合产品
  • 了解之前所有的交易和负债

Chapter9 技术

四个S ：服务器（Server），服务（Service），速度（Speed），扩容（scaling）

1.服务器（Server）

服务器（Server）

  • 优秀的工程师会学习如何避免去做运维的琐事，因为任何学到的关于服务器的知识都会在6个月内过时
  • 尽量不要买服务器，采用托管主机更省心

系统的三层架构：

  • 展现层（JavaScript，CSS，HTML）
  • 业务逻辑（Java，C++）
  • 数据（SQL，S3）

2.服务（Service）

API

PRC（Remote Procedure Call）：远程过程调用

SOA（Service-Oriented Achitechture）：面向服务的架构

SOA

3.速度

Key：解决服务链的速度问题

封装（Encapsulation）：将不相关的功能分开封装，则可以并行加载，提高速度

缓存（Caching）：

  • 缓存是数据源的一份副本，比如页面缓存、XML缓存、硬盘缓存，可以缓存任何东西
  • 缓存可从后备存储器中复制数据
  • 缓存缺失：即服务所需的数据不在缓存里
  • 优秀的缓存机制：会通读后备存储器并传回数据，而劣质的不会传回任何数据
  • 缓存更新：当数据存储中的某个值发生 变化，它必须先写入后备存储器，然后后备存储器必须更新所有缓存。在劣质缓存机制中，这会导致缓存的不一致性。

扩容

如何询问正确的技术问题

1.能请你给我画张系统图么？

  • 目的：理解系统图中的所有方框都是干什么的
  • 存放了什么数据 ，干了什么，接收和发送了什么数据

2.结果从这个方框传到那个方框的延迟是多少？

  • 通过系统图识别服务链，询问这类设计的必要性，并 弄清楚整体相应时间是多少和最坏的情况下是多少
  • ​

3.可以扩容到N吗？

4.去掉B方框有什么影响？

  • 了解系统会如何出错并如何恢复
  • 了解系统的哪些部分会产生致命错误，并让工程团队优先考虑对保证这部分的稳定性进行投入

5.能通过缓存什么数据来提升性能？

6.能通过独立加载什么数据来提升性能？

  • 比如独立加载广告系统，则即便广告系统坏了也不影响用户体验

Chapter10 沟通

1.尽可能少开会，但不要不开会

  • 能通过邮件解决的事情就不要开会
  • 如果不能将事物简单地表达出来，你就没有真正理解它

2.写清爽的邮件

  • 用建议取代质疑
  • 主次分明，分点阐述

3.如何组织会议

  • 会后立即发出会议纪要
  • 允许改变开会的目的
  • 不要发泄负面情绪

4.如何做好演示

  • 控制在15min内
  • 永远只传达一个核心信息
  • 讲故事：
    • 创意与生活联系
    • 让观众跟着你的节奏走
    • 例子必须使观众能够理解
    • 描述你要解决的问题和你的解决方案、价值
  • 制作综述单页
  • 重点演示用户体验
  • 极度专注倾听

讲故事实例：

story

5.团队合作沟通

  • 不说你或我，聚焦在产品上
  • 使用客观指标：比如决策矩阵（多项<带权重的>标准打分，然后取总分值最高的选择）

6.合理管理时间精力

  • 分优先级，重要性

十大交付原则

1.你不是来当老板的团队主管是仆人，他们存在的目的就是为了伺候工程团队

2.从用户角度出发。

3.用独特的方法解决很多人都有的大问题。

4.坏的消息就是好的消息。—杰克·韦尔奇

5.先寻求理解，再寻求被理解。——史蒂芬·柯维

6.构建最简洁的可用的产品。

7.交付手中有的，而非脑中想的。

8.无法测量的东西也就无法提升。—开尔文勋爵

9.你不可能做完所有工作，所以你应首先做那些只有你能做的工作。

10.永远走在交付的康庄大道上。

必须的工件

■轮值表—将寻呼器号码和手机号码的清单复制到一张钱包大小的纸上。

■使用Wiki搭建的“联络簿”，用于遇到故障、突发事件或问题时寻找相关负责

人。这个列表应该包括法务、公关、市场、产品团队、工程团队和网络运维(或

者任何负责生产基础设施的部门)的负责人和联系信息。

■描述使命的语句。

■关于未来两年的清晰策略。

页简要说明产品的人物/事件/原因/时间/方法的文档

■产品需求文档，或者叫功能规格说明。

口新闻稿。

■线框原型图或者餐巾纸草图。

■内部FAQ文档，其中部分间答打上外部FAQ标签以作为客户支持内容的原始

素材。

■沟通文档，包括关键信息、有潜在危险的问题和对这些问题的回应

■发布时穿的T恤衫。

■包含测试时间的开发计划表。

■未来两年的路线图。

■内部用户列表和迁移时间表(适用于基础设施项目)。

■可信测试者列表(适用于面向外部的产品)

特性需求列表，并将内部和外部客户中呼声最高的三个特性需求高亮。

■开放问题列表，并清晰标记这些问题的状态。

进行中的会议纪要。最好建一个文档保存项目所有的历史会议纪要。

发布计划或发布规程。

■记录什么特性在什么时间发布的生成变更列表。在排查客户问题时特别有用。

■对增长预测和硬件配置需求提前进行计划的生产设计文档。

■专利注册文件、商标注册文件和版权申明文件

■隐私说明。

■出色的数据指标—包含内部的状态面板和一些供外部消费的清洗过的数据指标。

■为幻灯片、演示、评审、发布准备的产品截图。

口团队本季度目标以及上季度目标完成情况。

■Bug状态面板和阻碍每个发布的Bug列表。

■错误原因报告或事后调查报告。

■会议纪要和团队周会、用户界面评审、产品评审、工程评审、Bug处理、法务

评审、业务拓展周会以及客户支持碰头会的时间计划表。

Thanks!