P.S. 这里的“迟到”指的是故意迟到。 看看满大街的招聘信息上都写着： 弹性上班，不打卡 我们还有必要思考如何防止程序员上班迟到吗？我不讨论有没有必要，因为肯定有不少公司存在员工上班迟到的同时，没把事情做好的。 也许你又会问了：如果是这样，上KPI不就好了，给他一个活，规定好时间不就可以了？ 这个问题，我觉得不在本文讨论范围内。我只想讨论：如何防止程序员上班迟到。 了解我的人，都知道，当我遇到问题时，我往往先想的是为什么，然后再想怎么。只有知道为什么，才能根治。 那么他们为什么要迟到呢？这个问题似乎是无解的。就似常常迟到的小学生，被老师问起原因一样，每个小学生，每一天都有自己的理由。 好吧，对于似乎无解的问题，我们暂且放一放。 回到问题本身：怎么“防”？ 一提这个问题，绝大数人就想到了：上打卡机呗。 以前，我也是这绝大数人的其中一个。可是最近，另一个疑问进入到我的大脑： 为什么去年我带团队时，没有迟到现象？ 晨会——这个词突然击中我。是的，因为团队每天早上上班时间点过20分钟都会准时进行晨会。 晨会就是指所有团队成员站着过任务卡，晨会一般都会很短。好处什么的，具体可以看我的另一篇博客：每日站会、代码审查、结对编程 之开源中国实践 晨会是如何“防止”程序员上班迟到的呢？ 因为我们团队达成一致：上班时间点过20分钟进行晨会。假如10点上班，你一个人10点20了还没来到，你好意思吗？ 不知道有人想到其中的腻味？人是会不好意思的，在团队这个交际圈里，除非你不想在这个团队待了。换句话说，这样的晨会在一定程度上利用了人性对交际的焦虑来实现“防迟到”。 但是，我要申明，我要申明，我要申明：晨会的真正目的不是为了防止程序员上班迟到！晨会达到自己的目的的同时，恰好解决了“迟到”这个企业难题。 有人会问，为什么10点上班，10点20才开始晨会？因为我们需要给团队成员一点时间进入工作状态，给团队成员一些空间融合。 小结 做水利工程时，与其围堵，不如疏导。这样的战略方针，在企业管理中同样有用。我们在思考如何“防”时，不应该只想着如何围堵，疏导可能是更好的解决方案。而晨会就是一种疏导方案。 题外话，员工为什么会故意迟到？这是另一个有更有深度的问题，留给大家。:)

P.S. 如果你没有了解过互联网产品，下文可能不适合你，因为我没打算写得能让所有人都懂。 Airbnb，就不详细介绍了。而Joe Gebbia则是这家公司的首席产品官兼共同创始人。 他在Ted上有一个Talk：How Airbnb designs for trust。而在网易公开课上翻译成：如何与陌生人建立信任？ 这个标题翻译得是否合适，仁者见仁了。 但从Talk本身，我学到了不少关于**“做产品”**的东西。以下是我所学到的，但对你来说这是二手知识，推荐你自己先看一遍视频，再继续阅读本文。 是什么驱动产品设计 我们的社会从小给就我们灌输了陌生人 = 危险的观念。同时，家是一个人最私密的地方，你怎么才会将这个私密的地方公开给一个陌生人住呢？ 而Joe知道Airbnb这款产品的本质是什么。是信任！如果不打破人们陌生人=危险这个观念，Airbnb不可能成功（至少当前是成功的）。 他们(似乎)研究了如何增加陌生人之间的信任。Talk中，他说： 事实证明：一个精心设计的信誉体系，是建立信任的关键。 P.S. 我想到了支付宝 然后才有Airbnb不一样的评论机制：只有房东和租客都评论后，评论才展示。这里有个问题需要你来思考：为什么要这样控制评论的展示时机？而不是追求评论数？哈哈。 说到这里，我最想说的是：原来这就是产品的本质驱动产品设计。 但是怎么做？ 但是当我们知道产品的本质后，如何做？或者说是如何在做产品的过程中慢慢发现这个本质？ Talk中，Joe说了Airbnb与斯坦福大学合作。不知道怎么合作，反正他们发现： 我们更喜欢与我们相似的人，与我们差异越大，我们越是不信任他们。这是人们与生俱来的天性。正确的设计可以帮助我们克服人们扎根心底的认知偏见。 P.S. 看到这里，我第一反应是：他们怎么会想到和大学合作？ 最后，他们通过数据分析发现： 当评论大于10条时，高的信誉评论比高的相似度更可信！ 房客的自我介绍是如何影响自己的被接受率的 是的，通过数据分析，我们就可以做各种实验并进行实验对照，以找到增加陌生人之间的信任度的方法。 这似乎是个老掉牙的问题了。 亲近你的用户 产品初期，Joe用自己的手机号码做起了客服。所以，他才会知道现有产品会有哪些不足。 这也是个老掉牙的问题了。 后记 上文绝属我个人虚构，Joe是不是这样想的，只有他知道。😂 本次Talk还有讲共享经济，而我只说了“做产品”这部分。 部分内容摘自字幕，如有侵权，麻烦告知。谢谢。

