管理

小明修复了 Web 后端的一个不大不小的 Bug。只修改了一行代码。并在 UAT 环境测试通过。 可是，当我问他为什么不发版时，他说： 代码是测试通过了，但是修改了一行代码，等和其他人的功能一起上吧 在我不长不短的职业生涯中，经常遇到这样的小明。我已经见怪不怪了。 笔者的观念是：如果变更的代码上线不会死人，能上就上。如果每次发版都很痛苦，那么先把发版难这个问题解决。至少也要朝着这个方向前进。 为什么我会这样觉得呢？因为： 程序员写出来的代码，只有真正运行在生产环境上了，才算完成工作。测试通过的代码不上线，就是库存。这在丰田称为“库存的浪费”。也就是不发布到生产环境，你为什么要写出来？还测试通过了。 如果一个分支停留太长时间，分支之间发生冲突的可能性就越大，而解决冲突这类操作对于产品的最终用户来说，是毫无价值的。用丰田生产方式的话说来，就是“动作上的无效劳动”。再者合并冲突过程容易再次引入缺陷。所以，应该避免分支停留过长时间。这个“过长”怎么定义，需要具体问题具体分析。 后记 其实，我很理解小明说出这样的话。大多是因为对部署没有足够的信心。对于没有自动化部署的团队来说，属于正常现象，你不能将责任推到一个人身上。而解决部署难的问题，不仅在管理上下功夫，还要在技术上下功能。

Photo by **Leon Macapagal **from Pexels 团队每天都会面对着看板开早会。过完卡后，会有一些技术问题需要进行深入讨论。大家你一句我一句，实在说不清了，我就想从桌子上拿一支笔将想法画出来。 但是在会议室找不到可用的笔，然后跑到文印室也找不到。这样，几分钟过去了，5个人团队就干等着我找笔。实在找不到，我们只得打开投影仪，打开 Windows 系统自带的画图软件画起架构图。 在经历过几次这样的痛苦后，我决定找办公室负责采购的小姐姐说这事。小姐姐心好，从其它地方拿笔到我们经常早会的会议室。 最后小姐姐补充：本月的文具已购买，下月我再向经理审批再买哦。 我当时没有反应过来，没有理解她这句话的意思。 过了两个星期，我发现又没有笔可用了（后来发现是我在文印室没有找仔细）。我再次找到小姐姐。并跟她说：能不能多放一些笔？ 小姐姐说：笔是统一放在文印室的，因为不知道哪个地方需要用。所以，你们有需要去文印室拿哦。 我说：文印室也没有了，没找到。 然后我实在没有忍住，一连串说了几句文具的成本是多低，节约人的时间，提高工作效率，可以节约更多的成本。 她似乎没有听进去：之前放了一支，你们又丢了。 我说：就一支，是不是别人拿到别的会议室了？ 她说：不知道。我买文具是要经理审批的。 我这才想意识到，她没有决定权。问题出在经理那里。为什么经理不允许买呢？ 从小姐姐那里了解到原来有一次小姐姐按往常一次提流程买笔和本子。谁知经理说：纸巾每月买可以理解，但是为什么笔和本子每个月都要买。 这就是现在为什么小姐姐很少买笔和本子的原因了。 最后，我也不提笔的事情了。因为我单独找经理谈这个事情，在当前的环境下，会被人说“跨级”。再者对小姐姐可能也不好。 谁知，过了两个星期，事业部的副经理从会议室跑出来，问：有没有见到大头笔？ 我苦笑地说：没有。 苦笑是因为我猜到发生在我身上的事，也会发生在别人身上。只不过没想到，发生在了经理级别上而已。 后来，也不知道他有没有找到笔。但是那个会议室还是偶尔找不到笔。 不知道读者朋友看出来问题没有？笔者认为关键问题出在： 提效不一定非要花巨资买个 DevOps 平台，效率发生在每一个企业运营的细节。 软件工程是知识密集型工作，人与人之间需要高效沟通。那么笔、白板（或纸）就是即高效，成本又低的工具。说实在点，工作少出现一个沟通失误，节约下来的钱就可能买下整个公司几年的笔了。小姐姐没有认识到，经理也没有认识到。 企业文化让看到问题的人不敢提问题。 你没有想到吧，一个负责采购小姐姐的决定，也可能影响一家公司的效率？这里没有贬低小姐姐的意思。每个岗位都有它的意义。 这些问题怎么从根本上解决？ 笔者认为，关键点是没有人从效率的角度考虑公司内部的行为。小姐姐考虑的是下次提流程时，经理不会问那样的问题。经理疑问了文具为什么用得这么快，但是并没有深究（几支笔的事情，当然没有必要深究）。其他人（可能）不想惹事，也不会找相关的人提“笔”的事情。在很多企业奉行谁提问题谁解决。有时我怀疑这句话对企业是有害的。 怎么解决呢？我只说一句：解铃还须系铃人。 一定能解决吗？我不知道。因为我也只是觉得可以解决。所以希望和更多人交流解决之道。 我把这些写出来，很有可能犯“政治错误”，得罪某些人。我还是要写出来。因为我相信还有不少企业发生类似的事情。不敢面对，怎么进步。

