Zh-Cns

从聊天说起 有一次和朋友聊天，他说他们有一次部署出事了，影响还挺大，那次事故后，他们公司对于部署流程增加了更多的审批。 当朋友说完前半句时，我已经猜到下半句，那是很多公司或个人会做出的反应。至于为什么会做出这样的反应，我也不知道。 我问：为什么那次部署会“出事”？ 他说：当时部署的人忘记了那台机器上有一条 Iptable 规则，导致了事故。 我就在想，如果有人审批，那次事故就不会发生吗？审批的人就知道那台机器上有一条规则导致事故的发生？然后驳回这次部署吗？连一线的开发和运维都忘记了的 Iptable 规则，“高高在上的审批领导”就更不知道了。 题外话：增加审批流程并不能避免这次事故，只不过当出现事故时，可以更好的定责。然而我又好奇了，这种“审批”是为了解决问题，解决什么问题？，还是为了逃避责任？谁逃避了责任？谁又有责任？ 对于这类问题，我心里已经有数了，但想知道这位朋友的回答，就接着问：那么怎么杜绝这类问题呢？ 他说：因为那条 Iptable 规则的设置太久远了，是谁都记不起。如果能把每次部署的步骤记录下来，这样下次部署的时候，过一下以前的部署记录，就会知道那个 Iptable 规则了。（作者：大概原意，已经记不清原话） 这位朋友说的做法，我之前待的一个团队的做法也差不多：会有一个页面专门记录下每次部署的步骤，步骤由开发人员写，然后由运维人员执行。只是我不知道他们会不会回顾之前所有针对这台机器的部署步骤。 这个团队里有某某大型互联网公司来的架构师和某财务软件公司来的运维，所以，我不负责地推测，我们这个行业很多公司对于配置的管理还没有达到足够的重视，也没有正确的看待。 我笑了，接着问朋友：那我要知道当前机器的“最终状态”，是不是要找出所有部署记录，还要过滤出对这次部署有影响的每一个细节？比如那条 Iptable 规则。 接下来的对话细节已经记不清，也不重要了。重要的是找出针对这类运维事故根本原因及解决办法。 我个人认为这类问题的根本原因在于： 配置管理的失控： 已经没有人完整知道线上环境配置是什么了？要了解时，只能一个个查。 测试环境与生产环境的配置不一致： 如果那位倒霉的同学在测试环境部署出现这样的问题，到生产环境部署时，自然就会注意相关配置项了。 以上只是我个人认为的，不一定正确，欢迎各位读者讨论。 那如何杜绝这类问题呢？ 这两个原因可以看作一个，也可以看作两个。但方法都是一样的： 使用声明式的配置管理方法，而不是脚本式 版本化这些声明的配置 所有环境使用同一套装配置管理方法 使用声明式的配置管理方法，而不是脚本式的 脚本式的配置管理是这样的： apt-get install build-essential apt-get install libtool cd /usr/local/src wget ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-8.37.tar.gz tar -zxvf pcre-8.37.tar.gz cd pcre-8.34 ./configure make make install 而声明式的配置管理是这样的： # ./ansible-nginx/tasks/install_nginx.yml # 使用这个7-0.el7版本的yum包 - name: NGINX | Installing NGINX repo rpm yum: name: http://nginx.org/packages/centos/7/noarch/RPMS/nginx-release-centos-7-0.el7.ngx.noarch.rpm # 当前机器的nginx的状态应该是最新版本 - name: NGINX | Installing NGINX yum: name: nginx state: latest # 当前机器的 nginx service 的状态应该是已经启动的。至于如何确保 nginx 这个 service，当前是什么状态的，又是如何启动的，我们不需要关心。 - name: NGINX | Starting NGINX service: name: nginx state: started 声明式的配置里写的是当前环境的“状态”，语意上，声明式的配置不论你执行多少次，你得到最终的“状态”就是你所声明的，这也就实现了《持续交付》里说的： ...

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

