面对需求,需要找对人、做对事、处理好关系

我是创始人李岩:很抱歉!给自己产品做个广告,点击进来看看。  

编辑导语:职场人经常会面对需求,进行需求的执行时,我们需要多方面的配合;首先我们需要了解需求,进行判断,其次需要进行需求的一系列操作,最后进行管理;本文作者分享了关于在面对需求是我们需要怎么做,我们一起来了解一下。

面对需求,需要找对人、做对事、处理好关系

几天前,在“ 管理从「需求」开始 ”文章中总结,需求可以通过访谈、调研会、竞品分析、用户反馈及数据驱动等多种方式发现与获取,按照紧急程度或KANO模型进行筛选与分类,需求的识别与梳理要遵循「保持与业务战略的契合、业务流程重构、业务连续」四项原则,最后将这些确定的需求进行优先级排序并实现。

这些工作与过程概况起来可以归纳为找对人、做对事和处理好关系,本篇继续聊下个人对这部分的想法。

一、找对人

无论是企业内部需求还是企业外部需求,无论是ToB的需求还是ToC的需求,无论是小需求还是大项目,它们都是为“用户”服务的,是解决“用户”问题的;所以,我们通常最关注的是 「用户」

但是,一个需求或项目的成功要考虑很多因素,从“人”的角度来看就不仅是最终用户这一个群体,它应该包括所有的利益相关者,即干系人。

需求的来源途径很多,有时候是老板的一句话,有时候是业务人员提出的,有时候是对接商家提出的,有时候是外部对接系统升级产生的…

所以,找对相关干系人非常重要,他们是需求或项目的关键参与者,这些参与者在后续的各个阶段中会对需求的执行结果有着不同程度的影响。

识别干系人的第一项任务就是,确定哪些人是需求或项目的主要利益相关者,通常可以划分为五类,即职能干系人、最终用户、项目组、运维人员及外部相关者(见下方简图)。

面对需求,需要找对人、做对事、处理好关系

① 职能干系人

电商企业的需求大部分来源于职能部门,企业的业务流程也会以职能组织结构的不同而不同,职能组织的复杂程度、部门间的职责边界划分也是影响业务流程和系统实现的重要因素。

面对一个需求或项目时,对于职能相关人的识别非常重要,而且找到能够对需求“拍板”的人更重要。

② 最终用户

B端用户或C端用户是一个很大的用户群体,对于他们的分析和挖掘企业投入非常多;通常理解为直接使用或操作通过需求或项目实现的解决方案的最终人员,他们是最直接的干系人,也是最终的受益者。

在在一个需求或项目中可能会涉及不同类别的最终用户,例如,对于一个门店补货项目来说,最终用户就涉及店员、门店运营人员、仓储人员和财务人员(结合业务流程涉及的各个环节上的操作用户来区分)。

电商企业中,最终用户有一部分同属于职能干系人。

③ 项目组

需求或项目的实现离不开项目团队,所以我们要识别项目组的相关人员,包括产品经理、研发人员、测试人员等;每类人员中还要按任务进行分组,以便判断影响。

个人觉得,找对项目组中的相关人员是需求执行期最为重要的,他们是需求的执行者,是对最终用户负责的群体

④ 运维人员

这里包括系统运维人员、安全人员、基础架构人员、应用服务人员等。根据经验,有时候项目的进度会受这些干系人的影响,要提前识别,预先准备。

⑤ 外部相关者

目前,企业的系统越来越复杂,依赖的也越来越多,同时,需要遵守的规范、保证系统的安全是非常重要的,面对一个新需求,我们需要考虑这些影响;例如,对外开放平台的需求要考虑对接的商家系统,购物流程的变更要考虑用户安全并遵守支付平台的接口规范等。

找对这些利益相关者是需求或项目成功的开始,根据这些人我们可以进行相关的分析,通过下面的表格可以体现。

面对需求,需要找对人、做对事、处理好关系

找到这些干系人(利益相关者)的目的是:通过这些人深入挖掘需求,了解哪些利益相关者将可能是阻碍者或批评者,哪些利益相关者是拥护者和支持者。确认这些干些人的权力、影响力,后续在需求执行过程中有侧重点的安排工作。

这里,也可以采用一个权利网格帮助我们进行描述和分析(如下图)。

找对人,做对事,处理好关系!

二、做对事

干系人确定了,下一步就是做事(需求分析、设计、执行……),需求的实现是渐进的、迭代的过程。

面对具体需求的业务分析时,常见的问题主要有过度分析,缺乏验证,太多的场景假设,PRD文档太长、缺少业务价值,理解的偏差等。

针对以上问题,应该明确需求的目标,这是大家熟知的,但现实却是结果往往偏离目标。

任何一个需求或项目,都需要进行裁剪(扩大或缩小),定制交付(分阶段),这样在目标偏离后才能及时校正。

对于繁杂的需求,哪些是真正的需求,哪些是伪需求呢?

对于这个问题,个人觉得真正的需求就是能够经得起业务反复推敲(验证)的需求,否则就是伪需求。

如果我们无法确定这个需求是否为真需求,可以采用多问几个为什么(WHY)的方式来进行判别;同时,可以借助于此方法去将表象需求转变为根本需求。

例如,采销人员提出在创建促销活动时增加商品的实时成本价的信息显示。

