管理 on 翟志军 Jack Zhai

小明说：代码是测试通过了，但是修改了一行代码，等和其他人的功能一起上吧

Sun, 07 Jul 2019 00:00:00 +0000

小明修复了 Web 后端的一个不大不小的 Bug。只修改了一行代码。并在 UAT 环境测试通过。

可是，当我问他为什么不发版时，他说：

代码是测试通过了，但是修改了一行代码，等和其他人的功能一起上吧

在我不长不短的职业生涯中，经常遇到这样的小明。我已经见怪不怪了。

笔者的观念是：如果变更的代码上线不会死人，能上就上。如果每次发版都很痛苦，那么先把发版难这个问题解决。至少也要朝着这个方向前进。

为什么我会这样觉得呢？因为：

程序员写出来的代码，只有真正运行在生产环境上了，才算完成工作。测试通过的代码不上线，就是库存。这在丰田称为“库存的浪费”。也就是不发布到生产环境，你为什么要写出来？还测试通过了。
如果一个分支停留太长时间，分支之间发生冲突的可能性就越大，而解决冲突这类操作对于产品的最终用户来说，是毫无价值的。用丰田生产方式的话说来，就是“动作上的无效劳动”。再者合并冲突过程容易再次引入缺陷。所以，应该避免分支停留过长时间。这个“过长”怎么定义，需要具体问题具体分析。

后记

其实，我很理解小明说出这样的话。大多是因为对部署没有足够的信心。对于没有自动化部署的团队来说，属于正常现象，你不能将责任推到一个人身上。而解决部署难的问题，不仅在管理上下功夫，还要在技术上下功能。

从文具的购买看一家企业的效率

Mon, 27 May 2019 00:00:00 +0000

Photo by **Leon Macapagal **from Pexels

团队每天都会面对着看板开早会。过完卡后，会有一些技术问题需要进行深入讨论。大家你一句我一句，实在说不清了，我就想从桌子上拿一支笔将想法画出来。

但是在会议室找不到可用的笔，然后跑到文印室也找不到。这样，几分钟过去了，5个人团队就干等着我找笔。实在找不到，我们只得打开投影仪，打开 Windows 系统自带的画图软件画起架构图。

在经历过几次这样的痛苦后，我决定找办公室负责采购的小姐姐说这事。小姐姐心好，从其它地方拿笔到我们经常早会的会议室。

最后小姐姐补充：本月的文具已购买，下月我再向经理审批再买哦。

我当时没有反应过来，没有理解她这句话的意思。

过了两个星期，我发现又没有笔可用了（后来发现是我在文印室没有找仔细）。我再次找到小姐姐。并跟她说：能不能多放一些笔？

小姐姐说：笔是统一放在文印室的，因为不知道哪个地方需要用。所以，你们有需要去文印室拿哦。

我说：文印室也没有了，没找到。

然后我实在没有忍住，一连串说了几句文具的成本是多低，节约人的时间，提高工作效率，可以节约更多的成本。

她似乎没有听进去：之前放了一支，你们又丢了。

我说：就一支，是不是别人拿到别的会议室了？

她说：不知道。我买文具是要经理审批的。

我这才想意识到，她没有决定权。问题出在经理那里。为什么经理不允许买呢？

从小姐姐那里了解到原来有一次小姐姐按往常一次提流程买笔和本子。谁知经理说：纸巾每月买可以理解，但是为什么笔和本子每个月都要买。

这就是现在为什么小姐姐很少买笔和本子的原因了。

最后，我也不提笔的事情了。因为我单独找经理谈这个事情，在当前的环境下，会被人说“跨级”。再者对小姐姐可能也不好。

谁知，过了两个星期，事业部的副经理从会议室跑出来，问：有没有见到大头笔？

我苦笑地说：没有。

苦笑是因为我猜到发生在我身上的事，也会发生在别人身上。只不过没想到，发生在了经理级别上而已。

后来，也不知道他有没有找到笔。但是那个会议室还是偶尔找不到笔。

不知道读者朋友看出来问题没有？笔者认为关键问题出在：

提效不一定非要花巨资买个 DevOps 平台，效率发生在每一个企业运营的细节。
软件工程是知识密集型工作，人与人之间需要高效沟通。那么笔、白板（或纸）就是即高效，成本又低的工具。说实在点，工作少出现一个沟通失误，节约下来的钱就可能买下整个公司几年的笔了。小姐姐没有认识到，经理也没有认识到。
企业文化让看到问题的人不敢提问题。
你没有想到吧，一个负责采购小姐姐的决定，也可能影响一家公司的效率？这里没有贬低小姐姐的意思。每个岗位都有它的意义。

