为什么要读这本书

作为团队贡献者，不是把个人做好就能把整个事情（项目）做成，所以积累把事情做成的各项能力尤为重要。当你做的不够好时，自然要找一个好的参考对象，而我比较崇信“学习硅谷好榜样”的理念。所以当自媒体节目《李自然说》推荐这本书，真是恰逢其时。

近代以来，不管是自然科学还是社会科学，甚至包含技术写作，欧美国家都积累了很多实用的方法论。当那些头脑发热的人宣称我们在某某方面超过美国，如果能认识到这一点，就能保持清醒。在相当长一段时间内，我们还需要以欧美为师。而我也要学习他们，提升对 用户、产品、商业 的理解能力。

整本书很薄，不到 200 页，所以不是对项目迭代全流程的每个节点长篇大论。作者对项目每个节点的关键关注点总结非常到位。

以下内容，也有 B 站 和 YouTube 视频分享。

在工作中的实际应用

一般在产品业务团队，敏捷流程比较完善：PM 出需求 > 交互设计 > 视觉设计 > 开发 > 测试，交付的计划时间推动整个过程运转，这其中甚至有专门的 PMO 负责协调管理项目。

我负责的方向，偏技术一些，没有 PM、交互、视觉、PMO，角色缺失较多。对那些纯逻辑、纯流程优化的的项目影响不大。对需要 信息架构、交互、功能组织，多角色协同开发的项目影响较大，做这类项目如果角色不齐全就需要非常强的综合素质。以前做业务方向，觉得理所当然，没有思考流程每一步的作用和价值，这两年公司倡导提升工程能力，加之技术方向的实践，才慢慢理解流程和软件工程的重要性。

做产品做项目时，都知道有问题，但不知道问题在哪里，怎么做更好，如果团队成员自驱力、积极性不高，软件工程知识体系不健全，战斗力必然会大大折损。认识到团队差异，认识到问题，才能解决问题。“赢在项目管理”这一章节帮我解决了这些疑惑。

比如如何能知道产品能按时交付，只有几点：

• 创建简单的计划表并持续维护。也就是拆解几个主要的功能点（或任务），每个主要功能点（或任务）按计划给出完成的时间点。
  • 同一个角色工作量是否均衡，如果不均衡，优化均衡后下交付可以提前。
  • 每个任务工作量大小
• 跟踪 Bug，观察燃尽图
  • 项目前期要观察 需求 的燃尽图，项目后期要观察 Bug 的燃尽图。
  • 进度判断：我简单用下面两个数据百分比比较，前小于后，差值就是进度 Delay 的程度。
    • 已完成工作量/整体工作量（也可以用 已完成 Story 数/整体 Stroy 数）
    • 项目流逝天工作日数/项目总工作日数
• 谨慎管理依赖
  • 这一点也非常重要，不考虑依赖的排期肯定是有问题。比如同一功能，服务端协议评审、发布 必然要在与前端联调，前端提测之前。
  • 两个角色间的交互接口 都是需要评审发布的。

简单三点，把项目管理的要点说的很清楚。看完之后感觉把握了项目管理的精要，最后 和 大团队的 PMO 请教，如何在公司的 需求管理 平台（类似 JIRA）去观察这些。实用又简洁的几个关注点，让我有恍然大悟的感觉。我想所谓的能力强的人人，都是善于把握这些关键点的人。

当然，项目管理只是产品研发活动中的一个环节，一个项目的成败，还有其他重要环节。下面就通过读书笔记（可能更类似摘要）的方式记录这些点，主要目的是抗拒遗忘。如有读者检索到这里，建议阅读原书（京东纸质书 或 微信读书）。

读书笔记

全书只有两个部分，第一部分软件工程或者说工程能力相关，第二部分是一些基础技能、软素质、组织与管理。文章组织结构也非常好，看标题基本就知道要讲什么了。

第一部分 ：赢在卓越产品，步步为"赢"

1、赢在使命和策略（统一目标）

团队如果没有清晰的使命，则会导致失败。因为团队和投资人会根据自己对使命的不同理解而各自为战。从而导致冲突、混乱和痛苦。

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

• 能够唤起人们的兴趣。长期吸引利益相关者注意，才有时间去挖掘产品细节。
• 提供言之有物且指明方向的原则。通过使命指明方向，并将希望达成的结果清晰化。
• 控制使命的长度，好记。

使命需要反应代表性的产品或服务，而不是面面俱到。

如何制定策略：

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

这里跟 SWOT 分析法类似。

案例一：Google Talk

使命：使人与人之间在任何地点都能通过任何终端通信。

优势：谷歌庞大的云服务基础设施。比微软的 Skype 更低廉。

需要特别注意为长期为客户提供比竞争对手更优质的产品。否则竞争对手就会迅速模仿并推出和你的产品功能一样，价格更低廉的新品牌来将你一举击溃。

