注：此文为笔者在阅读硅谷产品集团创始人/前eBay高级副总裁Marty Cagan的《启示录》之后写下的结合自身工作与文章的一些读书笔记。
前言
此前也读过苏杰写的《人人都是产品经理》和《淘宝十年产品事》等一些书籍，也许是当时从业经历尚浅，只能读到其中的两三成浅层内容。在从业2年以后，在kindle上读到了这本让我爱不释手的《启示录》，在找了好几家电商之后，终于买到了这本纸质书，实在是因为他解答了我在做一名产品经理的时候太多的困惑。在实际工作中，与我同龄的上司带我探索产品的工作方法和奥义，而在这本书，则是一位资深的、优秀的产品经理带我去了解他所定义的产品经理。
这本书当中，我首先最想谈的是第二十六章《合理运用敏捷方法》。在我毕业以后工作的第一家公司（某知名电商），在我成为产品经理之后跟随的第一位leader，恰好也是eBay的前技术经理，到国内之后担任技术总监，他也时常提到敏捷开发。然而我其实并不能清楚地定义出什么是敏捷开发，在工作的零碎片段中对敏捷开发的大体印象就是“小步快跑，快速迭代”？就是当我们需要完成一个功能的开发时，只需要做到能够验证想法的程度即可，不必尽善尽美，当时的我以为敏捷只是与开发密切相关，于产品而言只需要有概念即可。后来换了一家公司（某知名互联网），合作的是一位有经验的项目管理，在项目中会时常提到敏捷开发，那时我以为敏捷开发是项目管理当中的一个概念。但是直到我拜读了《启示录》以后，才明白到敏捷于产品经理而言也相当重要，并且渗透到产品工作的方方面面，对于产品开发项目而言是一个伟大而重要的概念。
作者在此章提到了产品软件领域使用敏捷方法的诀窍。产品软件（product software）是相对于定制软件（custom software）的概念，区别在于软件本身以什么为发展的核心。产品软件即以产品自身的市场需求、使用这款软件的大多数人的需求而定义需求和软件发展计划，产品经理的任务就是发掘大多数人的需求，常见于2C的产品；而定制软件则是以出资做这款软件的人的需求为主，出资方的意志代替了广大用户的意志，而产品经理面向的用户则变成了出资方，常见于2B的产品。
回归正题，作者所说的这十个在软件产品领域使用敏捷方法的诀窍如下（不适用于定制软件）。
1. 产品经理即产品负责人（product owner），他代表了客户的需求，因而需要与产品开发团队保持密切的联系，协助督促开发进程，及时解决出现的问题。
2. 使用敏捷方法绝不等于省略产品规划。
3. 产品经理和设计师的工作进度应该比开发团队领先一两个迭代周期，确保你们有足够时间攻克难题。
4. 尽量把产品设计工作拆分成独立的部分，分而治之，但也不能拆的太细——好比设计建筑不能一次只设计一个房间。
5. 产品经理的主要任务是定义有价值、可用的产品原型和用户故事（user story），作为开发的基础。
6. 让开发人员自主划分迭代周期。
7. 产品经理和交互设计师必须出席每天的晨会。
8. 除非达到了产品经理的要求，否则不要轻易发布新版本。
9. 在每次迭代完成后，产品经理应该向团队展示产品现状，以及下次迭代的产品原型，让大家看到工作成果，同时加深大家对产品的理解，增强团队对这种开发方式的信心。
10. 在团队内展开敏捷培训。
现在主要是想要围绕作者提到的这某些点，结合我自身的经历来谈谈，主要也是做一个自我的对照和总结。
1. 产品经理即产品负责人（product owner），他代表了客户的需求，因而需要与产品开发团队保持密切的联系，协助督促开发进程，及时解决出现的问题。
作者提到的第一点是最为关键，也是最为理想的情况。然而现实是从我毕业工作到现在，产品经理和产品负责人以及权责基本上没有出现过对等的情况，主要情况有两种：第一，产品经理与产品负责人并非同一人，与实际产品和开发团队关系并不密切；第二就是作者在第二章提到的，产品营销人员和产品经理的一些工作范围交叉。
第一种情况，主要是出现在一些年轻的产品经理身上。刚进入第一家公司的时候，因缘际会成为了产品经理。当时在一个内部小创新团队，团队leader是技术总监，而我就成为了团队唯一的产品。总监是团队的owner，项目的目标人物基本以他为原型，所以我们的需求主要来源于他。此时回头再看，其实当时的团队就有点像定制软件，完全围绕客户而不是用户进行开发，那么我其实就只是一个“制作产品文档”的产品专员，客户认为怎么样才是对的我们就如何做，但是是不是符合用户，没有没有足够量的数据去验证（当然这又涉及到项目冷启动的学问了），因此不得而知。在开发的实际过程中，owner忙于其他工作，并无太多精力投入到实际产品的细节打磨当中。最后，可想而知项目并没有得到很好的发展。这种情况对于初生产品经理会相对痛苦，由于缺乏经验，可能作出的判断有偏差，并且没有数据和经验支撑证明自己的想法，因此不断地需要向上级请示。特别当你上司是一个对细节很在意的人，那么你做的产品细节一旦不符合他的想法，你的需求就必须推翻重做。
可笑的是，你的设计和开发人员面对这种需求变更的时候，会问一句，“你不才是产品经理吗？”如果你没有办法阻止和PK掉不合理的需求变更的话，结果就是我们会丧失下游的工作伙伴对我们的信任。因此我们应该学会的是两点，第一点是如何管理好需求的变更，这其中也涉及到一些项目管理的节奏和方法；第二是如何管理你的上司，如何让你的上司信任你和放权给你。
第二点是作者在第二章用了长篇大论进行论述的问题，产品营销人员和产品经理的工作交集主要有三种误区。
1- 由市场营销人员定义产品；
2- 两人分担定义产品的工作；
3- 一人兼任两项工作
笔者现在也深陷这个问题的漩涡之中，正好看到作者对这个问题的一些看法，在此我也简单说下。笔者现在的工作主要是偏向营销类的产品，目前的工作基本是处于第二种情况，两人分担定义产品的工作。主要问题在于大家并没有清楚认识到彼此的工作职责应该是什么。
产品经理负责详细定义待开发的产品；产品营销人员负责向外界宣传和推广产品。
即使负责是一款营销类的产品，如常见的营销H5，也应该“为每款产品指派一名专职的产品经理”，将产品需求和用户体验设计相结合。产品营销人员定义的产品，很容易忽略用户体验的环节。
每个项目的目标是明确的、突出的，但是评估产品成功与否的指标却非只是项目目标是否达成。而产品营销人员很容易只为了项目目标而去定义产品，忽略了产品生命周期应该关注的一些健康的指标，产品经理则不然。产品经理的任务就是打磨产品细节与体验，并且与交互设计师交集较多，因此在思维方式本身会关注比较多在产品本身；而产品营销人员的精力除了在产品本身以外，还得关注产品的营销、渠道、推广成本等等，因此对产品本身的关注度肯定不如产品经理。这也是作者最后一点说的，当一个人兼任两项工作的时候，第一是会有精力方面的问题；第二点就是并非每个人都能有能力在产品营销和产品管理方面均具有突出才能的。
2. 使用敏捷方法绝不等于省略产品规划。
在产品之间或者产品研发之间的讨论中，许多人常常会听到一句话，“先简单做吧”。这句话，引起了许多人的误解，敏捷开发就是边做边看？这其实是有具体的使用场景的一句话。
我能想到的场景有如下一些
- 已有中长期产品规划，讨论的需求细节属于整个产品的非核心部分；
- 产品本身对于此需求细节有经验把握，认为此细节并不会为目标带来太大数据、体验的提升；
- 此需求细节不影响整体效果，可灰度收集数据再作细化；
因此并非使用敏捷方法则是省略产品规划，相反的，是对产品规划了然于心，明白哪些是核心，哪些细节不追求完美也无伤大雅。正如作者所说“只不过在敏捷环境里，规划周期应该适度缩短，反复迭代，采用轻量级的机会评估方法替代冗长的市场需求文档”。
此外还想提到一点。对于已经相对成型的客户端产品来说，功能点的搭建一般会比较零碎，因此零碎的功能需求比较适合小步迭代。一来是鉴于客户端的特性，最好是保证了主体功能完整以后，快速上线灰度收集用户数据，看用户对此功能的反应是好是坏，若是反映良好再迭代细化。这样既可以减少试错成本，也可以坚定和增强产品研发的信心。二来则是顾及用户对于新版本的感受，慢慢过渡会比一下子给用户一个可能无法适应的新版本来的要好。
对于相对完整的一次营销活动，例如H5来说，则需要相对完整的规划。营销活动一般是一次性产品，用户使用过一次（指活动完结）后则没有保留的价值了。因此营销活动的产品规划必须是最完整最细致，不能有一丝漏洞。但是对于营销活动而言，敏捷则是在保证活动主流程完整的情况下，对于非核心部分的适当舍弃，当数据表现符合预期时，再迭代固化成可用的插件或模型。
3. 产品经理和设计师的工作进度应该比开发团队领先一两个迭代周期，确保你们有足够时间攻克难题。
一个项目总体说来可分为几个阶段。
“需求期 - 研发期 - 测试期 - 灰度期 - 运营期”
在研发期之前，产品经理和交互设计师就必须交付一份完整的和达成统一的文档。交互设计师与产品经理的关系最为密切，分工也会略有重合。交互设计师侧重界面本身的合理性、逻辑性，是表现层面和用户感知层面的的组织者，交付成果给到UI进行设计，为研发期储备原材料；而产品经理除了考虑用户感受层面的逻辑以外，还需要考虑项目数据目标、前后台数据交互可行性、项目时间安排等等。由于产品经理在产生需求文档的时候，更多考虑逻辑和项目目标，因此需要交互设计师帮助纠正一些给用户感知到的信息，使得流程更加顺畅，信息传达到位。两者意见达成一致以后，就交付到给视觉设计师进行表达，并且需要一定时间进行三人的意见统一。项目越大，产品经理、交互设计师、视觉设计师需要花费协调的时间就越多。而研发资源总是稀缺，因此交付到研发手上的需求必须是清楚的、完整的，一来是提高研发的效率，二来则是使得需求上游人员思考清楚产品需求细节与规划，减少需求返工带来的人力浪费。
其他部分在书中均有叙述，我也无太多想要说明的，在此就不展开赘述了。最后想要提到的一点就是注意向团队展示项目成果增强信心以及展开敏捷培训。在实际参与项目的经历当中，发现许多声称使用敏捷开发的团队，除了项目经理以外，并无太多人真正明白敏捷开发的含义。而使用此种开发方法的团队若是对敏捷开发的真正含义无法理解，则容易产生内耗。即大家无法朝着同一个目标，走同一条路，花费大量时间在讨价还价上，无法达到默契合作的境界。如此不但浪费开发时间，也会影响大家对项目的信心。因此展开敏捷培训以及展示敏捷项目成果，能够有效解决这些问题。