这些问题怎么从根本上解决？

笔者认为，关键点是没有人从效率的角度考虑公司内部的行为。小姐姐考虑的是下次提流程时，经理不会问那样的问题。经理疑问了文具为什么用得这么快，但是并没有深究（几支笔的事情，当然没有必要深究）。其他人（可能）不想惹事，也不会找相关的人提“笔”的事情。在很多企业奉行谁提问题谁解决。有时我怀疑这句话对企业是有害的。

怎么解决呢？我只说一句：解铃还须系铃人。

一定能解决吗？我不知道。因为我也只是觉得可以解决。所以希望和更多人交流解决之道。

我把这些写出来，很有可能犯“政治错误”，得罪某些人。我还是要写出来。因为我相信还有不少企业发生类似的事情。不敢面对，怎么进步。

如果给你一支外墙清洗工程队，你会如何管？

Sun, 26 May 2019 00:00:00 +0000

本篇文章只是笔者看到外墙清洗工后，在管理方面思考的总结。笔者是外墙清洗行业的外行，所以，本文可能存在一些错误的假设。期望这些可能错误的假设不影响管理方面的思考。

引发思考的起因

某天上班，仰头看到大厦清洗外墙工人悬挂在20层楼的半空中作业，除了觉得他们危险外，脑海浮现一个问题。如果作为外墙清洗工的管理者，我们如何保证大厦的外墙的每一处被清洗干净了。

我们经常听管理者这么说：

我只要一个结果，不管过程。

可是这个“结果”是什么呢？

谁来定义“结果”

回到外墙清洗的管理，作为工程队的管理者，我们要的结果是什么呢？

面对这个问题，我们要马上回答的并不是“结果”的定义是什么。而是要问：这个问题本身应该由谁来回答。是由老板回答、管理者回答、还是由清洗工回答（我们假设管理者与老板这两种角色由不同的人担当）？

也就是说，对于不同角色的人，对于“结果”的定义是不一样的。

清洗外墙作为一门生意，结果当然是以最低成本赚最多钱。对于这一点似乎不用定义了。

但是，这个结果只是“老板”希望自己得到的结果。它与管理者希望清洗工给的结果是两回事。如下图所示。

至此，我们发现“谁来定义结果”这个问题，应该换个问法：谁来确定管理者想要的结果与老板想要的结果之间的关系？

笔者认为应该由管理者与老板共同确定。

如何确定不同层次结果之间的关系

管理者想要的结果与老板想要的结果处于不同的层次。那么如何确定不同层次结果之间的关系，这个问题由老板与管理者共同回答。

如果是把清洗外墙是一次性的生意，结果很准确，就是收到甲方的款。不论外墙是否真的被清洗干净了，因为贿赂验收人员我们一样能得到想要的结果。我们甚至可以设置一个部门专门搞定验收人员。这不是本文要讨论的范围。

如果基于企业长期发展的考虑，我们希望能把洗墙这项业务做好。最终会得到老板想要的结果。

本文，我们假设保证大厦外墙的每一处都被清洗干净是长期正作用于老板想要的结果的。如下图所示。

接下来，下文所说的“结果”均指管理者的结果。

如何验证结果

绕了一圈，终于把结果定义好了。现在咱们把“结果”定义为在文章开头就提了的：

保证大厦外墙的每一处都被清洗干净

但是我们如何验证这个结果呢？我们的管理者不可能也把自己挂在高高的外墙眼睁睁地检查清洗工洗过的每一处。就像产品经理不可能自己打 IDE 一行行的检查程序员的代码。

如果管理者无法做到，加一个监工不就行了？但是谁又来监督这个监工的工作呢？也就是谁来保证监工的工作做到位了呢？

还有一种办法：让工人相互监工。这样，花两个人的工资，顶三个人的活。可是，在企业里待过的人动下脑子都知道这个方案就不可靠。他们会串通的嘛。因为“偷懒”符合他们的共同利益。（在信息透明度高的情况下，让人相互监工是可行的。比如结对编程。）

以上都是臆造出来的解决方案。都是基于“监工”的模型。看看我们的身边，是不是也是这样？

回到我们的问题本身：如何确保大厦外墙的每一处都被清洗干净？我们换一种方式解决。

如果采用“激励”的方式呢？假如请了10个清洗工人，等最后清洗完成后，对这10个清洗工人的工作进行ABC评级。得A的人可以得到原来薪水的1.2倍，得B的人保持不变，得C的人是原来薪水的0.8倍。是不是感觉这套路很熟悉？

