产品经理的第一课：认知

2018-01-22 15:38:00

本文重点不在业务，在产品知识体系。业务非常重要，却只是产品知识体系中的一块。作为互联网产品经理，如何保证业务需求到IT软件形态产品的保质保量一次性可靠的落地，知识体系非常重要。全文约1万字，自己留出时间阅读。

入行前5年，特别爱写东西，或许是因为对于行业的新鲜感、也或许是出于求知或职场压力的驱动，5年时间竟然积累下一个3G大的纯文档知识库。如今越写越少、却越写越长。不可否认的是，写作确实是进行深入思考的一种最佳方式，不写出来，自己都不知道自己对于某种事物的理解到何种程度。在写作中，不断促进思考，不断促进改进，在思考与改进中就不断进步。当然，写作不是空想，而是基于自己实际工作的积累与总结。
写作欲望的产生，往往有一个激发点。基于某个事物产生了某种想法，便可以抓住并进一步思考，不要单纯的停留在脑子里。
从初入职场进入传统行业、到进入互联网行业，从不适应到逐步的进入佳境，有些经历，或许对于职场新人来说，有些帮助。
因此，在此强调一句，如果你选择继续往下看，请以坚持独立思考的态度，大胆怀疑小心求证，笔者一家之言不代表行业标准。
这是一个商业世界，商业的本质就是基于人的需求进行供给以获利。而人却是一种极其复杂的情绪化动物，充满善恶贪嗔痴喜怒哀乐怨。精明的商人便会利用人的种种人性与欲望进行商业化产品设计以获利——以此引出对于当下火热的知识付费的一些看法——不是对花钱买知识这件事、而是所看到的一些误解的看法。
正如知识管理专家田志刚先生在他的文章中《如何真正搞定一个领域的知识》所说：

“在互联网上有了许多知识资源，大部分内容都唾手可得，然后许多人就认为自己听了一下、看了一眼，然后就掌握了！其实是你想多了。别人家的知识，跟你的知识是两码事。“

付费购买或加入各种知识圈，有助于你了解行业的新动态、了解新思想新方向，但是方向性的东西往往是很粗的，要成为某个领域的专家，非得下苦功夫不可。没有一种知识是可轻而易举获得的。只有靠自己去大量阅读，深刻思考，然后再加上实践验证，这个过程不断循环转化，你才可能获得真知。以及笔者自身的成长经历，对此深为认同，下文会有专门介绍。
以此引出职业的话题。
如今BAT对国内职场人、尤其是互联网行业的人吸引程度，不亚于10年前欧美外资企业对于职场人的吸引程度，HR每天收简历都收到手软。作为早期从外企进入到互联网行业的我来说，有一点却尤其有感悟和体会：对于职业生涯的规划。
伴随着外企在国内的风行，也刮起了关于职业生涯的很多观念。而伴随着互联网的成长，却是普遍的浮躁与焦虑，变化太快了，往往一个新的词汇还没消化却又产生了另一个新的词汇，职场人好像都在忙于追热点、炒概念，却忽视了对事物本质更深入的理解，这是不正常的。变化快不是问题，而是炒作与赌博的性质是问题，尤其是年轻人深受其害。新概念需要被认真思考，理解本质，而非单纯的炒作概念。
作为个体的职业人士，必须更加关注个人职业生涯的规划与发展，而“专业”是基础。让自己在某个行业里成为专家、依靠终身学习的动力，持续的更新知识以满足行业发展的需要才是根本。所谓中年危机，大抵是因为自身知识体系无法满足行业发展的需求而被行业淘汰，人才与年龄无关，所谓70后与90后无法在一起工作的文章，都是炒作。

一、关于专业

专业是一个很抽象的词汇。有一个普遍性适用于各行业的关于专业的模型。

三个维度看：
工作理念（价值观）：
工作理念（价值观）具有行业特征，不同行业对于从业者的工作理念是不一样的，但也都包含三个方面—工作动力的驱动来源、工作过程的模式选择、工作结果的认知。理念会影响你工作动力的产生、责任感成就感、执行过程、工作结果等方方面面。理念无形、却展现于各个方面。
方法与工具：
无新方法与新工具的发明，超级工程根本无法实施。掌握行业内的先进方法与工具的应用，对于成为行业专家是必不可少的一个环节。
领域知识：
对于细分行业的业务知识的掌握，是最终价值实现的必要保障，是你与团队成员沟通与合作的基础。

二、关于产品经理

