“现场”与体验是最好的管理

01

—

最近听到一个职场故事。

一个非常资深和有能力的高管被挖到某公司后，被新公司寄以厚望，要TA亲自领衔某款产品的开发和销售。

结果这位高管负责的产品槽点满满。

从材料、设计、外观都毫无亮点，产品毫无吸引力和用户体验差。它是一个在指标上都“合格”的产品，但绝对不是在销售上有任何优势的产品，销量自然不好。

相比之下，该公司新开发的其它产品在销量上都有了突破。

我了解了一下这位高管的背景，瞬间明白为什么会这样。从某种类型的企业出来的人，习惯了一直坐在自己的办公室忙乎，甚少接触真实的市场，也不会去生产现场了解制作过程和工艺。

TA在产品上的投入并不少，为了这款产品的设计、制作和上市，也没少加班，同时也要应对作为企业高管的各种管理事务。

但TA做出来的东西，大家的最普遍的评价就是“不接地气”。

TA在这款新产品上的玩法完全就是TA在以前的公司的套路，这些套路也为TA在之前的公司获得了很大的成功，要不然也不会被高薪挖角。

但在新的公司面对新的市场、新的产品类别，客户画像、市场环境、品牌力、产品特点、销售渠道完全不一样，所以翻了车。

这样的领导很多。他们确实也很忙，但绝大多数时间都坐在自己的办公室内，开各种会议，讨论各种二手信息，闭门造车。

在某些公司，这样做也许没什么，公司通过强大的品牌力、成熟的流程、充足的资源，事情不会错到哪去。

但对于需要快速响应、紧贴市场和用户、处于品牌初创阶段的公司，这种“离地”的领导就容易翻车。

体验是最好的管理

精益，除了提出了可视化、限制在制品和观察与改善流动，还提出了现场的理念。一个好的领导，要在“现场”，要多接触一手信息，才能充分理解问题，和团队一起做出正确的决策。

对于我们做软件交付的，作为领导和管理者，就是要多接触客户和体验开发者的工作。

我从2021年6月份负责我们公司的云平台自动化开发团队以后，为了更能理解团队成员面对的具体挑战和困难，我一直在体验团队成员需要承担的各种开发和运维的工作。

通过这个过程，我得以更快地掌握这项工作所需要的知识和技能，也能和团队成员“说得上话”，和他们能够进行“同频”沟通，从而可以和团队一起更容易地理解和解决问题，优化流程。

比方说，我们在2022年定下了要把运维工作自动化的目标——要把所有工单尽可能地自动化或自助化。

同时，我们也要招聘扩充团队。

由于我们的主要职责是自动化开发，在招聘时，应该优先考虑应聘者的开发能力。但是负责运维的小组长提议，我们还是需要有一到两个组员是聚焦在运维上的，为用户更及时地解决问题，提供更好的服务体验。

我一开始是拒绝的，因为我们的目标是运维自动化，随着自动化的实现，我们需要人工运维的工作应该越来越少，而不应该再新聘人手只负责运维。

但是，我经过体验了几周运维工作后，理解了这位小组长的提议。

首先，我们的自动化是有很多障碍的，我们不是只有开发人员不足这一个问题，云平台上有很多我们需要的API并没有开放或支持，这不是短期能迅速改善的情况；其次，有些工单的处理过程非常复杂，不可能完全自动化，顶多只能实现部分自动化，要完成整个过程，还是需要人来进行拼接。

有些非标准化的工单和咨询，需要运维人员和用户非常充分的沟通去理解问题，并和平台方协调，非常耗时。

最后，我同意了运维小组长的提议，我们招聘标准不能只侧重于开发能力，如果有熟悉云平台运维的，也要考虑。

对于团队提出的各种挑战和提议，我发现在体现前后，感受是不一样的。通过这种方式，我也更能获得团队的信任，特别是团队里技术牛人的认可，我自己的信心也大大提高。

下一步，我将体验团队磨合了几个月的新开发框架和模式下的开发工作是否顺手。

说这些，并不是为了自吹自擂。其实我做的还远远不够。我对于与团队一起持续改善内部流程和工具，是比较擅长的。但对于接触用户，从他们的角度改善用户体验，还做得远远不够，是我要花更多力气的地方。我自己也有上面提到的那位高管的习气。

另外，经常有人说，管理者不应该事事亲力亲为，把团队的活揽在自己身上，这样不光产出有限，自己和团队都无法成长。

我完全同意，因为管理者自己的输出肯定是有限的，无法有效带领团队进行输出，就会失去了杠杆，事倍功半。

但是我进行各种体验，并不光是为了把活干了，弥补团队人手不足的问题，而是为了改善，目标是完全不一样的。