做了一年企业内部系统,我学会了竞争和博弈

编辑导读:为了管理企业和业务的需要,很多公司都会开发自己的内部系统,供员工使用。本文作者在做了一年的企业内部系统后,对竞争和博弈有了更深的理解,一起来文中看看吧。

时间过得很快,转眼做企业内部系统的产品已经一年。

在之前入职满半年Þ的时候,收获了三点心得,自己也通过践行这些心得,让日常工作顺遂不少。

回顾一下:

一是大胆质疑预设流程。通过预设流程的改进,在合作层面,增加业务对我们做了什么,做的好不好对理Î解。

二是用影响代替顺从或者硬扛。耳濡目染的释放自己的影响圈。

三是拿结果,做闭环。把工作延伸到上线后,关注使ਮ用情况再次迭代,对做完对需求有跟踪意识和改进意识。

具体想了解的话,可以查看http://www.woshipm.com/it/5215779.html

回顾完过去,立足现在审视:在之前的基础上,又经历了半年的历练,自己对这项工作有新的看法了吗?

答案是:有的,有从更宏观的角度来思考了企业内部产品的立足,发现从竞争和博弈两个词出发,似乎可以找到一些最优解。以下就是我的思考。

一、为什么做企业内部产品比较难受?

在日常工作中,经常看到企业内部产品产生这样那样的怨念:

  • 业务强势且指挥不当,对于需求做不做,优先级总有自己的看法
  • 业务管辖的范围太宽,想要参与产品设计,甚至交互设计
  • 需求做的时候催得急,上线后了没人指挥没人用也没人负责

久而久之,很容易丧失了对产品的“掌控感”,一身武功没地方使的憋屈打压着产品的积极性。

而做企业内部产品,也仿佛成了低人一等的辅助性存在。

那么为什么在内部产品身上会产生这么多憋屈呢?具体和两点有关。

首先是价值链中的话语权竞争。

如果把一个企业看成流水工业车间,业务方就是流水线૧上的工人和工头,而产品只是负责这个流水线的机器修理工,确保机器可以正常开动。

工人不上工,企业没饭吃,工头不上工,企业产出效率低,而机器的运行是正常现象,也不依赖于修理工活儿干得好不好。

在这个链条中,修理工的价值平时是很难被看见的,但只要机器停止运转影响到工人和工头,那责任也就大了,毕竟晚1分钟修好,就ਯ是晚一分钟的收入。

价值少但责任不少,就是内部产品的真实写照了。

从价值链的组成来说,业务从事的工作是能直接创造价值的基本增值活动,而产品是间接创造价值的辅助性增值活动。

正因为业务是属于创造价值的重要组成部分,所以腰杆更直,声音更ો大,更能理直气壮的要求别人来配合他。在这种理所当然的配合要求中,产品的难受就埋下了种子。

除了竞争,业务还擅长拉起一场零和博弈。

围绕公司更能出成绩的地方发力,无论是做主力还是打配合,一个成熟的职场人都不会抗拒。

但业务的要求配合,往往会演变成一场零和博弈——要么听你的,要么听我的,没有商量和共赢。

对于业务而言,往往跳过现场描述和细节场景,直接给到解决方案,甚至要指挥到交互细节,过程中大有不容置喙的霸气。

那这时产品的价值又如何体现呢?难道只能成为没有思想的的线框图生产机器吗?

确实在常规的工作流程中,产品是更偏辅助的职能,会用上支撑,助力这样的词汇来描述产品在业务上起到的作用,但这并Ο不代表我们的价值只有画图和沟通这一亩三分地。

所以,零和博弈的相处方式并不适合真的想实现自我价值的产品。

二、以上问题,我们怎么破解呢?

首先,回到提升竞争优势的环节。

虽然业务天然有价值链的话语权,但往往提出需求有如下问题:

  • 需求方向零散:提过来的需”求五花八门,什∏么模块都有。拉通时间线一看,几乎无法对需求做归类。汇报的时候只有挨个叙述效果,零散的程度,让不了解执行细节的大老板们非常瞌睡。
  • 需求描述不清晰:沟通的时候回答不了产品的灵魂5why,用语模糊,神色慌张,产品最后找▤到最直接的当事人发现可能想要的就不是这么回事儿。
  • 需求价值点模糊:无法用ˆ指标衡量需求产生的价值点,或者说需求的价值建立在各种理想但现在不具备的条件上。

还有部分业务方,由于个人经验,思维的局限,往往提不出需求,勉强要提只能说一些表现层的感受:这个按钮位置不好,几个页面跳转麻烦,操作时间长了一点,总是围绕ô用户体ક验打转。

或者干脆把老板的随口一提当成圣旨,以老板提的次数多少作为做与不做,需求是否高优的判断标准,导致很多无效需求就这样被生产出来了。

