总结我带人的独门方法：把控好结构就能有好下场

我带产品经理也好，带运营也好，都有一些独门方法。看上去不太能复制，与我的个人情况强绑定，但还是不妨一说。

• 这件事的长期目标（如果有的话）与用户价值是什么？
• 这件事的阶段性目标是什么？
• 针对阶段性目标，有哪些关键节点与思考重点
• 第一步做什么，第二步做什么（我通常只看两步，再根据交付来计算接下来的两步）

这意味着，我会在脑子里飞快地把任务结构给搭出来。大到一个为期半年一年的项目，小到一个功能设计。

比如说这次我带的人是（针对这个任务而言）经验不错的小顾，和经验欠缺的小刘。

我会先听小顾讲，把他表达的内容，套进我的结构里去判断，哪些是有质量的思考，哪些不对，哪些被遗漏了。然后，融合他的表达和我的结构，说服他在结构上达成共识，预先建立一套两个人都认同的任务结构。

而对于小刘，我会在安排任务的时候，直接把结构铺出来告诉他，把第一步作为任务下达给他，约定时间回收结果。

也就是，只要我能把控好结构，一是这个任务的结果大差不差，二是素质比较好的同事，也能在理解和推进结构的过程中，获得长足的进步。

但对于结构的把控，不仅仅是纸上谈兵。

一开始，我在脑子里飞快搭建出来的结构，大概率是不准确的，与实际情况不匹配的，必须在进展中及时修订。

这意味着，我需要每周开（多半是 1V1 的）小会，关注每一步的完成情况，理解每一个关键节点的交付。如果小顾和小刘走偏了，我要把他们拉回来；如果小顾和小刘卡住了，我要带头拿出解决方案；如果小顾和小刘遇到了一些推动力上的问题，我得帮他们解决问题；如果小顾和小刘做得很好，我会给他们热情的正反馈。

更重要的是，在每一步的结尾，以及每一个关键节点的复盘时，根据进展来调整结构，与他们同步新的结构并达成共识。

在合作中，如果对方很强，我不争功，而是积极地给他提供支持（因为我通常产品运营一把抓）。如果对方的工作有亮点但不全面，我会先表扬亮点，再在结构和重点上补足欠缺的部分。如果对方经验很少（我也带过不少新人），我会自己把方案框架飞快地做出来，交给他去落地执行。

这么搞，我能忙得过来吗？

没问题。

一方面是我手快，在这个行业里从未见过比我更快的人；另一方面是拆解任务，把体力活拆出去，我只做重脑力运算的部分。

比如说，我会提出大量的数据要求，用研要求，竞品分析要求，细化成一系列清单。我会自己把这张清单打几百字，作为任务下发，避免他们理解偏差。然后按期回收。

当我需要的数据、用研、竞品分析都摆在面前，且交付质量不错时（交付质量与我下发的清单质量强相关），我就能飞快地运算出当前步骤的结果，调整好下一个步骤的方向与节奏。

因此，我的工作习惯是不停地开会，尤其是开 2-4 人的小会。跟任务负责人 1V1，1V2 的小会，通常每周 1-2 场。如果我同时盯 10 个任务，大约每周 15 场，每场 1-2 小时。而我一天可以连续开 6 个会——没有压力，没有难度，反而因为大脑持续高速运转而兴奋得很。

在小会上讨论进展，输出结果，再转移到大会去通报结果，接受评审。

并且，我还有一个有意思的习惯是，小会通常会控制在 4 个人以内。人越少，越能够对着投影，快速进入心流，经常一边看方案一边改方案，就跟我自己动手画原型的感觉差不多，有时候甚至现场画框架原型给他们示范。

我曾经说过一句很刻薄的话：小会人数超过 4 个人的时候，如果大家都说话，则聒噪得很，讨论容易被低质量的发言带偏。如果有人不说话，你安静地坐在一边，你就是那个噪音，干扰我的思考。

所以我开小会时先清场，沉默的人离开，只留下最重要的一两个相关人员。

我这样的管理习惯，带 P6 也好，P7 也好，效果都很好。对其他人来说，可能觉得是不是太累了（不，我很开心），是不是管得太死了（任务没做好你负责？），是不是对自己要求太高了（我这 17 年练出来的麒麟臂啊）。