摘要：本文尝试一步步还原HTTPS的设计过程，以理解为什么HTTPS最终会是这副模样。但是这并不代表HTTPS的真实设计过程。在阅读本文时，你可以尝试放下已有的对HTTPS的理解，这样更利于“还原”过程。 我们先不了聊HTTP，HTTPS，我们先从一个聊天软件说起，我们要实现A能发一个hello消息给B： 如果我们要实现这个聊天软件，本文只考虑安全性问题，要实现 A发给B的hello消息包，即使被中间人拦截到了，也无法得知消息的内容 如何做到真正的安全？ 这个问题，很多人马上就想到了各种加密算法，什么对称加密、非对称加密、DES、RSA、XX、噼里啪啦~ 而我想说，加密算法只是解决方案，我们首先要做的是理解我们的问题域——什么是安全？ 我个人的理解是： A与B通信的内容，有且只有A和B有能力看到通信的真正内容 好，问题域已经定义好了（现实中当然不止这一种定义）。对于解决方案，很容易就想到了对消息进行加密。 题外话，但是只有这一种方法吗？我看未必，说不定在将来会出现一种物质打破当前世界的通信假设，实现真正意义上的保密。 对于A与B这样的简单通信模型，我们很容易做出选择： 这就是对称加密算法，其中图中的密钥S同时扮演加密和解密的角色。具体细节不是本文范畴。 只要这个密钥S不公开给第三者，同时密钥S足够安全，我们就解决了我们一开始所定问题域了。因为世界上有且只有A与B知道如何加密和解密他们之间的消息。 但是，在WWW环境下，我们的Web服务器的通信模型没有这么简单： 如果服务器端对所有的客户端通信都使用同样的对称加密算法，无异于没有加密。那怎么办呢？**即能使用对称加密算法，又不公开密钥？**请读者思考21秒钟。😜 答案是：Web服务器与每个客户端使用不同的对称加密算法： 如何确定对称加密算法 慢着，另一个问题来了，我们的服务器端怎么告诉客户端该使用哪种对称加密算法？ 当然是通过协商。 但是，你协商的过程是没有加密的，还是会被中间人拦截。那我们再对这个协商过程进行对称加密就好了，那你对协商过程加密的加密还是没有加密，怎么办？再加密不就好了……好吧，进行鸡生蛋蛋生鸡的问题了。 如何对协商过程进行加密 新问题来了，如何对协商过程进行加密？密码学领域中，有一种称为“非对称加密”的加密算法，特点是私钥加密后的密文，只要是公钥，都可以解密，但是公钥加密后的密文，只有私钥可以解密。私钥只有一个人有，而公钥可以发给所有的人。 虽然服务器端向A、B……的方向还是不安全的，但是至少A、B向服务器端方向是安全的。 好了，如何协商加密算法的问题，我们解决了：使用非对称加密算法进行对称加密算法协商过程。 这下，你明白为什么HTTPS同时需要对称加密算法和非对称加密算法了吧？ 协商什么加密算法 要达到Web服务器针对每个客户端使用不同的对称加密算法，同时，我们也不能让第三者知道这个对称加密算法是什么，怎么办？ 使用随机数，就是使用随机数来生成对称加密算法。这样就可以做到服务器和客户端每次交互都是新的加密算法、只有在交互的那一该才确定加密算法。 这下，你明白为什么HTTPS协议握手阶段会有这么多的随机数了吧。 如何得到公钥？ 细心的人可能已经注意到了如果使用非对称加密算法，我们的客户端A，B需要一开始就持有公钥，要不没法开展加密行为啊。 这下，我们又遇到新问题了，如何让A、B客户端安全地得到公钥？ 我能想到的方案只有这些： 方案1. 服务器端将公钥发送给每一个客户端 方案2. 服务器端将公钥放到一个远程服务器，客户端可以请求得到 我们选择方案1，因为方案2又多了一次请求，还要另外处理公钥的放置问题。 公钥被调包了怎么办？又是一个鸡生蛋蛋生鸡问题？ 但是方案1有个问题：如果服务器端发送公钥给客户端时，被中间人调包了，怎么办？ 我画了张图方便理解： 显然，让每个客户端的每个浏览器默认保存所有网站的公钥是不现实的。 使用第三方机构的公钥解决鸡生蛋蛋生鸡问题 公钥被调包的问题出现，是因为我们的客户端无法分辨返回公钥的人到底是中间人，还是真的服务器。这其实就是密码学中提的身份验证问题。 如果让你来解决，你怎么解决？如果你了解过HTTPS，会知道使用数字证书来解决。但是你想过证书的本质是什么么？请放下你对HTTPS已有的知识，自己尝试找到解决方案。 我是这样解决的。既然服务器需要将公钥传给客户端，这个过程本身是不安全，那么我们为什么不对这个过程本身再加密一次？可是，你是使用对称加密，还是非对称加密？这下好了，我感觉又进了鸡生蛋蛋生鸡问题了。 问题的难点是如果我们选择直接将公钥传递给客户端的方案，我们始终无法解决公钥传递被中间人调包的问题。 所以，我们不能直接将服务器的公钥传递给客户端，而是第三方机构使用它的私钥对我们的公钥进行加密后，再传给客户端。客户端再使用第三方机构的公钥进行解密。 下图就是我们设计的第一版“数字证书”，证书中只有服务器交给第三方机构的公钥，而且这个公钥被第三方机构的私钥加密了： 如果能解密，就说明这个公钥没有被中间人调包。因为如果中间人使用自己的私钥加密后的东西传给客户端，客户端是无法使用第三方的公钥进行解密的。 话到此，我以为解决问题了。但是现实中HTTPS，还有一个数字签名的概念，我没法理解它的设计理由。 原来，我漏掉了一个场景：第三方机构不可能只给你一家公司制作证书，它也可能会给中间人这样有坏心思的公司发放证书。这样的，中间人就有机会对你的证书进行调包，客户端在这种情况下是无法分辨出是接收的是你的证书，还是中间人的。因为不论中间人，还是你的证书，都能使用第三方机构的公钥进行解密。像下面这样： 第三方机构向多家公司颁发证书的情况： 客户端能解密同一家第三机构颁发的所有证书： 最终导致其它持有同一家第三方机构证书的中间人可以进行调包： 数字签名，解决同一机构颁发的不同证书被篡改问题 要解决这个问题，我们首先要想清楚一个问题，辨别同一机构下不同证书的这个职责，我们应该放在哪？ 只能放到客户端了。意思是，客户端在拿到证书后，自己就有能力分辨证书是否被篡改了。如何才能有这个能力呢？ 我们从现实中找灵感。比如你是HR，你手上拿到候选人的学历证书，证书上写了持证人，颁发机构，颁发时间等等，同时证书上，还写有一个最重要的：证书编号！我们怎么鉴别这张证书是的真伪呢？只要拿着这个证书编号上相关机构去查，如果证书上的持证人与现实的这个候选人一致，同时证书编号也能对应上，那么就说明这个证书是真实的。 我们的客户端能不能采用这个机制呢？像这样： 可是，这个“第三方机构”到底是在哪呢？是一个远端服务？不可能吧？如果是个远端服务，整个交互都会慢了。所以，这个第三方机构的验证功能只能放在客户端的本地了。 ...

