当前位置:首页 > 科技 > 正文

浅谈管理之“统一思想”

编辑导语:这篇文章讲述了作者对于管理的体会,和经历的三个管理阶段,作者认为,团队管理导向必须由“做事”变为“指导做事的原则”,并提出了想要推广和重点落地尝试的四个思想。一起来看看吧!

浅谈管理之“统一思想”

最近在制定11-12双月的okr,过程中,第一次尝试按照“用户分类”和“用户价值”进行框架拆分。而以往的okr,都是按照“事情的维度”进行拆分。

两者对比,直观感受清晰了许多,从“人等事”变为“人找事”,从“小事件”变为“大事件”,从“散点”变为“系列”。

结合过去,我第一次觉得制定okr不再是堆事情,而是像一个“固定”、有生命的框架。我觉得这个点在一定程度上算是管理上的“统一思想”。

那为什么我会突然产生了尝试的想法?“统一思想”又具体是什么意思呢?

接下来,我就结合自己过去的经历,尝试解答下这个问题。

一、从“盯事情”,到“搭框架”,再到“统一思想”

过去5年多,我负责的业务范围和团队人数都在逐渐变多,而我对于管理也慢慢有了不一样的体会。

1.“盯事情”阶段

从2016年到2020年6月份,整体上算是“事情规划”驱动。

简单来说,就是在最初我心中就有一个蓝图,即发展到成熟阶段,电商支撑体系的框架会有哪些产品线组成。而每一步的节奏,就是结合公司战略和业务发展,沉淀中台把蓝图实现。

所以,这个阶段,都是按照事情在牵引。目标很明确,人数也少,协同起来也没有大的问题。

2.“搭框架”阶段

去年6月份转转与找靓机融合,中台部门进行了长达近一年周期的系统融合工作。

在这个阶段内,发生了两个非常重要的变化:

  1. 系统融合,有较多的后遗症逐渐暴露出来,如系统稳定性变差、新老系统兼容系统超级复杂;
  2. 融合之后,团队人数变多,新人占了一半,且两地办公;

造成的直接结果就是,业务与中台对接的效率降低。对外,中台的信赖度降低;对内,团队员工的工作感受不好。

于是,在今年的三四月份,中台启动了内建专项,其核心就是在整个机制层面搭建一些框架。

如:

  • 在业务与中台对接重点,搭建平台化系统,承接业务项目需求和排查问题需求,减少业务与中台内部的接触点;
  • 将高频打断产研日常工作的重复工作,配置工具化,提升日常的效率和人的意识;
  • 系统性进行中台全域能力梳理与培训系列,提升产研内在的软实力;
  • 启动一些因成本大而一直积压的架构项目,把一些热点问题彻底解决;
  • 在每个方向设置产品运营角色,持续性跟进改善online问题;

所以,这个阶段,不再是做零散的事情,而是在“搭框架”,设置一些维度牵引事情,结构化解决这个阶段的效率和质量问题。

3.“统一思想”阶段

为什么会突然有这个观点?还得从最近两个事情说起。

第一个是,公司的产品学习小组,组织我们PM体验了一些公司线下产品交付的流程——让我们体会到了我们理解的“用户第一”并不完全是“用户第一”;

第二个是,看了公司顾问推荐的一本书《用户经营飞轮》——仔细了解亚马逊的亮灯工具后,被亚马逊的“用户第一”所震撼;

这两个事情,让我在“用户第一”这个维度有了不一样的感触。

我受到的启发有2个维度:

  1. 狭义的用户,即企业产品服务的产品使用者。
  2. 广义的用户视角,即从用户出发,关心各类用户的需求与痛点。其中包含产品使用者、业务方、团队内部人员等等。

其中第二点的感触,就是本文重点要说的。

以前不同阶段,很多事情都是被动发生的,即别人需要我们做什么事情。而在真正的用户需求洞察和价值衡量上,一直都是被动和弱参与的。也就是说,我们并未真正做到“用户第一”。

那真正的“用户第一”应该怎么办呢?我们应该主动出击,想中台所服务的所有用户是谁?需求与背后真正的痛点是什么?真实价值的大与小?

说到这里,大家可能会觉得这不是一个很正常的思维方式么?

没错,在单个人员层面,一些个人素养较高的员工,是可以达到这个水平的。但是,如果是团队呢?你如果想要团队的每一级、每个人、每个工种角色都具备这个思维方式,就必须在思想层面达成统一。

也就是说,团队管理导向,必须由“做事”变为“指导做事的原则”。

