《启示录》读书笔记（二）

有个方法解决以上冲突，采用流水线方式并行开发产品。一旦1.0版本的产品进入执行阶段，就开始规划2.0版本的产品。一旦前一个版本进入开发阶段，就把热情投入到下个阶段。需要注意的是，不要让这种做法干扰正在执行的项目。下次公司高管要求新加功能，也不会影响正在开发的产品，因为你已经在构思新版本，可以把新功能纳入其中。

探索产品的进度可控吗？

定义产品是创造性的工作，更像是一门艺术而不是科学。

首先，产品经理应该探索是否有用户需要的产品，也就是说，要寻找市场，让用户验证你的构思。

其次，产品经理要探索能够解决问题的产品方案。也就是说，它必须是有价值的，有用的，可行的。要设计解决方案，请用户和开发团队来验证。

第13章产品原则

什么是产品原则？

产品原则是对团队信仰和价值观的总结，用来指导产品团队做出正确的决策和取舍。

制定产品原则的目的：决定什么重要、什么不重要，哪些原则是根本的、战略性的，哪些是临时的、战术性的。

制定产品原则容易出现的两个错误：

1、原则过于空洞，失去了指导作用；

2、把设计原则误当做产品原则。比如，为用户提供清晰的导航路径（方便用户完成下一步操作）属于常见的设计原则，不是产品原则

作产品决策过程中，如何解决团队中的意见冲突？

在作产品决策之前，应该先确定决策要解决什么问题，让大家在以下几个要点达成共识：

究竟要解决什么问题？
要为哪类人物角色解决这个问题？
产品要达到什么目标？
每项目标的优先级是什么？

每当团队出现严重意见分歧时，并非是大家对事实的认定有争议，而是对目标的优先级有不同理解。务必认真分析产品目标的优先级（从最重要到最不重要排序），让团队达成共识。

制定决策的过程和依据必须完全透明，不要让人觉得你只凭直觉判断。务必告诉大家决策的依据和理由，清楚地展示每一个决策环节。

第14章产品评审团

成立产品评审团是制定决策的最好解决途径

组织产品评审团的难点

既要为高管制定产品决策、监督产品流程提供透明的信息，又要避免高管插手干预产品团队的具体工作，比如亲手参与产品设计。

产品评审团的工作目标

目的是决定产品战略方向，从宏观上监督公司产品的研发流程，合理地配置资源。

产品评审团的成员组成

由公司各个部门的管理者组成，一般是首席执行官、产品管理总监、用户体验设计总监、市场总监、开发总监、网站运营总监、客户服务总监。要确保每个关键部门都有代表参加评审团，但最好把人数控制在十人以内。

产品评审团的职责

产品评审团的职责是监督产品研发流程，制定关键决策：

评审产品战略和产品路线图，选择值得投入精力的产品，请产品经理开始评估产品机会。
根据评估产品机会的结果，决定是否开始定义产品的解决方案。
评估产品原型、用户测试结果、成本估算明细，决定是否开始开发产品。
评审最终产品、产品品质、发布计划、社会效应，决定是否发布产品。

注意事项

根据公司规模大小设定一个或多个产品评审团。
产品评审团不负责对产品细节的更新或者修正。
产品评审团不负责具体的产品设计工作。
产品解决方案未形成，不可凭直觉估算产品成本，最多只能估计大致的项目规模；在开发产品之前，应该仔细估算开发时间跟成本，让公司上下做好准备。
尽量避免产品评审团讨论具体的执行策略。
产品评审团的开会频率取决于具体产品的进度。
产品评审团还应该回顾、分析产品上市后的表现，反思之前的决策是否明智，今后应该如何调整。
每次评审会议，应该由产品经理向产品评审团汇报产品的进展情况。

何时估算项目成本？

开始研发产品之前，应该先评估产品机会（参考11章）。评估产品机会的目的是看产品创意宣称要解决的问题是否有价值。确认产品机会有价值，粗略估算的成本也可以接受，管理层才能允许项目组着手定义产品解决方案。理想情况下，产品解决方案应该包含可供用户测试的高保真原型。