本篇文章只是笔者看到外墙清洗工后，在管理方面思考的总结。笔者是外墙清洗行业的外行，所以，本文可能存在一些错误的假设。期望这些可能错误的假设不影响管理方面的思考。 引发思考的起因 某天上班，仰头看到大厦清洗外墙工人悬挂在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

注意，下文所说的“老板”通常指业务提出方。 问题描述 上个星期，在持续交付2.0的群中，群主发出一个别人的提问。在我看来，这个问题在软件工程领域非常的典型，所以想单独写一篇博客来讨论。以下是问题原文： 我是一个开发部门的管理人员，团队规模还较小，开发需要兼任测试和部分应用运维的工作，但公司业务条线不算少（差不多有4个左右，目前部门中基本是按每个条线分配2-3个开发，出现某个组资源不足以满足需求时再进行调剂），之前这么做还算稳定，因为各业务对交付频率的要求一般很低，但近期各业务都提出了一个较紧急的项目需求，而且都还无法推迟或拒绝，资源一下子变得非常紧张（如果可以推迟某一个当然就会有富裕资源，但是这些项目由于各种原因公司都不能放弃，也很难推迟），如果依然每个组独立完成自己的项目，可能导致大部分项目因无法按时交付失败，而且每个组还必须保留少部分资源用于处理日常业务，如果临时招聘也来不及做培训，我们暂时是让资深一些的程序员和管理人员参与多个项目中的开发，但仍不能完全解决问题（他们抱怨任务太多都来不及测试），请问帮主遇到这类情况应该如何协调？ 提问者所说的情况，在现实中，太普遍了： （无法拒绝的）紧急需求的插入，打乱原有的步骤 开发除了需求的开发，还需要处理日常业务 人员不足：临时招聘也解决不了 开发人员报怨任务太多，来不及测试（就上线？） 项目无法按时交付 可以看出，“人员不足”是“项目无法按时交付”这个“果”的其中一个“因”。而提问者希望通过业务线之间人员的调剂和临时招聘的方式增加人员，但仍不能完全解决问题。笔者每当听到增加人员的信息，都会想起《人月神话》所说的：向进度落后的项目中增加人手，只会使进度更加落后。 而从提问者口中也了解到，原来人员还算足（感觉是刚刚好），只是因为出现了一个无法拒绝的紧急需求，问题就暴露出来了。 问题解决 面对这样的问题？你是如何解决的呢？以下是我个人提出来的解法，不一定对，只做交流： 第1是把当前工作的优先级排出来 把所有的工作内容（包括日常维护和新功能实现）列出来，同时，也要找到这些工作的交集（避免重复开发）。工作内容列出来后，确定它们的业务价值及优先级，并预估其开发难度。有些新功能是老板直接下发的，但是实现难度过高且业务价值又不高（团队及产品经理觉得），能和老板谈就和老板谈。这部分工作是我觉得最难的。 这个工作的优先级一定要让老板看到。主要是避免老板中间随意的插入需求。当然，有时需要向现实妥协，但不是每次。同时也要让所有人达成共识，遵守这个优先级。 第2是找出团队平时工作中最耗时的环节（瓶颈），想办法在这个环节上减少耗时（自动化或者别的办法）。一般来说，经常工作在这个耗时环节的人会知道如何优化它。 第3是慢慢让人可以流动 意思是人没办法调剂到其它项目，通常是因为他不了解其它项目（业务或者技术）。所以，在平时，就要注意将项目的“知识”尽可能准确地传递给更多人。当然，也可以定向的传递。具体操作方式要看团队平时的协作方式。 最后，1，2，3步需要重复执行，同时1，2，3步也不是顺序的。 笔者提出这样的解法并不是笔者猜的，而是有依据的。依据如下： 人员不足只是表象，我们怎么知道是真的人员不足，还是没有真正发挥每个人的最大潜能呢？第2、3步是为了让每个人发挥最大的潜能。而工具方面，个人建议通过看板可视化人员的工作内容，来达到了解当前资源状态的目的。 即使每个人的潜能都发挥到了极致，但是还是出现人员不足的情况啊。这就是第1步要解决的问题。这时，我们要学会舍弃。但是为什么老板就不会舍弃，老爱插入一些所谓的紧急需求呢？个人认为是因为老板不了解你当前的工作内容及其优先级。所以，这个优先级一定要和老板达成共识。 小结 当我把解法提出来了，群里的同学就提出了质疑：如何确定老板提出新功能是业务价值不高的？毕竟老板从整个公司考虑问题的。 这位同学提出了一个软件工程领域内经常发生的问题：执行者怀疑业务提出者提出的需求的价值。个人觉得质疑是好事。但是质疑之后，双方有没有讨论及讨论结果才是关键。讨论了就容易形成共识，有了共识，大家才好力往一处使。题外话，“我只要结果，不管过程”的管理理念的适用范围是拿出来讨论的。 最后，以上解法，不一定适用所有的情况。比如在外包项目管理中，可能就不适合。

