干了半年企业内部系统,这是我的三点感悟

7 评论 8871 浏览 39 收藏 9 分钟

编辑导读:每一个企业的系统各有不同,都会根据自己的业务产品进行调整。本文作者根据自己在企业内部系统方面的工作经验,总结出了三点感悟,希望对你有帮助。

说来挺不好意思,咱也不是啥产品新人,行业经验9年;从业这些年,2C2B啥都干过,资本每隔几年的热潮也都精准踩过,从020干到智能硬件再来健康APP,看到潮水来了又去。

遂发现2B才是本命,重新起航,跨过金融SaaS,物流SaaS,低代码平台。兜兜转转,人到中年,想轻松一点,选择一家大型上市企业,做企业内部系统,然而发现这里的工作,也是要有点东西。

入职半年多,和大家分享我的几点感悟。

一、大胆质疑“预设流程”

1. 刚来公司,发现几个别扭的预设流程

所有的需求都是业务对口人给过来,且排好优先级,优先级准则一般是“老板提的次数多少/老板是否关心”。一个需求给过来,往往会出现这样的温馨提示“这个老板关心,提了几次,优先做这个”。

再来,需求设计过程中,对口人会对设计合理性提出质疑,用“之前的习惯“”大家的认知”一些原因,试图影响产品设计。

最后,所有面向用户的界面,都没有埋点。所以需求落地后,从来都没有搜集到一线的信息,了解用户有没有在用,用户使用得如何。

2. 问题出在哪里?

1)业务对口方式

对口人应该有自己清晰的准则规范,这份规范代表着整个业务层的统一意志,然而现在是以个人偏好来决定。更可怕的是,支持这份偏好的理论,是老板的只言片语,而非和老板的坦诚沟通,所以代表我们筛选需求和判断需求优先级的逻辑,可能全是错误的。

2)信息流通渠道

在这个过程中,都是我们单向接收信息,业务不了解我们做了什么,花了多少代价,结果如何(甚至我们自己也不了解)。

3. 那我们做了什么呢?

总的来说,是通过沟通渠道的建立,慢慢优化整个对接的流程。

1)启动并优化月度例会

拉上业务老大,在例会中,陈述近期上线能力,展示上线后能力效果。

同时这样的形式,也倒逼我们重视用埋点等方式,搜集用户数据。

过了一段时间,我们发现罗列需求会让业务老板听得昏昏欲睡,整个陈述用老板的话说”太技术预研“,于是我们优化了2.0的形式。 以”钱花在哪里去了“为主线,对需求进行划分和陈述。

这样一来,能让业务老大明白钱花到哪里去了,围绕哪些目的花了更多的钱,让大佬在优先级上给到更多执行上的意见。

2)有目的的规划产品版本

在之前的会议中,业务老大是处于“事后被告知”的角色,体验仍旧不够好。

所以我们也计划能够做到事先知会。首先会评估每个需求的分类,同时以版本为中心,纳入不同分类的需求并控制比例。

例如 新业务支持/现有业务支持/精细化管理/体验优化几项,我们会按照不同比例排布,有些要鼓励甚至创新(新业务支持),有些要引导(现有业务支持/精细化管理)、有些要控制(例如体验优化)。

如果说之前解决了让老板知道钱花在哪里了,现在可以知道产品通过控制需求控制版本,达成了“钱用在了最有价值的事情上”的目的。

3)启动需求澄清会议

所有需求上会沟通,邀请业务主管一起参与,对需求的业务特性和背景进行梳理,对需求接受与否达成共识,对需求优先级初步形成共识。

二、用“影响”替代“顺从/硬刚”

在沟通的过程,业务和产研思考方式不同、角色不同,自然少不了冲突。

但要特别要强调的是,作为新同事,尽量不要用“硬刚”的方式来沟通。沟通的目的是先是为了赢得信任,然后在信任的基础上去解决问题。

面对上游业务,你的硬刚会让对方退避三舍或者反弹硬碰硬,无法真正达到沟通的目的。

但一味的顺从是否可取呢?也不是,甚至后果会比硬刚更严重。因为顺从=乖巧=没有自己的意见=没有自己的价值。

哪怕是面对内部系统,产品的价值也不仅仅是实现业务的需求,也不仅仅是上传下达,是用脑袋思考这部分的需求,把放到更大的框架里,放到信息化能为这部分解决哪些相关的问题,同时注意帮业务查漏补缺,多想一想这样设计的风险和后果。

比如业务对你提出,我们需要对下游供应商维护更多的字段,以便知道这些供应商的资质是否符合公司标准,便于总部管控。你立马应该想到“那我们是不是要通盘考虑供应商管理”的这些事情了?供应商准入、日常绩效、供应商准出等等环节,要不要坐下来讨论一下?不求马上有结论,但求产品和业务在反复沟通中,形成有这样的意识和共识。

三、拿结果,做闭环

1. 真正的结果和闭环

不要因为做的是内部系统,就不考虑拿到真正的结果了。

对外部产品而言,真正的结果和闭环是形成商业化。