建立对一个事物的认知先从它的定义开始。理解定义是建立认知的基础，定义即基础。
互联网是一本巨大的百科全书，有疑问互联网搜索一下，但要能区分真伪。产品经理（Product Manager）是企业中专门负责产品管理的职位，产品经理负责市场调查并根据用户的需求，确定开发何种产品，选择何种技术、商业模式等。并推动相应产品的开发组织，他还要根据产品的生命周期，协调研发、营销、运营等，确定和组织实施相应的产品策略，以及其他一系列相关的产品管理活动。
基于定义，也就能明了产品经理所需要掌握的专业技能。以下也仅为笔者基于自己的知识体系所提炼，请坚持独立思考、大胆怀疑小心求证的态度阅读。具体的方法及工具，笔者基于行业通用标准学习吸收，没有[原创方法论]，行业通用规范均为诸多前辈苦心沉淀积累并实践验证，学习吸收灵活应用即可。

关于理念，只简单介绍：
用户：是需求的来源，是产品发展最原始的驱动。
对于用户的正确认知，是做产品的第一步与基础。一旦产生偏差，后果确实极其严重。产品的用户是谁、你的产品该如何去更好的服务你的用户，这些都会极大的影响到你的产品最终落地的形态与效果。
笔者曾经极其严肃的火爆过一位产品经理，因Ta这句话“我们怎么做业务就怎么用，不需要业务的建议“。
与用户理念相对的，就是功能思维。功能思维就是关注功能的实现而忽视用户体验，早期软件工程盛行的时候这种思维尤其盛行，随着商业环境的变化迫使企业必须关注用户，否则只会死亡。
迭代：是过程模式的选择，产品发展过程的选择。
直接影响对于业务价值最终兑现的效果。过程模式，也在逐步的迭代中完善，从早期软件产品研发的瀑布模式、到RUP统一过程模式、到SCRUM敏捷模式，过程模式的选择，依据不同的产品需求，灵活选择应用，但在互联网行业敏捷迭代模式已经成为主流，从目前应用状况看能最佳匹配行业的变化。
3）商业价值：是最终结果的兑现。
企业存在的核心目标为盈利，所有的产品结果基本都为更好的促进这个目标的达成。
关于方法/工具，学习应用行业标准规范并吸收消化灵活运用即可，不需要自己去总结和创造一套“我的方法论“，既四不像也不具有普遍应用性。基于软件产品的特性，结合互联网行业的特性，笔者提炼以下6大方法域。

2.1软件产品通用方法与工具

不能只谈业务不谈基本功。在专业性强的领域成为专家，意味的是在该行业建立了体系性的知识。从业务需求到IT软件形态产品的落地，是一个极其复杂的过程，无专业的方法体系与工具的应用不足以保质保量高效的一次性落地。接一两个小需求可能用不到，如果要从0到1让你去搭建一套完整全流程的复杂IT产品呢？无体系不足以言。
作为互联网产品经理，必须掌握透彻软件工程常用分析方法体系以及常用工具。具体在面向对象的系统分析方法和面向过程的系统分析方法。面向对象与面向过程，是两种不同的方法体系，两派之间的争论不多说，但就笔者的观点：只要有助于解决问题，都可以灵活应用。
整体而言，还是以面向对象为主、面向过程为辅。下图为面向对象方法体系与面向过程方法体系的主要方法。而支持这些方法的应用的常用工具就是微软的Visio。也就是说：这些方法和工具必须深刻理解其内涵、并能灵活应用，主要就表现在：理解这些方法及工具的应用场景，在分析什么的时候该用什么方法最佳。拒绝机械化的学习方法，而要去理解方法的应用场景，以及把方法整合成体系。

上图中，绿色底色标注的就是常用的方法，要求能深刻掌握，并且依据严格标准高效绘制，每种图形均有其严格的绘制规范，这就是标准化与专业度。其它了解即可。
下文重点介绍面向对象的方法体系。并在[3.3文档写作与产出规范] 章节会参入介绍面向过程的方法体系的应用。
什么叫面向对象？概念性问题不多纠结，以免为概念困扰，关键去理解其内涵与本质。有兴趣了解的同学可以去读谭云杰老师的《大象》这本书，算是国内目前对面向对象方法体系阐述的最完整与体系的。以及徐峰老师的《软件需求最佳实践》这本书，了解完整的软件过程。
这里引入[场景]的概念。面向对象方法体系的核心就在对于场景的分析，以及如何应用每一个具体的方法、去对应分析场景中的哪些或哪个要素。省去对于概念的解释，而直入主题。也尽量采用大白话的方式，去解释这些生硬的方法，因为理解是学习掌握的第一步。
场景分为业务场景和系统场景。两者之间的区别，一个在于对纯业务的分析、一个在对人在系统上完成某个任务的分析，后者基于前者衍生，前者粒度大后者粒度小。分析的方法是通用的，只是分析指向不一样。
一个场景包含四个维度：人、事、物、规则。我们去分析一个场景，也就是运用具体的方法展开对于这四个维度的分析。