在定义解决方案的过程中，产品经理和交互设计师需要一位开发人员的协助来评估不同解决方案的成本。产品经理和交互设计师根据评估结果进一步调整解决方案，待完整的产品说明文档形成后，即可根据文档字节生成详细、可靠的成本估算结果。

总结就是分两个阶段进行成本估算：在评估产品机会时做粗略估算；根据最终的产品说明文档做详细估算。

第15章特约用户

在项目开始阶段确认几位积极、活跃、乐于分享的用户。要求是他们在产品的目标用户中具有一定的影响力。

成为特约用户的好处：

参与构思产品和创意，解决他们手头的问题
提前试用产品，越早使用产品意味着越早解决麻烦
提前试用产品可以显著降低用户的各种成本

产品经理的收获：

聚拢一批积极用户
提供调研便利
可以定期组织特约小组进行讨论
特约用户第一时间试用、测试产品，迅速反馈意见
如果特约用户满意产品的表现，会乐意公开推荐产品

第16章市场调研

常用的市场调研工具和方法

用户调查：做用户调查时需要注意两点：第一，结合具体背景，仔细设置调查问卷的问题；第二，调查结果是为获得解决方案提供了一条途径，但不是解决方案本身。
产品使用分析：使用实用工具分析用户访问网站的行为。
数据挖掘：统计用户账户信息...
拜访用户：成本高、耗时长
人物角色：定义使用产品过程中用户的不同角色
可用性测试：观察用户使用现有产品的反应，收集反馈意见，了解他们的真实想法
同款产品分析：找出竞争对手的优势，学习对手的成功经验

合理地利用市场调研工具和方案可以回答以下为关键问题：

谁是目标用户
用户会怎样使用产品
用户能想明白怎样使用产品吗？障碍在哪里？
用户为什么选用你的产品？
用户喜欢产品的特点有哪些？
用户希望如何改进产品，增加哪些功能？

市场调研的局限性

市场调研结果可以作为研发产品的依据和参考，但不能决定产品研发的方向。

探索（定义）产品的过程要回答如下问题：

采用什么技术更好解决产品要解决的问题？
设计什么样的用户体验？

第17章产品人物角色

产品经理应该参与所有产品的可用性测试，抓住一切机会与用户交流，深入了解目标用户。

产品人物角色主要用途：

人物角色可以用来筛选重要的产品功能，有助于决定谁是目标用户。面面俱到的产品往往一无是处
使用人物角色可以避免把自己的需求当做用户需求
使用人物角色有助于对用户类型的优先级进行排序，识别需要重点考虑用户体验的地方
有了人物角色，可以方便向团队描述产品的目标用户是谁，他们怎样使用产品，他们关心产品的哪些方面
和产品原则一样，人物角色可以帮助团队成员达成共识。

使用产品人物角色需要注意的地方：

每次应该针对每一类角色的用户，把产品的优势发挥到极致
与用户面对面交流是必不可少的环节
建议邀请多样化的用户参与产品原型测试

第18章重新定义产品说明文档

传统的产品说明文档弊端：

没有确定关键细节
不解决实际困难，必须等到开发阶段这些问题才能得到解决
产品文档不断变更、造成项目延期，士气低落

理想的产品说明文档应该满足以下要求：

完整描述用户体验，不只是用户需求，还包括交互设计和视觉设计
准确描述软件的行为
必须以某种直观的方式把产品信息和产品行为告诉所有人
产品说明文档应该可以修改
撰写产品说明文档的过程中会出现很多衍生物，比如按优先级排列的需求列表、线框图、实体模型，但应该有一个主体来代表产品，避免混淆不清，版本错乱。

高保真产品原型可以满足以上所有要求，“高保真”的含义是原型应该真实地体现用户体验，最突出的优势是可以用于测试。

第19章用户体验设计与实现

先定义用户体验再动手开发

把用户体验和软件设计放在一起进行，这是行不通的，原因如下：

一旦产品进入开发阶段，再修改设计思路是非常困难的，而且越往后修改的成本越高。
用户体验设计要保证产品同时具备可用性和价值，任务很重。
验证设计思路必须使用高保真原型。
产品开发可陈过多次迭代，用户体验设计却不能拆分。设计师必须全面地、连贯地看待用户体验，考虑以往的用户习惯。
用户体验设计不一定是最费时间的工作，但至少要一两周的时间