说在前面 在《持续交付》的第二章配置管理的小结里说到： 配置管理是本书其他内容的基础。没有配置管理，根本谈不上持续集成、发布管理以及部署流水线。它对交付团队内部的协作也会起到巨大的促进作用。 再怎么强调配置管理的重要性也不为过，特别是在多环境下。然而大家都知道重要，又少有人告诉我们具体如何做，所以实在难受。 本文总结了我在多环境配置管理实践方面的一点心得，希望对大家有帮助。 Ansible 介绍 你可以简单地把它理解为一个自动化运维工具。本文将会使用这个工具下 inventory 概念来实现多环境配置。简单一点来说，inventory是一个文本文件，你可以在这个文件里记录下所有的机器，并对这些机器进行分组（分类）。 当然，其它的自动化运维工具也可以使用同样的思路来实践。本文只以 Ansible 为例。 例子 比如我们有两个环境，分别有一台机器。使用Ansible的 inventory 来管理这些机器，就会像下面这样： ## inventory [aws-prod-app] 10.171.32.158 [aws-test-app] 10.161.158.221 所有的 app 应用都是同一份代码，而且都会涉及操作数据库。当然，不同环境下的 app 读取的数据库的配置项的值是不样的。比如 aws-test 环境下配置是 db: url: test.mysql.url username: testu1 password: passwordtest 而生产环境 aws-prod 环境下配置： db: url: prod.mysql.url username: produ1 password: passwordprod 这时，因为机器少，我们可以使用 Ansible 的 inventory 变量实现不同环境的配置隔离，比如： ## inventory [aws-prod-app] 10.171.32.158 ## [分组名:vars] 这样的写法是 Ansible inventory的约定 ## 按照这个约定来写，Ansible就可以识别了 [aws-prod-app:vars] db.url = test.mysql.url db.username = testu1 db.password = passwordtest [aws-test-app] 10.161.158.221 [aws-test-app:vars] db.url = prod.mysql.url db.username = produ1 db.password = passwordprod 接着，如果环境上要部署新应用呢？而且还是很多呢？我们的 inventory 就会变成这样： ...

坊间一直流传着“康威定律”的概念，但是都是鲜有人能说出真实的反应这一“定律”的例子。本文则尝试弥补这一空缺。 本文本为几部分： 康威推论的历史：有必要了解它的历史 康威推论的定义：《人月神话》也只是转载康威的话 康威推论的例子：我的真实经历 启示 康威推论的历史 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会在某个环节里随机其他部门的人来面试。这种机制能有效避免有人利用手上权利招聘一些利益相关的人。比如把自己的并不能胜任能力的表弟招进来。 而企业中，我发现这种交叉组织面试真的是值得的。 现象：管理者让你把数据拷出来 朋友打电话来诉苦，说他上级要求他把公司的大数据拷出来。这时，你会怎么做呢？我也不知道，说实在的。 但是这个问题是所有企业都会遇到的问题：如何管理无形资产？这个问题有些大。今天不讨论。 小结 其实，还有很多职场经验、组织管理上的思考。这些只是其中一些。其中有些话，是有些绝对，你对号入座了，反正我不负责。 作为一个软件工程师，我是不是有些不务正业？我是不是该执行上级领导给的需求，什么也别想就可以了？ 向独立思考者致敬。