其实业务是没有办法替代产品的工作的,产品的思维能力,规划能力,设计能力,行业洞察等能↑力和技术是需要时光累积,历经高峰与低谷的沉淀,才能真正实现决策上的高胜率,方案上的高准确。

而只有到这个程度的产品,才能帮助企业信息化以扎实的,稳步的,较低的成本来发展。这样的理想情况,需要产品和业务,认可对方的价值,然后各司其职,有效配合才能实现。

而产品可以从两个方面入手,去解决价值链带来的话语权竞争问题。

一是规划主线,有节奏有重心地控制业务往前推移。

拉长时间来看,把握产品节奏比争论单个具体需求更有价值。

当产品主动把零散的需求归纳成线,逐步推进这条线的演化渐变,业务方才能够感受到:产品真的在做实事,而且是有规划有方法地在提升产品的价值,从而感受到产品角色的价值所在。

那具体怎么做呢?

从短时间来说,可以1月内定期完成一个“大事件”。

它可能是一个全新的模块,可Š能解决了一个新的业务场景遇到的问题,或者是服务于新的的角色。

具体举例:

  • 服务于角色的业务管理APP
  • 数据报表模块
  • 某个新业务的线上化全流程

只要是和以往不同的、有新鲜的成分的、相对独立的、工作量不小的都可以纳&#25c8;入大事件的范畴。

立下大事件的输出计划,对于产研团队可以尽早规划手头的工作,在大事件之外,再来规划其他较为零散的需求。

对于产品和业务方,在沟通的时候可以清晰的看到成块的内容的产出,同时也可以把业务老板的注意力拉到大事件上,让对方的注意力有所聚焦。

根据我们之前的经验,1个60分钟的汇报会议,按单个需求去陈列说明上线情况和上线效果,至少有80%以上的时间老板都是沉默不语漠不关心的,仅有几个关键词的触动能打动老板多问两句。

而按照大事件为主去沟通和陈述,可以有效避免这种平均用力留不下印象的情况。

除了按月去进行规划,季&#25d3;度甚至年度中,也可以有一条主线来做串联。

主线可以清晰的瞄准一个数据目标。

例如:

    œ

  • 支持100%的业务线上化
  • 支持某个角色100%登陆激活,越活跃率达到80%。
  • 支持90%的数据准确率

数据并不需要业务给出,而是产品可以为自己和身后的研发团队定下的一个志向。

那怎→么定呢?

根据系统化所处的阶段可以有一个简单的区分。ⓓ

业务在线了吗?如果还没有,首要是往业务跑通,支持更多业务闭环去做。

员工在线了吗?如果系统已经具备了业务闭环▣的能力,那么首要是帮助业务把员工使用率提起来。

通过日常观察得出,行政指令和管理手段并没有我们想象的那么有效。令出即随是不存在的,从管理强制但人人都规范性操作,还有很长的时间,这个过程中产品至少可以减少用户的负面体验,让系统推进更加顺滑。

↵数据在线了吗?员工开始正常使用系统,但并不代表产生的数据就会非常准确,中间还会有非常多的管理,调优,限制的工作要做,这也是产品可以提前预示预警,在产品方案上和业务管理方式上给出意见的地方。

其实有的时候业务没有那么专业,反而Ð是产品可以向前一步,在经验不足的情况下获得更高级别权利的机会。同时,也因为了产品的向前一步,可以让业务后退一步,形成重新的动态平衡。

二是产品对自己的定位可以再拔高一些。

半年前,我画过这样一张图,去分析系统未来可以发力੭的方向。

后面发现自己格局还是太小了,因为这个时候我的想法,还是局限在把自己定义为业务支持方,想着我去服务于某些价值更大,或者使用更频繁的用户,去用系统改善或者服务他们现有的工作流,解决他们最困难或者最耗时的问题,这样就能为系统信息化带来更大的收效。

但如果格局打开,想象如果我不仅仅是支持方呢?

我能否利用技术的力量去做那些业务堆人力也很难做到的事情呢?

我是否可以做一些功能,作为企业创收的核心Ô竞争力?

我是否可以做一些功能,只要使用就能为企业降本呢?

举个例子。个人从事的物流行业,某些场景下对于订单智能排线有着极度的依赖。这是在一定的数据量下,几乎是无法人力来完成的工作。那对自己来说,能不能先实现这块功能,然后拉着某个城市的业务去跑通,然后不停地向各个区域安利我们有具备的功能,可以服务于哪类客户。然后和业务通力合作,把这块收入真的做起来。

大家从事的职业有所不同,但是可以往科技改变商业的思路去靠。思考到底实现什么功能,才可以做ℜ到让企业因你而不同。

三、改变零和博弈的状态

首先要相信,你和业务一定是有着共同的关键目标的。

通过冲突模型,可以先来理解双方的替代选择,来确定强势和弱势。