以前的“盯事情”阶段和“搭框架”阶段,其实还是不同阶段解决了不同的具体问题,只不过后者在解决问题上由点变成了线。

而“指导做事的原则”是什么概念呢?下边我就具体描述几个,也是接下来我要重点落地尝试的,大家可以理解下。

二、下个阶段,要推广的几个思想 1. 按用户看需求(用户是广义的)

这是最重要的一个思想,举一个okr制定的例子。

之前制定okr:

  • 业务视角驱动,一个个项目;
  • 对项目实现的用户需求,更多上游业务在关心;

后续制定okr:

  • 用户视角驱动,一个个需求,以及需求对应的价值;
  • 中台自己提供的终端产品,更加深入理解用户第一;
  • 中台支持的业务需求,也要穿透到上游去理解用户,同时自己承担一定程度的价值判断;

在后续制定okr的时候,按照用户视角和价值来分析,我们发现很多事情不再依赖业务信息。我们有了更多“自主性”,且能够发挥okr制定参与者的“主动性”,大家梳理事情起来,也更有“框架性”。

这个框架是有生命的,因为你的对象是用户,你会围绕他进行发散,而不再是一个个独立的事情。

这个思想接下来会围绕okr来进行落地。

2. 产品五步法
  1. 洞察用户:你要深入分析你的用户,感受用户的痛点,而不是停留在产品想当然的推测中;
  2. 价值预估:任何一个产品的诞生,必然解决了某些需求。而对资源投入方来讲,也需要对价值收益有个预期,体现在某些维度指标的变化上;
  3. 产品设计:这个就不聊了,产品基本功;
  4. 验证产品:用户需求match产品设计,预想的需求场景有没有被满足?实际的产品体验究竟如何?这个强烈建议产品更多体验第一现场。产品设计偏差很正常,但是对产品没有验证机制,没有修正,那才是灾难;
  5. 价值衡量:结合实际产品产生的影响,针对第二步“价值预估”进行结果衡量,也是产品闭环的最重要一步;

以上5个步骤,理解起来并不难,但是每个步骤真正都做了的人屈指可数,而每个步骤都做到位的更是凤毛麟角。当然我自己扪心自问,也做的不是很好。

对产品来讲,每个层级处理的事情难度不一样,但这个流程却都适用。

根据我对过去身边人的观察,发现高段位选手做事都是按照这个路径,本质其实就是闭环,往前闭环,往后闭环。

这个思想,我接下来会带领PM重点去实践。

3. 抓大放小

抓大放小,字面意思理解起来比较容易,就是一个人主要把精力放在盯有限的重点事情上。

但是,说起来容易,做起来就比较难。中台是中枢,在过去大部分时间,都是以业务满意度为导向,很多需求来者不拒,也就有了非常多的事情。

接下来,一定要在这块有所坚持,在需求层面价值判断把好关,将有限的资源更多聚焦到“大”的事情。另外,抓大放小也要体现到责任分工上,不同层级关注自己需要关注的“大”事,也要擅于使用搭班子方式,将“大”的事情进行分摊。

这个思想,也会在接下来okr里面有所体现。

4. 画场景地图

这个思想是唯一一个技术层面的思想。

B端产品很复杂,尤其是在一些重履约的场景。在产品形态上,不仅要考虑前端与后台交互、线上与线下交互、人与系统交互,同时还要面对“人”的不稳定操作,以及特殊场景对系统逻辑的特殊分支。

这时一旦有某个环节出现问题,产品就会表现出很多口碑问题、效率问题、资损问题。例如过去我们在一些线下场景,就会经常发生因各种原因找不到货的情况。

思考解法,最终我们得出了一种可能有效的方式,目前正在进行积极的尝试。

那就是“画场景地图”,也叫“场景还原”,把客观的现况(实际流程、系统当前流程)用流程图非常细地画出来,体现所有角色、所有流程分支、所有关联操作和逻辑规则。后续每一次功能的新增与修改,都可以按地图review下全局影响,当然也可以按照地图找各个节点去挖掘用户痛点。

三、保障思想统一

最后,针对上述的思想,理解层面我估计大家都没有问题。但是思想是一种思维习惯,在形成之前,我们必须有对应的机制来保障。

这个机制无它,就是过程节点反复check,结果跟绩效挂钩。

凡事不易贪多,接下来一段时间内,就聚焦以上4个思想的实践。这也是接下来我最重要的工作。

你可能想看:

有话要说...

取消
扫码支持 支付码