导致CPU100%的原因很多，而程序中出现死循环就是原因之一。然而，并不是每个人在工作中都有机会踩中这个坑。我就是其中一个没踩过的。人生似乎有些不完整。 所以，我做了一个很重要的决定：在程序中写一个死循环。看看会发生什么事情。 当然，不是在生产环境。😜 我搭建了一个实验环境来做实验。只是这个实验环境不仅可以用于这个死循环实验。以下是这个环境的结构图： 还是老样子，使用Vagrant + Virtualbox + Ansible自动化搭环境。代码及搭建步骤在文末。 我们会写一个简单的Spring MVC 应用，然后其中一个接口里会有死循环代码： @RequestMapping(value = "/loop", method = RequestMethod.GET, produces = "application/json; charset=UTF-8") public void endlessLoop() { int i = 0; while (true) { System.out.println(i += 1); } } 以下是我自己尝试找出这个死循环的过程。 使用top，查看是哪个进程的问题 我请求一次：http://192.168.88.10:9898/web/loop 然后，我打开新窗口，又请求一次 这里，我好奇CPU没有到200%。一直在120%和130%之间。P.S. 我一定是某个知识点不牢固，要不，不会有这个疑问。 堆空间 因为不涉及JVM堆空间问题，执行 jstat -gcutil 32593 1s 没看出什么问题。32593为Java进程ID，1s指1秒抽样一次。 栈 堆没问题，就看看是哪个线程占用得高。 列出java进程的线程，top -H -p <java 进程pid> 将jvm的栈dump下来 jstack -l <其中一个线程PID> >> stack.log，这里我选3596。 ...

