所有的流程和规范最终都是为了解决实际问题的，不要贸然引入流程，除非已经碰到问题，否则尽量简化流程，提高效率。
要交付一个产品，其中最重要的只有3点：
- 确认用户需求和预期指标
- 以最小成本实现最主要的需求
- 发布并获得数据反馈，确定下一个迭代目标
在软件行业中，我们把设计、打造、发布一款符合市场需求的软件称为交付（shipping）
交付卓越产品，步步为“赢”
有效的交付过程，它分为7个阶段：
- 阶段一：确定正确的产品方向
- 阶段二：尽可能清晰详细地定义产品
- 阶段三：设计用户体验
- 阶段四：做一些基础的项目管理工作，不要太多也不要太少
- 阶段五：开始测试
- 阶段六： 准备发布
- 阶段七：发布
阶段一 正确的产品方向
你的使命就是解决客户的问题，你的策略就是找到一种独特的方法来满足这个群体或细分市场的共同需求
使命
需求：
- “以客户为导向，而不是以竞争为导向” – 杰夫.贝索斯
- “不要只想着解决简单的问题，越困难的问题越值得去努力”–谢尔盖.布林
卓越的使命需要完全符合以下三点要求：
- 能够唤起人们的兴趣
- 提供 言之有物且能指明方向的原则
- 适合印在T恤上
策略
策略就是只在竞争对手的压力下，利用公司独特的优势来争取目标用户的粗略计划，它只是一段用于说明对目标客户来说你的产品将如何长期保持比竞争对手更强的吸引力的话，简而言之，你要阐明三件事：客户、公司和竞争
阶段二 产品定义
产品定义过程主要分为10步：
- 撰写新闻稿
- 更简洁、可读性更强且更关注真实的产品能给用户带来什么价值
- 六大要素
- 产品命名
- 发布时间
- 目标客户
- 解决了什么问题
- 如何解决（简明扼要）
- CEO的公开赞辞
- 创建并不断更新FAQ文档
- 绘制线框图或流程图
- 撰写产品单页或10分钟的演示文稿
- 在FAQ中添加API文档
- API最重要的作用是明确系统的各个边界，而明确的边界有助于人们了解各类功能或输出分归哪方负责
- 撰写功能规格文档
- 它是用来详细描述用户应该如何体验产品的文档，不包括系统在后台如何运行之类的技术细节
- 功能规格文档包含以下九个内容块
- 介绍（使命和策略）
- 目标与非目标
- 用例或用户场景
- 原型图或线框图
- API
- 负载规划
- 依赖
- FAQ和开放问题
- 关键事件
- 邀请设计团队和工程团队主管参与产品评审
- 找出边界情况：漫步于功能之中
- 找客户测试产品概念
- 团队会轻易陷入一场为莫须有的客户问题构建完美解决方案的狂欢中
- 命名、定价以及预测收益
- 如果你的产品好，你的客户基数大，你满足的需求真实有效，那产品的初始定价对长远成功有什么影响呢
- 你只需要理解产品定价的三个基本方法：按成本定价、按价值定价和按对比性定价
- 向管理层汇报
阶段三：用户体验
了解各类设计角色：用户体验，用户界面，信息架构，视觉设计，用户体验研究…以及角色模型
用户体验：UX user experience，关注的是用户如何完成任务以及该如何优化向用户展现信息的方式
用户体验设计师：对信息架构IA，information architecture尤为关注
- 信息架构专注于理解用户怎么才接收到信息，而不是系统怎么才能正常运作
用户界面：UI user interface，用户体验旧称，更关注单个页面或屏幕设计，是用户体验的组成部分
视觉设计：Visd visual design ，是关于如何通过一种赏心悦目，夺人眼球又清晰明了的方式来展示内容
用户体验研究：UXR user experience research，是用户体验的一个特殊组成，专注于研究用户是如何看待你的产品的
了解如何评估设计，6个用户体验问题
- 该用户界面要求用户完成的最重要的任务是什么
- 这是最简单的解决方案吗
- 我们应首先着眼于可用性的优化，滥用的问题等它出现了再解决也不迟
- SHE框架：简化 simplify、隐藏 hide、附和 embody
- 信息是否组织得当
- 最重要的客户类型最关注的信息应该最突出
- 信息排列方式应该像报纸文章：从标题到摘要
- 信息应尽可能个性化且实时，合理的前提下尽可能详细
- 最常用空间出现在最容易找到的地方
- 设计是否易用而且一目了然
- 解决可方向性问题：定位、视觉设计、惯例
- 标准是否一致
- 能否减少用户点击次数：用户必要的点击次数会极大的影响用户完成这个任务的能力
了解如何与设计师沟通
- 以用户的口吻说话
- 以提问的方式建立共识
- 反复讲述业务目标
- 用数据说话
- 提供一些竞争对手或类似体验中运作良好的案例
如果发现需要写一大段文字来解析某个特性该如何使用，你就应该重新设计这个特性
阶段四：项目管理
要想在交付上取得突破，你需要低成本的项目管理
三项低成本的工作：
创建一张简单的计划表并持续维护
- 一张简答的计划表只需要包括任务列表和每个人物的工作评估量
跟踪bug，观察燃尽图，计算实现零Bug率（ZBB zero bug bounce）的日期
谨慎管理你的依赖
如何拿到评估量
- 如果你不是工程经理，让你的工程经理去要评估量
- 表面上接受评估结果
- 认识到你的权利
- 只跟踪剩余时间
- 要求不考虑余量的评估
- 每周一次在团队会议上评估各任务的剩余时间
管理依赖
- 如果去除它也可以运转，那就去除它
- 如果内部能构建，就内部构建
- 如果必须添加一个依赖，那就趁早添加
- 如果必须添加一些依赖，那就依靠它上一个已构建的版本
- 如果交付得早，被依赖伤害的可能性就少
阶段五：测试
可以遵循下面8个主要步骤：
- 坚持测试驱动开发
- 围绕优秀的测试主管组建测试团队
- 亲自评审测试计划和测试用例
- 自动化测试
- 虔诚的推行内部实用 dogfood
- 开展找bug总动员
- 勤勉且有条理地处理bug
- 任命可信测试者以构建最后一道防线
阶段六：赢在量化
- 优秀的量化指标应具备5个关键特点：
- 测量成本低廉
- 测量可靠且可重复检验
- 能频繁地测量，最好能实时测量
- 团队能够根据它做出明智的改变
- 专注于客户
- 需要采集的三类数据：
- 目标进度
- 目标指标会告诉你目标的完成进度
- 经营绩效
- 经营绩效指标会告诉你产品的问题在哪里以及如何提升用户体验
- 系统性能
- 产品的实时健康度
- 目标进度
- 专注于目标本省，忽略细节末枝
阶段七：发布
- 对改动说不
- 发布手中有的，而非脑中想的
- 为了减少衡量的随意性，可以通过检查团队是否对目前的产品抱有自豪感来确定产品是否可以发布
- 建立一个“发布后第一时间”（IPL immediately post-launch）修改的需求清单
- 几乎所有对代码的改动，都会引起新的风险
- 尽可能推动工程团队去维护一套发布分支
- 开启作战室
- 营造紧迫气氛：渗透到你的从属方
- 发布完成清单的检查：目的在于确保软件发布中所有需要跟进的事项都有被有序安排且被详细描述，促进团队交流
- 撰写博文
- 发布软件：发布特性的最佳方法是借助一套实验性框架
- 亲自验证软件
- 应对发布带来的影响：
- 出现问题，回滚软件：只要成功回滚，发布就还没有失败
- 应对产品危机
- 演示产品
- 应对媒体
- 庆祝发布