人：即场景中的参与者，可以是现实的人、也可以是拟人；
事：即人做的事，事不能单独存在，一定是人产生的；
物：即人在做事时用到的物，物是名词，是动作的指向对象，例如吃苹果，苹果即为物；物是业务实体的核心来源，也是信息与交互设计中信息的核心来源；
规则：人做事所要遵循的规则、或者物本身的存在的规则；

场景的四大维度中，人是核心，所有的一切都是围绕着人展开，所以，面向对象的方法体系本质来说就是以人为中心的方法体系。
自己想想，你做任何一件事，是否均包含这四个维度？结合实际生活的案例去理解。
对应上文说的必须掌握的方法：
用例：对于场景的全面分析，包含对于场景的人、事、物、规则的全方位分析；包含用例图与用例规约说明；用例规约说明是核心，主要包含这8个方面的分析。不要去纠结概念，理解本质与内涵。

具体应用：用例提供了一种完整的、结构化的思考的模型，当你要去分析一个场景的时候，你该从哪几个方面去完整的思考 ——思考这个场景是谁主动发起的、发生的前提条件、以及什么时机会触发，以及发生后的正常流程是什么，异常流程是什么，以及场景的运行规则、运行中所涉及的物，以及运行结束后会影响到其它什么。
具体，自己可以去随便拿生活中的某件事，应用上述模式进行仿照分析，以便理解。
活动图：对于场景中人、事，以及做事的规则的分析；
范例，仅供参考图例，业务不精确：

绘制规范，规范促进对于场景的思考：

具体应用：绘制前需要对场景中的各个参与者做详细的调研、梳理、整理，然后形成规范的图形模型。笔者应用活动图用来绘制业务流程图、系统交互流程图、以及其它各种流程图。一幅图可以鸟瞰整体业务的运行状况，规范标准也便于其它人理解。
状态图：对于场景中的物的分析，分析物的状态流转；
范例，仅供参考图例，业务不精确：

表的形式整理 [状态——操作/条件——转化状态]：

具体应用：状态图的核心在于，一个实体的全生命周期的状态流转，从最初的原始状态，到因为什么动作或条件，导致向另外一个状态变迁。我们研究状态的核心在于：除了有多少状态外，还在于研究对应状态下的操作及条件；
实体关系图(类图)：也是对于场景的物的另外一个维度的分析，分析物与物之间的关系，以及实体属性的规则；
图形更抽象，理解几点，不多介绍：

数量关系：是1对1，还是1对多，还是多对多？…
语义关系：关联关系、依赖关系、扩展关系、包含关系、聚合关系、组合关系…
实体属性提取与规则定义：实体属性是开发数据库建表的核心参考，也是信息与交互设计环节中信息的核心来源；对于属性提取的完整性，直接影响从业务到系统功能落地的完整性与可靠性；
规则分析：规则是一种特殊的存在，它依托于人事物，却非常核心；单独拎出来介绍；

具体应用：业务规则依托于业务流程；内禀性规则依托于实体属性；交互规则依托于操作；先理解，也不多介绍；
人的分析：通过用户画像了解，人的基础属性、交互属性、业务属性、社交属性；这里不多说了；不同业务环境下对于人的了解是不一样的；会影响很多非功能性需求的考虑；
这就是为什么必须掌握这几种图像方法的原因。
2.2信息与交互设计
限于篇幅，这个章节只介绍一些核心模型与核心方法。多玩产品，多思考，为什么人家要这么做？是否可优化？产品经理是不靠谱的，但是人人都是用户是可以的，基于体验提出几个问题，基本都可以做得到。
推荐几本书：
《用户体验要素：以用户为中心的Web设计》，Jesse James Garrett著，书虽然很早，但是核心理念却非常好；
《交互设计指南》Dan Saffer著，也挺早的，但很值得学习；
其他限于篇幅，暂略。
信息与交互设计的专业程度，直接影响的是你产品的是否好用，从而可以放大或者缩小产品最终商业价值的兑现。
两个模型：
1、笔者自己总结的模型：