在管理这个行当里，存在两个基本理论，X理论和Y理论。希望大家认真看一看，这样你就理解了，为什么公司会有这样那样的政策。 X理论 Y理论 一般人的本性是懒惰的，工作越少越好，可能的话会逃避工作。 人们在工作上体力和脑力的投入就跟在娱乐和休闲上的投入一样，工作是很自然的事——大部分人并不抗拒工作。 大部分人对集体（公司，机构，单位或组织等）的目标不关心，因此管理者需要以强迫，威胁处罚，指导，金钱利益等诱因激发人们的工作源动力。 即使没有外界的压力和处罚的威胁，他们一样会努力工作以期达到目的——人们具有自我调节和自我监督的能力。 一般人缺少进取心，只有在指导下才愿意接受工作，因此管理者需要对他们施加压力。 人们愿意为集体的目标而努力，在工作上会尽最大的努力，以发挥创造力，才智——人们希望在工作上获得认同感，会自觉遵守规定。 在适当的条件下，人们不仅愿意接受工作上的责任，并会寻求更大的责任。 许多人具有相当高的创新能力去解决问题。 在大多数的机构里面，人们的才智并没有充分发挥。 | 资料来自维基百科 是的，不少公司的管理人员或多或少基于其中一个理论。有些人在决策时甚至意识不到XY理论的存在。 这两个理论，我都赞同，也都不赞同。就如同我赞同人有善的一面，也有恶的一面。而且，在不同的时候，有不同的一面。 所以，当人们表现为X理论的一面的时候，我不是马上认定这个人100%就是X理论里所说的人。而认为是我们的工作流程或机制的设计出现了问题。 为什么这样说呢？我们先来看看公交卡的设计。我们都知道公交卡可以分为老人卡、学生卡、普通卡。 我们如何避免不是老人的人刷老人卡坐公交呢？可以想象的方法有这些： 很明显，政府出一个“公文”不允许非老人刷老人卡，是最没用的方法。 老人卡使用特殊的颜色，这样刷卡时，司机就可以辨认刷卡人是否为老人。可是广大人民的智慧是无穷，只要加个卡套就好了。P.S. 很少人会想到这样会导致下属人员作假。 在刷卡的地方，加一个专门的人去检查卡人是否一致。这样，大多数人可能上下班可能都会迟到。P.S. 很少人会想到这样还会导致腐败、人与人的矛盾。 不要笑，我们不少公司管理方法的背后的思维模式和这些“方法”的没有多大区别。 如果我们用X理论来度量所有坐公车的人，我们的公车效率就会变得低效。如果我们用Y理论来度量所有坐公车的人，我们的公车效率是好了，但是赚的钱变少了，而且可能亏本。 这就是不少企业经常遇到的问题：抓过紧就死，放太松就散。 公交卡问题如何破局？说到这里，坐过公交车的人已经知道答案了：老人卡刷卡时，语音播报：老人卡。其它特殊的卡依此类推。 很长一段时间，我都在思考：为什么？ 后来，我想通了。语音播报时，刷老人卡时，如果这个人不是老人，他一定会脸红（羞耻心）。因为公交上其他人都看到了。语音播报利用了社会人所具有的羞耻心来解决公交卡问题。 回到本文的主题，这样的“公交卡”给我们的管理带来什么启示呢？ 一个人不应该用XY理论分类 企业管理做决策时，不能完全基于X理论，也不能完全基于Y理论 利用人性引导人们趋向于Y理论，而不是相反 让信息透明会让我们收益良多 利用人性引导人们趋向于Y理论看似卑鄙，但是总比一些游戏利用人性让你上瘾更让人接受。 信息的不透明是很多管理难题的根本问题所在。以后我们再谈。 小结 公交卡的设计给我带来的不止是启示，更有意义的是背后的思维模式。而思维模式能带给我在任何情况下随机应变的能力。 最后我提个问题，留给读者思考。问题是：如果10人软件开发团队里，服务经常因为开发人员在自己的机器上打包而出现bug，你会如何解决这个问题？ 注意，解决这个问题的同时，会反应出你的思维模式。