摘要：John McCarthy身为Lisp之父和人工智能之父，同时，他也是GC之父。1960年，他在其论文中首次发布了GC算法（其实是委婉的提出😂）。而Java的前身Oak是在1990发布的，利用JVM实现了跨平台。GC因此一举成名。 最近想复习一下JVM的知识。然后发现网上不少文章在写JVM的垃圾回收算法时，都比较偏向于具体实现，而少有站在更高角度来看垃圾回收算法的文章。而我本人想对垃圾回收算法有个全景的认识，所以，就找到了这本《垃圾回收的算法与实现》（以下简称《垃圾回收》）。本篇博客就是尝试对“全景”的总结。 以下为方便讨论，垃圾回收缩写成GC。 为什么要有GC 我时而听到C++程序员说我们是被GC惯坏了的一代。的确是这样的，我本人在学习GC算法时，大脑里第一问题就是为什么需要GC这样的东西。说明我已经认为GC是理所当然了。😂 总的一句话：没有GC的世界，我们需要手动进行内存管理，而手动内存管理是纯技术活，又容易出错。 既然我们写的大多程序都是为了解决现实业务问题，那么，我们为什么不把这种纯技术活自动化呢？但是自动化，也是有代价的。 这是我的个人理解，不代表John McCarthy本人的理解。 “垃圾”的定义 首先，我们要给个“垃圾”的定义，才能进行回收吧。书中给出的定义： 把分配到堆中那些不能通过程序引用的对象称为非活动对象，也就是死掉的对象，我们称为“垃圾”。 GC的定义 因为我们期望让内存管理变得自动（只管用内存，不管内存的回收），我们就必须做两件事情： 找到内存空间里的垃圾 回收垃圾，让程序员能再次利用这部分空间 [1] 只要满足这两项功能的程序，就是GC，不论它是在JVM中，还是在Ruby的VM中。 但这只是两个需求，并没有说明GC应该何时找垃圾，何时回收垃圾等等更具体的问题，各类GC算法就是在这些更具体问题的处理方式上施展手脚。 GC的历史 John McCarthy身为Lisp之父和人工智能之父，同时，他也是GC之父。1960年，他在其论文中首次发布了GC算法（其实是委婉的提出😂）。 标记-清除算法 由John McCarthy在1960年提出 引用计数法 由George E. Collins在1960年提出 此算法会有循环引用问题，Harold McBeth 1963年指出。 复制算法 由Marvin L. Minsky在1963年提出 《垃圾回收》的作者认为： 从50年前GC算法首次发布以来，众多研究者对其进行了各种各样的研究，因此许多GC算法也得以发布。[2] 但事实上，这些算法只不过是把前文中提到的三种算法进行组合或应用。也可以这么说，1963年GC复制算法诞生时，GC的根本性内容就已经完成了。[3] 那我们常常听说的分代垃圾回收又是怎么回事？作者是这样说的： 人们从众多程序案例中总结出了一个经验：“大部分的对象在生成后马上就变成了垃圾，很少有对象能活得很久”。分代垃圾回收利用该经验，在对象中导入了“年龄”的概念，经历过一次GC后活下来的对象年龄为1岁。[4] 分代垃圾回收中把对象分类成几代，针对不同的代使用不同的GC算法，我们把刚生成的对象称为新生代对象，到达一定年龄的对象则称为老年代对象。[5] 好了，这下我总算知道为什么要分代了，我的总结是： 将对象根据存活概率进行分类，对存活时间长一些的对象，可以减少扫描“垃圾”的时间，以减少GC频率和时长。根本思路就是对对象进行分类，才能针对各个分类采用不同的垃圾回收算法，以对各算法进行扬长避短。 留一个问题给读者：我们知道分代垃圾回收所采用的堆结构是： 为什么新生代空间要分成“生成空间”和“幸存空间”，而幸存空间又分成两块大小相等的幸存空间1，幸存空间2? 这些GC算法共同解决的问题 上面我们说了，GC的定义只给出了需求，三种算法都为实现这个需求，那么它们总会遇到共同要解决的问题吧？ 我尝试总结出： 如何分辨出什么是垃圾？ 如何、何时搜索垃圾？ 如何、何时清除垃圾？ 这样，只要涉及到垃圾回收，我就可以从这2点需求，3个共同问题（两点三共）出发来讨论、学习。 如何评价GC算法？ 如果没有评价标准，我们当然无法评估这些GC算法的性能。作者给出了4个标准： 吞吐量: 单位时间内的处理能力 最大暂停时间：GC执行过程中，应用暂停的时长。 较大的吞吐量和较短的最大暂停时间不可兼得 堆的使用效率：就是堆空间的利用率。 可用的堆越大，GC运行越快；相反，越想有效地利用有限的堆，GC花费的时间就越长。 访问的局部性：把具有引用关系的对象安排在堆中较近的位置，就能提高在缓存中读取到想利用的数据的概率。 好吧。两点三共，四标~ 小结 搞清楚为什么要GC，要实现GC都要解决什么问题，而各类算法又是怎么解决的，最后怎么评价这些算法。GC原来是这么回事。 但是这不是GC的全部。但是提供我一个思考GC的思考框架。 以上就是《垃圾回收的算法与实现》的读书笔记。如果想更深入，可以阅读《垃圾回收算法手册:自动内存管理的艺术》。 [1] 《垃圾回收的算法与实现》 P2 ...