2、《用户体验要素》一书中所提的五层模型：

2.3文档写作与产出规范
做一个优秀的IT产品经理，写作是你最基础的能力。但沟通的两种媒介：[文字]与[语言]，你都需要精通。
2.3.1五个方面全方位理解产品写作及产品文档

2.3.2写作的目的
你写作产出的文档，是与协作对象之间进行沟通和传递需求的载体，语言是对产出的必要性的再解读。
产品经理一般沟通与协作对象，见下图。当你的沟通与协作对象很多的时候，光靠语言来传递信息是非常容易导致信息丢失的，所以文字是非常必要的。

2.3.3写作的原则

金字塔原理：
整体内容的组织需遵循金字塔原理，形成明晰的由总到分的内容类目结构。
文不如表,表不如图：
在内容的组织上，当文字很多时需要考虑将大段的文字进行表格格式化，如果能用图形表达的，最好采用图形化表达；
如SA结构化分析方法中的数据字典、决策树、决策表，也是常用来对逻辑分析的图形化或表格化的呈现；等等
如OOA面向对象的分析方法中的活动图、状态图，也是常用来对业务进行分析的图形化的呈现；等等
结构化语言：多用1、2、3这种结构化组织形式；以及基于数据字典的结构话描述；
对于产品的文档来说，可以更进一步结构化的常用模式是【如果…则…】的if else的结构化语句，这也是SA结构化分析方法中，结构化语句的经典模式。
2.3.4写作的工具
产品的写作产出，最常见的就是PRD （Product Requirement Document），即产品需求说明书。PRD的文档模板有很多种，其实模板类型倒不是关键的，不管哪种模板类型，最终目的都为服务于文档的目的—传递需求。但就所见到的一般软件公司的文档来看，生涩难懂、阅读体验差，动辄几十上百页、第一眼看上去-哇-好规范，但规范不是目的，规范的目的也是为了传递好需求，不能达成这个目的，再规范也是个纯粹的看物。
就写作PRD的工具来说，其实个人很推荐Axure，Axure不单纯只是一个原型设计工具，作为从5.5版本一直用到目前的8.5版本的骨灰级用户、也用过其它各类工具、模板产出PRD来看，Axure写作最佳、传递需求最佳。
第一步：编制完成的金字塔形的内容结构。Axure的Sitemap功能。这一点非常关键，因为编制好后，Axure导出规范的结构化文档就是基于此。在Sitemap中，可以将各类流程图等等都放在里面。
第二步：单个产品功能需求的描述。这里举个后台系统的功能需求描述的格式化方法及基于Axure的写作。一般后台功能分为【增加、查询、列表数据、操作】四大类，快速逆向简单的写了个例子，仅供参考，非笔者业务：
1、【新增】实例介绍，一般针对新增的功能需求描述可以结构化为：
1）字段规则；
2）操作校验；

2、【查询】实例介绍，一般针对查询的功能需求描述可以结构化为：
1）查询条件；
2）查询操作；

3、【列表数据、操作】实例介绍，一般针对列表数据的功能需求描述可以结构化为：
列表数据的排序规则；
列表数据的分页规则；
列表数据的数据权限；
列表数据的初始化呈现；
列表数据的呈现字段及其规则；
状态及操作（涉及状态及操作，后面会有专文分析介绍，太核心太重要！！）；

Axure中，我们直接基于其所提供的【Widget Interactions and Notes】中的【Notes】功能就好，非常实用。在【Shape Footnote and Name】中定义好字段名称，然后在【Description】中基于上述规则去描述即可。
没必要这么写？写多了？自己反思去。写文档从来不会耗费时间，关键是：你对于业务理解的完整性、是否透彻。
2.3.5写作的产出
在产品经理的产出中，最常见的为BRD与PRD。
BRD用来定义业务需求，即需求的业务背景、需求的原因、期望达成的目的、以及所需资源投入与产出的分析、基于需求来源的业务领域的业务模型（如业务用例、业务流程图、实体状态图等等层面的）的分析。
而PRD则用来定义需求转化为功能后的功能需求，一般包括系统用例、功能树、角色与权限定义表、用户界面与交互规则，但也不必刻板。如上节针对【培训需求单列表】的功能需求描述，实际整合了系统用例与用户界面与交互规则，让功能需求的描述更容易被各协作对象理解、传递。
当你在Axure中写完后，导出Html或标准模板的Word文档，会非常便捷于规范。个人更喜欢使用直接使用【Generate HTML Files】，直接导出网页，在阅览的时候更方便，Word因为文档过长时浏览非常不便，只作为存档用。
具体操作，自己去实践吧，不累赘。

