在软件行业中，我们把设计、打造、发布一款符合市场需求的软件称为交付（shipping）。要交付一个产品，最重要的只有3 点：

  • 确定用户需求和预期指标
  • 以最小成本实现最主要的需求
  • 发布并获得数据反馈，确定下一个迭代目标

在亚马逊和谷歌做得最好的团队是如何交付软件的

有效的交付过程，它分成7个阶段:

阶段一，确定正确的产品方向：需求–>使命–>策略

  1. 找到正确的需求
  • 以客户为导向，而不是以竞争为导向
    • 团队应该始终积极地去解决客户的问题，而不是紧盯竞争对手，被动地做出反应
  • 必须专注于解决真正的客户问题
  • 必须解决真正的客户问题，必须确保这是个很多客户都存在的大众问题

真实、大众、共有这些大问题的标准尽管很明显，却依然经常被忽略。这些标准还构成了使命的基石。应围绕这些基石构建使命并制订策略。

  1. 构建卓越的使命
  • 能够唤起人们的兴趣
  • 提供言之有物且能指明方向的原则
  • 适合印在T恤上
    • 让你和你的团队更容易记住使命
  1. 制定正确的策略

策略是指在竞争对手的压力下，利用公司独特的优势来争取目标用户的粗略计划。需要阐明三件事：客户、公司和竞争。

  • 如何才能长期为客户提供比竞争对手更优质的产品？
  • 越简短的策略越容易实现，也越容易获得他人的认同

阶段二，尽可能清晰详细地定义产品

产品定义过程主要分为10步。每一步都建立在上一步完成的基础上。

  1. 撰写新闻稿（可以只在首次迭代时进行）
    • 产品命名
    • 发布时间
    • 目标客户
    • 解决了什么问题
    • 如何解决（务必简明扼要）
    • CEO的公开赞辞
  2. 创建并不断更新FAQ文档
    • 节省重复回复问题的时间
    • FAQ分为内部问题和外部问题两个部分
  3. 绘制线框图或流程图
  4. 撰写产品单页或10分钟的演示文稿
    • 产品名称
    • 目标客户数量有多少
    • 解决了什么问题，这个问题对于目标客户来说有多大价值
    • 这个解决方案类似线上哪个产品，为什么你的方案能让竞争对手在长时间内都无法模仿
    • 何时交付，主要的里程碑有哪些？
    • 团队背景（仅针对VC）
  5. 在FAQ中添加API文档
  6. 撰写功能规格文档
    • 用来详细描述用户应该如何体验产品的文档
    • 不包含系统在后台如何运行之类的技术细节，这类细节应该包含在工程主管撰写的技术规格或设计文档中
    • 功能规格文档的读者一般为你的工程团队、设计团队，偶尔还有市场营销团队
  7. 邀请设计团队和工程团队主管参与产品评审
    • 找出边界情况并得到团队认可
    • 必须捍卫产品的核心原则
  8. 找客户测试产品概念
  9. 命名、定价以及预测收益
    • 想清楚基本的商业要素——命名、定价和收益
  10. 向管理层汇报
    • 取得上层的认可

产品单页和演示文稿实际上是新闻稿的延伸，它们增加了市场机会（用户量）、收益机会（解决方案的价值）和长期竞争优势（对手长时间内无法模仿）这三方面内容。

功能规格文档包含以下九个内容块，按照先整体后细节的顺序排列：

  1. 简介（使命和策略）
  2. 目标与非目标：目标是告诉别人你要做什么，非目标则是告诉别人你不要做什么
  3. 用例或用户场景
    • P0：没有该功能产品无法演示
    • P1：没有该功能产品无法交付
    • P2：锦上添花的功能
    • P3：哈哈哈！
  4. 原型图或线框图
  5. API
  6. 负载规划
  7. 依赖
  8. FAQ和开放问题
  9. 关键事件
    • 硬性时间要求
    • 主要事件的达成时间，如特性完成时间、可信测试者版发布时间

阶段三，设计用户体验

用户体验（UX，User Experience）关注的是用户如何完成任务以及该如何优化向用户展现信息的方式。通常用户体验设计师会通过制作流程图或原型图来说明用户体验。用户体验设计师对信息架构（IA，Information Architecture）尤为关注。不同于工程架构，信息架构研究的是信息该如何在用户界面中呈现，而不关心底层的数据结构。

视觉设计（VisD，Visual Design)是关于如何通过一种既赏心悦目、夺人眼球又清晰明了的方式来展示内容的一门学问。视觉设计师往往具有较强的平面设计、排版和美术功底。他们根据既定的信息架构，使用调色板之类的工具增强或削弱信息在用户界面上的醒目程度。好的视觉设计师会基于栅格系统排列按钮、文本及其他控件以增强产品体验的一致性。这种通过在设计界面中添加固定间距的虚线来辅助设计的栅格系统为设计师提供了一套有序控制留白和内容的框架，从而提升了用户寻找内容的便利性和不同场景下用户体验的一致性。

用户体验研究（UXR，User eXperience Research）是用户体验的一个特殊组成部分，它专注于研究用户是如何看待你的产品的。

角色模型（Persona）是一个由雅各布·尼尔森倡导并备受欢迎的方法，这个方法提供给你和你的设计团队、工程团队一个评估设计的框架。你的设计和业务团队将创建一组虚拟角色来代表目标客户，这些角色模型拥有姓名、薪水和目标，你还可以赋予他们任何你知道的目标客户的特征，然后利用这些角色模型来评估设计的效果。