案例二：亚马逊 IMDb（Internet Movie Database）

使命：启发视频观看者。（提供信息和数据服务）

策略：随着越来越多的内容产生，每天消费内容的用户也越来越多，但对于 20 ~ 40岁的工薪族来说，他们在海量的内容前却不知如何选择。我们需要给这些用户启发，帮助他们找到要看的视频，并让他们再看的过程中对内容有更深的理解。

用户群体选择：与有大把时间耗在 Facebook 和 YouTube 上的青年不同，工薪一族时间有限，人际网络丰富，个人主见强烈，还有可自由支配的收入，愿意在内容上付费。（优先满足工薪阶层需求，青少年在 版本 2 中考虑）

优势：

• IMDb 独特的电影数据集
• 亚马逊对内容分门别类的能力
• 可靠的个性化推荐技术
• 推荐算法覆盖平台多，数据丰富，更精准。（对比 Netflix）

2、赢在产品定义（需求分析）

产品方案具体且可理解。需要用文字非常贴切的描述产品，使设计师可以借此设计原型，HR 可以借此雇佣工程师，项目组可以拿项目经费购买面包和服务器。

当设法细化产品方案时，你会发现产品要解决的一些客户问题都是你主观臆想，采用“最小化可行产品”方法来证明臆想是否正确。产品定义过程分 10 步，每一步都是建立在上一步完成的基础上。10 步完成后就有一份完整、清晰的产品文档。工程团队也可以进入编码阶段了。

① 撰写新闻稿

策略说明，促进各方了解和公开透明。主要是从用户视角出发简明扼要地阐述产品是什么、什么时候发布以及为什么要做这个产品。一般有以下几个要素：

• 产品命名
• 发布时间
• 目标客户
• 解决了什么问题
• 如何解决（务必简明扼要）
• CEO 的公开赞词

② 创建并不断更新 FAQ 文档

记录争议点和重要细节。产品方案细化过程中，问题会层出不穷，问题能指出产品的不足之处。如果一个问题外部用户（应该是项目组外的成员，编者注）也会问到，就会记录到 FAQ 文档的“外部问题”章节。

FAQ 的好处：

• 节省大量回复邮件的时间（不用对重复问题重复回答），还能抵御一些内部责难（不会因为一些小问题被问责，证明你是尽职的）。
• 当客户支持团队和技术协作团队整理面向公众的内容时，FAQ 是一个很有价值的资源。

③ 绘制线框图或流程图（UX）

对产品可视化的描述，在讨论或答疑中使用可以让观点更清晰。具象化产品各环节的用户体验。

④ 撰写产品单页或 10 分钟的演讲文稿

写给高管或多数风险投资人看的产品介绍文章。需要把控介绍的详略程度。争取工程团队、管理层、VC（风险投资人）、其他利益相关方的初步支持。否则 到 第 7 步要返工。这两份文档包含五个要素：

• 产品名称
• 目标客户 + 数量有多少
• 解决了什么问题 + 问题对目标客户有多大的价值
• 核心优势：解决方案 + 类似线上哪个产品（竞品），为什么你的方案能让竞争对手长时间内无法模仿。
• 何时交付 + 主要的里程碑有哪些
• 团队背景（仅对 VC）

大部分对象对行业都有充分的认识和独到的见解，但并不了解要做事情的前因后果。所以演讲最佳方式是先讲用户现状，在延展上面的五要素，最后留出时间供聪明的听众就他们关心的点刨根问题。

不要埋怨他们咄咄逼人，他们并非喜欢看你理屈词穷的样子，这只是他们考察你的一种方式。

⑤ 在 FAQ 中添加 API 文档

API 文档可以说明你的团队如何与其他团队协作、外部开发者如何使用这套系统以及你需要存储什么数据。预先定义清楚 API 有诸多好处：

• 帮助搭建有这些 API 构成的面向服务的体系架构（SOA，Service-Oriented Architectures）
• API 的作用是明确系统的各个边界，而明确的边界有助于人们了解各类功能或输出分归哪方负责。
• 项目初期建立了理解和术语上的一致性，为后续高效沟通产品需求打下坚实基础。

API 是产品的第一技术触角，第 6 步会把他们整合到需求文档里。你需要花数小时起草一些 API，后续再在工程团队的帮助下完善他们。

？ 这一点有疑问，笔者工作中都是在需求发布、交互发布、视觉发布 会后，有技术团队进行接口协议的评审和发布。需要向英文版原书考证。

⑥撰写功能规格文档

产品需求文档（Product Requirements, PRD ,谷歌常用此名），市场需求文档（Marketing Requirement Document，MRD，微软常用此名）。它是阐述产品各功能详情以及为什么要有这些功能的最权威的文档。可以将 新闻稿、FAQ、线框图、产品单页 和 API 文档内容加到需求文档的各章节。除去这些主要内容，还需要添加负载规划、非目标（不要什么）以及非常见用例。

