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

假装是运营 2023-08-01 21:54:38

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

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

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

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

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

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

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

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

2. 问题出在哪里？

1）业务对口方式

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

2）信息流通渠道

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

3. 那我们做了什么呢？

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

1）启动并优化月度例会

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

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

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

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

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

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

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

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

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

3）启动需求澄清会议

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

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

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

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

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

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

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

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