人人都是产品经理
作者: 来源: 文字大小:[大][中][小]
已经收到了苏杰的赠书了，第一感觉就相当好，特别是书的排版，字体字号，图的选择，内容的可读性都比较好。看到到要写一本书确实需要很大的精力，时间和投入。对于这次的读书笔记，我准备是读到哪里写到哪里，在读的过程中也做一些思考，帮助理清自己的一些思路。
本书的定位相当好，做产品讲定位，写书也需要先考虑定位。本书不是一本
产品管理的系统化，理论化的教科书，而是一本结合作者实践的心得总结。本书给1-3岁的
产品经理，实际上给所有的产品经理应该都有借鉴，只是借鉴多少罢了。
从目录看，本书2-5章看上去散，实际完全围绕了产品生命周期的主线。需求，项目，团队正是我们说的解决做什么，如何做的问题。第5章很重要，讲到了战略层面和
产品规划层面，一般的产品管理书会放到最前面来讲，而该书这种安排相当合理。如果连需求管理，
项目管理这些都没有做好，很难马上站到产品和战略的高度来看待问题。理解市场，细分市场，战略规划和路标规划，理论容易实际做起来却很困难。
产品经理关注三方面内容，用户究竟要什么？我如何把用户要的东西做出来？做出来的产品如何好卖？第一个内容关注到产品需求管理和产品设计，第二个内容关注到产品规划，产品研发和项目管理，第三个内容关注到产品运营和市场管理。从现在产品经理发展趋势来看，1和3的作用远远大于2。现在的产品经理在这三方面往往会有所侧重，当时必须有这三方面的意识。
产品经理的切入，从需求，项目管理，产品设计等都是可以的。不论是从哪个方面接入都要求对
产品开发周期全流程相当熟悉，不能有明细的知识缺陷。从产品设计切入最怕的就是空中楼阁，不考虑可实现性，产品理念无法落地；从项目管理切入的又容易犯闭门造车的问题。
入行一年关注需求，入行两年关注项目和团队，入行三年关注战略和修养。正好是全书的章节结构，所以全书本身就是一个产品经理的逐渐成长史。再回顾下我个人的成长史，前三年做软件开发，需求，架构；后三年做专职的IT项目管理，后三年做产品总工。到了产品经理阶段重点补充的就是市场管理，产品规划，组合项目管理，运营意识方面的内容，但是前面6年的工作到现在仍然感觉是很重要的基础阶段。
第一章，最后给出的全书结构图很清晰，清楚的表达了需求，项目，团队，战略之间的关联关系，体现了全书的金字塔结构。后面给出的产品经理生态系统的图示也很形象。再简单总结下就是产品经理自我修养是本，战略是道，其它是方法，工具和技术。离开了本和道不可能是一个成功的产品经理。
第二章，首先看一个需求的奋斗史这个图，包括用户研究，需求采集，需求分析，需求筛选，需求管理五个部分的内容，后面五个章节对五个部分内容展开描述，思路相当清楚。需求的三大阶段往往会对应不同的需求呈现方式，在需求采集阶段是原始需求，在需求分析阶段是用户需求或产品需求(结构化和条目化)，在需求开发阶段是软件需求。在需求分析阶段往往涉及到需求组合分析，优先级排序和筛选。
需求从用户中来，到用户中去，理解需求是产品经理最重要的特质。需求的本质就是问题，而问题的本质是理想和现实之间的差距。满足需求就是在解决问题。而解决问题我们必须考虑问题的缘起是什么？究竟解决谁的问题？老问题解决是否会带来新问题？问题是治标还是治本？问题背后的本质是什么？理解需求一方面是要熟悉业务，更重要的一方面则是透过现象看本质的需求挖掘能力。
对于用户和客户，用户是使用产品的人，客户是购买产品的人，有时候往往既是用户又是客户。而对于产品经理既要关注用户的需求，也要关注客户的需求。在软件项目里面我们往往不这么谈，而更多的谈法是产品必须要能够满足企业的决策层，管理层，执行层不同层面对软件系统的需求。很多时候决策了购买产品往往只是艰苦的开始。
我们无法满足所有用户的需求。试图满足所有用户的需求是一场灾难，他会让产品变成一个臃肿不堪，谁都不满意的四不像。这里考虑两个方面的细分，一个是产品的细分，包括产品组合，产品和子产品；一个是垂直领域的细分，包括行业和特殊用户群等。做产品最重要的仍然是在为客户创造价值的同时盈利，因此满足用户哪些需求要和我们的商业目标匹配，而商业目标+功能需求的分解对应到具体的VE
价值工程。
书中谈到用户研究方法分为定性和定量。定性研究可以找出原因，偏向于理解；而定量研究可以发现现象，偏向于证实。定性和定量必须结合。第一轮，听用户定性的说，确定产品方向，具体做什么？第二轮，听用户定量的说，确定需求优先级；第三轮，看用户定性的做，要先做的是哪几个需求；第四轮，看用户定量的做，根据产品使用情况不断改进产品。
需求采集常用的方法仍然是用户访谈和调查问卷。而实际上很多时候确实是用户访谈在前面，通过用户访谈收集原始需求，通过对原始需求的了解有针对性的来设计调查问卷，通过调查问卷数据的分析来确定优先级。需求采集最建议的方法还是单张需求卡片，书里面有具体的模板可以参考，也可以进一步简化为敏捷方法中的User-Story Card，要注意到需求采集中最核心的仍然是业务场景，角色，行为，业务数据四个内容。
需求分析是从用户提出的需求出发，找到用户内心真正的渴望，再转化为产品需求的过程。书里面谈到需求分析是一个分-总-分的过程。其中分是分解，分解的核心个人认为是粗粒度需求的条目化描述；总，即抽象和提炼，这个和核心的是共性需求的提取和挖掘。需求分析的重点就是实现用户需求到产品需求的转化，一个用户需求可能需要多个产品需求来实现，或者一个产品需求本身通过通用化和产品化考虑又可以实现多个用户需求。产品需求本身的重点就在于产品化的思路，寻找共性和通用解决方案，而不是增加特定用户太多的个性化需求定制。
在需求分析中可以对条目化的需求增加需求说属于的业务组件，模块，工作量，优先级，难易度等分析和评估。在Scrum方法论中需求条目化管理和项目管理过程紧密结合，从ProductBacklog到SprintBacklog，需求到计划，需求到实现的过程跟踪等。
对于需求筛选，2.4章节的内容稍微脱节，谈需求筛选的内容比较少。前面讲的业务目标，需求商业价值部分内容可以移动到后面的战略和产品规划层面来谈。需求筛选涉及到两个大的层面，一个层面的产品定位和市场细分；一个是确定优先级，指导后续产品的迭代版本开发计划。
再回来看下需求生命周期管理和产品生命周期管理之间的关系。需求有几个大的对象之间的转化从原始需求->市场需求->产品需求->软件需求。在这个里面产品需求对象很多时候可以合并进入到市场需求或软件需求中。需求最开始的产生是原始需求，后面经过初步分析转化为市场需求或用户需求，根据用户需求形成产品规划和产品版本计划；产品版本计划对应具体的项目咨询，在项目版本中将用户需求转化为软件需求。几个大的需求对象之间往往存在较复杂的对应关系，特别是大型产品或产品线的开发，需求全生命周期管理重点正是需求状态管理和需求跟踪(需求关联关系)。大型企业的需求管理工作相当复杂，很多原始需求还跨了产品线，特别是里面的需求拆分，拆分后的对应。需求最终的闭环验证都不是一两句话能够说清楚的。
对于产品管理和开发中需求管理的一些最佳实践和做法可以参考
IPD集成产品开发中的OR需求管理部分内容；对于项目管理中的软件需求分析和开发，再次强烈推荐徐锋老师的《软件需求最佳实践》这本书；对于需求采集，需求分析开发和项目管理的紧密集成，建议阅读SCRUM敏捷方法论中的需求收集和管理方法；对于需求如何做到以用户为中心，建议阅读Alan Cooper的《软件观念革命-交互设计精髓》。对于需求采集和用户访谈，再次建议补充业务
流程管理和业务建模方面的知识，推荐IBM的业务建模型CBM和SOMA相关的方法论。
对于产品经理和项目经理关注点的不同，我原来已经做过比较，具体如下：产品经理是做正确的事情。需要的是确定该做什么产品；而项目经理是正确的做事情，在已经确定了产品和项目的目标后，按目标把项目做成功。产品经理关注的是产品生命周期，关注集成产品研发IPD等，关注组合项目管理和多项目管理；项目经理关注项目生命周期，关注软件工程和CMMI过程和改进等，关注PMBOK的单项目管理知识体系。
在这里我讲下原来做产品经理的时候两者的衔接点，首先是每年的10月就会启动下一年的产品规划工作，在这里涉及到大量用户的访谈，原始需求的收集和整理，优先级的排序，需求的条目化。其次是对业界同类产品发展趋势的分析和研究，业界关于该产品标准做法的一些研究以确保模型本身的标准和完整性。整个产品规划里面涉及到很多内容，其中最重要的就是路标规划，年度规划，季度规划。路标规划一般是3-5年中长期规划，年度规划一般是当年计划，季度规划则会细化到具体的子产品和产品版本。一个大产品会涉及到多个子产品，当时我负责的大产品下面涉及到10个左右的子产品，4个专职化的项目经理，因此产品规划需要确定去下一年每个子产品要做哪些产品版本，每个产品版本要实现哪些用户需求，具体的人力资源投入估算等。这里就涉及到比较多的组合规划，动态资源管理，组合项目管理，需求管理方面的内容了。
这个产品规划完成后，每个季度会对产品规划重新拿出来进行评审，对产品规划的内容进行调整。评审确认后产品版本对应到具体的项目版本，因此走产品计划审批到最终的项目立项。项目立项后一个新项目正式启动，所有的管理和跟踪工作基本就转移到了项目经理，后面产品经理的工作基本就是关键点的跟踪。而我们说的关键点主要是项目主计划评审，需求评审，关键技术评审，可用性测试和评估，产品版本发布评审。所以产品经理不仅仅关注产品生命周期，也关注项目生命周期，只是关注的点和粒度不同。
在这里对于一个60多个人的大团队，本身就是一个大产品，IT项目经理专职化是很多公司无法做到的，这块做到了感觉还是收益很大。四个子团队都有专职的IT项目经理，项目团队成员的资源动态调配就很关键的，而能够调配的关键又在于使用同一个业务架构和技术平台。公司本身有专门做技术平台的人，因此后面关键的一件事情就是业务和技术的横向贯通性。到后面把业务架构和技术架构从项目中抽离出来，形成了业务架构和技术架构的跨子产品，保证架构的完整性。
产品管理不是产品经理一个人的事情，而应该形成产品管理团队。在这里我们的产品管理团队就包括产品经理，项目经理，业务架构和技术架构。产品管理工作重点是产品经理+项目经理+开发经理；而产品设计的工作重点则在于产品经理+业务架构+技术架构。这也是我谈的产品管理铁三角和产品设计铁三角。
项目启动会议很重要，最好是能够要求高层领导参加，重点是确定资源，明确项目经理的职权。对于项目组织结构项目一般都采用强矩阵或者完全项目型，要弱化职能部门对人员的控制，体现项目经理的权力，特别是考核权和物质激励分配权。
项目经理要做到心中有树，项目经理最重要的意识仍然是目标意识，项目的本质就是在保证品质的前提下，在时间要求，人财物花费，项目范围三点上做平衡。WBS模板很重要，做的产品或项目越多，应该形成自己的产品或项目WBS模板。在CMMI下这些会提升到组织级过程资产，组织会根据项目类型的不同定义不同的项目生命周期，制定不同的WBS模板。
用户需求是从特定用户角度出发，而产品需求则是从推出通用化的产品出发，这是两者最重要的区别。不考虑产品需求，不从产品通用性出发会导致项目最终产品只能满足特定用户需求，完全是一单子买卖，首先是导致产品营销范围狭隘，同时也不利于推出通用化的产品，形成企业的核心竞争力。用户需求需要向产品需求转换，转换的重点就是考虑用户需求的共性，考虑如何使产品每具备一个功能特性就能够满足更多的用户需求。用户需求收集->分析和归类->该需求的根源->抽取共性->形成产品需求，通过这种方式形成的产品需求有利于后期产品的通用化。我们在软件产品开发过程中使用一些框架，公用组件，分层等各种架构要素目的正是为了满足产品的可扩展性和配置性，而不是单单满足当前的用户需求，虽然这样在软件开发过程中可能会花更多的工作量，但投入的成本是完全值得的。
产品需求和软件需求可合并，也可以分开为两个文档。分开的时候产品需求关注产品化，关注业务模块和业务单元，只需要说明清楚业务单元的关键功能特点就可以了。同时要注意产品需求里面一定要包括非功能性需求的描述，产品需求是实现用户需求朝产品化转化的一个重点，产品需求往往应该由业务架构来完成，技术架构来落地，偏向于业务建模。到了软件需求重点则是用例分析和建模，在这里原来有一本书讲软件需求阶段也分了重要的三个层面，即需求的细化过程，首先是用例分析，然后是界面建模，然后是事件建模和交互细节补充。软件需求阶段一定要完成界面原型开发，这是这么多年来我们实践RUP方法的一个重点心得。
对于用例建模和软件需求文档，这是我们原来实践CMMI做的比较好的一个过程域。从产品经理到项目团队的每一个成员都足够重视需求。我们的敏捷是体现在了大的产品迭代开发，已经变成了3-5周的短周期版本。而在每一个项目版本里面我们的需求变更基本是完全可控的，投入在12-15个人左右4-6周的项目在整个项目生命周期需求变更很少。
对于用例文档我们后面也做了适当改进，因为发现了重要的问题即我们说的没有经过业务建模直接过渡到了单个用例实现的细节。所以后面改进的一个重点是增加了业务场景和业务背景的描述，增加了该业务场景下业务流程或活动的描述。在此总描述的情况下再展开到单个用例实现的描述，方面设计和开发人员理解业务。
对于书里面谈山寨级项目管理，很实践，也确实我们在项目管理里面比较关注的内容。包括文档，流程和敏捷，但是这个分法三者不在一个维度。敏捷里面包括了文档，流程，沟通，软件工程的一些内容等。对于文档一定要注意首先要分为两个大类，一类是流程模板类的，一类是实际的项目执行类的。流程模板类的包括了规范标注，指导书，培训教材，检查单，模板等一系列内容。CMMI这种建立组织级过程资产库的做法还是值得借鉴。
对于评审涉及到产品生命周期和项目生命周期，产品生命周期中最重要的是阶段决策和技术评审，确定产品是否有市场，产品是否能够做出来。而项目生命周期中的评审就比较多，一般是计划，需求，设计，代码，测试相关工件都需要评审。书里面谈到的商业评审本身就是一个重要决策，需要在产品生命周期的关键阶段都做，确定项目是否要继续，项目投多少资源等。
对于敏捷项目管理，我原来涉及到这方面的文章还是比较多。重点仍然是短周期迭代，持续集成，需求条目化，进度可视化，高效沟通协作。在SCRUM里面可以看到一个重点就是ProductBacklog和SprintBaclog两级关系，而且关键就是这个文档的一跟到底来实现所有的进度状态跟踪和可视化管理。无论发现什么，我们必须理解并完全相信：每个人在其当时说处情况下，在其能力范围内，做了最大的努力。
第四章开始谈我的产品，我的团队。从标题来看涉及产品和团队两部分重要的内容，读完该章最大的感觉还是主线不是特别清晰，个人感觉还是产品和团队不适合放到一起来谈，虽然两者结合的很紧密。对于产品关注的是产品什么周期上的关键点，或者讲是在项目生命周期外产品外延的部分，从这个角度可以看到包括产品规划，产品设计，产品运营，产品决策等关键的内容。对于项目生命周期的内容可以在项目一章谈，这样产品和项目的边界和外延根据清楚。对于团队我们关注的内容包括团队的组建，团队的构成，团队角色和分工，团队的矩阵结构，团队会议，团队沟通机制，团队建设，团队激励等方面的内容。
•产品之大，产品外延完全超过了软件或项目本身。一个是产品生命周期前期增加了需求管理，产品规划，产品设计相关内容；一个是产品本身融入了商业特性，包括前期市场分析调研和后期的产品运营，真正了体现了市场驱动研发。
•设计之大，在传统产品研发中可以看到工业设计很早就进行了分离，在软件行业随着用户体验越来越重视，设计团队开始分离。从最初的美工转化到易用性，视觉设计，交互设计，行为研究等更加细化的分工团队。产品成功包括三个方面的要素，真实存在的需求+好的产品设计+好的产品运营。
•团队之大，产品开发跨越多个职能部门，为了打破职能部门壁垒，必须形成跨职能部门的协作团队。其次，团队不断演进，岗位角色和分工逐步细化，真正体现专业的人做专业的事情。设计开发的分离，开发和管理的分离，
研发团队和支撑团队分离，都可以看到一个大型的产品团队的管理和协作是相当不容易的。
产品规划师，书里面提到的从概念设计到信息架构提法还是不错的。产品规划师重点就是产品构思，而产品规划师本身也需要多构思进一步细化，即我们说的产品架构+业务架构。如果对于软件项目，产品规划师需要进行业务建模并给出产品总体架构图，关键技术图，如果从这个层面对产品规划师要求是很高的。
产品设计师，现在最关心的还是视觉设计和交互设计，一个静态一个动态，而两者又都需要基于用户行为研究进行正确的设计决策。注意交互设计和敏捷开发本身不矛盾，个人理解交互设计中随时都要用敏捷的实现，比如原型的设计是迭代的过程，要逐步求精，交互设计的迭代和实际开发的迭代可以很好的并行。
产品运营师，这个完全可以作为一个很大的话题来谈了。不过书里面介绍的个人博客运营实例还是有些思路可以借鉴，比如对数据的分析，运营前的分析和策划等。产品运营设计到市场，营销，用户心理，数据分析，定价策略，产品推广，品牌等一系列问题。能够做好这项工作确实很不容易。
产品经理是管理者，偏技术管理路线，重点是管事，目标驱动；职能部门领导也是管理者，重点是管人，人员的发展，培训，企业文化，Q12等。类似带兵打仗时候将军和政委之间的关系。如果在弱矩阵下产品经理没有资源控制能力很难管事和管人，因此推荐仍然是强矩阵模式。产品经理管人的重点偏团队管理和团队建设，团队精神的塑造，团队成员产品意识的提升等。
第五章的内容偏战略层面，实际涉及到理解市场，细分市场，产品和需求的组合分析，产品版本规划等一系列内容，这块可以以产品规划为主线展开来看。一个完整的产品规划至少应该包括如下内容：
•理解市场：本产品的业界标准，业界成熟的产品和产品发展情况
•理解市场：产品未来的发展趋势分析
•细分市场：客户的原始需求或市场需求
•细分市场：SWOT竞争分析(如何找寻到产品核心竞争力)
•细分市场：目标市场的确定，产品关键功能确定
•产品规划：产品发展目标和发展愿景
•产品规划：产品的路标规划(3-5年)，产品的年度规划
•产品规划：需求组合分析，产品组合规划(主产品，子产品，产品组合)
•版本规划：根据市场推进策略，如何迭代规划版本转到项目开发过程
•技术规划：产品平台，产品关键技术
•财务规划：产品的盈利模式分析，产品的定价策略，产品开发预算和
成本管理