文档面向对象是工程团队、设计团队、偶尔会有市场营销团队。功能文档包含以下几块：

• 简介（使命和策略）
• 目标和非目标
• 用例和用户场景
  • 在什么场景，怎么使用（产品上叫 Persona，笔者 注）。
  • 资源的有限性，必须要确定优先级。
    • P0 ：没有该功能产品无法演示
    • P1 ：没有该功能产品无法交付
    • P2 ：锦上添花的功能
    • P3 ：基本上要被裁掉的功能
• 原型图 或 线框图
• API（？这阶段出现有点早）
• 负载规划
  • 根据未来一段时间内用户的使用量进行粗略估计并制定应对计划。方便工程团队做好服务器和存储扩容准备。
  • 制定预案应对突发高峰
  • 制定备用策略应对最坏情况
• 依赖
  • 列出全部 依赖方、负责人、依赖的原因、会产生什么影响（流量或异常情况）不需要太详细。
• FAQ 和 开放问题
• 关键事件
  • 硬性时间（比如 苹果的开发者大会时间，资金能支撑到的最后时间等）
  • 特性完成时间（粗估）
  • 可信测试版发布时间（粗估）

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

获得项目组对产品的认可，并让他们帮忙寻找产品中存在的各种极端和边缘情况。找到边界情况并得到团队认可：没有人能在第一次就能创建完美的产品；一方面必须找到边界情况，另一方面还必须参与捍卫产品的核心原则。

⑧ 找客户测试产品理念

在此阶段，你需要了解产品方案是否真正能解决客户问题。

⑨ 命名、定价以及预测收益

通过收益预测会更加确信产品能给投资人带来回报。

定价方法：

• 按成本定价
• 按价值定价
• 对比定价

收益模型：

• 估算买家总体市场规模
• 预估市场规模的增速
• 估算你的目标市场占总体市场的比率
• 通过市场推广能触碰到的用户规模。（市场预算/CPM，CPM：千人印象成本）
• 预估出触碰用户的转换率
• 找到其他用户增长渠道并加入到模型中。比如产品中，有“邀请朋友”的机制。
• 最后，将产品定价乘以每个时期增长的用户数就是收益。

减少哪些成本高但转化率低的广告投入。模型对假设是高度敏感的，这不是它的问题而是它的优点，它揭示了假设以及特定变量的重要性。

⑩ 向管理层汇报

3、赢在用户体验（交互设计 与 视觉设计）

用户体验不仅是产品的外观样式，还是产品的使用方式。体验问题不能全抛给设计师，也不能自己去解决所有体验问题。要做的就是让设计团队发挥他们最佳的水平。你需要：

• 先理解设计，再让设计团队理解你。可以从设计师的不同角色来了解设计。
  • 用户体验（UX）：交互，关注信息架构（IA，Information Architecture），不关注底层数据架构。信息架构专注于理解用户怎样才能接收到信息（翻译别扭，大概可以解释为 页面布局、页面间跳转步骤、信息组织），而不是系统如何才能正常运作。输出是低保真模型。
  • 用户界面（UI）：关注单个页面或屏幕的设计。
  • 视觉设计（VisD，Visual Design）：根据既定信息架构设计配色，单页内信息排版，体验一致性。视觉设计师有较强的平面设计、排版和美术功底。输出是高保真模型。
  • 用户体验研究：从用户中挑选参与者，研究用户如何看待你的产品，构建有序不带偏见的研究。通过研究产出关于产品成败的统计显著性数据，反馈给工程团队。
  • 角色模型（Persona）：创建一组虚拟角色来代表目标用户（客户，这两概念是不一样的，《人人都是产品经理》中有介绍）。
• 了解如何评估设计，这样才能和设计师进行有意义的互动。
  • 每次检查原型或设计师都要问以下六个问题：
    • 该用户界面要求用户完成的最重要的任务是什么？
      • 谁是最重要的用户？
      • 这类用户必须完成的最重要任务是什么？
      • 这个任务在页面中最重要且最简洁的部分吗？
    • 这是最简单的解决方案吗？
      • 用户完成任务的能力与该任务的复杂程度呈非线性函数的关系。（对用户要求越多，用户完成的能力和意愿就越低）
      • 前田约翰在《简单法则》一书提到简单化的框架 SHE：简化（simplify）、隐藏（hide）、附加（embody）
    • 信息是否组织得当？（亚马逊的产品详情页信息数量庞大，但组织优美，所有内容块都按他们的收益能力排序）。为让数据和特性该如何组织起来，需要遵循：
      • 最重要的客户类型最关注的信息应该最突出
      • 信息的排列方式应该像报纸文章那样从标题到摘要一一排列。
      • 信息应该尽可能个性化且实时。
      • 最常用的控件出现在最容易找到的地方。
    • 设计是否易用且一目了然？
    • 标准是否一致？
    • 能否减少用户点击次数？