① 为什么要在这里增加实时成本价的字段呢?

因为我们在设置促销时有个参考价,防止促销价设置低了。

② 为什么要用成本价呢?我们采用的是移动加权价,实时成本价是变化的,为什么不采用当前采购价或历史售价呢?

因为“毛利=售价-成本”,我们通过成本价来判断对毛利的影响。而且,实时的成本价就是当前商品的成本价格,我们觉得这样计算出来的毛利会更准确。

③有些促销活动就是采用低价策略拉新和留存的,毛利会是负数,为什么要用毛利这个指标来衡量呢?

因为这涉及到我们的业绩考核,毛利是我们的一个重要考核指标,其他的还有GMV、新用户购买金额等。

通过提问,我们清楚了此需求的业务价值,可以向业务人员阐明促销活动只是销售的一种手段,在创建活动时的成本价并不是后续销售报表中毛利的成本。

建议业务部门将采购与销售综合考虑,系统采集一定时间段的数据信息进行分析,重新设计相关的考核指标,用以指导促销等相关运营决策。

做该做的事,明确各自的工作职责,避免越界。

工作一段时间后,我们清楚各自的工作职责,了解自己应该做的事,撇清与自己无关的事情,通过任务的紧急重要程度合理的安排工作。

每个人都在不断的学习和进步,随着个人的技术和能力不断提升,我们往往会忽略工作边界,工作职责范围在不知不觉中被扩大,工作量随之增加,工作重心有时候也会偏离。最终导致,该做的没有做好。

举个例子,产品经理在写PRD文档时,是否应该用UML工具来进行相关业务的建模?对于一些数据的存储是否应该定义好字段及长度呢?

这便涉及到工作职责的划分,个人觉得,产品经理的目标是将业务需求转换为产品需求,将其描述清楚,对于建模和数据如何存储、结构是什么样,属于业务架构师或研发人员的工作,各司其职。

有时候做的多了并不见得是好事,以这个例子来讲,如果UML或数据存储设计的不好,很可能会误导研发人员,在需求评审时也会产生冲突。

但要说明的是,“不做”并不是真的不做,应该是有选择的;我们应该在职责与边界上合理把握,适当的去做也会促销我们的工作与沟通,这也是一种变通,前提是一定要把该做的事做好。

三、处理好关系

处理好关系涉及到管理与沟通。

关于管理,在“管理的认识与思考”曾将其划分为「自我管理、向上管理、平级管理与向下管理」,在这些层级间做好管理,有助于我们工作的开展。

沟通是管理中非常重要的组成部分。需求或项目会涉及大量复杂并相互联联的信息与众多干系人;在合适的时间,向合适的利益相关者有效地沟通有针对性的信息,达成共识,是项目成功的一个关键因素。

在实际的工作中,我们要坚持“向上沟通要授权,对等沟通要支持,向下沟通要落实”的原则,建立沟通计划,进行有效的沟通。

沟通计划的内容一般包括以下几个方面:

找对人,做对事,处理好关系!

  • 干系人:识别出利益相关者,并通过沟通需求对其分组。
  • 关注点:确认沟通的需要、与需求和项目目标相关的关键信息,考虑沟通的风险和关键成功因素。
  • 方法与手段:确认沟通机制,用于与干系人间的沟通、并允许其了解项目信息,如通过会议、邮件、项目管理平台等。
  • 时机与频率:确认沟通时间表,确定在什么时候、什么地点、与哪些人进行什么样的沟通等。

有效的沟通加之合适的管理方法,会使得各方关系保持和谐,可以避免各种冲突。

在实际的工作中,由于一个需求或项目对于相关干系人的影响程度不同,相关间的关系是很难处理的;我们可以采用“胁之以迫,动之以情,晓之以理”的策略,使其“从否定到肯定,从消极到积极,从不参与到参与”。

① 胁之以迫:可以利用向上获取的授权,讲述利害关系,明确责任影响,“逼迫”相关人员合作;但要避免以“这是老板要做的”这种类似的理由来说服相关干系人,要围绕需求和项目的影响来阐明,确定后续阶段的配合程度与参与方式。

② 动之以情:以“共赢”为基础,以帮助解决问题为目标,充分发挥个人的魅力;但是,在工作中,我们要切忌“忽悠”,不能“承诺”一些无法达成任务和目标。

③ 晓之以理:以企业战略的角度来看待问题,以业务流程的重构与业务价值的实现,合理的分析与解释,使其达成共识。

在工作中要想处理好关系,就是要通过不断的沟通,让利益相关者达成共识,“沟通无止境,共识求发展”。

四、写在最后

面对一个需求或项目,找对可以完成这个需求或项目的人是关键;同时,要处理好其间的关系,正确的将各种事情做好。

那么,这个需求或项目的实现过程会比较顺畅,业务价值也一定会有所体现。

最后,感谢您的阅读!

#专栏作家#

倔强的大萝卜,公众号:倔强的大萝卜,人人都是产品经理专栏作家。较早的互联网电商行业从业者,有过多家电商公司的工作经验;撸过代码,10年以上的团队管理经验,目前的学习方向是供应链及业务构架等。

本文原创发布于人人都是产品经理,未经作者许可,禁止转载。

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!

本文被转载1次

首发媒体 人人都是产品经理 | 转发媒体

随意打赏

提交建议
微信扫一扫,分享给好友吧。