面对需求，我们首先想到的是什么 在家电IoT这个领域里，通常都会需要实现家电的分享。比如老婆分享家里的电饭煲给老公，让老公控制电饭煲。 拿到这样一个需求，通常大脑里想到的就是增加一张家电分享表来实现： appliance_user_shared master_user_id shared_user_id appliance_id 然后再修改家电列表的实现，因为需要将别人分享给自己的家电也要能获取到。 同时，别忘记了，我们还要修改所有对于家电的操作的实现。比如业务规则中说明，家电的主人才能对家电的名称进行修改。 就这样，我们实现了用户对于一个家电的分享。这时的业务模型可以表示如下： 过不了多久，产品经理跟你说，如果一个用户家里有10个家电以上，一个个家电的分享，这种体验太糟糕了，我希望将一个家庭分享给其他人，这样，可以将家庭下所有的家庭一下子分享给另一个人了。 当然，我们同样可以将这个需求，看作是添加一个家庭分享表，再修改一下家电列表、家电名称修改、家电控制……这是A方案。 A方案的领域模型表示如下： 但是，我们还有一个B方案。 当我们仔细思考时，我们似乎掉进了产品经理挖的坑：产品觉得通过增加一个“分享家庭”的概念来实现多个家电的分享。 事实上，我们服务器端实现并不一定需要这样做。前端APP可以有一个家电分享的操作界面，但是，服务器在实现这个web api时，只需要在找到这个家庭下的所有家电，然后重用原来单家电分享的概念了，就可以了。 这样做，就非常符合软件设计的开闭原则：对扩展开放，对修改关闭。 基于B方案，我们不需要对家电列表等功能进行修改。同时，你还会发现，某天产品经理抽风，觉得一次性分享所有的家电不好，如果能在一个家庭基础下实现部分家电分享的功能，是不是更好？A方案就头大了。而B方案可以很轻松的应对。 B方案的领域模型表示如下： 说回来，我们应该警惕产品经理或需求人员帮我们做软件设计。 面对需求时，我们的大脑里，第一想到的是数据库表如何设计、如何实现改动最小、是使用微服务呢，还是使用七边形架构……这类技术问题时，我们的设计是技术驱动设计的。 如果我们大脑里第一思考的是什么单家电分享、家庭分享和单家电分享之间是什么关系……这类领域问题，然后基于这些思考，建立一个领域相关的知识体系——以领域模型为体现。如果我们的软件是基于此领域模型进行设计，就是：领域模型驱动软件设计。 按《领域驱动设计》中，作者所说的： 领域驱动设计是一种思维方式，也是一组优先任务。 领域建模 要搞清楚，什么是领域建模，就必须搞清楚什么是软件的核心。 我们来看看《DDD》前言里所写的： 一些设计因素是技术上的。软件的网络、数据库和其他技术方面的设计耗费了人们大量的精力。很多书籍都介绍过如何解决这些问题。大批开发人员很注意培养自己的技术，并紧跟每一次技术进步。 然而很多应用程序最主要的复杂性并不在技术上，而是来自领域本身、用户的活动或业务。当这种领域复杂性在设计中没有得到解决时，基础技术的构思再好也是无济于事。成功的设计必须系统地考虑软件的这个核心方面。 这个核心方面指的就是领域知识。 而领域建模就是消化吸收大量知识（领域相关），最后产生一个反映深层次领域知识并聚集于关键概念的模型。这也就是领域驱动设计的实质。 上文中，关于家电分享的例子，从A方案到B方案，实际上就是随着我们对领域知识的理解更深入，领域建模的一个过程。 小结 就如《DDD》作者所言：很多因素可能会导致项目偏离轨道，如官僚主义、目标不清、资源缺乏，等等。但是真正决定软件复杂性的是设计方法。当复杂性失去控制时，开发人员就无法很好的理解软件，因此无法轻易、安全地更改和扩展它。 领域驱动设计这种思维方式，再加上一整套的设计实践、技术和原则，就能帮助我们控制真正的复杂性。这就是领域驱动设计的作用。 而这种思维要求我们在面对领域问题时，优先考虑的是领域问题，而不是技术问题。 注意，这并不是说我们不考虑技术如何实现。这是优先级问题。 最后，以上举的例子并不是最终的模型。因为家电分享这个概念并不是最根本的概念。更根本概念是家电的权限。这是一个更层次的领域模型：