用户体验设计应该在软件开发前完成，敏捷方法里有个“第零次迭代（sprint zero）”的概念：产品经理和用户体验设计师利用这段时间先完成产品设计工作，然后交由开发人员开始迭代开发。这需要跟更详细地定义待开发任务（backlog），但团队工作会更愉快，产品也会更好。

注意：尽管提倡需求调研和产品设计都要在软件开发前完成，在此期间至少邀请一位软件开发人员检查设计工作，他可以协助你评估设计的可行性和成本。我们的目标是打造有价值的、可用的、可行的产品。

第20章基本产品

不再试图定义最终产品，转而定义只满足基本要求（价值、可用性、可行性）的产品，简称基本产品。采用新的产品设计方式：

产品经理和设计师合作设计产品的高保真原型，只具备实现商业目标的基本功能要求，以及良好的用户体验和吸引力，把开发时间减到最少。
邀请一个开发人员（比如架构师或主程序员）参与设计原型。请他减产原型，估算各种功能的直接成本和简介成本，指出设计上的误区，并分析、评估尚不确定是否可行的功能。
请真实的用户验证（测试）产品原型。

设计产品时一定要考虑哪些功能是最重要的，争取设计出只满足基本要求的、不可删减的产品。

第21章产品验证

产品经理在向团队提供最终的产品说明文档之前，需要进行以下三项重要的验证：

可行性测试。邀请架构师和开发人员深度参与技术调研，寻找可行的方案。
可用性测试。一定要请真实的用户来试用可用性原型，从目标用户那里可以得到宝贵的反馈信息。注意：为了测试可用性，即使要模拟复杂的后台处理过程也是值得的，关键是要评估用户体验的实际效果。
价值测试。重在观察用户是否喜欢这些功能，是否满意功能的具体实现方式，用户是否觉得你的产品有用，是否愿意购买。

第22章原型测试

自己寻找测试者

邀请特约用户参加测试（参见第15章）
如果是企业级产品，同类产品的展销会是寻找目标用户的好去处
可以在分类信息网站上发布广告，征集测试者
如果是大众产品，可以邀请自己的亲戚好友参加测试。注意，测试者不能局限于亲友
从营销团队获取电子邮件列表
参考主流公司的做法，通过公司网站征集志愿者
建议较大的公司定期开展原型测试活动
到用户聚集的地方，寻找测试者，送些小礼物表示谢意
邀请测试者上门参加测试，尤其是出于商业目的，应该补偿测试者为此损失的时间
在测试前一天致电测试者，跟测试者再次确认测试时间

准备测试需要注意的事项

事先定好测试测试内容，着重测试主要项目：用户大部分时间执行的操作。
只有一次机会了解测试者未接触产品原型之前是如何解决产品要解决的问题，不让用户看测试者看产品原型，看他们会怎么做。
观察测试者是否能从产品原型看出产品是要解决什么问题，哪些地方最能吸引他们。
测试者完成测试任务，了解产品用户后，通过聊天进一步收集信息。
为每个问题的答案打分，记录每个阶段产品原型的表现。
不必等到完成原型完成后再测试，可以先测试主要项目

如何准备测试环境

可以准备专业的测试实验室，没有也没有关系，在咖啡厅开展也是可以的
用户的办公室也是上佳的测试场所
测试也可以通过远程工具实现，但是面对面测试不可替代
产品经理应该亲自参加每次原型测试，尽可能与用户接触，观察他们使用原型的反应
产品经理也可以参加原型测试
理想情况下，应该安排一个人主持测试，另外一个人记录

进行原型测试的实际测试技巧

测试前不宜与测试者交谈过多，避免透露产品线索导致用户不能说出他们对产品的第一印象。
跟测试对象说明这只是产品原型，是产品的初步创意，不是正式产品。说出真实的看法，不必碍于情面有所保留。
测试时，尽量让测试者保持平和的情绪，避免测试者进入吹毛求疵的状态。多观察用户的操作，少听他们的抱怨。
测试时不要给测试者提示

第23章改进现有产品

开发新产品的第一步是要明确目标，一个产品如何改善，也应该是从各指标的维度分析如何优化改进。

