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