编辑导语:这篇文章讲述了作者对于管理的体会,和经历的三个管理阶段,作者认为,团队管理导向必须由“做事”变为“指导做事的原则”,并提出了想要推广和重点落地尝试的四个思想。一起来看看吧!
最近在制定11-12双月的okr,过程中,第一次尝试按照“用户分类”和“用户价值”进行框架拆分。而以往的okr,都是按照“事情的维度”进行拆分。
两者对比,直观感受清晰了许多,从“人等事”变为“人找事”,从“小事件”变为“大事件”,从“散点”变为“系列”。
结合过去,我第一次觉得制定okr不再是堆事情,而是像一个“固定”、有生命的框架。我觉得这个点在一定程度上算是管理上的“统一思想”。
那为什么我会突然产生了尝试的想法?“统一思想”又具体是什么意思呢?
接下来,我就结合自己过去的经历,尝试解答下这个问题。
一、从“盯事情”,到“搭框架”,再到“统一思想”过去5年多,我负责的业务范围和团队人数都在逐渐变多,而我对于管理也慢慢有了不一样的体会。
1.“盯事情”阶段从2016年到2020年6月份,整体上算是“事情规划”驱动。
简单来说,就是在最初我心中就有一个蓝图,即发展到成熟阶段,电商支撑体系的框架会有哪些产品线组成。而每一步的节奏,就是结合公司战略和业务发展,沉淀中台把蓝图实现。
所以,这个阶段,都是按照事情在牵引。目标很明确,人数也少,协同起来也没有大的问题。
2.“搭框架”阶段去年6月份转转与找靓机融合,中台部门进行了长达近一年周期的系统融合工作。
在这个阶段内,发生了两个非常重要的变化:
造成的直接结果就是,业务与中台对接的效率降低。对外,中台的信赖度降低;对内,团队员工的工作感受不好。
于是,在今年的三四月份,中台启动了内建专项,其核心就是在整个机制层面搭建一些框架。
如:
所以,这个阶段,不再是做零散的事情,而是在“搭框架”,设置一些维度牵引事情,结构化解决这个阶段的效率和质量问题。
3.“统一思想”阶段为什么会突然有这个观点?还得从最近两个事情说起。
第一个是,公司的产品学习小组,组织我们PM体验了一些公司线下产品交付的流程——让我们体会到了我们理解的“用户第一”并不完全是“用户第一”;
第二个是,看了公司顾问推荐的一本书《用户经营飞轮》——仔细了解亚马逊的亮灯工具后,被亚马逊的“用户第一”所震撼;
这两个事情,让我在“用户第一”这个维度有了不一样的感触。
我受到的启发有2个维度:
其中第二点的感触,就是本文重点要说的。
以前不同阶段,很多事情都是被动发生的,即别人需要我们做什么事情。而在真正的用户需求洞察和价值衡量上,一直都是被动和弱参与的。也就是说,我们并未真正做到“用户第一”。
那真正的“用户第一”应该怎么办呢?我们应该主动出击,想中台所服务的所有用户是谁?需求与背后真正的痛点是什么?真实价值的大与小?
说到这里,大家可能会觉得这不是一个很正常的思维方式么?
没错,在单个人员层面,一些个人素养较高的员工,是可以达到这个水平的。但是,如果是团队呢?你如果想要团队的每一级、每个人、每个工种角色都具备这个思维方式,就必须在思想层面达成统一。
也就是说,团队管理导向,必须由“做事”变为“指导做事的原则”。
以前的“盯事情”阶段和“搭框架”阶段,其实还是不同阶段解决了不同的具体问题,只不过后者在解决问题上由点变成了线。
而“指导做事的原则”是什么概念呢?下边我就具体描述几个,也是接下来我要重点落地尝试的,大家可以理解下。
二、下个阶段,要推广的几个思想 1. 按用户看需求(用户是广义的)这是最重要的一个思想,举一个okr制定的例子。
之前制定okr:
后续制定okr:
在后续制定okr的时候,按照用户视角和价值来分析,我们发现很多事情不再依赖业务信息。我们有了更多“自主性”,且能够发挥okr制定参与者的“主动性”,大家梳理事情起来,也更有“框架性”。
这个框架是有生命的,因为你的对象是用户,你会围绕他进行发散,而不再是一个个独立的事情。
这个思想接下来会围绕okr来进行落地。
2. 产品五步法以上5个步骤,理解起来并不难,但是每个步骤真正都做了的人屈指可数,而每个步骤都做到位的更是凤毛麟角。当然我自己扪心自问,也做的不是很好。
对产品来讲,每个层级处理的事情难度不一样,但这个流程却都适用。
根据我对过去身边人的观察,发现高段位选手做事都是按照这个路径,本质其实就是闭环,往前闭环,往后闭环。
这个思想,我接下来会带领PM重点去实践。
3. 抓大放小抓大放小,字面意思理解起来比较容易,就是一个人主要把精力放在盯有限的重点事情上。
但是,说起来容易,做起来就比较难。中台是中枢,在过去大部分时间,都是以业务满意度为导向,很多需求来者不拒,也就有了非常多的事情。
接下来,一定要在这块有所坚持,在需求层面价值判断把好关,将有限的资源更多聚焦到“大”的事情。另外,抓大放小也要体现到责任分工上,不同层级关注自己需要关注的“大”事,也要擅于使用搭班子方式,将“大”的事情进行分摊。
这个思想,也会在接下来okr里面有所体现。
4. 画场景地图这个思想是唯一一个技术层面的思想。
B端产品很复杂,尤其是在一些重履约的场景。在产品形态上,不仅要考虑前端与后台交互、线上与线下交互、人与系统交互,同时还要面对“人”的不稳定操作,以及特殊场景对系统逻辑的特殊分支。
这时一旦有某个环节出现问题,产品就会表现出很多口碑问题、效率问题、资损问题。例如过去我们在一些线下场景,就会经常发生因各种原因找不到货的情况。
思考解法,最终我们得出了一种可能有效的方式,目前正在进行积极的尝试。
那就是“画场景地图”,也叫“场景还原”,把客观的现况(实际流程、系统当前流程)用流程图非常细地画出来,体现所有角色、所有流程分支、所有关联操作和逻辑规则。后续每一次功能的新增与修改,都可以按地图review下全局影响,当然也可以按照地图找各个节点去挖掘用户痛点。
三、保障思想统一最后,针对上述的思想,理解层面我估计大家都没有问题。但是思想是一种思维习惯,在形成之前,我们必须有对应的机制来保障。
这个机制无它,就是过程节点反复check,结果跟绩效挂钩。
凡事不易贪多,接下来一段时间内,就聚焦以上4个思想的实践。这也是接下来我最重要的工作。
有话要说...