改进产品不是简单地满足个别用户的需求，也不能对用户调查的结果照单全收。能提高指标的功能才是你关注的重点。你应该找准方向，分析关键指标，有针对性地改进产品。

第24章平滑部署

避免更新产品导致用户反感

通常用户是不喜欢变化的，虽然他们希望产品更完善、功能更丰富，但前提是不改变已有的使用习惯，大多数人不愿意花时间学习、适应新的使用方式。

为了将版本更新带来的负面影响降到最低，有以下建议：

通过公告、邮件通知的方式提前通知用户，但很多用户没时间或者没兴趣阅读这些内容，这个方法的效果有限
加倍做好测试工作，避免更新版本带来的问题，例如可靠性问题、扩展性问题、性能问题
如果新版本会影响大规模的用户，应该采取并行部署或者增量部署的方式来降低风险

平滑部署的方式如下：

发布两个并行的版本，邀请有兴趣的用户试用新版本，如果新版本运行正常，大部分用户适应新版本之后，再将新版本设置为默认版本。将旧版本保留一段时间，公示旧版本保留的最后期限。
区域性增强部署，先在某个区域部署新版本，逐步扩大范围
增量部署，将更新项分割成几个较小的部分逐步发布。

无论采取哪种方式，关键要全面考虑更新可能带来的“副作用”，为用户提供便利，方便他们在空闲时适应变化，同时尽可能降低新版本带来的负面影响。不要轻易试探用户的耐心，让好感变成反感。

第25章快速响应阶段

产品发布后的几天至一周内，所有的项目成员应该留出时间作为快速响应阶段。这个阶段的主要工作是快速响应、处理产品发布后的用户反馈意见。

一旦问题反馈回来，产品团队应该至少每天召开一次简短会议，讨论问题的轻重缓急，确定最佳解决方案。

第26章合理运用敏捷方法

使用敏捷方法的十大诀窍

注意：这些诀窍只适用于产品软件团队，不适用于定制软件团队

1）产品经理即是产品负责人（product owner）,他代表了客户的需求，因而需要与产品开发团队保持密切的联系，协助督促开发进程，及时解决出现的问题。

2）使用敏捷方法绝不等于省略产品规划。产品经理要明白产品的方向和目标，设定衡量产品成功与否的标准。只不过在敏捷环境里，规划周期应该适度缩短。

3）产品经理和设计师应该比开发团队领先一两个迭代周期，确保你们有足够的时间攻克难题。

4）尽量把产品设计工作拆成独立的部分（目标是设计出符合基本要求的产品，参见第20章），分而治之。

5）产品经理的主要任务是定义有价值、可用的产品原型和用户故事（user story）,作为开发的基础。

用产品原型和用户故事代替产品需求文档和产品和产品功能说明文档有三个优势：

可以请用户测试
强迫产品经理全面认真地思考问题
向开发团队明确地描述每次迭代周期需要完成的任务

6）让开发人员自主划分迭代周期。

7）产品经理和交互设计师必须出席每天的晨会。

8）除非达到了产品经理的要求，否则不要轻易发布新版本。

9）每次迭代完成后，产品经理应该向团队展示产品现状，以及下次迭代的产品原型，让大家看到工作成果。

10）在团队内开展敏捷培训。只有每位团队成员都真正理解敏捷方法，你才能把工作重心放在执行上，否则敏捷方法就只能停留在教条式的理论层面。

第27章合理运用瀑布式开发方法

瀑布式开发方法的基本原则

采用阶段开发，软件开发过程事先分成固定的几个阶段
采用阶段式评审，每个阶段结束后，对该阶段提交的成果进行评审，评审通过之后此案呢过进入下一阶段

瀑布式开发方法经久不衰的原因

瀑布式开发具有可预测性，因而深受管理层欢迎。只要能准确理解需求和技术，而且需求不再变更，开发团队能够为大规模的、复杂的项目制定精确的开发计划。
在每个阶段都会提交书面材料。有了丰富的文档，在一定程度上能够增强人们对项目的信心。问题在于文档不能像软件一样运行、验证。

瀑布式开发让产品经理头痛的地方

产品验证严重滞后，在投入大量人力和资金之前，软件的可用性无法得到验证。
变更计划代价不菲，发现问题应该尽早解决，从成本上考虑，早改肯定比晚改好。
无法适应快速的市场变化

