编辑导语：在以终为始的内容中，目标举足轻重，但是在实践过程中，或许还会力不从心：目标要怎么定？什么样的目标才有价值？在大大小小的分析事务中，如何管理众多的目标？本文将围绕这些问题，聊聊数据分析师的目标管理该如何做。

通常来说，数据分析项目的起点是业务需求；按以终为始的落地思维，f分析项目过程需要围绕着业务目标开展，但是业务需求做不做？如果要做的话，需要做到什么程度？需要对其背后的业务价值进行思考。因此，为了讨论清楚目标管理，需要探清其上下游：需求管理（what，解决做什么的问题）-目标管理（how，解决怎么做的问题）-价值管理（why，解决做到什么程度的问题）。

一、需求管理

数据分析师会遇到大大小小的许多分析需求，在对它们进行管理之前，需要先知道有哪些需求：

• 按时效性区分，可以把业务需求划分为临时需求（例如取数、统计指标）、专项需求（例如活动效果分析、人群运营策略）、与长期需求（例如指标体系、日常运营监控、甚至是数据产品需求）。
• 按输出形态区分，可以把业务需求划分为PPT报告（例如针对活动的分析报告）、Excel表格数据（例如从数据库提数、聚合后的报表）、BI报表（例如BI系统中的实时报表）、REST接口（例如模型以接口形式落地，供前端调用）。

做需求管理，最理想的状态就是在拿到需求后能迅速识别分析项目的风险、影响、难点：

• 风险，更多指的是无法落地的项目，可能多是出自于领导“伟大的构思”，最终不了了之。
• 影响，分析结果的影响什么及程度多大？是仅仅给业务瞅一眼，还是会根据分析结论调整产品功能？
• 难点，对风险低、高影响的分析需求，是否具备可行性？

不论是老鸟还是新手，分析师起码能对以上三方面有初步的判断，接下来还需结合优先级思维做决策。

1. 优先级思维

数据分析实践中，面对业务需求，很少场景能让分析师决定做不做，因此，面对众多的需求，更重要的是如何分配优先级，同时，这也是重要的落地思维之一。基于重要紧急模型，可以把需求分为重要紧急、重要不紧急、紧急不重要、不重要不紧急。虽然说需求的判断力依赖沉淀的经验，但是可以大体分为以下几个维度的思考：

1. 交付日期Deadline 主要是帮助判断需求的“紧急与否”维度。
2. 重要性如何判断需求的重要性？某个事物的重要性在于它对其他事物的影响，也就是要回归到业务场景来看当前需求在业务流程里的作用。同时，也可以反向思考它的必要性：如果不做这个需求会怎么样？
3. 需求方在经营管理中，强调“以客户为中心”，作为数据分析师，需要思考我们的客户是谁？部门领导、业务部门、产品经理等。需求方来自哪个客户，实际上也是对需求重要性的加权：

• 直接上级：从考核指标来说，这类需求的权重最大
• 项目相关业务方：除了领导交代的任务外，分析师所在的项目在不同阶段都有不同的需求， 因为项目的成败关系自身的考核，所以这些需求也同样拥有较高权重
• 非直属的业务领导：一些扁平化管理、管理灵活的组织存在跨部门协作，因此会有来自其它部门的领导的需求，虽然它们往往和自身考核关联不大，但由于存在职位权力，可以赋予一般的权重
• 无项目相关的业务方：除以上的需求方，其余的业务方的需求，就显得不那么重要。什么是业务方？我想是那些与自身的考核方向、项目外延相关的。虽然这类需求很多时候与自己无关，但是从维护职场关系的层面来说，可以以“安排排期”的形式来承接
• 其它职能部门需求(非业务方)：剩余的需求方恐怕除了是同事外就没有什么关系，这类需求往往就是同事个人想请求分析师的协助。建议直接拒绝，省点力气建设自己。

至此，通过需求管理，我们解决了需求做不做、何时做的问题，接下来需要借助目标管理来指导如何做。

二、目标管理

项目管理，实际上就是在做目标管理：制定项目最终的落地目标，按以终为始的思维倒推到当前节点，把过程拆解成里程碑阶段性目标，而甘特图上每个流程节点都有输出交付的小目标。

