写给所有数据人。
共 1932字，需浏览 4分钟
·
2020-09-17 20:21
大家好，我是宝器！
拖更太久，开头先抱歉，希望这篇文章对你有所帮助。
很多实习或者刚入职的分析师都会陷入一个问题，陷入需求变成SQL取数技师和需求处理工具。你可能会经常收到这样的消息：
1、“Hi，可以帮我统计一下最近一个月宝器直播不同频道DAU吗”
2、“背景是这样的，国外相比国内运动社交功能的活跃一直不好，我有个疑惑是不是跟每个用户的好友数指标相关，所以可以帮我看看国内外用户平均好友数的对比吗”
不仔细看，确实没什么问题，但这里面有两个误区。
问题1，需求方认为分析师只是取数技师，无需针对需求背景和目的讨论分析逻辑。
问题2：需求方的目的是验证好友数这个指标和运动社交活跃的关系，不需要分国内外，需求方认为他定的衡量指标和维度是对的，分析师只需要取到我所需要的数据就好。
而长此已久工作下去，会让自己陷入一直无法接触业务的思考，都是执行和工具人，工作年限带来的ROI也只是处理需求+1。
其实更多的应该是对每一个需求的背景和目的都了解，这个过程中思考用哪样的指标来反馈需求，而对于需求方只需要给到问题，背景和目的，更多的分析逻辑和思考留给分析师，而不是需求方自己分析，分析师变成提数工具。
并且，对实习生和刚入职的分析师来说，可以通过这种解决需求的方式不断的深入公司的业务，过程中梳理业务指标体系，逻辑模型分析体系，之后就可以思考如何用模型、方法反哺这些业务。
同时，对老板来说，设立数据团队肯定不是来解决需求的，你做1个需求和做100个需求其实贡献度差别不大。更多的是针对业务的增长分析、驱动产品的迭代分析及解决业务异常的逻辑模型。
所以，在工作中需要定好自己的基调，一定不能让业务方从心里认为你只是个取数的，每一个需求都要问清楚背景和目的，并且在这个过程中辅助业务方学会基本的SQL解决一些基本需求，而定制化的专项分析留更多的时间取思考和执行。
那可能需求方会问，我们都会基本SQL了要分析师做什么？
嗯，这个问题你可以这么回答。
第一，告诉你的需求方，会基本SQL不等于会SQL，复杂的专项分析逻辑和执行效率优化需要分析师来做。
第二，SQL只是处理业务需求的某种工具，而当有些任务需要的不只是取个数，更多是需要应用分析理论模型、数据挖掘模型、假设检验、因果推断等等时，需要从专业的角度才可以解决。
但这些，都只是工具。请一定记住，一切以业务为导向。快速解决业务问题的分析模型、方法就是最好的。
具体如何解决这件事？
宝器分享一下目前个人的思路，出一个《数据需求规范体系》。而当落实到各业务组这件事的时候，一定要给各业务组聊清楚《数据需求规范体系》的意义，宝器思考了几点。
准确度：规整自己的需求目的和背景，确认正确的评价指标体系，降低不准确的概率。
任务透明化：让需求方和分析师都能看到目前在进行的分析需求有哪些，负责人是谁，需求优先级和需求大致完成时间。
效率：减少无效的沟通和需求混乱，让分析师可以按优先级处理需求，做好其他任务排期。
良性循环：分析师可以了解详细的分析背景和目的，所以对于需求方发来的衡量指标可以从问题出发，以专业的角度重新梳理指标。待提出数据后，再将结果进行加工分析，最后以半结论半数据的方式反馈给需求方。长此以来，就很少有需求方会提出具体的指标，而是提出问题，让分析师来提供分析方案，从而留给分析师更大的发挥空间，进入良性循环。（这需要先从需求中规整出咱们数据字典和指标体系）。
那这个要包含哪些内容，简单讲一下，需要两张规范表。
第一张：
1、需求编号（带有日期和编号）
2、需求发起人
3、需求分类（产品需求，研发需求，运营需求等等，根据各公司业务定）
4、需求负责人
5、需求是否已确认（分析师已经确认好需求的背景和目的，了解了业务意图）
6、需求状态（已处理、正在处理、待处理）
7、需求预计完成时间、
8、需求优先级
第二张：
1、需求编号
2、需求背景
3、需求目的
4、需求衡量指标
5、需求统计口径
为什么需要两张表？现在快1点多了，有点困，下一期分享。主题：结合需求及OSM+UJM模型构建完善的数据指标体系。
最后的最后，由于宝器弟弟的拖更，略表心意，送几本书给大家，具体内容、参与规则等见下：
1、第一种方式：文末参与问题留言讨论，主要说下大家对文章内容的期待和想法，喷我也好，留言讨论的点赞前2位。
2、第二种方式：在看、点赞前2位，。