像学习Spark这类大数据平台，搭建环境，是一件很费时费力的事情。特别是当你想使用多台机器模拟真实生产环境时。 为了更有效的学习Spark，我决定将自己的学习环境按生产环境的要求来搭建。但是真实生产环境的群集往往由多个集群组成：Hadoop/Hbase集群、Zookeeper集群、Spark集群。掐指一算，至少需要6台机器了。 我们真的需要买6台机器吗？当然不是，我们只需要在自己的电脑上虚拟化出6台就好了。而我的电脑只有16G，虚拟化6台太吃力了。最终，我决定搭建成以下结构： 以下是搭建过程： 环境的搭建 按以前学习像Spring这些类Web，开发环境的搭建非常简单，也就引入几个依赖，添加几项配置，就好了。 但是学习Spark，我敢肯定不少人在环境搭建这一环节踩坑。正因为这样，才会有此博客。 Spark不是一框架，而是一个分布式的计算平台。所以，你不能通过引入依赖，添加配置就完成搭建。需要先将Spark这个平台部署起来。Spark支持4种部署方式： 单机：同一台机器，同一进程，不同线程运行Master和Worker 伪分布式：同一台机器，不同进程分别运行Master和Worker Standalone方式：多台机器分别运行Master和Worker，自己解决资源调度 Yarn和Mesos方式：将资源调度这一职责外包出去 虽然Spark的单机部署方式很简单，但是没有人会在生产环境上使用单机部署方式。而伪分布式我见不少人搭建，以此为基础来学习Spark。但我不推荐。 因为在线上真正运行的是Standalone、Yarn、Mesos方式，也称为完全分布式的方式。只有一开始就使用完全分布式的方式来进行开发调试，你才会学习到生产环境会遇到什么问题。 机器准备 如果采取完全分布式的部署方式来学习，你必须准备很多台机器，就像上面所说的。 我想大多数人都会选择虚拟化方案来得到多台机器。我推荐Virtualbox。 我见不少人手工的创建一台机器，然后安装操作系统，接着想要多少台机器，就复制几台，甚至还要分别进入机器修改每台机器的IP。。。 这样的方式，效率低，又很难与你的同事分享你的环境（也就是统一一个团队的开发环境，以避免不同开发环境不同引起的问题）。 所以，我一开始就使用Vagrant。把机器的虚拟化这一动作进行自动化和版本化（提交到git仓库中）。使用了Vagrant，你只需要在Vagrantfile中定义机器数据、机器的系统镜像、CPU个数、内存，然后执行vagrant up，就可以得到你想要的机器了。要与同事统一这些机器，只需要他使用相同的Vagrantfile就好了。 同时，这样，还能实现：统一开发环境与生产环境使用同样或相近的机器环境。 以下是一个Vagrantfile样例： Vagrant.configure(2) do |config| VAGRANT_VM_PROVIDER = "virtualbox" machine_box = "boxcutter/ubuntu1604" -> 系统镜像 config.vm.define "offlinenode1" do |machine| machine.vm.box = machine_box machine.vm.hostname = "offlinenode1" machine.vm.network "private_network", ip: "192.168.11.151" -> 指定IP machine.vm.provider "virtualbox" do |node| node.name = "offlinenode1" node.memory = 4096 -> 指定内存 node.cpus = 2 -> 指定CPU个数 end end config.vm.define "offlinenode2" do |machine| machine.vm.box = machine_box machine.vm.hostname = "offlinenode2" machine.vm.network "private_network", ip: "192.168.11.152" machine.vm.provider "virtualbox" do |node| node.name = "offlinenode2" node.memory = 4096 node.cpus = 2 end end ....... 还可以定义很多这样的机器 end 搭建Spark集群 在准备好机器后，接下来做的就是搭建Spark集群。我会选择Ansible来实现自动化搭建，而不是一台台机器登上去，一条条命令的执行安装。 ...