有了目标之后，在开展分析工作的过程中，尤其是在最后给业务建议的环节，都需要评估当前的工作是否在为目标服务。

制定一个落地的目标可以借助SMART工具。

前面在讲需求管理时，提到对需求风险的评估，也就是项目能否落地？这一点就可以借助Smart原则来对需求的完整性来做判断。

假设领导夜间在朋友圈看了一个推文打满鸡血，转发给你说要做。与领导沟通后，如果需求对应的目标仍是缺少了SMART原则中的其中一项，还能通过调整目标来实现，风险可控；但是一旦缺少了两项及以上，项目落地风险就剧增，例如缺少了 R 和 A，说明这是一项全新的业务，现有资源无法支持，需要拉长战线持续投入，此时项目充满的是未知数，自然就谈不上落地；更不用说缺少了SMART原则中三项及以上的要素，一旦遇到则要及时“把梦想扼杀在摇篮里”。

三、价值管理

落地思维有一个重要的内容，就是对“程度”的思考：从输出形态的角度，对同样一件事，是给数据结论就可以了，还是说要做成分析报告？是给数据报表就可以了，还是说要做成BI在线报表？做得越深的事情意味着需要付出更多的精力，这同时也需要有更高的价值支撑。

并不是说所有事都值得all in。这里强调的是对需求交付目标的把控需要和价值匹配：

• 避免用力过度：业务只需要临时看一眼指标，竟然收到一份完整的分析报告;
• 避免不及预期：业务期望从分析师结论建议中找到功能迭代的方向，却只收到一份结果数据的呈现报表。

具体如何做呢？可以从数据分析师自身价值，和分析项目价值两个方向出发考虑。

1）数据分析师的价值

这件事中数据分析师自身的发展是否有价值？例如分析师刚开始学习SQL，缺少了实际的工作场景，此时产品部门提需求做较为复杂的存销分析报表，尽管此项工作并非考核内容，但是可以帮助分析师实践、强化SQL能力，那就值得去做

2）分析项目的价值

目标的设定除了要符合SMART原则外，还要紧贴项目的最终落地价值。

例如电商业务中，探索人货场打通的策略，老板说这次项目是要扩大目标人群的规模。此时，如果只是围绕这个目标去扩大人群，最终容易陷入价值困境，因为如果扩大的人群不能带来转化就没有价值。

所以基于老板告知的目标，考虑其最终的价值落地在于人群转化的产出业绩。在实践中，应该先打造高转化率的典型场景，再基于此扩大人群，此时，随着人群的扩大，转化率会有下降，但是能确保一个基准。反之，如果先扩大人群再考虑转化率的问题，落地难度很高。

完整的价值管理应该包括：

1. 价值判断。思考分析需求背后的业务价值点，以及设定的项目目标、里程碑目标是否紧贴落地价值;
2. 预期管理。最好能让团队成员(或者是需求方、业务方)对需求、甚至是项目的目标及背后的价值达成共识。尤其是对领导给的风险较大的分析项目，及时向上管理对齐预期，减少不必要的效率浪费;
3. 价值落地。完成项目分析的最后一公里，通过策略建议、BI报表等所见即所得的形式落地;
4. 价值升级。能落地的价值证明分析师已经满足了这个层次的要求，接下来可以持续上扬，而这可以借助工具PDCA循环来实现。

PDCA循环是项目质量管理工具，它把项目工作分为Plan（计划）、Do（执行）、Check（检查）、Action（处理），简单来说就是不断得复盘、调整。在实践中，PDCA循环的魔力在于每一次项目之间，通过标准化沉淀经验，持续释放数据分析价值。

PDCA循环强调的是做价值升级，具体体现在对需求的主动升级上：临时取数 → 统计指标 → 指标体系 → 专项分析 → 产品落地。

例如临时取数的需求没有价值可以言，但是在取数交付时可以与业务沟通是在做什么统计，分析师可以以更专业的视角来帮助统计指标。通过不断的主动升级，将数据分析价值在业务流程中落地，实现变革提效。

本文由 @饼干哥哥 原创发布于人人都是产品经理。未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。