那一年，我在西安。现在在深圳。但，时常怀念在西安的生活。 每到一个处吃饭（除了星级酒店），不管它是面馆、快餐店、排挡，还是路边小摊，我都会观察它们是如何经营的。 那一年，西安火车站旁，看上去非常普通的面馆，大概60平米左右，却使用了不一样的经营方法。让我一下子感觉发现了新大陆。 当时，在上火车前，想吃点什么。因为没时间，就直接走进了路边的一家面馆。面馆处于火车站正大门前的一个丁字路口边上，人流量自然没得说。 推开门，径直走向前台。可是前台就几个客人，再环视面馆，座位基本都满了。当我走到前台时，那几个客人已经开始找座位。我跟前台说：你好，来碗臊子面。 前台：你自己找个座位先坐下来，然后叫服务员点菜。 我：不用拿号吗？ 前台：不用。 然后，我一会儿就找到一个空座位。心中有种侥幸感：还好有座位。即使，我是与一个看起来很凶的大汉共享这张二人桌。 现在想想，这是多年在火车站旁消费带来的条件反射：在火车站旁，有位置就不错了。 桌上有菜单和基本上每个“快餐店”都会有的桌号。 我举手示意服务员，她1分钟左右就过来了，后来观察到，她是专门负责点餐的。 点完就马上付钱。 这位点餐员提醒我：你千万不要乱换座位，要不等下找不到你的。 面也没有等多久就上来了。这时，我才发现，店里，没有我们经常听到的大声吆喝：5号，5号，臊子面……看到送餐员从厨房后面出来，直接就走到了相应的客户桌上，十分精准。 当我吃完，要去赶火车时，我也不担心要排队买单。老板也不用担心我跑单。因为在点餐时已经付过了。 这家面馆，在我看来属于快餐店一类。现在我们来看看这店与一般的快餐店有什么不同： 它没有客户号，只有桌号 这样，送餐时，菜，桌一一对应，节约送餐员的送菜时间，也缩短了客户取餐的时间。 一般的快餐店送餐员全店的找“4号客户”，实在找不到，就大声吆喝，这给我们带来不好的用餐体验不说，我们的快餐店的生意居然寄托于服务员的眼力和短时间记忆力！ 客户先找座位，再点餐 做面是需要时间的，并不是你点了，马上就可以拿到。像KFC，在前台完成点餐，取餐，买单所有流程的。在面馆里不适合。 后来，我也就明白了，为什么有些快餐店会把饭类和面类分到不同的点餐通道，我想就是因为饭类和面类之间从点餐到取餐之间的速度是不一样的，需要分开处理。 多说一句，我们做软件架构时，也会把慢速流程和快速流程分开处理。 先付款，后消费 平时，大家都喜欢先消费，后付款。一是不知道还会不会加点，二是，这种消费体验更好。想想哪个高级酒店，不是先消费，后付款。 但是对于一家火车站旁的小快餐店，是不成立的。第一，火车站旁，大多数人，想要的是快点走，点了又点的概率太小；第二，火车站旁，消费者要的是快，而不是“更高级”。 “先付款”节约了完成消费时的计算时间和叫服务员买单时间。最后，节约了客户的时间。至少，我们的生意，也不用寄托于服务员的记忆力。 最后的好处是：火车站，鱼龙混杂，“先付款”，防止了跑单。 给我带来了什么启示 后来，我见识不少火车站旁的快餐店，但是基本上都会有手托的服务员，费时费力的找“客户号”。我知道西安火车站旁的这一小面馆的经营方法，并不是行业的“共识”。虽然每家店都想赚更多的钱。 这家小面馆的经营方法并不一定适合于所有的面馆。况且，世上有没有适用于所有面馆的经营方法，也是个问题。 但是，这家小面馆，一定是看清了自己的价值流：从客户进店，到客户出店。然后，不断优化这个价值流的节点，使其更顺畅，最终实现赚更多的钱。 对于我们做软件产品的呢？我们的价值流又是什么呢？好问题！ 另一个问题：发现价值流后，如何持续优化？我的答案是：现场管理。但是软件产品的生产过程，如何做到现场管理呢？好问题！ 如果一个不懂软件开发的人，如何管理好软件产品生产过程呢？好问题！ 最后提一个问题：这家面馆的经营方法算不算精益？ 图片来网络。如果侵权，必删。