对于业务方来说,大概率是可以压着产品按需实现需求的,毕竟一句“你们不懂业务”就可以压垮产品的1万句用户思维。而产品如果和业务方真的闹得很僵,走的人大概率是产品。

在这种天然的强弱关系下,可以从核心诉求入手,去驳斥业务的合理性,以及给自己找论据支撑。

首先可以从以下方面驳斥:

需求和关键目标的相关性:这个需求真的能实现关键目标吗?它们之间是怎么样起到作用的?如果要起到这些作用,业务要做的一些准备工作或者先决条件有没有具备?

需求对关键目标起的作用的大小:这个需求对于业务向上的动力真的可以起到那么高的作用吗?值得放到高优吗?有没有其他的业务认为重要但不紧急的,工作量很大的活儿也可以拿来先规划着?业务的近期,中期,远期规划如何,同时间内外部竞争和环境又会有什么样的发展,需要产品做什么样的准备?

设计方案对关键目标的影响:这样设计操作流程真的会影响关键目标吗?按钮放哪里,界面怎么排布会影响目标达成吗?同时也需要请业务放心,产品的设计一定不是空穴来风,是基于未来需求演化进行的框架设计。

其次产品也可以给自己找外援。

  • 用后µ果做外援:列出业务方案可能产生的最严重问题和后果,如果业务没法解决这个问题,他就不太会再去坚持了。
  • 用竞品做外援:同类产品的状态做外援。竞品做了的不一定适合我们,但也有比较大的参考价值,而没做的可能就要谨慎对待了。
  • 用用户做外援:找产品使用者的观点来支持。
  • 用数据做外援:找之前的相关或者类似的案例,来证明自己是对的。

另外要做到以上的点,核心要点是——比业务还要懂业务。

用我自己现身说法。有一块历史悠久但支持收入体量大的业务系统,主要处于维护状态,很少去做改动,也没人了解里面的背景和逻辑,但是由于业务量大,仍然会不时的有需求过来,所以决定还是有必要去深入了解下这部分的内容。

那我怎么做的呢?

首先我请资深的业务接口人从头到尾讲了一遍系统的前世今生,形成了初步的文档。

同时欢迎业务丢需求过来,不管做还是不做,我都会顺着需求的场景去了解现有的功能模块,也增加对于五花八门的业务形态的了解。

与此同时,也抽空几次去现场观察学习,实地看到大家的现场流转和系统使用是怎么对接的,当中又有什么问题。

通过这一系列的操作,我成为了业务心中的贴心小能手。直到现在,业务在这部分有了新的问题,不管是技术问题甚至业务问题,都会找到我询问解决方法,我真的成为了这个板块的专家,也自然在这个板块有了核心的话语权。

四、妥协后的选择

当然要说的是,有的时候环境并没有那么理想,哪怕做出了所有的努力,也会不得已按照业务规划的来走。

那么此时可以做的是什么呢?

放下情绪,正视最后的结果。

当时争论的过程一定是有意义的&#25d0;,虽然不能达成想要的效果,也可以奔着理解对方在想什么做努力。

和业务૤一起复盘。

当时争论的焦点,可以一一记录和保留。在功能上线后,拉着业务去复盘和对照。证明谁对谁错不是本质需求,重要的是双方可以在真实的结果面前,一起回顾为什么这个决定对了这个决定错了,背后的思考方式是什么,渐渐摸索出大家都能认可的思考方式,让业务更靠近产品思维,让产品也更能理解业务思维,也为大家的信任埋下基础。

五、总结

个人视野有限,只能以工作覆盖到的场景,也就是企业内部系统作为引子,来聊聊自己的思考。

但竞争和博弈的思路,应该不仅仅适用于企业内部产品这一环境,只要有资源的争夺,涉及多方合作的各种形式,都可以往这两个关键词上去延伸。

最后再回顾一下文章最后中给出的三点建议૮。

1)转化思路和行为,扭转自己的价值链地位

规划主线,有节奏有重心地控制业务往前推移。短期可以用“大事件”法则,中长期可以串联主线。拔高定位,直接避开在当前价值链的争锋,自己以企业最关心的指标为目标,以内部孵化的思路去新开辟一条价值链。

2)通过塑造专业力量在博弈中取得进展和认同

具体的冲突中,可以使用驳斥对方的观点,以及寻找自己观点支撑的办法来进行有理有据的沟通。日常的积累中,要努力做到比业务还要懂业务。

3)非理想情况下可以做的

放下情绪,正视最后的结果。

一起复盘。

做心中有光的产品,正能量的产品,你就会在不顺中先反省自己,改变自己,从自己出发去寻找出路。

这是我从前后两位领À导身上学到的道理,也和你共勉。

 

作者:假装是运营,微信公众号:SaaS学姐

本文由 @假装Χ是运营 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

Leave a comment

Your email address will not be published.