• 了解如何和每种设计角色有效地沟通，其中包含了解如何评价设计稿，以及如何向设计师提供反馈。
  • 以用户的口吻说话
  • 以提问的方式建立共识
  • 反复讲述业务目标，如果有些目标相互冲突，则反复讲述它们间的优先级
  • 用数据说话
  • 提供一些竞争对手或类似体验中运作良好的案例
• 学会用线框图和原型图来辅助沟通。
  • 灰度线框图（低保真模型）重于文案布局而非视觉设计，注重展示应用的结构。
  • 视觉稿（高保真模型）是更为精致的视觉原型。

4、赢在项目管理（项目管理）

三项低成本且必须要做的工作：

• 创建一张简单的计划表并持续维护
  • 开发测试比时间预估，如 3 ：1
  • 容差系数：容纳哪些未曾预见的问题和一般的生产力损失所消耗的时间。（一些团队判断 5 天开发时间，只有 3 天是具备生产力的）
  • 排除时间，比如不再周五上线。有问题需要抓回在酒吧买醉的工程师。
  • 找到开发时间最长的工程师，试着把归属他的任务分配给其他不饱和的工程师。让计划均衡。
  • 这样做的好处：
    • 便于项目剩余时间，和项目进展查看，控制项目风险。
    • 平衡团队内的任务分配
    • 便于预测项目各时间节点
    • 预先将你的假设传达给你的团队
    • 每周一次的团队会议上评估各任务的剩余时间

• 跟踪 Bug，观察燃尽图，计算实现零 Bug 率的日期。
  • 所有工作尘埃落定，停止项目计划去关注 Bug 列表和燃尽图，预估产品何时可以交付。，
• 谨慎管理依赖（5 个如果）
  • 如果去除它也可以运转，那就去除它
  • 如果内部能构建，那就内部构建
  • 如果必须添加一个依赖，那就趁早添加
  • 如果必须添加一些依赖，那就依靠它的上一个以构建的版本。
  • 如果交付的早，被依赖伤害的可能性就小。

5、赢在测试（质量控制）

如何确保你交付的软件不会让你蒙羞？8 个对产品质量有重大影响的步骤：

• 坚持测试驱动开发：自动化测试
  • 代码拆分片段，每个片段单一职责
  • 在写 具体方法 前，先写一个测试，即单元测试
  • 单元测试写完，开始编写方法，如果输出不符合预期，测试就会失败。
  • 软件构建时，单元测试会自动执行
• 围绕优秀的测试主管组建测试团队
  • 一流人雇佣一流的人，二流的人会雇佣三流的人。
  • 高标准雇佣外包团队：利大于弊
    • 弊端：
      • 需要一个开发主管与测试人员联系，会增加工程团队的成本。
      • 培训成本是沉没成本，且不可回收
      • 能力突飞猛进的测试人员期满后会选择其他团队
    • 优点：
      • 人员管理上，外包的组织成本比全职雇佣低
      • 与外包合作比与内部成员合作估计少，可以要求更快的速度，更高的产能以及稳定的质量
      • 不需要晋升外包员工
  • 按高标准雇佣测试人员，不使用外包团队
    • 要么交付有 Bug，要么工程师自己去做测试，项目最后总是窘迫收场。选择这种方式后果自负。

• 亲自评审测试计划和测试用例
  • 测试计划和测试用例的质量，测试用例必须包含以下描述性要素：
    • 领域
    • 严重性：1~4 级
    • 前置条件：测试该项 Case 的前置操作
    • 需执行的任务：哪些步骤，任何步骤失败测试都失败
    • 后置条件：执行操作后的期望结果
  • 单元测试覆盖低的复杂软件系统中，微小的变更很容易导致主要特性的瘫痪。
  • 你也可以选择只关注以下三块：
    • 用户体验最重要的部分
    • 安全和隐私：测试应该包括破坏你的网站
    • 依赖：如果依赖一些非内部构建的数据库、第三方服务或软件，确保这些依赖被严格测试。

• 自动化测试
• 虔诚的推行内部试用（Dogfood）
  • 谷歌文档：停止在公司电脑默认安装微软 Office
  • 亚马逊：员工使用亚马逊品牌服务（Prime）提供员工折扣。
  • 提供奖品给报告不重复 Bug 最多的人。
  • 高管们天生是令人敬畏的使用者。
  • 最佳实践：
    • 内部试用发布：带来称赞和反馈，提振士气
    • 使使用者能够很方便的提交 Bug 报告
    • 软件发布后应继续进行内部试用
    • 让进行内部试用成为企业核心价值观