先申明：我反驳“以结果为导向”的某些理由，并不代表我认为管理应该不制定目标，管理不应该有结果。 前些天与朋友聊天，聊到管理。虽然两人所处不同行业，他是保险业，我是软件开发，当聊到管理的“以结果为导向”。我的话匣就打开了。 后来，我总感觉自己思路还不够清晰，就总结此文。 首先，我们需要统一对“以结果为导向”这个概念的理解。要不，我们的讨论可能就不在同一个频道上。 我听过的最多的，对于“以结果为导向”的理解就是：我只管结果，不管你中间过程怎么做。 这个“我”，是当事人。这里的假设是，这个“我”是一个管理者。 但是，为什么呢？只管理结果，不管过程呢？我得到的理由是： 人多了，会管不过来 作为“领导”（很多人常常把领导和管理两个概念混淆），下属当然要完成领导指派的“结果”，否则，我要你做什么？ 我们要鼓励员工的主人翁精神 微管理会束缚员工的创造性 我不知道， 上述的有没有统一大家的理解。但我还是要尝试接着逐一讨论。 人多了，会管不过来 对于“人多了，会管不过”这个观点，我听到的阐述是： 当你手下只有3个人的时候，你当然可以管得过来，你可以很容易知道他们上班时间里有没有干与工作不相关的事情，甚至知道他们什么时候去厕所了。 但是当你做到事业部经理时，管理4个部门，每个部门都有100个人的时候，你怎么管。 这些支言片语中，我粗鲁地认为这些言语包含以下几点假设： 管理中，“监督”工作占很大的比例 管理一个3人团队和管理4个100人部门使用的是同一套管理方式 管不过来，是因为人多 我的个人观点： 以上几点假设之间相关的，因为如果管理400人时和管理3人时的方法一样，管不过来，当然是因为人多。同时，人数不是决定管理方法的唯一因素，还有你的团队成员职能结构组成等等。 我是领导，我只管结果 我擅自将“作为领导，下属当然要完成领导指派的‘结果’，否则，我要你做什么？”这句长句抽象成：我是领导，我只管结果。这个“结果”的同义词是目标，也被称为KPI。 首先，我们得承认，某些“领导”有这个权利那样做。 接着，我从这个观点中看到以下几点假设： 下属足够做得好，怎么样都能完成我（领导）定好的“结果” 领导的工作就是“管结果” 领导定好的“KPI”就是正确的 我的观点： 定好KPI是一种能力。如果一个没有定好KPI能力的领导说他只管结果，下面的员工就只能呵呵了。 管理是有级别的，过程终究是要管理的，只不过，不同的级别，管理的过程不一样。一线项目经理手下可能有前端、后端，如果他只管结果，不管，前后端是如何协作的，他是怎么知道他们团队的工作效率的？如果连自己的团队的工作效率都评估不了，我要这个项目经理做什么？😜 所以，并不是每种“领导”都有权利说“只管结果” 我们要鼓励员工的主人翁精神 这句话的假设是： 管理过程了，就是不鼓励员工的主人翁精神 只管结果，员工才会有主人翁精神 微管理会束缚员工的创造性 这句话的假设是： 只管结果，不管过程就不是微管理了 管过程就是微管理，那么，又引申出来假设：管过程会束缚员工的创造性 微管理会束缚员工的创造性 思考这些理由背后的假设是否成立 反驳一个人的观点时，一个有效的方法就是找到他的观点背后的“假设”。所以，我尝试去找到那些理由背后的假设。因为如果假设不成立，他的理由当然也就不成立了。 以上的“假设”在不同的公司环境，结果可能不一样。比如管理中，“监督”工作占很大的比例，在软件行业，管理活动中，“监督”所占的比例当然没有劳动力密集型工厂里的管理所占比例大。不过，说回来，软件行业也有劳动力密集型的。 软件行业的过程管理 说到底，一线软件开发团队当然需要过程管理，要不，你没办法评估它的开发效率。 当然，有些人就会反驳，你制定一个目标，如果他完成了，那么不是说明效率可以吗？ 我的回答是：你的假设是完成目标等于效率高，你仔细想想，这两者是等于关系吗？ 但是管理到什么程度算“微”，我目前没有想到好的度量方法。不过，过去一年中，我发现使用“看板”来进行微管理，效果不错。既能管理结果（软件产品），也能管理过程（团队成员协作）。本文的目的不在讨论软件行业如何进行过程管理，所以，就不深入讨论了。 小结 倡导“以结果导向”的管理方式的人，本质上是在倡导宏观管理。其实，倡导宏观管理，就是在假设宏观管理和微观管理是两个矛盾的东西。但是，我不认为这个假设是正确的，因为我们的目标是管理好一家公司以实现盈利，总之就是要管理好，为了实现这个目标，需要进行宏观管理时，就进行宏观管理，需要进行微观管理时，就进行微观管理。我们不能因“宏观”和“微观”的概念之分而忘记管理的初心。 上述观点纯属个人理解，不一定正确。欢迎讨论。 扩展阅读：平庸的领导忙着无数小事，卓越的领导从来只管大事