“激励”的模型虽好，解决的是清洗工人的积极性问题，还是没有解决我们的根本问题：如何验证结果。

定期验收

也许我们可以把“每一处”的标准降低。在所有的清洗工中，选一个最合适的人作为清洗工组长，让其工资高于一般的清洗工人。组长的其中一个重要职责是定期对玻璃进行验收。至于定期的周期设为多长，涉及到工作的反馈周期了，属于另一个问题了。暂不讨论。

虽然这样管理者不用自己被挂在外墙，但是“保证大厦外墙的每一处都被清洗干净”的结果强依赖于组长的责任心。

这个模型的缺点是管理者想要的结果必须强依赖于一个很不稳定的因素：组长的责任心。

用对比法解决

突然有一天，我再看大厦的时候想到，用清洗前和清洗后的大厦照片对比不就可以了吗？

也就是在保证环境一致的情况下，在清洗前拍一次，在清洗后再拍一次。只要照片足够高清，你想对比多细节都可以。更进一步，我们甚至可以使用软件进行自动对比。

使用此种办法，除了解决以上方案的缺点，还使得“保证大厦外墙的每一处都被清洗干净”的结果从模糊变成准确被量化了。

这意味着什么？

更短的反馈周期：每天都可以当天的清洗情况。这对于能否按时完成工作非常重要。
更准确的定义“干净”：怎么样才算干净，一对比就知道。同时，清洗工之间绩效对比也有了。
成本更低的检查“每一处”：由于只需要坐在电脑前进行检查，成本会低很多。可能不需要多发一份组长的工资了。

最后，笔者想找同一建筑的两张图进行对比，但是实在找不到。读者朋友就脑补一下吧。

使用对比法就是最终答案了吗？不是的。也许，将来成本更低的办法是使用外墙清洗机器人会代替人工。也许这样更容易得到老板想要的结果。

更甚至于搞个 AI 外墙清洗，然后融个资？笔者调皮了。

后记

以上内容虽不能完全重现笔者的思考过程。但是大体思路就是这样的。这个思考过程，在软件工程方面，笔者认为是相通的。

产品经理必须思考做出来的软件功能是否正作用于老板想要的结果；必须想办法加快反馈；必须想办法更低成本的检查程序员的工作结果；必须想办法让所有人准确理解需求。

同时，本文还有很多方面没有讨论，比如我们是否需要以及如何关心每个人想要的结果；清洗工也是人，企业中的人文关怀问题等等。

最后，说明一下，我并不想挑战别人的专业。以上只是讨论。欢迎大家交流

参考

玻璃外墙清洗的准备工作与注意事项：http://www.fjyybj.com/news/517.html
外墙清洗机器人现身多幢大楼，清洗前后泾渭分明！ https://juejin.im/post/5c73c3a251882562e5445024
人类真的是趋利避害的吗？：https://www.zhihu.com/question/60711385

活多人少，每个需求都紧急，多数项目延期，怎么破？

Fri, 01 Mar 2019 00:00:00 +0000

注意，下文所说的“老板”通常指业务提出方。

问题描述

上个星期，在持续交付2.0的群中，群主发出一个别人的提问。在我看来，这个问题在软件工程领域非常的典型，所以想单独写一篇博客来讨论。以下是问题原文：

我是一个开发部门的管理人员，团队规模还较小，开发需要兼任测试和部分应用运维的工作，但公司业务条线不算少（差不多有4个左右，目前部门中基本是按每个条线分配2-3个开发，出现某个组资源不足以满足需求时再进行调剂），之前这么做还算稳定，因为各业务对交付频率的要求一般很低，但近期各业务都提出了一个较紧急的项目需求，而且都还无法推迟或拒绝，资源一下子变得非常紧张（如果可以推迟某一个当然就会有富裕资源，但是这些项目由于各种原因公司都不能放弃，也很难推迟），如果依然每个组独立完成自己的项目，可能导致大部分项目因无法按时交付失败，而且每个组还必须保留少部分资源用于处理日常业务，如果临时招聘也来不及做培训，我们暂时是让资深一些的程序员和管理人员参与多个项目中的开发，但仍不能完全解决问题（他们抱怨任务太多都来不及测试），请问帮主遇到这类情况应该如何协调？

提问者所说的情况，在现实中，太普遍了：

（无法拒绝的）紧急需求的插入，打乱原有的步骤
开发除了需求的开发，还需要处理日常业务
人员不足：临时招聘也解决不了
开发人员报怨任务太多，来不及测试（就上线？）
项目无法按时交付

