三维抓手模型

加入滴滴已三月有余了，这期间我所接触到的、经历过的、尝试着手去解决的种种业务问题，不论是其本身的复杂程度而言，还是在问题解决过程中我所收获的成长，均远超过去。

而在我所有收获之中，对我来说，最有价值的，是这样一套思维方法论，权且称其为：三维抓手模型。

在具体介绍这一思维模型前，我们其实需要先明白，为什么从目标出发的思维体系如此重要。

对于产品经理而言，决定解决什么问题，要比怎么解决问题更重要。但许多产品经理却缺乏一套合理的，由业务目标出发导出项目切入点（aka 抓手）的思维流程，只得对着『提高用户数』『让用户更满意』等这类笼统的目标拍方案。因为我们可做的事情太多了，如果不从全局的角度对业务方向做拆解与分析，大概率会陷入到繁杂的细节之中，今天修个Bug，明天加个功能，整天都被Bad Case追着跑，最后发现好像所有人都很忙，做了不少事，但业务指标几乎没有变化。

在滴滴完成第一个项目后，我曾阶段性的总结出一套如何由业务目标导出抓手的思维方式：

简单总结为五个词：目标、问题、抓手、方案、执行，具体含义如上图所示。

当我处理第一个项目时，目标与指标均非常明确，我所需要做的，无非是问题的拆解，也即究竟哪些问题对业务指标的提升造成了障碍，进而确定各个问题处理时的抓手，确定整体项目推进节奏与框架之后，依计划执行即可。

但当我具体接手第二个项目时，我发现这个项目没有目标，或者说初始定位过于理想以至于无法落地。滴滴通常不允许一个项目长期处于纯粹的探索阶段，为了尽快将项目推上正轨，持续给出阶段性产出，我面临的第一个问题就是，如何确定目标。

这时我发现，目标理所应当是基于『问题』产生的，目标与问题之间，似乎并没有绝对的先后顺序，也即目标与问题并不在同一个逻辑维度上。这是引起我针对由目标到抓手这一过程进一步深入思考的第一件事情。

第二件事情是，在与leader拉齐认知，以及参与其他项目框架梳理的过程中，我明显的发现了除了针对目标与问题本身拆解来得到抓手之外，整个业务本身的架构层次也是重要因素之一。

基于以上两件事情带给我的新认知，我尝试修改了我脑中由目标到抓手的思维模型，如下图：

三维抓手模型

这个图确实很抽象，这里简单解释下：目标是指业务目标，是我们做这件事的目的，以及衡量目标达成程度的具体指标或指标组；而问题的来源是用户行为流/流量图/步骤划分/服务触点，通过对用户行为进行合适维度的还原、拆解与分析，最终发现问题所在；而架构是指构成整个产品的多个架构层次，以及各层中承担不同功能的系统模块；而存在于这个三维坐标系之中的，就是各个抓手，也即每一个抓手都针对某一特定业务目标，在某一特定架构层/模块中，解决某一特定用户问题。

如果从面的的角度来看，我倾向于将 xoy 称为事实面，因为不论业务目标为何，整个系统的架构/模块划分与用户实际使用流程，都是客观存在的事实；而 xoz 被称为业务面，因为系统架构与属于非业务逻辑，而业务目标与用户使用流程均属于业务逻辑，系统架构基本不会受业务目标与用户具体使用流程影响，其目的在于提供高内聚、低耦合、通用且可拓展的业务支撑系统；zoy 被称为战略面，在不涉及用户具体使用时（如产品的初期阶段），战略面不关心具体用户使用流程，只在乎采用一个怎样的产品去解决用户怎样的需求。

理论上，一个坐标轴的三种维度应该是相互独立的，但实际上，我发现目标与问题之间的关系，似乎又并非完全独立这么简单。的确，用户的使用流程与公司内部制定的业务目标并不直接相关，但目标的选择会决定用户行为流的拆解方式。用户使用产品是一个连续的流程，理论上整个流程可以被细化拆分为无限个点，每个点之间或多或少都有些不同，不论是用户情绪，还是某类决策倾向性的变化。而目标的存在使得从用户行为流到问题的拆分有了最优解，产品经理可以忽略与业务目标无关的用户行为的变化，而是把全部精力集中在与目标直接相关的用户行为发生变化的若干个时间点，进而得到流量/流程/步骤的划分，也即得到问题的拆解逻辑。

依照这一模型分析，我在上一家公司所从事的，就几乎全是架构维度的事情，从产品架构的角度考虑如何提供更优秀的业务支撑系统，但却忽略了对目标/问题等业务面问题的关注。

这一模型的价值在于，它能够帮助产品经理清楚的知道自己在做的事情究竟在整体中处于什么样的位置，全局性的思考问题，避免一叶障目，只窥一斑而不见全豹。比如当我们为了这某一业务目标在某一架构层级上解决某一问题的时候，或者也可以考虑在另一个架构层级上有没有更合适的方案，或者这一问题是否是最需要被解决的问题。这些问题如果没有一个全局的视角，无疑是难以回答的。

当然，这一模型也仅仅是我切身带过两个项目之后的感悟而已，随着经历的不断增加，也许我还会发现这个模型的其它不足，比如缺维度，或者维度的划分不合理等问题。但实际上，一个合理且有效的思维框架/方法论，通常都是从实践中感悟、总结，并在之后的实践过程中不断迭代与优化的。

在这一模型之外，另外一点我还没想好，不过也暂且记录在这里：抓手似乎仍包含着另外一种性质，通用或专用。有的抓手能够解决一类或多类问题，有的抓手却只能在某一特定场景下解决某一类问题，而并不能适用于其他类似场景。正是这类抓手的专用性质，衍生出了我们所常常采用的『优先解决Top场景问题』的做法。针对某一特定场景，专用抓手通常比通用抓手有效的多，但专用抓手对长尾场景通常是无能为力的，因为专用抓手需要分场景逐一去做，如此一来，就一定存在一个平衡点，在这一点投入与收益相等，再做更小众的场景，就得不偿失了。两类抓手性质不同，无所谓好坏，采取综合考虑当下及长期ROI做决策即可。