没有想到，这本教子经典的书里，除了教我如何与孩子实现真正有效的沟通，还带给我管理方面的启示。 关于情感 当孩子处于强烈的情感中时，他们听不进任何人的话。他们不会接受任何意见或安慰，也无法接受任何建设性的批评。他们希望我们能够理解他们心里在想什么，希望我们明白在那个特别的时刻他们的心情。 员工之间难免会有摩擦，当出现这种情况时，我们可以说出各方的感受，引导各方相互理解对方的心情。进而将讨论焦点拉回问题的本质。 指导孩子时，我们陈述问题以及可能解决问题的方法。我们不会针对孩子本人发表任何观点。 比如当员工出现工期延迟时，我们首先要做的是陈述这一事实，听听他自己的表述，再讨论问题，而不是指责。 关于说真话 为什么孩子会撒谎？他们撒谎有时是因为他们不被允许说出真相。 想想我们所在企业是否允许员工说出真相了？是什么机制导致员工撒谎，不愿意说出真相。有办法改进吗？ 如果我们希望教育孩子诚实的品德，那么我们必须作好心理准备，既要听让人愉快的真话，也要听让人不高兴的真话。 如果我们的管理者只喜欢好听的话，那么，员工就只会说好听的话。我常常会想为什么有些管理者会只喜欢听好听的话。为什么呢？因为好听的话让人感觉良好，还是因为听到不好听的，代表自己的权威受到威胁了？ 简而言之，我们不能激发孩子防御性的撒谎，我们不能有意制造让孩子撒谎的机会。 是的，我们在进行组织设计时，要考虑如何才能不激发员工的防御性撒谎。我个人目前能想到的就是在企业中“培育”一种说真话无罪的文化。 关于责任感 责任感的培养可以从孩子很小的时候就开始。 在我看来，员工的责任感可以从小事开始，在平时进行，而不是集中在一场大型“洗脑会”中进行。 培养孩子的责任感，就是要在跟他们有关系的事情上让他们有发言的机会，如果必要，让他们自己作出选择。 管理层常常报怨员工对公司产品没有责任感。但是孰不知，员工对公司产品没有责任感的根本原因是员工常常只能“服从”，没有任何对公司产品进行发言的机会。 员工有发言权，但最终选择权是产品Leader的。弄清发言权和选择权两者之间的责任范围很重要。 我们应该故意制造一些场景，让孩子自己作决定。父母选择场景，孩子作出选择。 作为技术Leader，我们其实可以大胆让员工自己做一些技术决策。一是让他们更有责任感，二是培养员工将来能独立做技术决策。 关于聆听 父母需要开明的思想和豁达的心胸，这样才能倾听到所有的事实，不管它们是让人高兴还是让人讨厌。 “聆听”在我看来是最难做到的，因为我总是那么容易先入为主。同时，我们在聆听时，可以承认对方的感受，但是不一定要同意。 小结 有人说了，员工不是孩子，不能像小孩那样“带”。然而，很多人的某些方面就是孩子，我们必须面对。你招的是他整个人，而不是他的某部分。 前两年看完这本书时，我的个人感受：带小孩和带团队有几分相似。要培养他们，要处理他们之间的矛盾，一样要处理他们的情感，还要给他们发言权……然而，带小孩和带团队都知易行难，大家相互勉励。 强烈推荐各位亲自阅读这本书。