可以看出，“人员不足”是“项目无法按时交付”这个“果”的其中一个“因”。而提问者希望通过业务线之间人员的调剂和临时招聘的方式增加人员，但仍不能完全解决问题。笔者每当听到增加人员的信息，都会想起《人月神话》所说的：向进度落后的项目中增加人手，只会使进度更加落后。

而从提问者口中也了解到，原来人员还算足（感觉是刚刚好），只是因为出现了一个无法拒绝的紧急需求，问题就暴露出来了。

问题解决

面对这样的问题？你是如何解决的呢？以下是我个人提出来的解法，不一定对，只做交流：

第1是把当前工作的优先级排出来

把所有的工作内容（包括日常维护和新功能实现）列出来，同时，也要找到这些工作的交集（避免重复开发）。工作内容列出来后，确定它们的业务价值及优先级，并预估其开发难度。有些新功能是老板直接下发的，但是实现难度过高且业务价值又不高（团队及产品经理觉得），能和老板谈就和老板谈。这部分工作是我觉得最难的。

这个工作的优先级一定要让老板看到。主要是避免老板中间随意的插入需求。当然，有时需要向现实妥协，但不是每次。同时也要让所有人达成共识，遵守这个优先级。

第2是找出团队平时工作中最耗时的环节（瓶颈），想办法在这个环节上减少耗时（自动化或者别的办法）。一般来说，经常工作在这个耗时环节的人会知道如何优化它。

第3是慢慢让人可以流动

意思是人没办法调剂到其它项目，通常是因为他不了解其它项目（业务或者技术）。所以，在平时，就要注意将项目的“知识”尽可能准确地传递给更多人。当然，也可以定向的传递。具体操作方式要看团队平时的协作方式。

最后，1，2，3步需要重复执行，同时1，2，3步也不是顺序的。

笔者提出这样的解法并不是笔者猜的，而是有依据的。依据如下：

人员不足只是表象，我们怎么知道是真的人员不足，还是没有真正发挥每个人的最大潜能呢？第2、3步是为了让每个人发挥最大的潜能。而工具方面，个人建议通过看板可视化人员的工作内容，来达到了解当前资源状态的目的。
即使每个人的潜能都发挥到了极致，但是还是出现人员不足的情况啊。这就是第1步要解决的问题。这时，我们要学会舍弃。但是为什么老板就不会舍弃，老爱插入一些所谓的紧急需求呢？个人认为是因为老板不了解你当前的工作内容及其优先级。所以，这个优先级一定要和老板达成共识。

小结

当我把解法提出来了，群里的同学就提出了质疑：如何确定老板提出新功能是业务价值不高的？毕竟老板从整个公司考虑问题的。

这位同学提出了一个软件工程领域内经常发生的问题：执行者怀疑业务提出者提出的需求的价值。个人觉得质疑是好事。但是质疑之后，双方有没有讨论及讨论结果才是关键。讨论了就容易形成共识，有了共识，大家才好力往一处使。题外话，“我只要结果，不管过程”的管理理念的适用范围是拿出来讨论的。

最后，以上解法，不一定适用所有的情况。比如在外包项目管理中，可能就不适合。

《孩子把你的手给我》给管理带来的启示

Tue, 27 Mar 2018 00:00:00 +0000

前两年看完这本书时，我的个人感受：带小孩和带团队有几分相似。要培养他们，要处理他们之间的矛盾，一样要处理他们的情感，还要给他们发言权……然而，带小孩和带团队都知易行难，大家相互勉励。

现实中的康威推论——IoT系统为例

Fri, 09 Mar 2018 00:00:00 +0000

是推论，还是定律，不重要

如何进行有效的指导，如何成功的分配任务

Mon, 19 Feb 2018 00:00:00 +0000

卓越管理的秘密

如何充分“使用”研发团队新人

Mon, 15 Jan 2018 00:00:00 +0000

缩短出活时长的目的不是为了让他们有更多时间加班。目的是提出团队的生产力。这样我们才有更多时间陪家人

一个软件工程师对职场、管理、企业的思考——上篇

Sat, 06 Jan 2018 00:00:00 +0000

一个软件工程师的思考

为什么站会会成为形式

Sun, 07 May 2017 00:00:00 +0000

想实践站会，但是过程非常痛苦

关于“以结果为导向”的管理方式的碎碎语

Fri, 20 Jan 2017 00:00:00 +0000

为什么要以结果为导向？

老翟书摘：《50大管理难题解决方案》

Wed, 20 Jul 2016 00:00:00 +0000

初做管理，想快速成长，而不想只依赖磨时间来带动“管理”的能力成长。所以，找到此书。