• 开展找虫总动员
  • 设置奖项，提供物质激励。
  • 项目计划中增加找虫总动员这样一个关键事件。安排在开发和测试日程表中。
  • 感谢每一个 Bug，坏消息就是好消息。
• 勤勉且有条理的处理 Bug，以下 3 步就能把 Bug 处理好：
  • 基于频率、严重性和解决成本对 Bug 进行分级
    • 频率越高，修复重要性越高
    • 严重性，对用户体验伤害有多大
  • 每天和开发和测试主管碰一次，评审新增的 Bug
  • 不断施加压力以减少新的阻碍发布的 Bug 出现。
• 任命可信测试者以构建最后一道防线。
• 以新用户的方式来使用整个产品
  • 删除账号和数据，从零开始使用软件。

6、赢在量化（数据驱动）

• 量化数据时团队主管的命根子，作为主管全部的工作都是说服别人或被别人说服。量化数据为这样的讨论提供了理性基础。
• 量化数据可以帮助你优化判断，至少为你的判断提供辩护。
• 好的主管能根据量化数据发现问题、跟踪进度并庆祝成功。
• 优秀的量化指标具备的 5 个关键特点：
  • 测试成本低廉
  • 测量可靠且可重复校验
  • 能频繁的测量，最好能实时测量
  • 团队能根据它做出明智的改变
  • 专注于客户，如购买转换率、启动次数 比 安装次数更有价值。
• 需要采集的三类量化数据：产品发布后要更新指标。
  • 目标进度：精确增量表达法
    • 7 天活跃用户数（比日均合理）。
    • 利润
    • 注册量
    • 下载量
  • 经营绩效：告诉你产品问题在哪里，以及如何提升用户体验。通常用比率表示
    • 点击购买到付款成功的转换率
    • 社交产品，可以统计 用户参与度（发信息，7 日活跃用户发帖率， 平均停留时间）
    • AB 评估改动带来的影响
    • 避免虚荣指标：如 安装量 高，而 流失率 高达 90%。
  • 系统性能
    • 异常变化
    • 到达率
• 专注于目标本身，忽略细枝末节
  • 不可以操纵指标。不能把指标当老板，使用不合理手段优化数据。

7、赢在发布

来到这个环节，几乎所有 Bug 已经修复，可信测试者很喜欢它，还构建了一套衡量产品的指标监控系统。以下几个步骤，保证发布质量：

1. 对改动说 “不”
   1. 建立 发布后第一时间修改的需求清单。有些改动固然重要，但不一定要在发布前完成。
   2. 几乎所有的代码改动都会引入新的风险，还有可能导致需要打开老 Bug。
   3. 分支管理：新特性分支、发布分支、热修复补丁分支。
2. 开启作战室
   1. 这个节点上应改为每日例会。每日例会能帮助你高效做出决策并营造一种紧迫的氛围。
   2. 还能促进团队的协作并消除信息传递时间。
3. 营造紧迫的气氛
   1. 别人急躁之时正是你保持冷静的时刻。
   2. 新手工程师通常会羞于督促其他团队或向别人请求帮助。他们害怕别人发现他们有不懂的地方。（承认自己有所不知是心理走向成熟的标志）
4. 核查发布清单
   • 需要跟进的事项都被有序安排且被详细描述。
   • 
5. 撰写博文
   • 阐述使命，目标客户以及你能解决的问题。
6. 发布软件
   • 借助实验性框架，亚马逊会发布网页实验室（Weblabs）
   • 有可能的话最好让你的数据模型向后兼容，便于回滚。
   • 不要选择在周五或临近假期发布，因为：
     • 假期拼命呼叫工程师成本
     • 你因此错过放松机会
7. 亲自验证软件
   • 所有服务上到生产环境后，你需要 2 天内完成产品验证。
   • 测试主管也会组织一轮验证（这一轮叫 验证测试，Build Verification Test）
   • 你需要以新用户的身份来亲自体验整个产品。从注册流程开始验证。
8. 应对发布带来的各种影响
   • 出现问题，回滚软件
   • 应对产品危机，危机是最好的教学材料
     • 知会危机扩大邮件成员
     • 知会相关方
     • 知会社区
     • 寻找引入专家协助团队解决问题
     • 知会管理层
     • 保持 Bug 状态的更新：更新出来不会对解决危机有什么负面影响
     • 事故调查报告：什么事情，什么人，什么时间，为什么以及怎么做。

第二部分 ：掌握卓越技能，更胜一筹

交付软件不同于其他大多数工作，它需要精准的技术沟通，跨多个领域的深厚学识以及无畏的勇气。

第二部分强调的技能都是经过实践检验，能够提升效能和幸福感的方法。更高效的效能和幸福感又能反过来推动交付。