坊间一直流传着“康威定律”的概念，但是都是鲜有人能说出真实的反应这一“定律”的例子。本文则尝试弥补这一空缺。 本文本为几部分： 康威推论的历史：有必要了解它的历史 康威推论的定义：《人月神话》也只是转载康威的话 康威推论的例子：我的真实经历 启示 康威推论的历史 1967年，一位名叫梅尔文康威（Melvin Conway）的早期计算机科学家、程序员及黑客向《哈佛商业评论》提交了一篇名为“组织是如何进行发明创造的？”的文章，但是立刻被退稿了，理由是他“没能证明该理论”。 对于软件设计界来说，幸运的是这篇文章随后被Datamation杂志（当时一流的IT杂志）接受，并于1968年发表。后来，Fred Brooks在其开创性作品《人月神话》中，将康威的某些理论归纳为“康威定律”，这个名字就这样流传了下来。 以文内容来自：《软件之道——软件开发争议问题剖析》。 康威推论的定义 我们来看看康威推论的原文 How Do Committees Invent? (1968) 最后的总结： The basic thesis of this article is that organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations. 按《软件之道》里的大白话来说就是： 任何组织设计出来的系统（此处指广义的系统）的结构都会照搬这个组织的沟通。 说实在的，如果没有经历过，我说的以下两个例子，真心很难体会到康威所表达的。下面，是两个现实鲜活的例子，我正在经历的。 康威推论的例证 例证一：错误码的设计 背景是某团队针对同一业务，有Android和iOS两个平台的SDK。 Android SDK和iOS SDK开发人员，他们对于同一业务错误，设计出了两套装错误码。比如对于登录时用户名或密码错误，Android给出的错误码是230，而iOS给出的错误码则是8100。 为什么会出现两套装错误码系统呢？明明可以使用一套装就可以了。当然可能会有历史原因。但是据我观察，可以肯定的是，他们在设计软件时，并没有就“错误码”达成共识。 有趣的是，他们是同一个团队。居然还会出现康威现象。如果康威推论是正确的，那么，即使同一个团队下，也会出现不同的沟通结构。 如果这个例证有些牵强，下面这个例证更能说明事情。 例证二：IoT系统的设计 IoT系统有其特殊性。通常它需要进行硬件端、移动端（App）、云端这三端的配合才能更好的完成事情。以空调为例： 2017年前，硬件端和移动端是（相当于，其实不是）一个团队，而云端则是由另一个公司负责。而真正业务的决定权在硬件端和移动端。所以，平时沟通上，只有硬件端和移动端的事，云端只不过是负责转发。所以，云端的系统设计的最终结果就是一个管道：硬件端给我什么，我就直接转给移动端，移动端给我什么，我就直接转给硬件端。如下图： ...

