「杂谈」数据团队不被牵着鼻子走的几种方式，最后一点最重要！
「杂谈」数据团队不被牵着鼻子走的几种方式，最后一点最重要！
序言
- 业务领导想看一个数据，麻烦帮忙跑一下！
- 需求产出的怎么样了？
- 为什么这次产出这么慢？
类似这种诉求和疑问，在你的工作中是否经常遇到？相信大多数数据同学都遇到过，久而久之，往往会觉得每日被业务方牵着鼻子走，自己很少有思考的时间。
面对这种情况，小火龙分享给同学们几种方法，些许会有帮助！
01
创建需求池
业务方频频说出上面那些话的原因，主要是为了在DDL之前交差工作，因此才会催促或者询问你。为了让合作方更好了解数据同学的工作，可将需求内容、进度维护到一个地方，供业务方实时查看。
有些企业有自己的需求管理平台，那是最好的，如果没有，可以维护一个需求文档wiki，实时更新需求进度，原理都是一样的，对工作内容和进度进行把控，具体涵盖如下图所示。
内容涵盖
涉及业务：当前需求属于哪个业务。
需求类型：不同部门，需求类型存在差异，例如：埋点、数仓建设、指标设计、问题排查、产品分析、用户分析、数据挖掘、BI等。
需求命名：需求名称。
需求描述：需求描述，也是提需的核心内容，涵盖：需求背景、希望通过数据佐证哪些内容、具体的数据需求内容（涵盖维度、指标、格式等）。
提需人：业务方。
承接人：数据方。
提需日期：提需日期。
期望完成日期：期望完成日期。
当前状态：需求当前状态，涵盖：未评审、已评审、待开始、进行中、已完成、已归档。
当前进展：需求完整进展、需求阶段性进展。
备注：需求备注内容。
02
执行需求评审
需求池可以帮助数据同学控制需求产出进度，在业务方没有异议的前提下，可以按照自己的节奏走。但是，需求池里面的需求是否合适？此类需求是否有必要做？这种问题很多一线同学可直接判断，但对于经验不是那么多的同学，往往不是很好决断，会带来很多无效工作。
为了解决这样的问题，数据与业务同学可定期开展需求评审，一般每周或者每双周，参加同学涵盖数据同学、业务同学，以及对应的leader。其目的是从第三方上帝视角，评判需求是否合理，控制需求的整体数量。
方式是将需求池里面的需求过一遍，由业务同学进行阐述，需求承接同学以及需求承接同学leader进行综合评判，判断需求的可行性。
这里需要注意！！！
注意1：需求评审时间不宜过长，阐述核心内容即可，缩短各方成本。
注意2：需要数据同学在会议前，过一遍需求内容，思考其数据验证方式及可行性。
03
参加业务会议
80%的数据同学基本不会参加业务周会，这样会导致三点问题。
其一：业务长期规划不了解。对于业务未来半年乃至一年的规划不了解，在后续做需求的时候往往是低头往前走。
其二：业务当前TOP事情不了解。对于老板当前最为关心的事情不了解，在接需求的时候无法判断事项优先级，业务说什么就是什么，被牵着鼻子走。
其三：无法判断业务提需的价值。对于数据同学影响最大的是此点，业务提完需求往往做了就做了，无法知晓其对于业务长期规划的价值有多大。对于未来写绩效、晋升、找工作，当对方问你所做事情对业务价值的时候，往往会支支吾吾说不上来。
综上所述，在条件准许的情况下，可以参加下业务的周会，如果实在没有时间，也要参加产品侧的大会，了解业务方针。