第 9 章 介绍系统知识，掌握系统知识帮助你引导工程团队做出正确的决定。学历不代表能力，有些非常聪明的计算机科学硕士一样不会创建不靠谱的架构。

第 10 章 阐述如何把卓越的想法如何有效的传达给别人。

第 11 章 收到产品反馈，有些很有价值，有些则十分荒谬，这一章介绍应对不靠谱建议的方法。并探讨你改采纳什么建议以及团队该如何做出正确的决策。

理解技术并具备了优秀的表达能力。离成功更进一步，然而每天仍需应对一些交付带来的特有挑战，如特性需求和高层的指手画脚。

掌握这些技能最大的挑战不在于理解他们，而在于始终如一地在实践中应用他们。

第 8 章 胜在团队

必须找到配合默契的工程主管、产品主管、设计主管。优秀的人总是聚在一起工作。

团队主管可以对成员的职业生涯和幸福感略加影响，如指明正确的项目方向，识别问题以及给予渴望获得认可的成员以赞誉。

团队主管工作量很大，通常难以一个人完成工作。所以至少需要一名工程经理、一名产品经理、一名项目集经理（？PMO），或者四种职能为一体的人。

• 项目集经理（？PMO）：职责在于整合不同团队和不同工作职能。比产品经理更少关注业务，比项目经理更少关注项目的技术角色。
• 产品经理：偏重软件的业务方面，产品经理要努力从用户的角度出发帮助确定特性开发的优先级。甚至有些产品经理是典型的 MBA 出身，专注于品牌管理、定价、市场准入策略等。
• 项目经理：排定项目计划和协调团队工作，他们负责向工程师要评估工作量，辨识任务间的依赖关系，以及如何在更短时间做更多的事（原文：“负责向工程师要评估值，辨识从属关系。”）。
• 工程经理：通常由老牌程序员担任，最佳的工程经理是那些由于热爱团队，善解人意，精通交付并乐于构建卓越产品而晋升到该职位的人。
  • 不同团队工程经理目标不同：如维持团队幸福感，战斗力；保持工程质量；还有人以为他近似于产品经理。

如何雇佣产品经理、项目集经理（？PMO）、工程经理

5 个主要的雇佣主管的原则：

• 雇佣比你聪明的人
  • 实际推出很多产品是关键加分项
  • 对财务和用户体验的影响
• 雇佣懂得自己不是来当老板的人
  • 合作决策
  • 基于数据的争论
  • 聪明的向上反馈
• 雇佣表达清晰、言之有物的人
  • 简短具体
• 雇佣用数据说话的人
• 雇佣充满活力的人
  • 主管往往是团队背后的驱动力，如果他们不能给团队带来活力，你的目标就会落空。

如何收购一家公司：（估计一时半会儿用不上，简单记录）

收购一家公司，一般有 4 个原因：知识产权、人才（关键人才、好的雇员、多余人才）、客户、防御。

收购陷阱及最佳实践：

• 计划将你的团队部分人调入他们团队，把商业文化、商业实践、商业政策带进这只新团队。
• 计划整合产品
• 了解之前的所有交易和负债

如何与远程团队合作：

• 组建一只工程师团队
• 充分沟通
  • 离你越远的团队越焦虑
• 不要外包设计或 PM 角色
  • 优秀的设计者会解决众多你没想到的问题（视觉设计可外包）
• 适应文化差异
• 构建清晰的需求
  • 新团队真不知道干些什么或者为什么该干这个
  • 详实的需求对所有团队都很关键，远程团队尤为重要
• 忍受时差，通过任何方式会面
• 委任得力的主管
• 大量出差，或者不出差
• 与远程团队共饮

如何加入一个新团队

关键两点：你该扮演什么角色，下好第一步棋。

第 9 章 胜在技术

想要快速交付一款产品，你必须会询问富有洞见的问题，会正确的引导方向，明智决定哪些事必须现在做，哪些事可以之后再做。

如果想顺利掌控产品开发过程，需要了解四个 S：服务器（Server）、服务（Service）、速度（Speed）、扩容（Scaling）

1. 服务器
   • 尽量不要买服务器，这样你不用做大量运维工作（如 安装更新）。
   • 托管主机的方法让你省心不少，放弃很多反正你也不需要的控制权。
2. 服务
   • SOA：面向服务的架构。微服务，独立构建、独立版本管理、独立运行。
   • 如果通过 API 通信，或 RPC （Remote Procedure Call）通信。API 都要写到文档中（评审、发布）。
   • SOA 的缺陷：
     • 大量服务时追踪问题成本，需要挨个排查。良好的监控可以缓解这个问题。
     • 团队间的依赖问题，如果没有通知的情况下修改了 API，你的系统就会遭到破坏。因此每个服务都必须确保向前兼容并主动通知用户，但这做起来很难。
     • 构建一个出色的沙箱或测试环境并不容易，他要求每个系统必须存在于沙箱中，这样才不至于污染生产环境。即便数据都保存在沙箱中，各系统频繁删除数据，很难保证数据一致性。
   • 虽然 SOA 有这样的缺陷，但如果想追求 可扩容性（可伸缩）、可扩展性（可升级性）以及其他优秀的特性，微服务化是值得的。