为什么想做这个东西 一直好奇像亚马逊这类网站的搜索是如何做到推荐的，最近刚好看到一篇文章：Redis 与搜索热词推荐，然而只写了思路。所以，就是想自己实现一个。 先上个效果图，再聊： P.S. 按四年前，要写这样的前端效果，对于我这个后台开发，还是挺困难的。而现在，简单的学了下Vue.js，再加上同事的小小指点，就搞定了。😂 热词推荐的本质 假如你预先就知道了用户输入：s、sz、shen、深这些字时，就是想搜“深圳”，那是不是说，我们只要提前将这些字放到一个Map结构中，将用户的输入想像出一个key，value就是“深圳”。 说到底，热词推荐的本质就是一个大大的Map。难点就在于如何更新这个Map，以至于让用户觉得“智能”，或觉得我们在给他们做“推荐”。 这个Map，常常被人称为“索引”。其实使用“索引” 这个名词也更准确一些。Map中的Key是不能重复的。但是我们数据结构是要求可重复的，为什么呢？因为，在系统中，s、sh、shen、深等等这些都是key，而它们对应的value，可能相同，又可能不同。举个例子： hotword:0>zrevrange s 0 10 1) 鼠蛟 2) 鼠场乡 3) 鳝鱼 4) 鳝溪校区 5) 鳝溪农场 6) 鳝溪 7) 骚子营社区 8) 骚子营 9) 驷马镇 10) 驷马桥街道 11) 驷马桥 hotword:0>zrevrange sh 0 10 1) 鼠蛟 2) 鼠场乡 3) 鳝鱼 4) 鳝溪校区 5) 鳝溪农场 6) 鳝溪 7) 首院胡同 8) 首阳镇 9) 首阳山镇 10) 首阳山 11) 首钢试验厂 仔细看到其中的不同了吗？同时，这里还有一个问题，那就是当用户输入s时，出现了10个value，我们如何给这些value如何排序呢？ 为了与排序模型解耦，我们为每个value都给出一个分数score。score越大，越排前面。最终索引结构就变成了这样子： P.S. 这些score之所以都为0，是因为数据问题。 总的来说，关于热词推荐，我们需要解决以下问题： 如何存储索引的数据？ ...

关键绩效指标（英语：Key Performance Indicators，简称KPI），又称主要绩效指标、重要绩效指标、绩效评核指标等，是指衡量一个管理工作成效最重要的指标，是一项数据化管理的工具，必须是客观、可衡量的绩效指标。这个名词往往用于财政、一般行政事务的衡量。是将公司、员工、事务在某时期表现量化与质化的一种指标。可协助将优化组织表现，并规划愿景。 KPI是指衡量一个管理工作成效的最重要指标。注意，是管理工作成效。实现中，管理工作当然由管理者来做，也就是管理者是拿来KPI来管理自己的工作成效。同时，KPI也要选择最重要的指标，而不是什么都选 ，因为并不是每项KPI都能体现管理工作成效。 光看这个定义，似乎很多公司都把KPI理解成：“员工完成了管理者安排的工作” == “管理者的管理工作有成效”！而且，只止于此。 翻看历史你就理解我说的了：宋太宗“雄韬武略”遥控指挥军队差点全军覆没！ 作为管理者宋太宗的管理工作成效应该是打赢仗，而不是军队有没有按照他的“阵图”来行军。（我又甩锅了。呵呵） 光看KPI是没有问题的，谁都想知道自己的工作成效如何，尤其作为管理者。 但，KPI的选择并没有那么简单。根据自己对KPI的理解，管理者为自己找KPI时必须做到： 管理者必须理解KPI的目标：衡量自己的管理工作成效。 管理者必须理解公司的业务目标是什么，避免为了KPI而KPI。 管理者必须知道业务指标是什么？比如500万的销售额 管理者必须知道执行哪些管理工作才能帮助实现业务指标，如果不知道，那么就需要做实验，再验证！ 管理者必须知道自己有没有100%执行相应的管理工作 定义个KPI都这么难，所以，管理者不好当啊。你也看到了，我一句也没有提下属的KPI。因为下属的KPI是需要管理者与其下属共同制定的。下属对自己的管理成效本质上就是很多公司希望的“自我管理”。而自我管理的成效是没有办法量化的，作为管理者，也只能看下属的自我管理后的表象。 看到这里，相信还是有很多人疑惑，到底怎么做KPI啊。 首先申明，KPI不是制定出来的，而是找出来的。因为指标本来就存在了，问题只是你选择什么指标作为管理成效的KPI。它是一个名词，不是动词。（想起人们常常开的玩笑：你今天被KPI了吗？） 那如何找KPI呢？我的回答是：你清晰地知道你的业务目标，以及如何达到，你就自然而然地知道你的KPI有哪些了。 小结 KPI是一个名词，不是一个动词。管理者的管理成效不等于员工的100%执行。KPI本质上是自我管理，不是上级对下级的工作安排。工作如何安排，不在本文讨论范围。 抱怨KPI是没有用的，现实世界中，KPI在企业中会与企业的其它因素起化学反应，远没有本文说的那么简单。 最后，两个思考题： “如果新浪要求自己员工每天要发2条以上微博” 这条能成为新浪员工的KPI吗？ “主导XXX系统（或模块）开发” 这条能成为你的KPI吗？ 请停留思考，然后再看：SMART原则。