【Generate Specification】导出Word，注意下：在Widget Tables中只要选择[Footnote、Name、Description]三项即可，导出的类似数据字典的字段表格不至于太多东西。多试几次你就可以上手，越用越偏爱。
2.3.6写作的实例
实例已经参夹在上文，自己去琢磨。多去写，写着写着，你的思维就丰盈与深刻了。

2.4项目管理

项目管理知识体系具有普遍性应用特征，不管什么行业、无论什么做什么事，都可以应用项目管理，从建筑行业、到律师行业、软件行业……甚至可以这么说，如果你能掌握项目管理知识体系，你做事、无论在专业度的体现上、还是在效率的提升上，都具有显著的效果。
PMP作为国际项目管理的职业资格认证，其所定义的项目管理知识体系具有绝对的标准意义。也就是说，兄弟、别自己去总结什么[我的项目管理经验]了、学标准化专业知识体系即可。从来不是专业知识没用、而是你学不会、本质上来说、不是PMP没用、而是人没用。
本文先介绍一个通俗易懂的项目管理概念，以便于简化PMP专业性、理论性过强导致的理解性障碍。确实，专业技能的掌握从来都不是容易掌握的、尤其是对于应用性专业知识来说，你不仅要掌握理论，更要在实际工作中应用。但是，即便再难、你想入行、就必须去学习、而且是深入的学习。
PMP项目管理8大领域

所谓「事事皆项目」。项目管理也可以广泛的应用到你的日程生活中，管理自己的事项。举个简单的例子：去超市买菜。

你计划要购买白菜1斤、牛肉2斤、胡萝卜1斤——这是范围，功能范围基于需求产生和定义；
你计划要在1个小时内完成买菜——这是时间；
你计划购买菜的预算为50元以内——这是成本预算；

买回的菜质量如何？你跟你家人以及卖菜的人之间如何沟通的？你去还是你和谁去买？采购时的询价、选择哪家买、达成交易及签订合同？
限于篇幅，也暂略。学习后灵活应用是根本。

2.5数据分析

限于篇幅，数据的介绍也简单扼要。
数据分为用户行为数据、业务结果数据。
行为数据是过程性的，主要是用户在网站的交互行为产生的数据，对于分析用户行为路径、改善产品流程及用户体验有重要参考意义。举个简单例子，仅供参考：

用户在网站的操作交互行为，都会有时间先后顺序，依据用户操作交互的时间先后，便可形成对用户访问路径的画像，从而进一步分析流程与体验的改进点。自己思考。
而结果数据，是业务运行后的数据，用以分析业务目标的达成状况。对业务数据进行各个维度的分析，观察业务运行结果对业务目标的达成状况，为过程的改进提供策略制定的决策依据。
可视化是数据分析的一种重要方法，运用各种可视化的图形模型，对数据进行直观的呈现，例如看占比的饼图、看趋势的折线图、看对比的柱形图等等。基于具体业务数据，进行图形模型的选择，是很重要的。例如：

2.6产品运营

限于篇幅，产品运用也简单扼要的介绍。产品运用的目的，在于获取更多用户、或者获取更高收益。为了达成目的，从而衍生出各种运营模式与策略，例如用户运营、内容运营、活动运营等，例如产品的交叉销售、增值产品售卖、针对不同生命周期客户的不同精准营销策略等等。

三、业务领域

对于业务领域知识的学习和掌握是非常核心的。换句话说，对于业务不熟，就会导致在进行产品设计时，因为对于业务场景理解的漏失，导致最终系统功能落地时对应功能模块的缺失，从而影响产品最终落地的完整性与可靠性。
但是，对于业务知识的积累非一日之功，要善于运用上述方法与工具去梳理业务、对业务进行领域建模，并持续的维护与完善。经常跟业务方沟通，了解业务的运行状况，是非常必要的，这也是你产品发展的核心驱动。
你能构建你所处领域的业务模型吗？领域模型的搭建，就是基于对领域中人事物规则的全面分析，运用对应的分析方法进行模型的梳理与产出，再持续的维护与完善。
好的产品经理，都是善于观察世界的，理解领域知识，一定要细致，大的流程都容易理解，关键是能否深入，简单的说，能否去理解每个业务字段的业务含义与规则。