3. 速度
   • 为了应对复杂性管理带来的挑战，一个可行方法是分开加载应用程序的各个独立模块。
   • 缓存是解决服务连接速度问题。
4. 扩容
   • 有更多用户时，你需要准备更多的服务器，第三方主机托管服务可以帮那个你解决大量这类问题。
   • NoSQL 类数据库技术，先天支持数据分布式。
5. 如何正确的询问技术问题
   • 能给我画张系统图吗？从离用户最近的方框入手，了解所有方框都在干什么。
   • 这个方框传到那个方框的延迟是多少？
   • 可以扩容到 N 吗？
   • 去掉 B 方框的影响是什么？
   • 我们是围绕组织边界或系统边界来架构的吗？
   • 能通过缓存什么数据来提升性能吗？
   • 能通过独立加载什么数据来提升性能吗？

第 10 章 胜在沟通

致力于交付，几乎有海量的信息需要传达，海量的状态需要收集，海量的检查需要执行，海量的其他细节需要担忧。只要懂得一些技巧，这些都不是难事。

关键技巧是尽可能少开会，但不要不开会。很多时候可以通过一封优质邮件就完全可以避开。

如何写好邮件：

If you can't explain it simply, you don't understand it well enough.（如果你不能简单说清楚，就是你没完全明白。）

爱因斯坦

• 如何写好邮件：
  • 作为出色的领导者，需要不断向团队传递清晰的、具体的信息，使他们明确方向，坚守使命。这也是写邮件的目的：清晰、简要。
  • 分清主次、加上正确的称呼（明确受众）、敬语和署名。
  • 使用增量表达法，能让任何人迅速看懂你做了什么，产生了什么影响，何时开始，何时完成。如：
    • 将某个变量增加或减少 XXX，即从 XX 增加或减少到 XXX。
    • 在 XXX 时间（开始时间） 到 XXX 时间（结束时间）这 XXX （总持续时间）时间内，将某个变量增加或减少 XXX （差值）。
  • 分点阐述原因
    • 将逻辑依据从视觉上划分成多个点进行阐述。
  • 设法用建议取代质疑，因为直接质疑会让人恼火。为避免如此，你可以这样转化问题：
    • 为什么保存按钮是红色的？ -> 能把保存按钮改为蓝色吗？
    • 为什么工作量还没估完就确定了发布日期？-> 发布日期还可以协商吗？
  • 考虑受众的感受
• 如何应对五种类型的会议：邮件不管用，就要考虑开会。
  1. 团队会议：
     • 目的是促使团队坚守使命并就当前一些悬而未决的问题达成共识。
     • 季度开始，重新审视团队季度目标，并调整目标直到所有人认同。
  2. 站会，时间不超过 15 分钟。
     • 会议简短。交流近况，促使团队内部信息透明，责任到位。
     • 每个人在站会应该汇报下列信息：
       • 我昨天做了什么
       • 我今天要做什么
       • 我是否遇到了障碍
     • 整个团队很清楚每个人的表现和项目的状态。
  3. 1 对 1
     • 适合主管们相约在一起坦率地进行交流并公开问题。
  4. 产品 / 工程 / 用户体验 评审
     • 产品评审会首要目标是让老板认可你的产品方向，给你提供反馈。
     • 用户体验评审会只需要准备产品原型图，在设计师演示之前，你应该讲一下为什么你在这儿，你的用户是谁？你的业务目标是什么？
     • 工程评审会目标是赋予开发主管权利，收集经验最丰富的工程师的专业反馈，以及尽量少花时间在演示上。
       • 提前审读材料，以免开发团队提出一些使命之外或与策略相悖的东西。
  5. 头脑风暴会
     • 目标是收集尽可能多的想法。
     • 没有时长限制，最好隔一个半小时休息一下。让头脑风暴发挥作用的 4 个基本原则：
       • 不要再头脑风暴过程中批评他人的想法
         • 这样将少一个贡献想法的人才。
       • W说“是的，嗯......”
         • 他将创意带到下一个层次
       • 通过结构化来促进讨论
         • 通过鱼骨图找出深层次原因。（5W 方法的应用，见 五个为什么和六合法）
         • 有条理并鼓励创造性
         • 有时甚至需要定下三个需要解决的问题并设法解决他们，帮助团队中更专业，更有条理的成员参加到你的过程中来。
       • 在头脑风暴结束时明确告知大家头脑风暴结束了。
         • 到了某些点，必须结束头脑风暴并进入批判性分析阶段
         • 如果不讲清楚，人们可能会随机调回纯创意模式
