MECE原则产品经理运营知识.docx
《MECE原则产品经理运营知识.docx》由会员分享，可在线阅读，更多相关《MECE原则产品经理运营知识.docx（17页珍藏版）》请在冰点文库上搜索。
MECE原则产品经理运营知识
MECE原则（穷尽与互斥原则）
MECE（MutuallyExclusiveCollectivelyExhaustive）：
对任何复杂事物的组合设计出一个合理的分类法，这个分类法能够穷尽所有的情况，而且各个分类之间不重叠交叉。
这也是信息管理业者最常用的工作技巧之一。
应用领域：
●对数据和信息分类
●对问题归因的分析
MECE作用：
●进行高质量的归因分析和项目计划
●帮助我们制订高质量的计划
●科学地组织和呈现信息（比如建立和维护公司的知识库）
6.2标准作业流程（SOP）
SOP（StandardOperatingProcedure）：
企业中将一些重要的流程标准化，并通过书面的规范固定化的。
SOP的产生有几个主要原因：
一是生产活动变得越来越复杂，企业的产出已经不可能是一个人能够从头到尾干完的了。
分工专业化必然需要更高效率地把作业方法和技能传递给大量的新员工，SOP可以被看作最核心的新人培训资料。
同时，SOP的建立也能够避免人员流动带来的知识流失。
二是因为很多生产活动的安全后果很严重，比如医疗和制药，如果没有按照标准流程来进行控制，是有可能出现人员死亡事件的。
还有一些行业，例如建筑工程等行业如果不能遵循SOP，也容易导致经济损失和工期延误。
分类：
●技术需要型：
大多出现在工矿行业，因为设备、工艺的限制，以及物理化学特性的影响，某些工作必须按照特定的次序和标准进行，否则就会有灾难性后果或者其他质量事故。
●监管需要型：
监管需要型的SOP则着眼于合规的要求，在金融、信息等行业应用比较广泛，比如银行业处理大额汇款的标准作业流程，通常需要额外的复核和审批环节。
对于企业应用设计工作来说，了解SOP的用途和价值能够帮助我们识别出流程控制类应用的本质目标是什么，SOP的内容起到的作用是什么，与之配套的软件流程是怎样与之协调的。
在生产制造管理软件中，SOP是一个内置模块，产线工人通过车间电脑或者移动设备可以直接调用一个既有的SOP，来指导生产活动的每一个步骤。
6.3PDCA循环（戴明环）
PDCA（Plan-Do-Check-Act ）：
计划、执行、核查、行动。
后来为了更好地强调迭代改善的方式，也有人把它修正为PDSA（S代表Study）。
这个理念可以简单概括为企业如果要提升产品的质量，就需要周而复始地执行这个循环。
针对一个复杂和关键的质量问题，我们会展开多个PDCA循环，但是在每一个循环中必须只改变一个参数，同时力求把其他的变量都控制起来，这样每一轮执行（Do）之后，我们才可能知道结果的变化是因为哪一个因素的调整引起的。
如果每一轮都是笼统的改进，那么结果无论是变得更好还是更差，我们都不知道缘由是什么。
比如，在PDCA循环常用的制造工业中，每一轮试生产都可以被看作一个PDCA循环，我们希望能够得到越来越高的良品率。
但是良品率可能受20个因素的影响，我们首先必须列出这些可能的因素，然后根据批判性思维的要求，从最有可能影响结果的因素开始测试，调整它的参数，改变它的工艺方法，然后根据结构来研判这个调整是否是沿着正确的方向的。
一旦找到针对一个因素的有效改善方法，就继续开始下一轮迭代，每轮的目标都是只改进一个参数。
这样，经过数轮的改进，我们可能就掌握了多个因素对结果的影响规律，从而得出量产制造规范。
除了制造流程，解决其他的企业问题也都有类似的要求。
改进者不能急于求成，也不能在改进的过计分析，虽然统计控制的要求听起来非常烦琐和缓慢，但是通常前几个问题的逐个解决就能够将产出明显提升，因为数个10%的优化积累起来的效果是110%的幂次改进。
而且，经过统计控制分析的改进才是持续有效的改进，而不是依靠运气的改进。
今天，在企业运营的很多环节，已经有了信息化辅助的PDCA循环。
例如在营销自动化应用中，A/B测试已经成了一个标准配置，一个E-mail营销活动的内容或者制作的落地页面可以有两个不同的副本，系统负责各自分发50%的流量，然后根据两个版本的效果差异选择那个更好的留下来，再与另外一个版本进行持续的A/B测试。
随着机器学习算法的普及，我们有机会在不远的将来通过自动调参改进应用。
但是今天，限制很多企业有效开展PDCA循环的因素依然是基础信息化。
首先，PDCA循环既是一套方法，也是一种理念。
几乎任何工作都有进行PDCA循环迭代的机会，包括个人的时间管理和绩效改善。
在践行过程中，最重要的步骤其实是第一步的「计划」。
如果缺乏计划，改进将没有明确的对象。
这就是大多数人在重复做一件事情很久以后仍然找不到章法、进步不明显的原因。
与技能类动作的提升不同的是，我们无法通过实时反馈和反复训练来提升工作事务的操作熟练度，进而达到精湛的水平。
工作事务的效果反馈没那么快，很多事情需要数周甚至数月才能看到结果。
此类工作技能的提高依靠的不仅仅是重复，还需要有意识地进行分析对比。
个人如果要想通过PDCA循环理念改进工作成效，首先需要养成做计划和记录的习惯，在动手做这件事情之前先列出计划的方案、期望得到的成效，在进行一段时间之后再去比较结果和期望的差距，然后根据结果决定调整计划中的某些成分，以观后效。
PDCA循环中的计划也可能是「假设」。
也就是说，我怀疑某一个因素是影响质量的主要原因，需要足够多的数据来做验证，如果还没有足够多的数据，那么就开始按照一个标准积累数据，这个积累数据的过程就是「执行」的过程。
例如，某位年轻的科技企业销售主管一直怀疑销售人员的性别会大幅影响销售成果，他认为男性销售的平均业绩要好于女性。
但是，他只有十来个销售人员的六个月的历史销售数据。
显然，依靠这么短时间内的数据、这么少的样本无法得出结论，于是他开始建立销售业绩跟踪表，并定期和销售人员花名册的数据进行分析比较。
做着做着，他可能又觉得销售业绩与销售人员的工作年限有关联，所以，又在花名册数据中加入了「工作年限」这列数据。
一到两年后，通过持续的数据分析，他可能得出了一些结论，指出该团队的销售业绩和性别几乎无关，和工作年限有35%的关联度，但和入职培训时长有70%的关联度。
那么，接下来，我们在招聘和培训中应该着眼于改进哪个因素就十分清楚了。
当然，这位销售主管很可能早就开始改进培训流程，并且开始追寻下一个高相关度的因素了。
对于更大的团队和企业来说，PDCA循环运用起来会更加复杂。
因为PDCA循环的各项动作已经不可能在一个人的完全掌控之下。
计划可能是经理做的，执行会涉及团队的所有成员，检查则可能是由另外一个部门来做的，改进行动又要由原有的和新近加入的团队成员来做。
对于PDCA循环周期比较长的改进项目来说，如果离开了周密的计划、严谨的记录数据的共享和频繁的沟通，PDCA循环就很容易失效，最终不了了之。
在这个过程中，有几个原则值得遵守。
●完整记录：
所有的计划和执行都要留下记录，并且对要记录的内容事先做出约定，甚至要落实到设计好的文档或者信息系统。
能够自动化记录的尽量实现自动化记录。
●透明沟通：
制订计划、执行、反馈结果、推导改进方案，这四个环节都要尽量全体会商，而不是管道传递。
尽力扩大知会范围，而不是一味追求沟通的速度。
●扁平协作：
参与某个PDCA循环的团队人数越少越好，对于过于复杂的改进项目，可以按照专业领域分到更小的团队进行，例如不同团队分别负责材料、工艺和设计。
这个原则也是和透明沟通原则相呼应的——因为是扁平团队，所以可以高效地进行透明沟通。
基于以上提到的这些原则，信息化系统应该能够提供有针对性的帮助。
一个便利、简明而有效的计划数据平台能够帮助我们记录改进工作的方案和实施过程；社交化的沟通和任务管理平台可以帮助团队节省大量的会商时间，又能保持透明度。
如果我们意识到每一项企业任务的改进都是一个PDCA循环，就能知道应该怎样设计一个驱动企业质量改善的协作平台。
6.4检查清单（Checklist）
检查清单产生价值的核心原因是，世界上最不可靠的生产要素是「人」。
只要是人，就会犯错。
在高度紧张的作业环境中，犯错的概率其实非常高。
通过检查清单的交叉确认，可以大幅降低差错率，又不需要付出太高的成本。
6.5工作分解结构（WorkBreakdownStructure,WBS）
我们可以将WBS简单理解为一个任务的树状目录，把复杂项目按照某一个维度逐项分解，主任务可以分解为若干子任务，子任务还可以有自己的子任务。
每个任务带有一些固定的信息，包括任务计划开始时间、完成时间，以及开启这个任务的前提条件是完成哪个任务。
有了这些基本信息，我们就能够计算出这个复杂项目最快需要多长时间来完成。
再进一步，我们也能够识别出那些进度敏感，一旦延误就会让整个项目延误的任务序列，这个序列被称为关键路径（CriticalPath）。
在项目管理领域的WBS有几个必须遵守的原则。
●100%原则：
WBS需要根据项目总范畴包含100%的内外部交付物，每一层分解的子任务也要100%覆盖它的父级任务范畴；也就是说需要在同一个层次上列出所有的子项。
例如，定制软件开发项目必须在第一层级覆盖需求评估、设计、开发、测试和交付5个完整的模块。
●元素互斥：
WBS结构中各个元素是相互独立不交叉的。
例如，在同一个层次上不能同时有「采购盘子」和「采购餐具」两项，如果存在这样的交叉，将会给未来的任务和资源分配带来混乱，工期和成本的估算也不会准确。
●围绕产出计划：
在列举WBS工作包时，要按照期望的产出物计划，而不能只是规划行动事件，因为后者要么是事无巨细地堆叠，要么出现挂一漏万的疏忽。
这是一个比较难以掌握的原则，因为我们本能上都习惯直接拆解工作。
但流程项目的完成都是为了交付一个承诺，这个交付标准决定了我们从第一天开始的所有工作内容。
再比如，为了策划一个婚礼，我们可以按部就班地依据习惯和他人的提醒列出WBS，但是更好的出发点是考虑一个婚礼所要实现的事项：
新人的纪念、家人的感恩、亲友的参与和记忆。
从这三个产出出发，可以更加完整和有目标地列出所有有意义的具体工作。
●要有合理的工作包（workpackage）大小：
项目所细分的工作包并非越小越好，它的合理大小取决于多个因素。
首先，它和项目成员的工作成熟度有关，经验丰富的成员组适合比较大块的工作包，让成员能够发挥自主性来围绕产出设计任务。
过细的工作包会让成员感到被过度管理，而且需要花费过多的时间来更新任务状态。
其次，工作包的大小还和管理沟通模式有关，对于案头协作的行业，按照8～16个小时（也就是1～2天）的体量确定工作包大小可以配合每日或者隔日的会商会议；对于外勤作业比较多的行业，按照更长时间完成的工作包大小可以适应每周会商的节奏。
当然，工作包也不能大到无法进行分工，至少每个工作包都要有明确的负责人；如果是多人负责的一类事务，则必须进一步细分。
复杂项目的WBS规划需要专业人员和经过项目管理训练的人员配合，所以它是一种高价值的知识资产。
比如一个机场或者地铁项目的WBS规划本身就是可以复制到其他同类项目中的。
也有不少咨询公司依靠积累的WBS范例来提供行业咨询服务。
软件行业也在为WBS规划需求进行变革，过去，WBS的规划依靠的是MSProject这样的项目计划软件，现在，在线协同软件已经发展得越来越强大，可以把复杂的项目规划和项目沟通整合在一起。
WBS规划需求也是企业项目管理和协作过程中的焦点问题之一。
基于WBS思想的项目管理又被称为流程项目管理，它有明确的项目开始点和终结点。
但是，企业中还有不少项目并没有这样的特征，它们往往延续很长的时间，周期性地完成一轮轮工作，比如互联网软件产品的迭代开发项目就无法设定明确的起点和终点。
围绕这种特性的项目，企业界又发展出敏捷项目管理的模式。
6.6敏捷项目管理
上面提到的WBS是一个典型的计划驱动的项目管理思想，强调的是边界明确、责任清晰、成本和进度可控。
所以，也有人把这个模式称为「瀑布」模式，计划和执行就像瀑布一样，从上至下，直到落地结束。
到了20世纪90年代，软件行业的效率极客们发现这个模式有很大的弊病。
首先，很多开发项目（尤其是软件产品）的计划过程很难明确边界，因为需要复杂的技能配合；责任清晰也很难在过早的计划阶段落实；更重要的是，一家软件公司的产品是没有开发的终点的，每个产品都希望能够分阶段长期发展下去，即使是一个版本的产品，也没有一个明显的开发结束的点，通常都要伴随长时间的缺陷修复和特性迭代。
甚至在互联网软件时代，还出现了MVP（最小化产品）的概念，极端地提出了一个项目的最早计划只应该覆盖两周到四周的工作时间。
2001年，十几位软件工程师在美国犹他州的一个会议后发布了一个著名的《敏捷软件开发宣言》（简称《敏捷宣言》）。
其中，JeffSutherland成为敏捷项目管理的布道者。
这份宣言非常简明，全文如下。
我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。
由此我们建立了如下价值观：
●个体和互动高于流程和工具
●可用的软件高于详尽的文档
●客户合作高于合同谈判
●响应变化高于遵循计划
●也就是说，尽管右项有其价值，但我们更重视左项的价值。
敏捷模式的原则包括，持续交付有价值的软件来使客户满意、为频繁的变更做好准备、通过高密度的沟通和协作提高开发质量。
如果说敏捷项目也有WBS的影子的话，那就是它强调的尺寸恰好的工作包——需要适合在两到四周内交付成果并开始得到反馈。
工作包的出发点不是具体的事物，而是被称为UserStory的用户需求描述。
用户需求描述的大意是明确一个迭代周期会解决客户的哪些问题，然后到这个周期结束时来检验这些问题解决得怎么样，从而决定下一周期加入哪些新的UserStory，或者继续保持原有用户需求的迭代。
在过去十几年中，敏捷的概念已经走出了软件行业，因为很多企业发现，原来基于瀑布流的周全项目计划内容对于自己公司内部的变革项目来说是不必要的。
企业内部具备足够的动力来面对变更的需要，从而保持灵活性，也让交付的结果更有意义。
一个软件产品的开发是这样的，一个企业内部的质量改善项目也是这样的。
我们可以看出敏捷项目管理结合了PDCA方法和WBS原则的思想核心。
其实，早在软件业推行敏捷项目管理理念之前，生产制造业已经在使用一个与之非常接近的管理工具，被称为「看板」（Kanban）。
20世纪50年代，丰田工程师大野耐一为了解决材料、生产和库存的衔接问题发明了这么一个简单的工具，后来被发展成丰田著名的精益生产和JIT库存生产方法。
软件行业是非常善于学习的行业，所以工程师们本能地将其发展成电子化的工具来服务自己的管理需求。
2011年诞生的SaaS产品Trello是第一个将看板作为产品核心的协作平台。
今天，绝大多数的互联网协作软件都基于这个思想。
过去，企业应用的委托者和开发者习惯基于一个瀑布项目来协作。
事先花费大量的精力来定义需求和讨价还价，一旦项目开始执行后，又缺失了紧密的沟通，通过这种合作模式开发出来的软件质量可想而知。
这也难怪《敏捷宣言》中写道「客户合作高于合同谈判」。
今天，协作工具和模式的演变也推动了软件外包行业的变化。
越来越多的需求者看到了敏捷项目管理的价值，不再将宝押在前期的周密计划上，而是和开发商一起，采用迭代优化的模式来保证开发出来的应用更符合用户的实际需求。
按合同交付变成了持续交付。
敏捷软件开发模式所催生的软件化看板并不限于用在软件开发上。
当改变看板名称后，它可以被应用在企业运营的多个环节。
比如，招聘员工的面试流程就可以基于面试和录用阶段建立看板，在它上面流动的就是候选人记录。
新员工入职，也可以利用一个分日期的看板，直观地呈现一名新员工在加入公司以后的若干时间内需要经历哪些导览、培训和测试步骤。
WBS原则和敏捷（Agile）模式都不是万金油，在不同的项目性质和目标下，不同的思想会占上风。
一个接受NASA委托的航天工程，如果只考虑敏捷，也是要付出巨大的财务和履约风险代价的；一个小型的软件产品公司如果迷信使用甘特图来绘制未来一年的产品开发计划，也是一定会遭遇惨痛损失的。
6.7销售漏斗（SalesPipeline）
接下来要介绍的其他几个管理方法和前面的有所不同，它们在信息化时代之前几乎不存在，它们是通过工具的设计和迭代一步步发展出来的，而且它们与企业的具体运营过程的关系更紧密。
我们从关注度最高的销售漏斗开始。
销售管理方面的应用是企业应用中的热门领域，尤其在国内市场。
要想打造一个有效的销售管理信息化体系，离不开清晰的销售管理理念和方法，否则，能够做的最多只是按需打造一些提高效率的工具。
销售管理方法的形成经历了漫长的过程。
差不多一百年前，西方商人就创造出「线索卡片」这样的管理工具，用一张卡片记录潜在客户资料，并同时利用这张卡片记录销售转化的全过程。
这是一个非常直观的方法，但是在销售组织扩大、销售过程复杂度提高后，这个方法无法解决现代企业销售管理中的几个重要问题。
●难以适应分工化的销售过程。
复杂产品的销售通常不是一个人能够完成的，它可能需要销售工程师的参与。
成交以后也不是业务关系的结束，而是客户服务和持续销售的开始，一个客户并不一定只有一次成交动作。
线索和客户其实并非一一对应的关系。
●难以通过数据分析有效地提高转化率。
很久以前，销售人员就发现B2B销售和一部分的B2C销售并非从陌生人到成交客户的直接转化。
销售的过程需要经历好几个不同的阶段：
第一次见面→了解客户需求→识别需求和产品的关系→制订销售策略→给出方案→报价→讨价还价→促进成交，等等，销售不是一蹴而就的。
在这么复杂的销售转化链条中，必然有的销售人员做得好，有的做得不够好。
对于那些做的低于平均水平的销售人员来说，到底哪个环节存在盲点或者培训不足呢？
大多数情况下，销售管理人员无法一眼看清楚。
●虽然有了潜在客户的记录，但是还是无法基于这个信息预测未来一段时间可能的销售成果。
基于这些希望解决的问题，西方销售管理业界在个人电脑普及的早期——单机软件时代就发展出了销售漏斗管理思想和配套的工具。
早期的销售漏斗管理将客户、销售线索和成交机会分开管理，建立了一家企业管理订单获得过程的基本数据结构。
然后，再将成交机会进行阶段划分，不同企业和产品可以根据实际需要将一个典型客户从接触到成交的全过程划分为4～5个阶段，阶段的名称可以自行定义。
因为有了这个数据结构，我们就能够通过数据来分析不同阶段之间的转化率、不同销售人员和团队的转化率，以及在销售漏斗中流动的成交机会金额。
通过简单的数学公式，销售系统就能够预测未来一段时间的可能成交金额。
比如销售漏斗中如果存在以下成交机会：
A客户购买X产品，预计成交金额100000元，目前在阶段1，成交概率为20%
B客户购买Y产品，预计成交金额10000元，目前在阶段4，成交概率为80%
加总以后，我们就可以得出累计的预测销售金额为28000元。
在这个例子中，我们忽略了订单成交周期问题。
如果漏斗中的成交机会数比较少，预测的精度就会比较低，但如果长期使用，就可以不断调整预测参数，让预测结果更准确。
有了这套方法和工具以后，销售管理就可以实现以下功能。
●对销售过程进行结构化的记录和分析，能够通过计算预测销售成果，也能够通过数据记录得到大量有价值的销售情报。
例如，如果交易失败，那么这些输单的主要对象和原因是什么？
●能够有针对性地改进销售转化率，而不是笼统概括地提出改进目标。
每一个销售阶段的转化都伴随着更加具体的方法、技巧和工具，并非每一位销售人员都能够完全掌握。
有了中间过程的数据分析，我们就知道不同销售成员在不同阶段转化上存在的问题（他们的转化率肯定低于平均水平）。
而且，如果进一步分析销售漏斗中的成交机会来源和大小，我们也能够知道销售人员是否能够有效地从现有客户中获得更多订单，找到的客户价值是否足够高，成交周期是否长于平均周期。
从Salesforce开始的销售管理自动化软件着眼的就是解决这些问题。
到最近几年，销售自动化已经发展到可以帮助销售人员自动完成一些销售动作，或者在恰当的时间给出销售行为提醒，甚至依据积累的数据来自动分析成交机会的质量（机器学习在这个应用领域有很大作为）。
如果我们把销售漏斗向前延伸，获取客户的过程其实还包括整体性的市场营销、获得最基础的客户线索；如果向后延伸，获取客户的过程还包括为现有客户提供使用帮助、加深现有客户的使用程度、促成更多老客户订单。
所以，销售管理应用还有营销自动化和客户支持两个「姐妹」，它们整合在一起就是比较完整的CRM解决方案。
有一些企业用户对销售漏斗方法中要求有效记录数据颇有成见。
他们认为销售人员很难有动力录入客户信息和销售过程。
这个问题要分两面看，一方面，CRM解决方案是为了从整体上提高销售效率的，所以，无论数据采集有多么艰难，如果没有事实的解析，就不可能有针对性的优化方案，企业就永远只能依靠明星级销售人员，这在企业高速增长阶段是难以为继的。
任何企业都应该有能力将普通销售人员训练为合格销售人员，这个能力正是CRM信息化所赋予的。
另一方面，采集销售过程信息的困难也未必是不可克服的。
CRM产品开发者都非常重视这个问题，他们有动力设计和开发出对销售人员更加友好的数据采集和记录方式，比如，现在大部分销售管理软件都能够和邮件、社交网络系统整合，不再需要销售人员重复记录沟通过程。
销售漏斗方法主要适用的是B2B商业模式企业，也包括一些成交过程复杂的B2C模式企业，如果你处于一般消费品和消费者服务行业，那么销售管理的模式是完全不同的，它对应的是企业的电子商务前端店面管理或者售点系统（POS）。
6.8用户分群和营销自动化
在现代营销理念中，「在正确的时间向正确的人传递正确的信息」是被广泛认同的原则。
但这条原则在越来越复杂的营销环境中非常难以实施，其有效实施离不开信息化和自动化的助力。
可以说，现代营销方法几乎完全都是在软件能力基础上逐步发展起来的。
今天绝大多数的营销投入都发生在社交媒体营销和数字化营销上。
营销活动不再是将单一的信息向大范围的受众传递，而是依据每一个受众的特征和行为自动触发营销动作。
这个过程几乎完全是自动化的，所以，企业用户依然保持了对营销活动整体管理的感知，只是这个管理过程远比过去复杂。
很久以前，营销软件就意识到要将用户进行分群。
它们通过分类或标签的方法把用户细分成很多群组。
然后营销经理根据不同的目标选择不同的群组传递不同的信息。
但是，当业务在线化水平越来越高、用户行为越来复杂、需要评估的数据点越来越多以后，这种简单的基于标签的用户分群方式已经无法满足营销管理的要求。
换句话说，营销应用的复杂性随它所管理的受众数据规模的扩大而大幅提高了。
因此，现代营销方法建立了更适应要求的「动态细分」概念，受众和用户不仅按照简单的标签进行分类，而且通过灵活度极高的检索条件创建出动态的细分组。
例如「新顾客」这个概念，在传统的用户标引中是很难实现的，因为今天的新客户在下一个季度就不一定是新客户了，他们
升级会员 