摘要 本文内容主要来自《门后的秘密——卓越管理的故事》，英文名：Behind Closed Doors Secrets of Great Management。在2013年第一次看这本书时就感受益匪浅，现在又重新看，越发觉得这本书写的都是大实话。非常推荐读者亲自去读。 如何进行有效的指导 指导也是管理者工作内容的一部分，但它着重于提高技术水平和能力。指导是一种帮忙与被帮忙的关系，所以一定要确认对方想要得到你的帮忙。 指导常常被忘记是管理者工作的一部分。因为管理者本身也会有能力不足的地方，“指导”的过程会暴露这些不足给下属。所以，设计组织时，要想办法让“暴露不足”成为常态，而不是羞耻。 有效的指导的一些准则： 帮助员工想出备选方案 有些管理者会想：如果还要我帮他想出备选方案，我还招他做什么。这是老旧的管理思想。我个人有以下理由需要帮助员工想出备选方案： 1. 避免失控，因为你了解方案的上下文，你才有能力判别是否失控。 2. 员工掌握的信息不足，无法做出最优方案。比如如果他不知道公司在长期业务的发展，是不会知道架构上哪些方面应该更灵活，哪些方面应该更固定。需要管理者帮忙他。 3. 与员工协作，而不只是丢一个点子。 就每一个备选方案的影响进行讨论。不要试图得到某一特定结果；应该鼓励对方从他的视角尽可能深入地去探索每一个备选方案。表达你的观点，但应让你的指导的这名下属根据自己所需，做出选择。 这个过程，其实，也是管理者学习的过程，学习别人的思考过程，同时，也可以从“思考过程”级别对员工进行指导。 制定行动计划 在一对一的会谈时，跟进这一行动计划找出成功的部分，对不成功的方法做出分析，尝试新的技术或者行为。完善并提高奏效的方法，纠正没有起到作用的方法。 在我的经历中，鲜有组织会对过去做这些分析总结。因为有不少组织文化是不愿意面对失败过去的。也不愿意让员工知道自己的失败，有一部分原因是怕员工知道这些失败，对组织没有信心。 **小小结：**当一个管理者本身能力不足，就谈不上有指导。比如，你根本就不懂SQL，谈何指导下属提升SQL性能的优化；还有一种情况就是管理者有能力，但不懂得如何有效指导，这是一种浪费。设计组织时，应该考虑如何帮忙这类员工。 有“绩效管理”思维的人可能会想，让“指导”成为KPI的一部分不就可以了？但是，如何设计这项KPI呢？我个人认为，让“指导”成为组织文化的一部分才是解决之道。 成功地分配任务 需要分配任务的理由： 你不可能每件事都亲力亲为，总有一天你需要将管理类或者技术类工作分配给其他人。（不要认为这做是偷懒逃避责任，你是在给别人提供机会。） 在行业内经常听到：教会他做的工夫，我自己都做完了。我们需要做办法说服这类员工。 但是为什么会出现这样的现象呢？因为他所在的组织没有“分享”的文化。更有甚者，某些组织或管理者会抑制分享文化，因为分享文化提高了员工能力的透明度，最终会暴露出组织或管理者本身能力的不足。 成功地分配任务的一些准则： 明智地选择你的分配任务对象。这名员工应该想要承担更多的责任，并已经确认了自己的职业发展方向，这项工作正好适合他的职业发展方向。不要选择对这项工作不感兴趣的下属接受任务。 高高在上的管理者是达不到这一准则的。因为他根本不了解自己的下属职业发展方向。 阐明你对这项工作的期待：什么样的成果才你能接受的。 在软件行业，特别是互联网行业，很多管理者也不完全知道自己对某项工作的期待。这不重要，重要的是管理者应该将这一点表明给下属听。 明确表明不被允许的方法 确定阶段性里程碑。当你做出分配工作的决定后，确保这一决定至少分为两部分：做出备选方案；选择其一。一定要表明哪一（些）部分是你分配下去的，如果在这两部分工作之间的某一点，你想进行检查，请明确地提出来。 这一点非常重要。“结果导向”的管理方式大行其道，这给很多管理者不进行过程管理的理由（这类人常常将“我只要结果，不管过程”这句话挂在嘴边）。同时，要确定阶段性里程碑，是需要有相关业务的能力的，所以，我常常好奇那些不懂技术的管理者是如何管理软件研发团队的。 **小小结：**在我个人看来，“分配任务”的能力很能体现一个管理者的能力。他必须有全局观，这样才能知道如何分配，效率才能达到全局最优。他必须有长远眼光，这样才会知道要在长远任务和短期任务之间做平衡（架构师才能在不同的技术方案做出更合理的选择）。 我也发现，鲜有组织会考虑让员工自行选择任务。让员工自行选择任务，我个人总结有以下几点需要注意： 找出信任他的理由：小心（可能）没有能力完成，但是又主动要求接的员工。这种情况，不是说不好，而是一定要和他共同制定方案，确定阶段性里程碑。这样，你才有信任他的理由。 检验他的方案：让主动的员工在所有人面前或者和你一对一地阐述自己的解决方案 小结 以上是卓越管理的两条技巧。看似简单，其实不易。比如在有些组织，根本上就没有“分享的基因”，你谈指导，得到的只是不理解。而且，面对中国的国情（面子、关系……），你需要权衡各方的“面子”和权力，更不易。大家且行且珍惜。 我个人作为一个组织的设计者来看这些“技巧”是有原因的。因为我觉得很多问题，并不是个人问题，而是组织设计的问题。