进入ThoughtWork后，每天都会有人向你提反馈。比如站会，你这样说会更好；你代码这样写也许会更好；你这段时间英语进步得非常快……这些反馈中，有对你优点反馈，也会对你的缺点进行反馈。 这个过程，我才发现自己以前很多没有发现的不足，某些固化的思维方式，我的视野也一下开了好多。 后来，离开了ThoughtWorks。我尝试将反馈机制带入到自己的团队。怎么尝试呢？ 首先，你需要让团队成员达成共识：只有成长，我们的生活才更美好，而反馈就是在帮助对方成长。当然人们对于“美好”的理解不同，有些人觉得有钱就是美好，有些人觉得得真正学到东西就是美好。这些都无所谓。因为成长了，这些美好都会有。 接着，从自己做起。每天尝试给团队成员反馈。只要找到合适的时机及时给予反馈。举例子： 一个成员写代码时，不加思索的就上个大大的if-else，这种情况，最好马上指出，同时告诉他背后的原因。但是现实中，有时，我们需要考虑多一些，比如这个成员是不是超级要面子的，这个成员是不是团队受尊重的老员工。这时就要考虑沟通方式了。 团队中两个成员因为某件事情吵了起来。而这件事，也不是特别大的事情，也没有吵多久。这时，你就要看他们是不是还气在头。合适的时机是等他们的气消了后，再分别给他们反馈。 然后，争取每隔一段时间就每一位成员进行一次一对一沟通。沟通的内容包括生活和工作，主要是了解他们对当前工作的看法，生活上有什么需要帮忙，学习上有没有遇到困难，工作上有什么不顺心……这个过程其实是成员向你反馈： 工作安排得合理不合理？ 与同事相处是否舒服？ 有没有学习的焦虑？ …… 《创业维艰》这本书专门有一节谈“一对一的沟通”，有兴趣的朋友可以看看。 最后，引导并指导团队成员相互之间进行反馈。 话说这里了。那反馈机制在企业中到底起到了什么作用？我不知道专业的管理行家如何回答。但是，我自己的理解是这样的： 马斯洛的需求理论，反馈能满足马斯洛的需求理论中的的安全需求（你可以和他一对一沟通）、归属需求（Leader是把他当一个团队成员来对待的）、尊重需求（尊重了他）。 人天生就是通过反馈来成长，就像小孩通过你他的反馈来调整自己的行为。而如果团队成员得到了成长，就刚好可以满足了他的“自我实现”需求。 需求得到了满足，在其中工作，当然就会快乐。 有人就会说了，员工在工作中能否找到快乐，那是员工的事。这个观点即对，也不对。快乐的确是每一个人的。但是员工毕竟是人，不是机器。 不快乐的工作，同样可以完成机械的活，像珠三角大批的工厂工人。而创造性的工作，如软件开发，做产品，不是机械完成就好了的，也不是能通过机械地堆人就能完成的。 同时，反馈带给员工的成长，会正反馈到工作中，员工工作效率高了（学习新的技术、知道更多的解决方案），我们软件开发速度及开发质量会不会提高呢？ 小结 我个人认为，以上只是“反馈机制”给企业带来表面利益，它给企业的是更深层次的东西：企业相互学习、相互帮助的文化。不是说企业有了“反馈机制”就有了文化，而是说企业文化就是由这些道不清说不明的东西，通过时间一点点积累起来的。 以上是个人习得的，希望能和大家交流。