• 如何组织好会议：
  • 会后立即发出主题纪要
    • 只有这样，你的团队才能感觉到他们是会议的参与者和下一步计划的执行者。
    • 在纪要中先放结论和下一步计划，再讨论详情。
    • 2~5 行概要放在纪要顶部。
  • 允许改变开会的目的
    • 开会三大目的：解决问题、收集信息、传递信息。
    • 因为你依赖的某个假设可能发生了改变。
    • 回忆中发现问题，如团队动力问题、系统设计问题、新需求。
  • 拒绝在团队中发泄负面情绪，但允许在 1 对 1 会议中发泄
    • 所有的危机都是教育机会
    • 与团队会议不同，1 对 1 会议很适合个人发泄情绪
    • 长期弥漫的负面情绪会伤害你的团队成员。
    • 在面对问题时不要抱怨，需要寻找建设性的应对的方法。
  • 使用鱼骨图等辅助工具解决问题
    • 持续问“为什么”直到找到根本原因。
    • 通过不停问“为什么”，向那些懂得你所不了解的知识的专家求助。

• 如何做好演示：
  • 通过演示获取资金
  • 通过演示提供产品更新信息
  • 通过演示推销式演示来说服人们与你的团队合作。
  • 制作出色的演示稿并出色演示是一个非常重要的技能。做好演示的一些技巧：
    • 将演示时间控制在 15 分钟内
    • 永远传达且只传达一个信息
      • 只有一个关键信息
    • 讲故事，代入感
      • 将创意与个人生活联系起来
      • 让观众跟着你的节奏走
      • 提供一个人人都能理解的具体例子
      • 描述你将要解决的问题，要求清晰
      • 描述你的解决方案如何提升用户的生活品质，用户放在第一位
    • 制作“综述单页”重点演示用户体验
      • 你想要讨论的东西是什么？
      • 机会
      • 提供的解决方案
      • 成本和实施时间表
      • 重点演示用户体验
    • 极度专注倾听
      • 把重要的利益相关者的反馈记下来
      • 提前了解谁是关键的利益相关者将使你聚焦在最重要的反馈上。
      • 如果对重要利益相关者的话尚不理解，必须趁现在问清楚。
    • 更多演示技巧：
      • 如果一页 PPT 上不只一幅图加一句话，请把要点信息放到标题里。
      • 不要担心留白
      • 不要使用红色来代表除危险或糟糕外的任何其他意思。

第 11 章 胜在决策

软件是决策的物质载体，产品的骨架取决于团队的决策。软件的复杂性决定了他是团队共建的产物，也是团队决策的反应。绝大多数冲突是沟通不畅造成的，使用角色模型来使交流模型变得客观。

推迟到下一次交付：

将不属于 MVP （原文翻译最小化可行特性，Minimum viable product，最简可行产品）的功能推迟到下一次交付。

谈判

你不是老板，因此依靠谈判快速达成共识是通往成功的必经之路，团队成员体验到参与感与发言权。

决策指导原则：让决策理由透明，团队参与决策的途径透明。

一些调查发现，团队中女性比例越高，小组的集体 IQ 就越高，研究认为女性将更多协作技能带入团队中，而非大男子主义，他们能促使共识的产生。

三种帮你从陷入谈判中回归正轨：

• 聚焦与促进
• 先寻求理解，在寻求被理解
• 如果你已经有了倾向性的判断，不妨先说出来，让后让其他人继续发表观点。

第 12 章 胜在从容

在交付中如何管理精力：先做哪些只有你能做的事情，合理分配每个既定任务的时间以及不要在意事情没有全部做完。

管理你的精力，而不是时间。

第 13 章 再次启航

文中参考书：

《爱他们还是失去他们》：谈论了如何留住最好的员工并让他们发挥出最大的能力，并提供一些好的想法和技巧。

参考：

[1]. 百度百科 - 项目管理办公室

[2]. 维基百科 - 软件工程

[3]. 维基百科 - 计算机科学

[4]. 维基百科 - 敏捷软件开发

[5]. 华为心声社区 - 全面提升软件工程能力与实践，打造可信的高质量产品

[6]. 百度百科 - SWOT 分析法

[7].知乎 - 产品设计方法和工具：人物角色 persona

[8].知乎 - UI、UE和UX三者之间的区别

[9].知乎 - 爱因斯坦名言（来源无考证）

[10].维基百科 - 最简可行产品

2021 年 5 月 30 日购买，2021 年 6 月 10 日读完，2021 年 7 月 24 日完成除笔记外的内容，11 月 5 日完成其余部分。