作为数分，我其实从来没把自己当数分

1️⃣主动沟通、主动承接 主打一个上赶着追业务（呸）。当时真年轻（现在也不老），冲劲儿足，各类需求从不拖沓，甚至可以接受不排期直接做，任何进展随时和业务保持同步。并且很多业务问题，不等pm张嘴，我已经担下来，总之想尽一切办法，扩大scope，增加话语权。 做这些，是因为我很早就意识到，数分和业务，就是乙方和甲方，想吃得饱吃得好，这几乎是唯一的路径 这方式也确实有效，在onboard到一个从0到1业务很短时间后，我作为一个junior da，就已经扛下整个C端的分析需求。并且但凡有重大项目，pm也愿意先来找我沟通，合作习惯就这样被培养起来了 2️⃣视角转化 解决了和业务的关系问题，接下来就是解决自己的问题。和很多DA一样，初入行，最大的问题是“业务sense”不够。我尝试了很多方式，看书、找leader沟通、找pm沟通，但发现收效较小。所谓sense，更多还是靠个人去悟 所以后来，我做了这样一件事儿，不让自己再做“数分”，做业务。也恰逢我当时和朋友合伙兼职创业，所以有更多机会，自己去做“业务”上的决策。这包括，基于业务目标，去找业务目标下的核心影响因素，再去找核心要素下需要被解决的问题。这其实是典型的top-down拆解思路，有别于数分岗位接需求时bottom-up的工作流程。‼️而且这个视角，不是单纯的产品or运营视角，是纯业务视角，也就是业务在为谁通过什么手段解决什么问题，并怎么赚钱。视角转化后，事情就好做了。能够自主判断分析需求的优先级了，能够独立发现业务优化方向并且可以立项了。也是在这个过程中，我逐渐从扛C端需求，去接手一个完整业务的数分工作 3️⃣成为业务的一部分 对外有了和业务更好的合作关系，对内有个人能力的提升，就自然到了最后阶段——成为业务。 这不是一句空话。业务想起飞，选对赛道、找到风口很关键，更要有相应组织架构配合，才能放大赛道和风口的价值 在一套成熟的互联网业务架构中，所有岗位都是为了解决业务问题，只不过大家手段不同。产品用功能和策略、运营用方案、研发用代码、战略用外部信息、数分用内部数据。能看清这个系统，自然就已经成为业务的一部分。想扩大scope影响更多，还是想偏安一隅恪守本分，就全在个人选择了