申明：缩短出活时长的目的不是为了让他们有更多时间加班。目的是提高团队的生产力。这样我们才有更多时间陪家人。 作为一个管理者，一定会遇到的一个问题是：如何团队新人更快的“出活”？ 面对这样的问题，行业内，我见过不少管理者，就直接丢给他一堆源码和文档，就什么也不管了。直到一个星期后才询问新人理解了多少，或者直接丢给他一个需求让他去实现。 这样做意味着： 一个星期是出不了活的，因为你已经在一个星期后才给他任务 一个星期后，你敢100%保证他所理解的东西能帮忙到他完成你一个星期后给他的需求？很有可能，他所做的需求和这一个星期内看的东西毫无关系 那怎么办呢？我知道你心中开始疑问。接下来，我介绍一些我个人的看法和做法。 “让新人更快的出活”是一个目标状态，我们应该问的是：达到这个目标状态的前提条件是什么？ 只要保证了这个前提条件，就船到桥头自然直。 我总结的前提条件有： 条件1. 对业务有基本的认识。比如做家电IoT时，他必须亲自拿着手机尽可能的玩一遍所有的家电。 条件2. 对于整个系统架构有一个大体的思考框架。比如家电IoT的整体架构有一个Big picture。 条件3. 大概了解每个团队成员的职责，知道哪类问题该找谁。 条件4. 了解自己的职责所在。这样才能有的放矢，至少，知道自己应该重点看哪些文档。 要达到这些前提条件的做法是什么呢？ 关于条件1：对业务有基本的认识 举例来说就是让他拿着一个家电说明书，然后让家电连上网，再控制他。这个过程，我们如何验证他的学习效果呢？ 让他记录下使用产品这个过程的困惑，因为这些困惑就是真正用户的困惑。换句话，除了让新人了解了业务，还能帮助我们这些“资深用户”找出产品所存在的问题。 关于条件2：对于整个系统架构有一个大体的思考框架 让团队里最熟悉整个系统架构的人，给这些新人讲解。让新人有一个全局观。同时，这个过程，也是让新人有发现系统构架存在的问题的机会。如何验证新人的学习效果呢？ 让新人当着所有人的面新口说一遍整个系统架构，并在白板上画出来。当然，如果所在团队没有这样的条件，就让他给另一个团队成员讲，也是可以的。 条件3：大概了解每个团队成员的职责，知道哪类问题该找谁 为每个新人分配到一个“辅导员”的同事。这个辅导员有责任回答新人所有问题。 这样做，有几个好处： 对新人有更多的人文关怀。特别是对于一个第一次来公司所在城市的外地人员。 新人可更快融入团队。因为这样新人就不会觉得“怯场”。也可以让新人更快的了解团队的文化。 作为团队的“老人”，也能更深入的了解这位新人。最终达到团队match的状态。 这点，我所经历的ThoughtWorkers就做得非常好。 条件4：了解自己的职责所在 当了解系统的整体架构后，我们只要画出他的职责的那块，他就可以很快地理解了。也就知道他接下来要做什么了。 再说了，我们的辅导员也有责任让他知道他接下来要做什么。 让新人更快出活的小技巧 以下是我自己总结的一些小技巧。 让新人和老人结对编程。比如让老人完整的实现一个需求，新人就坐在旁边看。这样，新人就很快熟悉在当前团队中一个完整的开发流程是怎样的了。 让新人去测试老人实现的需求。比如老人实现了一个需求，也自测了。但是我们团队有一个要求，只有别人测试过了，才算测试通过。在测试人员不足时，可以这么做。 让新人做测试即可以让他更快的熟悉业务，又可以培养他的测试思维。 小结 一个新人要多快出活，除了新人本身的素质外，我们作为管理者需要不断地思考，如何缩短他们的出活时长。 再次申明：缩短出活时长的目的不是为了让他们有更多时间加班。目的是提高团队的生产力。这样我们才有更多时间陪家人。 图源：https://www.pexels.com/photo/clown-fish-swimming-128756/

