职能部门的需求

每个产品都会有接到来自不同职能部门需求的经历,我们应该如何应对?如何应对不同部门提出的需求,以及需求的验证、判断与执行?

职能部门

我们之前聊过,任何部门提出的任何需求,我们首先要尊重。因为不同职能部门会站在不同的角度,以产品能更好为出发点给我们提出需求,这样的需求肯定会有一些经验上的观点在里面,那么我们想了解不同部门提出需求的原因,前提是需要了解下每个职能部门的职责,并且根据职能部门的需求去验证需求的真伪程度和可执行程度!

功能点影响力

一个需求,可能是我们在表现层能看到功能板块,或者是某一个交互的变更,如果表现层我们看不到的话,也许只是一个计算规则的改变。

那么新增加的任何一个功能点对产品整体的框架有没有影响呢?这个也是我们接到需求需要考虑到的,具体我们应该从哪些方面考虑?

从此图我们总结几条需要注意的点:

明确需求目标

目标一定要清晰,根据目标反推产品规则和设计方向来看会更有效,以目标为导向的设计思路.

滤清业务流程、业务数据

产品设计的过程中,通常会考虑到功能框架、信息框架、业务流程,而在梳理需求的时候,也是经常会用到的

滤清业务框架以及框架横向、纵向的影响

新增或者迭代的某个模块,可能会影响到整体框架的改变,比如某个角色使用的功能调整,某个部门的权限重置等等,一定要考虑清楚一个功能的出现,会对全局有什么样的影响

不同部门的处理

每个公司不一样,大公司和小公司的部门可能会有很大的差异性,大公司部门可能更加细分,职责清晰,而小公司就不一样了,也许一个部门身兼数职,我们从大方向来说,经常给产品部提需求的大概会有:市场部、业务运营、活动运营、客服、产品、老板

  • 市场部

市场部可以说是最了解业务的一个部门,因为他们经常会跟客户打交道,尤其是地推市场部或者经常和B端合作的市场部,他们是最前端,最容易碰到用户的群体,所以他们提的需求我们一定要重视,那么处理市场部的需求我们应该如何做?

了解需求:提出来的需求我们需要知道需求是什么,为什么提这样的需求,这个需求落实后会对产品、公司、用户的任意一方有什么好处,这些是我们需要抱着质疑的态度去了解的。

需求验证:市场部提出的需求我们也是需要验证的,我们可以通过定性或者定量的方式来验证需求的真伪程度,当真伪存在质疑的时候,回头看,使我们验证的方式有问题,还是我们没有深挖需求的本质,或者需求根本就是一个伪需求,这个也是需要我们来判断的

需求规则:了解需求的目的和需求验证后,我们需要了解一下这个需求的规则是什么,只有把规则滤清了之后,才能更好的在技术评审的时候告诉技术如何去做,重点该注意哪些

需求逻辑:逻辑流程也是非常重要的,当我们了解需求和规则之后,要把重点放在流程的梳理上,包括用户使用产品的流程、前后端交互的流程等,都需要滤清。在滤逻辑流程的时候,我们可以先重点把握大流程,在每个节点上也需要注意子流程的梳理

需求执行:当我们确认可执行,那么就是产品设计、技术评审、设计、跟进测试等工作了,这个就考研产品的业务功力了

  • 业务运营

业务运营一般主要负责用户和商户的正常使用,处理一些日常性事物,一般业务运营提出的需求针对业务性的较强,他们的需求大概来源于对后台使用中的需求、上下游的需求、整理市场部的反馈需求等,这样的需求一般真实性比较强,适用于内部的较多,和主营业务比较贴近,一般此类需求在领导批示之后,了解业务规则和逻辑的梳理之后即可开始相关设计

  • 活动运营