内部的闭环呢?不仅仅是降本提效创收那么简单,说白了,这几个目标的达成是产品的功劳么?这能达成的先决条件,都是业务能把事情想清楚,主动去规划去告知产品如何做。

如果你不是企业内部的产品,相信你也会成为这个主动规划主动拉通的角色,那为什么我们做了企业内部产品,就要放弃职业中最有价值的部分呢?我们照样可以成为这个去思考和推动降本增收提效的人呀。

2. 那产品可以干什么呢?

1)打开自己,了解外部发展。

无论是自己公司的业务现场,还是外部公司,或者为类似场景服务的商业软件,都是你可以学习的榜样。

2)在1的基础上,主动发起需求。

企业的内部的发展,往往分为业务线上化——财务线上化——业务精细化运营的几个阶段。

我们可以看到每个阶段的企业重心,主动找到围绕这一重心的提升方案,我们是可以走在业务之前,为企业扮演“信息化咨询顾问”这个角色的人。

提供了更多的实施方案,征求业务同意,获得实施效果。久而久之,业务的创新的闭环就跑起来了,你和业务的信任闭环也跑起来了。

都说《定位》是对管理学影响深远的一本书,因为先有如何认识自己,才有如何去做。

希望我们每个服务于企业内部的产品,都可以摆脱“执行者”的身份,变为“发起者”,真正提升自己在企业中的价值,以及提升在产品这一职业中获得的荣誉感。

 

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

题图来自Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 好细好赞!持续关注

    来自广东 回复
  2. 想请教一下,内部业务系统一般如何做闭环?一般需要采集什么指标数据呢?我自己也是做内部系统,我这边的问题时,业务上在还没明确业务指标时,便要求我们把功能做上去了。我们做的事情无法衡量,业务也总觉得我们做的事情好像不重要,一直恶性循环…

    来自上海 回复
    1. 1.数据、流程、结构化思维,一般是业务童鞋的弱项,但却是产品经理的强项。所以在这些方面,需要我们向前一步做更多的事情。每个需求开始前,梳理背景——和业务确定需求目标——精准定义到需提升的指标并和业务达成一致。这三项事情,需要产品的主动性是依次递增的。到最后一步,更多的依靠产品自驱去定义指标,然后告知业务,形成统一的意识。不管业务有没有目标,我们心中得带着目标来设计,来和团队复盘上线后的效果。
      至于指标需要采集什么,从每个需求来说要单独设计。从整体系统指标,可以从上到下按照关键角色去询问,业务日常关注什么,产品也需要关注什么。关注的不仅仅是结果数据,也要关注过程拆解。比如业务老大最关心收入数,那么要猜测他会按照哪些维度去拆分收入,按照项目,按照业务部等等。

      2.业务很难感知到产品价值,往往是因为我们做的都是系统工程,一连串瞄准相同目标的需求共同作用,才能在某项指标上有一大步推进。而且这一连串的需求,往往散落在跨度很大的时间内,如果按照月度复盘,给人的感觉就是事情做了一堆,但每一项都没啥重点进展。所以需要产品用结构化思维,多多来定义【大事件】,把相同性质的事情定义成一个大的事项,按照大事项去做计划以及和业务宣讲。例如可以分为【系统安全】【数据看板】【角色效率提升】【账单准确率提升】【系统体验】等等,每次过会的时候。按照大事项来回顾和展望未来,这样你做的每一个事情都不再是孤立存在的,都是存在于某一个体系有它的意义,有它需要支撑的指标体现。
      另外,还会有一类工作不会产生直接价值,但是没他不行,这类叫做【底盘建设】,例如基础的数据维护,权限架构都属于这种,这部分可能需要持续迭代占用自用,也是需要让业务童鞋理解的部分。

      3.认知是很难改变的,可能要花费以年来计数的时间。中间要追求小胜,日常业务看到我们的及时响应,通过对行业信息化的学习给业务多带来一些新鲜的思考和想法,慢慢建立信任。要做到对方想做但提不出的事情,这样后面才有机会化被动为主动。

      4.做企业内部的产品比较困难,很容易被弱化成功能性产品,所以加油共勉往【企业咨询师】上的路上走吧~

      来自四川 回复
  3. 可以多更点文章吗 哈哈

    来自广东 回复
  4. 想请教一下,tob的系统,要怎么做埋点?实际生产环境的系统允许做埋点吗?还是需要和甲方交涉?

    回复
    1. 我们以前都是直接埋在产品代码里面

      回复
    2. 埋点方式:开发手工埋,采用第三方工具(免费的友盟,百度;付费的神策)。另外获取数据的方式不仅仅是埋点,有一些结果性质的数据,可以通过SQL查数据库获得~
      埋点环境:只有生产环境的埋点,才能反应用户真实的操作,所以非生产环境的埋点木有意义呀。至少我所经历的公司,没有一个是不允许的,哪怕是上市公司。
      埋点许可:我先理解这里的甲方是业务方吧~业务利用系统是解决问题的,有些数据是需要通过埋点才能获得,才能用数据告诉对方,你关心的这些问题有没有解决,解决得如何~

      来自四川 回复