想象离开目前这家公司，你还能去哪？ 如果你发现，你只有和这家公司流程、政治、上下文等等强相关的能力，那么，你也只能靠“办公室政治”保留住自己的位子。因为，离开了这家公司，你什么也不是。 但是，也有例外，就是另一家公司没有分辨能力，你又特能忽悠。像这位“高管”：假证假名假文凭，小学文化男子应聘入职月薪7万公司高管。 最后，当你思考这个问题时，如果感到害怕，你就要小心了。 忠告：保持独立思考的能力，但隐藏起来 市面上有一些管理者是不允许你和他有不同意见的。通常，独立思考的人凡事都会有自己的看法。而如果你在别人面前和管理者提出不一样的意见，领导会觉得没面子。那么，今后，你可能就没好吃的了。 那么，正确的做法是什么呢？即使大环境下，所有的人都附和管理者，你同样不要被这种环境麻痹自己独立思考的能力。观察你的管理者是开明的人，还是职场“老油条”？选择一个合适的时机说出你的不同意见。 这时，你就知道“察言观色”能力的重要性了。 当存在不同意见的时候，作为组织和管理者需要思考，是不是管理者没有表达清楚，是不是这个“不同意见”更合理，如何说服这个不同意见的人，其他人是不是也有不同的意见？ 当然，有些人会觉得这样会导致企业的执行力下降。我想说的是，知识工作者执行任务不像体力劳动者，你告诉他把这个箱子从这里搬到那里，这么准确。任务定义不准确往往是组织管理者自己都还没有想清楚自己到底要什么。最后得不到自己想要的，又反过来说企业的执行力差。 现象：通过建立信息壁垒的手段，保住自己的位置 有一次，我问一个同行：为什么整个系统，这么多个工程，没有一个人知道全景图。（这个系统并不算大，也就30多个子工程）。我们能不能组织所有人建立一个全景图？ 他说了：别人是不会告诉你，他自己那块是怎么做的。 我问：为什么呢？有个全景图大家不就可以更好的协作吗？出现问题，也不需要等着某一个人了。 他浅笑，眼看前方：因为如果给你懂了他的那块系统，你就可以替代他了。 这下，我才明白。行业内，还有人通过建立“信息壁垒”，让公司离不开你；让管理者觉得你是有用的。 看懂这点后，你会发现，那些不干“实事”的人，为什么能一直“保住位置”。往往因为他们掌握了信息的源头。 这种协作机制，有好处，比如两个组织之间的对接方式明确，出现问题马上知道找谁解决。坏处一是信息的准确度会在对接人之间严重打折，带来的就是低效率。坏处二就是会滋生建立信息壁垒的职场老油条。 作为个人，我们要问自己，离开当前这家公司，你建立的信息壁垒，还会有价值吗？ 作为公司，信息不透明所带来的坏处，我就不想说了。管理企业和管理国家都会遇到这个问题。 忠告：小心那些威胁到别人“KPI”的行为 当公司的IT系统管理员做得不好时，不要直接在公司的大群里说。因为你这样做可能会威胁到他的KPI或他在管理者眼里的印象了。所以，私自跟这位IT系统管理员沟通就好了。 为什么：不管功劳，苦劳，一定要让管理者看到 过年了，相信不少人要开始表现得非常辛苦了。很简单，因为年底了，年终奖的多少就看这一个月了。当然，我说的不是绝对的。但是一定存在这种现象。 这种现象背后的原因是多种的： 管理者对人、工作的判断，依赖的是主观印象，而不是客观因素。 所以，你会经常听到有人在朋友圈、饭局上说自己最近因为工作太猛不舒服、没有时间陪小孩、过劳胖…… 当出现这种现象时，作为管理者就需要反思自己的管理方式了：组织的效率是不是有问题；作为个人，小心使用这种行为，不要让它麻痹了你独立思考的能力。 知识工作者的生产活动存在于大脑中，看不到摸不着。 比如没有好的技术管理的团队，即使你写出优秀的代码，对于你的“年终奖”也没有什么益处。 作为组织，我们需要思考，员工的表现一定要让管理者看到，而不是让所有人都看到。 玩笑：准时下班，肯定是工作不饱和 这是一句玩笑话。但是背后有它道理。 我们知识工作者有一个特点，就是从表面上，你是看不出这个人是否在工作的，因为他的真正工作存在于他的大脑中。他一天坐在那里，你怎么就知道他是否在工作呢？再者，绝大多数人的注意力没法做到连续一小时。所以，公司pay你的一天八小时，是打折的。 然后，我们软件行业里就有了这么一个玩笑话。 事实上，这背后更深层的含义是： 组织、管理者无法评估知识工作者的工作量 组织、管理者还没有理解体力劳动者和知识工作者之间的区别 那怎么知道一个程序员的工作是否饱和了呢？哈哈。这样的好问题，留给喜欢思考的人。P.S. 我不提倡加班文化，让程序员工作饱和的目的是让程序员不加班。 招聘：交叉组织面试是合理的 以前听说腾讯面试，你面试的是A部门，然后企业HR会在某个环节里随机其他部门的人来面试。这种机制能有效避免有人利用手上权利招聘一些利益相关的人。比如把自己的并不能胜任能力的表弟招进来。 而企业中，我发现这种交叉组织面试真的是值得的。 现象：管理者让你把数据拷出来 朋友打电话来诉苦，说他上级要求他把公司的大数据拷出来。这时，你会怎么做呢？我也不知道，说实在的。 但是这个问题是所有企业都会遇到的问题：如何管理无形资产？这个问题有些大。今天不讨论。 小结 其实，还有很多职场经验、组织管理上的思考。这些只是其中一些。其中有些话，是有些绝对，你对号入座了，反正我不负责。 作为一个软件工程师，我是不是有些不务正业？我是不是该执行上级领导给的需求，什么也别想就可以了？ 向独立思考者致敬。