评估用户体验设计要问的6个问题：

  • 该用户界面要求用户完成的最重要的任务是什么？
    • 谁是最重要的用户？
    • 这类用户必须完成的最重要的任务是什么？
    • 这个任务在用户界面中是最重要且最简洁的部分吗？
  • 这是最简单的解决方案吗？
  • 信息是否组织得当？
  • 设计是否易用且一目了然？
  • 标准是否一致？
  • 能否减少用户点击次数？

与设计师沟通时，我们要做的是清晰地阐述我们的业务目标以及它们之间的优先级，之后将权力交给设计团队，让他们以此为基础进行一系列的优化。

  • 以用户的口吻说话：作为【某种用户类型】我想……
  • 以提问的方式建立共识
  • 反复讲述业务目标，如果有些目标相互冲突，则反复讲述它们之间的相对优先级
  • 用数据说话
  • 提供一些竞争对手或类似体验中运作良好的案例

阶段四，做一些基础的项目管理工作，不要太多也不要太少，包括跟踪交付物的进展、指出问题以及控制项目范围

预估产品交付进度的三项工作：

  • 创建一张简单的计划表并持续维护
  • 跟踪Bug，观察燃尽图，计算实现零Bug率（ZBB，Zero Bug Bounce）的日期
  • 谨慎管理你的依赖
    • 如果去除它也可以运转，那就去除它
    • 如果内部能构建，那就内部构建
    • 如果必须添加一个依赖，那就趁早添加
    • 如果必须添加一些依赖，那就依靠它上一个已构建的版本
    • 如果交付得早，被依赖伤害的可能性就小

阶段五，开始测试

  1. 坚持测试驱动开发
  2. 围绕优秀的测试主管组建测试团队
  3. 亲自评审测试计划和测试用例
    • 检查测试用例是否包含下列描述性要素：领域、严重性、前置条件、需执行的任务、后置条件
    • 评审测试用例关注的内容：用户体验、安全和隐私、依赖
  4. 自动化测试
  5. 虔诚地推行内部试用（Dogfood）
    • 计划一次内部试用发布
    • 使其他试用者能够方便地提交Bug报告
    • 软件发布后应继续进行内部试用
    • 让进行内部试用成为企业核心价值观
  6. 开展找虫总动员
  7. 勤勉且有条理地处理Bug
    • 对Bug分级时需考察3个方面：频率、严重性、修复成本
  8. 任命可信测试者以构建最后一道防线

阶段六，准备发布

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

  • 测量成本低廉
  • 测量可靠且可重复检验
  • 能频繁地测量，最好能实时测量
  • 团队能够根据它做出明智的改变
  • 专注于客户

需要采集的三类量化数据：

  • 目标进度
  • 经营绩效
  • 系统性能系统

最后，正式发布产品

对改动说不。完成发布清单的核查.发布清单示例：

png

卓越技能

团队

4个PM角色：

  • 项目集成经理
  • 产品经理
  • 项目经理
  • 工程经理
  • 收购公司

如何与远程团队合作：

  • 不要租用工程师——组建一支工程师团队
  • 充分沟通
  • 尽量不要外包设计和PM角色
  • 重视文化差异
  • 构建清晰的需求
  • 忍受时差
  • 委任得力的主管
  • 大量出差，或者完全不出差
  • 与远程团队共饮

如何加入到一个新的团队：

  • 不要和团队说你们的产品一团糟这种话
  • 做一个选择：你是打算延期交付以解决这种混乱状况，还是承认它的存在然后正常交付

技术

四个S：服务器（server）、服务（service）、速度（speed）和扩容（scaling）

沟通

如何写好邮件：

  • 像记者写新闻一样写邮件
  • 使用精确增量表达法
  • 分点阐释原因
  • 立即停笔，你已经写完了这封邮件
  • 设法用建议取代质疑
  • 考虑受众的感受

开会有三大目的：解决问题、收集信息、传递信息。一般会议都只为其中一到两个目的。有时候每周一次的团队会议能同时达到这三大目的。常见会议类型：团队会议、站会、1对1、产品/工程/用户体验评审、头脑风暴会。

如何组织好会议：

  • 会后立即发出主题纪要
  • 允许改变开会的目的
  • 拒绝在团队会议中发泄
  • 使用鱼骨图等工具来解决问题

如何做好演示：

  • 将演示时间控制在15分钟内
  • 永远传达且只传达一个信息
  • 讲故事
  • 制作“综述单页”
    • 你想讨论的东西是什么
    • 机会
    • 提供的解决方案
    • 成本和实施时间表
  • 重点演示用户体验
  • 极度专注倾听

综述单页示例：

png

决策

在冲突中达成共识：

  • 阶段1：这不是你的错
  • 阶段2：公平谈判并使用数据支持
  • 阶段3：那个数据没谈成……我们编个新数据吧！
  • 阶段4：寻找可免费提供的东西
  • 阶段5：转身离开并安静思考
  • 阶段6：协议，文书工作，以及互相指责

十大交付原则

  1. 你不是来当老板的——团队主管是仆人，他们存在的目的就是为了伺候工程团队
  2. 从用户角度出发
  3. 用独特的方法解决很多人都有的大问题
  4. 坏的消息就是好的消息。——杰克·韦尔奇
  5. 先寻求理解，再寻求被理解。——史蒂芬·柯维
  6. 构建最简洁的可用的产品
  7. 交付手中有的，而非脑中想的
  8. 无法测量的东西也就无法提升。——开尔文勋爵
  9. 你不可能做完所有工作，所以你应首先做那些只有你能做的工作
  10. 永远走在交付的康庄大道上

参考

版权声明：本文为博主原创文章，转载请注明出处。 旭日酒馆