如果不得不使用瀑布式的开发方法，产品经理应该设法规避以上问题。首要的工作是在探索（定义）产品阶段，制作产品原型，请目标用户试用，确保产品设计是有价值的、可用的、可行的。只有这样此案呢过提高产品成功的几率，同时节约开发填对的时间和成本。

第28章创业型公司的产品经理

提高产品的成功率，节约创业成本：创业初期只设三个职位：产品经理、交互设计师和原型开发人员。这个团队可快速展开产品设计（详细可见第18章），迭代修改。主要关注以下两个关键点：

创建体现用户体验的高保真原型
邀请真实的目标用户验证产品原型

确定产品原型后，再招聘程序员进行开发。有了产品原型（代替产品说明文档），开发人员可以更直观、高效地领会产品设计和开发要求，这将大大缩短开发时间。

第29章大公司如何创新

20%法则：鼓励普通员工自己尝试各种想法，发挥大家的主观能动性，让员工打心底愿意倾注更多的激情和汗水去创新。

臭鼬工程：大公司里，普通员工很难凭空获得允许从事创新研究。如果你能拿出阶段性成果来，获得许可会容易得多。

主动观察：仔细观察用户使用公司产品或者同类产品的一举一动，留心他们欣喜和失望的表情。记住，创新不是发现新问题，而是用新方法解决已有问题。

改善用户体验：不仅要提高产品的工作效率，更要剔除多余的功能，明白哪些功能是用户必需的，哪些是设计和开发带来的衍生物。

收购小公司：不仅可以引入新技术，而且可以引入创新性人才，为公司注入新鲜血液。

第30章在大公司施展拳脚

首先，大公司都遵循一条潜规则——尽量避免风险。随着公司业务规模变大，公司会不可避免的变得保守，因为大公司承担的风险更大，如果出现问题，损失也比小公司惨重。

其次，多数大公司都采取矩阵式的管理方法，核心部门（比如设计部门、开发部门、测试部门、运维部门、市场部门）是共享资源，产品经理要确保争取到足够资源才能研发出产品。

理解这两点之后，以下将介绍在大公司施展拳脚的方法：

了解公司制定决策的方式。如果公司制定决策的方式不符合你的习惯，不要老想着改变大家来适应自己，要学着融入其中。
建立人脉网络。向大家介绍你手头的工作，不要等到有事才去找人家。主动帮助他人，积累人脉关系。
臭鼬工程（详见29章）。找三五个志趣相投的同事在工作之余做出产品原型，比起枯燥的陈述，生动形象的演示更优吸引力。
自己顶上。在资源不到位的情况下，自己想办法找人帮忙，甚至自己顶上。
有选择地据理力争。不要随便发脾气，与人辩论，要小心措辞，做到对事不对人。你的目标是万和城呢个产品，别为了一场战役输掉整场战争。
会前沟通，形成默契。
合理分配时间。产品经理应该重新检查会议日程，划掉无关紧要的会议。学会充分信任同事，让他们自己拿主意。产品经理应该留下时间完成自己的本职工作，制定产品战略，构思产品路线图，研究产品原型，分析竞争对手。
分享信息。分享信息会让你获得更多朋友跟资源。
向上司借力。如果需要上司出面说服公司高管，你一定要事前做好充分准备，为他提供翔实可靠的资料和信息，用实力取得他的信任，让他放心地当你的说客。
传播你的产品理念。多向同事传播你的产品理念，向大家描绘产品愿景，不要低估了内部宣传潜移默化的作用，让大家不遗余力地支持你。

crush1988

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
《启示录》读书笔记（二）

目录第11章评估产品机会为了评估产品机会，产品经理需要回答的10个问题开发新产品还是维护旧产品第12章产品探索软件项目的两个阶段产品经理必须在执行阶段切换工作重心，不同特质的产品经理在开发阶段应该注意的点探索产品的进度可控吗第11章评估产品机会为了评估产品机会，产品经理需要回答的10个问题：产品要解决什么问题？（产品价值）为谁解决这个问题？（目标市场）成功的机会有多大？（市场规模）怎样判断产品的成功与否？（市场度量或收益指标）有哪些竞争产品？（竞
复制链接

扫一扫