图截自：http://agilemanifesto.org/iso/zhchs/manifesto.html 最近，项目上遇到了以前我从来没有遇到的事情：10多个人一个团队（概念上的），要应对9个外部需求提出方；要维护超过10个子系统，这个“大系统”还是从另一个不愿意配合的团队接手过来的；项目管理者中，有倾向于敏捷的，也有倾向于瀑布的；最可怕的是这支团队完成组建才1个多月，只有3个人有站会经验，平均工作经验在7年以上😱。 所有的这些条件混合在一起，管理就变得异常复杂，困难。面对这样复杂的乱麻，谁都很难有勇气一刀切。 然而，事情还要做。比如站会。上周我自荐主持一次站会。说实在，那次站会是失败的，因为期间还是有两个人拿手机来刷。 有人拿手机出来刷，说明站会上的内容和他们无关，进一步说明站会是无效的。 但是，为什么呢？我会后一直都在思考这个问题。 我想起自己一年多前，也是带团队从零开始实践敏捷开发。为什么不会出现这样的情况？ 突然，一个词蹦出来：共同语言！ 站会成为形式的根本原因，就是整个团队没有共同语言！。没有共同语言使站会沦为形式。 好，现在我必须解释两个问题： 为什么整个团队没有共同语言导致站会成为形式？ 为什么整个团队没有共同语言？ 我先解释为什么整个团队没有共同语言，再解释为什么没有共同语言的团队站会是形式。 为什么整个团队没有共同语言 团队的沟通模型 第一个使整个团队没有共同语言的因素是：团队的沟通模型。 为了方便讨论，我们假设团队的沟通模型为： 项目管理A，对接需求方1、2、3，然后再将任务拆分给Q、W、E。项目管理B、C依此类推。 这样的沟通模型下，为什么团队成员会没有共同语言？ 在这样的沟通模型下，开发人员Q平时只与A沟通需求，尽管可能私底下与其他开发人员沟通一下实现，可以说，开发人员Q与项目管理A才会有共同语言。依此类推，每个开发人员只与他的直接上级有共同语言。 我的结论是：趋向于单向沟通的团队沟通模型决定团队成员之间没有共同语言。而且这种单向沟通的结构时间越长，团队成员之间共同语言就越少！现象是，同处一个团队，你不知道你隔壁坐的同学到底在做什么。 没有统一业务术语 第二个整个团队没有共同语言的因素是：团队内部没有统一业务术语。 我们假设站会时，移动团队里的iOS、Anroid、H5三个小组一起参加同一个站会。而在站会时，iOS针对功能A使用了“激活”业务术语，而Android的同学对同一功能A却使用“上线”业务术语。 不统一业务术语不仅导致成员之间没有共同语言，导致更严重的问题是：沟通效率低下。 为什么整个团队没有共同语言导致站会成为形式 其实道理很简单，你问问自己，你喜欢与自己有更多共同语言的人交谈，还是反之？这是人性！ 站会时，我们更倾向于听我们关心的，和我们听得懂的。但是因为没有共同语言，所以，我们即不关心，也听不懂！ 站会当然也就是形式而已。 怎么破？ 这下肯定会有人问，那为什么要站会？取消不就可以了。问这样的人是因为不了解站会的本质：站会一种团队快速反馈的机制。 至于为什么需要快速反馈，很简单：（真正有效的）每日站会的团队可以每天根据站会内容（反馈）来对人员、需求、发布时间进行调整，调整的时间是以天计。而如果只有周会的团队，那么，这个团队调整的时间是以周计，那你觉得哪种团队面对变化时更敏捷，迅速？ 说回来，如何让站会更有效，而不至于成为一种形式呢？ 至少可以肯定的是这不是一个主持人就能解决的。 剩下的先留给大家思考，我们下篇文章再讨论。 你也可以先读读我之前写过的文章： 每日站会、代码审查、结对编程 之开源中国实践 反馈机制在企业中的作用？ 如何防止程序员上班迟到？