活动运营一般针对的产品的用户方,以拉新、留存、促活为目的的较多,活动大方向上可以分为日常活动和节日活动,如果是大型活动需要提前很久准备。就好比,网易考拉的活动,有时候会提前半年之久就开始准备,准备的时候运营部、产品部、市场部、品宣等部门都会竭力合作,包括活动定位、目的、规则、业务流、视觉等,这个以后可以单独一篇来准备。活动运营的方案一般都是和后台数据有关的,通过数据的观察和分析,来决定为用户做什么样的活动,这样的活动产品也是很喜欢的,因为大家可以集思广益想尽各种玩法来和用户一起过过节

  • 客服部

客服部和用户也算很近,有些公司的产品刚上岗前一个月都是在客服部混,当然也是为了了解用户最真实的反馈,通过反馈可以分析出产品存在的问题。比如,我们经常会使用“饿了么”叫外卖,在这个外卖平台上,客服部接受整个业务链的问题反馈和处理,从点餐、配送、商家等多维度来处理问题,这样的部门反馈出来的问题,也是最接地气的用户反馈。但是一般我们需要作出对应的判断,就像有些用户反馈的问题是很客观的,但不能排除有些用户的反馈是“定制化问题”

  • 产品部

我们产品本部门输入的需求:产品部在不是很忙的情况下会做很多竞品分析、市场的了解和数据的了解,当我们看到一些有可能实施的方案,又或者有些不错的想法的时候,我们就会提出一些部门自己生产的需求。这些需求分类大概会包括:功能迭代、bug修复、体验迭代,而分别的出发点大概会有:增加产品亮点、增加产品竞争壁垒、创新、增值等。

最后想说的是,任何一个部门的任何一个需求都是值得尊重和认真对待的!

原文发布于微信公众号 - Miguel三先生(Miguel-sxs)

原文发表时间:2018-04-17

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏EAWorld

面向业务的企业元数据管理

最近Gartner在研究报告里明确指出,“元数据管理将是未来企业信息化的核心基础设施”。确实,在大数据环境中,如果企业不通过元数据管理把多种复杂的信息管理起来,...

5056
来自专栏大数据文摘

大数据的五大误区及其破解之道

2246
来自专栏PPV课数据科学社区

梦想与前行,一名数据人的自白

有些已经被行内人确认无疑的观点被反复强调,比如”数据挖掘/分析要懂业务”、“产品是数据价值变现的一条有效渠道”,观点没错,但听多了的感觉就好比一些健康养生专家在...

2653
来自专栏产品成长日志

最强大脑操作手册-思维导图

今天,互联网带给我们大量工具和无限流量的可能,让一个人也可以独立完成一款产品的研发,上市,推广。

953
来自专栏EAWorld

敏捷数据管理的12个技术原则

回顾整个数据平台的发展,在每一个阶段所有数据类应用都会或多或少的都会有数据质量的困扰,数据标准更是难以落地。数据管理由于难度大,涉及方面多逐步成为重要不紧急的事...

3418
来自专栏VRPinea

《Pokemon Go》新AR +模式支持6Dof,精确定位神奇宝贝

3637
来自专栏无原型不设计

5 个关键点!优化你的 UI 原型设计

当你和你的团队着手开始一个产品开发的时候,最开始的一步一般是绘制线框图,这是大部分产品项目的第一步,它不复杂但是却对整个产品的完成形态和质量有着至关重要的作用...

35510
来自专栏ThoughtWorks

TW洞见 | 估算的目的

我第一次与敏捷软件开发的邂逅,是在极限编程刚刚兴起时,跟Kent Beck一起工作的经历。其中让我印象深刻的事情之一,就是我们如何做计划的方式。这里面包括一种估...

36611
来自专栏人工智能

人工智能该怎么学

人工智能就像一个突然爆红的明星一样,唯一不同的是,它不会像明星那样会短时间过气。有些人想迫不及待的学习人工智能,从事人工智能。那么人工智能该怎么去学习呢?初学者...

2057
来自专栏机器之心

百度NLP | 智能写作机器人:不抢人类饭碗,我们只想人机协作

百度NLP专栏 作者:百度NLP 2016 年,百度全面发力内容生态领域,借助人工智能 (AI)、自然语言处理 (NLP)、深度学习 (Deep Learnin...

3054

扫码关注云+社区