数据研发要如何做好业务方管理
发布时间：2022-03-23 09:52:12 所属栏目：大数据 来源：互联网
导读：伴随着业务的发展，业务方通常会提各种各样的数据需求。面对繁杂的需求，数据研发可能会遇到下面这些问题： 怎么才能做到高效、高质量地交付数据需求?对于新业务需求，怎么才能快速把握? 怎么应对需求的反复修改？该如何say no 面对这些问题，我们需要学会做
|
伴随着业务的发展，业务方通常会提各种各样的数据需求。面对繁杂的需求，数据研发可能会遇到下面这些问题： 怎么才能做到高效、高质量地交付数据需求?对于新业务需求，怎么才能快速把握? 怎么应对需求的反复修改？该如何say no 面对这些问题，我们需要学会做好业务方的管理，这样才不至于让自己陷入被动的深渊而不能自拔。 窘境 面对源源不断的需求，数据研发会越发地感觉到自己只是一个取数的工具而已，因为都是在被动的接需求，久而久之，业务方也会觉得你就是一个取数的工具。大小问题，随时抛过来，只管要数，其他的一概不管。你要是说：[我事情太多，没空做]，或者[需求没有意义，往后排]，那么业务方可能直接找到你的主管来协调，最后事情还是你的事情，还是要乖乖地去完成他们的需求，即便你是不情愿的。那么怎么才能改变这种局面呢? 屁股决脑袋，立场不同，思考问题的角度也不同，做出的判断和决策也是不同的。所以想要破解这种尴尬的境地，需要我们转换一下立场去看问题。 从做事情的角度出发 灵魂拷问：需求的背景是什么?有什么价值?对后续的运营决策有什么帮助?没有其他的数据可看吗?不做行不行，如果资源有限改如何排优先级?该如何去获取更多的背景信息，为什么业务方要关注这些指标?需求背后的真正诉求是什么?我能够提供什么? 可以看出，从不同的角度看问题，会出现不同的判断，我们应该站在解决问题的角度去思考，与业务方达成某种潜规则，这样我们才能做到来者可拒，游刃有余。 我们先来看MRD是干什么用的，MRD指的是市场需求文档，主要描述通过什么业务方案来解决什么问题、达成什么业务目标。要解决的是让关联 PD 清楚业务诉求、认可业务方案，并可落地设计产品方案。MRD 书写语言为业务视角语言，无需涉及产品/技术实现。通常情况下，MRD包括以下内容： 业务问题：客户是谁、业务背景是什么、业务的痛点是什么、业务的痛点是什么 业务目标：包含具体的业务目标、业务价值 业务方案：包含整体的方案、涉及的业务流程、具体的业务功能需求、运营计划 基于这些内容，数据PD要产出一份PRD，基于业务需求及产品能力进行产品方案设计，通过产品方案支持业务方案落地，使业务、研发认可通过产品方案可支持业务目标实现，通常情况下，PRD要包含以下内容： 需求背景 业务价值 需求描述 产品方案 有了PRD之后，就到了数据研发登场了，这个时候需要把所有事情搞清楚，不然的话很容易跑偏影响交付的效率。到了需求评审阶段，数据研发需要做三个方面的事情：核心思想是批判与挑战，当然是要有理有据有节，而不是为了逃避任务而无理取闹。 挑战：需求是否合理，可不可以不做 需要了解数据的使用方是谁?业务背景，业务痛点?期望达到的业务目标(最好是定量)是什么?数据的使用场景是什么?紧急程度如何? 评审：需求沟通 积极了解业务需求相关资料，包括业务背景，痛点、目标、及运营方案。知道业务想干什么，为什么要这么干，我们在这里面能做什么。 考虑实现方案设计 对于比较复杂的数据产品，需要提前进入产品的规划中 确定相关干系人在场，避免导致重复沟通 详细的数据口径确认(数据范围、维度、指标口径、产出时间等等) 排期 经过前面的沟通，可以跟业务、PD、前端达成一致，这个时候就需要我们给出一个具体的排期，包括什么时候开始做，什么时候交付。对于复杂的需求或者新业务需求，要做到需求的拆解，给出预估的时间，同时也要留出一定的buffer，用于数据验证和方案调整，如果实在给不出一个具体的排期，也要告知到相关的业务，等梳理清楚之后，再给出一个合理的排期。 总结 本文主要介绍了作为数据研发该如何破局被动接需求的尴尬境地，核心的点在于要改变看问题的立场，多站在解决问题的角度去思考背后的逻辑。与业务方及相关干系人达成某种潜规则才是我们解决问题的杠杆，这样才能真正做到来者可拒，使自己不至于那么被动，同时也能够明确责任，提高效率。 （编辑：南通站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
