first commit

专栏/技术领导力实战笔记/000开篇词卓越的团队，必然有一个卓越的领导者.md

@@ -0,0 +1,49 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            000 开篇词 卓越的团队，必然有一个卓越的领导者
+                            管理大师彼得·德鲁克说：“组织的目的，就是让平凡的人做出不平凡的事。”然而，不是任何一群平凡的人聚集到一起，都能做出不平凡的事。甚至一群优秀的人聚集到一起，也可能只是一个平庸的组织。
+
+因为，大到一个国家，小到一个团队，任何一个卓越的组织，都必须有一个卓越的领导者。领导者是一个组织的灵魂，在很大程度上决定了组织所能达到的高度。
+
+技术团队同样如此，管理者的战略眼光、管理方法、人格魅力等，都会给团队的工作结果带来决定性的影响。
+
+但技术管理者面临的具体问题又有其独特之处。虽然CTO、技术VP、技术总监等职位的职责各有偏重，但总的来说，技术管理者对内要负责技术选型、产品功能实现、团队成员培养、技术人员考核等等；对外则要承担扩大公司技术影响力、为公司招募更多优秀研发人员，发展潜在客户等职责。
+
+因为工作关系，我们有机会经常与技术管理者交流。在这一过程中我们发现，技术管理者面临的问题往往是相通的，每一个技术人在通向技术高管的路上都要趟过无数个坑。比如“如何与其他部门的负责人高效沟通？”“如何制定科学的绩效考核方法？”“面对新的技术趋势应该如何布局？”“怎样做好技术人员招聘？”等等。
+
+关于这些问题，通过其他优秀的技术领导者在实践中总结的方法论来学习和提升，是最为高效的方式。因为人类之所以能够取得今天的成就，就是因为我们可以通过阅读等方式，不断地在前行者的基础上再进一步。
+
+而即便你已经一路升级打怪，成为了一名优秀的CTO，你仍然会面临许多挑战：行业格局瞬息万变、技术浪潮风起云涌、资本市场残酷善变，更不要说公司新加入的高管很可能与你气场不合，你与公司商定的股权分配方案可能存在隐患……
+
+在这一背景之下，极客时间推出了“技术领导力实战笔记”专栏。这是一个针对技术高管的付费专栏，由阿里、腾讯、AWS等上百家知名互联网公司的优秀技术领导者和CEO共同贡献和维护，专栏内容涵盖前沿技术、趋势分析、团队管理、软性技能等技术管理者关注的重点问题。该专栏希望通过体系化、有洞见的课程来帮助技术管理者提升认知，升华自我。
+
+“技术领导力实战笔记”专栏中的每篇文章，都是这些身经百战的管理者们基于实践经验的总结和提炼。专栏作者中，有些曾经获得“最具价值CTO”的荣誉，对于团队管理有自己的独到方法；有些从CTO进阶为CEO，对于CTO和CEO应该如何相处有着深刻理解；有些带领技术团队从无到有完成核心系统架构，助力公司业务实现百倍增长……
+
+每周五，我们还将邀请一位技术大神或互联网大佬，回答你感兴趣的问题。他们将以更高的高度，带来不一样的资讯和思辩。一些以往只能在新闻里看到的名字，你也将有机会与他们直接对话。
+
+我们将陪伴你一整年的时间，用六大模块为你详解技术领导力：
+
+一、格局与战略。这部分内容将帮助你打开视野，理解卓越技术领导者的核心能力的概念和价值，像 CEO 一样思考商业，让技术与商业战略协同，确立管理者能力模型。
+
+二、团队管理。这部分涵盖人员招聘、绩效考核、团队文化建设、研发管理等内容，将通过大量实战经验，帮你清楚认识领导力提升的有效途径，掌握领导力提升的工具与方法。
+
+三、职场软技能。通过这部分内容，你将了解如何更好地沟通、如何向上管理、如何打造个人品牌、如何管理情绪等等。令你在工作中游刃有余，从此踏上领导力提升的新旅程。
+
+四、跳槽与创业。有时候，选择比努力更重要，所以我们建议你先做好充分的准备。我们将和你一起探讨期权、套现、合伙人、商业模式等话题，让你的人生进阶之路更加平稳。
+
+五、技术趋势解读。让你快速了解最新的技术与趋势，比如区块链、人工智能、运维技术发展到了哪个阶段，你的企业是否还在用老旧的技术解决别人早已经轻车熟路的问题。
+
+六、国家政策解读。一个卓越的领导者，一定是顺势而为的。我们会邀请行业专家深入分析解读国家机构最新发布的产业政策，助力你洞察先机。
+
+希望一年之后，你已经成为了更好的自己。
+
+“技术领导力实战笔记”是一个全年专栏，在专栏的详情页中我们列出了全年六大模块中的具体话题，供你参考。下面是近四周将会具体更新的课程，后续还有更多精彩内容，欢迎订阅。
+
+
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/001你的能力模型决定你的职位.md

@@ -0,0 +1,87 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            001 你的能力模型决定你的职位
+                            在投资圈里经常听到这样的话：“CEO和方案都有了，就差个CTO了”。技术人员听了都哈哈一笑，觉得不靠谱。
+
+但是笑过后，反思这句话，其实无论巨头公司还是初创公司，每个公司都有这个情况，有些公司真的就因为找到了合适的CTO崛起，有的公司因为找错了CTO而走上歧途，也有的CTO因为找错了公司而耽误了自己的时间。
+
+究竟什么是CTO，一个公司真的需要CTO么？哪些公司的职位对于技术管理者来讲真的是CTO的职位？同样是技术最高负责人，为什么有人叫CTO、有人叫技术总监、技术VP，有人叫首席架构师？他们之间的差别是什么？怎样才能成为一个合格的CTO？
+
+这些问题，我将通过“CTO核心能力管理”系列文章分享一些自己的思考，也重新定义一下市场上对于上述职位的定义，各位CEO和HR在发布JD的时候重新思考一下，自己需要的是一个CTO还是技术VP、还是技术总监。
+
+跟各位技术管理者也谈一下自己CTO成长之路的一些感悟，希望可以对大家有所启发，也希望大家多多提意见，让我自己也能更多的向大家学习。
+
+首先说一个观点，“所有的职位不是别人给你的，而是你自己挣出来的”，一个人在某一个公司一个职位18个月以上，基本上是获得了这个公司合伙人和其他管理者的认可，存在必合理，现存的最高技术负责人：CTO、技术VP、技术总监、首席架构师都是合理的，一个公司最高技术负责人不一定是CTO。
+
+各职位之间的差异，我从以下技术管理者需要的五个核心能力来区别开：领导力、文化构造能力、人员管理能力、体系搭建能力、技术实力。同样是最高技术负责人，在这五点能力上的强弱决定了最终自己在市场上“挣”出来的职位是什么。
+
+这篇文章会把这5个技术管理的核心能力进行阐述，然后根据下面的技术核心管理能力模型来对这些职位进行重新定义。后续几篇文章会分享一下如何提高这五方面能力的一些心得和经验。
+
+领导力：“成事”的能力
+
+领导力的定义有很多，管理大师德鲁克的定义是“领导力能将一个人的愿景提升到更高的目标，将一个人的业绩提高到更高的标准，使一个人能超越自我界限获得更大成就；另一位领导力大师约翰·麦克斯威尔的定义是：领导者是知道方向、指明方向，并沿着这个方向前进的人。
+
+而我的定义很简单：“成事”的能力，领导力最终是用各种各样的方法、人员、影响力、号召力、决策力将一个事情从0到1的能力，如果把事情做成0.99，都不是领导力的体现。是否对最终结果负责，这也是所有带”O”的职位和不带”O”的职位最大的差别。
+
+文化构造能力：“影响意识”的能力
+
+文化是人类群体创造并共同享有的物质实体、价值观念、意义体系和行为方式，是人类群体的整个生活状态。对应到技术管理上，就是管理者对于大家意识的影响力，小到对于整个技术团队价值观，公司技术氛围、行为方式和状态的构造和影响能力，大到对于国内技术生态甚至国际技术生态的影响力。
+
+文化对于公司和部门管理非常重要，它是无形之手，决定了你团队的价值观是什么，你的公司能不能招聘到高级的技术人员，在我们日常流程和管理者眼睛看不到的地方，员工是怎样工作的。
+
+是否可以打造一个合适公司发展的技术文化，是否可以构造一个开放、透明的技术氛围，是否有能力建立一个MTP（Massive Transformation Purpose）能让每个技术人员深入人心，能在技术圈内影响到志同道合的牛人来一起共同奋斗。
+
+“影响意识”的能力是一个CTO水平高低的评判标准，也是每个“O”级别管理者能力的体现。同样是CEO/CTO，除了可以“成事”的领导力，文化构造能力也是决定了哪些企业可以持续壮大，哪些企业会昙花一现的关键要素。
+
+人员管理能力：“人*100”的能力
+
+人员是一个科技企业和技术团队核心最重要的资产，如何让技术人才这样特别聪明的一群人可以高效的工作，对这些聪明人如何招、识、管、留、开，是一个技术管理者的核心技能。人员管理其中不仅仅是沟通的能力，更要是对人员素质的准确判断、员工心理、团队士气、杀伐决断、上下级管理沟通的综合能力。
+
+从发挥人员能力的角度来看，一个好的技术人才可以做到乘以1，一个优秀的总监可以做到乘以10，一个卓越的O级别人物就要做到乘以100。所以，人员管理的能力，简化来讲，就是管理者如何让人乘以100的能力。这里的人员管理，不仅仅指的是管理下级，还有管理同级和管理上级的能力，能否和其他合伙人以及CEO/COO级别紧密沟通和配合，也是一个高级管理人员是否可以成功的关键。
+
+体系搭建能力：“建巢、管事”的能力
+
+体系搭建能力比较复杂，做成一个事情，不仅仅包括项目管理的能力，而且要包括从0开始建立选择项目管理方法、选择人员管理体系，然后再根据体系进行管理的能力。不同的公司，不同的阶段管理方法和体系都会发生一些变化，从项目管理、架构管理、到人员管理、体系管理，什么时间用什么样的管理方法，控制好质量、进度、节奏、人员是一个管理人员能力的体现。从具体管代码、项目，到最高层的建立一套体系取代管理人员日常的工作，体现这个管理人员的职位和公司对他的需要。
+
+技术实力：“技术肌肉”的实力
+
+技术管理人员，技术是必不可少的，在这个维度上经常有些争论，例如“CTO要不要是极客”，“CTO应该不应该写代码”。我这么理解，把技术人员对比成运动员，一个人的技术能力就是他的肌肉的实力。有的人上肢力量很发达，可以举重；有的人腿部肌肉很发达，可以短跑，有的人肌肉匀称，善于马拉松。不同的技术人员、不同的职位，需要的肌肉群是不同的，对于不同公司的相同职位，其实需要的肌肉群也不同。没有一个人全身的肌肉都发达，也没有一个公司仅需要一种肌肉群的CTO，作为技术人员来讲，你的肌肉强度和肌肉群的分布，也会影响职位的不同。
+
+下面根据这五个维度能力模型来重新定义现在的技术管理岗位，公司的管理者也可以根据实际需要来找到公司需要的人才：
+
+技术总监能力模型
+
+
+对于技术总监来讲，要有比较强的技术基础实力和人员管理能力，主要是要能把事情完成和落地，对于小公司来讲，如果最高职位是技术总监，那么就需要技术肌肉矩阵全面的，对于大公司，技术总监意味着单项技术肌肉比较强。无论公司大小，总监级别一般都会汇报给某个业务线VP或者技术线VP/CTO，因为他不是对最终结果负责的人。同样，领导力和体系搭建能力就没有那么强，对于文化构造能力更要弱一些，因为这个层级并不需要这些能力。
+
+技术VP能力模型
+
+
+技术VP和总监最大的差异在于体系搭建能力的增强，每一个VP会有一个或者多个总监来支撑，建立一套体系让技术研发高效的运转起来，体系搭建的能力甚至要高于CTO，因为他是CTO的大内总管。而技术实力略强于总监，领导力，文化构造能力也有所提高。VP和CTO的最大差异是是否可以对技术的最终结果负责，不仅仅是技术本身、而是在财务、战略方向上是否具有决策力，这是副手和正手之间的差距。在很多时候拍板很难，因为CTO很多时候不管是不是由你直接造成的，你都要承担所有的后果。所以技术VP一般不会直接汇报给CEO，因为CEO眼里只有0和1，不会接受任何理由。同时，公司外部文化和内部文化的构造能力也是VP和CTO的差异之一。
+
+首席架构师能力模型
+
+
+首席架构师应该是在公司里技术最全面最强的一个人，技术肌肉和公司整个技术最匹配的人员。经常有人会把首席架构师能力模型和CTO能力模型搞混，首席架构师可以是Geek一样的人物，因为他不对商业的最终结果负责，但是对技术整体架构、前瞻性，技术本身体系负责。因此，首席架构经常会把方案汇报给技术VP/CTO供选择，不会最终拍板。首席架构师的技术非常厉害，领导力和文化构造能力就会相对较弱一些。
+
+CTO能力模型
+
+
+CTO是能力矩阵里最均衡的一个，突出的能力是领导力和文化构造能力，而不是技术实力。公司小的时候，CTO可能是公司中技术最强的那个人，但是CTO必须要有能力构建一个文化和体系，迅速能让比自己技术牛的人、体系搭建能力比自己强的人融入到公司，才可以让自己到更高层次上来做决策。CTO要把控和技术相关的布局节奏、商业结果、公司战略、人才策略，并翻译成其他合伙人可以听懂的语言，来做“成”事。
+
+CTO的技术肌肉通常要全身匀称的，因为他是公司里的技术肌肉教练，他可以肌肉不强大，但是要知道找什么样的技术肌肉团队来满足公司的需要，在赛场上赢球。同样，如果CTO只对技术着迷而对于CEO的融资策略、战略决策、业务布局，COO/CFO的公司运营、财务运作没有有效建议并对结果负责的话，CTO也很难成为公司CEO、COO、CTO三个重要O级别人物之一。所以，最终的管理的道理是相通的，如果你选择了CTO作为你的职业路径的话，其实你已经放弃了你是公司技术最强的那个人的成长路径。
+
+结语
+
+上面用技术管理核心模型来重新定义了这几个职位，一个初级技术管理人员可以根据自己的职业发展方向有意地培养自己的能力来达到自己的目标方向，一个公司在招聘技术人员的时候也可以对号入座，构建合适的JD找到自己合适的人才。这个“郭氏”技术管理核心模型也是第一个版本，也希望各位多给宝贵意见，促进模型本身逐步迭代，更贴近企业技术管理真实现状。后续几篇文章会分享一下如何提高这五方面能力的一些心得和经验，请大家持续关注《技术领导力300讲》。
+
+作者简介
+
+郭炜，易观 CTO ，中国软件行业协会智能应用服务分会副主任委员，TGO鲲鹏会北京分会董事会会长。负责构建易观技术团队、完成易观大数据采集、平台、数据挖掘等技术架构与体系；从无到有完成易观混合云的搭建、以及易观 SDK 的升级，并发布易观秒算实时计算平台。目前易观大数据平台日处理数据量 30T ，272 亿条，月活用户5.5亿。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/002七位CTO纵论技术领导者核心能力.md

@@ -0,0 +1,127 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            002 七位CTO纵论技术领导者核心能力
+                            关于技术领导者的具体职责和能力要求，每个企业会给出自己的定义。同样的职位，由于企业文化的区别，以及具体的业务和发展阶段不同，相应的要求也会有所不同。但总体来说，有一些核心的能力，是衡量一位技术领导者是否优秀的通用标准。
+
+通常来说，CTO这个岗位对技术领导者的能力要求是最全面的，基本上可以覆盖技术管理核心能力的各个方面。因此，我们邀请了七位现任或曾任CTO，请他们根据自己工作中的体会，总结CTO需要具备的核心能力。对比来看，非常有意思。
+
+AdMaster 联合创始人兼 CTO 、TGO鲲鹏会上海分会董事会成员洪倍：
+
+“CTO”“首席技术官”这三个英文单词或五个汉字，其实已经揭示了CTO所需要的核心能力。我自己总结起来是 5个”shi”字。
+
+第一个是”将士”的士，也就是要会带兵。“首席”和“官”这两个词天然赋予了你带兵用兵的责任。所以了解每一个团队成员的特征，关心每一个小伙伴的成长，打造一支能战斗的团队，是对CTO最重要的要求；
+
+第二个是”做事”的事，除了带人，CTO也需要身先士卒、迎难而上，CTO没有攻坚平事的能力，愧对”技术”这个词；
+
+第三个是”视角”的视，CTO也要有行业洞察、市场思维、成本视角，只有多视角的观察自己所研发的产品、服务的用户、所处的市场环境，才能找到更匹配的技术解决方案，为员工、企业乃至社会创造价值；
+
+第四个是”试错”的试，CTO要勇于试错，当然有错了也要勇于承担，勤于总结，CTO不敢试错，那团队成员就更不敢试错了。创新和成功是来自于无数次的试错；
+
+第五个是”顺势”的势，CTO如果不能预判技术发展趋势，团队一定会面临无头苍蝇或者得过且过的窘境。同时 CTO也需要学会顺势而为，借助各方的资源和力量才能更好地带团队、攻难关、聪明地试错；
+
+CTO 就是这样一个需要会带人、能攻坚、有视野、愿试错、懂得顺势而为的岗位。
+
+杭州福强科技有限公司创始人王福强：
+
+CTO的能力要求很多，但我觉得有几个能力属于核心能力：
+
+第一个是运营能力， 当然，因为CTO主要是focus在技术前缀下，所以，他负责的是技术组织的运营， 这包括日常，组织结构以及技术文化和营销等一系列软硬结合的运营方式；
+
+第二个是转承的能力， CTO和产品技术部门的核心职责是支撑CEO和公司业务，所以，要能够很好地理解CEO和Peer部门的意图和规划，进而推动落地；
+
+第三个就是吸星的能力， 爱才如命，什么时候CTO对人的重视略高于对技术的重视的时候，CTO的格局就更上一层楼了。
+
+这是我的几点粗浅认识，仅供参考。
+
+有赞 CTO 崔玉松：
+
+CTO首先是一个O，O本身代表着一个管理职位，其次还有Owner这层意思，他要很了解这家公司的业务，包括人才战略、市场战略、用户战略、增长战略等，甚至必须参与这些战略的制订。
+
+技术说到底是为业务服务的，除非技术就是业务本身。在很多公司里技术真的就成了实现其他部门需求的工具，我觉得这样做CTO肯定是不合格的。首先它不能影响战略，需求提出方会经过很多转化，如果不是基于战略去推导，整个过程会失真。
+
+第二个，我认为最最重要的是业务架构的能力，可能管理能力还次之。对于管理能力我认为最重要的是对团队的感知能力，因为一旦到了CTO这个级别，他已经脱离一线，很难再把一些细节还原。如果没有很细腻的感知能力，很多的决策会有偏差。
+
+如果他不是一个业务架构师，不是一个能给团队指明更好方向的人，他最终会沦为一个需求翻译器，产品经理说怎么做就怎么做。他更多的只是负责保证产品的质量、开发的速度，最终被肢解成一个很琐碎的人。一旦团队上了一定的规模，团队就会从单纯的需求实现走向团队运营，而运营是需要方向的，业务架构就是一个基于运营和数据的一种综合的能力。
+
+总结一下，我觉得最重要的就是参与战略制订、战略实施和战略分解的能力。其次，就是业务架构的能力和对团队感知的能力，微观事物感知的能力。
+
+丁香园 CTO 范凯：
+
+我觉得CTO需要具备如下5方面的素质：
+
+一、技术视野良好，架构设计能力出色
+
+CTO要有良好的技术视野，不需要各种技术都样样精通，但是必须要所有涉猎，有所了解，对各种技术领域的发展趋势，主流非主流技术的应用场景要非常了解。知道在什么场景应用什么技术，公司业务发展到什么规模应该预先做哪些技术储备。产品架构的设计要有足够的弹性，既能够保证当前开发的高效率，又能够对未来产品架构的演进留出扩展的余地。
+
+二、动手能力要强，学习能力出色
+
+CTO并不需要自己亲自动手写代码，但是如有必要，自己可以随时动手参与第一线的编码工作，CTO不能长期远离一线工作，自废武功，纸上谈兵。否则长此以往，会对技术的判断产生严重的失误。另外，CTO也应该是一个学习能力非常出色的人，毕竟IT行业的技术更新换代速度非常快，如果没有快速学习能力，是没有资格做好CTO的。
+
+三、管理研发团队过硬，能建立团队研发文化
+
+CTO的责任是负责整个公司的产品实现，所以CTO要善于管理研发团队，掌控好研发工作进度，能够在规划好的时间内，步步为营，好整以暇地完成公司产品的研发工作。
+
+此外CTO还要擅长培养研发梯队力量，建立研发团队内部具有向心力的，开放性的，交流学习型组织文化。让研发团队具备自我学习能力，自我培养能力，自我建设能力。这样的研发团队工作极度默契，战斗力极强，而且员工归属感很强，流失率很低。
+
+四、具备良好的产品意识，以及跨部门跨背景的沟通能力
+
+CTO不仅要懂技术，还要对互联网产品有良好的感觉，从产品的逻辑性，可实现角度提出产品改进和完善的总体性设想。因为产品经理或者业务人员设想的产品，很可能是逻辑上不严密，存在实现矛盾的。
+
+此外CTO还需要极强的沟通能力，要能够和不同背景的人有良好的沟通能力，能够用对方的思维方式和话语体系来描述他不理解的专业问题。
+
+五、敢于对CEO说“不”
+
+只要不是技术出身的CEO，必然对研发是门外汉，很可能对产品也是门外汉。因此，CEO不是每个想法都靠谱的，CTO有责任站在更加专业的角度去帮助CEO纠正，推演，完善想法。一个不敢对CEO说不的CTO，这个公司肯定要走很长很长的弯路的。
+
+易宝支付 CTO 陈斌：
+
+在我看来，CTO可以不写代码，但是这意味着你有更重要的事情要做，比如需要具备技术战略、体系建设、人才培养、企业文化、商业眼光、领导艺术等方面的素质。
+
+首先，CTO是技术战略的主导者。在CTO的这些素质中，最基本是要有技术战略。比如：编程语言选Java还是其他的语言，有新技术出现的时候，及时地安排团队的人去学，以备不时之需。当然CTO自己也要不断学习新的技术，不断更新自己的知识储备。
+
+其次，企业文化是非常有力的管理工具。企业文化很重要，但在实践当中经常会被忽略。CTO也要管企业文化，不但要引导企业文化，而且要身体力行。其实企业文化是一个能够帮你把整个企业的研发人员、氛围、管理过程组织起来的有效手段。
+
+最后，要打造良好的技术团队氛围。研发人员需要一位能指导他们、了解他们的大哥，我在易宝经常会跟兄弟们抽抽烟，聊一聊，有的时候也会写写代码，原因在于可以通过写代码去了解大家在想些什么。你作为技术领导者，必须进到那个氛围，了解一线员工在做什么。然后作为他们的代言人，代表技术团队跟公司管理层争取一些利益和福利，大家才会觉得这是我们的带路人。
+
+携程首席科学家叶亚明：
+
+在我看来，合格的CTO有六大要素：
+
+要素1：技术问题的解决能力
+技术领导者会面临很多技术问题，尤其业务发展了以后，过去的一些技术瓶颈，都会变成问题。在这种情况下，要具备快速解决问题的能力；另外，你要指明方向，带领团队共同前进。
+
+要素2：具备强烈“还债”意识
+几乎所有的互联网公司都会遇到技术债，当业务发展到某个阶段时，一定会爆发。有技术债怎么办？除了能够“发现”债的存在，还要适时“还债”，作为技术领导要有这种前瞻性。
+
+要素3：构建与CEO的良好伙伴关系
+首先，要从业务负责人或CEO的角度去思考他提的需求是什么。其次，要会平衡产品需求，判断产品需求的优先级。第三，要提高交付满意度。第四，要有业务洞察力，要对业务有强烈的兴趣，如果你对业务非常有感觉，那么你跟CEO的交流就会上升一个层次。
+
+要素4：清晰的自我认识
+你要意识到自己处于什么位置？周围的人跟你的平衡点在哪里？自己的优势和短板在哪里？对自我有一个清晰的认识非常重要。认识自我还不够，还要认识团队。团队整体技术水平是什么样？团队的短板在哪里？有这样的意识，你就知道在哪个方面应该补强。
+
+要素5：团队人才建设
+实践起来主要有四点：第一，招募培养接班人；第二，CTO自身的影响力；第三，自己的人格要经得起别人的挑剔，做到客观公正；第四，能创造优秀的团队文化。
+
+要素6：给工作注入新的东西
+作为一个技术领导者，如果你经常为整个业务或者团队带来新的东西或思路，与公司授予你的权力相结合，那么推进起来会非常快。虽然自下而上的创新也可以成功，但是根据经验和中国互联网过去的发展，从上到下去推动改变会更快一些。
+
+磁云科技创始人及CEO、 京东终身荣誉技术顾问李大学：
+
+一个好的CTO是能够把商业和技术结合起来，或者说具有商业敏感性的CTO。我认为有三点：
+
+第一，CTO应该具备商业洞察能力。我比较喜欢看一些商业书籍，来锻炼自己的商业分析能力、判断力、决策力，因为只有把技术和商业去结合的时候，它的价值才能呈现出来。
+
+第二是战略思维。很多CTO都是从技术人员做起来的，技术人员往往会想一个问题怎么做，他解决的是how的问题，但是在研究战略问题的时候，我们更多研究的是What和who的问题，或者说，我们更多的是看趋势、看未来，如果看得远，就可以反过来思考，现在做得是否对。我们有时候太关注技术本身，没有站在战略角度考虑问题。
+
+第三是个人的影响力。这种影响力包括影响同事，影响下属，甚至影响CEO，当你有一定影响力后你会发现，你能团结凝聚更多的人，那你做事情就比较容易。对于CTO来说，领导力的核心就是影响力。
+
+结语
+
+以上就是七位现任或曾任CTO总结的“CTO的核心能力”，我们会发现，其中有很多相通之处，也有一些独特的观点。或许可以这样理解：是否具备CTO们都非常看重的能力，决定了你是否能够成为一个技术领导者；而是否具备部分CTO非常看重的能力，决定了你将成为一个什么风格的技术领导者。你的看法呢？
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/003CEO实话实说：我需要这样的CTO.md

@@ -0,0 +1,61 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            003 CEO实话实说：我需要这样的CTO
+                            昨天我们分享了几位CTO对于高级技术管理者需要具备的核心能力的分析，今天我们换个角度，看看公司真正的老大——CEO关于这个问题的想法，和CTO们是否存在差异。我们邀请了四位CEO现身说法，阐述他们需要一个什么样的CTO。这四家公司都拥有为人称道的技术水平，相信他们的看法会对你有所启发。
+
+七牛CEO许式伟：
+
+一个CTO应该具备什么样的能力？或者说CTO应该承担什么职能？我想不同业务类型的公司、不同阶段的公司都不太一样。这里我说说七牛云对CTO定位的理解。
+
+七牛早期只有单一的云存储业务的阶段，CEO最大的职责是产品经理职能，理解和识别用户的核心诉求，并将其转化为产品的能力去满足它，而CTO的职责就是确保业务正常落地，用户的需求可以被按时按质地满足。从前瞻性的角度来说，CTO同样应该深刻理解客户，以确保产品不止适应当前用户的需求，还要能够适应需求未来的演化。适应需求未来的变化，不仅仅是能够预测未来什么事情会发生，更重要的是预测未来什么不会发生。我一直比较强调需求的预见能力，是因为很多技术人员不太能够理解这件事情对其能力提升的重要性。而实际上只有做到这一点，才能从根本上解决研发资源的浪费（把精力放在不该放的地方）和重复投入（同一个组件反复投入反复没有做好）的问题。
+
+2014年是七牛业务多元化的开始，到今天我们发展出了以存储为核心、覆盖从连接到智能的多元化场景的数据管理平台。今天我们的业务覆盖了存储、网络加速、多媒体处理、机器视觉、AI/大数据、容器等多个领域，这对组织结构提出了新的挑战。今天七牛反而相对弱化了CTO这样一个单一岗位的职能，更多会倾向于在每个子业务设立一个首席架构师角色，而这些首席架构师会有一个架构师团队，各自负责该业务的系统架构和技术方案决策工作。在这样一个新的组织架构下，CTO的位置在哪里？我的看法是，CTO是这些首席架构师中的一员，一方面他也会具体负责某一个子业务落地的工作，另一方面，他牵头把公司所有架构师聚集起来，形成一个技术委员会这样的一个团体，这个团体会定期一起审视整个公司业务的健康状况，并推动全公司范围的基础设施迭代与改进。
+
+有赞CEO白鸦：
+
+CTO要具备的最基础的能力我认为有两点：第一，他站在技术的角度，可以提前规划这家公司的整体技术储备和技术基础能力的沉淀。这件事儿其他的O都不懂，甚至大家在讨论的时候，在定战略的时候，都不一定能够从这个角度去思考。
+
+但是，这个是CTO的专业，他的专业就是要做好今天在业绩上不能体现出来的知识储备，这是他一定要搞定的事情。
+
+第二，因为技术这件事儿对于业绩的体现不是最直接的，所以CTO需要具备一种能力，就是用人话把技术讲清楚，让其他同事以及合作伙伴们能够理解技术。
+
+总结起来，CTO本质上要做好技术储备和技术沉淀，然后用人话把技术讲明白。
+
+基于以上两点再对CTO提要求就变得非常简单：
+
+第一，他要有足够开阔的视野。要做好技术储备就必须具备一定的视野，具备视野他才知道储备。但是，视野也需要经验，没有经验何来视野？我认为，经验是视野的基础，但视野还需要更开阔的想象力。
+
+第二，因为这个时代技术迭代非常快，对技术的创新要求也特别快，所以CTO要具备很强的学习能力。这个很强的学习能力是指：他需要具备快速迭代自己的能力，他才能够有前瞻性的理解前端的技术，才能知道技术未来的方向。
+
+沪江CEO阿诺：
+
+不同企业由于所处发展阶段不一样，对于CTO的要求是不一样的。即使是同一个企业，在不同发展阶段对于CTO的要求也是不一样的。
+
+从0到1创业阶段，对于技术负责人的要求是要能快速解决问题，碰到任何问题可以撸起袖子自己上。在成熟期的企业，CTO作为公司的首席技术专家，需要具备战略的视野、优秀的管理能力和快速反应的能力，也就是三方面的核心能力：思维力、团队力、敏捷力。
+
+思维力首先是能够制定并推进技术战略。要能站在行业和公司的战略高度来看待技术发展，洞察和分享技术行业发展趋势、最佳实践，对公司的技术和核心竞争力有深刻的理解。提炼年度或更长期的关键技术战略目标，并确保相关者理解。推动创新方面，思维力主要体现为开放性，也就是以好奇和开放的态度面对问题。带动分享组织内外的最佳实践，倾听不同的观点。嘉奖创新表现，对创新想法和行动给予赞赏。
+
+团队力的基础是建立信任，能够聚焦企业文化和价值观的传承，建立学习型组织文化。展现正直、公平、诚实的可信赖品质，用行动兑现承诺，说到做到。最终目标是要建立成功的团队。引导团队设定清晰而吸引人的团队目标，激发团队斗志。为团队目标达成设置有效的分工、协作机制，降低内耗。定期盘点关键岗位上的人才供给及能力状况，培养人才，营造团队氛围。
+
+敏捷力体现在个人的敏锐学习力，能够随着发展不断更新迭代，对新趋势和新技术持续跟踪评估，会亲自尝试各种新技术。有强烈的提升自己的学习愿望，并为此付出切实的努力。敏捷力还体现在推动团队执行目标，追求卓越。以解决工作中的核心问题作为头等大事，持续而快速的推进，刻不容缓解决问题。当结果不理想时，果断承担责任，想办法扭转局面。
+
+乂学教育创始人栗浩洋：
+
+CTO的需求有三个方面，第一个方面要有非常过硬的背景和经历。对于一个创业公司来说，想要从初级突破十亿美金，比如我们乂学今年将超过十亿美金的估值，那么这个CTO过去的背景一定要是在远超十亿美金的公司里面工作过。比如说在BAT，或者是百亿美金的上市公司里工作过，这是第一。第二，他一定要有过上亿的用户的经验，然后有千万日活的技术的成熟经验，如果没有，只是负责一个小的部分，没有打过大仗，那这个人是不符合我们的要求的。
+
+第二，他要有进化能力。因为这个世界在不断地变化，产品在不断地变化，需求在不断地变化，技术也在不断的变化。如果他没有持续不断的进化和学习能力，那么其实他没有办法迎合企业不断往前发展的需求，就像我们现在，公司是一个AI为核心的公司，那么CTO就要在人工智能领域里边去进行深度的学习，要有深刻的了解。然后，我们这个产品还远远高于以前产品的复杂程度，因为自适应学习系统还牵扯到学生的认知学、心理学、教育学等等方面的知识，都要求CTO有自我进化的能力。
+
+第三是具备黑洞的能力，黑洞的特性。现在的CTO已经不仅仅只是一个技术的负责人了，在企业里面要衔接里里外外的各种板块。像我们乂学人工智能教育机构里面，他要衔接AI算法，要衔接教学研究的部分，要衔接我们的线上销售和marketing，他还要衔接商业拓展，还要衔接我们全国的所有合作学校。在这样的一个过程中，对他本身的沟通能力、协调能力和消化吸收能力要求特别高。
+
+他不能把自己定位成一个板块的负责人，首先他要从一个董事长的眼光，从一个宇宙的宏观的眼光去看整个公司和未来的发展。然后，他要把自己放的足够低，在这个过程中，他一定不能是高高在上的，一定是自己放下所有的身段去非常虚心地倾听，像从零开始的小学生一样去和各个部门沟通，然后通过技术将各个板块的需求衔接进来，来推动公司的整个从战略到细节的发展。
+
+结语
+
+以上就是四位CEO对CTO这一角色的真实需求，有没有让你更加理解老板对你的要求，以及更加明确自己需要加强的能力呢？欢迎留言与我们探讨。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/004技术领导者不等于技术管理者.md

@@ -0,0 +1,101 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            004 技术领导者不等于技术管理者
+                            在成为领导者的道路上，很多人会陷入一个误区，就是把“领导”等同于“管理”。事实上，“领导”比“管理”难度更大，因为管理很多时候是在解决重复问题，有章可循，而领导经常要面对新问题、新形势，而且没有现成的规章可以遵循。
+
+怎样成为好的技术领导者？著名软件专家、美国计算机名人堂代表人物杰拉尔德·温伯格在《成为技术领导者》（曾译名《技术领导之路》）一书中给出了一系列答案。
+
+2008年，还是一线程序员的余晟翻译了这本书，用他自己的话来说，“‘生吞活剥’了一整套关于领导力的学说，基本‘塑造’了我关于领导力的认知，深深影响了我作为技术领导的管理风格和价值取向。”
+
+余晟曾在传媒、电商行业工作，目前在互联网教育行业从事架构和研发管理的工作；业余翻译、审校过一些技术书籍，也撰写过专门讲解正则表达式的书籍；业余时间在个人公众号“余晟以为”（yurii-says）分享技术和管理话题，在技术圈小有影响力。最近，他与我们分享了关于技术领导力的最新思考，一起来听一听吧。
+
+好的领导者可以“赋能”其他人
+
+《成为技术领导者》这本书里，我能记起来的，现在还受用的主要有这么几点：
+
+领导对团队的作用。优秀的领导者加入团队之后，人还是那些人，资源还是那些资源，但是做事的效率和质量都提高了很多。换用流行的说法，好的领导者可以“赋能”其他人，做成这些人之前做不成的事情。
+
+勇于面对自己。如果一件事是“要做的”，但你迟迟没有做，那么坦白承认吧，你根本不想做。周围很多人总是立各种志、发各种誓，最后没行动，基本都是这样。想要改变，尤其是自我改变，是很难的，因为自我改变的任务通常不会像上级布置的任务那样，有明确的压力和期限，所以大多停留在“想”而已。真正要动起来，需要极大的勇气和毅力。
+
+认清真实的自己。我越来越发现，我们并不是自己以为的样子，很可能完全不同。有一次，有个资深的同事把来求助的女同事给吼哭了。我找他严肃谈才发现，他当时正在思考一个问题，只是不希望被打扰，完全没有意识到自己的声调有多么高，语言有多么严厉。这样的现象很多，领导者尤其要注意。
+
+“领导”和“管理”不应割裂
+
+既然技术管理不等于技术领导，那么技术管理者应该如何判断自己需要加管理能力还是领导力呢？
+
+我觉得这个问题没有不变的答案，好的技术管理者一定会根据具体的形势来调配“管理”和“领导”的分配，静态地、割裂地谈“领导”和“管理”都是不对的。
+
+正好前几天看到了一篇形象讲解管理和领导的文章：你可以“管理”机器、“管理”马戏团，但不能“领导”机器和马戏团。
+
+所以在我看来，如果你面对的团队还没有进入稳定的“轨道”（没有形成良好的习惯），甚至其中还有南郭先生和害群之马，那多半得加强管理。如果你面对的团队已经有良好的习惯，可以在目前的轨道上运行得很好了，那可能适合加强领导。
+
+作为反例，如果你的管理能力很强，但去了一个已经稳定运行，很需要领导力的团队，没准只会添乱。
+
+领导力可以换算为管理力
+
+一个管理能力不是很强的人，有可能成为好的领导者吗？基于我上面说的这点，我觉得是可以的。
+
+我见过不少精英型团队，自驱力和凝聚力都很强，它们其实不需要太多的管理手段。坦白说，管理在不少时候都是脏活累活——比如升职的安排、加薪的分配等等。
+
+当然，领导力有时候也可以“换算”为管理能力。假如公司开不起那么高工资，年终奖系数也不高，又需要保持团队稳定性。这确实是管理上的难题，需要管理者动很多脑筋。但是，也有不少人单纯是“愿意”跟着某些人而选择留下的。这就是领导力换算为管理力的例子。
+
+优秀技术领导者的必备特质
+
+我见过不少优秀的技术领导者，总的来说，他们都拥有如下特质。
+
+正直。大多数技术人员的价值观都比较朴素，天生不喜欢太复杂的算计和手腕，哪怕他们自己的利益并没有受损。如果发现领导者善于玩弄权术，多半不会佩服，而是觉得不舒服。
+
+体谅。遇到问题能够放下自我，善于从其他人的角度思考，理解其他人的难处，了解“白痴问题”的来龙去脉，找出合理的地方。技术很强大，但把技术当成自己的护身符，就会很可怕。
+
+谦虚。面子观念不能太强，要善于承认自己的不足，善于鼓励团队伙伴。领导者一定要清楚，衡量领导者业绩的落脚点是团队的产出，而不是个人的表现。
+
+眼光。不是所有人都习惯解决“一大坨问题”的，很多人更习惯解决明确的问题。所以领导者一定要有本事从“一大坨问题”中找到最关键的那一两个，投入资源，同时把其它问题“按住”。
+
+噢，还有宣传意识。约翰·洛克菲勒说过“除了做重要的事，也别忘了让其他人知道你在做最重要的事”。我见过太多这样的情况了：技术团队习惯默默无闻地付出，“耐心等待”上级有一个公正客观的判断，最后事与愿违。良好的宣传意识，对技术团队来说尤其重要。
+
+提升领导力的靠谱途径
+
+要提升技术领导力，我建议多看看技术领导力的书，比如《成为技术领导者》就不错（玩笑）。当然《最后期限》《凤凰项目》《告别失控》也是很好的书，甚至更好，毕竟《成为技术领导者》有点老啦。
+
+但是也别光盯着“技术”领导力，其它行业也有不少领导力可以借鉴。我最近半年看了《中途岛奇迹》和《午夜将至》，尼米兹在二战太平洋战场的指挥，肯尼迪在古巴导弹危机中的决策，都给我不少启发。
+
+另外，遇到问题多思考，多和其他人讨论。我们每天都在解决各种问题，但未必是以最优的方式解决的，甚至很多都是“凑合”对付过去了。“凑合”可以用来应付工作，但和成长绝缘。要成长，还是得像棋手要反复推演一样，多复盘自己的决策，持续讨论反思下去会有不少提升 。
+
+最后，持续关注《技术领导力300讲》专栏呗。
+
+以上就是余晟和我们分享的内容。最后，我们一起来回顾一下他在此前的一些文章里，关于技术领导力的几段精彩论述：
+
+1、通常的激励似乎是从行为主义心理学的角度出发的，认为简单机械的“奖励/惩罚”就可以对员工起到引导和归束的作用。但这种理论其实是行不通的。
+
+赫兹博格的“激励-保健因子”理论指出，员工在不同的阶段所看重的方面是不同的，简单说员工刚开始更看重的是个人生活、工作环境、薪金福利等“基本因子”，满足之后则寻求学习与发展、工作乐趣、成就与肯定等“激励因子”，而简单的“奖励/惩罚”在这些方面并不能奏效。
+
+更重要的是，因为技术工作的核心之一便是创新，简单的“奖励/惩罚”并不能催生创新。按照我的经验，激励的作用更多是树立正确的价值观。这种价值观既符合公司的利益，又兼顾个人的成长，而且还要能落实到真实的工作中来。
+
+在日常工作中，技术领导应当持续表扬和鼓励能提供高质量程序的行为（哪怕他日常不怎么说话），而不是提交质量一般但努力除错的行为。有这种持续的激励，才有可能塑造正确的价值观，给有潜力但还在摇摆、困惑的成员发出清晰的信号，从而打造高质量、迅速成长的团队。
+
+2、领导力的表现是创造让所有人都能成长，都能发挥更大价值的环境，当然不能把所有人当成可以互相替换的棋子。按照温伯格的意见，好的组织应当是“全面的（Organic，也可以翻译为“有机的”）”，也就是可以互相取长补短，形成一股合力。
+
+组织的全面，还体现在一个方面，即它是自组织的，各级的情况和任务可以在对应的级别自动自发地完成。或者用温伯格的话说：“在全面的组织中每个人都能解决问题，做出决策，执行这些决策。而领导不需要对各种问题亲自出面，亲自做决策，亲自执行”。
+
+要想打造全面的组织，有凝聚力的团队，温伯格列出了几种需要警惕的行为，包括“只抓大目标”、把人当成机器来看待、事必躬亲、奖励低效的组织等等。虽然我们日常工作中无法做到彻底戒除，但只有尽力避免这样的行为，才能真正营造全面的组织，形成有凝聚力的团队。
+
+3、许多技术领导者本身对技术非常有兴趣，所以他们自己在创新方面是没有问题的。但是身为领导，仅仅自己创新是不够的。既然相信人不是机器，既然相信软件开发是需要创造力的工作，那么就应当鼓励每个人的创新，为团队营造勇于创新的气氛。
+
+好的技术领导从来不应该因循守旧。按照温伯格的说法，即便你用某种方式成功过，也不意味着没有更好的办法来解决同样的问题。所以，身为技术领导，应当鼓励所有人的创新，对于不够完善的创新建议，不能简单拒绝，需要代之以鼓励和引导。
+
+甚至在某个问题上，即便自己有过成功经验，心里已经确定了方案，也需要虚心听取其他人的不同建议，更要勇于采纳更好的方案。
+
+要知道，这样做并不意味着贬低自己的技术威信，反而确立了积极创新，并且能采纳合理创新建议的工作方式。只有一个人能创新的团队，永远不会强过一支人人都能创新的团队。
+
+最后，用余晟的一段话与大家共勉：
+
+技术领导确实不好做。但是，考虑到技术已经在我们的生活中扮演了那么重要的因素，考虑到技术人员大多是那么的单纯可爱，对技术领导者们来说，提高自己的技术领导力，既是义不容辞的责任，也是让人迷恋的诱惑。
+
+正如上文所说，“领导”其实不同于“管理”，身为技术领导者，一定要把握好“管理”的份量，留出更多的精力给“领导”，才能更好的激发技术人的激情与创造力！
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/005CTO的三重境界.md

@@ -0,0 +1,101 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            005 CTO的三重境界
+                            在成为领导者的道路上，很多人会陷入一个误区，就是把“领导”等同于“管理”。事实上，“领导”比“管理”难度更大，因为管理很多时候是在解决重复问题，有章可循，而领导经常要面对新问题、新形势，而且没有现成的规章可以遵循。
+
+怎样成为好的技术领导者？著名软件专家、美国计算机名人堂代表人物杰拉尔德·温伯格在《成为技术领导者》（曾译名《技术领导之路》）一书中给出了一系列答案。
+
+2008年，还是一线程序员的余晟翻译了这本书，用他自己的话来说，“‘生吞活剥’了一整套关于领导力的学说，基本‘塑造’了我关于领导力的认知，深深影响了我作为技术领导的管理风格和价值取向。”
+
+余晟曾在传媒、电商行业工作，目前在互联网教育行业从事架构和研发管理的工作；业余翻译、审校过一些技术书籍，也撰写过专门讲解正则表达式的书籍；业余时间在个人公众号“余晟以为”（yurii-says）分享技术和管理话题，在技术圈小有影响力。最近，他与我们分享了关于技术领导力的最新思考，一起来听一听吧。
+
+好的领导者可以“赋能”其他人
+
+《成为技术领导者》这本书里，我能记起来的，现在还受用的主要有这么几点：
+
+领导对团队的作用。优秀的领导者加入团队之后，人还是那些人，资源还是那些资源，但是做事的效率和质量都提高了很多。换用流行的说法，好的领导者可以“赋能”其他人，做成这些人之前做不成的事情。
+
+勇于面对自己。如果一件事是“要做的”，但你迟迟没有做，那么坦白承认吧，你根本不想做。周围很多人总是立各种志、发各种誓，最后没行动，基本都是这样。想要改变，尤其是自我改变，是很难的，因为自我改变的任务通常不会像上级布置的任务那样，有明确的压力和期限，所以大多停留在“想”而已。真正要动起来，需要极大的勇气和毅力。
+
+认清真实的自己。我越来越发现，我们并不是自己以为的样子，很可能完全不同。有一次，有个资深的同事把来求助的女同事给吼哭了。我找他严肃谈才发现，他当时正在思考一个问题，只是不希望被打扰，完全没有意识到自己的声调有多么高，语言有多么严厉。这样的现象很多，领导者尤其要注意。
+
+“领导”和“管理”不应割裂
+
+既然技术管理不等于技术领导，那么技术管理者应该如何判断自己需要加管理能力还是领导力呢？
+
+我觉得这个问题没有不变的答案，好的技术管理者一定会根据具体的形势来调配“管理”和“领导”的分配，静态地、割裂地谈“领导”和“管理”都是不对的。
+
+正好前几天看到了一篇形象讲解管理和领导的文章：你可以“管理”机器、“管理”马戏团，但不能“领导”机器和马戏团。
+
+所以在我看来，如果你面对的团队还没有进入稳定的“轨道”（没有形成良好的习惯），甚至其中还有南郭先生和害群之马，那多半得加强管理。如果你面对的团队已经有良好的习惯，可以在目前的轨道上运行得很好了，那可能适合加强领导。
+
+作为反例，如果你的管理能力很强，但去了一个已经稳定运行，很需要领导力的团队，没准只会添乱。
+
+领导力可以换算为管理力
+
+一个管理能力不是很强的人，有可能成为好的领导者吗？基于我上面说的这点，我觉得是可以的。
+
+我见过不少精英型团队，自驱力和凝聚力都很强，它们其实不需要太多的管理手段。坦白说，管理在不少时候都是脏活累活——比如升职的安排、加薪的分配等等。
+
+当然，领导力有时候也可以“换算”为管理能力。假如公司开不起那么高工资，年终奖系数也不高，又需要保持团队稳定性。这确实是管理上的难题，需要管理者动很多脑筋。但是，也有不少人单纯是“愿意”跟着某些人而选择留下的。这就是领导力换算为管理力的例子。
+
+优秀技术领导者的必备特质
+
+我见过不少优秀的技术领导者，总的来说，他们都拥有如下特质。
+
+正直。大多数技术人员的价值观都比较朴素，天生不喜欢太复杂的算计和手腕，哪怕他们自己的利益并没有受损。如果发现领导者善于玩弄权术，多半不会佩服，而是觉得不舒服。
+
+体谅。遇到问题能够放下自我，善于从其他人的角度思考，理解其他人的难处，了解“白痴问题”的来龙去脉，找出合理的地方。技术很强大，但把技术当成自己的护身符，就会很可怕。
+
+谦虚。面子观念不能太强，要善于承认自己的不足，善于鼓励团队伙伴。领导者一定要清楚，衡量领导者业绩的落脚点是团队的产出，而不是个人的表现。
+
+眼光。不是所有人都习惯解决“一大坨问题”的，很多人更习惯解决明确的问题。所以领导者一定要有本事从“一大坨问题”中找到最关键的那一两个，投入资源，同时把其它问题“按住”。
+
+噢，还有宣传意识。约翰·洛克菲勒说过“除了做重要的事，也别忘了让其他人知道你在做最重要的事”。我见过太多这样的情况了：技术团队习惯默默无闻地付出，“耐心等待”上级有一个公正客观的判断，最后事与愿违。良好的宣传意识，对技术团队来说尤其重要。
+
+提升领导力的靠谱途径
+
+要提升技术领导力，我建议多看看技术领导力的书，比如《成为技术领导者》就不错（玩笑）。当然《最后期限》《凤凰项目》《告别失控》也是很好的书，甚至更好，毕竟《成为技术领导者》有点老啦。
+
+但是也别光盯着“技术”领导力，其它行业也有不少领导力可以借鉴。我最近半年看了《中途岛奇迹》和《午夜将至》，尼米兹在二战太平洋战场的指挥，肯尼迪在古巴导弹危机中的决策，都给我不少启发。
+
+另外，遇到问题多思考，多和其他人讨论。我们每天都在解决各种问题，但未必是以最优的方式解决的，甚至很多都是“凑合”对付过去了。“凑合”可以用来应付工作，但和成长绝缘。要成长，还是得像棋手要反复推演一样，多复盘自己的决策，持续讨论反思下去会有不少提升 。
+
+最后，持续关注《技术领导力300讲》专栏呗。
+
+以上就是余晟和我们分享的内容。最后，我们一起来回顾一下他在此前的一些文章里，关于技术领导力的几段精彩论述：
+
+1、通常的激励似乎是从行为主义心理学的角度出发的，认为简单机械的“奖励/惩罚”就可以对员工起到引导和归束的作用。但这种理论其实是行不通的。
+
+赫兹博格的“激励-保健因子”理论指出，员工在不同的阶段所看重的方面是不同的，简单说员工刚开始更看重的是个人生活、工作环境、薪金福利等“基本因子”，满足之后则寻求学习与发展、工作乐趣、成就与肯定等“激励因子”，而简单的“奖励/惩罚”在这些方面并不能奏效。
+
+更重要的是，因为技术工作的核心之一便是创新，简单的“奖励/惩罚”并不能催生创新。按照我的经验，激励的作用更多是树立正确的价值观。这种价值观既符合公司的利益，又兼顾个人的成长，而且还要能落实到真实的工作中来。
+
+在日常工作中，技术领导应当持续表扬和鼓励能提供高质量程序的行为（哪怕他日常不怎么说话），而不是提交质量一般但努力除错的行为。有这种持续的激励，才有可能塑造正确的价值观，给有潜力但还在摇摆、困惑的成员发出清晰的信号，从而打造高质量、迅速成长的团队。
+
+2、领导力的表现是创造让所有人都能成长，都能发挥更大价值的环境，当然不能把所有人当成可以互相替换的棋子。按照温伯格的意见，好的组织应当是“全面的（Organic，也可以翻译为“有机的”）”，也就是可以互相取长补短，形成一股合力。
+
+组织的全面，还体现在一个方面，即它是自组织的，各级的情况和任务可以在对应的级别自动自发地完成。或者用温伯格的话说：“在全面的组织中每个人都能解决问题，做出决策，执行这些决策。而领导不需要对各种问题亲自出面，亲自做决策，亲自执行”。
+
+要想打造全面的组织，有凝聚力的团队，温伯格列出了几种需要警惕的行为，包括“只抓大目标”、把人当成机器来看待、事必躬亲、奖励低效的组织等等。虽然我们日常工作中无法做到彻底戒除，但只有尽力避免这样的行为，才能真正营造全面的组织，形成有凝聚力的团队。
+
+3、许多技术领导者本身对技术非常有兴趣，所以他们自己在创新方面是没有问题的。但是身为领导，仅仅自己创新是不够的。既然相信人不是机器，既然相信软件开发是需要创造力的工作，那么就应当鼓励每个人的创新，为团队营造勇于创新的气氛。
+
+好的技术领导从来不应该因循守旧。按照温伯格的说法，即便你用某种方式成功过，也不意味着没有更好的办法来解决同样的问题。所以，身为技术领导，应当鼓励所有人的创新，对于不够完善的创新建议，不能简单拒绝，需要代之以鼓励和引导。
+
+甚至在某个问题上，即便自己有过成功经验，心里已经确定了方案，也需要虚心听取其他人的不同建议，更要勇于采纳更好的方案。
+
+要知道，这样做并不意味着贬低自己的技术威信，反而确立了积极创新，并且能采纳合理创新建议的工作方式。只有一个人能创新的团队，永远不会强过一支人人都能创新的团队。
+
+最后，用余晟的一段话与大家共勉：
+
+技术领导确实不好做。但是，考虑到技术已经在我们的生活中扮演了那么重要的因素，考虑到技术人员大多是那么的单纯可爱，对技术领导者们来说，提高自己的技术领导力，既是义不容辞的责任，也是让人迷恋的诱惑。
+
+正如上文所说，“领导”其实不同于“管理”，身为技术领导者，一定要把握好“管理”的份量，留出更多的精力给“领导”，才能更好的激发技术人的激情与创造力！
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/006像CEO一样思考.md

@@ -0,0 +1,113 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            006 像CEO一样思考
+                            2008年5月，我加盟京东。实话说，刚到京东的时候，京东技术面临非常多的问题，甚至根本跟不上业务的成长。所以我在京东做的第一件事情，就是准备了5个人的团队，郊区租了一个别墅，决定开始封闭开发，要把京东的网站进行改版。
+
+我们5人团队连续征战了三个月，把整个网站都重新改写了。正是因为这次改版，京东的用户体验上了一个台阶，成为电商用户体验的标杆。那次改版之后，京东的订单从几千单突破了几万单。
+
+在公司小的时候，很多事情CTO都必须亲力亲为。但是，当公司逐渐长大，比如2010年京东的技术团队超过了200人，开始做前后台拆分，公司的快速成长对我的能力提出了更高的要求。一年后，京东的前、后台都超过了600人，技术架构必须统一，我以前从来没带过这么大的团队，面临着很大的挑战。
+
+我意识到，作为一个技术专家，我可能是够格的，但是作为一个CTO，其实我没有准备好。这时我想起这句话，站在CEO的角度思考。
+
+经过一段波折，2012年底，我把京东整个研发体系重新管理起来。2012年到2015年5月期间，京东的技术又上了一个台阶。
+
+所以，我想要跟大家分享：CTO要像CEO一样思考。其实有时候做这个决定很难，因为，这意味着你要受委屈，你要放下，你要接受很多挑战，最重要的是，你要坚持。
+
+换位思考，CEO眼中的CTO是啥样？
+
+一个人最大的问题，是不能很好地认识自己。两个人互相审视，一定会发现一个盲点，即你身上的问题我知道，而你不自知。
+
+所以作为CTO，一定要360度审视自己：员工对你有什么样的要求，同事对你有什么样的要求，CEO对你有什么样的要求，特别是在他们眼中是怎么看待你的。如果你不把这个问题处理好，你就不是一个合格的CTO。
+
+那么，CTO怎么才能让别人能理解我们呢？我觉得要反过来换位思考：我们要去理解别人，如果我们很好地理解别人了，就能很好地让别人来理解我们。如果研究我们自己的话，我们是有盲点的，所以我们要把同事、员工、CEO甚至合作伙伴当做镜子，不断地反思。
+
+通常在CEO眼里，CTO是一个「成本中心」，总是要钱、要人、要资源，还经常出事，这是一个困境。
+
+一般来说，CTO最大的问题在于沟通。我们习惯用技术思维来沟通，在我们的世界里只有0和1，非黑即白。但是对CEO来讲，每天面临的都是不确定问题，不是靠推导逻辑可以推导出来的。
+
+尤其做战略选择的时候，只是判断一种可能性，他面临很大的压力，这种思维模式跟技术思维是不一样的。所以我们用技术思维方式去跟CEO、业务部门沟通，就会有很多问题。
+
+2015年4月，我从京东出来创办了磁云科技，需要解决的最大问题就是：怎么把互联网人才、技术人才和传统行业相结合、对接？
+
+所以我们技术人要知道，在CEO眼里，我们是什么样子，这样我们才可以去改变自己。
+
+CEO如何思考问题？
+
+CEO怎么思考问题呢？一般有五个维度：
+
+先说第一个，用户维度。
+
+一个公司其实就是做两件事：第一件事，把用户吸引过来；第二件事，让用户把钱掏出来，把用户留住，持续掏他腰包。
+
+所以CTO要研究：我们企业的用户是谁？用户从哪儿来？怎么把用户留住？怎么让用户掏腰包？怎么提升用户的转化率？这里面就有很多学问，如果在用户这个维度，能够给CEO提供一个用户的仪表盘，我们做技术就有了一个新的方向。
+
+第二个维度是行业的维度。
+
+我到京东以后，努力学习仓储、配送、供应链、零售等其他业务部门的知识。因为如果你不懂，你是无法跟业务部门沟通的，当然更没法同CEO沟通。
+
+所以，CTO必须要具备行业知识，不能只讲技术，不能只用技术语言，很多时候你要结合商业和技术。你必须要懂行业，了解行业的本质。
+
+第三个维度是竞争。
+
+CTO要对他所在的行业了如指掌，特别是这个行业里有多少企业，处在什么样的地位。要对整个产业画一个地图，把我们企业和企业未来要演变的路径标在上面，这样才能够按照整个行业趋势去做，才能奠定自己的优势。
+
+我们在京东的大多数时间都在研究对手，研究对手正在干什么，怎么去追求卓越，怎么超越他们。
+
+第四个维度是生态。
+
+也就是要关注我们的合作伙伴，特别是那些上门推销卖硬件、软件的，我们要给予足够的重视。要很好地处理这些合作伙伴的关系，CTO的圈子不仅仅要有技术圈，还要有行业的圈子，扩大自己的圈子，找到可以帮你的人。
+
+第五个维度是要面向未来去思考。
+
+通常，做技术的为了解决眼前的问题常常疲于奔命。其实，如果CTO能看到公司未来三年、五年的前景，可能会更得心应手。CEO的思维一定是面向未来的。所以怎么把技术的战略跟公司的业务战略结合起来，这也是CTO要研究的课题。
+
+沟通的时候，用数据说话
+
+在京东，我学到很好的一招：和CEO沟通的时候，尽量用数据说话。包括立项，要说清楚这个项目能给公司带来什么，不是带来技术的先进性，而是跟收入、利润或者用户体验挂钩。如果你这么去做，更能够得到业务部门的支持，也更能够得到CEO的支持。
+
+用数据说话也意味着，每个技术团队的成长可能都有三个阶段。
+
+第一个阶段，技术跟随业务。业务跑得很快，技术跟在后面，业务部门可能不满意，但是要通过技术能力的提升去满足业务的要求。
+
+第二个阶段，技术同业务肩并肩。这个阶段需要用数据说话。在京东我们成立了一个大数据部门，对每个业务部门制定3~5个指标，每个核心指标包括100~300个小指标。每个月都会做月度经营会，各个部门PK这些指标，通过指标的PK，各个部门业务就可以提升。
+
+也就是说，企业发展一定有一个业务验证到规模化的阶段，而规模化的时候就需要精细化，精细化的时候就需要数据说话。
+
+我在京东的时候，曾给强东总做了一个仪表盘，打开手机对公司的经营情况一目了然，非常清楚哪个库房出问题了，哪里打包拥堵了，我们会用三种颜色来标记业务的状态：黄色警告，绿色正常，红色报警。
+
+尽管2014年京东要上市，2013年强东总到哥伦比亚大学学习去了，但是不要紧，虽然有这么远的距离，他通过这个仪表盘，对公司的运营了如指掌。
+
+第三个阶段，通过技术来引领整个公司的发展。在京东一路走来，我认为技术部门一定要换一个思路：要跟业务部门做伙伴，要帮助业务部门成功。公司一般是业务部门立项，立项一定会带上研发部门。如果我们有这样一个心态，去帮助别人成功，顺带成就我们自己，在内部就能获得很多支持。
+
+所以在京东研发部发展的过程中，组织结构一直在变化。以前京东是一个职能化的结构，包括产品部、研发部、测试部、运维部，后来分了很多研发部。比如，采销部门有研发部，物流部门有研发部，财务部门也有研发部。
+
+其实，当研发人员达到几千人的时候、是最需要做业务研发闭环的。研发人员同业务在一起，业务、研发、运维、运营都在一起，这样响应的速度是最快的；业务的目标就是研发的目标，这样会更有成效。
+
+所以公司的组织结构也是CEO、CTO们要考虑的一个问题，如何调整以适应公司的发展。甚至每一项技术的引进、每一个项目的设立，都要回到数据上去。看看对公司带来怎样的贡献，和哪个部门有利益关系，和哪个部门去合作。
+
+当家才知柴米油盐贵
+
+最后说说我自己成为一名CEO之后的一些感悟。
+
+说实话，变化还是挺大的，比如做CTO的时候，当一门新的技术出来的时候，就会深入下去，可以亲自动手，现在就比较难做到了。我能做到的是搭一个平台，让这些牛人团结起来，在那个技术方向上能够深入下去，并且我让他们随时把进展的情况给我分享，我就能够跟上这个技术发展的步伐。
+
+当你从CTO到CEO位置的时候，你需要有勇气来承认技术上不如CTO了，但是要保持对技术的好奇心，要跟踪技术的趋势，同时要尽量花多一点时间跟他们在一起。
+
+另一个方面，技术现在进步非常快，但是技术怎么转化成生产力？怎么去商业变现？这是我考虑更多的问题，怎么从新技术，或者新趋势里面找到商业机会，这方面我往往很敏感。我当CTO的时候，我感觉有个框框把我框住了，那可能是企业战略或者CEO要求你要这么干，我做CEO的时候，我发现没有了框框，有一种天高任鸟飞，海阔凭鱼越的感觉，这种感觉能够让我抓住更多的机会。
+
+在磁云科技助力产业转型升级的过程中，我发现真正制约企业发展的瓶颈是资金和效率，磁云科技因此逐渐明确了科技赋能产业升级的思路，成为一家以区块链为核心的科技金融公司。
+
+2016年，磁云率先布局区块链的场景应用；2018年，磁云聚焦区块链＋供应链金融，发布了磁云唐票产品，基于自有区块链核心技术，将行业上下游的账期资产实现了数字化和信用化，从而实现了数字资产的切分、流转和融通。
+
+你当了家之后，你才知道柴米油盐贵，当你成了CEO，公司的生存发展就是头等大事。而且CEO承担的压力是很大的，很多人都在关注你，我当CEO之后，抗压能力更高了，对自己的要求也更高了。
+
+作者简介
+
+李大学，磁云科技董事长兼CEO、京东集团终身荣誉技术顾问。中国互联网+实战团发起人，正和岛互联网+部落酋长。曾担任天极网CTO、京东集团高级副总裁，主管技术研发体系。在京东期间，带领京东研发团队从不到30人发展到近5000人，通过技术驱动，实现了京东业务一万倍的成长。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/007要制定技术战略，先看清局面.md

@@ -0,0 +1,73 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            007 要制定技术战略，先看清局面
+                            随着企业创新节奏加快，CTO作为核心高管之一，在管理战略上起到越来越重要的作用，一方面要理解公司战略，另一方面要给出正确的技术战略和节奏反馈管理层，让所有管理层对技术有一个正确的预期和把控。
+
+什么是技术战略？用通俗的话来讲，就是在现阶段用合适的人、合适的技术架构办合适的事情。
+
+首先要看清“现阶段”
+
+不是每个公司从一开始就是和BAT一个阶段的，每个公司实际业务形态也不同，所以技术战略、架构选型、人员招聘等直接选择与BAT对标往往会把公司坑得很惨，所以认清楚现阶段很重要。简单说来，要认清以下两点：
+
+公司团队现状：公司现状包括管理团队和执行团队的价值观、认知、潜力、水平等。对于高级技术管理者来说，其他高管对于技术的价值观和认知很重要。这涉及到你对于技术的投入、人员变更一系列的决策是否可以得到其他合伙人发自内心的支持，只有这样你才可以让技术形成有效闭环，技术和业务才可以螺旋式上升。所以，技术高级管理者要花非常多的时间，结合实际业务反复给其他合伙人沟通你的观点和认知，并把事情“做成”，赢得其他合伙人的信任。
+
+认清现状，同样适用于执行团队，没有一个执行团队天然就是全能的，在这个业务快速变化的时代，每个技术团队都需要在不断迭代中适应公司和市场的变化。当前团队的长处和短板是什么，当前情况下业务情况下，对于技术团队是需要招聘、优化、还是培养。这都是一个高级技术管理者需要了解和决策的。
+
+业务增长节奏：了解当前业务的节奏、财务的预期是什么。这是高级技术管理者后面选择人、架构和事情重要的参考，在控制技术节奏的时候非常重要。无论是牛人，还是最棒的架构，都是为了业务预期服务的。
+
+如果公司节奏是在快速上升通道，那么需要孤注一掷的砸资源、请牛人、扩大技术团队以支撑几何级数上涨的业务；如果公司业务处于探索阶段，那么适当控制团队规模、用实用而稳定的技术，控制管理团队预期就很重要。
+
+如果节奏没有了解清楚，技术节奏把控不好，很可能会导致技术无法支持现有的业务增长，或者业务收入无法供给辛辛苦苦招聘来的技术牛人，看着一起成长起来的兄弟却要忍痛优化掉，这是每一个技术管理者都不愿意见到的。所以，深度了解公司业务、洞察业务增长节奏，是每一个高级技术管理者必修课。
+
+技术架构升级就是对人的升级
+
+了解了当前公司的节奏和现状后，就可以对现在的执行团队和架构做一次评估，然后决定做什么样的事情。人、架构要做的事情是一体的，技术架构升级其实也就是对人的升级（可以参看我发表在TGO鲲鹏会微信公众号的文章《技术框架升级其实是整个公司的升级》），不同情况下执行团队和架构也是不同的。
+
+公司初期，业务验证阶段：技术品牌与技术资源都不足，为了尝试业务，需要快速实现MVP并开始迭代。在这个期间，人才招聘和快速达成MVP是最重要的，MVP用的技术架构可以是丑陋的，因为这个时候业务闭环比技术优美更重要，“快”才是第一位的。
+
+同时，招聘也是最重要的，是否可以组建一个有相同价值观的初创团队，经受住压力快速推出MVP是这个阶段的“生死门”。此时人才招聘宁缺毋滥，一个不够优秀的人才你还要花很多精神去管理他，而在初期你同时要做很多事情，已经焦头烂额，不寻找到能自我驱动的人才，其实是给你自己挖坑。
+
+而人才的价值观和技能最重要，此时没有时间去培养，一个人的力量永远是有限的，要一帮能同仇敌忾的兄弟才能成事。当然此时大多数公司人力招聘还跟不上，所以往往要技术合伙人自己去寻找人才。在后面关于人员管理的文章中，我会详细讲到如何能找到第一批技术骨干。
+
+公司高速突进阶段：此时，公司业务模式已经定下来，需要高速发展。人才的抢夺、高可用高可扩充的架构是需要重视的。此时，公司每天业务可能翻几倍的成长，初期留下的技术债急需修正。所以，招聘人才时，一方面需要看人才对价值观的认同、潜力和能力，另一方面需要高出市场平均价格来吸引人才迅速加盟，确保公司业务顺利进行。卓越的人才团队建立是这个时期最重要的，如果人才不到位、高可用高并发的架构必然无法满足，业务出现各种问题就会让整个技术团队进入被动。经常看到一些初期的技术合伙人和技术团队在这个阶段因为无法跟上公司发展的步伐而被优化或者替换。
+
+其实，同作为技术管理者我很理解这些处理，只要公司处理的公正和公平就无可厚非，不能因为技术团队的一个人或者几个人阻碍公司的发展。有的人擅长从0到1，有的人擅长从1到N，作为高级技术管理者，要了解自己的认知边界，要么不停挑战自己不停进化，要么急流勇退，为整个公司提供更好的上升空间。所以，这里的人才抢夺不仅仅是执行团队，也包括管理团队自己。跟上公司高速发展的步伐，是这个阶段整个技术团队最大的挑战。
+
+公司平稳发展阶段：公司在市场的大格局已定，此时技术体系搭建和文化的建立是最重要的。经过高速的发展，各种能人已经召集大半。一方面随着业务进入常态，技术开始进入平缓期，有时间可以对过去的技术债进行偿还，另一方面也要注意避免技术过渡镀金和官僚的滋生。此时，可以挑战最新的架构来适应未来不确定的业务变化，重构升级原有技术体系，将前面各阶段的漏洞补上。
+
+打江山难，坐江山更难，每一个技术管理者不要放松警惕，此时可以好好思考一下，怎么来好好管理了。需要建立合适的文化和体系，让这些牛人有合适的氛围，继续打磨原有的产品和技术框架的同时为未来的业务拓展打好基础。注意不要给过多的资源，一直要保持着技术团队“半饥饿”状态，这样在前期积累的狼性才可以持续保持，而不是把一群狼训练成狗；当然，也不要把在余粮的时候故意把狼饿死。同时，开始配合公司进入新业务领域的研发和突围，继续从业务验证阶段重新开始新的挑战。
+
+公司业务紧缩阶段：尽管大家都不愿意面对，但是某个业务或者某个产品都会遇到瓶颈，或者试错失败的情况。此时，如何紧缩是每一个技术管理者最大的挑战。这个阶段，保持士气和核心成员是最重要的，公司里应该有一种试错的文化，很多时候业务的失败是天时地利人和的问题，不是某一个团队的问题。但是因为公司的发展和生存，可能某个业务方向要紧缩。
+
+人员如果可以转到其他业务最好，如果需要人员裁剪，注意方式方法，如果可能尽量送上大家一程，同时尽全力保留核心骨干。此时，对于士气的保持很重要，毕竟业务紧缩，不是整个公司破产，通过领导力和个人魅力留住核心人员维护最基本的业务运转，以图东山再起。“地失人在，人地皆得；地在人失，人地皆失”。仔细看每一个成长起来的大企业，无一不经过一些巨大的挑战活了下来，浴火重生的团队才是真的战无不克。
+
+管理体系建立的关注点
+
+在不同阶段，都要建立不同程度的流程体系，具体有很多文章介绍，从传统的瀑布模式到Scrum到DevOps，我就不一一介绍了，这里需要说的是除了日常的人、财、物的体系构建之外，管理体系建立还有几个需要注意的点：
+
+不确定性控制与持续改善：技术面临的不确定性很多，如果做得快了，成本难以收回；做得慢了业务无法支持。面对巨大不确定性，立一个巨大的项目，通过庞大的管理体系去管理往往都会失败。我们通常面对要做100个50分的功能和50个100分的功能的决策，我们要毫不犹豫的坚持50个100分的功能。针对每个项目、每个管理步骤，最小的闭环很重要，步子不要太大，每一个小的迭代都是成功的，持续完善才是王道。
+
+持续交付与迭代：这里不想讲CI的东西，只想强调CI的目标是“快”。最快的集成，最快的给出高质量的产品，最快的训练出来高效的跟的上节奏的团队。这才是持续交付与迭代的目标，把团队的速度和交付节奏拉起来，淘汰跟不上的人员，对优秀的人员持续激励。这样才可以得到优秀的团队，做成事情，获得其他合伙人的认可。
+
+构建使命式管理结构：团队大了就会出现行为不一致的情况。这时候有两种选择，一种是自上而下命令式管理，一种是水平沟通使命式管理。我会选择后者，尽管看上去不像自上而下流程管理那么清晰，但是，在现在这个瞬息万变的市场，你很难有效的获得最真实的信息。此时，你再厉害的经验和决策，往往也会在信息一收一发当中扭曲变形。
+
+因此，使命式管理，通过让整个团队了解明确的目标以及目标背后的原因，把权力下放，让一个产品经理也可以决定某个网页带bug上线，而达到整体产品流程完整。这个时候你会发现，形成业务闭环的速度比你想象的要快得多。
+
+结语
+
+战略和体系搭建是很难通过几篇文章或者一个培训就可以学会的，更多的是高级技术管理者的自己的思考和顿悟。此时，除了技术类书籍，建议技术管理者可以通读一下管理者经常看的书籍，例如《毛泽东选集》、《原则》，或者管理大师德鲁克、精益系列的书，从中一定会有所收获。
+
+当然，也可以加入TGO鲲鹏会，和更多的高级技术管理者在私密环境下深入切磋。很多时候，高级技术管理者，特别是技术一把手是孤独的，很难有人可以分担一把手的压力，阅读和深入切磋是大家解忧的好办法。
+
+后面，我将针对领导力、人员管理、文化建立做详细的讨论，欢迎大家持续关注。
+
+作者简介
+
+郭炜，易观 CTO ，中国软件行业协会智能应用服务分会副主任委员，TGO鲲鹏会北京分会董事会会长。负责构建易观技术团队、完成易观大数据采集、平台、数据挖掘等技术架构与体系；从无到有完成易观混合云的搭建、以及易观 SDK 的升级，并发布易观秒算实时计算平台。目前易观大数据平台日处理数据量 30T ，272 亿条，月活用户5.5亿。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/008技术领导力就是成事的能力.md

@@ -0,0 +1,79 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            008 技术领导力就是成事的能力
+                            人，是一个创新企业最重要的要素，在确定方向上能否在市场上胜出，在于这个企业招聘和管理了什么样的人才。越是高端的人才越难招聘和管理，而如何和各层级人员有效的合作，领导力是一个技术管理者的重要能力。在上一期的技术管理核心能力模型中：领导力、人员管理能力、文化构建能力、体系搭建能力、技术实力，领导力是排在第一位的。
+
+那么什么是技术人员的领导力呢？经常有人这样定义技术管理者的领导力：领导力就是让人服你，所以技术管理者的领导力就是技术要比大家都强；还有人认为领导力就是权力，赋予你权力自然就有领导力。这都不是正确的理解。
+
+领导力，管理大师德鲁克的定义是“领导力能将一个人的愿景提升到更高的目标，将一个人的业绩提高到更高的标准，使一个人能超越自我界限获得更大成就”。另一个领导力大师John Maxwell(约翰·麦克斯威尔)定义是：领导者是知道方向、指明方向，并沿着这个方向前进的人。
+
+而我对领导力的定义很简单：“成事”的能力，职位不是别人授予你的，而是你自己挣出来的。领导力就是用各种各样的方法、人员、影响力、号召力、决策力将一个事情从0到1的能力，如果把事情做成0.99，都不是领导力的体现。
+
+“成事”，对最终结果负责，这是最高级领导力的体现，如何培养自己的领导力，能“成事”呢，在我看来需要以下几种能力和素质的培养：
+
+决策力：迅速拍板并为结果负责的能力
+
+大家所理解的决策，经常是给老板三个方案，老板从三个方案里拍板一个最好的，然后让大家去执行。其实实际情况并不是这样的，作为一个高级管理者，经常能看到下属遇到一些困难的球（问题），大家想尽一切办法去接着这个球，好接的球基层、中层管理者都搞定了，出现在你面前的球都一定是“仙人球”了。
+
+所以，技术管理者看到的情况，经常不是“两好选其优”，而是“两害取其轻”，通俗的话讲，你面前两坨翔，一坨大的，一坨小的，让你必须选一坨吃，如果你不迅速确定，这两坨马上各自增长一倍。
+
+所以，每一个决策者其实都是痛苦的，他要在信息不完全明确的情况下，面对痛苦和更痛苦的事情上，迅速决定用哪个方案，并为结果负责，同时为了激励士气还不能表露出任何痛苦。如何能在这样的情况下迅速决策，结果只是当时最好的（最糟的决策就是不做决策），而所有产生的问题和压力都要独立承担，而不能给下属，这就是一个管理者决策力的表现。果断敏锐地选择当前可行的方案并为之负责，这就是决策力。
+
+沟通力：倾听与准确反馈的能力
+
+沟通是普通管理者最重要的工作，高级管理岗位除了日常的沟通之外，还要倾听中层管理者和员工的声音并准确的反馈，其中难得是“准确”二字。在对直接下属沟通时，根据员工的性格和成熟程度，准确告诉他的管理问题和对事情的目标、方法以及异常的处理情况。初级熟练员工需要手把手完整的指导如何去做，高级员工需要使命式沟通，如果沟通方式相反，反而会让初级员工不知所措，高级员工觉得无法成长，而起到反作用。
+
+在批评员工时更要准确，批评不是发泄自己的压力，对事不对人，有效的批评是帮助员工成长，下次不会再需要你操心同样的问题。如《原则》中提到的“严厉的爱才是最可贵也是最难得的”。
+
+沟通力，就是在合适的时间对合适的人用合适方法说合适的事情。
+
+影响力：号召管理层和员工一致行动的能力
+
+“职位不是别人给的，而是自己挣出来的”，这句话就是影响力的真实表现。影响力包括对外对内两部分。
+
+大部分人提到影响力，会提到一个技术人员在外部被多少技术会议邀请，有多少技术文章和概念被其他人引用和认可。其实对外影响力的目标是作用在对内影响力上，通过对于业界的影响力以及方案判断和决策不断的验证，建立管理层对于技术整体团队的信任。这样在决策和预判过程当中，作为CTO和技术管理者的技术基因才可以有话语权，可以让公司以合适的技术节奏和技术路线来发展，避免过少或者过多的技术投入导致影响业务。
+
+对于员工的影响力，是员工发自心底的一呼百应，通过准确的技术判断、正确的管理决策、合适的领导方法让员工信服决策者而不是因为职位的高低而去执行。这样才可以打造一个积极向上、海纳百川的产品技术团队。
+
+识人&授权：通过人员管理人员，通过别人完成使命的能力
+
+一个超过百人的高级技术管理者一定不是亲自再做细节的工作，而是通过更多的合适的人员来完成任务。首先，知人善用是高级管理者重要基本素养。所有的创新企业都是由人构成的，人是否合适在一个岗位上是管理者最重要的判断。在企业的不同阶段，是适用不同类型的人才的，而每个人也都是不完美的，尺有所长、寸有所短，如何管理这些人是需要有技巧的，后续文章也会再详细的讲述。
+
+其次，要充分的授权。高层管理者的授权不是说只是布置事情让大家去看，然后自己再去指挥，高级的管理者要和自己的直接下属建立信任，“疑人不用，用人不疑”。
+
+什么是授权，我用个极端的例子，哪怕是下属去犯错，你也要眼睁睁的看别人犯错，而自己来承担所有的后果。除非你判断问题超过你的职权范围或者挽回范围，否则你不能直言相告。“看着下属犯错，自己却不能说” 这点是最难的。因为你说了，这些经验就永远是你自己的，下属不在错误中成长，管理者就是永远的瓶颈。这是中美文化最大的差异，也是创新企业和传统企业管理方法最大的差别。
+
+“允许犯错，但不允许同样的地方持续犯错”这也是在后续文章讲“文化构建能力”时会讲到的。是否做到识人&授权，是管理者是否可以管理超过100人团队的门槛。
+
+坦诚&开放：营造一种氛围，绝对的透明和坦诚，绝对的开放
+
+如前面所说，一个技术管理者不一定是公司技术最强的人，这很好理解，在公司小的时候往往是技术最强的人，随着技术团队的壮大，如果他还是各方面技术能力最强的人，那么他一定是这个公司的技术瓶颈，会被公司淘汰。
+
+但是作为技术一把手，他一定是公司里对技术人员最坦诚、最开放的人。举一个我自己的例子，刚到易观的时候技术团队还不够给力，技术债很多，一次严重事故的时候，整个技术团队48小时没有解决一个平均QPS30多万-峰值快到100万的数据接收问题（一天快200亿条数据接收IP还是写死的，资源还不够LVS后面netty还是tomcat业务都撑不住 @_@），没办法，自己上阵用72小时学了lua和openresty分流了压力，按照我设想的逻辑重构了接收端，临时解决了问题。
+
+等到我招到好的技术人才，把项目交接给他的时候，他公开的非常直接的对我讲：“大侠，你写的这个东西什么破玩意啊，有更好的函数为什么不用，看这里写的简直画蛇添足……”巴拉巴拉地把我训了一通。
+
+一方面，我坦诚承认我的不足，在那个环境下如果他来了，肯定比我解决的更漂亮；另一方面我很高兴，在会上我们可以开诚布公的就事论事，没有谁是权威，只是坦诚、开放的讲对的事情。这样才可以容纳更牛的人，让事实带领全公司的团队走向正确的方向，而不会因为个人的误判导致整体的失败。
+
+如何建立这样的文化和体系，后面的文章会和大家分享，坦诚&开放是一个团队走向持续增长的必要条件。
+
+悟性&个人魅力：悟性与个人魅力是一个管理者的必备的软技能
+
+没有一个人是天生的管理者，所有的管理经验都是通过不同的管理实践和反馈中积累起来的。对于同样的一个人或事情，管理者从中参悟到什么，理解到什么程度，是一个管理者是否可以持续提高的关键。所以作为高级管理者，至少留给自己20%的时间在思考，而不是具体做事情，反思自己的决策、沟通、影响、开放当中的问题，是否可以有更好的方法来提高，这样才可以让自己持续在管理岗位上提高。
+
+而个人魅力是和管理风格息息相关的，尽管每个管理者的管理风格都不太一样，但是你发现做到高层管理者的人，去掉这个管理者的title，在其他领域的普通沟通当中，他依然有特殊的人格魅力让他闪光，让他身上具有一种“领袖气质”。这点并不是通过专业性辅导可以做到的，而是管理者自己在做人的方面要有更深的理解和见地，反复的参悟自己、提高自己才可以做到。
+
+所以，大家看到很多高层管理者开始大量阅读非专业的书籍，也是源自于此。一个人能做到什么样规模的高级管理者，和他对于自己、对于业务、对于管理甚至对于世界的参悟程度有关系，最终管理的瓶颈是对于自己对于世界的认知瓶颈，而不是技能瓶颈。所以，专心阅读《技术领导力300讲》和各种知识含量的书籍、杂志是扩大自己认知边界的好方法。
+
+最后，大家可以看到管理是没有年龄界限的，无论是一个70后、还是一个00后，一个具有决策力、沟通力、识人&授权、坦诚&开放、悟性&个人魅力的技术领导者是一个有领导力的技术一把手的必要条件，而体系搭建能力、文化构造能力、人员管理超能力、技术实力也是一个技术一把手不可或缺的，这些请大家持续关注我在《技术领导力300讲》的“打造技术管理核心能力”系列文章。
+
+作者简介
+
+郭炜，易观 CTO ，中国软件行业协会智能应用服务分会副主任委员，TGO鲲鹏会北京分会董事会会长。负责构建易观技术团队、完成易观大数据采集、平台、数据挖掘等技术架构与体系；从无到有完成易观混合云的搭建、以及易观 SDK 的升级，并发布易观秒算实时计算平台。目前易观大数据平台日处理数据量 30T ，272 亿条，月活用户5.5亿。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/009CTO是商业思维和技术思维交汇的那个点.md

@@ -0,0 +1,73 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            009 CTO是商业思维和技术思维交汇的那个点
+                            CTO这个岗位，在今天的任何一家互联网企业中显然都是不可缺少的，特别是处于创业阶段的企业。当我在微信群里发出一条“推荐靠谱CTO”的消息后，会瞬间被无数红包砸到。但当我试图了解他们对CTO的需求时，回答却迥异。同时，在CTO的圈子里，我又经常听到对这份工作的迷惘甚至抱怨。
+
+我非常不愿意把人群分类，用标签的形式去评价。但我认为，在任何一家对技术需求较大的企业中，确实存在两类差异较大的人群，一类偏商业性思维，另一类偏技术性思维。而CTO恰恰就是这两类人群交汇的那个点。
+
+CTO的“本职”工作
+
+站在CTO的角度，我认为以下三类工作应该算是本职工作。
+
+第一，团队建设。包括招新人，培养人，淘汰人。如果团队大了，还包括文化建设，制度建设，层级体系建设。
+
+第二，还技术债。例如TutorABC/vipJr是一家有20年历史的互联网企业，有大量的老系统，老代码。我的一个重要任务就是解耦和重构。我相信所有CTO都面临这个最难最复杂的问题。再难你也要解决。边开飞机边换引擎，早已经是普遍的做法了。
+
+第三，技术升级。互联网技术日新月异，CTO需要让一些新技术落地，开花，提振士气。2017年，TutorABC/vipJr的两项技术成为亮点。基于WebRTC，后端用Go语言实现的新一代音视频技术TutorMeet+，实现了在丢包率20%的不稳定网络环境下，仍然让学生和老师顺畅地进行双向互动。大数据系统不仅让数据处理能力提升了2个数量级，还让业务的数据分析速度提升到秒级。自定义报表进一步提升了数据分析效率。除此之外，我的年终总结还包含了可用性数据，人效数据等其它支撑数据。
+
+其他CTO的年终总结或许还包括异地多活技术，小程序，AI，甚至区块链技术等等。CTO们带着各自的技术团队忙活了一年，交出这样的作业后，公司们都满意吗？我认为，做到以上三点是必须的，是及格，但未必得高分。作为交汇点的那个人，CTO的作业还应该包括公司的商业价值。
+
+CTO还可以做什么？
+
+除了做好公认的“本职”工作以外，CTO还可以做什么？这显然是因人而异的。结合2017年的工作内容，我在这里分享一些实际工作案例。任何行动都是思维的产物。所以我把它们抽象为四种思维方式：效率思维，用户思维，跨界思维，和商业思维。无论是哪种思维，都必须对应到公司的商业价值，都应该以产生商业价值为最终目标。
+
+效率思维
+
+提升内部效率通常是CTO最容易切入的点。大家的方法会有很多相似之处。比如改进工作流程，推进数字化管理，通过自动化代替人工等等。但CTO很容易陷入的一个误区是，只用报表证明自己的成绩，而非用公司的成本来衡量效率。
+
+内部效率的提升，通常不是省了钱，就是省了人。但省出来的钱或人去哪里了？公司的总费用或总人数下降了吗？辛辛苦苦省出来的钱或人，有没有被拿去做了效率更低的事情？如果回答不了以上问题，效率提升也许并没有真正发生。
+
+在TutorABC/vipJr，我们在客服系统上投入了大量研发资源，包括人工智能。对于在这方面的效率提升，我的目标很简单，就是大幅下降客服的人数。当然前提条件是客户体验不能下降，其它部门人数不能因此上升。这就是我今年的主要目标之一。我建议CTO们看效率的时候，不仅要看局部效率的提升，还要看全局效率的提升。只有全局效率提升，才能为公司真正节省成本，创造价值。
+
+用户思维
+
+CTO通常比较善于通过表面现象看本质，也比较喜欢系统性地根治问题。我们可以把解决客户当下问题，解决表面问题定义为短解；把系统性地根治问题定义为长解。当寻求短解和长解平衡时，CTO比较容易倾斜到长解这一端。但是在今天高度竞争的互联网环境中，如果短解不够，不能立刻解决客户的当下问题，很可能导致客户流失和失去竞争优势。
+
+很多时候，问题经过层层汇报后，已经失去了当时的温度和紧急性，从而衰变成了没有温度的数字。这时候很容易选择长解而忽略短解。例如，在服务中，数据显示有万分之一的用户有某种问题，我们往往觉得问题不大，还有比这个优先级更高的问题。但如果是我们自己或者亲朋好友碰到这种问题时，我们就恨不得要马上解决，立刻解决。后者更紧急的原因是我们对用户有很强的感知，有同理心。而前者已经变成了冷冰冰的数字，激发不起我们的同理心。
+
+CTO可以解决这个问题。一方面，可以通过系统，尽量让用户的问题原汁原味地传递到后台，让解决问题的人看得到当时的场景以及对问题用户的紧急程度。另一方面，CTO需要激励和培养团队的用户意识和用户思维能力。只有让更多的员工做好短解和长解的平衡，公司层面的平衡才能做到更好。
+
+跨界思维
+
+有些CTO做过多个行业，有些CTO了解多个行业。我认为跨界思维是CTO特有的技能。而这个技能或许可以给企业带来很大的价值。
+
+TutorABC/vipJr虽然是一家在线教育的公司，但我们的做法非常跨界。在整个教育行业中，几乎所有公司都采用学生选老师的模式。学生是客户，老师提供服务，客户选择服务，貌似这是天经地义的。但我们在很早以前就颠覆了这个思路。我们决定不让学生选老师，而是通过算法来匹配老师。其实我们做了教育行业的滴滴和Uber。大家试想一下，如果打车软件让你选司机，会怎么样？很可能的结果就是，要么你选的司机离你很远，空车过来接你很浪费司机资源；要么你选的司机正在接客人，不能服务你。这就是目前很多在线教育企业的问题之一，一边企业拼命增加老师，一边客户抱怨选不到他们想要的老师。
+
+我们的DCGS（动态课程匹配系统）很好地解决了这个问题。不仅如此，DCGS还可以做到1对多的小班课。大部分在线教育公司还停留在1对1的水平。1对1上课，类似普通打车。而1对多小班课，类似于顺风车/拼成模式。DCGS通过算法，做到了把多个水平相当，兴趣相似，对老师的偏好一致，上课时间相同的学生匹配到一起。
+
+DCGS的另外一个创新是真正实现了个性化的非线性课程教学。线性课程就是普通课本，上课顺序必须从第一课到最后一课。DCGS可以做到非顺序，非连续的个性化教学。例如根据计算，某个学生从第8课开始，然后跳到第15课，然后再跳回到第3课。线性课程在传统教育中被认为是再正常不过了。但试想打车如果也是这样，每辆车都必须像公交车一样走固定路线，是不是很滑稽？
+
+CTO是一群经常接触互联网最先进技术，最先进商业模式的人。如果我们能跳出自己的行业，看看其它行业在怎样解决问题，或许能给我们的企业带来非常大的创新机会。我觉得自己很幸运，能站在前人的肩膀上，把跨界思维发挥到极致，让我们和普通竞争者在不同的赛道赛跑。
+
+商业思维
+
+绝大部分技术和产品研发在公司中属于成本中心，是后台支持部门。但如果技术逐渐强大之后，也许可以利用技术直接产生商业价值，让后台直接变成前台。
+
+我们在2017年看到了青少年编程这个市场在逐渐变大。于是我们决定由研发团队内部自己孵化，并且不占用公司任何的额外资源。我们自己设计产品，做市场营销，自己运营“vipJr青少儿编程”微信公众号，然后通过朋友圈转发来获客。我们的产品经理和程序员兼职做销售，通过微信来转换客户，引导客户去自助购买我们的课程。最后，我们的程序员兼职做老师，和家长约定时间，给小朋友上Scratch课和Python课。从产品设计，产品定价，市场营销，到销售，到服务，技术部完成了闭环。
+
+这件事不仅为公司创造了新的商业价值，也让技术部从后台走到前台，亲身体验产品，营销，销售和服务这几个核心环节。这对于技术部直接参与到公司的核心业务中，有着非常大的促进作用。一个充分理解公司商业模式的技术团队，一定是公司的核心竞争力之一。
+
+结语
+
+现代的企业对于技术的依赖越来越大。CTO是企业中商业思维人群和技术思维人群的交汇点。因此，CTO在商业策略和组织策略中扮演的角色是枢纽。好的枢纽可以让信息沟通顺畅，让商业决策变得快速，让技术能力得以释放，让企业高效并充满竞争力。
+
+作者简介
+
+汤峥嵘，TGO鲲鹏会上海分会会员。2016年10月18日正式出任iTutorGroup集团首席技术官（CTO），于2018年1月3日升任为iTutorGroup集团首席运营官（COO）。曾在阿里巴巴历任淘宝网、支付宝、B2B的资深总监及日本阿里巴巴、途牛网的CTO，并先后负责淘宝网架构迁移、支付宝网站创建、国际网站、途牛整体技术架构、淘日本的技术研发项目。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/010创业公司CTO的认知升级.md

@@ -0,0 +1,71 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            010 创业公司CTO的认知升级
+                            在不同的行业中，以及不同公司在不同阶段，对CTO的要求是非常不一样的。同时任何一个时期，对CTO的能力要求其实都是综合的。
+
+我所在的公司是一家创业公司，我是公司的联合创始人和CTO。我想结合我在公司不同阶段的经历，谈谈我对CTO这个岗位的认识。
+
+公司初创期
+
+大多数互联网创业公司，一开始都是从几个人开始干起，我们也不例外。这个阶段最重要的是如何快速开发，快速试错，通过试错不断验证自己的idea是否靠谱。而对于技术架构是否可扩展、研发流程是否规范、绩效考核等则不会过多考虑。
+
+记得我们在开始第一个产品的时候，直接写JSP页面，不需要前后端分离（因为我们也没有专职的前端），数据库则用了Schema free的文档数据库MongoDB，无它，就是追求最快迭代开发速度。
+
+这个阶段的公司，应该建立怎样的认知呢？首先是创业越早期风险越高，其次是低成本试错。那么作为CTO或者技术负责人，你的决策也需要匹配公司当前的状态。
+
+比如招人方面，从匹配性上看，如果候选人没有创业心态，过于追求安稳，就可以pass掉；从技术画像上看，一个全栈工程师会比一个技术专家更能帮助到团队。
+
+比如技术选型方面，不要犯杀鸡用牛刀的错误。尽量选择轻量级的框架，考虑最大化团队的开发效率为核心。在产品还未被被验证之前，过于超前的为大规模用户使用、超高并发和海量数据访问投入设计，很可能最终只能沦为摆设。因为产品的死亡率极高，方向也随时可能发生变化。
+
+网上流传着腾讯的QQ服务端架构从建立初期一直沿用到现在的说法，腾讯的CTO 张志东在一次内部培训中被问及此事时，很坦诚地说，其实QQ的架构一直在不停的改造和优化，到目前为止已经做了4~5次的调整。当初创业时候的规划是：第一年同时在线人数到达1K，第二年2K，第三年4K，第四年8K，第五年就可以上万了，而实际上第五年的时候腾讯已经做到了500万的同时在线数，目前QQ支持的最大的同时在线人数已经超过上亿。张志东说，如果1998年创业初期，就让他做到支持500万的同时在线人数，可能就不敢创业了。
+
+高速发展期
+
+一旦你的产品通过了用户和市场验证，公司可能会进入了新的发展阶段，这时候你才有机会接受进一步的考验。随时用户和业务的增长，产品需求可能越来越多，公司对产品的迭代要求更高，老的技术架构已经不能适应新的业务迭代，同时管理层也越来越关注产品的稳定性对客户的影响，你的团队人员在不断的膨胀，而你还没有准备好绩效管理，也还不知道如何去淘汰不合适的员工……
+
+开始接近自己的创业梦，发现梦想并不是想象中那么美。在公司的高速发展期，问题产生的速度远比你想象中快。这个阶段的CTO应该建立怎样的认知呢？
+
+我总结有三点方面的思考非常关键：
+
+第一，抓大放小，区分主次。分析清楚当前主要矛盾和次要矛盾，重点解决主要矛盾。把当前的问题、内外部需求、公司的规划进行梳理对比，找出核心问题，重点投入。
+
+在我们公司发展历程中，曾经遇到一些问题。首先是团队效率，在人员膨胀的情况下，如何保证做到小团队作战的人效。亚马逊的CEO杰夫·贝索斯有个“两个披萨原则”，如果两个披萨不足以喂饱一个项目团队，那么这个团队可能就显得太大了，沟通协作的效率很容易下降。把团队按业务或职能切分，可能是更好的方案。如果你的团队人员扩充上去了，生产力并没有跟上，那么是时候考虑团队规模是否太大的问题。
+
+如何平衡各种需求？在我们公司的发展历程中，早期产品稳定性是我们的核心问题，当时我们内部同事也会反馈说竞品有这个功能那个功能，而且网站上页面看起来比我们舒服多了，这些需求我们能不能做？记住，资源永远是有限的，次要的功能不做不会影响用户的核心流程，页面长得不好看也不影响用户的使用。但如果产品不稳定，那客户是要跳起来的，所以我们早期研发的重心之一是做稳定性优化。
+
+第二，追根溯源，从源头解决问题。特斯拉的CEO埃隆·马斯克倍受推崇的“第一性原理”思维，就是强调在基本事实的基础上探究问题的本源，不被过去的经验知识所干扰。在高速增长期，我们也会遇到各种各样的问题，从根源上解决问题才不至于反复的疲于应付。
+
+比如面对产品的故障，是每次修复完就忙于下一个需求，还是重视复盘总结问题根源？这一点《SRE Google 运维解密》这本书提到的“事后总结制度”做得非常到位，除了追溯问题本质原因外，还建立了良好的总结文化，会收集事后总结内部分享，开放评论，对于良好的事后总结和事故处理还会做公开的奖励，甚至可以得到高层的点赞。
+
+再比如技术债，技术债累积越多，后期的研发效率、问题隐患越多、维护成本越高，适时的解决技术债问题，是从长远考虑非常有价值的投入。
+
+第三，充分放权，有效监督。早期小团队作战，也许还能靠几个尖兵一招鲜，快速占领先机；中后期拉开战场了，必须要依赖团队作战，依靠制度管理。
+
+首先，早期成长起来的CTO，长期战斗在一线，冲锋陷阵以身作则的品质自然是不用说的。但是作为最高指挥官，最难得的是需要自知和自省，知道自己的短板和优势是什么，知道如何补自己的短板，不管是找到比自己更强的人，还是依赖团队的力量，这要求CTO具备有大局观和开阔的心胸。我们看到很多公司设立技术委员会、架构组等技术决策层，也有些公司设立联席CTO，其实是非常好的尝试，既下放了一些技术决策权，又补充了CTO可能的技术短板，同时也可以根据需要，对CTO的技术决策权做一定的约束，形成互相监督。
+
+其次，团队作战，也讲究排兵布阵。按业务切分，还是按职能切分？还是更复杂的混合架构？孙子兵法曰：“知己知彼,百战不殆”。需要结合团队成熟度、业务特点和竞争格局考虑，要求CTO除了了解自身团队特点，还要熟悉行业竞争格局，以制定出最强有力的打法。阿里巴巴搞出了“大中台、小前台”组织架构，即作为前台的一线业务会更敏捷、更快速的适应瞬息万变的市场，而中台将集合整个集团的运营数据能力，产品技术能力，对各前台业务形成强有力的支撑。
+
+最后，有不同的团队，就需要更多的将军。在这个阶段，要有意去选拔和培养合适的leader，建立人才梯队。但人才培养、团队建设都是一个长期的过程，并非一蹴而就。高速增长的阶段，也要适时去补充能独当一面、身经百战的大将，在专业能力、技术视野、管理经验等方面补充团队的不足。不至于出现“蜀中无大将，廖化作先锋”的悲哀。同时对于新上任的将领，作为将军需要知道每个人的局限在哪里，每个人都不是完美的，要知道如何去补位和防范，以制定有效的监督。
+
+稳定发展期
+
+经历了早期的试错和高速的发展，公司可能会进入一个相对稳定的发展阶段。为了公司长远发展，公司需要不断的进行新业务探索、不断进行技术的创新，CTO对新技术的判断力和商业敏感度会越来越重要，CTO的视野关系着公司的未来。就像前微软CTO Nathan Myhrvold 所说：“My job at Microsoft is to worry about technology in the future. If you want to have a great future you have to start thinking about it in the present, because when the future’s here you won’t have the time.（我在微软的主要工作是关心未来的技术。 如果你想拥有一个美好的未来，你现在必须开始思考它，因为当未来来临时，你就没有时间了。”）
+
+我们也看到了很多优秀的公司，在技术上所做出的超前布局。全球公认的最优秀的CTO之一，亚马逊的Vogels 在一次采访里介绍了 亚马逊在机器学习领域的技术布局。他介绍说，在过去的 20 年间，已经有多达数千位软件工程师在亚马逊参与了机器学习项目。他认为亚马逊是一家在业务领域使用人工智能和机器学习技术的前沿公司，也正是因为不断地创新，才会让业务发展不断突破瓶颈。
+
+写在最后
+
+就像电影《后会无期》中所说的：“听过很多道理，却依然过不好这一生”，每个CTO的经历和挑战大不相同，只希望以上分享的经历能抛砖引玉，对大家能有一点帮助。
+
+在创业路上共勉！
+
+作者简介
+
+林佳齐，云片网络 CTO，TGO鲲鹏会杭州分会会籍委员&服务委员。2010 年加入淘宝，参与淘宝搜索技术的改造与优化、淘宝去 IOE 等项目。2012 年创业， 负责技术团队搭建和管理、核心产品研发和运维保障。从为淘宝商家提供 CRM 服务的维客软件，到为企业提供短信、语音、流量等服务的云片云通讯平台，对高可用、高并发系统架构设计有丰富的实践经验，对于云通讯技术和稳定性实践有深厚积累和独到见解。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/011最合适的技术才是最有价值的技术.md

@@ -0,0 +1,75 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            011 最合适的技术才是最有价值的技术
+                            很多技术人在最开始工作的时候，都会有一种误解：做技术主要的工作是要和计算机打交道，而不是和人打交道。只要技术足够牛，不用考虑太多其他的事情。但是随着时间的推移，大部分人的看法也有了很大的改变。
+
+好的技术一定是从公司的状况出发，最新的、最先进的技术不一定就是最合适的技术，最合适的技术才是最有价值的技术。作为技术领导者，又该如何去把握呢？我们就这个问题采访了几位技术负责人。
+
+花虾金融CEO、前宜人贷CTO 段念：
+
+在我看来，技术本身是为业务支撑服务的，换句话说，技术所有的价值最终都要通过业务结果来呈现的，我不认为技术可以独立于业务之外去体现它的价值。所以从这个意义上来讲，所有对于业务有好处的可能，我们都愿意花时间和精力去尝试。
+
+当然对于技术，我的另一个观点是，所有重复性的事情都应该被具体的程序化的方式所替代。所以我一直试图找到一个平衡，一方面技术是为业务支撑提供服务的，但技术人应该do smart things，应该用聪明的方法做事情，而不只是作为业务的一个实现手段。
+
+一个好的管理者首先应该面向目标，这意味着他不会关注太多范围、界限，而是奔着把这件事情的结果给搞定。所谓目标，可以用简单的整个公司层面的目标来解决，但同时它也需要落地，每一个团队和个人都需要知道自己的目标是什么。这个目标并不是一定要去改变什么，但需要始终在组织中间做一个清晰的传递，让大家都清楚。
+
+另外，面向目标也就意味着整个组织的绩效管理、晋升体系等方面，都需要与之强烈挂钩。
+
+融云CTO 、TGO鲲鹏会北京分会董事会成员杨攀：
+
+我在微软有一段工作的经历，微软给团队的定位就是三个角色：产品、研发和测试。但实际上微软的团队模型中，这三个角色是互相交叉的，要求你每个角色都要懂其他角色的东西。在做任何事情的时候，都应该站在其他角色、其他知识领域上去考虑这个问题，当你能做到这样的时候，你在这个团队中就会是一个非常非常优秀的角色。
+
+我觉得优秀的人，都至少能达到：1、能够清楚地认识到什么东西是对的。2、在知道是对的情况下，愿意去把事情做得更好。我是一个特别有洁癖的人，我会要求我的团队在写中英文混杂的东西的时候，按照一定的标准去写。
+
+要了解什么是正确的，认同正确的理念，愿意按正确的理念去做事情。
+
+极光推送CTO兼首席科学家 黄鑫：
+
+无论我们是否承认，公司大了就需要划分部门，划分部门就需要有部门管理者，每个管理者一定会为自己的部门争取最大的利益，这个利益不仅仅是金钱层面的利益，还包括可控性、风险性等等。
+
+举例来说，假设我们需要做一个需要多方配合项目，移动端会说我们负责的就是把数据传到后端，各种逻辑转换应该后端来做。后端会说我们负责的就是维持后端架构的稳定性，具体的业务逻辑你们来搞。数据会说你们能不能把数据清理好再传给我，这样我集群压力小。当然，三方都有自己的理由，大家都讨厌业务复杂度，保证技术架构的纯净。很多技术人员避免和其他部门产生过多的联调。这时，能站在中立角度去评估分工合理性的只有CTO。
+
+要做到这一点，那么自然牵引出了两个必备的素质：1、全面的技术能力，不求多深，但是可以听懂不同部门的诉求和技术方案，了解不同方案的技术难度。2、 优秀的沟通能力和说服能力，这一点无需多言。
+
+恺英网络的技术支持系统副总裁 伍涛：
+
+除了技术与管理，技术人应该进一步用商业思维武装自己，努力去思考如何帮助公司获取利润、提升市值。新的商业模式几乎都是挖掘出来的，敏锐的商业嗅觉非常重要。
+
+我觉得最厉害的人是有理想的技术人，他们能把技术和商业结合。比如，Microsoft 的 Bill Gates 、Tesla 的 Elon Musk 、Facebook 的 Mark Zuckerberg 、小米的雷军等，那些伟大的公司都是这些有理想的、有技术背景的人创立起来的。
+
+恺英是个小团队作战的公司，所有成功的产品都是靠业绩打出来的，在恺英只要做得好，就可以获得相应的回报。恺英看似低调，其实 2017 年有超过 16 亿元的净利润，能够做到这个业绩的公司并不多。能够取得这样成绩在于团队里有很多有互联网商业头脑的人，他们在思考如何在互联网行业里把握新的机会，机会来了就去做，然后把它迅速变大，成为公司一个新的业务。
+
+苏宁云商IT总部执行副总裁、苏宁技术研究院院长 向江旭：
+
+在创业公司，公司的业务需求、生死存亡肯定是首要问题，那技术领导者的思维方式也要把公司的生死存亡放在第一位，不需要考虑太多的系统架构更新。
+
+但在构建系统、提出方案的时候，要跟CEO沟通清楚各个方案的优缺点，比如采取短平快的方式，前半年、一年系统可以支撑，但也许一年后要付出的代价更大，如果到时系统架构重构的话，对业务的冲击可能是现在的10倍。要把那些利弊、短中长期的厉害关系跟大家沟通清楚。
+
+同时，技术领导者还要向CEO展示，技术不仅仅只是业务的支撑，技术还可以引领业务的发展。以电商为例，不是网站不宕机、可以卖货，就是一个好的电商系统，还需要研发大数据等技术，更好的理解用户、精准画像，做精准营销、做技术推送、提高转换率等等，这些都是帮助业务更好发展的。
+
+Coding.net CTO 孙宇聪：
+
+如果一个创业公司做不到统一开发环境和研发体系，那么势必会造成我们研发力量的分散。这就是为什么有些公司事儿特别少但人特别多，因为每个人所作的事情都不通用。
+
+完全禁止创新是不可能的。因为作为一个公司、团队必须要尝试新鲜的东西，不然难以进步。如果一个团队老用旧的东西那他就领会不到外界的好处。举一个例子，这就和像园丁打理花园一样，你可以让花随便长，但到了一定时间一定要把长得不好的砍掉，选出其中一种，或者是有限的几种一定要留住的。最终的决定其实并不重要，重要的是要有这样一个决策的过程，以及强有力的执行。
+
+作为 CTO 来说，我的工作就是抵住 CEO 的压力。每周我们要安排一些产品上的事情，也要留出一段时间来做架构上的整理，改进，统一。我需要给程序员们留出时间，创造条件来做这些长远的事情。 只要把程序员聚到一起，他们自然而然就会产生出很好的想法来，然后再把这些好的想法推广出去。
+
+欧电云创始人 韩军：
+
+作为公司的技术一把手，CTO一定要把握行业趋势，我觉得在行业内去看技术可能更好一些，因为对行业理解得越深，实际上你解决How的问题的能力就越高。你最好在某一个领域达到专家级的水准，这对你往水平方向扩展有很大的帮助，因为很多的方法论都是相似的，你其实可以用在一个领域的深度去做一些思考，这对你有非常大的帮助。
+
+其次是要从客户角度思考。这是非常难的一件事儿，一是因为你的客户有很多种，如高层老板、产品经理、开发人员等；二是你还要满足客户的客户，最终的用户才是产品最终有价值的东西，不是说今天满足客户就OK了，我还要满足其他用户的需求，这个难度就非常高，不是简单的说今天了解我的一个客户、一个想法就OK了，其实没有那么简单。
+
+还要从业务角度思考。我们发现很多技术人员和业务人员的沟通经常是鸡同鸭讲，完全不在同一个沟通线。技术人员理解之后出来的东西不是业务人员想要的，再做一遍又不是想要的。很多时候因为没有同样的思维逻辑，大家其实是很难沟通的，所以作为公司技术的一把手一定要有业务思维。
+
+结语
+
+以上就是几位技术领导者对于技术部门在整个公司的定位的理解，哪些观点与你不谋而合，又有哪些观点是你之前没有想过的？欢迎留言与我们探讨。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/012谈谈CTO在商业战略中的定位.md

@@ -0,0 +1,63 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            012 谈谈CTO在商业战略中的定位
+                            “战略”一词最早是军事方面的概念，战略的特征是发现谋略的纲领。在西方，“strategy”源于希腊语中的“strategos”一词，意为军事将领、地方行政长官，后来演变成军事术语，指军事将领指挥军队作战的谋略。在中国，战略一词历史长远，“战”指战争，“略”指“谋略”、“施诈”；春秋时期，孙武的《孙子兵法》被认为是中国最早对战略进行全局筹划的著作。
+
+战略是一种从全局考虑谋划实现全局目标的规划，而战术只为现实战略的手段之一。实施过程中，往往又是要牺牲部分利益，去获得战略胜利。战略是一种长远规划，是远大的目标，往往规划战略，制定战略，用于实现战略目标的时间是比较长的。
+
+争一时之长短，用战术就可以达到目标，如果是争一世之雌雄，就要从全局出发，去规划，这就是战略。那么，在互联网企业公司中，一般是由CEO制定战略，那么CTO在中间应该扮演什么角色呢？这个问题是令很多CTO感到疑惑的。
+
+战略必须被认可和接受
+
+首先第一点：作为技术领导者，首先要参与讨论战略，充分认可战略目标，并作为决策者的立场上接受。要站在整个公司的层面上，觉得公司的战略是可以实现的，也是合理的。用一句俗语来说就是：CTO永远是要为CEO的“吹牛”去埋单的，但是，从职业的角度来说，不能玩死了。
+
+大概意思就是，在总体战略下，CTO作为技术领导者，至少需要从产品设计、技术落地两个层面去支撑战略在产品上的的落地，若不能理解并接受，产品是无法及时有效的落地，并推向市场的，连试错的机会也会失去。
+
+其次，战略宣讲。任何一个团队，CEO、CTO……CXO，再怎么厉害，现代企业中，不可能靠一个人能将所有的事情都完成。同样，这些不同团队的负责人也不能将一家公司的战略在战术上完美落地，必须依靠一个核心团队，依靠能够理解，并接受战略，且各自不同分工的团队。如何让核心产品和技术团队推进落地，对其核心团队进行宣讲，并让核心团队能够接受，作为技术领导者在对战略的分解，在战术上的具体落地，策略的制定，等等，时刻被考验着。
+
+战略宣讲的三个步骤
+
+那么如何进行宣讲呢？就我的经验来说，一般宣讲分为这么几个步骤。
+
+第一步：战略制定者从全公司层面对公司来年的目标、运营模式进行宣讲。这种情况下，一般面向公司全员宣讲来年的目标，讲解制定目标的意义，制定这些目标的依据。这种面向全员的宣讲，最大的问题并不是无法将目标和战略详细的讲解清楚，也不是担心整个公司层面是否能够接受，而是在于如何能够清楚的描述为什么能够完成这些目标，完成这些目标的底气和信心来自哪里。这些都是在宣讲过程中，需要向全公司层面清楚的描述的，同时核心管理层要给大家展示以及表达能够完成这些目标的信心。
+
+第二步：这一步最重要的点就是战略和目标分解。公司层面的目标定义完成，接着就需要每个团队根据目标，认领自己团队的目标，团队负责人对团队目标进行分解。实际上这里是对整个公司来年的目标的进一步分解和目标宣讲。这一阶段实际上最重要的是根据公司的目标，在产品和技术层面的支持。为了达到公司既定的战略目标，产品的设计思路是如何提供对完成目标的支持的。以及在产品思路上，技术的架构设计思路，技术路线设计，以及在技术上的落地策略。
+
+再次，落地策略、资源调配。战略再高大上，最后也要靠战术推行落地。若只是战略上的宣讲，而没有最后的落地策略，往往会被认为是吹牛。作为CTO，理解并接受战略之后，接着就要做产品策略，设计产品思路，其核心思想一定是在产品上体现战略。围绕着公司的整体运营思路，体现产品的设计思想。产品的设计一定是整体运营思想的体现，在这个中间，CTO一定要带领整个产品、技术团队，在既定的战略思维指导下，对产品目标、策略进行设计，确定产品的范畴，明确产品诉求、目标客户群体，设计产品具体的运营玩法。
+
+能解决问题才是合格的CTO
+
+确定产品的设计思路、目标群体、产品范畴等之后，就要调配资源进行落地，此时，作为产品、技术的领导者，对其基本功底的考验就变得非常重要，如何在现有资源上，对资源进行最优化的配置，产品功能如何抉择，合理利用资源，优化资源，最大化利用资源合理设计并执行落地，是需要技术领导者去做的事情。
+
+至于很多公司的技术领导者觉得不知道自己该为战略做什么，其实这个问题一般是因为，CTO尚未理解公司的目标定位，即便知道也是一知半解，对公司的目标定位并不是完全接受。
+
+有些技术领导者则是能完全理解并接受战略目标定位，但是并不清楚公司在这种目标定位下团队短板在哪里，需要补充的资源是什么，以及这些资源该如何补充。
+
+对于这个问题，个人觉得，CTO应该在充分理解之后，跟每个团队，尤其是不属于CTO负责的团队进行充分的沟通，理解这些团队的痛点，业务上的不足，设身处地的站在对方团队的基础上理解并接受对方的痛点，换位思考，对症下药。
+
+什么样的CTO才能在商业战略上做决策？
+
+那么合格的CTO应该具备什么素质，才能支持其作为核心决策者之一，参与公司的战略定位和经营决策？个人认为，至少需要具备以下几点素质：
+
+至少在技术上的某一个领域独当一面，无论是架构设计、性能优化、服务端开发等，至少需要具备很强的经验，踩过坑，否则，对于技术上的经历更多的只会停留在纸上谈兵的层面。
+
+CTO未必要亲自写代码，但一定要懂得系统是如何通过代码实现的，懂得编程的原理，懂得程序员是如何干活的，各种方法的优缺点必须心中明白，说的直接一点就是，不能让下面的任何人把你给忽悠了。
+
+架构设计是CTO关注的重点，未必亲自设计，但一定要了解各种架构的优缺点，以及当前选择的理由和依据，结合当前的业务发展，做最优的选择。
+
+相当重要的一点是沟通能力，往往沟通能力体现的是两个方面，其一是表达能力，充分、明白的表达自己的观点，在跟不同的人沟通时，能用不同的语言和方式表达；其二是理解能力，不管跟业务方、产品经理、运营或者CEO沟通时，都能get到对方的真实意图，透过现象看到本质，获取最真实和原始的需求。
+
+很强的产品意识和商业意识。任何商业模式希望在最后获取最大化的商业价值，技术是无法逾越的鸿沟，而CTO作为公司的技术最高指挥官，必须同时具备很强的产品意识和商业意识，将业务和技术有机的结合起来，才能实现商业目标最大化的商业价值。
+
+总之一句话，CTO是为CEO的吹牛而埋单的，但是不要忘记，作为追求利润最大化为唯一目标的经营单位，任何一次的目标定位，都是生死抉择。作为核心决策者之一，理解接受只是最基本的要求，充分参与其中，合理调配资源，并解决问题才是合格的CTO。
+
+作者简介
+
+吴万港，前中恒云能源CTO，TGO鲲鹏会杭州分会服务委员&学习委员。10多年的互联网行业从业经验，带领多个团队完成设计、研发了分布式K/V，分布式数据库，日处理达到百T级别的分布式文件系统。8年以上互联网行业大型的产品、技术团队的建设、团队发展、团队管理经验。对于从产品需求、技术实现等管理方面有全面的认识和实践经验，深入理解敏捷研发管理办法以及多年的实践经验。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/013把脉高效执行的关键要素.md

@@ -0,0 +1,153 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            013 把脉高效执行的关键要素
+                            曾经有个公司的高管跟我说，“竞争对手家的团队”天天加班到很晚，于是也想让自己团队实施996工作制，问我怎么看。
+
+我问他，希望通过996来达成什么目的？他一时语塞。
+
+我其实挺理解他的感受，他希望事情能够做得更快，团队更有干劲，产出更有效率，让整个公司跑起来，至少比竞争对手跑的要快。我也理解他为什么会语塞，在创始人眼里，创业公司就是要热火朝天啊，就是要996啊，就是要比竞争对手更努力啊，这还用问吗，至于要达成什么目的……没仔细想！
+
+但我还是要问，因为996终究只是手段，而手段必定需要为某个特定目的服务，目的还不明确的时候，手段的有效性是无法评判的。我们靠“理所当然”的常识做决策，往往达不到我们想要的效果，甚至事与愿违，唯一的效果就是阶段性的自我安慰。
+
+高效执行，本身也并不是目的，而是达成特定目的的手段。因此，当我们探讨如何打造高效执行团队的时候，就不能只谈论“执行”本身。那么，要谈论哪些内容呢？
+
+什么是高效执行
+
+为了避免我的个人狭隘，我做了一个公开小调研，当提及“高效执行”的时候，大家第一印象是什么？回复我的有一线员工，有经理层，也有创业者，集中在下面这些词句：
+
+“令行禁止、不拖延，军队”
+
+“多做少说、决定干了就干，别讨论了”
+
+“发奖金、扣工资”
+
+“实施996 997”
+
+“红色性格”（热情、奔放有力量）
+
+“理解沟通”
+
+“时间管理”
+
+“项目管理、过程控制”
+
+“目标明确、收益明确”
+
+……
+
+看到这些反馈，我的内心是崩溃的：即便是背景相对一致的朋友圈，大家对“高效执行”的理解都这么大差异，探讨这个话题是多么有挑战的一件事啊。
+
+好在，人类有一项特异功能是其它动物所不具备的，那就是使用隐喻去提炼问题的核心。于是，我们也借用一个简化了的管理模型：把执行一项任务，看做是把一架马车驾驶到特定目的地，他们都是要带着队伍去达成某个目标。所谓“高效执行”，就变成了如何尽快地到达目的地；而管理者，此时就变成了一名马车夫，他能否快速到底目的地，大体取决于3个关键因素：
+
+1)每匹马用多大力气拉车。
+
+2)多匹马是否步调一致，且往一个方向走。
+
+3)马车是否在有效地朝着目的地方向前进。
+
+用一个近似公式来表示是：
+
+路程
+
+—》速度x时长
+
+—》马车动力x方向有效度x时长
+
+—》单马动力x步调一致性x方向有效性x时长
+
+
+
+对应到团队管理和任务执行中，就是这样三个问题：
+
+1)每位成员的个体能力和努力的意愿。即，个体动力。
+
+2)成员间的组织结构是否合理，协作的节奏是否一致。即，协作水平。
+
+3)大家是否在朝着一个稳定的目标努力。即，目标清晰度/方向有效性。
+
+对应的近似公式是：
+
+绩效
+
+—》效率x时长
+
+—》团队合力x方向有效度x时长
+
+—》个体动力x协作水平x方向有效性x时长
+
+可见，每个公司都希望拥有的高执行力，除了时长这个“简单粗暴”的因素外，个体动力（能力x意愿）、协作水平（默契x机制）、方向有效性（目标清晰），是三个重要的着眼点，我们分别来探讨下。
+
+个体动力和员工激励
+
+我们先来看个体动力。一匹马能出多大力，取决于它的实力，以及使用实力的意愿，即个体动力=实力x意愿，对应到员工就是：能力x意愿。
+
+个体实力的提升，功夫在平时的积累，其提升的方式也各有神通，我们不展开讨论。而意愿的激发，却可以是立即起效的，所以我们看到大部分的管理者都在意愿的激发上做文章，比如发奖金、扣工资等，这就是我们经常说的员工激励。
+
+员工激励是个很大的话题，值得我们关注的是，目前职场上正在经历从驱动力2.0到3.0的转变，即从胡萝卜加大棒的外部奖惩驱动，过渡到以提升自驱力为特征的自主投入驱动，能够发挥优势，以及工作的目标感、成长感、意义感成为激励的重要手段，在员工激励的话题中，我们再展开来探讨。
+
+协作水平和团队合力
+
+是不是每匹马都尽力去拉车了，车就一定跑得快呢？
+
+其实未必，如果几匹马用力的方向不一致，车有可能是不会动的；即便车辆设计非常好，马匹不会出现用力方向不一致的情况，几匹马的步调如果不一致，车速也不是最优。因此，所有马匹是否形成有效的合力，这才是决定车速的最终力量。
+
+团队合力亦是如此，组织架构是否让团队成员往同一个方向努力，以及大家工作节奏是否协调一致，也决定着团队的产出是否高效。
+
+当然，在团队中，两个员工出现往相反方向努力的情况并不常见，但是团队每位成员对一项任务的优先级有不同的理解，却非常普遍。在A手上是第一重要的工作，在上下游团队中的B手上未必是，此时信息同步和整体协调就显得尤为重要，那么，我们是否拥有有效沟通的机制呢？只是靠人的主动性，肯定漏洞百出。
+
+目标清晰度和方向感
+
+驾驶马车的方向感，其实就是一个团队的目标感。大家也许会问，目标设定是规划的范畴，和高效执行有什么关系？我想说的是，脱离目标来谈执行，这恰恰是最普遍存在的问题，这个问题至少会引发了三个不良后果。
+
+第一是激励失效。如果你和一线员工有着顺畅的沟通通道，不难发现引发他们强烈抱怨和失去动力的一个重要原因就是需求变化太快，导致手头上的工作任务频繁切换，带来三个主要的负面影响。
+
+1） 工作反复切换，之前的讨论、评估、设计、开发都变成了沉没成本，员工的挫败感不断累积，而成就感很少。
+
+2） 时间越来越紧，挑战越来越大，员工不得不承担更大的工作压力和强度，引发员工焦虑和负面情绪。
+
+3） 员工认为管理层没有想清楚，甚至是质疑管理层的能力，对公司和团队降低信任，甚至丧失信心。
+
+清晰的目标，本身就是激励，目标缺失的团队和员工，是很难有效激励的。如果大家还有疑惑，你可以盘点下自己过往取得的那些最得意的成绩，回顾一下自己曾经有过的“心流”体验，你不难发现这些好的体验，都有一个共同特点，就是当时的目标非常明确，方向感非常好。
+
+第二是协作失调。明确而认知一致的目标，对于团队所有成员保持统一的工作步调的意义，是非常显而易见的。相反，目标不一致的情况下，让员工保持良好的节奏和状态就变成了奢望。
+
+除了对步调和节奏的影响，对于多任务优先级的判断，也便没有了最核心的依据，此时要想在沟通中达成一致意见，沟通成本非常高，所以才有人反馈高效执行的第一反应就是“多做少说、决定干了就干，别讨论了”、“理解沟通”，换句话说，低效率的沟通也是执行的一大障碍，而目标不清晰必然会导致低效率沟通。
+
+第三是忙乱无效。高效执行，除了速度快，还得有效，所谓有效就是往正确的方向前进，即，离目标要越来越近。
+
+快速执行的现象有两类：一类是看上去很忙；另外一类是真的忙得很有效，其区别，就在于核心目标的达成度。如果目标不清晰，就属于“瞎忙”，这种状态是不健康的。
+
+从以上三个负面影响来看，目标和方向感的不清晰是高效执行的大敌。而这个问题却很普遍地存在很多公司中，却往往不被管理层重视，更常见的情况是——
+
+老板说，我们目标一直都很清晰啊，不就是……，说了多少遍了！
+
+管理者说，这也不是我能左右的……，而且这个时代也没法做长远规划……
+
+员工说，方向总是变来变去……
+
+归结起来就是，要么没目标，要么就是目标不清晰，要么是没有被有效解读和传达。
+
+管理者除了要明确目标，还必须把握该目标的核心衡量指标，即，这个任务最核心的指标是进度（赶时间）、质量（稳定可靠）还是效果（功能完善），只有这个问题明确了，在碰到突发情况的时候，我们才能把握住决策方向，优先满足最核心的期待，让结果更加有效。
+
+结语
+
+总而言之，打造一个高效执行的团队，是一个系统工程，不能只是靠简单堆时间去达到所谓的“高效执行”，因为堆时间可能会让其它要素打折扣，比如员工意愿。当我们去诊断一个团队的执行力问题时，也不能头痛医头脚痛医脚，而要通盘考虑这些要素，从而找到高效执行的最大提升空间。
+
+最后总结一下，高效执行的要素就是：
+
+个体动力x协作水平x方向有效性x时长
+
+（能力x意愿）x（默契x机制）x（目标x沟通）x时长
+
+作者简介
+
+刘建国，TGO鲲鹏会北京分会会员。果见管理工作坊创始人，聚焦于技术背景准经理和新经理的培养。埃里克森国际教练学院教练、国家认证职业生涯规划师、清华大学高级工商管理硕士（EMBA）。
+
+12年互联网从业经验，完整经历从一线员工、一线经理到150人独立部门负责人的全过程，培养出40-50位一二线经理。其中在百度9年，负责过百度知道、百度passport、百度开放平台、百度app1.0、百度手机助手1.0、移动搜索等产品研发和团队管理，百度最佳经理人；创业3年，负责过天使轮到C轮各阶段互联网公司的CTO体系团队。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/014从零开始搭建轻量级研发团队.md

@@ -0,0 +1,97 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            014 从零开始搭建轻量级研发团队
+                            2015年，我加入特赞，带领了一支 5 人的研发团队。那时公司还在天使轮，团队最大的目标是能让产品上线，并证明我们的商业模式是可行的。三个月后，我们实现了这个目标，看到公司第一笔订单产生。随后我们拿到了 A 轮融资，开启了公司新的征程。在接下来的两年中，我们不断开发新的产品功能，不断优化现有产品特性，但似乎总是很难感受到研发和业务之间发生的直接影响。
+
+不久前我们拿到了 B 轮融资，今年是公司的重要转折点，也是公司业务和规模同步增长的重要时期。我认为有必要将团队中一些有价值而有意义的工作做一些总结，希望能给业界朋友们一些帮助，或者给大家带来一种新的思考。
+
+我将从组织架构、研发流程、绩效考核、团队文化这几个方面，与大家探讨如何打造一支高效的研发团队。首先从搭建团队组织架构开始，我们现在就一起出发吧。
+
+矩阵式组织架构
+
+如果研发团队规模大于 10 人，并且希望团队以最高效的方式实现项目交付，不妨采用以下“矩阵式”组织架构（如图 1 所示）。该架构能让团队更加专注，而且整个架构的扩展性也非常强。
+
+
+图 1：矩阵式研发团队组织架构图
+
+我们将横向的“职能团队”比喻为“虚线团队”，将纵向的“项目团队”比喻为“实线团队”。以实线项目团队为主，以虚线职能团队为辅。横纵交错，形成一个优雅的矩阵，横向可扩展，纵向可延伸。
+
+横向的职能团队
+
+根据团队成员专业技能的不同，可划分为多个职能团队，也称为“小分队”，例如：前端小分队、后端小分队、测试小分队、运维小分队等。当然，可根据我们所面临的实际环境，灵活划分出合理的职能团队。
+
+需要注意的是，每个职能团队必须有一名负责人，也就是说，不要让同一人担任多个小分队的队长。因为划分职能团队的目的就是为了将专业技能聚焦，队长的职责之一就是帮助队员们在专业技能上得到成长，为职能团队赋能。
+
+除了前端、后端、测试、运维这类职能团队以外，也可以搭建更有意思的职能团队，比如：技术委员会。
+
+我们需要让团队们都知道的是，能够加入技术委员会的人，都是团队中技术水平最高的人，需要让他们有一种至高无上的荣誉感。技术委员会的成员可能来自于前端、后端、测试、运维，但技术委员会的人数一定是非常精简的。
+
+技术委员会中有一名“技术主席”，也可称为“技术委员长”，他是整个技术委员会的权威，拥有最高的技术决策权，其他成员统称为“技术委员”，他们都是“技术专家”，而技术主席是“首席技术专家”。
+
+随着团队规模的扩展，如果团队中其他队员希望申请加入技术委员会，此时必须得到委员们的一致认可，主席拥有最终决策权。加入的过程可能需要笔试或面试，或者也可以增加一些投票环节，我们可以把这个过程设计得更好玩一些。
+
+除了技术委员会以外，还有产品委员会和设计委员会。产品委员会中的成员往往都是产品经理，当然也可以欢迎具备产品思维能力的工程师们加入，决定权还是交给产品委员会主席来定夺。设计委员会中的成员一般都是设计师，同样也包括对设计感兴趣的伙伴们。
+
+需要强调的是，委员会中的成员，务必确保少而精，而且加入的成员都要有自己的责任。
+
+可见，职能团队包括“小分队”与“委员会”两种形式，不管哪种形式都有一名负责人，即队长或主席，他们是自己所在职能团队的核心，他们的首要职责是帮助成员们在专业性方面得到提升，从而提高整个职能团队的战斗力。
+
+职能团队负责人并非空降或任命，而是由职能团队成员们共同选举。每隔半年，团队全员可通过投票的形式，以匿名选举出自己心中认为最称职的职能团队负责人。也就是说，职能团队负责人是有任职期的，且任职期为半年，他们需要在这半年时间内努力改善自己所负责的职能团队，并努力让团队能得到成长，自己才能得到进步。
+
+现在，我们可绘制一幅职能团队组织架构图（如图 2 所示），我们也可以根据实际情况进行合理设计。
+
+
+图 2：职能团队组织架构图
+
+横向关注人员成长，纵向关注项目落地，下面我们就一起来搭建纵向的项目团队。
+
+纵向的项目团队
+
+在纵向层面，我们还需要搭建一些项目团队，并确保这些项目团队是可以并行工作的，也就是说，他们的工作一般是彼此隔离，不会相互干扰。
+
+在业务发展过程中，难免存在一些实验性工作，业务团队希望研发团队能够快速给出产品方案，并以最快的速度上线且投入市场，通过试错来验证业务的意义。研发团队也希望快速响应业务的变化，以提高产品和技术的价值。因此，我们需要搭建一个称为“功能团队”的组织，该组织的成员将面向业务中实验性的新功能进行快速开发，并确保这些功能可以尽快上线，但质量上却不能打折扣。
+
+另一方面，已经上线的产品功能还需要在业务上不断磨合，通过不断收集用户反馈来持续迭代，才能打磨出一款优秀的产品。我们需要在已有产品功能上进行调优，以不断适应业务的需求。因此，我们需要搭建一个称为“效率团队”的组织，让他们来跟踪已经上线的产品功能，并通过数据和反馈来驱动产品不断优化。
+
+公司主营业务固然重要，对于创新性业务而言，将会为公司带来更多的商业机会。因此，我们可以需要搭建一个称为“创新团队”的组织，它是我们的“独立团”，我们需要为这个团寻找一名称职的团长。
+
+此时，你将得到一幅项目团队组织架构图（如图 3 所示），每个项目团队都有其负责人，每个项目团队可根据实际情况，划分多个项目小组，确保大家都能并行工作。
+
+
+图 3：项目团队组织架构图
+
+需要注意的是，由于项目周期是变化且短暂的，因此每个项目的负责人也是动态的，可能由项目团队负责人来担当，也可能是由项目团队负责人授权一名项目成员来担当，但项目团队负责人需要为项目最后的结果负责。
+
+如果说功能团队的职责是实现产品功能的从 0 到 1，那么效率团队的工作就是完成产品从 1 到 100（如图 4 所示）。
+
+
+图 4：功能团队与效率团队的关系
+
+我们可将实验性的功能交给功能团队来研发，将优化性的工作交给效率团队来跟踪。
+
+队员的选拔也十分重要。功能团队的队员对技术实现能力要求较高，尤其在做新功能的时候，需要考虑对整个系统架构的影响，不仅需要有较高的效率，同时还需确保较高的质量。效率团队的队员对业务理解能力要求较高，当他们对现有功能进行优化时，需要通过业务反馈和数据表现做出正确的判断，指导自己的下一步工作。
+
+当功能团队所负责的项目上线后，他们会将该项目交接给效率团队，随后效率团队将对功能团队的交接情况给出评价，评价结果将影响功能团队的绩效考核成绩。关于绩效考核问题，我将在“绩效考核篇”中进一步与大家探讨。
+
+我们认为员工不应该存在“双线汇报”关系，这样只会让组织架构变得更复杂。因为项目团队才有汇报，职能团队没有汇报，只有培养。项目团队为公司目标负责，职能团队为团队成长负责。换言之，项目团队帮助公司成长，员工可拿到项目奖金；职能团队帮助员工成长，为员工实现升职加薪。
+
+写在最后
+
+对于一支研发团队而言，需要拥有合理的组织架构、高效的研发流程、科学的绩效考核、良好的团队文化。如果缺乏这些方面的建设，研发管理工作将变得痛苦且低效。我们应该做的是，从管理中追求效率，从效率中提升价值。
+
+杰克·韦尔奇曾经说过：Before you are a leader, success is all about yourself. When you become a leader, success is all about growing others.（在你成为领导者之前，成功的全部就是自我成长；当你成为领导者之时，成功的全部就是帮助他人成长。）
+
+现在我想说：当你在赛场上踢球时，你应该考虑做一名优秀的球员；当你成为一名优秀的球员时，你应该考虑做一名优秀的教练。从技术到管理，正是球员转变为教练的过程，我们不能停止前进的脚步。团队的成功，才是我们的成功，我们的职责是给团队赋能。
+
+与君共勉。
+
+作者简介
+
+黄勇，现任特赞科技（tezign.com）CTO，图书《架构探险》作者，Smart 开源项目作者，TGO鲲鹏会上海分会董事会成员，QCon 讲师。十年以上互联网软件架构与技术管理经验，擅长敏捷开发，推崇“轻量级”系统架构。喜欢阅读，热爱交流，乐于分享。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/015定制高效研发流程.md

@@ -0,0 +1,132 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            015 定制高效研发流程
+                            当我们的研发团队组织架构搭建完毕后，接下来需要思考的是，如何让这个架构跑起来、跑得快、跑得稳。此时，我们需要定义出一个高效的研发流程，还要尽可能降低研发过程中所遇到的风险，确保在流程的每个环节中都不能出错。
+
+在定义具体的研发流程之前，我们需要从整体入手，先把研发流程体系架构定义清楚，便于让团队从全局上把控整个过程。接下来需要从局部入手，将研发流程中所涉及的操作步骤罗列出来，便于指导团队完成具体的工作。
+
+现在我们就从整体开始，对研发流程的体系架构进行探讨。
+
+研发流程体系架构
+
+高效的研发过程应该具备“多线程”的特性，仿佛多条并行流淌的河流，上游是业务，中游的是产品，下游是技术，流量取决于业务，流速取决于产品和技术。
+
+需要说明的是，这里的“业务”其实包括两类人：一是公司内部使用产品的业务同事，二是公司外部使用产品的最终用户。为了便于描述，下文统一将他们称为“业务需求方”或“业务方”，简称“业务”。
+
+根据我的上篇文章可知，整个研发工作流程体系架构是职能团队与项目团队的有机结合，团队职责清晰且协作高效（如图 1 所示）。
+
+
+图 1：研发流程框架图
+
+在职能团队中，产品委员会的产品专家们将业务需求统一记录到“需求池”中。需求池中的每一个需求都要描述业务的当前现状，还要包括业务对产品的未来期望。每隔一段时间（一般是 1~2 周），产品委员会将根据需求池中所记录的需求细节加以讨论，并将优先级较高的需求进行立项和排期，项目团队可知晓近期需要实现的业务需求是什么，整个团队的方向感也更加清晰了。
+
+需求池中一个典型的需求可包括以下字段：
+
+需求名称：用一个关键词描述，最多15个字。
+
+需求来源：该需求来自于哪里？包括业务、运营、财务、法务、市场、其他。
+
+业务痛点：为何要实现该需求？即业务当前的现状。
+
+需求描述：该需求具体是什么？即业务将来的诉求。
+
+渴望程度：期待何时可以上线？包括：本周、本月、下月、本季度、下季度、未来、或具体截止日期。
+
+需求类型：包括：新功能（从 0 到 1）、优化（从 1 到 100）。
+
+需求规模：包括：大（两周以上）、中（一至两周）、小（一周以内）、未知。
+
+备注：可写下对该需求的补充或疑问，以便深入交流。
+
+附件：可通过相关文档对需求进行补充描述。
+
+创建人：该需求被谁创建？
+
+处理状态：包括：未处理（默认）、处理中、已处理、关闭。
+
+优先级：包括：A（重要&紧急）、B（重要&不紧急）、C（不重要&紧急）、D（不重要&不紧急）、X（待定）。
+
+负责人：该需求由谁跟进？
+
+简单情况下，可使用电子表格的方式来维护需求池，比如：Numbers、Excel 等，当然也可通过在线方式来管理，比如：石墨文档、金数据等。
+
+需要注意的是，需求池对公司全员共享，由产品委员会管理并维护，其他人员只能阅读但无法编辑。产品专家们首先需要和业务需求方进行有效沟通，深刻理解他们的业务痛点与未来期望后，才能将这些需求入池。
+
+从需求池中挑出的高优先级需求将分别“流入”对应的项目团队中，在项目的执行过程中难免会遇到技术上的遗留问题，然而团队不希望因为这些问题而导致项目工期受到影响。因此，这些技术遗留问题将被列为“技术债”，技术委员会中的技术专家们将对这些技术债加以管理和跟踪，在后期会有针对性地解决这些技术问题，偿还这些技术债。
+
+了解了研发流程体系架构后，下面我们进入具体的研发流程操作步骤。
+
+研发流程操作步骤
+
+将需求转化为项目，是一个复杂的过程，如果只是一个体系架构，恐怕也只是空中楼阁，因此我们有必要对整个研发流程体系架构进行细化，为其设计具体的操作步骤，以便让整个流程可以顺利落地。
+
+我们可定义了以下 10 个操作步骤，将需求转化为产品，将产品转换为项目，将项目顺利上线（如图 2 所示）。
+
+
+图 2：研发流程操作图
+
+以上 10 个阶段，涉及到不同角色的人员，每个阶段需要包含当前所需完成的任务，也涉及到相关例行会议。我们可将这份操作步骤打印下来，发给每一位研发人员，并贴在会议室的墙壁上，每日站立会的时候，团队都能看得见它。我们会慢慢发现，每个项目团队都有相同的工作习惯，大家还可不断优化这份操作步骤以及其中的相关细节。
+
+需要注意的是，产品经理在需求调研阶段，必须了解业务的当前现状，搞清楚业务痛点是什么？我们不妨这样做业务调研：如果没有这项功能，业务同事需要花多长时间、多少人力来完成自己的工作？当前的获客成本是多少？订单转化率是多少？产品经理需要将这些信息和数据记录下来，并丰富到需求池中。此外，在每次启动项目之前，需要得知该执行项目的目标是什么？如何来验证这个目标？
+
+我们需定期对已上线项目进行复盘，可通过“复盘四步法”来完成：
+
+审视目标：当初设定的目标是什么？目前达成的现状是什么？差异是什么？
+
+回顾过程：回顾整个过程是如何进行的？大致分为几个阶段？每个阶段发生了什么？
+
+分析得失：哪些方面做得好？哪些方面做得不好？为什么？
+
+总结规律：再次做同类事情应该怎么做？对未来工作有何指导？有何规律、原则、方法论？
+
+使用以上项目流程与复盘方法，可确保以正确的方法将事情做正确。但是，只能解决研发内部的闭环问题，似乎无法解决研发和业务之间的外部闭环问题，也就是说，研发和业务之间的高效协作问题还需进一步探讨。
+
+研发与业务如何协作？
+
+这个问题也许在许多企业中会存在，毕竟业务和研发的工作性质不同，关注点也不同，因此考虑问题的方式也会不同。
+
+业务心中可能会这样认为：为何我们提出的需求，研发总是迟迟不解决？
+
+研发心中可能会这样认为：为何我们上线的功能，业务总是迟迟不反馈？
+
+我们似乎遇到了一个“死锁”问题，彼此都在等待对方。业务提出需求，得不到及时响应；当研发响应后，却得不到反馈。久而久之，业务和研发之间会失去信任，从而严重影响企业的可持续发展。
+
+这里我向大家介绍一种新玩法，它能让业务和研发得到更好的闭环，而且让双方的协作过程变得更加顺畅。我们称这个方案为“特赞之声”（如图 3 所示）。
+
+
+图 3：特赞之声
+
+在公司内部，我们制作了一种叫做“特赞币”的虚拟货币，其实它只是普通的磁铁，币上贴了一个自制的图案而已。我们给业务部门发放固定数量的特赞币，为了避免“通货膨胀”现象，我们一次性不会发太多币，后期可根据实际情况适当增发。
+
+当业务部门遇到痛点时，可在痛点卡片上手动填写具体痛点，并用特赞币将卡片固定在白板上。此时需要消耗一个或多个特赞币，如果一次性使用多个币，表示优先级更高。项目上线后，当业务部门提供使用反馈后，将得到一个特赞币，提出的反馈包括对已有功能的称赞或吐槽。
+
+也就是说，提需求要“花钱”，提反馈可“赚钱”，这样可确保业务所提需求都是最大痛点，由于币数是固定的，因此需要通过提反馈来获取新币，这样研发和业务自然就建立了有效循环。
+
+除了痛点和反馈以外，公司全员也可以提出脑洞，也就是对产品的奇思妙想，脑洞被产品委员会采纳后，可赠送一定数量的特赞币。痛点会使用特赞币将其吸附在白板上，反馈和脑洞可使用普通磁铁来固定。
+
+使用特赞之声，我们得到了以下收益：
+
+业务人员：业务痛点得到更好的重视，得以更快速地解决。
+
+研发人员：产品价值得到更好的体现，产生更高的成就感。
+
+彼此双方：业务与研发不再孤立，从而形成了完美的闭环。
+
+写在最后
+
+没有人愿意在一个复杂的流程上投入自己更多的时间，流程是帮助我们更规范地做事情，目的是避免犯错误。因此，在流程的定义上，我们可以先简单后精细，简单才便于操作，精细才易于管理。
+
+以上我们提到的研发流程十步骤，对于大家而言只是一个参考模型，大家需要根据自身实际情况，作出合理调整，流程才能发挥出最大的作用。否则，它可能会变成一种负担，反而约束了我们前进的速度。
+
+研发流程是团队的行动规范，是大家共同智慧的沉淀，流程高效，产出才能高效。
+
+作者简介
+
+黄勇，现任特赞科技（tezign.com）CTO，图书《架构探险》作者，Smart 开源项目作者，TGO鲲鹏会上海分会董事会成员，QCon 讲师。十年以上互联网软件架构与技术管理经验，擅长敏捷开发，推崇“轻量级”架构思想。喜欢阅读，热爱交流，乐于分享。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/016培养中层团队的管理认知.md

@@ -0,0 +1,59 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            016 培养中层团队的管理认知
+                            技术团队到达一定规模之后，要保持高效，中层管理者会变得非常重要。他们在团队中起到承上启下的作用，既要接受上层的指派，又要领导下层执行。如果中层管理者给力，上层的管理者会轻松很多。所以一定要选对中层，培养中层。
+
+先做目标管理
+
+在说中层团队的选拔和培养之前，先来说说我选择公司或者职位的理念。首先，我要去了解这家公司的目标是什么，我个人非常关注目标的选择。目标选择的好，就比较容易成功。反之，个人和团队都会比较辛苦，结果还不一定好。有了一个合理的目标之后，剩下都是一些执行层面的技巧，我很清楚如何去带领团队达成一个目标。
+
+举个例子，我之前在盛大集团刚开始负责整个测试团队的时候，当时CEO觉得测试团队不能满足公司的期望。测试团队一般有两个指标，一个是速度，另一个是质量。其实不只是测试团队，绝大部分团队都是这样，很多时候这两个指标的实现上存在一定的冲突。
+
+我意识到公司对测试团队的期望是速度能更快一点，避免因为测试花掉太多时间，而导致产品上线的延迟。当时的测试团队把过多注意力放在了测试质量上，时间用的比较长。
+
+我做的一个最主要的改变，就是让整个测试团队了解我们真正的目标是什么，把原来以质量为重的目标，变成了质量和效率兼顾的目标。目标修改了之后，整个测试团队对公司业务的支撑就改善了很多。不到一个季度的时间，整个公司都感受到了测试团队的涣然一新。这是通过目标的选择和调整，让团队表现更好的一个例子。
+
+在盛大在线的时候，我曾经带领数据团队做数据算法的研究，大概用了两个季度左右的时间，把我们广告的推荐算法优化，让整个点击率和广告收入提升了大概一倍。利用这个案例，我分享一些管理经验。
+
+很多时候我们团队在做事情时可能会忽略一些东西，从而导致整个进展不够顺利，我要做的是帮助他们把事情理顺。那时候的实际情况是，团队已经在广告算法上探索了很长时间，但是一直没有很好的产出。我接手之后，比较全面地去了解了导致团队进展慢的原因。我发现了几个问题：一个是当时数据的准确性是有问题的，原始数据的准确性不够，导致我们被数据误导，结果自然不会很好。
+
+另外，在广告算法提升场景上，我们也是做了一些判断。很多人在做算法的时候，会有些假设，很多时候我们认为某一个用户的唯一标识代表的是一个用户。其实在实际情况中，你应该想到，有的电脑白天是先生在用，晚上是太太在用，有一些类似这样的情况。后面我们基于这样的假设再去提升整个推荐算法，效果就会比较明显。
+
+我想用这个案例告诉大家，有些目标达成过程中会出现一些困难，要能够全面的思考可能是哪里出了问题，问题解决之后，才会获得比较好的进展。
+
+根据需要选管理者
+
+在中层团队建立起来的时候，我会把这些亲身实战的管理方式传达给我的中层管理者。我现在的团队大概有五、六个中层管理者。每一个细分的团队都有各自的Manager，包括运维团队、后端开发团队、移动端开发团队、测试团队等。
+
+我是如何选拔中层管理者的呢？首先，我觉得很多时候不要去谈这个人是否是一个管理者。有时候一件事情需要很多人共同完成，也有些简单的项目开发只需要一个开发工程师。只有当你需要有些人把某个团队的整体能力或者整体工作效率提得更高，才应该去考虑选拔一些偏管理型的人才。
+
+一线工程师需要做实际的工作，但是管理者更主要的目标是用各种手段帮助一个团队更好地提高产出，或者说提升整个团队的能力。我属于一个非常关注目标的管理者，围绕这个目标，我们会去了解是不是有合适的人来做管理者。如果内部有些合适的人，就会内部提拔，如果内部没有太合适的人，我会考虑从外部招一些管理人才，让他们来帮助我把团队的产出和整个技术能力提的更高。
+
+很多管理者比较关注选拔中层管理者的通用标准，我认为不存在通用类型的中层管理者，也就没有通用的标准。关键还是要结合团队当时的情况，选拔最需要的管理者类型。
+
+大多数时候，不同的团队需要的管理者都是不一样的。有些团队面临的问题是，由于经验不足导致很多东西做不了，大家都不知道应该怎么做事。在这种情况下，就不能找一个通常的人员管理能力较强的管理人员，而是需要一个过去做过类似事情的人，他只有在做这种类型的事情上有经验，才能帮我解决问题。另一些团队遇到的问题是内部沟通不够顺畅，激励机制不够顺畅，导致大家士气低落，这种情况下，我要找的管理者就偏向于更擅长人员管理和沟通的人。
+
+做好教练
+
+管理者选好之后，接下来才是培训。对任何中层管理者，首先，我一定会跟他们分享我对管理的认知。很多管理者对管理的目标、职责以及常用的管理方法还不太了解，其中包括管理的职责是什么，最主要的目标是什么，常用的管理手段是什么等问题。
+
+一旦有了这样的认知，在一些具体的操作细节上面，他们才会有管理的概念，他们会在日常工作中实践一些东西。如果在实践的过程中遇到了问题，我会进一步跟他们一对一沟通，分享一些精髓。主要是让他们对自己的职责和大的提升方向有一个比较清晰的认识。然后，在日常工作中会根据实际案例、实际情况分享在不同的情况下应该怎么采取管理手段。
+
+中层管理人员的时间分配也是大家比较关注的问题，我认为这个事没办法固定。还是那句话，不同团队情况不一样，有些团队人员比较少，内部沟通也比较顺畅，不需要花太多时间做人员管理，这时候我会要求管理者直接做一些技术方面的事情，提升架构能力，或者做一些产品的方案设计。让他们利用过去的经验，帮助团队少走一些弯路，让整个的团队产出更好一些。
+
+有些团队可能在具体的业务技术经验方面还可以，主要是内部的沟通不够顺畅，这种情况，我就会希望他在人员管理方面投入更多的精力。
+
+结语
+
+最后，我还是要强调一下目标管理的重要性。不管管理什么样的团队，我首先会做的就是帮团队管理一个目标，让所有人都能理解这个目标。对于应该用什么方式为这个目标努力，我也会有比较清晰的设置。在设置完目标之后，我使用的是偏教练式的管理方式，也就是说，极少情况下我才会真正代替他们做事。更多时候是以教练这样的角色，了解他们在完成目标过程当中会遇到的困难，然后通过启发式的提问，让他们意识到他们应该做怎样的改变，才能够更好的完成目标。
+
+作者简介
+
+陆怡，医信金融 CTO，TGO鲲鹏会上海分会董事会成员。20年以上的技术团队管理经验。曾在盛大，eBay 中国研发中心任职技术高管，管理过各种类型的技术团队。2013年作为技术合伙人，和朋友共同创立维金公司，提供互联网金融的解决方案和系统服务。从零开始组建产品技术团队，团队人数最多时接近 200 人。维金先后获得IDG和蚂蚁金服的投资。目前出任医信金融CTO，全面负责产品和技术工作。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/017团队成长要靠技巧和体系.md

@@ -0,0 +1,89 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            017 团队成长要靠技巧和体系
+                            谁都希望能够有一个牛逼的团队。但创业公司前期资金少，不可能全员都是牛人，所以也会引入一些在能力上刚刚合适或有一定潜力（比如实习生）且认同公司价值观的人加入，先让业务跑起来，再来优化结构。
+
+从HR的角度，所谓优化，就是补短板，或许直接换掉来得更快，但作为早期加入有过苦劳的员工，这样太不公平。所以提升团队成员，让他们与公司一同成长才是团队领导者第一选择。
+
+实战，毫无疑问是最快的提升方式。项目的压力会让一个人的潜力快速显现出来。但是时间过长且过大的压力会让人疲劳，所以除了实战外，我们应该还有一些技巧和体系来帮助团队成员成长。
+
+如何来引导他们的成长方向
+
+一个成熟的公司，会清楚的知道他们需要什么样能力的人才，所以根据公司的实际情况，构建一个清晰的JobModel（能力模型），规划出不同层级的核心能力、通用能力及标准，可以对团队成长有较为明确的指引。
+
+以二维火为例，一个JAVA工程师，他的核心能力为：
+操作系统、编码基础，JAVA，网络协议、网络安全、数据库、架构设计、运维能力等。JAVA这一项再分解成：
+
+
+Java语言基础：异常处理，泛型，reflection，annotation;
+Java基本类库：io, util
+Java高级特性和类库：class loader，bytecode，nio, juc 等
+Java多线程编程
+Java网络与服务器编程, TCP/IP协议
+Dubbo
+开源产品和技术
+JVM原理和调优
+
+
+每一项能力需要有三个等级的评定：
+
+
+第一级是会用，有过三个到五个项目经验，对正常的语法、概念、配置、部署等方面有正常的认识；
+第二级是熟练，有过十个项目以上的经验，能够指导他人进行工作并解决问题，同时阅读过源码；
+第三级是能多深入源码，能够做较为低层的优化。当遇到无法解决的问题，能够通过修改源码甚至更换技术及框架来解决。
+
+
+将来在对团队进行评级时，可以通过多个项目的代码来看出他对这项技术的掌握程序。同时这些能力和等级都会引导团队更加深入的对相关进行系统性研究。
+
+文化和学习氛围比培训更重要
+
+2012年曾经有幸加入过支付宝技术大学，在这半年当中，除了建立了内部的培训和分享机制外，深刻的体会到，培训和技术分享本身带来的效果是非常有限的，在团队内部营造一种人人爱学习，乐于分享的氛围，建立一个持续学习的文化，才能让团队更快成长。
+
+当然，培训本身的设计与实施也是非常重要的，例如阿里内部的三板斧、AMDP、青年禁卫军等体系化的培训，能够批量提升技术和管理意识并学习到一些技巧。
+
+培训的设计应该考虑到不同层级，不同岗位对能力的要求，不可能一项培训提升所有能力。以下介绍二维火的两项内部培训设计：
+
+火种计划：是针对每年实习生和应届毕业生组织的培训，里面会从非常基础的编程技巧、项目流程、各种工具的使用和企业文化等相关内容，最后还会有一个一周的练习，大多是一些内部系统的开发，顺便还能提升一下内部生产力。培训结束后，这一期的小组不会解散，会继续以民间小组的形式维护这个系统。
+
+我2014年加入二维火，当时团队只有20人左右，急缺高层级的技术人才，但我们还是在当年年底做了一轮校招，招聘了5名实习生，并组织了第一次火种计划培训。当时团队也有人认为，业务已经忙不过来了，还要分出精力来带人，是不是划算。但是当这些实习生陆陆续续毕业并加入正式的项目组，解决了我们半年后的人才招聘问题。2015年我们招聘了一名硕士实习生，实习半年就是项目主力，等到他毕业直接以P6（高级工程师）入职，今年夏天有望晋升P7（架构师）。
+
+管理培训（初级、进阶）：针对主管、经理层级的管理人员进行基础的管理技巧培训，从组织结构设计、岗位模型、招聘技巧、授权、激励、绩效管理等多个方面进行深入的培训，后期所有的技巧都会由上级主管记录应用的过程，定期探讨。
+
+很多技术高手没有得到专业的管理培训就直接上岗，往往连最基本的管理技巧也没有，只有粗浅的项目管理知识，这样带出来的团队一定在某些环节上出问题。
+
+举个例子，有一名主管经常会在团队周会或办公区批评团队成员，这样给团队成员的自信心打击非常大。人都是感情动物，都会要面子。而激励讲的就是如何提升团队士气，奖励一个人需要在公开场合，而批评或指出问题需要在一对一的时候，这样效果才好。而奖励和批评都要具体到事例，不能空泛，同时事例经得起团队认可等等。
+
+所以后面我们在挑选出团队管理者的时候，一定要经过各种管理知识的培训，另外需要更高级别的主管进行长期的辅导，才会正式任命，保证公司在团队管理上少出问题。
+
+除了专业培训外，其他的培训例如一些通用能力，包括项目管理、沟通技巧、时间管理、会议管理等，可以多在公司内部挖掘一些讲师，给予他们一些额外的鼓励。
+
+另一个对学习氛围有提升的方式是分享，尤其是内部分享，对一些较新的团队成员来说，是一个可以直接答疑解惑的好机会，而外部分享可以帮助团队成员去了解同行在领域中的技术应用方式。目前我们每个月都会和一些非常优秀的公司进行交流，比如同在杭州的有赞、又拍云、上海的饿厂等，都给团队带来了非常多的益处。
+
+同时公司还鼓励参与外部专业认证培训，例如PMP、以及一些云厂商提供的培训，报销所有费用。
+
+最后再说一项建立培训和分享机制的好处，就是在招聘方面会有好的口碑，更容易招到有潜力的新人。
+
+从绩效上给予激励和鞭策
+
+如何帮助和鼓励团队成员成长呢，人都是有惰性的，或者很容易陷入具体的工作中。
+
+这个时候作为团队的管理者，要为每一个团队成员做好职业规划和能力提升的规划，定期review。绩效考核相信一定规模的公司都会用到，在这里建议把员工的个人成长放进绩效，当能力有提升时，给予一些实际的奖励。
+
+提升的表现可以分为两个方面，一是应用在实际工作中，二是给团队做了一次成功的分享，都可以做为加分项，并告诉他这会做为将来晋升时的参考。同时也是在帮助他在公司内部建立自己的影响力。
+
+如果没有做到，也要有相应的惩罚，来提醒他成长已经停滞，当成长速度低于公司和团队的成长速度时，会被淘汰，要做到丑话当先。
+
+随着业务跟技术发展，研发具有技术挑战的系统平台，激发团队成员的潜力与热情，避免一直只做业务开发，技术成长慢，让他们取得技术成就感。
+
+最后，给所有的技术管理者分享一个心态，很多管理者担心自己培养了很长时间的人才一两年后就跳槽走了。实习生成本方面比社招要低很多，你的成本其实已经收回了。也不要因为培养出来的人跳槽，就有了是不是给其他公司当了培训班的心态，其实这反而可以扩展你的团队在行业中的影响力，还有可能带回来一些人，同时也让我们反思给这些子弟兵的待遇是不是符合他们的成长。
+
+作者简介
+
+芦宇峰，花名红烧肉，前支付宝用户技术部/技术大学负责人，《旅途求助》创始人&CEO，现任二维火产品研发中心副总裁， TGO鲲鹏会杭州分会会长。首席按摩师，美腿控，健身无效达人。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/018做到这四点，团队必定飞速成长.md

@@ -0,0 +1,92 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            018 做到这四点，团队必定飞速成长
+                            如何激发团队的斗志？
+
+如何促进团队成员的成长？
+
+如何帮助团队成员设定工作目标？
+
+我相信这几个问题一定反复困扰着每一个团队的牵头人。方法很多、理论也不少，从KPI到OKR，每个都是很多企业和团队实践的经验，但从我十多年的团队管理经验来看，这些方法和理论其实有一个共同的内核：摸清禀赋、认清目标、扫清障碍、列清奖惩。
+
+摸清禀赋，力求人和事的匹配
+
+摸清禀赋是第一步，我相信孙子兵法的“知己知彼，百战不殆”是众人皆知的古训。西汉晁错的《上书言兵事》也提到“ 卒不可用，以其将予敌也； 将不知兵，以其主予敌也”， 所以作为团队牵头人，摸清每一个团队成员的性格、能力甚至是健康和家庭状况，是帮助团队成员成长的第一步。摸清了成员的禀赋，也更有利于团队的分工，帮助成员找到合适的角色和位置。
+
+一般来说，我们总能将一位同事从几个角度来评价，不管是 MBTI、九型人格还是近年流行的DISC，其实都在做同样的事情——摸清团队成员的禀赋。
+
+我们也可以加入更多的角度来评估我们的团队成员，思维方式更有广度还是更有深度、主动创新还是按部就班、聪明异常或是勤奋过人 、坚韧专注还是勇于探索，擅长哪些领域，熟悉哪些工具和技能。团队所从事的具体每项工作和事务，同样也可以从几个角度来分类，就像我们不太会赶鸭子上架，让一个设计师去写数据库的代码一样，“专注执行不容错型”和“勇于创新敢于试错型”显然也需要不太一样的成员。
+
+工作的特性匹配了成员的特质，至少可以避免时间、人力和资源错配导致的浪费，也为团队的组建、短板的补强提供了方向。
+
+讲到人的禀赋和事的特性匹配，这里还要提醒一下各位技术团队的牵头人，一定要和HR同事密切沟通，是不是要招人、招多少人、招什么样角色的人、补强短板还是建立优势壁垒、是不是需要空降一个牵头人，都需要和HR同事有统一的推演和规划；也千万不要轻视职位要求定义、面试筛选、背景调查的流程，哪怕是内部转岗最好也需要经过面试的过程。面试、背调就是一次全面摸清禀赋的过程。一千个人眼中有一千个哈姆雷特，HR同事的视角和经验，也是很好的禀赋评价或分类的角度。
+
+认清目标，规划合理的成长路径
+
+如果说摸清禀赋更多的指成员的现状，那么认清目标讲的就是筹备未来。
+未来当然也包含两层含义：成为什么样的人，做成什么样的事。事是团队乃至企业的目标，要由团队成员来执行；成为什么样的人，就是个人的成长目标，来自于工作、学习乃至生活中的磨练。
+
+大家都大致了解“一万小时理论”，但是往往忽略了这里的“一万小时”指的是刻意实践所累积的时间，而不仅仅是打发消磨的时间。看一万小时电视剧并不能让人变成著名演员、编剧或导演，甚至连成为影评家的概率都很低，因为那不是刻意的实践而仅仅是打发时间。工作显然是一段带有刻意训练特征的时间消耗，虽然很多工作是出于谋生养家，但是花同样的时间、赚同样的钱，人总是希望做一些有助于成长目标、让你自己获得成就感的刻意训练。
+
+和团队成员一起深入沟通，找到一个既能帮团队做成事、也能帮助成员个人获得训练积累成长1万小时的目标，显然变成了重中之重。
+
+找出个人的成长目标一般分三步：找寻榜样，自省差距，分解突破。榜样可以是身边更出色的前辈，也可以是业界的大牛，甚至是几个实例的综合体，自省差距往往也可以和摸清禀赋结合在一起，然后从众多的差距中找到一个相对好入手、好训练、有助于成事的点，进行突破。
+
+例如，对于一个软件工程师，写代码并调试就是一个带有刻意训练性质的本职工作，降低代码bug严重程度、提高代码和需求匹配度，就是不错的训练目标。突破的了代码质量的成长目标，也许代码中的逻辑严谨性或者代码编写的全局思维就是下一个需要突破的目标。
+
+关于目标设定，我相信大家也都熟知目标设定的S.M.A.R.T原则。一个好目标一定具有：S特定领域、M衡量方法、A实现路径、R所需资源、T时间范围 这五个要素。
+
+这里我尤其想提醒大家近年来管理学界的一些补充：R 字母更有指导意义的解释是达成目标所需要的资源 Resources ，这一观点在2013年 由John Lawler 和 Andy Bilson 提出 ，显然这个解释优于之前和实现路径 (Achievable) 含义相近的若干单词“Relevant 相关的” 或“Reliability可靠性”或 “Realistic 现实的” 或“Reasonable合理性”。
+
+一个团队成员除了自身的能力、经验和人脉这些内部潜力外，最大的外部资源往往来自于团队其他成员的互补、来自于团队牵头人更丰富的阅历、经验和人脉。
+
+扫清障碍，扶上马还得送一程
+
+认清了人和事的大目标、分解逐个突破的小目标后，我们已经能够和团队成员一起设计出一些可行的路径，也许这条路径并不完善，还需要不断修正，但是至少这时，团队成员可算是在成长快速道路上入了门。接下来团队的牵头人，要做的一件事就是帮助成员一起扫清路径上的各种障碍，俗语也叫“扶上马还得送一程”。
+
+送一程干的事情无外乎卸包袱、供粮草、 共填坑、调节奏、把方向之类。
+
+合理的分配任务，尽量排除偏离个人成长目标（但是可能适合其他成员）、又耗费工时的工作事项称为卸包袱；
+
+提供攻坚所需的关键性的数据、硬件甚至是经费称之为供粮草；
+
+遇到困难和棘手问题，作为牵头人自己不能退缩，不能甩锅，甚至要敢于背锅，授权成员去试错，要和成员一起战斗，这才是共填坑；
+
+因为企业的经营环境、团队的工作环境和个人的生活环境会不断变化，所以往往大目标不变的情况下，小目标却需要因应调整，及时调整前进的步点和节奏，才能不为环境所累；
+
+环境的重压之下，节奏不断变换，团队牵头人还需要提醒个人成长目标和做事的初衷，避免为了成事而疲于奔命，一起把握既定的大方向。
+
+在成长之路上提速的整个过程，也和驾驶手动挡汽车起步提速一样，踩离合（也就是卸包袱）、给油（也就是供粮草）都必不可少，坡起时还要借助刹车（也就是共填坑），即使右手不断换挡（也就是调节奏），也要紧握方向盘目视前方（也就是把方向）。
+
+另外不得不提一句，如果团队的牵头人，并不享受带领团队成长“扶上马送一程”的过程 ，也不认为成为一个好的团队牵头人是自己的成长目标，那么请大胆的告诉你的领导，你更适合技术专家、科学家、架构师的角色，请婉拒团队的管理者、牵头人的任命，请不要把你自己的刻意训练时间累计在你不想要、不享受的目标上。
+
+列清奖惩，用惩罚警示，用奖励提速
+
+对于快速成长的团队，奖惩也要列清，尤其要避免功过相抵的糊涂帐。团队成员和团队牵头人一起设定的目标，既是承诺也是对赌；甚至因为团队成员的小目标和团队的大目标往往天然交织在一起，一个人的工作瑕疵就会拖累其他成员乃至整个团队；因此奖惩不仅仅是物质上的得失，更多是一种仪式，奖是仪式上的凯歌，惩是仪式上的警钟。
+
+在对具体的成员进行惩罚之前，请各位团队牵头人先自我检讨三个问题：
+
+我是不是足够了解这位犯错的成员，包括这位成员最近的健康、家庭等外部环境变化？
+
+我有没有错配人和事，让成员从事了既不胜任亦不享受的工作？
+
+我有没有帮助成员找到明确的目标和清晰的路径，并在路径上做好保障？
+
+如果这三个问题中，有任何一个问题的答案是否定的，那么请先检讨你自己的工作缺位。甚至对成员个人的惩罚有时也不需要处罚金钱，也不需要记过存档，而仅仅需要的是集体复盘、自我检讨，然后修订目标，制定改进计划，让成员知耻而后勇、避免再犯。牛奶已经因为错误而泼出，与其纠结如何惩罚既成事实，不如把亡羊补牢、改进未来作为一种惩罚方式。
+
+关于奖励，也请告别庸俗的纯物质奖励，金钱固然好，但是并不一定是团队成员需要的，因此和HR一起，设计更有温度的奖品，会让成员更有归属感和求胜欲。
+
+我个人和我们公司非常不推荐长期执行闭关冲刺这种不健康的、错将时长当效率的工时制度，但是在团队成功的完成短期闭关冲刺的交付目标后，集体休个小长假就是团队最需要的奖励；将奖品奖金和团队的谢意，直接寄送给获奖成员的家人，让军功章的另一半一起分享成员的成就，让成员在家庭获得认同，也是一种有温度的奖励；忽略年龄和资历的桎梏，给予充分的授权，允许年轻的杰出成员，独立带领一支年轻的新团队，给予年轻人更重的责任和更深的信任，也是很好的奖励；帮助成员完成梦想，哪怕是资助成员停薪续保去留学深造、去创业，更是一种有温度也有气度的奖励。
+
+人在工作和生活中主动或被动的扮演很多的角色，但是趋利避害、改善境遇是共通的发自人性的需求。如果说“己所不欲，勿施于人”是一种不作为，那么“人己共欲，施之援手”就是一种共赢的主动选择。带领团队快速成长，靠的一定不是鞭子，而是每个成员各自所需、且无法拒绝的果子；找到那颗果子、那棵果树，规划前往果园之路，这条路才会是有助于成员成长的高速公路。
+
+作者简介
+
+洪倍，AdMaster创始人兼首席技术官，TGO鲲鹏会上海分会会员。毕业于上海交通大学，于2006年与闫曌共同创立AdMaster。拥有超过13年大数据产品构架、挖掘、处理和创新技术研发经验。带领AdMaster研发团队，架构了国内领先的涵盖广告监播、社交聆听、电商渠道及移动应用等多种数据源的营销大数据采集和处理集群。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/019将企业打造成一所终身大学.md

@@ -0,0 +1,153 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            019 将企业打造成一所终身大学
+                            我们可能经常会遇到一种情况，团队成员突然有一天跑过来，跟我们说：
+
+
+“我学不到东西”
+“我已经都会了”
+“我感觉没啥成长”
+“每天都在重复劳动”
+
+
+……
+
+接着就是，“我想离职，换个环境……”
+
+团队成员的成长是一直困扰管理者的问题，今天我们就一起简单讨论学习一下。
+
+成长的定义
+
+我对成长的理解就是通过自己的学习和工作，在一个环境里，和组织一起互相扶持，发挥自己的价值，同时也创造价值，得到反馈，不断积累的一个过程。过程中会有坎坷，不断克服困难，放空自己的心态，接受一切挑战，并最终朝着一个既定的目标前进。整个过程中充满了乐趣和成就。
+
+团队成员的成长一开始更偏基础实际一点，而随着经验的增加，诉求会更多元，也更偏上层务虚一点。
+
+新人刚加入团队的时候，我们会有一套帮助他着陆的方案。包括公司历史，文化，价值观，公司内部的技术框架，公司业务，最佳实践等。随着员工的成长，会给他更成体系的培训，并有日常的经验分享。对于公司核心人才或高管会有管理咨询培训，并且有创业营计划，在带领团队打仗的过程中不断成长。
+
+在务虚方面，我们每周三会组织一个管理会，将20多个技术负责人聚在一起，大家讨论和产品技术无关的话题，讨论关于人的问题。有的时候采用分享的方式，有的时候采用分组讨论的方式，有的时候采用集体共创的方式。互相扶持着成长，经验和想法交流，帮助某位同学解决问题，用集体智慧共同解决公司问题。
+
+企业本身需要打造成一所终身大学，含有各个学科，可以永不毕业，每个人都能一直深造。
+
+管理者可以做什么
+
+管理者需要和员工一起定目标，拆成多个阶段，定落地方案，并阶段性给出反馈结果。过程当中我们采用共创的方式，达成共识，充分尊重团队成员的想法，而管理者在当中教的最重要的是学习和工作方式。
+
+目标
+
+目标要清晰，可度量，限定时间，包括工作和学习。在定目标前，我们会先调查现状，并和团队成员在目前现状上达成共识，接着一起定目标，并充分尊重团队成员的意愿。我们年初时会和各业务团队定好目标，并分解到季度，每个季度会重新review，并及时调整目标。每个团队技术负责人会和各团队成员定成长目标，每个季度都会有到个人的oneone review。
+
+落地方案
+
+目标会分阶段实施，每个阶段先大致定个目标，再不停迭代优化。这个时候，会再讨论什么是最重要的，最紧急的，用户到底需要什么，未来会是什么样的，用终局来看当前，寻找最合适的方案。
+
+反馈（Review）
+
+人往往都需要监督，给出反馈，才能不断优化。首先鼓励团队成员自我总结，反馈，其次从专家和教练方向，督促他，给出管理者的反馈意见。
+
+工作/学习方法
+
+我们经常会说：“这个人不行，思路不对”，其实是这个人的学习方法，工作方式不对，我们给出指导，给员工机会让他成长，如果实在不行再淘汰。
+
+工作方式要有框架性或整体思维，落地时分阶段落地，得到结果，为下一阶段提供准备。细节决定成败，在落地过程中要关注细节，但如果代价太高，需要权衡。得到的结果要有价值，只有苦劳，没有功劳，是得不到成长的。
+
+学习方法我自己分为快速学习，系统学习，深度学习。快速学习是了解一个新领域，如果想进入就先系统学习，如果自己操刀就需要深度学习，成为专家。
+
+我们看一个实例：我们一个中台开发年度目标移动端推送打开率，推送打开人数/DAU提高绝对值10个点。
+
+这位同学一开始比较抵触，说推送这个主要看推送的内容用户喜不喜欢，这是运营团队的事，是各业务线的事，我不能背这指标，我只能负责推送的达到人数。当然推送的到达人数多了，打开率就会高。但是这对于他的成长，价值是有限的，我们描绘了这件事给他的未来的成长空间，怎么去赋能业务，怎么去跟踪数据，怎么去做个性化，怎么去倒逼业务，怎么去利用资源等等。如果你都把这些事情做好，数据会不会增长，你自己会不会比你一开始提的目标得到更多的成长。
+
+这位同学回去后立马对目标做了分解，Q1做达到人数，Q2做推送数据可视化，Q3做特征模型训练，Q4做货币化（和业务结算资源），并对工作做了详细拆解。每个Q下来我们会对结果做Review，并且把所有业务团队对接人一起叫过来，真正从用户角度review，收集反馈。而我们只是教练角色，从工作方式上给予指导。
+
+成长来自于实践, 不会一帆风顺
+
+成长过程中，会遇到很多的挑战，很多新事物，直观的感觉是排斥它，这样无法成长。有首歌是这么唱的，不经历风雨，怎么见彩虹，没有人能随随便便成功。而作为管理者，给团队成员更多的机会，让他们去锻炼，不要担心他们会失败，但也不要袖手旁观。有些leader在管理时就直接放手，只管结果不管过程，导致团队成员一次次失败，更打击了他们的积极性。有人会问在什么时候给出帮助呢？
+
+
+他向你求助时
+阶段性看过程时
+
+
+不管是工作，还是学习，都要和团队成员进行阶段性review，在review时要给出帮助。
+
+
+解决紧急问题时
+
+
+紧急问题需要立刻解决，所以并不能给团队成员太多时间，这时他其实也可能需要你的帮助，互相沟通一下，如果他有思路解决，给他时间，如果没有思路，跟他一起解决。
+
+
+方向把控时
+
+
+要和团队成员，确定大家的目标都是一致的，而且没有方向的问题。主要防止走错方向，做无用功，恶劣地影响团队整体产出。
+
+
+跨团队和跨部门协调时
+
+
+作为团队的负责人，你比他更有调动资源的能力，要为他协调组织。
+
+成长来自于实践，在实践中我们会有很多收获，我们要及时把他们保存下来。
+
+
+知识库
+
+
+建立一套知识库体系，早期的时候会用confluence来记录，文档放在NAS上。后续会搭建公司内部资料共享的系统，公司技术博客。
+
+
+复盘
+
+
+复盘是一种很好的总结，学习的方式，从失败当中获得成长。每个人都做自我总结，大家再一起给出改善建议，将整个复盘的结果保存下来，缺点改正，优点传承。
+
+成长不是个体的
+
+成长的最高境界是成就他人，但首先还是管理者自己的个体成长，自己不要成为团队的天花板。技术管理者是团队的旗帜，大家都在向他看齐，他的言行举止是最重要的。成长首先是看个体成长，团队成员的每个人都是其中的个体，每个人都有自己的想法，而且处的阶段都不同，要让他们每个人都能获得成长。团队需要有出类拔萃的标兵人才。但整个团队都依赖于个别人，说明人才结构就不健康了。
+
+选才培养
+
+从招聘开始，就会去选适合团队文化和人才结构的候选人。我们很重视对年轻人培养，敢于破格提拔年轻人试错，让有作为的年轻人成为团队的核心。
+
+团队目标
+
+上一节提到个人目标，整个团队需要有一个整体目标，协同所有人，一定要沟通到位，上下一致。
+
+营造氛围
+
+营造工作学习氛围，调动大家的积极性，每个人都能独立负责一块。在营造技术氛围这一块，我们鼓励大家分享，建立培训体系，组织hackthon活动，喜欢真正对技术感兴趣并乐于分享的同学，给他们荣誉，比如最佳讲师，技术创新奖等。同时创建公司技术博客，在精力允许下，提倡员工出去分享，提高技术影响力。
+
+成长就是为了创造价值，并满足自我需求
+
+成长最终目的还是为了创造价值，成长过程中的成就感也来源于创造的价值。创造的价值最终是服务于我们的用户，得到成就感，但同时基于人性，我们不能忽视财富，权利，虚荣心的需求。
+
+成就感
+
+最好的办法是让做工作的人有成就感，通过工作本身，变得有成长，通过工作不能调动他的动机，就没有持续的动力来调动他的积极性。
+
+荣誉
+
+荣誉可以成为不断鞭策荣誉获得者保持和发扬成绩的力量，还可以对其他人产生感召力。在企业中我们设计了职位，职级，表彰（优秀员工，优秀团队）等，给予员工最大的尊重。对于员工的重大贡献，要公开表扬，同时对犯错的员工不要过分批评、指责和抱怨，对事不对人，给予帮助和指导。
+
+财富
+
+包括工资，奖金，股票期权。工作的结果不会直接跟工资挂钩，工资会和岗位，职级挂钩。奖金往往和工作绩效挂钩，要考虑工作背后的真正价值，防止过度KPI化。奖金要和员工期望值挂钩，过度激励和过少激励都是不科学的。长期业务的奖金偏向于阶段性激励，而不是项目制，这样才能给予真正的价值判断。
+
+使命感
+
+企业强调自己的使命愿景价值观，加强员工的使命感，所有人活着都想做点有意义的事情，将所有员工的成长和公司使命愿景放在一起，形成共识，激发团队的向心力，用价值观去规范员工的言行举止。
+
+结语
+
+团队管理者不光是个人获得成长，要让团队成员都能获得成长，和他们一起分享成长和收益，让每个团队成员未来都会比自己更好，成就他人才是最大限度的成就自己。
+
+作者简介
+
+陆栋栋，TGO鲲鹏会上海分会会员，喜马拉雅CTO&技术合伙人，伴随着喜马拉雅的整个成长，微胖界典型码农。关注音频，知识付费，直播，AI大数据，区块链等领域。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/020论团队管理与共同升级.md

@@ -0,0 +1,82 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            020 论团队管理与共同升级
+                            近两周，我们共同探讨了打造优秀的技术团队的一些经验，接下来几周，我们还会继续相关的话题。其实，不管是招聘、培训、考核还是激励等等，归根结底考验的是团队负责人的“人员管理能力”。
+
+此前，易观CTO郭炜在“技术管理核心能力”系列文章中，已经分析了”领导力“和“体系搭建能力”，今天我们就来一起听一听，郭炜对于”人员管理能力“的分析。以下为正文内容：
+
+所有企业管理的问题都是“人”的问题，人就是一个企业的竞争优势。在写作本文时，我思考了半天用什么词来讲“人”的问题，用“管理”这个词并不合适，卓越的人才其实是“自我驱动”，而不是仅仅需要被“管理”的，所以加入了“共同升级”一词。
+
+在《原则》当中有这样一张图，有效的说明了一个企业其实就是一个从设定目标到实现最终结果的机器，这个机器是由一些“原则”组成。而执行就是由“文化”和“人”来做到的（详细的内容强烈推荐大家仔细阅读《原则》这本书），人本身也是由文化和制定的原则来影响的，卓越的人才对卓越的文化体系有一个正反馈，对公司本身的原则也是一个正反馈，最后与公司“共同升级”。
+
+
+公司并不是僵化、一成不变的，而是一个由“原则”构成的生机型组织，这也是现代企业必备的生存和竞争技能。所以，人员是一个科技企业和技术团队最重要的核心资产，如何让这些特别聪明甚至“傲娇”的技术人才可以在一起高效的工作，对这些聪明人如何招、识、管、留、开，是一个技术管理者的核心技能，这也是本文主要讨论的内容。
+
+招：人才招聘
+
+对于科技企业，招贤纳士是每一个技术管理者最头疼的问题，一个CTO往往会花50%以上的时间用来找人。但是，招聘其实不是一个单点问题，招不到合适人才，并不是招聘体系出了问题，招聘是一个企业的技术品牌、技术文化、技术薪酬体系的综合产物，只靠钱是买不来人才的，我一直坚守着的原则是只有将心比心、诚心求才，才可以换来高质量、忠诚的员工。
+
+技术品牌：技术品牌上技术人员是否认为你所在的企业是一个有技术发展潜力的企业，自己在加盟企业的过程中，除了待遇，是否可以学到东西有成长空间，将来离开企业是否会对自己未来的职业生涯有正向影响。
+
+技术文化：技术文化是技术最高管理者和公司共同营造的核心技术竞争力，看上去非常虚无，但是一个公司重要人才的流失、招聘不利，往往是公司的文化和所需要人才的不匹配造成的。一个公司的文化是目标导向、创新导向、还是KPI导向、是否容错，这些其实是要融合公司当前阶段和技术在公司中的作用来做。既不能让技术放任自由，也不能限制过死导致没有发展空间，招不到牛人。
+
+技术薪酬体系：整体上需要构建和市场接轨的薪酬体系以迅速扩张团队，在团队构建初期以期权和现金的模式吸引高级技术人才，中期以高于市场同等价位迅速扩张，迅速淘汰保留优秀的中层人才；长期通过异地研发中心等方式拉平整体研发成本，提高整体技术团队ROI。对于薪酬定位可以参考BAT的薪酬评估体系，这里不再详述。
+
+关于招聘，最后还有一句话，高级人才的招聘要高级技术管理者自己亲自上阵，三顾茅庐，将心比心、诚心求才才可以成功。对于高级技术管理者，招聘，并不是人力的事情，而是自己的事情，有这样的觉悟，才可以求到一起共同奋斗的弟兄姐妹们。
+
+识：识别人才
+
+首先，我们一定只招聘精英人才，这是公司精英文化的基础。怎样算是一个精英的人才，大多数技术管理者往往会在考察人员的技术技能上下很大功夫，而从我看来，这是不对的。我是用如下逻辑来看一个人才的：
+
+价值观>>>学习能力>>技术技能
+
+先考察一个人的价值观，因为这是一个人最难改变的。一个优秀的技术人才是否认同公司的MTP（MTP，Massive Transformation Purpose 参见 《How Google Works？》），是否认同公司的使命和顶层设计，通俗化讲，你所招聘的员工信不信这个公司或者部门能把事情做成。这点非常重要，因为你很难改变一个人的观点，即使这个人再卓越，他不认同你所做的事情能做成，那么后期你在用人阶段，你无论怎么激励也不会有任何效果。
+
+这也是我为什么坚持终面所有人都要我亲自面试一次的原因，此时不会再考量这个人的技术技能细节，而是“闻味”，看它是否和我们团队的价值观和公司的价值观一致。
+
+其次是看一个人的学习能力，这可以从人才的简历看出来，也可以从人员的经历以及他问的问题和回答问题的情况看出来。一个优秀的技术人员，现在会什么其实并不是那么的重要，而是他是否有潜力可以学习更多的东西。在技术领域里，没有一成不变的东西，一个新技术，往往1、2年就过时了，能不能快速学习迭代自己的技术，快速适应公司业务的变化，往往是一个人才自己最重要的素质。
+
+最后再看技术技能，在价值观和学习能力都OK的情况下，技术能力好的人才，可以节约你培养的时间，可以快速上手。而招聘时为了快速上手，招聘大量技术技能不错而价值观、学习能力不行的成员，一定会面临一次大洗牌，重新更新团队。
+
+管：和人才共同成长
+
+首先我的管理理念是精英团队理念，也就是所有的团队成员一定是由精英构成的团队，哪怕团队规模小一些，也不会有鱼目混珠的成员在其中混事。这样的好处是可以迅速打造精英文化，在招聘和识人上下了很大功夫之后，在管理上反而会轻松很多。
+
+这里需要和大家分享的观点是用“使命式”管理，而不是用“命令式”管理。使命式管理含义就是告诉大家要做什么，目标是什么，为什么要这样做，让大家理解我们的使命是什么，而权力和决策下放到具体执行层面，只在关键点上进行协同。而不是“命令式”管理，把一个事情按照传统项目制细分WBS，把每一个人每一天要做的事情全部细分下去，这样你的团队没有积极性，留下来的也一定只是听话的“庸才”。而面对瞬息万变的市场，这样的团队是无法生存下去的。
+
+使命式管理，是坚定的把“人”放在核心位置上，每一个员工是否愿意承担责任，上级领导是否愿意支持下属的决定，对善意的错误是否可以容忍。这个理论基础不在这里详述，喜欢军事的管理者可以参考一下拿破仑的“机动作战”体系，或者冯 · 毛奇提出的面对不确定性作战的理论，他那句名言“遇到敌人，一切计划都将被打破”，正是现在中国瞬息万变的市场的体现。对于人才，我们要做的不是“管理”，而是使命式管理下的共同成长。
+
+留：评估和挽留人才
+
+挽留人才是在“管”这个阶段管理没有做到位的体现，往往是一线管理者或者团队使命出现问题，才会进入“留”这个环节。一般提出分手的员工，需要从他的需求来做分析。马斯洛的需求理论在这里可以发挥出比较大的作用。最终员工心理需要的是什么，有的员工是待遇问题，这种挽留是最容易做到的，是因为你可以考虑重新招聘一个员工和留住这个员工的代价。
+
+而员工在这个阶段的个人发展诉求没有满足是比较棘手的，因为企业发展阶段和员工自身发展阶段可能会出现不匹配的情况，那么尽力对员工进行岗位的调整，项目组的调整，如果依然无法匹配那么只好友好的说再见，等待下次时机成熟再次合作。
+
+如果是因为一线管理人员不到位的情况，可以通过重新宣贯价值观，调整一线汇报线等方式进行处理。整体上，走到“留”这一步的精英骨干员工，都是因为管理不到位造成的，是技术管理者需要避免的情况，需要从前几个环节找问题，而不是到最后需要挽留再临时抱佛脚。
+
+开：和人才友好分手
+
+开有两个含义，一个是管理者要在每隔一段时间，例如半年，评估一下所有的员工，把他们和市场上的资源相比，重新招聘一次，这个员工是否还值得。一方面，对于表现优秀的员工进行奖励，保持市场价值的均衡，另一方面，对表现不如市场资源的员工，分析我们自己管理哪里没有做到位，导致员工入职后成长速度不如市场预期，对于一直表现有问题的员工要进行优化。所以，从某种含义上来讲，其实每半年你心里把所有员工“开”了一遍，又重新招聘了一遍，只有这样做，才可以分析整个管理团队哪里做的有问题，管理团队自我也要再提升。
+
+另一个含义，开，是针对触犯公司文化、原则红线，或者持续无法跟上公司节奏的员工进行的处理。没有开过员工的管理者不是好的管理者，大多数技术管理者性格比较随和，不喜欢开除员工。但是出现触犯红线的员工或者跟不上节奏的员工，你保留它反而会影响团队整体的士气，因此需要杀伐决断，当机立断采用合适的方法让员工离开。当然，如果只是能力跟不上的员工，你也可以推荐给其他公司适合的岗位，让和自己一起奋战过的兄弟有一个好归宿，也会让在职的员工会感觉温暖。整体上“慈不掌兵”，在开人这件事情上，高级管理者不要过于犹豫，为了一两个人最后影响整体团队的士气反而得不偿失。
+
+结语
+
+人是最复杂的动物，对于人员的管理和共同成长，是一个技术管理者毕生都需要研习的课程。究竟最终所有的生机型企业都是由精英人才构成的系统。人员管理其中不仅仅是沟通的能力，更要是对人员素质的准确判断、员工心理、团队士气、杀伐决断、上下级管理沟通的综合能力，也是技术管理者核心能力中最难的一个能力。
+
+判断一个团队的技术管理者是否做好了人才管理，其实可以用一个很简单的问题来验证，你的精英是否愿意推荐他周围精英加入到你的公司，如果大多数精英愿意这么做，那么你的人才管理是有效的。同时，这也形成了你这家公司的精英文化，让更多的精英汇聚到你这家公司来。
+
+“人在地失，人地皆得；人失地在，人地皆失”。人，才是一个企业的竞争优势。
+
+希望各位管理者都有一支能打硬仗的队伍。在下一篇文章中，我会分享文化的构建能力，欢迎大家持续关注《技术领导力300讲》。
+
+作者简介
+
+郭炜，易观 CTO ，中国软件行业协会智能应用服务分会副主任委员，TGO鲲鹏会北京分会董事会会长。负责构建易观技术团队、完成易观大数据采集、平台、数据挖掘等技术架构与体系；从无到有完成易观混合云的搭建、以及易观 SDK 的升级，并发布易观秒算实时计算平台。目前易观大数据平台日处理数据量 30T ，272 亿条，月活用户5.5亿。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/021绩效管理的目标不仅仅是绩效考核.md

@@ -0,0 +1,145 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            021 绩效管理的目标不仅仅是绩效考核
+                            我们经常讨论绩效考核这个话题，有不少人为如何考核程序员产出这件事烦恼。我旗帜鲜明的提出观点，绩效考核只是绩效管理的一环，如果抛弃绩效管理谈绩效考核，无异于舍本逐末。本文尝试聊几个大家关心的话题：绩效考核有哪些痛与伤、绩效管理与绩效考核的关系、目标与KPI、OKR的关系等。
+
+绩效考核有哪些痛与伤
+
+我们先回顾一下绩效考核都有哪些常见问题。
+
+第一类问题，我们姑且称为”工作量考核”。顾名思义，工作量考核的关键点在于工作量评估。工作量评估，又会绕到一些常见的问题：
+
+Java开发工程师的工作产出如何衡量？
+
+前端工程师的工作产出如何衡量？
+
+产品经理的产出如何衡量？
+
+DBA的工作产出如何衡量？
+
+有人提到过代码行评估，但代码行评估其实在业界的争议非常大。代码行多是绝对代表产出更好吗？不同语言之间对比代码行也是一个有点滑稽的事情。
+
+第二类是绩效考核，可以称之为”全面指标考核”。全面指标考核可以说在”考核”本身这件事上已经做得足够了，一般会关注多个维度的评估以保障全面性。我曾在一家电信业务的IT公司做部门经理，当时公司是采用平衡计分卡来做绩效考核。
+
+平衡计分卡是从财务、客户、内部运营、学习与成长四个角度，将组织的战略落实为可操作的衡量指标和目标值的一种新型绩效管理体系。我后来反思，绩效目标要突出拉动力，而不是面面俱到。否则很容易导致全面指标考核在实操过程中走向失败，绩效考核的维度和实际运营维度不match。
+
+我们再看一个例子。在项目研发中往往以研发过程数据、业务结果、公司制度（比如考勤）、主管主观评价等构成程序员的绩效考核体系。如下图所示，示例了一个绩效考核的指标体系。
+
+
+
+业务结果、研发过程、制度考勤、主观评价4个维度有对应的权重，来体现不同的岗位角色和各项指标的关联紧密程度。比如，活跃用户数超出预期，研发人员自然是有贡献，但产品和运营所起到的作用更是重要。我认为，研发过程的指标应该作为观测指标，真正的考核指标是业务在线上运营的故障和缺陷，以及研发人员对于需求响应、客户服务方面的满意度。由外而内，避免自嗨。
+
+绩效考核还有一类问题，出在绩效指标设定上。绩效指标要和组织目标对齐，不要为了设置而设置。我们来看一个例子。某测试同学的绩效指标设定：1：所负责的模块无线上缺陷；2：辅导应届生进行功能测试；3：完成一次性能测试。
+
+到考核季的前一个月，这位同学发现我的第三个指标(完成一次性能测试)还没做呢？于是急急忙忙去做了。当主管评估该同学绩效指标的时候，发现所有指标都完成了，包括性能测试的指标。但这个指标是不是当下最重要紧急的，甚至这个个人绩效指标跟项目目标、团队目标没有强关联。目标没有对齐的危害，可能是树木和森林没有很好的对应，甚至可能南辕北辙。
+
+通过这个case可以思考一个问题，绩效目标设定和所属团队目标的关系，以及和上级组织目标的关系。
+
+我们跳过绩效考核应该如何做，先回头来看看绩效管理是怎么回事。
+
+绩效管理闭环
+
+有个专家叫戴明，他发明了一个快速反馈的工具叫戴明环，又称为PDCA环。PDCA环实际是美国质量管理专家休哈特博士首先提出的，由戴明采纳、宣传，获得普及。PDCA循环的含义是将质量管理分为四个阶段，即计划（plan）、执行（do）、检查（check）、行动（Action）。
+
+绩效管理其实质也是一个PDCA循环。
+
+第一步是目标设定。目标来自于哪里？技术团队的目标一定是来自于业务。我经常讲不服务业务的技术都是耍流氓。阿里巴巴CTO行癫也有句话，所谓的工程师文化就是”让好技术驱动业务腾飞”。比如一个业务负责人把一款app(如极客时间)的目标设定为：
+
+活跃用户数达到10万
+
+单品专栏成交量超过20000
+
+按照增长黑客的思路，引新、留存、促活、转化这些套路都会用起来，那么对于技术平台就可能有一些对应的技术指标。比如：
+
+App7*24小时可用（实际上可以放宽一点，深夜4点还在学习的用户极少）
+
+App稳定性(安装包大小、启动时间、崩溃率、App耗电等)
+
+易于分享和传播（比如分享步骤不超过3步，过于复杂会让用户失去兴趣，当然还可以通过返利一定程度上平衡）
+
+第二步是设置计划，亦即是PDCA环中的P(Plan)。设置计划来自于目标的分解。比如：
+
+8.31完成A业务线的全部业务接入
+
+9.30完成B业务线的全部业务接入
+
+10.31完成C业务线的全部业务接入
+
+第三步是执行 (Do)，执行过程中进度风险、人员流失、技能不够、需求变更频繁等风险都有可能存在，甚至是不止一个因素同时发生。那么我们要做好的就是缩短反馈环，解决问题。每日立会、缩短迭代发布频度等有助于掌握项目实际的风险和完成状况。参与项目的同学，项目整体目标与个人目标息息相关，可以通过主动反馈主管来做阶段性检查(check)对齐。
+
+第四步是检查（Check）。对于个人而言，日常过程中的绩效管理尤其重要，及时发现偏差，及时清晰的沟通，落地有效的改进计划或方式。同时如果涉及绩效目标的变更，也要及时沟通调整。
+
+第五步是给出Action。根据check结果给出Action帮助目标进行改进。同时进入到新的PDCA循环。
+
+由此可见，绩效管理是一个闭环过程，而绩效考核是其中一个阶段。如果等到考核期才发现问题就晚了，应该保持按周、月、季做check有利于早发现、早纠正。
+
+目标与KPI、OKR的关系
+
+首先辨识一些基本概念。
+
+什么是目标？目标是要去的方向，并且转换为可衡量的数据指标。目标不是孤立存在的。
+
+KPI(Key Performance Indicator)是关键绩效指标，来自自上而下的分解。各部门的主管需要依据企业级KPI建立部门级KPI，并对相应部门的KPI进行分解，确定相关的要素目标。KPI的好处就是分解清晰，力出一孔。
+
+OKR（Objectives and Key Results）即目标与关键成果法，是一套明确和跟踪目标及其完成情况的管理工具和方法，主要目标是明确公司和团队的“目标”以及明确每个目标达成的可衡量的“关键结果”。OKR 首先确定 O(Objectives)，然后从 O 分解出 KR(Key Results)，然后用 KPI 或者 Milestone 的形式来表示 KR。
+
+有论者批评唯KPI论，一切都是KPI惹的祸。我觉得关键的问题不是出在KPI，而是出在KPI的制定者，或者是KPI的执行者。KPI顾名思义，是关键绩效指标，指标不等于目标，所以KPI应该在目标的指导下工作。
+
+举例来讲，在2011年的时候，我们大团队曾经做了一个产品叫悬赏交易，如果我没记错的话，大概业务指标是做100万笔交易。热心的运营同学想了各种办法来完成这100万笔，包括给旺旺用户推送消息，然后跳转到对应页面，获得一个赠送的商品，默认点击则完成一笔交易。我认为这样的KPI在执行层面是有害的，设定KPI背后的why是什么？是让这个产品被用户知道，让用户愿意来使用，有用户留存。如果用户在引流过来对产品毫无感知，单纯完成的交易并不能说明什么问题。总结来说，KPI没有错，在使用KPI的时候，要了解背后的why，要了解我们要去的方向在哪里，目标在哪里。在灯塔的照耀下，KPI就能被合理的应用于考核。
+
+有时候方向对了，KPI设定错了，还可以走一段之后去调整它，所谓“不忘初心”，在行进途中别忘了，我们为什么出发？而OKR的美丽在于，对于目标提出了可度量的关键结果。所以无论KPI还是OKR都需要强目标驱动，单纯谈KPI，可能会丢掉目标和初心。
+
+我们参考一下吴军老师2017年初给自己设定的OKR，下面仅引用目标1。
+
+目标1. 完成《数学之美》的英文版和韩文版，《大学之路》第二版
+
+关键结果1.1 找到英文版的出版商 ；（1.0，已经签了合同）
+
+关键结果1.2 寻找合适的、母语是英语的合作者，修改英文版的书稿 ；（0.3，试了两个翻译者，都不满意，在联系第三个翻译者，让她试着翻译一章。）
+
+关键结果1.3 完成英文版的写作；（0.1，因为翻译者还没有找到，因此我自己翻译了一章、前言、目录，以后要由翻译者做）
+
+而我在工作中，习惯了增强KPI的设置模式，这个模式里面有关键绩效指标, 但关键绩效指标仅仅是一个评估结果。于是又增加了过程关键指标。过程关键指标如同温度计，它不是用于惩罚和制裁。而是去发现可能的异常，通过高频快速的反馈促进团队和个人改进，以便于满足阶段性KPI的达成。下面就提供一个设置增强性KPI的示例。
+
+夯实底盘（稳定性、资金风险）：通过XXX手段加强事前、事中、事后的风险防控。
+
+【衡量标准】：
+
+最终结果：
+
+无重大故障
+
+无P1级故障
+
+线上总故障数<=5
+
+过程关键指标：
+
+线下缺陷，缺陷密度、紧急发布等作为观察指标(详细指标此处省略)
+
+应急体系：（衡量指标：变更导致线上的问题的发现时效、主动发现线上问题比例等）
+
+业务分钟级异动感知， 5分钟内止血消除影响。
+
+加分项：
+
+1：创新解决问题方案，有案例支撑并具备跨子域或者更大范围的推广价值。
+
+2：在问题的解决过程中追求极致，有典型案例支撑。
+
+大家可以思考一下，如果把上面的例子修改为OKR应该如何做？我认为KPI本身并不low，关键在使用这个工具的人。在使用KPI的时候要紧扣目标，绩效管理闭环有助于产出的改进。OKR创造性的提出了Key Results，但也要防止Key Results陷阱。随着公司业务发展和规模扩大，越来越多的团队面临的是不确定性问题域，很可能3个Key Results结果都很好，但关键目标并未达成。
+
+结语
+
+绩效管理的目标不仅仅是绩效考核，绩效考核只是绩效管理PDCA的其中一环。考核的目的是为了改进，而不仅仅是做一个评价。技术团队设定目标的方向非常重要，目标应该来自于组织目标分解，同时为了保有创新和自主性，组织目标不宜确定过细、让团队拥有一些创造性解决key result的机会。KPI是关键绩效指标，关键绩效指标要在目标的作用下工作。OKR在目标的基础上分解出关键结果，有利于目标的过程跟踪。
+
+作者简介
+
+于君泽，蚂蚁金服资金运营技术部负责人，TGO鲲鹏会成都分会会员。从业超过16年，业务领域兴趣在支付、金融风险、监管科技。同时经常就高可用分布式架构、研发管理、内建质量等发表观点。维护公众号：技术琐话。著有《深入分布式缓存》一书。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/022验证研发团队价值的绩效考核机制.md

@@ -0,0 +1,95 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            022 验证研发团队价值的绩效考核机制
+                            业务同事的绩效很容易考核，签了多少单？赚了多少钱？清晰可见，容易衡量。对于做产品研发工作的我们来说，成本很好计算，但价值却很难衡量。业务团队能为公司赚钱，研发团队却花公司的钱，研发团队从此就变成了公司的“成本中心”。
+
+我们需要有一套合理的绩效考核机制，衡量并验证自己的价值。这套机制需要简单易懂、操作方便，而且需要通过数据说话。有数据还有要对比，需要与自己比较，还要与别人比较。
+
+本文将结合之前的文章（第14讲：从零开始搭建轻量级研发团队）中提到的内容，从绩效考核方面继续探讨下去。首先，我们针对研发团队考核模型，进行深入探讨。
+
+研发团队考核模型
+
+我们的研发团队分为横向“职能团队”与纵向“项目团队”，所有的研发人员都在职能团队中，他们都在所在的项目团队中，体现出自己的工作绩效。因此，绩效考核是基于项目团队进行的，而不是职能团队。针对不同类型的项目团队而言，需要制定不同的团队目标，采用不同的考核方式（如图 1 所示）。
+
+
+图 1：项目团队考核方式
+
+每种项目团队都有共同的考核部分，那就是“个人 OKR”，它包括两方面：一是个人成长，二是团队贡献。个人成长又包括专业技能和综合技能两方面，前者是“硬技能”，后者是“软技能”。个人是否得到成长，取决于和自己的曾经作比较，而并非与他人作比较。团队贡献包括的方面较广，比如：技能培训、经验分享、偿还技术债、制定并落地规范、组织团队活动等。在本文下一节中将对 OKR 进行深入探讨。
+
+需要注意的是，个人 OKR 需要个人结合团队目标来定义，由个人所在职能团队来评审个人 OKR。 也就是说，OKR 是自底向上的，而 KPI 却是自顶向下的。此外，我们认为 OKR 和 KPI 既不冲突，还能相辅相成。将 OKR 与 KPI 有效结合，不仅可以激励团队成长，还能促进团队完成公司的核心目标。
+
+对于功能团队而言，他们的目标是确保以最快的速度，高质量地让项目上线。然而，速度和质量往往是相互制约的，速度太快，质量一般不会太高。也正因如此，我们才需要对功能团队的速度加以限制，否则项目上线后，一个难以维护的成果即将诞生，可以想象，随后效率团队一定会踩坑无数。因此，我们需要对功能团队定义一些“技术 KPI”，才能确保项目的顺利交接，比如：上线时间、代码质量、产品质量等。
+
+对于效率团队而言，他们的目标是优化现有产品功能并帮助业务实现目标。可见，业务的成功，决定于效率团队的成功。我们无需像要求功能团队那样去要求效率团队，因为他们关心的不再是速度和质量，而是如何不断提升业务效率，帮助业务团队实现业务目标。因此，我们可将业务 KPI 作为考核效率团队的参考标准。
+
+对于创新团队而言，他们的目标是帮助公司创造新的商业机会与盈利方式。往往需要通过收入的方式来考核该团队，我们需要同时设置业务 KPI 与技术 KPI 来验证该团队的价值，即投入与产出。
+
+当然，不论哪种项目团队，都需要考核项目是否延期？上线后是否有 Bug？而且这些标准都应该是事先确定清楚并和团队达成共识的。我们相信：先有共识，才有共赢。只有大家一致认同的原则，才可能有效地去执行。
+
+以功能团队和效率团队为例，在绩效考核的具体操作层面上，我们可采用“打分制”，根据具体情况进行加分或减分（如图 2 所示）。
+
+
+图 2：绩效考核打分制
+
+需要注意的是，效率团队将对功能团队的交付成果进行考核，不仅是代码，还包括文档。确保功能团队的 1.0 项目这根“接力棒”可以顺利传递下去，未来在效率团队的手中，让它变成 1.1、1.2、1.3 等。若要开发产品功能 2.0，可认为这是新的尝试，同样需要功能团队来开发，2.0 功能上线后再次交给效率团队进行功能迭代。
+
+每个季度可进行一次绩效考核，具体的考核成绩将分为 S、A、B、C 四个级别，S 表示大家心中充满美好期待的那根线，A 表示努力跳起来就能够得着的那根线，B 表示及格线，C 表示不及格。绩效考核的成绩需要公示，考核结束后根据具体成绩进行奖金发放。同时，个人 OKR 也在每个季度结束时进行考核，但考核结果不会体现在季度奖金中，而是体现到每年的加薪幅度上，因为个人 OKR 是个人的能力提升与团队贡献程度的表现，与薪资挂钩会更加合理。
+
+关于 OKR 方面，虽然它无法直接反应在绩效上，但它对团队的成长是至关重要的，团队成长了，绩效才能提高。下面，我们专题讨论一下 OKR 的十大要领。
+
+OKR 十大要领
+
+OKR 最早来自于 Intel 公司，随后在 Google 公司得到了更好的应用，现在全球杰出的互联网公司几乎都在用 OKR。要在企业中更好的应用 OKR，完全取决于我们自己对它的认识。
+
+OKR 包括两大要素：O 和 KR，O 是 Objectives（目标）的缩写，KR 是 Key Results（关键结果）的缩写。O 用于描述我们心中希望通往的美好目标，KR 用于描述衡量实现这个目标的关键结果。
+
+为了让大家更好地理解 OKR 的精髓，我们提出以下 OKR 十大要领：
+
+
+OKR 不是一款绩效考核工具，而是一款目标管理工具。
+OKR 包括自顶向下（制定）与自底向上（评审）的全过程。
+O（目标）需要做到简洁且定性，要鼓舞人心。
+KR（关键结果）需要做到明确且定量，用数据说话。
+一个季度制定一次 OKR，季度结束需对 OKR 进行评审。
+每周做一次 OKR 回顾，每月做一次 OKR 调整。
+OKR 制定过程需进行多次评审，以确保它与上级目标不冲突。
+O 一般不要超过 5 个，O 所包含的 KR 一般为 2-4 个。
+OKR 需要做到透明化，向团队完全公开。
+OKR 评审结果可作为加薪的重要参考依据，但不是唯一依据。
+
+
+对于 OKR 而言，很多人容易将它理解为绩效考核工具，认为它和 KPI 是同类，这是一种误解。如果将 OKR 理解为考核工具，我们一定无法用好它，也更无法从中受益。OKR 是一款目标管理工具，它管理的是我们所制定的目标，让我们的目标更加清晰且容易实现。
+
+KPI 是自顶向下的，老板定义了 KPI，各级领导去背 KPI，员工去完成 KPI，大家各扫门前雪，达成自己的 KPI 即可。然而，OKR 却是自顶向下和自底向上的全过程，老板结合企业战略去定义企业 OKR，领导结合企业 OKR 去制定团队 OKR，员工结合团队 OKR 去制定个人 OKR，这是 OKR 制定过程。通过一段时间的努力，随后进入 OKR 评审过程，员工评审个人 OKR，领导评审团队 OKR，老板评审企业 OKR。可见 OKR 即包括了自顶向下的制定，也包括了自底向下的评审。
+
+我们务必做到能用一句话来描述 O，这句话要让团队任何人都能完全理解，即简洁且定性，还要做到鼓舞人心。例如，如果目前我们的团队文化做得不太好，我们希望未来一个季度可以得到改善，O 如果写成“改善团队文化”，这句话虽然做到了简洁且定性，但不够鼓舞人心。我们可以将其改为“打造更好的团队文化，让大家爱上这个团队”，是否瞬间就产生了正能量？
+
+每个 O 都有对应的 KR，它们用来说明为了实现这个 O，应该做到的关键结果是什么。KR 需要做到让团队任何人都能完全衡量，即明确且定量，还要做到用数据说话。例如，如果目前我们的系统架构中微服务的颗粒度较大，代码的可重用性方面比较低，为了解决这个问题，我们希望对微服务边界进行切分，如果将其中一个 KR 写成“切分颗粒度较大的微服务”，这样是不合乎要求的，我们可将其表述为“至少切分 3 个颗粒度较大的微服务”，增加了一个数字来描述，这样的 KR 就更加容易衡量了。数字是最容易衡量的，此外“有”和“没有”也比较容易衡量。
+
+通过实践我们发现，一个季度制定一次 OKR 是非常合理的，季度结束需对我们所制定的 OKR 进行评审。OKR 并非制定后就无法调整了，我们自己每周可做一次 OKR 回顾，自行将有问题的地方记录下来，职能团队每月在一起可做一次 OKR 调整，以及时修正我们的 OKR。对于个人 OKR 而言，并非完全由自己制定后就开始执行，个人 OKR 制定过程需要进行多次评审，以确保它与团队 OKR 不冲突。O 和 KR 的数量也有限制，O 一般不要超过 5 个，O 所包含的 KR 一般为 2~4 个。
+
+最后，需要说明的是，OKR 要做到透明化，可用电子表格或纸质卡片来管理，这些表格需要向团队完全公开。此外，每个季度末的 OKR 考核结果可作为加薪的重要参考依据，但不是唯一依据。
+
+我们作为团队领导者，也需制定自己的 OKR，以下是一位研发团队领导者的 OKR 示例（如图 3 所示）。
+
+
+图 3：一位研发团队领导者的 OKR 示例
+
+写在最后
+
+一个团队需要有目标，也需要对目标完成情况加以考核，目标与考核往往是相辅相成、缺一不可的。如果只有目标而没有考核，将无法检验团队的价值；如果没有目标而只有考核，团队将离我们越来越远。
+
+OKR 不是绩效考核工具，而是目标管理利器，所有人都能理解 OKR 的定义，但不是每个人都能很好的应用它，这也正是 OKR 的魅力之处，往往好的工具都是理解容易，但应用不易。大家可参考我们给出的 OKR 十大要领，再根据自身实际情况加以调整，就能顺利地实施 OKR，在组织中发挥出它的效果。
+
+我们认为，衡量结果好坏的最简单手段就是数据，只有数据才会让人信服，绩效考核关键就是用数据说话。
+
+作者简介
+
+黄勇，现任特赞科技（tezign.com）CTO，图书《架构探险》作者，Smart 开源项目作者，TGO鲲鹏会上海分会董事会成员，QCon 讲师。十年以上互联网软件架构与技术管理经验，擅长敏捷开发，推崇“轻量级”系统架构。喜欢阅读，热爱交流，乐于分享。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/023产品技术团队OKR使用法则.md

@@ -0,0 +1,91 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            023 产品技术团队OKR使用法则
+                            经常有团队问我，团队或者部门是否可以应用OKR工作法。我的回答一般是否定的。像销售、市场、人事、行政这样的职能部门，如果彼此独立设定OKR，几乎必然是无法和公司的聚焦目标对齐的。而且这些孤立的部门无法形成完整的业务链条，如果不能从公司或者事业单元的角度出发，就无法识别出影响成长的瓶颈问题和可能存在的增长动因，也就无法做有意义的聚焦。
+
+但是，这个问题在产品技术部门可能是个例外。尤其是产品型公司的产品技术团队。一方面是因为产品型公司的聚焦重点经常会放在产品本身；另一方面是因为很多互联网公司在产品技术方面遇到的问题和机会都非常接近，以至于我看到不少科技公司在企业层面的OKR设定都非常近似。
+
+先决条件
+
+即便如此，也并非所有的产品技术团队都适合独立引入OKR方法。如果要让这个方法在企业中发挥出成效，不产生部门本位主义，那么这个团队要符合以下这些特征：
+
+1）产品技术团队能够对产品的设计、开发和交付整体负责；团队具备主控性，而不是受制于多个部门的配合；
+
+2）非项目服务业务模式，产品技术团队服务的是本企业的产品，而不是客户的产品，否则这个团队的核心管理体制很难超越项目管理本身。而且外包项目的生命周期也不足以来激励OKR的实施。
+
+3）公司的业务成效很大程度上取决于产品本身的定位、特性与市场需求的适配度和产品质量；销售和营销职能起的是放大器作用。消费者应用领域的公司大多符合这个条件。如果是2B的产品则要视情形来看。
+
+如果以上先决条件不存在，那么这样的团队独立实施OKR的成效是不乐观的。实际上，缺乏自治度和管理关注度的产品技术团队，本身也很难有动力来自行发起目标管理。即使做，一般也只是为了响应公司从上至下的管理要求而已。
+
+常见的产品技术部门OKR类型
+
+当我辅导了十家科技企业的OKR制定沟通会议以后，我发现这类企业的OKR选择有非常明显的规律。团队相对容易达成一致的目标意图（Objective）大体会分成这么几类：
+
+1、产品特性交付里程碑
+
+这可能是最常见的目标之一。产品技术团队因为担负交付产品和特性的责任，所以容易有这样习惯性的思维——本季度发布xxx特性，交付2.0版本产品等。
+
+在这个动因下，产品技术部门设定目标要有更清醒的头脑和更整体的认知。为什么要交付2.0版本？2.0版本主要解决的问题是什么？除了形式上的交付，用什么KR能够更好地定义交付成功？一个好的产品交付目标应该揭示背后的商业意图。比如：“通过2.0解决客户自助部署问题”就是更加完整的目标描述。
+
+正是因为如此，这类目标所配套的关键结果（Key Results）也要能够反映出意图达成的KPI（请中性理解这里的KPI含义）。发布时间本身不应该成为KR，发布后能够形成的一个关键数据指标才是。比如上面“通过2.0解决客户自助部署问题”的Objective可能需要配套一个KR：自助部署页面的UV数量，它反映了这个特性交付带来的客户价值，每有1000个UV，说明可能有1000个用户得到了自助部署系统的帮助。
+
+在产品特性交付目标方面，我还经常发现一个常见困难，就是每个季度的OKR周期很难保证一个大宗的产品特性交付彻底完成，更加不要说获得使用相关的数据。这时候，我们就需要定义更加细分的里程碑，而不是一个版本的交付，比如“完成单元测试”、“完成数据架构设计”等。
+
+2、提升开发和运维质量
+
+在产品型公司的早期，因为经验和能力的原因，在产品开发和运维过程（devops）中存在大量缺陷。有一些质量问题也可能是因为“MVP”理念导致的。这些可能都是创业公司不可避免的阶段。
+
+但当公司开启了商业化进程，建立了专门的销售团队，低质量的产品会消耗巨大的营销投入，不仅无法转化满意的客户，而且会让整个团队士气低落。
+
+但站在公司的角度看，刚刚建立了销售团队，管理层的注意力通常被牵制在销售团队的形成和管理上，有时候是无暇顾及，有时候是没有意识到产品质量对于提高销售效率的重要性。与其等到部门之间相互指责和推诿，有全局观的CTO应该尽快聚焦在提升质量的目标上。在达成这类目标时，产品技术团队的自治能力至关重要。
+
+技术产品的质量提升目标不难设定用于衡量的关键结果（KR），但指标选择的过程最好依然是从下至上的，因为非专业人员很难有相关的知识背景。如果是和软件缺陷有关的质量改进，这个关键结果最好能够落在测试流程内部（用例的数量和覆盖度，测试的自动化程度等），而不是去衡量客户投诉率这样的滞后性KR；如果是和运维质量相关的目标，KR则更容易选择一些，因为有足够多的监控工具来直接提供有意义的指标。
+
+3、运营改善相关
+
+产品运营的职能划分在不同公司不一样，但有很多互联网企业很重视产品运营，并且意识到产品设计和研发团队对运营管理的直接驱动力。所以，也有不少产品技术团队会直接提出和运营改善有关的目标，这通常发生在企业的成长阶段。
+
+AARRR（获取，激活，转化，留存和推荐）是建立运营改善目标的最佳模型，它揭示出一个产品的总体成功来自这五个基本运营环节的成功。产品运营绩效目标的达成依靠的是方法、智力的投入，比如通过User Onboarding Design（用户上手指南设计）提升新用户激活度，而它带来的产出在财务上却非常显要。卓越的产品运营能够大幅降低平均营销成本，提升用户终生价值。从这个角度看，来自产品技术团队的相关目标设定，能够大幅影响公司的最终绩效。
+
+这类目标的描述可以非常直白，面对惨淡的留存，产品团队应该意识到“提升用户留存”是一个显然的目标意图。但是在每个公司的具体业务中，它的描述可以更加明确，比如“通过游戏化设计来加强用户留存“，“通过Onboarding模块加强用户留存”等。目标的设定越明确，在OKR执行过程中的任务设计就越顺畅，在复盘时头脑也更加清醒，不会被干巴巴的数字所制约。
+
+和开发运维质量提升相关的目标类似，产品运营的KR制定也有它的专业性要求，比如有关用户留存的KR，专业领域内有几十个可以使用的指标，到底哪个指标能够反映当下目标的实现度？次日留存和次月留存可能有完全不同的暗示。这需要专业的产品运营自发来选择指标，而不是等待管理层派发指标。同样，前面提到的目标描述的具体度也会影响我们选择KR时的精确度。
+
+4、提升产品市场适配度
+
+产品的功能和特性与客户的实际需求存在断层，这是一个普遍的企业失败原因，不仅在产品早期可能出现，在扩张阶段也可能再次遇到。杰佛瑞·摩尔在经典著作《跨越鸿沟》中阐明了出现这种情况的必然性。尤其是科技产品，早期用户和主流用户在需求和心理上的巨大差异使得一个新产品在进入早期市场和拓展主流市场的不同阶段面临完全不同的市场接受度。
+
+产品市场部门很难独立定义这样的目标。不仅可能缺乏足够的决策信息，也很难有这样的决策权威，因为它很容易挑战到一个公司的品牌和市场定位，细分市场选择。所以，这类目标的设定通常都需要和管理层，销售业务部门充分的沟通。
+
+设定好这一类的目标的前提是企业对“理想客户对象”有更加明确的定义。假设这个步骤能够达成共识，那么产品技术团队就需要和销售业务团队仔细沟通产品应该怎样改进才能更好地满足这类目标客户的需求。在以季度为周期的OKR执行中，聚焦解决那些能够有助于提高产品市场适配度的关键特性。这时候，选择对应市场的销售转化率作为KR，可能是更明智的做法。因为在客户买单之前，我们很难找到可靠的前导性指标。对于2C产品，验证要更加容易一些，一般留存率和活跃度指标都能够很好地反映需求匹配度。
+
+5、技术选型变更和偿还技术债
+
+在业务成长到一个阶段时，有一些技术团队会意识到紧迫的架构调整、技术选型升级等偿还技术债问题。这更加是一个需要由下至上设定目标的领域，因为很少有公司的管理层和其他业务部门关注这一点。如果业务发展顺利，用户不断增长，那么该发生的事情一定会发生。警惕性高的CTO们会未雨绸缪。
+
+设定这类目标时，要重视的是和管理层达成共识，因为这些技术工作必然会影响功能特性开发，锁死一些常规事务的进展，也可能涉及一些可控风险。如果没有事先的沟通，很可能会发生不必要的冲突。
+
+当然，这些目标是否应该成为产品技术部门某季度必须面对的关键目标，不能是CTO的主观臆断。它应该建立在数据的客观分析和预测上。
+
+衡量这类目标的KR也不难识别，甚至纯技术层面的压力测试就能够很好地回答这个问题。我们有没有让基础构架更加健壮？我们能否承受每小时100万次以上的访问？设定了这类目标和关键结构，就公开给其他部门的同事，这样既能够让团队周知这些事务的重要性，争取支持，也能够激励营销和销售部门，建立更强的业务拓展信心。
+
+执行和评估
+
+我列举了产品技术部门可能独立制定的五类目标类型，它们中的一部分依然有赖于和其他部门的深度协作，KR的设计也考验团队的策略分析和批判性思维能力。但这些都还只是开始，OKR目标的有效达成，并不是依赖选择出科学的KR，而是需要设计出切实有效，尽责执行的任务项，并且连续跟踪这些任务的完成状况，遇到的问题，改进方案。
+
+我为什么要强调“任务设计”，而不是“任务分配”？因为OKR目标所对应的问题通常不是一个常规运营问题，更加不是一个逐步改良性的目标，而是一个阻碍企业成长的关键问题，必须集中精力去跃升。如果依靠一般的任务分配所能够达到的成效，是很难有惊喜的。当OKR脱离了传统的绩效考核范畴，参与者就可以解放思想，采用创造性的手段来达成目标，这就是为什么要叫“任务设计”。
+
+在产品技术相关的目标达成中，我发现卓越完成的情况往往依赖两个重要的驱动力，一是成员的敬业度，二是成员的学习能力。对于一个产品技术问题的解决，很少存在可不可行的问题，更多的是团队暂时没有取得相关的能力，不知道行业的最佳实践是怎样的。敬业度又和学习能力相辅相成，彼此关联。所以，想要OKR目标的达成度提高，CTO和产品VP们应该长期关注的是人才的选拔标准，和团队共同学习进步的具体安排。
+
+我在管理明道的几年中，最大的感悟就是这一点。科技公司的兴起来自于关键技术能力的提前掌握，同样，科技公司的衰败也是因为没有能够跟上产品技术进步的洪流，它和团队成员有没有及时完成一个短期绩效目标没有太多联系。所以，OKR工作法看似是一个围绕短期，高速迭代的执行落地方法，但它的有效性有赖于使用者对长期绩效和价值创造的绝对关注。
+
+作者简介
+
+任向晖，企业社会化协作平台明道创始人&CEO。梅花网创始人。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/024996、987，程序员加班文化你怎么看？.md

@@ -0,0 +1,89 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            024 996、987，程序员加班文化你怎么看？
+                            某日，在TGO鲲鹏会全国会员群里，一位会员说了句“刚开始实行996一个半月，就有人提出离职了”。这一话题马上引起许多会员的共鸣，由此展开了热烈的讨论，其中不乏许多精彩的观点与实用的经验。加班文化，是很多技术管理者绕不过去的困惑，到底应不应该加班，怎么衡量加班的成果，怎么加班才不会让团队的兄弟们反感？为了解答这些问题，我们邀请了几位当天参与讨论的技术领导者写下了自己的观点，供大家参考。
+
+启赟金融CTO马连浩：
+
+启赟金融的技术团队规模近100人，当前实施996的工作时长。我个人工作时长除了和团队一起996之外，还会有非坐班时间的支持工作，比如融资支持，商户谈判支持和战略讨论，实际工作时长远超996。
+
+支撑员工接受高强度的工作时长无外乎是工作内容的高度认可，有温度的管理氛围，高度协同的工作同事，当然还有合理的物质回报。
+
+长期加班必须在工作产出的有效性上，判断自己的工作内容和研发项目是否符合能够有效提高公司的销售业绩，能够有效降低公司的运营成本，能够符合公司未来战略布局，符合度的高低和工作产出的有效性成正比。重复劳动和返工对一线员工影响很大，这块需要技术负责人来把控，保证技术团队接收到的需求是正确的。
+
+任何工作投入和产出都是成正比的，加班实际上是一种时间投入，内外培训和员工分享同样是投入，是在效率提升上的投入，在身心能够承受的范围内，合理提高时间上的投入，肯定在产出上会有正反馈。当然有个前提是加班要建立在工作需要上，提高工作的有效产出上。
+
+更重要的是，让员工建立主人翁意识，认为是公司命运共同体的一部分，为自己的事业而奋斗，很多抱怨和不解自然也就烟消云散了。同时，公司后勤要跟上，比如下午茶，加班水果等体贴式福利还是要到位，让马跑，还要让马吃草。
+
+今日头条上海研发中心负责人，前WeWork亚太地区技术总监陈满砚：
+
+我目前刚刚离开WeWork加入今日头条。之前在WeWork时的团队分散在亚洲各地包括澳大利亚，规模在50人。可以在家完成工作, 生病可以MC。
+
+我自己没有固定工作时长，也没有特定的休息日，毕竟作为亚洲和美国的枢纽，我是单点链接, 累计时长应该在50小时一周，如果加上因为工作需要的应酬和洽谈，应该在60小时左右。
+
+工程团队由于没有特别可以量化的指标（KPI），所以我们都是OKR驱动的，而OKR是自上而下的传输，为了达到公司的短期/中期目的而努力，所以这个作息只适用于工程团队，我们的销售等团队的工作时间也会比工程团队多一些。
+
+我觉得加班在目标明确的情况下是必须的，比如release出问题了，比如吃鸡要一个月上线等。可是加班不应该上升到一种文化，更不能宣传这种奉献，因为我们都清楚IC的权利是没有保障的，而公司的利益是有明确的保障的。
+
+我们都知道，有流水线程序员（code monkey），有程序员（engineer）。我不否认，流水线必然会战胜小手工作坊，可是同时我们也要知道，流水线上的每一个人每一个部件都是可以随时被取代的，当AI升起，流水线程序员肯定是会被直接淘汰的，我希望我们能发现和培养出更多的程序员，培养他们独立思考的能力，做一些对我们这个技术产业增值的事情。
+
+爱因互动创始人兼CTO洪强宁：
+
+爱因互动目前属于较早期的创业公司，技术团队只有30人左右。我们不实行996也不实行987，而是五天工作制，弹性上下班时间，全公司实行，从创业第一天开始就是这样。2017年全年离职率为零。
+
+但是这并不意味着我们是一家慢悠悠的养老型公司，相反，虽然我们没有实施996，但无论是夜晚还是周末，大家热情高涨加班冲刺的情况比比皆是。作为一家高速增长的创业企业，事情多，期限紧是常态，碰到事情做不完的时候必然需要依靠加班。但我们不把延长上班时间作为工作进度的保障，而是依赖频繁公开的进度沟通，依赖对交付物的质量要求，使得团队成员无论是否加班，都把产出作为首要目的，避免“为了加班而加班”的情况出现。
+
+软件开发是一个高度创造性的工作，为了提高产出，相比于简单粗暴的延长工作时长，我们更倾向于把精力放在增强技术平台、完善工作流程、打造学习型企业文化上，以及更重要的，精挑细选有足够强的自驱力，能融入到团队文化中的人上。
+
+“我们认为用在办公室出现的时间长短来评价一个工程师的产出是缺乏逻辑的。需要加班的场景，一定是因为有事情需要在限定的时间范围内完成，只要事情完成了，大家应该充分享受闲暇的时光。”
+
+这个是我们的招聘文案，我们也是这么做的。
+
+慧安金科高级产品研发总监马宇翔：
+
+我从955（偶尔还需要倒时差）的工作（4年）到创业公司955、996、987的工作（10年）都经历过。
+
+首先我认为，不要用“自己的认知”来看待和定义问题，对于创业公司的初创阶段来说，不管是955、996、987都是种工作模式，暗扣在企业文化这个大主题下面，只是种表现形式罢了。
+
+创业公司在初创阶段，创始人的性格和工作模式会很具备代表性，所组建的核心团队和对公司认可的初期成员也是对公司、创始人、工作模式的认同。
+
+不能抛开客观条件谈这类开放式的话题，客观前提条件是：创业公司（初创阶段）、核心小团队、企业文化和创始人风格、高效且高度认可的团队成员，在超出劳动合同规定工作时间范围以外的工作，是否界定为加班或加班文化，这一点因人而异了，毕竟每个人的三观和认知并不相同。
+
+我自己目前987半年了，依然不认为很辛苦或过于劳累，这样的生活方式与工作方式早已是习以为常的事情，虽然每天八点看似很晚，但要考虑到北京的交通问题，很多时候七点半晚高峰才退去的时间点，八点以后有选择性的文体活动，比如说我可以保证每周2次篮球2次健身1次纯娱乐放松，并未感觉到时间不够或工作严重挤压生活时间。只要这样的生活模式不会影响到身体健康、家庭、朋友、自己的兴趣爱好，也是种不错的生活方式与工作方式的平衡。
+
+二维火产品研发中心副总裁 芦宇峰：
+
+二维火的技术团队大概在400人以上，去年我们实行了大半年996，因此离职的技术人员大概有3%。
+
+衡量技术人员绩效，当然不能用工时。时间确实不重要，有质量的进度才是重要的，毕竟竞争对手有时候强大到不拼命不行，比如我们的对手是美团，融个资都比公司估值高十倍，你想想有多让人绝望。也招不起百把个博士或架构师，只能用勤奋弥补了。
+
+行业不一样，客户不一样，战略也就不一样。我所处的行业很大一部份是传统软件，我们的客户这些餐饮老板，在见面第一件事不是看你的产品有多好用，而是给我们一张五六页的纸，上面写着几百条功能列表，如果我们的产品覆盖了80%，才谈下一步。所以，我们对功能量有很大的要求。
+
+任何所谓好的体验，大数据带来的价值，节约了多少成本带来了多少客流，都要建立在整个产品体系的完善上。所以我们是劳动密集型企业。
+
+996其实是一个概念，或者是一个动员，其实在具体控制上，大部份员工都是早上10点左右才到，晚上8点半左右离开，这样就行了。还有一些基础要做好，比如绩效奖励，晚餐宵夜零食打车，再加上项目的各种庆祝，中午休息时间加长。非996的时候多一些活动和调休，比如周五周六晚上不加班，。实施方法如果得当，996也不是万恶的。
+
+公司业务快速增长，才是最好的团建。最终还是要回到结果上。如果结果好，那就都好。
+
+众安在线财产保险股份有限公司技术总监 陈天予：
+
+我们公司目前现状是99N（N=2~4），每周平均会有两三天的加班。在项目或业务需要的时候才会长期开启996模式。特殊制度执行时长一般根据项目周期来。高强度情况下最多有过连续2个月的996状态。
+
+加班只是一种手段，没有哪种手段是万能而不可替代的。但是为了追求更高的目标和自我价值，但凡能用的手段我们都应该用到极致，这其中自然也包括加班。毕竟世间唯一公平的是时间，要追求更多，加班已经是我们能选择的成功率较高的手段了。
+
+对于提升团队产出，首先是团队的使命感培养，只有团队有一致的目标及使命感，非常清楚“Why？What？How？”这三个经典的问句的答案，这样的团队一定能在相同条件下爆发出更强的战斗力。
+
+其次是建立透明公开的奖惩机制，在日常工作中对典型情况及时快速的进行奖惩及团队宣导，尤其是奖励这块，能极大地发挥榜样作用，激发大家的激情和竞争意识。在肯定其工作成果的同时也要不断的给予其更高的要求和挑战。
+
+最后是做到足够的人文关怀，尽可能去关心员工的心理状态和生活情况，在组织有能力的情况下帮员工去解决些后顾之忧或者帮助员工来更好地履行家庭责任。当员工能平衡好身心、家庭的关系时，必定能爆发出更大的工作热情和工作效率，从而提升团队产出。
+
+写在最后
+
+你所在的团队，工作时长是怎样的？你对加班抱有什么样的态度呢？欢迎留言与我们交流。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/025建立有效的员工淘汰机制.md

@@ -0,0 +1,85 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            025 建立有效的员工淘汰机制
+                            作为技术管理者，我们要常常梳理团队结构、梯队建设等事项，通过梳理才能更好的认清当下团队的状况，才能为更美好的未来最好准备。
+
+团队的发展其实与个体一样，只有不断的去突破自己的舒适区，根据实际的变化，放弃那些过时的认知，才能不断进步。
+
+想创建优秀团队，筛选出优秀的员工，淘汰不合适的员工，是一个团队能否健康发展的重要因素。好的员工是企业最大的财富，同理，差劲的员工也能让一个企业陷入万劫不复。
+
+本文就来聊聊，当你遇到不合适的员工时，该如何合情合理的进行淘汰。
+
+那些不同类型的“问题员工”
+
+首先，我把“问题员工”分类概括为“既合格，又合适的员工”、“合格，但不合适的员工”、“既不合格，又不合适的员工”、“合适，但不合格的员工”这四种。
+
+从管理者的角度来看，当然是那些“既合格，又合适的员工”更受青睐，为此往往不惜重金招聘，给以丰厚的福利待遇，委以重任。但是，这种员工毕竟是少数，因此，管理者不应该把太多的精力放在这类员工的身上。
+
+其次就是“合格，但不合适的员工”，这类员工往往具有职业上的硬技能，但是也许在软技能等其他辅助能力上缺乏潜力。对于这些员工，企业的处理方法应该是人尽其用，把他们所有的知识、技能都应用在工作中，尽力让企业的其他员工都分享他的知识和技能。
+
+如果他们主动提出要离开，企业不需要着力进行挽留，因为对于当今互联网时代的企业来说，倡导扶持高潜力员工的发展，才是面向未来的有效论调。
+
+再来说说“既不合格，又不合适的员工”，这类员工既不符合本职工作的技能要求，也不符合企业文化的需要，属于“无法胜任，也无潜力”的两无人员，这样的员工对于企业来说并无价值，基本是需要淘汰的对象。
+
+最后说说“合适，但不合格的员工”，企业管理者需要把主要精力放在那些“基本胜任，但潜力大”的员工身上。这些员工虽然职业技能有所欠缺，但是他们所具有的良好的学习技能和沟通技能，决定了他们能够通过培训很快弥补这些不足。
+
+通过以上分析我们发现，问题员工分布的范围比较广泛，技术管理者需认真鉴别，区别对待，发掘问题员工的长处，适当容忍其短处，对其存在的问题适时加以正面引导，真正做到 “用人之长，容人之短”。
+
+建立有效的员工淘汰机制
+
+一个团队必须建立相应的淘汰机制，人人都有危机感，都有随时被淘汰的可能，才能实现优胜劣汰，保持团队活力的同时，尽可能的保持最大的竞争力。就像是鱼群里的鲶鱼，随时威胁大家的生存，才能保证让大家都动起来。
+
+在具备有效的员工淘汰机制之前，有哪些问题是我们需要探讨的呢？比如“如何把真正的‘末位’员工剔除出来？“，“到底是从员工的工作质量、工作态度、个人品德、交际能力还是其他方面进行衡量？”或者“谁来评价，才能做到公正合理？”
+
+可以说，在企业内部建立淘汰机制是必要的，关键是如何做到“有效”，把不符合企业要求的员工进行淘汰，这才是我们应该真正关心的。
+
+在我看来，要保证“淘汰机制”的有效性，有效的绩效管理体系必须具备对企业的高层管理者（与公司总体绩效挂钩）、中层管理者（偏重本部门绩效的考核）及基层员工（偏重工作本身的考核）等不同的考核体系，最终通过约束与竞争机制促进个人及团队的发展，而考核者和被考核者都应将通过绩效管理手段提高工作绩效作为首要的目标。
+
+在执行过程中，对于一些比较容易考核的职位，可以考虑用试用期间的业绩及上司的意见，综合考虑新员工的去留。如果是一些技术性较强的，可以通过技术理论和操作两方面进行考核，再综合上司的意见后，由人力资源部决定新员工的去留。
+
+另外，也可根据员工的综合素质、能力、工作态度等因素，通过换岗、降职、培训的方式进行处理，或者直接淘汰。
+
+总而言之，建立一套员工淘汰机制是非常必要的，但是，淘汰员工要根据企业自身的特点选择比较适合的方式。
+
+如何让员工淘汰更具说服力
+
+众所周知，淘汰员工这件事，无论是用人部门，还是人力资源部门，常常煞费苦心，采取各种办法，结果却常常引发被淘汰者的极大不满，甚至引起劳资纠纷。
+
+为了让这个过程更具有说服力，我觉得需要从“管理环节重视”与“淘汰工作中的原则”两方面进行考虑。
+
+先来谈谈，我对“管理环节重视”的主要认知。
+
+首先，我们需建立起一套有效的甄选机制，进行有效的人才识别，则可为企业招聘到合适的人才，而无须在日后花费过多的精力进行人员淘汰管理。
+
+随后待员工入职后，为避免在短短的一个小时的面试过程中，难以对一个人作出全面而综合的考评，应重视试用期间对员工的更进一步的考核，通过员工在试用期间的实际工作表现，综合考评其知识、技能及态度，以更好了解此员工是否胜任本职，从而作出淘汰或留任的决定。
+
+紧随其后的是绩效考核，通过有针对性的绩效考核制度，实现有效的优胜劣汰，淘汰绩效不佳的员工。但对于许多企业来说，采取生硬的淘汰方式也许过于激进，也可以选择在其合同期满的时候，与员工终止劳动合同，从而达到淘汰的目的。或通过组织架构或业务流程重组时，进行淘汰处理，原来需要两个人完成的工作，现在只需一个人即可，这样，则会对多余的人员进行淘汰。
+
+所谓“没有原则，不成方圆”，与人力资源同学相比，技术管理者在淘汰员工的过程中应承担主要责任，因为对员工的业绩更有发言权，更具说服力。因此，在淘汰员工的管理工作中，除了管理环节重视之外，还应把握原则。
+
+在准备淘汰时，须事先搜集好员工的业绩考核数据资料，只有在论据充分的前提下实施淘汰管理，才能使员工能够接受将被淘汰的事实，不致引起员工过激的行为。
+
+淘汰面谈时，仅对其工作业绩不佳做出评价，不对员工性格，为人处事加以评论，尽量告知员工本人，并不是他能力不够，或本人有问题，只是不适合公司目前提供的工作而已。
+
+明确其的功过得失，不能全盘否定，任何一个员工都会有所长，有所短，有很多员工业绩低下只是因为他缺乏对自已的职业了解，目前从事的恰恰是自已不擅长的工作，或是因部门内部人际关系没处理好。
+
+沟通时，避免直来直去，注意说话的语气，用词，管理方式，方法，注意自已的身体、面部等，并注意说话的语气，措词。
+
+强调“青山不老，绿水长流”的态度，在员工有需要时要提供帮助，千万不能当仇人，因为他们对公司基本上或者全面了解，如果你能想到要帮助他们，他们一旦有机会也会回报你及帮助公司。
+
+结语
+
+无论对于企业，还是团队，在这个互助互盈的互联网时代中，其本质还是竞争。想要达到一个“你好，我好，大家好”的氛围，只是一个美好的梦想罢了。
+
+有竞争，就会有淘汰，只不过在这个过程中，我们应当更合理、更有效、 更具原则性。
+
+作者简介
+
+王晔倞，TGO鲲鹏会上海分会会员，好买财富平台架构部技术总监。2013 年加入好买财富，在 4 年内亲身经历了公司面向互联网的业务转型与技术变迁，辗转过不同的业务团队，对技术与业务都有深入的了解。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/026让细节的病毒感染你的团队.md

@@ -0,0 +1,83 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            026 让细节的病毒感染你的团队
+                            很多大公司的技术高管，既要思考战略和执行，又要管理繁杂的业务，有限的时间都占得满满当当。那么，作为企业的技术决策者，是否还需要关注细节呢？对于这个问题，我的答案是肯定的。
+
+为什么要关注细节？
+
+“细节决定成败”，这个道理自古就有，尤其是在这个全球商业竞争激烈的时代，更是很多成功公司奉行的理念。如果要找一个最能代表这种精神的公司，那就非苹果公司莫属了，其产品如iPhone、MacBook、MacOSX 等都堪称当今工业界最高水平。最近几十年在中国市场上发展起来的很多本土企业，也日益肯在细节上下功夫，出现了很多极为成功的科技公司。
+
+在知乎上有篇写腾讯CEO马化腾领导风格的帖子，提到其经常在深夜还发邮件和团队探讨产品细节问题，最厉害的是这些讨论往往第二天就能被团队落实。这个帖子中还提到，QQ邮箱在2008年的400多个创新点中，有近300项是由马化腾本人发现和提出。马化腾发现这些问题的方法很简单，就是反复使用。
+
+连大公司CEO都在半夜讨论产品细节，作为CTO或者技术决策者，还好意思说自己没时间关注技术细节吗？并且，我工作这么多年，有个感受，就是越到高层的老板，越重视细节、越抠细节。
+
+谷歌CEO埃里克•施密特在他写的《重新定义公司》书中提到，在偶遇一位许久不见的高管时，一句诚恳的问候之后，埃里克便会开门见山地提问：“你最近的工作进展如何？遇到了哪些问题？应该交付的产品进度如何？”这些问题的效果有两重：不仅让埃里克掌握了对方的业务细节，还让他知道这些主管是否掌握了他们的业务细节。在埃里克看来，没有掌握细节的管理者，是不胜任工作的。
+
+所以说，作为技术负责人，同样需要关注技术的细节。而善于提出问题，就是很好的了解细节的方法。
+
+细节决定成败
+
+前通用电气CEO杰克·韦尔奇曾在他的回忆录《赢》中讲述过一个案例。
+
+起初通用电气在核磁共振设备的市场中一路领先，韦尔奇曾发现自己的产品口径太过小，使人受到的压抑感太大，而此时日立公司正在研究大孔径设备。韦尔奇与医疗事业部门讨论发现：孔径加大会导致成像的准确度下降，医院的人不会接受。韦尔奇后来一有机会就会督促医疗部门考虑改进成像技术，但得到的反馈都是敷衍。随后不久，原本处于领先地位的通用电气被日立公司超越，其追赶之路辛苦万分。韦尔奇在自传中写道：我非常后悔，为什么自己没有付出更大的努力，对下属提出更严厉的要求。
+
+孔径之大小，能如此影响一个公司的发展，使我们不得不重视细节。
+
+技术做为一个业务中的重要部分，是保障业务成功的基础。由于互联网的应用，涉及到客户端程序和服务器端程序共同实现，也普遍有多个技术系统的相互依赖。在一个大规模分工合作的团队中，产品体验要做到极致，没有技术决策者的亲自参与，就不能有效调动和协调必要的资源，也没法保证执行的快速精准。也只有技术决策者关注到技术细节中去，才能掌握全面的信息，做出准确的判断。否则就会造成很多工作的处理结果，犹如隔靴搔痒，劳而无功。
+
+最近几年流行的短视频和视频直播应用，各家比拼的体验中，秒开就是一个技术上追求极致的例子，就是在细节上的深入探究和改进。
+
+秒开是指手机视频应用中显示的视频，只要点播放，1秒内就要完成视频的下载并播放。要做好这个体验，需要把点击播放、下载视频、首次播放等环节的处理时间记录日志，并进行分析，来决定哪些环节需要优化来缩短处理时间，这种分析往往会沉淀为日常的机制，确保秒开比例保持在高水平。
+
+为了提高秒开比例，除了手机客户端应用作优化，我们白山云作为视频分发的CDN服务商，也需要让速度变得更快，尤其是快速填满客户端上视频播放缓冲区。
+
+对于这个目标，开始团队做了一些改进但是没有大的突破，后来我们的技术VP苗辉作为技术专家亲自参与和组织，通过对TCP/IP和网络传输的深入研究，优化TCP重传、窗口拥塞、慢启动等机制，整体上加快客户端视频下载速度；通过智能DNS的动态IP库和四维调度算法优化，更实时的把用户调度到网络质量最优的CDN边缘节点。那么结果怎么样呢？根据我们一个CDN客户提供的数据，其直播客户端首次播放时间稳定在450毫秒左右，远远小于1秒。
+
+抓住细节的“七寸”
+
+既然关注细节如此重要，是不是技术管理者就应该深入了解每一个细节？这是一部分管理者尤其是初级管理者经常会遇到的困境，关注细节本身没错，但前提是抓住大的，再聚焦小的，找到影响整体工作的关键细节，以免自己被细节缠身。
+
+2014年我还在前东家时，曾经参与过微博客户端图片和视频的加载性能优化，当时的问题是运营部门经常抱怨，总是说用户投诉图片点开显示慢，或者打不开。客户端团队和存储、CDN团队做了一些排查和优化，但还是有用户投诉，大家就很疑惑这到底是不是个严重问题？问题在哪里？怎么改进？
+
+当时也是有一些性能监测数据，但是不能直接反应用户端体验，运营部门不认。当时我负责的微盘云存储应用，通过采集客户端性能数据，做性能持续优化，所以我提出先建立微博用户端性能的量化评估指标，比如加载时长、成功率，确保各个业务方都认可这些指标，这相当于大家有了统一的性能标准。
+
+当时先和业务运营方负责人沟通定义好客户端加载性能的几个一级指标，然后推动建立了客户端性能数据采集机制，建立全面的性能数据分析体系，以及不同环节的性能类和质量类二级指标体系，覆盖客户端到服务器端、和多家CDN。一级指标主要用于运营方评估用户体验，二级指标用来监测各个技术系统的性能质量情况，二级指标对一级指标有重要的影响。并且在我负责的部门内指定了各指标相关的责任人，具体的工作由他们去负责落实、并且为指标达成负责，这样工作就分解下去了。
+
+通过合理的工作安排，和我在重要细节上的关注和参与，最后的工作成果让大家非常满意，有了清晰的数据体系，还消除了很多工作上的争议。经过半年时间持续优化，图片下载速度加快了25%；对于用户投诉，也能够提供量化的错误率数据，基于用户帐号可以检索全部的服务端日志，以及客户端上报的错误日志，还能排查出是客户端软件异常、手机网络异常、运营网络异常、还是服务器端异常，这些信息对于解决问题和改进产品的帮助也很大。
+
+让细节的“病毒”感染你的团队
+
+只有技术决策者关注细节是不够的，业务上的很多细节，是需要每一个人去关注去抠的，只有这样才能让整个团队重视每一个环节，尤其把重要环节在细节上做极致，才能给用户超出预期的体验。这种对细节的态度，不是每个人天生就会的，而一个业务的负责人，如果能够具备这样的素养，把这样的态度融入在工作中的每一个环节，影响到团队中的每一个成员，就可能培养出更多具备这种能力的员工。
+
+如何打造一个重视细节的团队，我再分享几点经验。
+
+首先，做好招聘环节，更倾向本身就关注细节的人，面试时多问问候选人工作中细节的问题。关注细节体现在不同的方面，关注代码的质量、风格是细节，关注产品的技术方案是细节，关注产品的上线流程是细节，关注业务的成本构成也是细节，关注业务的运营数据更是细节。
+
+其次，通过自己不断对细节的把控来影响团队、树立榜样，尤其对重要事情的细节上斤斤计较，提出细节上的问题，参与细节上的改进，当然，你更多的是分析、沟通、决策，具体的工作更多的是团队来落实。
+
+然后，带领团队梳理流程和方法，通过流程规范的完善，使团队成员更能关注细节，这点再展开说一下。
+
+工作的发展，也是不断完善和细化的过程，比如业务最开始，最先解决的是核心的功能，仅仅满足能用。而在发展过程中，随着业务要求的提高，之前很多没有做的工作就逐渐提出来了，比如运营、质量、监控、流程等等，这些工作的落实，都需要负责人参与到细节中去。
+
+比如去年初，白山云因为一些重大项目推进中的问题，决定建立项目管理机制。一位同事起草了初步的项目管理方案，通过讨论和完善方案，最后定下来项目管理机制、项目需要的文档、立项结项需要的文档等，这些我也仔细看过并且确认。制度确立后，前期的几个重要项目立项，我也参与，一方面是观察团队的接受程度和执行情况，一方面也需要了解制度是否还有些问题。几个月后，我就只关注重点项目的周报、月报，关注项目本身的细节，而不在于项目管理制度的细节上了。
+
+随着项目管理方法被更多团队接受，很多工作的细节就更有保障了。还有其他如客户需求管理、故障管理、变更管理、变更流程等机制的建立完成，让整个团队的工作能力得到提升，在工作上更加有序、也更可控。对于细节的重视，被融入在各个流程机制中，未来随着业务变的更加复杂、团队规模更大，我相信也能保证各项工作高质量的输出。
+
+结语
+
+关注细节，就体现在日常的管理工作中，你了解的细节越多，对工作的问题看的就越准确，管理工作才能做到有的放矢。
+
+深入细节，既是你观察、培养人才的过程，也是团队磨合、建立信任和默契的过程。对于达到稳定的业务，或者配合很默契的下属，你就充分放权，不必太多关注细节，把你省出的精力投入在其他地方。
+
+如果所有的问题，团队都能帮你搞定，那你自然不用太关注技术的细节。但是实际情况不会这么乐观的，总会有一些团队自己搞不定的事情，所以这才是你作为技术决策者存在的价值。
+
+作者简介
+
+童剑，白山联合创始人兼首席技术官，TGO鲲鹏会北京分会董事会成员&学习委员。前新浪研发中心总经理，2016 年 5 月加盟白山，迅速搭建和完善各产品线技术梯队，构筑云链产品技术体系，带领团队推出云存储、云聚合产品，助力白山抢先布局云后市场。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/027如何在不同组织文化下推行技术管理.md

@@ -0,0 +1,93 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            027 如何在不同组织文化下推行技术管理
+                            2016年初，我从一家互联网视频公司出来，那个时候就感受到移动互联网创业达到了顶点，人口红利已经吃尽，2C端的流量趋于饱和，新的现象级的App难以出现，并且受到BAT的严重挤压。这时很多传统企业都在谈数字化转型，希望利用云计算大数据等IT技术帮助企业转型。我本人接到了很多公司的邀请去构建行业的云平台，来自汽车、医疗、教育等行业的都有。同时我看到业内甚至周围一些朋友也从互联网公司加盟了传统企业，这里面有做的比较成功的，比如平安科技、链家网等等，但也有很多人遭遇了诸多挑战甚至很快折戟沉沙。
+
+最近两年，我先后在两家传统企业集团担任技术高管，目前在海航的科技子公司易建科技担任技术副总裁，主管上千人研发团队的技术体系以及云服务事业群整体管理。在此分享一下如何适应不同企业文化下的技术管理，有哪些挑战与机会。
+
+传统企业VS互联网：面临的挑战
+
+通过这两年多的经历，我发现传统企业在诸多方面跟互联网企业还是存在很多不同，对技术高管推行技术管理会带来很多的挑战。
+
+从组织架构上来说，很多互联网公司都是比较扁平化的管理，尤其几年前小米倡导的三级制管理。一般技术产品团队都归CTO统一管理，以业务为导向，底下分为技术、产品、运营及运维几条线。而传统企业大多采用事业部制，事业部有独立的人财物的权利，研发团队以成本为导向。公司层面没有CTO，或者各事业部的研发团队虚线向CTO来汇报。这样就造成各事业部通常都各自为政，技术力量比较分散，没有统一的技术体系，各事业部的研发团队只关注自己的绩效，相互之间很难协同。最后造成整个公司形成了大大小小的技术孤岛，也不容易有核心的技术积累。
+
+从激励机制上，互联网企业更看重技术产品人才的创造性，加上近年来创业资本的助推，工资水平较高，同时也会采取股权期权的形式激励。而传统企业通常更看重资源资本的因素，对技术人才的重视程度相对不够，更多的是采用项目奖金的方式激励，工资平均水平较低。这个时候从外部引入互联网人才，工资低了没有吸引力，工资高了，容易形成倒挂，对内部老员工心理上会造成很大冲击。
+
+开发模式上，传统软件开发团队一般采用瀑布模型，对新需求响应比较缓慢。互联网开发团队通常采用敏捷开发，注重小团队作战以及快速迭代。同时互联网公司由于发展比较迅速，人员新陈代谢比较快，可以迅速组建团队，人员也比较年轻。而传统企业进人流程相对缓慢，对学历要求较高，有严格的背调机制，同时也很少主动做人员淘汰，人员平均年龄比较大。这个时候如果沿用在互联网公司一套管理手段，可能会面临水土不服。
+
+个人的经历与收获
+
+互联网技术高管进入传统企业需要考虑如下问题：如何打通技术体系；如何引入新技术；技术人员如何更好的成长；如何调整管理方式。
+
+我本人经历的某家企业是个传统的集团型企业，该企业是一个传统的从事系统集成的集团公司，涉及的领域包括校园支付、身份认证、智能交通等，集团新的战略希望利用线下的优势，尤其是在高校领域行业第一的占有率，孵化新的线上业务，进行互联网转型。
+
+公司管理层下了很大决心来进行互联网转型，在集团层面一年投入了上亿的预算，成立了专门的PMO组织，请了业内顶尖的咨询公司做业务规划，并成立了专门的技术产品团队，构建了整套的私有云平台和微服务架构。并落地实施了首例校园支付App。
+
+但由于上面提到的组织架构，人员激励，团队配合等诸多问题，新的技术和产品未能得到有效的推行和利用，新团队也很快瓦解。
+
+吸取之前的一些经验教训，在目前公司管理层的支持下，我作为技术副总裁，在一年之内推动了如下的一些工作：
+
+
+技术体系的构建
+
+
+我目前所在的公司分为三个大的事业群，每个事业群有自己的技术总监。事业群A负责集团的大IT，事业群B负责IDC和云平台，事业群C负责智慧科技。我们的专家委员会由各个事业群技术总监，及他们提名的各事业部的技术专家组成。有定期的会议和月度的技术分享。
+
+通过一年的运行，各个事业群形成了各自的技术体系，同时在公司层面三套技术体系有了边界和融合。事业群A和B有了比较明确的边界，A构建IT的大中台，而B主要聚焦在IaaS和CaaS平台。C事业群则主要对外，利用AI技术向各个事业部的行业赋能。同时，我认为在一些局部，适度的重复和冗余是必要的，比如我们两个事业群都有一些大数据方面的团队，但各自的场景还是有很大不同，没必要强行去捏合，但是彼此可以有技术的交流和促进。
+
+同时专家委员会由各个事业群轮流，对各自领域的技术进行分享和推广，一年之内我们陆续介绍了云计算、大数据、AI、分布式数据库等主题，也邀请了很多外部的专家，得到了技术人员的踊跃参加和不错的反馈。
+
+另外公司也有比较好的技术投入的传统，在新的技术体系之下，我们通过研发评审，对重点项目进行了财务补贴，这样事业部能够减轻收入利润的压力，加大技术投入。
+
+
+新技术的推动
+
+
+即便有了技术体系和技术分享等常态化的机制，推动新技术也会遭遇很多阻力，比如技术人员的学习成本，比如需要其他业务板块甲方的认同等等。这个时候需要利用一些时间窗口和契机。比如集团去年对信息安全比较重视，投入也比较大，我们迅速组建了安全团队，在人员设备各方面做了相应的投入，得到了各方的认可，同时也顺势把这块的技术体系提升了一个台阶。
+
+安全本身也不是孤立的一块技术，和IDC云平台都有很大关联，这块的提升也会暴露出其他方面的一些短板。在问题暴露后，我们迅速调整了变更流程和协同机制，也通过春运两会博鳌等一系列的重大保障的检验，使新的技术进入了稳定期。
+
+
+管理方式的调整
+
+
+在公司每个事业部负责的业务和技术的挑战不同，就像Gartner所提的双模IT理念类似，确实有传统IT和敏捷业务并存的情况。所以我认为没有必要强行来推动敏捷DevOps等理念，允许不同团队选择适合自己的开发机制。
+
+另外对于不同团队，也应该有不同的激励手段。对于发展比较迅速，人员比较年轻的团队，多运用正向激励。而对于情况相反的团队，可能负向激励会比较奏效，技术高管需要有自己的判断，灵活运用。
+
+开展工作前先考虑这些
+
+总体而言，我觉得互联网出身的技术高管在进入新的组织文化，尤其是传统企业时需要考虑如下方面：
+
+
+业务机会
+
+
+比如云计算这个领域，公有云的机会已经不多了，如果帮助传统企业构建行业云，实力雄厚的企业集团相对更有耐心，能够保证长期持续的投入。同时大的企业品牌知名度较高，人才基础比较好，能够提供比较好的人员支撑，也有利于组建新的团队。技术毕竟是为业务服务的，如果没有好的业务机会，技术再厉害，也没有很好的施展空间。
+
+
+管理层的支持
+
+
+公司的管理层需要对技术有合理的预期，重视技术的长期价值，不急于短期见效。同时管理层对公司的发展历史比较了解，能够对技术的落地给出比较好的建议。技术高管应该虚心听取其他高管的意见，结合自己的技术背景来采取合理的方式推行新技术。
+
+
+碎片化到体系化
+
+
+传统企业在多年的发展历程中，已经形成了成熟的业务和组织架构。期望一个完美的战略和一步到位的落地是不现实的。但我觉得长期的机会还是存在的，也是值得很多技术高管去尝试的。毕竟看到你的技术能够支撑一个千亿甚至万亿的企业集团的数字化业务，这种成就感还是不言而喻的。但我个人认为这个重塑的过程必定是碎片化的，量变引起质变的。这些碎片需要我们一点点去寻找和拼凑，直到引发整体变革的那一天。
+
+写在最后
+
+酝酿本文的过程中，正好看到了中兴被美国制裁，以及陆奇从百度离职等消息，感触良多。我本人非常幸运，成长经历中得到了中科大清华很多老一辈的指引，对技术抱有很大热情，少走了很多弯路，但仍感觉跟老一辈还有很大差距。已近不惑之年，深感我们这一辈还是需要有点家国情怀，相信技术能够改变世界，并贡献一份绵薄之力，共勉。
+
+作者简介
+
+钟忻，易建科技技术副总裁兼云服务事业群总经理，TGO鲲鹏会北京分会会员。2003年清华大学自动化硕士毕业。曾在Turbolinux、IBM、Intel等多家IT公司担任资深软件工程师。13年底到16年初担任乐视云平台高级总监，主导了乐视IaaS、PaaS平台从无到有的全过程。目前负责易建科技上千人研发团队的技术体系的搭建，以及整个海航集团的IDC和基础云平台的产品研发、运营和市场开拓。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/028业务高速增长期的团队管理：知轻重、重绸缪、调缓急.md

@@ -0,0 +1,83 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            028 业务高速增长期的团队管理：知轻重、重绸缪、调缓急
+                            作为企业的技术管理者，如技术总监、技术副总裁或是CTO，必定会期望企业业务快速发展，这样技术团队对业务的价值才能最大程度得到体现。但业务的爆炸式增长将不可避免地带来组织结构的变化和管理上的挑战，那么作为技术管理者，你是否做好了迎接这些挑战的准备？
+
+本文将结合我过往在创业公司以及大公司新业务扩张时期的经历，来讲述如何在企业快速成长时做好技术团队管理，我将通过“再识技术管理”来聊聊对技术管理的理解，再通过“边开飞机边换引擎”来聊聊企业快速成长时技术团队管理面临的挑战，并给出一些管理团队的建议。
+
+再识技术管理
+
+技术管理者大多都是从技术专业人才转变成为管理者的，极少情况下存在着没有技术背景的技术管理者，一般都是在企业发展过程中，需要在专业能力或业务贡献上已经被证明过的技术专业人才来成为技术管理者，期望他们将自身的业务能力进行复制，带给整个团队，以让企业的技术团队正向发展。晋升为技术管理者，这是一个令人振奋的新角色，但同时也需要不少新的技能和能力来面对这个职位带来的挑战。我们先来看技术专家与管理者在日常工作输出上的区别：
+
+技术专家
+
+
+与产品、QA团队日常撕
+分析业务需求并制定技术方案
+编写代码实现功能需求以及修复bug
+解决线上故障或突发问题
+经验知识沉淀及技术学习
+
+
+管理者
+
+
+设立团队目标、制定工作流程
+协调必要资源来支持团队、并与其它团队保持良好沟通
+观察团队工作进展、向上输出业务进度报告
+招募并培训技术人才
+评定团队成员业绩
+
+
+从上面对比不难发现，这两个角色实际是从不同角度来看相同的业务挑战，因此日常需要完成的⼯作内容是完全不一样的。简而言之，技术人才或技术专家是面向任务来工作，而管理者或经理的角色是面向人来工作，他是要驱动激励团队来完成业务需要，并根据公司远景来提前布局。
+
+边开飞机边换引擎
+
+在业务高速发展的公司，例如创业公司B轮融资后开始冲业绩、又或是被媒体报道后的激增，一般业务量会有几倍甚至于几十上百倍的增长，这取决于公司的业务模式，这时企业的技术团队将面临巨大的挑战，比如业务系统能否抗住高并发、业务系统的响应速度以及业务代码是否存在影响严重bug等。这里我们要聊的是在这种情况下的技术团队管理该如何做，所以我们不过多关注具体的细节问题，而要以管理者的角度来更加全局性地来审视这样情况下面临的核心冲突或矛盾是什么。
+
+大家会经常听到的一个比喻是“边开飞机边换引擎”，这个比喻十分形象地将这种困境描述了出来，我们简化来看这个困境，实际面临的是两个问题，一个是时间，我们需要驾驶这架飞机在最短的时间内安全到达目的地；另一个便是资源，我们拥有的飞机就只有这一架，并没有其它备用飞机提供给我们来进行替换使用，因此我们只能在这架飞机上进行修修补补继续飞。
+
+不难看出我们在企业高速成长时技术团队管理面临的两个核心矛盾或问题就是时间和资源。时间上的矛盾在于业务系统开发和完善、以及技术储备等都需要时间来进行开发维护以及沉淀，但业务增长的速度和时间窗口并不会给技术团队以太多喘息机会，那么在这个时间矛盾下，怎么做好技术团队管理呢？精简来说就是“知轻重、重绸缪、调缓急”，如何理解呢？这种情况下时间对于企业、团队和个人来说都很紧张，因此技术管理者如何分配时间便很关键，如何分配时间和资源也将决定了技术团队的发展趋势和业绩输出，所以做到“知轻重、重绸缪、调缓急”是很关键的。
+
+管理者需要从公司业务未来发展趋势上来做规划，进而来看自己所负责事情的轻重缓急，例如招募并培训技术人才、 Code Review、设立团队目标、制定工作流程这样的事情，对于企业和团队来说是至关重要的，但是并不会马上有明显产出。但需要持续坚持做，是利于长期的事情，那么我们到底该怎么从众多的事务中来做区分呢，下面我们先看一张图：
+
+
+To Do轻重、缓急象限图，以及典型事务分布
+
+从上面象限图来看，作为技术管理者我们应该怎么分配时间和资源呢，以下是我简单的总结。
+
+
+重要紧急：
+得做，但要避免做。例如线上故障解决，这种问题重要又紧急，可能目前只能你来处理，但是应该是有各种故障后备用方案，让团队成员去实施，先保障业务然后团队再进行问题定位。
+重要不紧急：
+坚持做。例如人员招募培养、组织架构调整、Code Review以及技术踩坑分享等，这些事务做了不会马上产生收益，坚持做的话日后收益会很大。
+不重要紧急：
+让团队成员做。将锻炼机会留给团队成员，自己做好支持工作。
+不重要不紧急：
+不要做。在时间和资源有些许喘息机会时，可以安排成本低的方式来处理。
+
+
+因此，技术管理者应该未雨绸缪地将未来发展所需事务列举出来，也就是说要有技术管理者的远见，然后再将目前要处理的事务列举出来，放置在上面的象限图中，你需要关注的一个象限是“重要不紧急”，另外需要培养团队成员来处理的两个象限事务是“重要紧急”和“不重要紧急”。象限里的事务并非是固定的，会产生事务移动的情况，有些移动是需要技术管理者自己总结和主动发起的，最后跟大家分享两个小案例，希望对大家有些启发。
+
+案例一：运营活动支撑，“重要紧急”变为“重要不紧急”
+
+之前公司有做过一款社交App，运营同学定期会进行运营活动策划，例如情人节、春节、七夕等，活动类型比较多且比较频繁，涉及到活动广告位、活动着陆页、活动参与页、活动结算以及App内状态标识等诸多App内相关的修改变更。 对于社交App来说，运营活动能够提升客户活跃以及营收，属于是“重要紧急”的事情，一般来说都是分配1到2位开发人员进行运营活动的开发工作，开发⼈员一般不太愿意接这样的活，因为技术挑战不大且重复性工作较多，面对这样的矛盾局面，我们是怎么处理的呢？
+
+很明显这样的运营活动一定会持续办下去，那么将“重要紧急”变为“重要不紧急”就尤为重要了，然后我们在研发团队内部立了个小项目——“运营活动定制系统”，对于过往经常使用的运营活动策划手法进行了总结整理，可以将App 内广告位、着陆页、活动参与页以及状态标识修改等诸多内容可以通过该系统进行定制，通过运营、iOS/Android、前端、服务端同学的一起参与，将该项目开发完成，运营仅通过后台便可以完成常规活动的定制、审核以及发布。
+
+案例⼆：提前部署组织架构调整，典型的“重要不紧急”
+
+企业业务初期时，业务线比较少，一般研发团队组织架构按照岗位职责来划分，例如前端团队、服务端团队、运维团队以及客户端团队等。但随着业务不断的发展，会出来很多的子系统和产品，例如产品A、产品B、内部运营系统以及数据可视化系统等，这时按照职能划分团队方式的弊端就很明显，研发团队成员需要身兼多项工作任务，如何在各项工作任务之间弄清楚优先级，会出来很多扯皮的现象，并且团队越大，团队负责人专门的管理成本会升高。
+
+面对上述问题，通过提前部署好组织架构调整，可以进行化解。我们先将运维、 数据、服务端团队划分部分人员到基础服务团队，将前端、服务端、客户端团队按照项目组来进行划分，项目组里加上运营、产品团队成员来形成小团队，降低内部沟通成本，提升组织运作效率，同时研发团队绩效考核上会加上项目组业务的权重评分，这样保证项目组目标一致高效运作。
+
+作者简介
+
+刘俊强（微信公众号：程序员精进），现任腾讯云资深架构师，TGO鲲鹏会深圳分会会员。曾任迅雷技术总监、某互联网公司技术副总裁。10+年以上互联网开发经验，8年以上技术管理经验。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/029被8成的人误解的工程师文化.md

@@ -0,0 +1,138 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            029 被8成的人误解的工程师文化
+                            软件开发是一场需要集体智慧的运动，它的成功不完全属于团队中任何一个人。然而，团队成员们做人做事的风格却不完全一样，因此我们需要一种叫做“团队文化”的东西，通过它让大家的心聚集在一起，齐心协力完成目标。
+
+本文将从团队文化入手，站在软件开发的角度，讲述工程师文化是如何打造出来的。文中会包含一些可立即落地的实践方法，大家可根据自身实际情况，灵活运用。
+
+下面，我们就一起聊聊关于团队文化的那点事儿吧。
+
+什么是团队文化？
+
+我们认为，团队文化主要包含以下三个方面：
+
+
+团队气氛
+做人原则
+做事方式
+
+
+我们先说“团队气氛”。我们每个人都希望团队有个好的气氛，都不希望气氛变得糟糕，因为气氛糟糕会让人的心情变得糟糕。我们的工作性质决定了，我们每天都要与人协作和沟通，如果缺乏好的团队气氛，合作关系将变得冷漠，工作也将失去激情。
+
+然而，营造好的团队文化，起到决定性作用的就是团队领袖。公司就是一个最大的团队，公司文化取决于公司老板。道理很简单，团队成员能否加入这个团队，是由这位团队领袖决定的，他决定了人的构成，人决定了团队的气氛。
+
+团队文化也包括“做人原则”。坦率地说，团队中每个人的性格可能不尽相同，性格必然多元化，性格也必须求同存异，同类型的人只会让团队的短板更加明显。我们相信，没有完美的个人，只有完美的团队。但是，做人原则与人的性格不同，做人原则是态度和行为的根基，如果这个根基就不对，那么也很难做成一件成功的事情。
+
+团队领袖就是团队做人原则的根基，他说的每一句话，做的每一件事，团队都看在眼里，大家都以他为标准。如果团队领袖是一位正直的人，那么邪恶的人也无法留在他的团队中。正所谓，物以类聚，人以群分。
+
+做人原则决定了“做事方式”。如果团队都是性格直爽的人，那么一定是有话直说，对事不对人；如果团队都是溜须拍马的人，那么一定会让领导笑口常开，用表象去掩盖事实。不得不说，在一些互联网公司中很多老板（也包括一些领导），他们很喜欢看数据，很相信数据，认为公司是一家数据驱动型企业。如果没有一个求实的企业文化，员工就会拿数据来欺骗老板，因为老板相信数据，员工就会给老板看到数据。
+
+事情做不做都在那里，做的方式不同，效果也会完全不同。一位求实的员工，一定会用数据说话，但不是单纯地给老板看数据，他会将数据背后的本质原因分析给老板听，帮助老板正确地做出决策。团队的做事方式同样也取决于团队领袖，他是怎样的人，就会带出怎样的团队。
+
+综上所述，团队气氛、做人原则、做事方式这三点构成了团队文化，而且这三点都由团队领袖来决定，如果你就是这位团队领袖，不妨思考这样三个问题：
+
+
+你想要怎样的团队气氛？
+你的做人原则是怎样的？
+你的做事方式是怎样的？
+
+
+把以上三个问题的答案写在纸上，反复思考自己是不是这样的，想明白后就去亲自实践，用写下来的这些准则去要求自己。当自己违反了这些准则时，思考为什么会这样？到底出了什么问题？
+
+我曾经写过以下 5 条行为准则，自己一直都在努力践行，这些也是我们的团队文化。
+
+守信 —— 为自己的承诺负责
+
+进取 —— 勇敢面对新的挑战
+
+高效 —— 追求高效工作方式
+
+学习 —— 不断学习新的技能
+
+分享 —— 乐于分享个人收获
+
+其中，守信是做人的原则，进取是做事的态度，高效是做事的方式，学习是对自己的要求，分享是对团队的贡献。
+
+需要注意的是，团队文化必须体现在平时的日常工作中，通过文化来影响整个每个人，通过文化来指导团队的行为，通过文化来融入更多的新人。团队文化不是喊出来的口号，也不是贴墙上的标语。只有我们心中认可的文化，才是真正的团队文化。
+
+既然我们都是软件工程师，那么我们也需要有自己的文化，我们需要的是“工程师文化”。
+
+什么是工程师文化？
+
+弹性的工作时间、优雅的办公环境、穿着自由且随意、做自己喜欢的工作、工程师们说了算……这些是工程师文化吗？显然不是，这些只是工程师文化的表象，而非本质。学习工程师文化，一定要抓住本质，否则舍本逐末，不伦不类。
+
+有些互联网创业公司，对外号称弹性工作时间，但当员工做完当天工作并按时下班时，老板却认为这些员工不够努力，他们都在打工，而不是在创业，老板因此感到心寒，但束手无策，只能在内心里埋怨。当这样的事情屡次发生后，老板对员工会产生更加强烈的不满，离员工的距离也会越来越远，从而不再信任他们。
+
+我有一位朋友，他在一家公司做技术高管，公司提倡工程师文化。他的老板经常对工程师们说：“大家白天写代码，晚上可以做业务嘛，这么早下班回家干嘛呢？做业务的同事天天加班到深夜，凌晨给他们发微信，他们都是秒回的”，当老板说出这句话时，也就注定了，这家公司不可能拥有真正的工程师文化，他们公司所号称的工程师文化其实都是表象，老板根本就不理解工程师文化，公司也留不住优秀的工程师。
+
+果不其然，这位技术高管无法承受老板的态度和行为，选择了主动离职，他的离开影响了整个技术团队的稳定性，导致优秀工程师大量流失，公司业务也受到了影响。
+
+我们认为，工程师文化是以共同解决实际问题为目标的团队文化。工程师文化并非由工程师们自发创建，更不是工程师们的一种自嗨行为。工程师文化是由企业文化所决定，企业文化由老板所决定，老板必须理解工程师这样的人群，才能把合适的工程师放在合适的位置上，才能真正领悟工程师文化的真谛，才能做成一家真正的互联网产品技术型公司。
+
+可以抽象地认为，工程师文化只是一个代号，一种象征。工程师文化强调的是团队有目标、有分工、有协作，而且团队所解决的是当前面临的实际问题，并非是一些不切实际的目标，更不是加班这种表面上的东西。
+
+工程师文化并非一个人或几个人就能打造起来的，需要公司老板以及高管们的认同，自顶向下的影响并鼓励自己的团队。老板必须懂得工程师这个职业，必须深刻理解工程师文化。
+
+怎样打造工程师文化？
+
+如果你是一位技术负责人，你的老板却并太不懂技术，你很希望打造出工程师文化，这样对外容易招聘，对内也能让团队更加融合，工作更加高效。此时你需要掌握正确的操作方法，才能打造出良好的工程师文化，否则后面迎接你的将是一场噩梦。
+
+你要做的第一件事情是，让老板理解软件开发是一项工程，需要工程师们一起合力完成，还要让老板看清工程师的价值。因为在不懂技术的老板眼中，工程师的成本是相当昂贵的，他们做的东西自己又看不懂，不知道钱花得有没有价值，工程师们每天都在做什么？为何做一个项目不能直接开干，还要先去估时？估时会不会有水分？
+
+我们必须站在老板的角度去理解他，把他心中的这些顾虑全部排除掉，让他觉得软件开发是一项伟大而复杂的过程，需要工程师们用科学的方法来避免风险，从而让项目得以顺利交付。很多技术负责人可能都忽略了这个过程，导致后面做的一系列事情，老板都看不懂，也不认为有价值。
+
+当你让老板理解了软件工程以及工程师价值以后，接下来可以做以下几件事情：
+
+
+让团队扁平，自己和团队一起工作
+没有 Leader，只有 Owner
+没有“你们”，只有“我们”
+一切都以数据说话，分析数据的本质
+可以加班，但拒绝无意义的加班
+
+
+以上这些观点，首先你需要确保自己能做到，你的团队才会做到，你才有可能打造出真正的工程师文化。
+
+接下来，你需要不断培养队员们的软技能，其中有 3 点非常重要的态度，这些态度决定了团队做事的行为：
+
+1、主动担当任务，并非被动等待
+
+2、具备用户思维，产出有用成果
+
+3、具备服务意识，乐于帮助同事
+
+除此以外，你还可以考虑做到这些事情：
+
+
+让大家成为朋友
+缩短项目迭代周期
+为每个项目找到 Owner
+选择最合适的技术
+技术尽可能自动化
+注重代码质量
+建立开放与共享
+预留学习时间
+不追究任何责任
+只招最对的人，不招最贵的人
+
+
+你可以组织一些有意思的活动，比如：茶话会、小黑屋、经验分享、内部演讲、摄影比赛、话题辩论、体育活动、健身、户外运动、技能培训、读书会、黑客马拉松等，只要对团队成长有帮助的活动，你都可以去大胆尝试。
+
+写在最后
+
+打造一支高效的研发团队，我们至少需要关注四个方面：组织架构、研发流程、绩效考核、团队文化，这四点缺一不可。其中，团队文化是至关重要的，它是团队价值观的主要体现，是大家做人做事的行为准则。
+
+我们非常提倡工程师文化，但也要有正确的方法去打造工程师文化，需要让自己的上级产生信任感，也要让自己的下级产生幸福感，我们必须做到这些，才能打造出真正的工程师文化。
+
+我已在《技术领导力300讲》发表了 4 篇关于“打造高效研发团队”的系列文章，这几篇文章的内容还比较片面，不一定能完全帮助大家解决现在所面临的问题。深知自己水平有限，但我愿意分享，愿意和大家交流成长的点点滴滴，还请大家不吝赐教。
+
+作者简介
+
+黄勇，现任特赞科技（tezign.com）CTO，图书《架构探险》作者，Smart 开源项目作者，TGO鲲鹏会上海分会董事会成员，QCon 讲师。十年以上互联网软件架构与技术管理经验，擅长敏捷开发，推崇“轻量级”架构思想。喜欢阅读，热爱交流，乐于分享。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/030关于工程师文化的六个问题.md

@@ -0,0 +1,92 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            030 关于工程师文化的六个问题
+                            说到工程师文化，很多人会马上想到 Netflix、Google、Facebook等知名的硅谷科技公司。如果一家公司的“工程师文化”备受推崇，大家往往会觉得很羡慕，但是到底什么是工程师文化，我们为什么需要工程师文化，却没有多少人说得清楚。今天我们就通过几位技术高管的视角，来重新审视这些问题。
+
+问题一：工程师文化能够令一家公司获得成功吗？
+
+答题人：风投公司Andreessen Horowitz联合创始人及合伙人Ben Horowitz
+
+如果你去问10个创始人，什么是企业文化，你会得到10种不同的回答。比如企业文化跟办公室设计和筛选不合适的员工有关，企业文化牵涉到价值、乐趣以及人员配合，企业文化就是寻找志同道合的员工，企业文化就是要像宗教一样的狂热崇拜。
+
+在探讨这个问题之前，我想说，任何技术初创企业都必须要做的一件首当其冲的事情是，开发出这样一款产品，它做某件事情达到的效果至少要比目前市面上的通行的方式好10倍。好2、3倍还不够，因为那样大家切换到新事物的速度和规模都会不足。
+
+任何技术初创企业必做的第二件事是占领市场。如果说你把某件事做得比原来好上10倍是有可能的话，那么能做到这一点的公司不止你一个也是有可能的。因此，你必须在别人也做到了这一点之前先占领市场。能够比竞争对手好上10倍的产品少之又少，所以，废黜其他窥伺王位的王子要比让老国王退位困难得多。
+
+上述事情如果有一件你办不到，你的文化就会变得一点重要性都没有。这个世界到处充斥着拥有世界级文化的破产公司。文化并不能造就一家公司。
+
+那么，我们还要谈文化又是何苦呢？三个理由：
+
+
+文化关系到你实现上述目标的程度。
+随着公司的不断壮大，文化能够帮助你坚守自己的核心价值，让你的公司处在一个有利的位置，让它未来的表现更好。
+也许最关键的一点是，在你和你的人历尽艰辛，用各种惨无人性的努力换回了公司的成功之后，如果你的文化却让你感觉到连自己都不想呆在那里的话，你的努力无疑将是一场史诗般的悲剧。
+
+
+问题二：为什么要强调工程师文化？
+
+答题人：团队协作软件公司Atlassian技术传播者Sven Peters
+
+产品时刻都在发展变化。在之后的几年中，一个你倾注过血汗和眼泪的产品可能会不复存在。不过，如果你能同时专注于创造健壮的团队和编码文化，你就能够时刻准备着，抓住出现的机遇。而且，发展强健的文化需要对团队所代表的立场达成共识，而这种凝聚力也会正向地反映到团队所构建的产品上。伟大的文化促成伟大的产品。
+
+人们通常会将文化可见的外部标志——免费食物、免费饮品、瑜伽课程、Aeron电脑椅、电视游戏、Nerf 玩具枪——错误地等同于文化。的确，许多公司，特别是科技企业都会提供这些很棒的福利，但是这与文化没有半点关系。文化是我们如何交流、工作、组织、荣辱与共。文化无法准确描述，但是它能够让员工更加快乐、更有生产力。如果员工害怕失败，公司等级森严，雇主把利润看得比员工更重要，即使有再多的免费食物和公务津贴也无济于事。
+
+在科技界有一个耳熟能详的故事，小型创新公司随着规模的增长会逐渐失去创新的能力。的确，大型组织与初创企业相比会更加结构化，缺乏灵活性，这会导致难以孕育开创性想法并使之浮出表面。文化如此重要的一个原因就是无论公司规模多大，它都可以帮助公司始终保持创新。
+
+问题三：如何让工程师文化体系化、可传承？
+
+答题人：微软CTO、前LinkedIn高级副总裁Kevin Scott
+
+在扩展研发团队的时候，最有价值的管理工具是文化宣言（cultural manifesto）。文化宣言是一个文件或一组材料，以帮助整个研发团队处在同一轨道上，让大家清楚如何做事情，以及如何作为一个团队运转。文化宣言是引领公司高速增长的锚。LinkedIn、Google和AdMob的文化宣言是完全不同的。因为不同地方的环境不同，在每一个地方所专注的要素也不同。
+
+如何建立一个文化宣言以引导和激励研发团队？
+
+
+不要等到灾难出现才开始行动。无视研发文化会不经意间产生巨大危害。起草一份宣言就是迈出积极的第一步。当危机来临时才决定开始写可能会非常困难，应该尽早开始腾出时间起草一份文化宣言。
+经常性地讨论和修改宣言。随着时间的推移，宣言可以作为一种优化研发文化的方式。不要指望公司开始存在的那一刻，你的文化就完美地与你的公司契合。由于每家公司的情况都有所不同，其文化宣言也必然不同，但是可以利用一个统一框架来讨论如何组建、操作和运行一个团队。
+寻求协调，而非达成共识。让每个人都在同一轨道上并不意味着让每个人都认同。因为文化宣言必定站在了某个立场，可能会不符合研发团队中部分人的利益，所以没必要让每个人都对宣言认同。文化宣言不是一份意见目录，而是一份打印好的承诺。
+明确界定研发的角色。市场能够帮助研发团队清楚地认识研发的角色。清醒地观察市场之后，研发的角色会变得清晰，即需要研发团队取得一切可能的先发优势以帮助企业占得先机，这在研发文化中应该得以明确。而且研发必须具有灵活性，即采用的技术平台可以让团队克服大量的风险并迅速采取行动。
+
+
+问题四：如何让价值观潜移默化地影响每个人？
+
+答题人：开源软件公司Redhat总裁兼CEO Jim Whiteh
+
+当行动和价值观一致时，组织文化就成一种积极的力量，推动组织更快实现更大的创新。当行动和价值观相背离时，就会发生相反的情况，组织就举步维艰。
+
+这里举一个例子。我最近参加了一个公司会议，其核心价值观就是安全。安全高于一切，它形成了公司所有决定的基石。当会议正式开始时，有人进入房间一本正经地向我们告知附近所有紧急出口的位置。这个人说：“在紧急情况下，我们将沿着以下路线疏散，在这个确定的位置重新集合”。
+
+没有人觉得诧异，每个人都觉得这个启动会议的方法完全正常、自然和有价值。事实上，如果会议没有这样开始，我怀疑人们会马上注意到并立即说出来。这家公司希望安全——这一核心文化的价值——无处不在。因此，它建立了安全无处不在的一系列可观察和学习的行为。
+
+对比这个例子，我知道每个人都至少看过一次，领导声称有价值的东西，却没有鼓励或强化它。价值只出现在行为中，行为取决于价值观。当同事加入组织时，他们会立即接受周围人的行动表达出来的的价值观。
+
+问题五：在公司规模持续快速扩张的情况下，怎样保护公司文化？
+
+答题人：在线网页制作工具Jimdo CTO Arne Roock
+
+文化是一种难以捉摸的东西。我见识过一些公司企图制定和控制本公司文化的失败尝试。在我看来，凭空制定自己向往的公司文化，然后指望据此建立一家公司，这绝无成功可能。在现实中，公司文化的来源正好相反，它已经蕴藏在公司的运转方式里面，重要的是从中鉴别出有效的成分，确认创始人和每位员工认为重要的方面，并找出需要加强或改变的地方。
+
+一旦确定了公司的核心价值观，写成书面的记录可以坚定公司的支持立场。接下来就要采取行动来滋养、强化和扶植我们树立起来的公司文化——首先从创始人自身开始，以身作则来影响其他人。
+
+文化的重要性说起来好像是个很玄的话题，但其实与我们的日常工作息息相关。每当遭遇困境，面对重大变化，或者招聘新员工的时候，我们总是可以停下来，问一问核心价值观可以怎样帮忙解决当前的状况。这个办法总能取得很好的结果，至今帮我们排解了诸多难题和冲突。我们真诚相信健康的公司文化是无价之宝，并且会大胆地投入在这上面。
+
+问题六：硅谷和国内的工程师文化差异在哪里？
+
+答题人：Twitter高级主任工程师王天
+
+工程师本身的人都没有什么区别，硅谷在之前那么多年的发展过程中积累下来一些很好的实践，普通工程师已经受到这些实践的训练，你觉得天经地义就是应该做的东西，或者搭一个东西要搭成什么样子，对底线的感觉不一样，国内对底线的容忍比较低，工程师文化的发展实际上是慢慢抬高这个工程质量底线。
+
+大家觉得硅谷有很好的工程师文化，实际上是因为大家在整个环境和社区的影响下已经塑造了比较好的底线，有共同的话语。国内这些话语在慢慢形成，硅谷和国内现在的联系也很紧密，当这些实践慢慢实施开的时候，国内的底线也会提高，工程师的环境也会更加活泼健康。
+
+现在国内非常活泼，那么多公司，那么多东西大家都在做，但是经验在传播的过程中有时候没有很好的积累下来，或者需要有人推动一下。科技媒体，还有整个社区的交流，这些都非常重要，在中国以前这些东西影响可能没有那么大。
+
+结语
+
+以上就是我们关于工程师文化的六个问题，和技术领导者们给出的答案。可以肯定的是，上述几位答题人都认为构建合适的工程师文化是必要的，并且应该坚定地贯彻下去。那么，你怎么理解工程师文化？你所在的团队有令你骄傲的价值观吗？欢迎留言与我们探讨。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/031五位技术领导者的文化构建实战.md

@@ -0,0 +1,106 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            031 五位技术领导者的文化构建实战
+                            昨天，我们一起了解了关于团队文化的一些事情。作为技术领导者，构建良好的工程师团队文化可能是你绕不过去的一个课题。今天我们就请5位过来人，讲述他们的文化构建实战经验。当然，由于每个公司对工程师文化的理解不同，这些经验不一定能拿来就用，但至少可以提供一种思路。
+
+中青易游CTO 张辉清
+
+我35岁前主要钻研技术，近几年逐步转向管理，带过几十人至一两百人的研发队伍。在最近的管理工作中，总结并归纳了几个可以贴到墙上的大字，即 “共治分享自视一起拼，简单有效快”。
+
+共治：共治就是部门要共同治理，自我管理和部门管理一起进行，每个人要管好自己，部门的共治我们希望能转化为个人的自治。具体形式有部门共治文件夹、轮值会议等；
+
+分享：因为专业所以自信，因为自信所以开放，因为开放所以分享。具体形式有周五分享日、书斋建设；
+
+自视：自视就是自我察觉，双眼反向注视着自己。对公司和他人的要求转化为对自己的要求，少一些抱怨，多找一些方法，如乐捐；
+
+一起拼：一起拼就是团队要一起拼搏，一起奋斗，一起喝酒、一起爬山，如户外、项目管理；
+
+简单有效快：把复杂的事情变简单，追求事物的本质，这就是简单有效。“快”是指快速地交付，快速响应业务的需求，如站立式会议等。
+
+当我们确定了这个阶段的部门文化后，团队氛围有了较大的改善，从死气沉沉到激情活力，从固步自封到好学分享，从互相推诿到勇于担当。在后期的几个大项目中，项目的成功显得自然得多，特别在新员工的融合上，成本也低得多。
+
+文化的构建并没有想象的那么难，也没有多少高大上。它也需要脚踏实地、土了吧唧，一步一步埋头干。先有管理工具、制度和行为措施，然后予以贯彻，形成一种习惯，最后才是总结提升。
+
+我们不能简单的参考大公司的做法，或者管理书籍上挑选几个词语，然后领导喊两声或挂在墙上。构建团队文化的过程就如同花朵或生物一般，需要播种、栽培，然后才能收获。这样「长」出来的文化，才能管人做事，深入骨髓、改变思想，才能成为公司或团队的核心竞争力。
+
+付钱拉高级架构师 周恒
+
+关于如何建立工程师文化，我们付钱拉团队的经验是，最好的方式就是把业务和技术结合起来，通过技术降低业务的难度，从而提高学习的时间。分享技术，让代码和思想都能得到升华。
+
+我们在团队内部通过工具化，框架化和实时重构，本质上简化了我们的运维成本，同时也提高了大家对技术的钻研兴趣，用学习的技术解决实际的生产问题。另外还有挺重要一点就是平时工作中多鼓励大家钻研技术，鼓励刨根问题，鼓励知识共享。鼓励思维创新，鼓励组建技术小组，攻克技术难点。开展黑客马拉松，强调竞争，合理奖赏。另外在工作之外，会组织一些游戏竞赛，一来放松心情缓解疲劳，二来团队合作增加彼此了解。
+
+其实工程师文化就是一种放松的，自我驱动的技术文化，在这种文化下，通过成员的自我创新，通过技术手段，降低工作强度，优化业务数据，将技术与生产的需要相结合，并做到极致，从而使人在这个环境中得到飞速成长，团队也飞速进步。工具化，框架化强调DRY原则，避免重复，提高工作效率。实时重构避免代码质量恶化，重新设计提升代码品质。技术氛围创造来良好的环境，促进工程师文化持久留存，人人受益，团队才会受益。
+
+出门问问CTO 雷欣
+
+作为一个核心团队来自于谷歌的初创公司，出门问问的公司文化很大程度上受到了谷歌工程师文化的影响。其中我印象最深的是，谷歌对代码质量的要求和追求到了一种近乎狂热的程度。
+
+那我们怎么在一个小的Start Up中间达到谷歌的代码质量呢？我有一些建议：
+
+
+坚持原则
+
+
+一定要坚持原则，坚持Unit Test和Code Review。
+
+Start Up的步伐、步调是非常快的，各方面的竞争也很激烈，你不快的话就会落后。在这种情况下的话，很多产品经理面对各方面的压力，可能会说“我只需要这个产品快速出来，我根本不Care你是怎么做的，你的代码质量、代码风格，Whatever，我不Care。”
+但实际上，，从公司的长远角度来讲，你把基础框架搭好之后，对以后的发展、稳定都会有很大的帮助。因此，在很大程度上，要坚持Unit Test、建立Code Review的机制，一定要保证你的代码是有一定质量的。
+
+
+拥抱开源
+
+
+第二点是要拥抱开源。实际上，谷歌是一个非常大气的公司，它已经把很多很好、很酷的内部的东西都开源出来了，我们要做的话，就只需要把这些东西积攒在一起，然后搭建一套更适合于创业公司的开发环境。
+
+
+鼓励更新、快速迭代
+
+
+很多时候，我们会面临一个问题，代码的第一个版本出来之后，我以后是在这个基础上修改呢，还是在一定阶段把它推翻了重来呢？
+
+谷歌内部基本上都认为，没有什么代码是能活过超过2、3年的，所以，会对代码进行推陈出新。实际上，在代码的推陈出新之间，会把以前没有考虑到的东西会做得更好，也会锻炼新人，然后学到更多东西。
+
+FreeWheel高级副总裁 容力
+
+拥有良好工程师基因团队的三点要素：
+
+1、管理人员必须要从技术第一线提拔而来
+
+如何从一线的工程师转成技术管理者，对个人和工程师团队文化来说都是非常重要的一环。我非常看重的的一点是，技术公司的管理人员一定需要从技术第一线提拔而来，这样才能让公司保持工程师团队文化，而且这种文化才具有与生俱来的某种技术特性。
+
+在我的定义和FreeWheel的文化中，转变为团队领导的人必须要在他的团队里具有最顶尖的技术水平，要能够服众。
+
+2、培育一种开放的文化：信息和思维双维度
+
+我们的开放主要体现为在信息维度的充分共享和在思维维度的创造激发。整个公司发展中，技术层面和商业模式层面的信息，可以在领导层和员工之间做到充分的沟通和共享，使得全员在任务处理上能更好地把握整体方向、理清事情的优先级，做对公司最重要的事情。另外，大家做事情都是本着平等开放的原则，不会因为说话的人不同，就对他提出的问题或者方案有不同的态度。这样做的目的就是要激发大家的积极性，充分发挥每一位员工的创造力。
+
+3、对Engineering Excellence的追求
+
+追求Engineering Excellence，是近期FreeWheel整个工程师团队的最大变化。在公司整体度过了生存期的挑战并进入到加速生长期时，我们要关注的事情，不再是到处救火，而是要追求卓越， 要打造一个可以在未来几年里，支撑业务发展的优秀技术平台。 在这个新的目标下，FreeWheel工程师团队也发生了不少变化，包括对Full Life Cycle Engineer理念的倡导，对CI/CD(持续集成/持续交付)等高效开发流程的探索和精进等。
+
+花虾金融CEO、前宜人贷CTO 段念
+
+作为管理者，我们会忍不住像游戏一样去设计规则，但这是不可能的，我们也不应该这样做。我们应该去强调约束，定义规则的边界，确保规则跟约束没有冲突。
+
+我们倾向于让团队成员自己以民主的方式形成自己团队的规则，我尽量不插手。当然，在团队发展早期，你也可以尝试为它设置一些规则，但你会发现这些规则很快就会被团队内部产生的新规则所替代。
+
+有些公司比较看重员工的一致性，尤其是思想上的一致性，统一的价值观，这点我是不认可的，我觉得统一思想这件事毫无意义。所谓共识，大致有三个层次：
+
+愿景。就是“什么该做什么不该做”。比如往页面上放广告，这事儿该不该做，大家会有自己的看法。
+
+价值观。就是“应该怎样做事”，在愿景之下，通过规则和约束体现出来。我觉得价值观不是贴在墙上的东西——越是贴在墙上反复念叨的，一般都是越没有的东西。
+
+规则与约束。这是在行为层面。规则是一个很容易被复制的东西，比如开发流程，你看到大家都用pull request提交，你也很容易跟着这样做。在这个过程中，价值观得到了强化。
+
+对于我来说，我更愿意大家在行为上一致，而不去追求思想上的一致。规则创建的过程应该是民主的，这个过程需要有冲突，有碰撞，有妥协——因为大家的思想并不一致；而规则一旦建立，则人人遵守规则。
+
+结语
+
+以上就是五位技术领导者在实践中总结的“工程师文化”的内涵及实施经验，可以看出来，不同公司的工程师文化确实存在比较明显的差异，相信也是在实践中慢慢演化而来。希望你也可以通过思考与实践，在你的团队中构建起最适合的文化。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/032文化是管理的那只无形之手.md

@@ -0,0 +1,59 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            032 文化是管理的那只无形之手
+                            文化是人类群体创造并共同享有的物质实体、价值观念、意义体系和行为方式，是人类群体的整个生活状态。对应到技术管理上，就是管理者对于大家意识的影响力，小到对于整个技术团队价值观，公司技术氛围、行为方式和状态的构造和影响能力，大到对于国内技术生态甚至国际技术生态的影响力。
+
+文化对于公司和部门管理非常重要，它是无形之手，决定了你团队的价值观是什么，你的公司能不能招聘到高级的技术人员，在我们日常流程和管理者眼睛看不到的地方，员工是怎样工作的。是否可以打造一个合适公司发展的技术文化，是否可以构造一个开放、透明的技术氛围，是否有能力建立一个MTP（Massive Transformation Purpose）能让每个技术人员深入人心，能在技术圈内影响到志同道合的牛人共同来一起奋斗。
+
+“影响意识”的能力是一个CTO水平高低的评判标准，也是每个”O”级别管理者能力的体现。同样是CEO/CTO，除了可以“成事”的领导力，文化构造能力也是决定了哪些企业可以持续壮大，哪些企业会昙花一现的关键要素。
+
+《原则》当中提到,公司就是一个从目标到结果的运作的机器，而这个机器构成主要有两个部分文化和人：优秀的机构拥有优秀的人和优秀的文化，优秀的人具备高尚的品格和出色的能力，优秀的文化不掩盖问题和分歧，而是公开妥善的解决，喜欢让想象力驰聘且愿意开创先河。大多数公司在初期技术团队可以形成点状的成功而无法延续成功都是因为没有构建合适的企业技术文化不断升级公司这个“机器”、保持引进卓越优秀的人才。
+
+构造技术文化的关键点
+
+构造一个公司的技术文化，需要结合公司的顶层设计确定以下几个关键点：
+
+
+愿景
+
+
+技术团队要成为什么。一般会根据公司的业务和技术团队具体情况定义一个宏大定义，它就像一面旗帜，吸引高级技术人才的同时激励现有员工不断学习，挑战自己的极限，让自己成为卓越团队中的一份子。
+
+例如，在易观，技术团队要成为世界顶尖的用户大数据团队。这里结合公司的愿景，阐述了几个事情，第一是，易观的技术团队是做大数据的，特别是用户大数据，其中涉及到的技术就比较垂直，用户画像、数据存储、数据采集、数据处理、数据引擎等，都是面对用户大数据的，而不是自然语言、爬虫、舆情分析这些。那么，在招聘和技术品牌宣传当中，就可以针对做这些人群进行定向宣传，同时人员培养的路径也比较清晰。
+
+第二，我们要做世界级别的顶尖技术团队，因此，我们要的是卓越的人才，面临的挑战也会世界级别的，这样可以激励加盟易观的小伙伴可以不断挑战极限，遇到5.5亿月活的时候也不认为多复杂，遇到复杂的模拟用户行为的算法时候就不会觉得不靠谱，激励员工不断挑战不可能。
+
+只定义愿景还是不够的，作为高级技术管理者，我们不能把它变成空的口号，而要在日常的招聘、培训、工作安排当中，都要体现我们实际的行动。例如，招聘的人员是否都是卓越的人员，给予大家的培训和辅导是否是国际化的，技术的挑战是否是其他公司无法提供的，是否有技术大牛来在面对无法攻克的难关的时候给大家指点迷津。有些是当时无法一步达到的，定义了愿景，整个技术团队就要不断的为之努力。
+
+
+使命
+
+
+技术团队要去做什么，一般都是一个宏大的概念，一般是和公司业务一个比较抽象集成，例如为世界贡献XXX、改变世界的XXX，连接世界的XXXX。它和价值观一起，指导员工具体怎样去做事情，大家内心有一个的使命，会在具体做事情、做决策、发生矛盾的时候有一个统一的目标。
+
+例如在易观，技术团队的使命是“让未来数据科技开箱即用”，这里面有几层含义，第一是未来，我们使用的都是最前沿的技术，甚至是我们自主研发的技术，这些技术相对于我们服务的内部客户和外部客户是未来才会普及的技术，放眼未来的科技，才让我们不会停滞在当前临时的困难和辛苦。
+
+第二是数据科技，这既明确我们是针对数据这一细分领域，同时也澄清我们要做的是科技，而不是简单的技术应用，需要大家有科学家的探索和不断迭代试错，挑战极限。而“开箱即用”说清我们技术的目标是什么，不是为了炫技，而是为了让内部、外部的客户通过极致的“开箱即用”的体验认识到卓越技术带来的效果。所以，技术是要有商业闭环的，一味追求技术并不是在技术团队要追求的事情。大家在定义技术团队使命的时候，一定要和公司的实际业务来结合技术团队的使命，这样可以和公司其他的部门耦合更紧密，也会和其他团队更融洽。
+
+
+价值观
+
+
+一个团队提倡的团队理念，换句话讲，不符合这个理念的人，是不能招聘到团队当中的。首先，价值观是在公司大价值观之下的，每个公司都有自己的价值观和理念。其次，针对技术团队需要增加一些特殊的价值理念，例如，绝对透明，勇于担当等等，这些价值观定义了你的团队是怎样的一群人走到一起。这和一个管理者的管理风格也密切相关。一个高级管理者的价值观会带入到团队当中，所以，才会有“强将手下无弱兵”，“兵怂怂一个，将怂怂一窝”。价值观没有对错，但是定义了哪些人可以“对味”。在处理事情和决策当中，碰到公司价值观的红线，那么很大可能会被清理出团队。如果价值观不同，也很难在团队中立足。
+
+结语
+
+愿景、使命、价值观看上去虚无缥缈，但其实它定义了你要的是怎样的人，这些人要去做什么，用什么样的理念来处理事情。而正是这些人在这样的文化下，把公司一个又一个的目标变成结果。文化并不是一日就可以建成的，它需要定型后，不断的给员工反复重复，直到这些文化成为你团队的灵魂，在管理者在或不在的时候，让你的团队可以在这样的文化下进行自我驱动自我决策。
+
+此前，我已经给大家分享了领导力、体系搭建能力、人员管理的能力如何构建和提高，这些都是有形之手，都是看得见摸得到的；而文化，就是管理的那只无形之手，融入到你团队每一个人的血液里，在很多前面几种能力鞭长莫及的地方发挥它的力量。
+
+作者简介
+
+郭炜，易观 CTO ，中国软件行业协会智能应用服务分会副主任委员，TGO鲲鹏会北京分会董事会会长。负责构建易观技术团队、完成易观大数据采集、平台、数据挖掘等技术架构与体系；从无到有完成易观混合云的搭建、以及易观 SDK 的升级，并发布易观秒算实时计算平台。目前易观大数据平台日处理数据量 30T ，272亿条，月活用户5.5亿。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/033选对的人，做正确的事情.md

@@ -0,0 +1,105 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            033 选对的人，做正确的事情
+                            人才队伍，对一个组织能否打胜仗起到至关重要的作用；人才结构，决定企业能够做多大走多远。人对了，事才能对，选对的人，做正确的事情，企业才能步入发展的快车道。企业经营的过程就是在招兵、练兵和用兵的过程，今天我们就来谈谈招兵买马这件事情。
+
+招聘的岗位要求、流程和方法论，本文不作过多探讨，相信每个公司都有自己的操作章法。本文把重点放在招兵买马认知和实战经验上面：
+
+选用什么样的人才？ —— 甄选人才的六大基本标准；
+
+如何挑选人才？ —— 识别人才六大基本素质的实用方法；
+
+哪类人才要慎用？ —— 管理者要慎重聘用的六类人才。
+
+甄选人才的六大基本标准
+
+“以德为先”作为选用人才的第一个标准。
+
+没有良好的职业道德、人生观和价值观的人才，往往缺乏奉献精神，很难将做好本职工作作为对自己的第一要求，严重时，其不良倾向会波及和影响整个团队，进而给团队带来较大的管理难度和管理风险。如果管理者道行不深，很有可能需要花费大量时间和精力纠正其行为，却效果不大，产出也很低。你的时间和精力是宝贵的，不应该投入在没有产出的人身上。
+
+“务实为本”是选用人才第二个标准。
+
+任何成功都是从点滴开始积累的，务实型人才往往乐于从基础工作做起，一步一个脚印。尤其是搞技术的，如果整天只是夸夸其谈，不干实事，浮于表面，将很难立足，很难给公司创造价值。唯独踏踏实实，认认真真，把心沉下来，用心做好事情，在做事情的过程中，不断磨砺自我，提升自我，方能成为企业的顶梁柱。
+
+“良好的团队精神”是选用人才的第三个标准。
+
+现代企业中几乎不存在个人英雄主义逞能的土壤，成功离不开团队全体成员竭诚协同努力。一个缺乏团队精神的人，表现为自私、利己、很难与别人合作、很难认可别人的贡献，这样的人会与团队格格不入。如果无法融入团队，即使有一技之长，也很难有机会施展，最终无法为团队创造应有的绩效。
+
+“较扎实的基础知识”是选用人才的第四个标准。
+
+较扎实的基础知识是能否进行有效培养继而使其成为“能人”的前提条件。其中最重要的是语文知识和数学知识。一个人如果具备良好的语文基础知识，则理解和表达能力通常不错，有利于与人的沟通；具备良好的数学基础知识，则逻辑思维能力会比较强，处理事情一般会比较严谨和细致。另外，良好的语文和数学知识对于掌握新知识、新技能也非常有利。
+
+“认同企业文化”是选用人才的第五个标准。
+
+认同企业文化与招聘后人才的稳定程度有关。人才不稳定，不但不利于团队工作的开展，而且会增加人才招聘成本，给企业带来不必要的负担。有了共同的团队文化，大家用一种语言沟通，在同一频道上对话，有一致的想法，工作步调又一致，节奏一致，劲往一处使，形成合力产生共振，把组织效能发挥到最大，最后把事情做成，正所谓上下同欲者胜。
+
+“较好的发展潜力”是选用人才的第六个标准。
+
+较好的发展潜力是一个人能否快速成长的先决条件。企业需要的是这种具有较好发展潜力的人才，因为企业为这样的人才付出的成本可能不会很高，但其创造的价值却会不断增长。这也是大家选股票找对象喜欢找潜力股的原因，性价比高，未来增量将会释放大量价值。
+
+识别人才六大基本素质的实用方法
+
+应聘者是否具有良好的道德情操，可以通过了解他以前的工作和学习情况来发现，也可以通过他的言谈举止来观察，因为一个人内心的想法多数时候会“溢于言表”。
+
+应聘者是否具有良好的务实精神，可以通过查看他以前的工作履历来了解。如果由于个人原因而频繁跳槽，这样的应聘者十有八九不属于这一类，聘用时需慎重考虑。
+
+应聘者是否具有良好的团队精神，可以通过讲解项目研发过程，遇到的人和事，是怎么处理和面对的，通过设置好的一系列问题去深挖，去捕捉他处理的小细节和肢体语言来判断。
+
+应聘者是否具有良好的语文基础知识和数学基础知识，可以请他就某一个问题进行书面（或口头）阐述，通过他的表达清晰程度和分析理性程度来判断。
+
+应聘者对企业文化是否有认同感，可以通过向他介绍企业的规章制度、用人政策、薪酬政策等，来观察他所表现出来的认同程度。
+
+应聘者是否具有较好的发展潜力，可以通过他对事物的个人见地去了解，是否具备相应的思维空间和相应的意识。有些时候，通过观察应聘者的精神面貌也可以作为基本的判断，精神面貌积极、阳光的人，一般来说发展潜力都不错。
+
+管理者要慎重聘用的六类人才
+
+
+个人简历与实际情况不符者
+
+
+管理者在招聘人才时，一般是先看应聘者的个人简历，然后决定是否面试。在面试的过程中，如果发现应聘者自我介绍的内容或者回答的问题与其个人简历上描述的存在较大的差异，那么这样的人要慎重聘用。一个弄虚作假的人，不要期望他能在以后的工作中干出多少名堂。此外，不诚实守信就很难和上下级建立信任，做的事情和产生的成果就会被质疑，自己痛苦，上下级也痛苦，是个双输的结果。
+
+
+频繁跳槽者
+
+
+在把自己的岗位工作做好的前提下，根据自己的职业生涯规划，理性地选择更有利于自我发展和成长的工作环境，应该是一种值得肯定的行为。但有些人才，却往往把跳槽作为“快速”提升自我价值的有效手段。这种类型的人才往往会急功近利，当感觉自己已经达到“自我期望”时，无疑又会选择跳槽。经验表明，大多数频繁跳槽者的工作经验和技能不如同工龄的工作比较稳定者，因为他们在频繁的跳槽过程中，空耗或贻误了一些非常难得的沉淀经验和技能的时机和机会。
+
+
+眼高手低者
+
+
+在招聘过程中，我们会发现有些应聘者高估了自己的工作能力，只想做“大”事，不愿做“小”事，这种类型的人才要慎重聘用。因为这类人实际上眼高手低，往往“小”事不想做，“大”事做不了，不愿从基础工作做起。这样的人在工作中很可能会找各种各样的借口推脱他们自认为“小”的事，而最终变得游手好闲，无法为团队作出应有的贡献。
+
+
+夸夸其谈者
+
+
+在招聘的过程中，我们会遇到口若悬河、夸夸其谈者，自我介绍时滔滔不绝、天花乱坠，甚至根本不着边际，这种类型的人才要慎重聘用。因为这种类型的人往往不太务实，工作起来比较浮躁，通常只图将事情做完，而不关心事情是否做好。这种类型的人才很难委以重任，对团队的贡献也比较有限。技术工作是靠能力靠本事干出来的，不是靠嘴吃饭的。
+
+
+过分看重个人利益者
+
+
+有些人才，过分看重自己的个人利益（如薪酬、福利等），将企业能否满足他的“自我期望”作为是否“加盟”的首要甚至唯一条件，这种类型的人才要慎重聘用。因为这种类型的人才有不断膨胀的个人私欲，他们的“自我期望”是无止境的。即使招聘时满足了他们的要求，工作时他们也会不时提出新的要求，甚至将是否满足他们提出的要求作为是否继续工作的条件。这种类型的人才虽然可能会有贡献，但管理起来会非常辛苦。
+
+
+过分追求自我表现者
+
+
+有些人才，一味追求自我表现。他们往往过分自信，一心追求彰显自己聪明才智的机会，这种类型的人才要慎重聘用。因为这种类型的人才只看重自我表现，不善于考虑别人的利益和感受，不愿意与别人协作，其能力发挥将非常有限。现在是一个协作共赢的年代，成就别人，也是帮助自己；成就公司，也就是成就自己，大家都是命运共同体。
+
+结语
+
+李云龙的部队无论走到哪里，都不会忘记两件事，一是招兵买马，二是筹备武器装备（工具），这才由千多人的团队发展到后来将近万人。对于现代企业来说，这两件事同样重要。互联网公司的核心竞争力是人才，人才多寡、人才结构、人才分布和人才搭配决定组织效率，决定公司生死存亡。祝各位管理者都能找到适合的人才。
+
+作者简介
+
+黄玉超，现任拉卡拉金融集团研发经理，有十余年的软件开发、架构和技术管理经验，其中有八年互联网金融行业经验，喜欢阅读，乐于分享，爱好技术管理和领导力的深化，使其工具化的落地。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/034打好技术团队搭建的基础.md

@@ -0,0 +1,85 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            034 打好技术团队搭建的基础
+                            从运营、到产品、再到技术研发落地，都需要一个团队的执行，尤其要仰仗团队的核心骨干来执行落地。对于CTO等技术领导者来说，招聘始终是绕不过去的话题，毕竟，任何一个团队，都不是每个岗位都齐整，等着你来领导的。如果技术领导者不能搭建自己的强大团队，是无法胜任其岗位的。
+
+那么，招聘前需要做好哪些准备工作？如何定岗定级？有哪些有效的招聘渠道？本文将就这些问题展开探讨。
+
+明确发展阶段
+
+首先要明确的是公司发展阶段，这点非常重要。产品从0到1，和1到N的过程中，对团队的人员需求，能力诉求是完全不一样的。在从0到1的过程里，讲究的是如何高效的利用现有的条件实现产品研发落地，而不过分追求技术的先进性。
+
+这个阶段中，往往从CEO开始到一线的产品、研发人员未必清楚产品在市场上的响应，整个团队的核心思想其实是需要将产品放到市场上试错，从而收集第一手的用户数据，这时，时间决定一切。这个时候的CTO（未必就是一个CTO，可能是技术总监或者技术专家的角色）更多应该扮演的是技术专家的角色，主要的工作是根据产品的设计，带领大家一起写代码，并在团队资源紧张的情况下，自己撸起袖子写代码。
+
+随着产品在市场的反响越来越好，慢慢的有了一些用户基础和用户数据，数据日益增长，原来的系统架构越来越不能胜任用户增长、数据增长的需求，要求平台从会员、商品、WMS、交易等进行划分，甚至微服务化，此时对团队的技术能力要求也越来越高，需要专人专岗负责，甚至专业的团队来负责。这时，团队规模较公司创立之初有了较大幅度的扩张，CTO应该将更多的精力转移到团队管理，如绩效、战略等。
+
+明确团队发展阶段对于CTO来说，是招聘的前提，比如在创业之初，没有P9级别的诉求。做技术的人都有一个通病，总是希望将技术做到极致。殊不知，在QPS 1000都到不了的情况下，从技术上将QPS做到100万级别没有任何价值。
+
+在本人的从业经历中，遇到过这样的例子：当时公司TPS大概在100左右，本人空降过去成为技术Learder，团队里有一个技术控，他的技术能力确实不错，一眼就能看穿我们当时的系统技术上的瓶颈。但是当时的系统足够使用，没有从技术上改造的必要。而当时另外的一个业务产品需要新的团队来负责，我希望由他来负责，但是他就是不想负责这个业务产品，就是想对平台的技术进行改造，希望团队能协调资源支持他进行改造。多次沟通无果，最后不欢而散。
+
+我也遇到过另外一个相反的例子，当时我们系统的TPS大概在3000左右，而实际的用户场景中对TPS的需求已经达到了30000+，直接导致系统每天都要不定时的重启。我认为每天对生产系统不定时的重启是不合理的，而且没有监控系统，不知道什么时候需要重启。在本人未入职之前，整个技术团队为了解决这个问题，将所有的精力都投入到了新产品的研发中，而置生产系统不顾，关键是新的产品不知何时落地何时上线，也不知能否解决这个问题。我上任之后的第一件工作就是希望解决这个问题，其实从技术上来说并不难，但由于团队里没有合适的人，只能是我自己带领技术人员来解决。
+
+以上例子说明，作为技术领导者，在用人和招人时，要非常明确团队所处的阶段，在合适的阶段用合适的人，当然也包括CTO在内。
+
+定岗定级
+
+大多数的创业型互联网公司都是靠融资活着，在公司扩张方面，有人任性，有人谨慎。当然也见过有人任性到拿到投资时无限制招人，到最后裁员的结局。任何一家公司都不可能无限制的扩张，基本都是根据业务的需求制定合理的招聘需求，对于技术领导者来说也是一样的。
+
+作为一个技术领导者，需要根据业务和产品的需求，结合现有团队的资源（现有团队的能力分布对于新的业务需求在招聘岗位上的能力需求是很有意义的参考），定义岗位的能力要求。
+
+比如，现在要做一个WMS，那么首先就要评估团队的现状，明确团队的技术栈（比较忌讳采用全新的技术栈，一般沿用现有的技术栈）。从产品角度来说，如果团队成员对WMS都比较熟悉，但就是没有资源能将想法落地，此时需要一个对WMS有点概念或者比较资深的产品经理来设计落地即可，至于招聘还是内部提拔，视不同情况而定。
+
+对于研发技术人员的需求，本人比较崇尚根据目前团队某个产品的duty team的构成作为参考，而不是盲目地提升团队的需求，导致招人困难，致使项目延期；也不需要为了便于招人，刻意降低团队的需求，从而导致最后产品质量没法保障。
+
+那么如何定级呢？相信大家对现在互联网行业中的P／M定义都非常熟悉，但是不能照搬，要结合自己团队的现状定义合理的级别。此时，HRBP在这个过程中能够起到很大的作用，通常HRBP在每个季度都会对团队的效能进行分析，明确每个团队，每个伙伴的绩效分析，和效能分析报告。CTO可以根据这些分析报告，结合业务需求，制定比较合理的headcount。
+
+在技术管理者中不乏这样的人，对headcount的诉求是拍脑袋决定的，总觉得人越多越能显示权威，说明自己越厉害。这样的技术管理者自身就是不合格的，我们一定要避免陷入这种思维。
+
+招聘渠道
+
+面向不同岗位，不同定级的招聘诉求，对应的招渠道应该尽量多样化。可能很多人都认为招聘渠道的获取应该是HR的事情，这种观点本人并不认可。本人2003年参加工作，那个时候领导真的是领导，在办公室高高在上，而现在的领导，尤其是互联网行业的CTO等，已经早就不是领导，而是保姆。对于招聘渠道的布置和推广，CTO至少要参与其中，给出思路，让HRBP去执行。
+
+目前比较有效的几个招聘渠道，基本上有下面几种：
+
+1、熟人圈子
+这种方式是最可靠的，尤其针对核心岗位，骨干级别，高P／M级别的岗位，非常推荐这种方式。熟人圈子最大的优势是，对于业主和候选人都知根知底，背景清楚。
+
+2、猎头
+通常企业在需要招聘团队负责人时，才会启用猎头，毕竟利用猎头的成本不低。但是，由于猎头准入门槛较低，滥竽充数者大有人在，作为团队负责人，想要提高命中率，恐怕需要向猎头明确候选人背景、候选人经历、能力、岗位诉求、岗位价值回报等。因为对于候选人来说，猎头是其最先接触，并最先了解企业的入口。候选人往往会希望从猎头口中得知更多的关于企业的信息。这就要求企业在向猎头发布招聘需求时，非常清晰的表达企业的要求之外，还要明确说明岗位的工作内容，价值回报等。
+
+本人经历过太多猎头推荐岗位，大多数的猎头没有办法清晰的描述业主的vision、企业的商业模式、岗位的基本诉求，更多的在谈该岗位的价值回报，要知道，通过猎头推荐的岗位，候选人往往更加在乎的是能否共同成长。
+
+因此，通过猎头实施招聘，建议选择专业的猎头机构，专业的人员合作。
+
+3、内部推荐
+内部推荐实际上是对企业文化的一次考验。记得一位朋友曾经说过，如果公司发布的任何一次关于公司vision，团队文化建设等，员工都将其分享到朋友圈，说明该公司的企业文化建设相当成功。
+
+大多数创业型团队将内部推荐作为常态工作。根据岗位定级的差异，设计内部推荐的激励制度。内部推荐成功的概率往往比较高，毕竟大家都不希望自己推荐的候选人被拒，从而或多或少影响到自己。
+
+4、扫街
+负责团队招聘的HR在各大招聘信息网站上海选简历，将符合需求的简历放入到人才库，接着再一个一个电话预约面试。
+
+这种获取简历的方式工作量巨大，效率比较低下，也难以获取符合岗位诉求的候选人。
+目前，很多公司已经不大会采用这种方式了。
+
+5、发布招聘信息
+大多数希望从传统转型到互联网的企业比较喜欢的招聘渠道。由于深受传统思维的限制，这种类型的企业的HR大多认为用人单位是强势的一方，就等着人家主动投递简历过来，我来筛选。
+
+现在的招聘方式变了，候选人更加在乎的是自己做事情的感受，是否被认可，是否受到应有的尊重。不是说不能发布招聘信息，而是应该更加主动的出击，直接面对候选人，而非被动的等待投递的简历上门。
+
+对于招聘渠道，往往需要一个双向的，长期的建设过程，除了正常的维护高质量的招聘渠道之外，还要尽量的对外推广。推广的目的之一是企业形象的推广，实际上是促进招聘的便利。
+
+结语
+
+招聘，对于很多团队来说，只是日常工作的一部分，毕竟业务每天都在变化，团队也每天都在变化，铁打的营盘流水的兵，谁都无法保证在一家公司呆一辈子。以上我分享了一些自己在多年工作中总结的招聘流程和渠道，相信大家也都有自己独特的经验。总之，作为技术领导者，需要在日常工作中不断总结经验，从而不断提升招聘成功率，提升团队效能。
+
+作者简介
+
+吴万港，前中恒云能源CTO，TGO鲲鹏会杭州分会服务委员&学习委员。10多年的互联网行业从业经验，带领多个团队完成设计、研发了分布式K/V，分布式数据库，日处理达到百T级别的分布式文件系统。8年以上互联网行业大型的产品、技术团队的建设、团队发展、团队管理经验。对于从产品需求、技术实现等管理方面有全面的认识和实践经验，深入理解敏捷研发管理办法以及多年的实践经验。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/035做个合格的技术岗位面试官.md

@@ -0,0 +1,53 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            035 做个合格的技术岗位面试官
+                            昨天的文章中，我分享了如何做好技术团队招聘的基础工作。那么，当有了较合适的简历，应该如何有效的面试，在满足自己岗位需求的同时，将不符合要求的候选人挡在门外？本文将详细讲述，作为一个技术领导者，如何做好面试的工作。
+
+不同岗位关注点不同
+
+由于个性，知识背景，每个CTO在招聘过程中，面试的技巧都不一样，有人偏向技术，有人偏向情怀，等等，各人各异。本人认为对于不同的岗位面试技巧，不同的候选人，面试技巧应该因人而异。
+
+在定岗定级时，基本上就确定了，不同岗位在团队中扮演的角色的差别，有些岗位是核心岗位，而有些岗位则是辅助性的，相对来说没有那么重要。
+
+对于核心岗位，根据岗位的需求，针对候选人的简历，在短短的不到2个小时的面对面沟通中，主要考察的是候选人对该岗位描述中使用到的技术的掌控能力，以及候选人过去的工作中是否真如其描述的那样的经历和经验。
+
+针对核心岗位候选人的面试，在面试过程中，考察的重点往往是候选人过往的经历是否对该岗位负责的事情起到带头的作用，候选人的经历和经验会成为考察的重心，作为技术领导者，要能一眼看穿候选人是否夸大其自身经历和经验，不至于被忽悠了。
+
+另外，对于核心岗位，公司都是非常希望候选人作为核心骨干能够与公司长期共同发展，共同成长的。这里要表达的意思是，应该要给候选人卖一点情怀，让候选人能够明确的感觉到团队希望其能共同成长，共同发展，而不是仅仅为其提供一个工作的岗位。
+
+而对于一般的岗位，最重要的是考察其能力，是否能够胜任岗位所描述的需求，若能够满足，实际上可以录用的，否则就算了。针对这些岗位的候选人，本人觉得比较忌讳的是大谈特谈所谓的忠诚度，谈贡献，而忽略了个人利益。很有可能对于候选人来说，他们所需要的可能仅仅只是一份工作而已。
+
+当然，任何岗位的面试，针对候选人的基本技能、感知认识等的面试和了解，是任何一级的面试官都必须要去面对的问题，这里不做深入的探讨。
+
+如何考察技术能力
+
+针对技术岗位的候选人的面试，随着面试慢慢的深入，往往候选人会放下戒心，有些CTO会抓住这种机会，在自己认为重要的技术点上，采用压力面试，实际上考察的是候选人在面对危机时的临场处理能力，面试官也未必比候选人就这些知识点了解的更加透彻。本人就非常喜欢根据面试气氛的变化，采用这种方法。
+
+面试过程实际上是双方相互之间第一次了解和试探的过程，候选人向面试官详细描述了自身的背景、经历之后，出于互相尊重的需要，尤其是对于核心岗位的候选人，面试官需要将公司的商业模式，公司的vision，团队的现状告知候选人，向候选人描述团队对该岗位的定义和诉求，以期达到双方对该岗位预期诉求的基本认同。
+
+对于技术岗位的面试，很多公司往往会进行临场的编码考察。这种面试方法本人也比较喜欢，尤其是定位在p7/p6以及以下级别的岗位，这个定级的岗位在日后的工作中往往是方案设计、编码的主力，对于性能、可靠性等关键的质量要素的敏感性往往很高。因为大多数候选人是很不喜欢考察临场的代码能力，在面试过程中考察其临场代码能力，实际上并不是要求候选人完全按照既定的思路和设想去完成，并达到完全正确，而是为了考察候选人在面对临时的全新的命题时，解决问题的思路方面的能力。
+
+面试中的忌讳
+
+往往，针对比较核心的岗位的面试可能要持续好几次，不同的面试官（包括HR）从不同的角度了解候选人的背景、经历等。最后不同的面试官会得出不同的面试评估，最终是否录用可能会根据团队情况的变化和面试评估报告，最后给出一个综合的结论。
+
+但是，非常忌讳的一点是惹恼了候选人。这里讲一件本人经历的事情，记得在2013年前后，我在面试一个视频云SaaS平台的解决方案工程师时，候选人有在一家国内大型的专业提供视频服务的企业的背景，由于本人一时不慎，要求候选人在视频SaaS的基础上，详细描述广电集团在景区的应用场景中就视频历史数据本地化和云化如何结合的解决方案。候选人觉得其背景受到了质疑，面试持续了5分钟就不欢而散，最后HR团队认为我作为面试官，不够尊重候选人，给企业带来了负面影响。
+
+这个例子想要说明的是，切忌一时口快，而让候选人觉得受到了质疑。面试官在控场的同时，要把握好面谈氛围，尽量让候选人觉得愉快，从而能够让其放下戒心，清楚的表达其真实想法。同时，面试官也能在候选人比较放松的状态下，更加直观的了解其真实的背景和经历。
+
+同样忌讳的是，在面试过程中和候选人海阔天空，夸夸其谈，偏离了面试的本质，最后什么面试结果都没有。记得有一次本人的一个HRBP反映，下面的一些主管在面试过程中毫无时间观念，和候选人就一些热点事件聊的不亦悦乎。这种面试过程，其结果多数是候选人反映面试官不专业，不切实际，面试官针对候选人没有有价值的面试评估报告。浪费大家的时间，浪费公司资源，最后拖延的往往是项目时间。
+
+结语
+
+CTO等技术领导者是核心团队的核心领导者，对于运营、产品到最后研发落地等岗位，招聘中对于候选人的考核，尤其对于核心人员，请将综合素质摆在第一位，宁缺毋滥是第一原则。同时，在关注候选人素质的同时，也要不断提升自身面试技巧，并充分尊重候选人。只有这样，才能赢得合适的候选人的认可，从而提高入职率。
+
+作者简介
+
+吴万港，前中恒云能源CTO，TGO鲲鹏会杭州分会服务委员&学习委员。10多年的互联网行业从业经验，带领多个团队完成设计、研发了分布式K/V，分布式数据库，日处理达到百T级别的分布式文件系统。8年以上互联网行业大型的产品、技术团队的建设、团队发展、团队管理经验。对于从产品需求、技术实现等管理方面有全面的认识和实践经验，深入理解敏捷研发管理办法以及多年的实践经验。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/036高潜力人才的内部培养.md

@@ -0,0 +1,57 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            036 高潜力人才的内部培养
+                            三年前，我加入饿了么担任CTO，这三年饿了么技术团队从30多人发展到数千人。经常有人问我，饿了么技术团队怎么做招聘。其实关于招聘，我个人倾向于：高级岗位尽量内部培养，其次校招，最后迫不得已才会空降。
+
+空降不如内部培养
+
+这里的高级岗位是指P7或以上级别，或者管理类的，我们称为经理的这样一些角色，一般一线工程师的招聘可能问题不是很大，也谈不上空降。高级岗位合适的人是比较难找的，因为你是要管团队，或者要去带一个业务的架构，或者作为很有深度的专家。管理型人才、架构师我们通常都是内部培养，基本是这样一个思路。校招有些挑战，有些校招的同学非常不错，比如有些海归的硕士，他可能进来就是一个高P。
+
+我刚进饿了么是救火的，我虽然自己是空降进来的，但我还是倾向于内部培养。因为空降的员工要跟公司的业务，或者老员工去磨合，确实有一些麻烦，这也是我那时候的一个感受。
+
+内部培养是有周期的，空降可以很快来一个看上去很不错的人，马上可以上手干活。但是空降的人，他不一定熟悉内部的情况，人员的情况。还有业务，比如原来我认为外卖是个很简单的业务，进来之后，远远复杂度超过我的想象。
+
+不过我的观点主要是针对创业公司，其他企业不好判断。业务比较稳定的公司，比如说外企，或者大型企业，我感觉可能空降的情况可能会多一点，因为外企相对来说，对试错的容忍度差一些。因为已经有很好的业绩，你轻易再去试错，万一把主营业务拖累了怎么办？不像我们创业公司，本来就是在不断试错。还有上市公司，要关注财报，你花了这么多钱，结果没有业务产出，跟投资人也不好交代。这些公司更趋向于求稳。
+
+“高潜力”人才的标准
+
+内部培养管理者，我们通常有两个选拔标准。首先技术一定要OK，他至少有一些，我们叫“技术的信用”，大家都认为这个人技术不错，不一定需要很牛。在饿了么刚开始人不多，都是技术可以的，你如果技术不过关，只是说管人很厉害，下面的团队是不服的。我们现在的管理岗，技术是一个必选项，你要曾经做过厉害的项目，而且在饿了么证明过你做过这样的项目。
+
+第二就是经历过火坑，因为有些同学不愿意去做跳火坑的项目，或者救火的项目。满足这两个条件，就是我们愿意去培养，也是我们内部叫“高潜力”的人才。他可能现在工作时间不长，很难说有多少经验，但是他潜力比较好，我们就愿意花精力去培养。
+
+在管理方面，我们有时候会拔苗助长，可能很多公司也经历过，这个工程师他可能自己不喜欢做管理，但是现在没有管理者，这个位置你先扛着，扛着扛着有些同学发现管理很有意思，有些同学越做越郁闷，他说我要么离职，要么重新做很纯粹的技术。这两类同学，我们都有。
+
+对于后一种没办法，只能让他回去做技术岗，因为强扭的瓜不甜，不是每个人都想做管理的。我们这边，尤其公共团队，很多同学讨厌做管理，更喜欢做比较成熟的技术，就让我安安静静戴个耳机写Code，或者做调优。因为他们是要成为一个深度的专家。
+
+但是在产品研发，就是垂直团队，可能有些同学就走两条路线。一种是管理岗，因为他要跟产品经理去聊，跟业务去聊，跟运营去聊，他必须有沟通能力。很多同学不愿意做管理，更多的还是不适应做沟通这个活，不光是跟自己的团队沟通，还要跟合作的团队做沟通。还有一种呢，他也不带团队，但他会去主导一个项目，我们叫架构师，架构师也需要很强的沟通能力。整体而言，我们的管理岗并不多。
+
+没有“最适合的人”
+
+当必须外部招聘时，怎样找到最合适的人？我觉得这个很难，因为空降之后首先要磨合，这是个长期过程，我个人这三年来的经验，包括以前在一些稍微大一点的公司的经验是，能找到合适的人纯属运气好。没有最合适的人，磨合融合是必然的，再厉害的人，情商再高智商再高都是要磨合的，因为家家有本难念的经。
+
+即使你人脉比较广，或者资金雄厚，比如刚刚融到一笔资金，可能在外面给的Offer很诱人，也很难找到特别合适的人。你开的出价格，找到的可能是牛人，但牛人不一定是合适的人。比如一个创业公司，只有三个人，它现在最缺的不是CTO，你找一个很牛的CTO来没有意义，找个程序员来干活就可以了，先把系统搭出来。有可能你找了一个CTO三个月后，代码没搞定，公司倒闭了，你找了个程序员三个月后做了个APP，或者做了一个什么系统出来，后面慢慢再去找厉害的人。
+
+公司内部挑战自我
+
+我们垂直团队的绩效，其中最主要的一个指标就是业务指标，因为他们是跟业务是紧绑定的，我们叫业务单元。当然有的团队说，我这个业务单元今年业绩做得不好，我是不是也受累？没错，就是要受累，除非你不愿意做这个业务，做这个业务，技术团队，还有产品团队，运营团队，首先就是要对齐业务指标。
+
+我们的垂直团队一般是按领域来拆的，不是按角色来拆。对单个成员来说，他的成长首先与他的业务指标相关。我们内部对于垂直的产品研发PE或者RD来说就八个字，一荣俱荣，一损俱损。我们开玩笑说，业务今年做得很好，你技术老是宕机，但没有一起大问题，你也有收获；但业务做得一塌糊涂，你一个Bug也没有，你今年也是Nothing。当然说的略微有点夸张，但就是这个意思，这些工程师不仅仅只是程序员，他要懂业务，懂产品，他甚至可以去挑战业务，挑战产品，说你这个功能是不是合理，应该如何调整。
+
+也许有人会觉得这样绑定是不是合理？我们认为是合理的，这就是自己的一个选择。我们招人的时候，你做过订单，我倾向于你来做定单；你做过用户会员，我倾向于你来做会员；你做过结算支付的，我让你来做支付。但也有些同学可能喜新厌旧，他做腻了想换一个。你换一个也要考虑风险的，没有旱涝保收的，旱涝保收谁都想去，这种不存在的。
+
+一开始，公司既然决定做这个业务，肯定是有一定前景。当然成熟业务每年的指标相对是可预计的，试错的业务就考验同学们的判断力了。我们内部是鼓励去创新试错的，风险和收益成正比，稳定的业务很难有那种非常大的那种突破，它可能每年会有增长率，但这个增长率基本上是可以看得到的。就像有些在硅谷的程序员说的，他可以看到他20年后的样子。所以为什么很多硅谷的程序员都回中国？中国可能空气质量不好，中国的创业公司可能倒闭的比例比硅谷高，但是他至少不是那么容易看到20年后的自己，有机会脱颖而出。
+
+结语
+
+内部人才培养好处多多，不仅能够为企业节省成本，降低团队成员间沟通、磨合的成本，也能为员工提供更多机会，增加团队成员的归属感。但是做好内部的人才培养，也要求企业的技术领导者建立起有助于人才成长的机制，前期会辛苦一点，但是后面就会有很大的收获。
+
+作者简介
+
+张雪峰，饿了么CTO，TGO鲲鹏会上海分会会员。曾带领携程软件架构团队 & 框架研发团队，后担任携程国际 BU CTO。曾有过一次创业经历（教育行业），深知创业之痛并快乐着的感觉，理解创业之苦、之难、之惨烈。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/037技术创业该如何选择赛道.md

@@ -0,0 +1,101 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            037 技术创业该如何选择赛道
+                            你好，我是熊飞，经纬创投董事总经理。今天我想跟你分享的话题是“技术方向创业该如何选择赛道”。
+
+这两年，技术创业，特别是Infra创业有一些新趋势出现。
+
+第一，资本市场开始认可，国内3~5亿美金估值规模的公司大量增加，如七牛、GrowingIO等。毋庸置疑，在2-3年内，我们会看到很多Infra领域的独角兽出现。
+
+第二，商业开始认可，这些公司已经形成商业化的收入，好几家公司收入规模已经达到亿元量级，并且保持高速增长。
+
+第三，创业机会极大增加，可以看到美国Infra公司创业持续繁荣，随着大数据、云计算在各个领域的使用越来越深入，大家对于底层架构的要求越来越高，使得创业机会极大的增加。
+
+同时，整体生态愈发繁荣，任何行业都是需求驱动的，否则技术人再牛、再有愿景也没什么意义。这3年，我们能够明显看到底层架构在云计算、存储、网络等领域的客观需求在暴涨，我们正生活在一个非常好的时代。
+
+趋势背后的原因
+
+为什么这些趋势会在这3年如此显著的发生呢？
+
+第一个原因是人的问题。 人越来越贵，劳动力成本越来越高，所以大家都在思考怎么去自动化。以运维为例，原来运维没那么复杂，运维人员比较好招，工资也不是很高，所以公司不太在乎要不要把运维自动化。但是，这两年情况发生了变化，运维越来越复杂化，运维人员也越来越贵、越来越不好招，所以大家拼命想把运维自动化，或者能不能买到相应的产品来提升效率。
+
+第二个原因是各行各业的业务互联网化已经成为核心趋势。 以银行等传统行业为例，面对蚂蚁金服、腾讯金融等互联网金融公司的冲击，对他们来说，IT问题已经从一个锦上添花的问题变成一个生死存亡的问题，这是一个非常强的驱动力。
+
+另外，以电商为例，现在他们会花费几百万买安全产品，但在大促时，这笔支出会帮助他们拦截羊毛党，挽回一两个亿的损失。因此，对他们来说，IT Infrastructure已经从锦上添花变成必然的基础设施。
+
+这些都反应了各行各业的互联网化，也让Infra创业领域充满机会。
+
+第三个原因是各行各业都认清了数据的价值，都在尽可能收集数据、分析数据和使用数据。可以看到，不管处在哪个领域，大家都有一个非常清晰的概念，那就是不管用不用得上，先把数据收集上来再说。
+
+正因如此，现在数据量在暴涨，行业对数据处理的实时性、分布式等都提出了更高的要求，这也使得大家对底层架构的要求变得非常高，由此需要更先进的供应商来解决问题。
+
+如何选择赛道
+
+既然如今的趋势这么好，那技术人创业该怎么选择赛道？我觉得可以主要看三个方向，一是数据，二是新技术架构变迁，三是机器学习应用。围绕这三个主题，未来三五年内将持续出现很多新兴的创业机会。
+
+首先来看数据，数据的大方向下又包含几个小方向。 第一是数据量的暴涨带来的存储、整合等领域的巨大机会。
+
+第二是数据对实时性的要求越来越高，如果你在实时性数据处理上有相关积累的话，这里就有很多机会。
+
+第三是新型的数据格式，比如图数据、IoT等。过去一年，图数据库的创业非常红火，行业至少有3到5家非常不错的公司开始尝试这个方向。背后也是同样的道理，随着风控、社交等领域产生越来越多的多维数据，对数据处理也要求越来越有效率，图数据库因此有非常多的机会，IoT数据也是如此。
+
+第四是在线数据分析，很多数据是在云上的，通过Realtime、通过业务数据做分析也有很多机会。
+
+因此，如果你想做Infra领域、做底层架构方向的创业，可以先围绕数据做思考。
+
+其次来看新技术架构的变迁。 过去2-3年，最火的词就是容器，而这会衍生出安全、运维等多方面的问题。因此，如果你们在容器生态下有自己很好的解决方案，可以试着通过开源等渠道先推广出去，有很大机会在里面。
+
+另外像是近年来火的Lambda、Serverless，包括更细分的软件定义的存储、软件定义的网络等，其中都有很多机会。
+
+最后来看机器学习的应用，可以衍生出自适应的安全、自适应的运维、自适应的很多方向，而在安全和运维两个领域，已经出现了很不错的创业公司，是真的能够大大节省人力和提高效率的。
+
+这些就是我对赛道的理解，把握数据在暴涨，把据新技术结构一直在变迁，把握机器学习会应用在Infra各个相关的领域，其实就会找到很好的赛道。
+
+怎样赢得资本青睐
+
+找到赛道之后，如何赢得资本青睐呢？这是大家都感兴趣的话题，毕竟一个好汉三个帮，有几个VC帮帮忙，创业这件事儿就会变得容易很多。我会讲一下我们的标准。
+
+一是先人一步，在Infra、在基础架构领域创业，没有一两年基本上是磨不出来好产品的，所以，你创业的话一定要做1%看到那个趋势的人。千万不能等到20%、30%的人都觉得这是个好方向了你再去做，这样等你把产品做出来的时候，可能80%的人都知道了，而且市面上也早就有不错的产品了。
+
+Infra创业不像2C，2C因为有流量优势、错位竞争等各方面因素，是有可能后发先至的。但在Infra领域创业是没有捷径的，所以建立优势，最笨最有效的办法就是先人半步。
+
+另外，先人一步才能找到敢吃螃蟹的标杆客户。做2B这个生意，产品都是磨出来的，得找一流的、有痛点的客户才能去慢慢打磨出来。那么，只有你是这个行业最先行的人，你才能跟观念和理念最先行的客户碰撞在一起。
+
+七牛的例子就是这样，他们2012年左右的开始做云存储，当时大家都觉得这个东西太早了，但后来像美图这些公司在云端存储、图片存储上遇到巨大问题，在市面上看了一圈之后，发现只有七牛能满足他们的需求。借助这样一批早期的一流客户，公司自然就跑起来了。
+
+二是在大市场中去系统性解决问题。技术类创业偶尔会步入一个误区，就是切入的点太小，虽然当前的增速很快，但公司的天花板太低。相信大家创业肯定是想做一个十年二十年、收入几十亿甚至上百亿的大公司，那么天花板这事儿就要比当前的增速重要无数倍。
+
+另外，资本其实是很实际的，他们会看你的技术，投你的科技公司，但本质上，他们投的是一个商业科技公司。科技是一个手段，他们希望看到的是你用非常好的技术手段最终实现了非常不错的商业目标。
+
+所以，如果你考虑在Infra或底层架构这方面创业的话，就需要多花一些时间想想天花板的事情，想想你想涉足的行业，在5年、10年之后，能不能诞生一个年收入至少几十亿人民币的公司。
+
+三是一流的相互信任和互补的团队。这边我想举的例子是GrowingIO，当时我们投他们的时候，团队只有4个人，大部分来自LinkedIn。那首先，LinkedIn的数据分析团队绝对是世界一流的团队；其次，团队成员之前就共事了大概4-5年，彼此非常信任；最后，团队成员间非常互补，有人产品做得很好 ，其人技术做得好、有人在用户体验甚至商业分析方面有非常多的经验，4个人非常互补，极大的帮助团队获得了资本的青睐。
+
+四是要尽可能深入思考发展路径，举个例子，我们投了一家公司叫才云，应该是国内Kubernetes生态里最好的一家创业公司，但在谷歌掌控的开源社区下发展，是很容易碰到限制和天花板的。
+
+因此，后来他们和谷歌一起开源了Kubeflow，简单来说就是TensorFlow On Kubernetes。这个产品就是才云能够自己掌控的，而且跟TensorFlow和Kubernetes两大未来最核心的趋势结合，一下子就把公司的天花板拉高了10倍。所以，要尽量多思考发展路径。
+
+Tips
+
+最后，我总结了5个Infra创业的Tips共大家参考。
+
+1.选择早期标杆用户，而且一定要非常反逻辑地选那些事多钱少麻烦的客户，因为只有这样的客户，才是真正能够帮助你把产品打磨成行业一流的客户。
+
+2.要抵制项目制诱惑，在早期，项目制就是毒药，你所有的人力开发都会陷进去，而时间窗比收入重要一千倍。一个Infrastructure的时间窗也就2-3年，如果你在那几年里忙着做项目挣钱，那等你项目完成，创业这事儿也就结束了。所以，要明确只有产品制才有未来。
+
+不过，也并非所有项目都不能做，如果项目里有很多代码、功能是能被公司其他项目、产品复用的，是能标准化的，那它就是积累的资产，是没问题的。
+
+3.要耐得住寂寞 ，我们最好的Infra产品、底层架构产品无不都是憋了1-2年， 这是Infrastructure的客观规律。
+
+4.Leverage 开源并利用口碑效应，开源是行业内的必然趋势，据我估计，未来3-5年，国内每一两年至少会有2-3家很不错的开源公司出现。
+
+5.要想着从科技公司到商业科技公司，这才是公司走的更为长远的必然基础。
+
+本文整理自经纬创投董事总经理熊飞在GTLC全球技术领导力峰会上的精彩分享。熊飞于2011年加入经纬中国，负责考察、筛选及评估互联网领域的投资机会。加入风险投资行业之前，他曾先后在阿里巴巴、腾讯担任产品经理。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/038CTO要掌握的产品哲学：理性与人性的权衡.md

@@ -0,0 +1,79 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            038 CTO要掌握的产品哲学：理性与人性的权衡
+                            大家好，我是梁宁。今天主要想跟大家分享一组概念词，就是理性和人性，这也是CTO想做好产品必须厘清的概念。
+
+合理的部分是理性，不合理的部分是人性
+
+我是在部队家庭长大的，大学又学了计算机，可以说我是在一个高度理性的环境中成长出来的。所以当我走出这个环境，走到江湖里的时候，就觉得到处都是不合理的事情，比方说我提出一个要求，按理说人们应该这样给我反馈，为什么我得到的反馈从来不符合我的预设，包括团队沟通也好、用户反馈也好，都是这样子。
+
+开始的时候，我很被这件事情困扰，后来就慢慢理解了，其实合理的部分是理性，不合理的部分是人性。
+
+在生活中，理性其实只占了很小的部分。那人们为什么会按照理性做事呢？因为外界的巨大压力，只有在压力下，他才会按照理性做事。如果你没有足够的能力给他足够大的压力，其实他是会按照自己的人性做事的。
+
+所以我想明白这点之后，也就不再像以前那样苦恼了。当我的伙伴、我的用户在我面前展现我认为不合理的事情时，他们其实是把人性和天性展现在我面前，从另一个角度来想，其实是给了我一个真正认识和理解这个人的机会。
+
+好产品=10%生理体验+90%心理体验
+
+那么CTO为什么要理清理性和人性的概念呢？因为当我们做产品的时候，我们要洞察用户需求，重视用户体验。但你会发现，我们的体验中可能只有10%是生理体验，是人的身体可以真实感受并给出反应的，剩下的90%都是心理体验。
+
+如果CTO在追求用户体验的时候，无法理解人的心理体验是怎么构成的，那就无法真正的了解用户体验，做出优秀的产品。
+
+以衣服为例，可能两件不同价位的衣服带给人的保暖、舒适等生理体验是差不多的，但它们的差异来自于优越感、文化认同感、自卑感等心理体验的差异，而这些差异的根源是社会氛围、是人们的共识观念。
+
+技术出身的人做产品的时候，特别容易去追求理性，觉得功能达到了，做到了服务器的完美负载匹配，就已经很好啦，但其实只满足了10%的生理体验。
+
+那么心理体验中，人最核心的情绪是什么呢？很重要的词是满足，还有一个很关键的词是存在感。对人类来说，除了生物性的生存，其实还有一个社会性的存在感。而存在感包括两个方面，一个是世界观，就是你对你所生存的场域的真实认知和感受；另一个就是从关系中感受自己的存在，看到自己存在的证明，所以有一种慈悲就是给别人存在感。
+
+因此，我们谈管理的时候，为什么非常强调管理者在说话的时候要看着别人的眼睛，因为这意味着你看到了对方的存在，你在关注他，这对他来讲是非常重要的。
+
+围绕着生存和存在感，以满足为中心，会分成两组不同的情绪，一旦不满足，就会产生不爽、担心、着急、紧张、恼火、生气、心神不宁、忧伤、沮丧、难过、烦燥等状态。而一旦被满足，就会出现愉悦、兴奋、喜悦、欣喜、甜蜜、精力充沛、兴高采烈、感激、感动、乐观、自信等状态。
+
+此外，围绕生存和存在感，还有两个词是愤怒和恐惧，这是一体两面的情绪，其中的差异主要来自你对对手的感知。猫划定地盘之后，如果来的是另外一只猫，它就会感到愤怒，而如果来的是只老虎，它就会感到恐惧。再比如说英雄人物和普通人的区别，就在于大多数人感到恐惧的时候，他们感受到的是愤怒。
+
+但因为每个人的所在意的生存场域不一样，所以他需要的满足点和在意的最不能被侵犯的点也是不一样的。
+
+“应该”是角色化的产物
+
+这时候，我们会更愿意用抽象、用“应该怎么怎么样”去推测一些问题，技术出身、偏向理性的CTO就更偏好抽象了。但这很容易出现一个问题就是，抽象往往会忽视现实的复杂性，也就是所谓的人性。
+
+我们经常会用应该怎样怎样来预期一件事情，但实际上“应该”是角色化的产物，是压力的产物，你只有在给对方足够大的压力的情况下，他才会在你设定的“应该”里去工作。
+
+举个例子，我原来在联想工作，大家都在以某种方式说话做事配合，如果谁面对压力却退缩，这是一件羞耻的事情，这是由于联想企业文化的系统压力形成的人的行为特性。但当我离开这样的环境，自己走到江湖开一个小公司后，我再给人原来的压力，对方就辞职了。他不会认为退一步是羞耻，因为我根本就没有形成这样的组织势能。
+
+这也是为什么大公司高管出来创业，一开始都很不适应的原因之一，因为人们和他以前的配合方式不一样。
+
+在大公司，公司有足够的组织势能和系统压力，压着每个人都在他设定的角色脚本里去工作，他们呈现的不是他们本身人性的样子。但当你出来创业后，你就是江湖风浪中的一叶小舟，每个人都用他本来的人性面对你。这时候如果你还想着“应该”，那就只是在给自己找挫折而已，不妨open地去看人们真实的样子，不要再将他们套到角色化的模子里面。
+
+不满足的状态+处境+场景=需求切入点
+
+因此，CTO们做产品时首先就要去弄懂人在什么状态下不被满足。我之前在创业马拉松的时候，有个小组说他们的产品解决的是老年人孤独的问题，他们觉得孤独是一个需求。但我不这么认为，我认为孤独只是一种状态，而不是一种需求。从状态到需求之间，还有处境，还有在这个处境里解决这个状态的场景，接着才变成产品对接的点。
+
+以饥饿为例，饥饿也是一种状态而非需求，同时，菜场、超市、便利店、餐馆、盒饭、外卖等诸多产品和服务都是在对接这个状态，所以在状态和产品之间还需要加上用户的处境。
+
+比如说我饿了，但我在减肥，同时经济上还算宽裕，那么基于这样的处境和场景，我可能选择代餐或是低卡饮食，或者在另一个健身房场景下，我的选择可能是冲一杯蛋白粉。所以，从我们洞察到的用户没有被满足的状态，到能提供的产品和服务之间，还存在这对用户处境、所在场景的洞察。
+
+而不满足的状态+处境+场景就构成了我们常说的需求切入点，也就是痛点、痒点和爽点。
+
+痛点是什么？ 痛点其实是恐惧，恐惧自己的生存资源被侵犯、生命安全无法保障等，举例来说，当今中国，教育是你对生存机会的恐惧，医疗是你对生命安全的恐惧。
+
+痒点是什么？ 痒点其实是对理想化自我的追求。一个女孩为什么买200只口红，这就是上面提到的，人的体验10%是功能性体验，90%是心理体验。从功能性上来讲，3、5只口红已经够用了，但内心的空洞是没有尽头的，也就是心理体验是没有尽头的。这是为什么如今物质已经极大丰富了，但我们依然有机会不断做新产品的原因。
+
+爽点是什么？ 爽点就是一个长期被压抑、不被满足的需求，突然被满足了，就像古话中的人生四大喜：久旱逢甘霖、他乡遇故知、洞房花烛夜、金榜题名时，满足的都是人们的长期期盼。
+
+不过，这些都是2C产品的定义，如果是2B产品，那么痒点和爽点就没那么重要了，重要的只有一条，那就是抓住老板的恐惧。因为2B产品需要系统灌输及系统学习的成本，如果不能抓住老板的恐惧，他们是不可能让组织付出代价、付出时间去贯彻2B产品的。
+
+另外，2C和2B产品细分还可以分成3类，一种是C端产品直接卖给C，一种是C端产品B买单，还有一种就是给组织用的。这3中产品在用户体验上是有差别的。
+
+以钉钉为例，它就是很典型的C端产品B买单。对普通用户来说，钉钉其实是很反人性的，用它很不爽，但在钉钉团队看来，他们这个产品是给集体设计的，而集体人格就是反人性的。但在老板看来，钉钉能为他提供确定性，能让他觉得爽，也愿意依赖这个产品，所以他就愿意为此想办法克服C端的抱怨，让这个产品得以持续下去。
+
+最后，我想说，我们都是技术出身，从小学的、崇尚的都是理性思维，但今天我们要搭团队、要跟人协作、要为人们提供产品，所以我们需要看到人和人是不同的，我们要接纳他人与我们的不同。他们对一件事情的感受和反应、他们的满足和不满足、他们的愤怒和恐惧和我们不一样，所以需要我们能够真正地完整地看到别人，然后和别人真正地连接。
+
+本文整理自著名产品人梁宁在GTLC全球技术领导力峰会上的精彩分享。梁宁是湖畔大学产品模块学术主任，曾任联想、腾讯高管，工作经历横跨BAT，与京东、美团、小米等企业有长期深度交流。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/039从客户价值谈技术创新.md

@@ -0,0 +1,65 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            039 从客户价值谈技术创新
+                            你好，我是百姓网CTO姜杰，今天想跟你分享的话题是“从客户价值的角度谈技术创新”。
+
+图灵在他的论文中提出了“图灵机”的描述，即“以布尔代数为基础，将逻辑中的任意命题用一种通用的机器来表示和完成，并能按照一定的规则推导出结论”，奠定了现代计算机发展理论的基础。
+
+而在大多数的互联网企业中，技术很多时候承担的角色类似“图灵机”的定位，主要在解决和实现产品和运营提出的相对确定性的需求。那么作为一个技术负责人，除了响应和满足这些“本职工作”外，是否需要思考技术创新呢？ 答案显然是肯定的，那又该如何从技术的角度去规划创新呢？
+
+技术创新要跳出技术本身思考
+
+首先分享一个不成功的例子，前段时间聊了一个候选人，他做了10年的中间件，有着非常好的中间件实践经验。在上一家公司，他作为一个架构团队的负责人，发挥了积累多年的功力，做出来的中间件，无论是设计、架构还是性能都有着非常优秀的水平和可取之处，然而他离开公司的原因却是老板并没有对中间件的价值有足够的认可。
+
+表面上可能是他的向上沟通出了问题，没有跟老板沟通好这件事情的真正价值。但深入剖析之后却发现，当时公司的整体技术中，中间件并不是当时公司最需要的技术，公司更需要的是解决像客户端连通率等更迫切的用户侧工程问题。因此，如果制定最初的目标时，仅从自己的优势经验角度出发去思考，往往就会产生比较大的Gap。
+
+所以，大家在思考技术中长期目标和创新的时候，一定要跳出技术本身的一些惯性思考，把组织业务的发展需要纳入到自己的思考维度中，而且要放在非常重要的地位。在此之上再去思考如何用最合适的技术方案解决可能遇到的问题。
+
+技术创新要围绕客户价值
+
+当技术发展到一定阶段，团队已经能很好地支持当前阶段业务发展的时候，有一天你会突然发现好象有你没你业务都能够顺利地开展，也就是俗称的“业务上没啥技术挑战”时，很多人会觉得技术到了天花板，会开始考虑选择换一个环境，寻找更高速发展的业务和挑战。
+
+但此时往往还有一个更具挑战的选择，就是在当前的环境中去探寻技术本身的突破，思考更长远的技术规划和技术创新，让技术未来成为业务发展的重要引擎。
+
+创新并不意味着一定要做新产品，在产品研发、售前、售后等过程中的效率提升和成本降低也有很多的技术创新可能。
+
+技术创新可以应用在很多方面，往往也意味着非常大的开放性和不确定性，很容易出现为杀鸡而研发一个牛刀的过度目标设计，所以就更加需要找到相对稳固的锚点来进行重要性和优先级评判，那就是从客户中找答案，很明显对养鸡场来讲，牛刀远不是他们最需要的产品，能增强禽类免疫力的鸡饲料才是。
+
+企业的核心是围绕客户价值实现的，而在当今信息和数据智能的时代，企业长期的发展和利润取决于技术在客户价值上做得有多深，技术创新要是能多从客户角度思考，就能让创新决策跟企业的中长远发展保持一致，并且能够保证持续地得到技术发展所需要的资源，构建长期竞争力。
+
+技术团队如何更好地关注客户价值
+
+那么作为技术团队，如何更好的关注客户价值并思考技术规划呢？我们可以从组织文化、研发流程、产品功能这个三个维度着手。
+
+首先，从组织文化的角度来看，在追求技术卓越的同时要将技术对业务和战略产生Impact作为重要衡量指标，避免过度设计和炫技。对业务型团队可以推行技术合伙人制，鼓励每个同学都以技术合伙人或业务合伙人为目标，每个团队都能基于业务和客户价值，去思考并制定团队使命，并让团队中的每个人都清楚这个使命，能够自主地为这个目标去思考、去优化。
+
+其次，从研发流程的角度来看，构建可快速交付客户价值的能力也是技术负责人需要思考的重要课题，关键模块服务化、敏捷流程、持续集成、快速部署、自动化测试及线上回归等一切能够提升工程师效率的手段都值得持续地投入；灰度发布和线上自动化的fail over处理等高SLA保障可以尽可能地降低对线上客户的影响；全链路的数据分析和用户模型则可以提升对客户的理解，为更好的用户体验和客户价值提供必要的决策依据。
+
+最后，从产品功能的角度来看，要鼓励技术能够经常接触用户。如果工程师只坐在办公室里，接收的往往都是来自产品和运营的“二手”需求，而让他们真正有机会去接触客户，直接参与客户需求反馈，往往会发挥出更多的效率创意和技术价值。通过一些机制的设计，比如客户轮岗日等，保证工程师们能够有这样的环境获得客户的一手信息和反馈。基于这些信息再加上对技术本身的理解及技术趋势的思考，往往就能保证技术创新的目标能足够接地气并且足够Sharp。
+
+技术创新不能憋大招
+
+制定创新目标后，在推进技术规划时很重要的一点就是不要想着憋大招。我看过到不少的项目就是因为一直在“推进”而迟迟没有价值产出而被砍掉。技术价值的释放曲线是一个S型，一开始呈现出的价值会比较低，所以大家在做技术规划的时候，千万不要想着去做一个特别完美的技术方案，然后再把它推到实际业务中去。这时，你做出来的所谓“完美方案”，很有可能和实际的场景、需求之间存在比较大的Gap，实践才是检验设计的唯一标准。
+
+所以，一定要先把技术的最小MVP快速地做出来，并且找一些应用场景，快速地根据反馈进行迭代。公司内部的很多技术项目包括一些中后台技术项目，我也都鼓励大家走出去，走到客户及业务技术中去，真正倾听他们的反馈，解决他们的痛点，才能保证技术价值的有效性和持续发展。
+
+小结
+
+之前谈了很多客户价值，但这里的客户并非单单指市场上的客户，很多时候，内部很多团队其实也是彼此的客户。比如说架构团队，他们的目标客户就是各个业务技术团队，所以，技术管理者也需要培养不同的团队产生这样的意识。
+
+有时候，技术同学会觉得跟产品、运营等业务方在合作中有着所谓“不可调和”的冲突与矛盾，而从客户价值出发，更多的是希望技术同学能够跳出技术领域换一种思维方式，它不仅可以帮助你思考技术创新，组织管理也可以从客户价值的角度来进行思考和创新。
+
+另外，管理者本身也可以尝试从客户价值的角度去思考问题，把自己的技术团队和团队成员当成客户，去创造一个自由且有效率的环境，让大家能够更加自主、自驱地去打造优秀的技术引擎。同时让这些优秀的技术人才也能够以客户价值作为技术创新的重要思考维度，避免技术与业务之间可能出现的冲突视角，将这些优秀的技术引擎最大可能地落到技术价值和客户价值上。
+
+本文整理自百姓网CTO姜杰在GTLC全球技术领导力峰会上的精彩分享。
+
+作者简介
+
+姜杰，现任百姓网CTO，负责百姓网整体的技术研发管理工作。在加入百姓网之前，他曾先后在腾讯、盛大、百度等公司，带领过数个亿级规模产品的技术团队，在技术架构与研发管理方面有超过十年的丰富经验。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/040技术人投身创业公司之前，应当考虑些什么？.md

@@ -0,0 +1,67 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            040 技术人投身创业公司之前，应当考虑些什么？
+                            你好，我是余晟，一个积攒了许多创业惨痛教训的老程序员。今天想跟你分享的话题是“技术人投身创业公司之前，应当考虑什么？”
+
+创业火热，回想过去十来年的热点，移动互联网、海淘、云计算、微信生态、大数据、人工智能、区块链…… 虽然技术和商业的大潮起起伏伏，但创业的吸引力、关注度却始终保持在高位，而且，这些热潮也大多和技术有密切关系。 “万事俱备，只缺程序员” 虽然更像是一个玩笑话，但这毕竟说明，创业对技术的依赖越来越严重，技术人员的价值也水涨船高。
+
+因此，也有许多技术人员义无反顾地投入了创业的大潮。其中有些人赚得盆满钵满，有些人碰得头破血流，还有些人起起伏伏，似乎也没有比在大公司打工更好。
+
+为什么会这样？除去运气，技术人员在创业之前的考量和准备也非常重要。运气不好，充其量是不成功，认命就好。而准备不充分，即便有好运气也可能错过甚至被坑，这就非常悲剧了。
+
+那么技术人在创业之前要考虑些什么呢？我觉得，技术本身是没有太多值得赘述的，反倒是下面这些“非技术因素”值得认真考虑。
+
+第一，放下技术的骄傲
+
+有许多投身创业的技术人，之前已经做的相当不错了。他们已经在之前的工作中取得了足够多的成绩，所以，也非常有信心能够在创业中继续贡献力量、创造价值、证明自己。但是，许多人往往低估了“惯性”，忘了考虑自己之前的成绩都是在技术而且是在某个专门的领域做出的。如果去做其它领域的事情，他们往往会觉得不适应，觉得没有“物尽其用”，对资源是浪费，对自己是贬低。
+
+但是投身创业，你会发现“技术”的范围其实相当广泛。在你的合作伙伴的理解里，所有和电脑、网络有关的事情，都归“技术”管。而且，创业公司往往不会有那么充分的资源，那么严格的分工，因此，所有和所谓“技术”有关的问题，都只能靠少数技术人员来搞定。如果这时仍然恪守之前的专业分工那一套，很可能会不适应。
+
+我曾经加入一家电商创业公司，通过重整代码和团队，在业务高速发展期解决了业务瓶颈，也得到了创业元老们的认可。但是后来吃饭我才知道，元老们根本不懂具体的技术细节，重整代码、重整团队这样的事情到底有多重要，该什么时候做，他们完全没法判断。但是他们通过一件我完全没想到的小事判断，我是值得信任的。
+
+什么小事？当时仓库的网络总是出问题，每次一出问题就影响发货。因为当时的网管不给力，又没有招聘到合适的人，所以这个问题爆发时，我只能亲自上场。“看到你身为技术的头，不是在上面高调指挥，而是抱着个交换机在仓库里钻来钻去拉网线，我们觉得这人一定能把事情干成”——你看，这就是创业公司的判断依据。
+
+后来我才知道，这并非特例。有位好友的经历成了反例：他技术也做的很好，也加入某个创业公司负责技术，但干了不长时间就退出了，问他为什么，答曰“公司太不正规了，难以适应，连办公室Wi-Fi不稳定也总是找我，我是负责组建技术团队的……”。这位朋友技术当然很好，但他离开之后，公司发展得也相当好。
+
+不是每个技术人加入创业公司都要去拉网线、调Wi-Fi，但是，你要做好足够的心理准备。
+
+第二，加深对人性的认识
+
+创业是九死一生的博弈，能成功的人寥寥无几。所以，成功的企业，都是上天眷顾的幸运儿。不过，别以为你加入的创业公司成功了，你就“一荣俱荣”了。我见过不少成功的创业公司，公司的成功与员工的回报，没有一毛钱关系。
+
+为什么会这样？多半是因为技术人员对人性的认识不够深，没有足够的防范意识。
+
+许多人之所以选择做技术，正是因为“不喜欢、不擅长与人打交道”。他们的思维往往带有计算机的惯性：这个事情就“应当”是这样，那个事情就“应当”是那样。
+
+在计算机的世界里，这样的规则或许存在。但是在商业世界的利益格局里，人性的复杂体现得淋漓尽致，尤其是在“创业成功，价值增长成百上千倍”的考验下，人心会如何变化，实在是没有保障也很难琢磨的事情。最终的利益格局，多半会与简单朴素认定的那些“应当”大相径庭，完全是博弈、较量和妥协的结果。
+
+我有位朋友，在师兄弟的拉拢下加入某创业公司，拼死拼活干了四五年，终于盼来公司大好形势，却发现承诺给自己的股票早已在暗地里大打折扣。更悲催的是，他还不能发作，如果发作，剩下的那部分也拿不到手，只能出去从头再来。
+
+他始终没有想明白的是：当年创始人求自己加入，“拉着我的小手看月亮”的时候，怎么没看出来他其实有那么多花花肠子呢？其实，未必是“当时就有那么多花花肠子”，只是世事难料，人心无常，这位朋友的困惑，未免有“刻舟求剑”的性质。
+
+也不要以为签了白纸黑字的合同就可以高枕无忧，不管公司有没有做成，大家撕破脸皮的例子不胜枚举。所以加入创业公司，一定要加深对人性的理解，虽然你未必能够因此多获得多少利益，但至少可以增加自己利益的保障。
+
+第三，与业务的人打成一片
+
+你在创业之前，经常与公司里哪些人一起吃饭？
+
+据我观察，很多技术人在创业之前，最经常一起吃饭的公司同事，就是技术人员。大家本来工作交集就比较多，相同的工作性质也导致大家的趣味、价值观比较一致，共同语言自然也很多，所以大家也比较愿意交流。
+
+创业公司不一样，创业公司的一大特点是“麻雀虽小，五脏俱全”。加入创业公司，你能直接打交道的同事的数量可能减少了，不太可能有“远在天边”的团队来找你，但接触的业务却可能更多了，也许以前客户的声音要经过重重过滤，变成规范文档才传达到你这，但现在不得不每天都面对枪林弹雨。
+
+打交道的人数变少了，技术人员大多是欢迎这种变化的，毕竟大家都喜欢简单。但接触的业务更多了，顺带的，接触的人也更复杂了，这种变化则让相当多的技术人员不适应，认为合作伙伴“心思不单纯”，抱怨“业务烦耽误自己专心做技术”，“没有流程导致浪费严重”等。
+
+但是我敢说，如果你考察一百家创业公司，起码有九十九家是这种情况。所以，问题不是出在公司身上，这个阶段的公司“就是”这个状态。如果一定要分个对错，那么不对的一定是你，是你没有弄清楚形势，或者说，缺乏足够的业务感知。
+
+所以，与其抱怨合作伙伴心思不单纯，不如去观察他们是怎么搞定各种事情的，慢慢你就会发现，某些事情确实不是心思单纯能搞定的；与其抱怨业务繁杂，不如去了解为何业务这么繁杂，时刻记住“公司要生存”，这些业务到底是自找麻烦，还是不得已而为之；与其抱怨公司没有规范流程，不如去看看大家都在着急处理什么事情，没有制作规范流程，到底是没有意愿，还是没有时间，或是没有资源……
+
+找到这些问题的答案很重要。但身为技术人员，大概很难冲到业务第一线，直接面对客户、面对竞争对手，所以和业务伙伴打成一片就非常重要。只有和大家充分交流，你才能从完整的角度理解公司的这盘生意，从价值链的角度看待自己的工作。最终，你的价值才能够充分体现。
+
+技术人员加入创业公司，遇到的问题通常不是技术问题，难倒他们的也通常不是技术问题。正因为如此，重视非技术问题，在加入之前就考虑清楚，这些再怎么强调也不为过。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/041技术人创业前要问自己的六个问题.md

@@ -0,0 +1,65 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            041 技术人创业前要问自己的六个问题
+                            你好，我是张新波，同盾科技联合创始人兼技术副总裁，今天想跟你分享的话题是“技术人创业前要问自己的六个问题”。
+
+从2002年大学毕业到现在这十几年职业生涯，虽然只经历过四家公司，但是有一半时间是在创业过程中，经历过第一次创业惨痛的失败，也体验过目前创业的快速发展小有所成。创业的过程无比精彩，也无比痛苦，它有可能让你功成名就，更有可能让你一败涂地，因此创业前做好深入的思考和充分的准备是十分有必要的。
+
+我的第一段创业经历是在2005年，一个朋友拉我到杭州做一个短信移动搜索的创业项目，通过短信来搜索生活类信息，有点像短信版的58同城，并且已经和国内非常知名的一家VC谈好了第一笔融资。
+
+当时我正好在第一家公司呆满三年准备出去闯一闯，当时虽然智能手机还没有普及，但功能机几乎已经人手一部了。但是，当你离开家或办公室后，如果想要查询出行、美食等相关信息，是非常不方便的，再加上当时准备用自然语言处理的方式来实现对话交互，是一个非常新颖的方式，所以当时觉得这个方向还是有戏的。然而，这次看起来美好的创业，最后却是一败涂地，自己也深陷泥潭浪费了至少两年的时间。
+
+第二段创业经历是在2013年底。经历了第一段失败的创业后，我去大公司锻炼了整整4年，一直专注在风控领域。当我们CEO邀请我一起创业做一家专业的第三方风控公司时，我觉得事靠谱人靠谱值得冒险，但是基于上次的教训，我还是没有当场就答应，慎重地考虑了一周后，才正式答应加入，如今公司已经迈入独角兽行列。
+
+回头再看这两段创业经历，比较相似，创始人都是我非常熟悉的人，都有海外经历有着宽广的视野，对事业有着执着的追求；都是技术出身，公司做的事情也是技术驱动的事情，并且在当时都是非常创新的业务模式；一开始都拿了非常知名的投资机构的钱，有了资本的支持，但同样四年左右的时间，结果却完全不同。
+
+是什么原因导致了这两段创业结果有如此巨大的差距？总结下来，我觉得除了运气之外，在创业前的六个关键问题上的答案差异导致了完全的不同的结果。
+
+第一，做的事情在今后5到10年，是否是一个大的趋势。 第一次创业时，当时虽然以功能机为主，人们对短信的需求非常强劲，但是智能手机已经开始流行，我自己就买了MOTO的一个翻盖智能机，经常用UC浏览器看新闻资讯。
+
+然而我自己从来没有想过，或者即使想过也没有深入思考过，短信搜索以后是不是可以做的长久，当时只是想快点开始一段新的工作和生活。可惜当时吴军老师的《浪潮之巅》一书还没有出版，还不知道顺势而为这个道理。
+
+第二次创业做同盾时，当时互联网正处在高速发展中，越来越多地渗透到人们日常生活的方方面面，然而个人信息的保护却并不完善，网络上的各种欺诈非常猖獗，并且可以预见，这种状况会长期存在。但是，国内还没有一家专业的公司以一种全新的模式来服务众多的中小公司，而国外不少可以参考的对象已经做得非常不错，以数据驱动的模式做第三方风控，是个不错的方向。
+
+第二，有没有跟对老板。 我毕业后在第一家公司呆了3年，做基于位置服务的车辆监控和报警系统，一开始就是用云服务的模式给众多公司提供服务，并且和河南全省的110指挥中心专线连接。当时还创新性地实现了市场上多家GPS终端设备的兼容，做成了一个基于位置服务的监控报警服务平台。
+
+即使现在回过头来看，我们老总在这些方面也是有着非凡的前瞻性和很强的资源整合能力，是非常有希望把这个事情做大的，但后来因为他自己的一些格局和性格上的缺陷，导致留不住人才，公司始终原地踏步，后来无奈离开。
+
+之后跟朋友创办第一家公司，我又犯了同样的错误。我这位朋友年龄比我大很多，在美国学习工作20年，经历很丰富，人也非常勤奋。他有着非常强的事业心，但是做事比较固执，认准一个方向就会一头扎进去，对外界的变化不是很敏感，以至于在智能手机来临后，依然坚信短信搜索这个方向。再加上在资本运作和商业经营方面的欠缺，导致这段创业非常艰辛，一年就把VC投的钱烧光了，我们俩自己借钱维持公司运营，甚至找我们的投资方借过过桥贷款等，然而大势已去又不能卸下包袱轻装上阵，最后基本上只能勉强苟活。
+
+经历这两段惨痛的教训后，再次选择时我首先考虑人的因素。当时杭州的阿里发展势头最猛，我想这家公司能快速发展，老板一定有不凡之处，我应该去这样的企业学习。事实证明，确实如此，我在阿里的几年亲身见证了这家公司的快速成长，马云的胸怀、眼光、魄力等都很少有人比的上，自己也取得了长足的进步。
+
+所以，后来我们CEO邀请我一起创业时，之所以我在心底瞬间就做了决定，就是因为我对他非常了解。在一起共事的四年中，我发现了他身上很多其他技术人员不具备的特质，比如对风控的热爱，出色的学习能力，有领袖气质，能吸引和说服人才加入团队，以及从体系外从零打造一个风控体系并推销到各个事业部的销售能力等。再加上他之前也有过成功的创业经历，所有这些因素加起来，让我看到了一个未来企业家的样子，愿意和他一起赌一把。
+
+当然，如果你出来创业准备自己当老大而不甘心当一个合伙人，你也得做好创业伙伴的选择，这几乎是所有成败的关键。
+
+第三，是否有足够多的行业积累。 第一次创业时，我只有三年纯开发的经验，并且是只有十几个人的小公司，去了没多久，公司唯一的开发也离职了，所以所有的东西都是靠自己摸索，没有经过正规的训练，也没有学会如何在一个大的团队中进行协作，以致创业过程中走了很多弯路，也不知道找谁来帮助。当时做短信搜索，既没有搜索经验，也没有自然语言处理的经历，完全凭一股初生牛犊不怕虎的精神在支撑。
+
+第二次创业时，经过阿里四年的锻炼，经验、见识、人脉都有了很大的提升，并且我们做的事情还是风控这个老本行，都有非常丰富的经验，这也是我们能快速推出产品，并且在经历快速增长时，能够不断改进和优化系统，遇到困难也能找到帮忙的老同事或朋友，这是我们能支撑上万家客户每天上亿请求量的主要原因。
+
+第四，是否有足够开放的心态。 技术出身的人，往往会陷入我技术好就是比其他竞争对手牛的虚幻中，实际上，技术上的先进不代表产品上的先进，技术上的成功也不代表商业上的成功，创立和运营一家公司是一个非常复杂的系统工程，技术只是其中一小部分。
+
+第一次创业时，我们老总坚持觉得我们在这个领域的技术是最牛的，没法接受移动互联网带来的变化。第二次创业时，我们CEO则迅速把自己变成了一个销售、一个全能战士，自己跑客户谈合作找融资，哪个地方缺人他就补位，包括我自己，虽然还是搞技术，但也接触了很多以前没经历过的东西，不断学习快速成长。这在公司成长的过程中，尤其是早期阶段，帮助我们构建了别人不具备的竞争优势。
+
+第五，是否尊重商业规则。 一起创业的伙伴大多是同学、朋友或同事等比较亲密的关系，既然大家为了一个共同的理想走到一起，想做一件了不起的事情，那就要尊重商业规则，尤其是利益分配上的规则。
+
+可以看到很多公司开始发展的很好，但到后面，创业伙伴却因为利益分配不均而不欢而散甚至反目成仇。所以，一开始，大家就要把这些事情谈清楚，不管事后看来是否合理，只要是双方当时都认可的，就应该遵守，不能因为觉得自己贡献大为啥分的少就不爽闹事，或者看别人现在不值这个价，就想方设法去挤兑甚至坑别人的股份，把团队搞得分崩离析。
+
+第六，是否取得家人的支持。 创业要想取得阶段性的成功，是一个非常漫长的过程，早期一定是拿非常低的薪资，没有太多精力和时间照顾家人，心情也会起起伏伏不太稳定。这时家人是否能够理解和支持，是至关重要的，后院不稳的话，很难有足够的精力和良好的心态迎接创业路上的各种挑战。
+
+以我为例，我第一次创业时还年轻，一无所有，机会成本不大。第二次创业时，虽然有家有口有房贷压力，但是幸运的是家人非常支持，家里的事情几乎不需要我操心，使我可以全身心地投入到工作上。
+
+结语
+
+创业是一件极其有挑战也极其有成就感的一件事情，如果人生当中没有经历过，肯定是一个遗憾。如果你想清楚了，就撸起袖子加油干吧，尽自己最大的努力，准备迎接最坏的打击，永远期待最好的结果。
+
+作者简介
+
+张新波，同盾科技联合创始人&技术 VP，TGO 鲲鹏会杭州分会会长。2009 年加入阿里巴巴，成为国际交易风控与反欺诈团队的早期成员。2009 年至 2011 年，全程参与了国际站风控与反欺诈系统的建设，因为绩效突出被晋升为技术专家。后期负责整个 B2B 风控与反欺诈系统并参与集团统一风控平台的建设，对风控与反欺诈领域有深入的研究。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/042团队激励之分配好你的奖金.md

@@ -0,0 +1,97 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            042 团队激励之分配好你的奖金
+                            大家好，我是刘译璟，百分点技术副总裁兼首席架构师。今天，我想跟大家分享的是团队激励中关于奖金分配的话题。
+
+团队激励有许多种手段，物质方面我们可以考虑股权、绩效工资、项目奖、年终奖、加薪、提成等等，职业方面可以考虑晋升、表彰、授权、培训、宣传等等，还有其他诸如批评、竞争、对赌等等都可以作为激励手段。
+
+众多激励手段中，奖金无疑是最简单最直接最容易见效的。但想把奖金分配好、发到位乃至收获效果，却是一件很有挑战的事。在这里，我想通过案例剖析的方式，同大家分享如何充分利用好奖金激励。
+
+在正式剖析案例之前，有一些背景信息需要先介绍一下：我从2016下半年开始带一条新的业务线，负责政府行业的大数据解决方案和项目落地。团队规模最初大约10人，随着业务快速发展，到2017年底的时候团队已经发展到了180多人，再加上公司其他部门的支持人员，前前后后有近300多人参与过这条业务线。
+
+团队构成方面，有2位业务总经理，4位核心总监，30多个Leader，其余都是普通员工。那么如何在2017年底给大家发年终奖呢？（当然，首先得有奖金可发才行，这个问题需要大家自行解决，不在本次分享的讨论范围之内。）
+
+摆在我面前的第一个问题是，为什么要发奖金，我想通过奖金激励获得什么？我很快有了结论：发奖金是期望团队知道公司乐于分享，业务的成长会给大家带来的收益，并且对业务贡献越大的人获得的收益越多。由此我得出了三个奖金分配的原则：
+
+原则一：根据业务发展情况设置奖金池大小。 业务发展的好则奖金多，发展的不好则有可能完全没有奖金。这个原则比较容易让大家接受，毕竟不会天下掉馅饼，大家只有努力把蛋糕做大才有可能得到更多。也有个别来自基层员工质疑的声音，他们会争辩说“我自己这一块做得好就应该有奖励啊，业务做的好不好我也负不了责。”如何看待和应对这种质疑呢，这里先不展开讨论，大家不妨一起来思考，也欢迎留言讨论。
+
+原则二：根据每个成员在业务中的贡献度统筹分配奖金。 对业务做出越大贡献的人得到的奖金越多，而且我希望贡献度前30%的成员可以分配总奖金的70%！请大家注意，这里的贡献度不是指个人绩效，而是一种对业务的综合影响程度。显然的，团队Leader和关键岗位更容易做出大的贡献，在这种机制下他们天然就会分配到更多奖金，再加上30%的人获得70%的收益，那么这种分配原则公平吗？这也留给大家一起思考。在实际操作中，这是最核心的原则，但也确实是解释成本最高的原则。
+
+原则三：根据每个成员的月薪计算奖金。 每个人的薪酬不一样，这就造成大家对“奖金多少”的理解是不一致的，同样是一万块钱，甲可能觉得匹配自己的努力，但乙就会觉得太少了。为了消除这种不一致，每个人的奖金都会是他月薪的一个倍数。这个原则的解释成本特别低，但在具体操作中会给分配人带来许多工作量。
+
+大家仔细思考可以看出，上述三个原则实际上把个人和团队的利益绑定在了一起，让每个人都切身感受到自己参与到了业务中，业务成长个人才能受益。而这正是我实施奖金激励的初衷。
+
+这些原则是在2017年6月份定出来的。毫不夸张的说，原则一敲定，就等于成功了一半，剩下就是具体如何操作了。
+
+一项政策要落地，不是领导拍脑袋就说了算的，必须得到团队的理解和认可。所以我要做的第二项工作就是细则制定和宣传。在这个环节中，我首先跟2位业务总经理讨论激励目标和原则，进一步明确了以下事项：
+
+
+第一，业务发展状况由公司来评定，主要考虑收入、客户满意度和项目质量；
+第二，成员贡献度的评估精心设计，至少要参考岗位重要度、个人绩效、参与业务的时长这些重要指标；
+第三，成员贡献度被分为S、A+、A、B+、B、C和D七档，对应的奖金是月薪的6、5、4、3、2、1和0倍。很明显奖金的幅度会拉得比较大，这个系数在最后落实时候被调整成了6、5、4.5、3.5、2.5、1.5和0，稍微平缓了一些；
+第四，岗位重要度被分为ABCD四档，分别代表某个功能小组，如咨询、产品、技术等小组中的核心、副手、骨干和成员。我的基本策略是，奖金分配时要优先AB两档，满足C档，照顾D档。因为任何一个小组，只要核心和副手在就能运转起来，只要骨干在业务就能发展，普通成员的参与影响的只是业务发展的速度；
+第五，个人绩效被划分为SABCD五档，分别代表超预期、优秀、良好、合格和不合格。由30位Leader按照小组成员的日常工作情况来评价，并且进行面谈后确定；
+第六，参与业务的时长由HR给出，基本上是按照入职到本业务线的时间来计算的；
+第七，只要参与过业务的人员，不论他是否归属到本部门都会一视同仁，都会计算他的贡献度，都会有奖金。
+
+
+在与2位业务总经理讨论明晰之后，我进一步征求4位核心总监意见，而后在部门聚餐中向30位Leader介绍这些原则和细则并与大家讨论。最后，在一系列的团建活动和培训中向所有团队成员简介2017年度的奖金激励规划。
+
+整个讨论、意见征询和宣传活动贯穿了2017年下半年，团队成员大致都明白了我的奖金激励计划和背后理念。某种程度上讲，我认为2017年下半年的这一系列活动要远比发奖金本身更重要，因为它是团队形成共识的过程，也是塑造团队文化的过程，更是夯实团队班底的过程。
+
+在这过程中，每个人都有机会表达自己的见解，从而有机会识别出每个人对团队、对工作和对利益的不同理解和诉求，团队就是在这些理解和诉求的激烈碰撞中逐步成熟的。
+
+实际的奖金分配工作是2018年1月才开始启动的，此时的关键问题是如何合理的评估大家在2017年的贡献度？在操作层面，我做了如下工作：
+
+其一，我和2位业务总经理为每个成员确定了岗位重要度。这一步是很容易达成共识的，AB两档主要是30位Leader，C档是Leader们委以重任的架构师、高级咨询顾问、高级工程师和设计师等角色，大多数成员都是D档。唯一特殊的情况是，有许多人只是短期支持过本部门工作，贡献度不明显，为此我单独划了一个E档出来，给他们一笔固定的感谢金，不参与贡献度的计算；
+
+其二，由30位Leader给出了每个成员的年度个人绩效。由于Leader的业务职能差异和手松收紧程度不一致，不同团队之间个人绩效的差别还是很大的。同样的研发人员，他在小组甲的绩效可能是A，跑到小组乙可能就是B，这也说明完全按照绩效发放奖金并不是个好主意；
+
+其三，我从HR处获得了每个人参与到本业务线的天数。
+
+收集到以上数据后，我着手设计一个相对公平的贡献度评价模型，这个模型必须站在整个团队的角度评估每一个成员的工作。我的做法大概是这样的：
+
+
+第一，我和2位业务总经理挑选了一些典型员工出来，商定了他们的贡献度档位，作为基准和样本；
+第二，基于上面的样本训练了一个SVM模型，输入是每个人的岗位重要度、个人绩效和参与业务时长，输出是贡献度档位，训练的过程中会发现样本中也存在基准不一致的问题，那就进行适当的调整，最终经过参数和基准调整使得模型的准确率达到95%以上；
+第三，将训练出来的模型用到全体成员上，得到每个人的贡献度；
+第四，一旦有了每个人的贡献度，就可以估算需要的奖金额度，不过还要跟实际的奖金池去匹配，对每级贡献度的奖金系数进行适当的调整，以免发不出那么多的钱……
+
+
+这个过程描述起来很简单，但实际上我前前后后用了两周多时间才计算好，中间涉及到许多沟通、数据校正和系数调整的工作，都是很细的活儿。老实说，由于业务线比较新，2017年在制度建设和数据积累方面条件不足，这部分的工作不算非常细致，例如评价要素不够丰富、个人绩效过于粗糙等等。今年我已经针对这些问题做了制度上的改进，相信2018年的年终奖分配会更加合理和精细。
+
+经过上面的工作，我有了一个初步的奖金分配方案，但这还不够，因为还有一些特殊情况需要考虑，例如有些员工得到了客户的高度认可、有些员工即将承担重要岗位需要特别鼓励、有些员工月薪偏高/偏低等等等等，以及每个Leader对团队成员都会有一些微调。因此，我又做了两件事：
+
+
+第一，与2位业务总经理讨论，对极个别特殊员工进行了贡献度上调整；
+第二，对每个小组，利用上面得到的分配方案核算出一个奖金包，给到小组Leader，由他进行微调，再反馈给我；
+第三，汇总上面得到的数据，形成最后的分配方案。
+
+
+这一阶段的工作又持续了两周。在这一个月时间内，分配方案更新了12个版本才算敲定。任何涉及到利益的事都不能大意啊！
+
+分配方案敲定以后，从2018年2月开始，团队开始逐层沟通每个人的年终奖，总的来说非常顺利，没有出现负面的声音。大家也拿着年终奖开开心心过了大年。
+
+以上就是我进行2017年奖金分配的整个过程，期间其实还有许多小插曲，以及公司和业务线的特殊情况，这里就不展开了。通过这个案例剖析，我想大家可以感受到奖金激励不只是最后发钱那么简单，而是一项需要考虑公司文化、业务体系、制度和利益的细致工作。如果做不到位，甚至会带来反效果，还不如不发。
+
+小结一下，奖金激励是团队激励中最直接和有效的手段，但为了更好地发挥奖金激励的效果，管理者需要做到以下几点：
+
+
+必须想清楚发奖金的目的是什么，按照什么原则发；
+要通过一系列的宣传工作让每个人知晓管理者的目的和原则，团队齐心激励才有意义；
+需要设计合理的机制，保证奖金的分配是合理的，是可以被团队认可的；
+发放奖金时各层管理者一定要进行面对面的沟通，讲清楚规则，让员工理解我为什么拿了这些奖金，以后怎么办才能得到更多。
+
+
+最后，希望所有的团队管理者都能运用好奖金激励这个手段！
+
+作者简介
+
+刘译璟，百分点信息技术副总裁，TGO鲲鹏会北京分会会员。负责产品研发工作以及研发团队管理和培训工作。工作后主要关注高并发Web应用、分布式存储和计算、机器学习、商业建模和用户画像等技术领域，以及个性化推荐、互联网广告、精准营销和客户管理等应用领域。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/043通过积分考核提升技术团队的绩效.md

@@ -0,0 +1,79 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            043 通过积分考核提升技术团队的绩效
+                            你好，我是一维科技CTO杨立东，今天我想跟大家分享的话题是“如何通过积分制，更合理有效的考核技术团队。”
+
+技术团队考核一向是个大难题，合理的考核机制加上奖励制度，能极大激发团队成员的热情，提升团队效率，而不合理的考核机制，却往往会造成团队缺乏热情，高手离职、庸人留下的严重后果。今天，我就想跟大家分享一个综合了不同考核方法优点的方法——积分制。
+
+在聊积分制之前，我想先说一下，为什么我认为“任职资格标准”和“OKR”这两种人力资源方法并不适合作为技术团队的考核方法。
+
+1.任职资格标准——技术人员的晋升通道
+
+很多公司已经实施了任职资格标准，通过任职资格标准给技术员工进行评级，让技术人员在公司内有明确的晋升通道，解决的是员工持续发展的问题。而技术管理者可以根据不同的级别设置不同的薪资范围，一旦员工通过评估达到了相应的级别，就应该主动给这个员工加薪到这个级别的薪酬范围。这样员工才能有动力持续不断的努力达到更高的级别。
+
+但是，任职资格标准更像一个门派武功或者修真秘籍，用于长时间的筛选这个门派的核心骨干，在更高层面上，通过不断招募新人和让每一个人在这个标准下不断的晋级两种方式来保持技术团队的搭配合理性。
+
+因此，虽然这种方法对员工有一定的激励作用，但却不足以用来刺激员工或团队提升效率。因为每人起点不一样，有的员工想半年晋一级，有的员工觉得两年晋一级就不错呢。
+
+2.OKR——聚焦员工和团队的工具
+
+技术团队的工作大多是多目标的，特别是如果你服务的对象是企业客户或产品经理，他们会毫无节操的给你们团队设定目标。这些无聊的需求和目标足以让技术团队抓狂，但如果实施了OKR，将会缓解掉这些矛盾。
+
+我们可以给团队设定相对单一的目标（O），可以是进度，也可以是这期迭代要完成的功能和产品特性。而在这个目标下最多分解不超过3个关键结果（KR）。对于团队中的个人也是一样，设定与团队相一致的目标和关键结果，这样才能让团队聚焦到最重要的工作中去。
+
+那为什么OKR不适合做考核呢？因为在实际操作中，有人喜欢挑战，KR设得高却可能得不到高分，有人保守，KR设的很低，不需要努力都能达到。如果把OKR作为考核工具，必然结果是每个人都去设定没有挑战的目标，这非常不利于团队的激励，也偏离了OKR管理的初衷。
+
+既然任职资格和OKR都不适合做考核工具，什么才是适合团队的考核方法呢。我们都耳熟能详的绩效考核方法包括：360度考核法，BSC平衡记分卡，KPI法等等。我们不去评价哪种方法的好坏，因为不同的组织和公司文化适用不同的方法。下面我想跟大家介绍的这种方法是综合了不同考核方法的结果，积分制。
+
+首先来看项目积分的设定
+
+积分制适合于项目型组织，在这个组织里，一切都可以转化为不同类型的项目。管理层首先要对项目进行重要性排序或者打分。根据项目的规模，这个活动可以每个季度执行一次，也可以每个月执行一次。与此同时管理层还需要给每个项目设定1-3个量化的目标，为目标设定卓越线和及格线。
+
+
+
+如果一个项目目标都达到卓越，那么最终每个成员的项目得分都是满分。例如，参与“盘古”项目的成员，项目上线后1个月内统计数据显示产品7日留存率提升到了39.7%，崩溃率降到了0.19%，那么所有参与该项目的成员都能拿到项目分的满分5分。
+
+接着来看个人积分的评定
+
+项目得分如果参考量化标准，是比较容易打分的，但个人打分是一件十分困难的事情。作为技术管理者，这个时候就到了体现你智慧的时刻，你可以把打分的权利完全授权给团队，让他们根据对目标的贡献度互相进行打分。你可以给定一个总分数和两条打分原则：1.不能均分；2.按照每人对目标的贡献度进行打分。
+
+总分的范围为团队人数×项目系数，而项目系数从1-5，越早上线的项目系数越大，从而激励团队尽早完成项目和上线使用。如果项目周期3个月，系数可以如下表。其他项目的系数根据项目周期可以类比。
+
+
+
+还是以“盘古”项目为例，项目提前2周上线，那么项目系数为4，同时项目人数10人，那么我们可以设定团队的总分为10×4=40分，这40分分给团队让团队进行自己打分，个人最多5分，最少1分。这个打分过程由于不能平均，每个人又都按对目标的贡献进行打分，所以会相对公平一些。如果你在这个项目中得到了5分，那么你在这个项目的期间段个人积分就是项目分×个人分，也就是5×5=25分；如果你的得分只有3，那么你该项目的个人积分就只有3×5=15分。这个方法将会大大拉开不同成员之间的差距，起到更好的激励效果。
+
+积分季度排名和年底排名
+
+不同的公司可以按照以上的规则进行季度排名和年底最终排名，根据自身的经营情况可以按季度发放奖金，也可以年底统一发放。出于诸多因素的考虑，我还是建议全年排名和计算发放。那么问题来了，不同的积分该发多少奖金呢？
+
+首先，年初管理层应该根据预测的业绩设置一个奖金包，这个奖金包就是发放的基础。奖金包是否独立于年底双薪取决于你们的招聘制度，如果公司不愁招人，完全可以忽略双薪，直接定奖金包。如果招聘环节招人就困难，那么奖金包应该区分于年底双薪而独立设定。既然是奖金包，最少也要有技术团队2倍工资作为起点才有意义，如果太少，什么考核方法也起不到激励作用。
+
+其次，奖金倍数的计算是根据员工积分进行的，积分的导向就是尽量拉开差距，不搞平均主义。可以设定积分排名前20%的人按4-8倍系数发放奖金，后20%的人不发奖金，中间60%的人能拿到1-2倍系数奖金。在这种体制下，如果你月薪20000，排名第一，就可以拿到20000×8=160000年终奖金。
+
+需要注意的是，中层经理不参与积分，如果要考核中层，可以参考360度考核法。
+
+最后，需要在试用第1年后汇总员工的建议，并根据反馈将以上的考核方案形成制度，然后通过人力资源部和CTO两个渠道下发给员工。我们不难发现，积分考核综合了KPI和OKR，鼓励做有价值的项目，鼓励在项目中有卓越的和目标相关的表现，同时还导向项目及早上线。
+
+最后来说一下实施积分制的阻碍
+
+技术团队考核是行业难题，所以不管实施什么考核方案都是困难重重，阻碍多多。项目的分数评定是需要所有相关的高管共同参与的，即使出来一些没有规划的临时项目，也需要高管们及时给一个项目分数。
+
+同时员工也不愿意去做那些低分项目，比如：运维，行政，市场等，因为这些项目很难出成绩。对此，需要直接主管配合员工设定合理的量化目标，确保即使项目不容易拿高分，也能让个人在项目表现中拿到高分。
+
+另外，互联网公司项目的量化目标相对好设定和检验，可以通过第三方数据公司获取相对客观的数据。而对于面向行业进行项目交付的公司，项目的分值大同小异，因为你不太容易界定那个客户重要，哪个客户不重要。
+
+因此，在这种类型的公司里，个人积分排名不容易拉开，就失去了实施积分制的意义。所以追本溯源，还是要通过项目毛利、项目回款等因素对项目进行不同分值的划分，通过项目预算节约、进度和上线后售后投入等因素对项目给予不同的项目系数。
+
+小结
+
+作为技术管理者或者CTO，团队效率的提升是首要考虑的事情，当你还是一个小团队时，可以撸起袖子加油干，而随着团队的扩大，就需要建立适当的规则再用公司情怀来激励。团队再大一些，再讲情怀已经没用了，务实一些就需要建立合适的考核制度。
+
+积分制在项目层面综合了OKR的目标管理的精髓，让团队关注对公司最有价值的项目，同时在个人考核上又遵循了KPI的方式，只不过把KPI的权利下放给团队进行互评，这样更能激励那些自身努力而又关注目标的员工。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/044空降技术高管的择业七计.md

@@ -0,0 +1,117 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            044 空降技术高管的择业七计
+                            你好，我是黄勇，今天想跟大家分享的话题是“空降技术高管的‘择业七计’”。
+
+2015 年，我离开阿里，空降到一家创业公司做 CTO，原本以为自己可以轻松驾驭这个岗位，没想到刚加入公司，我就面临了职场中最大的三个挑战。
+
+挑战一：我的空降打破团队平衡，受到团队的质疑和排挤
+
+我第一天来到公司，有位同事就找我私聊，突然问我：“你会把我们现有技术团队都开掉吗？”这句话如同晴天霹雳，让我猝不及防，我根本没有想到他会问我这样的问题。还好我脑筋转得快，镇定地反问他一句：“你为什么会这么问？”，此时我的大脑在飞速地运转，思考接下来应该如何回答这个尖锐的问题。
+
+他很直接的说：“你是搞 Java 的，我们是搞 PHP 的，你以后肯定会招 Java 的人来取代我们”。我对他说：“我只会开掉长时间都做不出成绩的人”。这句话言简意赅，他瞬间找到了答案，认识了我的态度，我也顺利地化解了这次挑战。
+
+但挑战并不总能迎刃而解，面对一个新的地盘，我很需要有自己的人，这样我才能更快地做出成绩。
+
+我邀请了几位以前合作过的同事加入公司，我不再是一名空降兵，我们形成了空降部队。我的初衷是想用自己熟悉的人来提高工作效率，没想到却带来了“抱团”现象，技术团队变成了新老两个团队，我是“新人队”队长。老人队不约我们新人队吃饭，甚至也不主动找我们讲话，我约老人队一起吃饭，吃饭时大家各玩各的手机，一句话也不说，场面十分尴尬。我毕竟是 CTO，我深知自己不能搞团队分离，但我当时面临这样的挑战，却显得束手无策。
+
+除了缺乏同事的信任以外，我还面临着第二个挑战。
+
+挑战二：产品系统架构非常脆弱，现在是否应该推倒重来
+
+当时公司产品虽然已经上线，产品质量却出现了非常严重的问题，其他部门领导吐槽声不断，每次管理层周会上，我都是他们“批斗”的对象。原来最近半年里，公司已经换掉了两批技术团队，前面已经走了两位 CTO，我是第三任。原本以为是蝙蝠侠，没想到却是背锅侠。
+
+当我看到用户注册都有 Bug 时，我才感受到自己这次接手了一个“烂摊子”。反之，我看到了这也是一个绝好的机会，如果我能将产品质量提升，那么这个 CTO 的位置我才能坐得长久。
+
+当时整个系统是一个单体架构，不管是上线一个新功能，还是修补一个 Bug，都要手工部署，效率极低，而且每次上线时间都要放在深夜里，上线前还需要发布一条网站升级公告。我之前在阿里研究过微服务架构，也实践过 Docker 容器化技术，站在技术人员的视角上，我很想在团队中实践微服务架构，但又担心研发成本太高，如果失败了，我的结局也会和两位前任一样，更严重的是，这家创业公司会断送在我的手里。
+
+我最终放弃了这个美好的想法，开始脚踏实地修改每个 Bug。我将关注点转移到了研发流程上，开始亲自带领团队，采用敏捷方法进行产品研发，短期内让团队的节奏有了改善。
+
+当我花了一个月的时间，熟悉了现在的团队后，紧接着就遇到了第三个挑战。
+
+挑战三：公司只能发四个月工资，产品出不来公司就关门
+
+记得有一天，我和老板一起吃饭，他告诉我：“天使轮的钱不多了，只够发四个月工资，商业模式还没得到验证，产品功能还没开发完毕，很可能公司就要走不下去了……”。没等老板把话说完，我就告诉他：“用不了四个月，给我三个月就够了，我让产品闭环，你可以拿着产品去跟投资人讲故事了”。
+
+背水一战，没有任何退路。我带领团队，疯狂地工作，每天早出晚归。那时我女儿才两岁，活泼可爱，但我几乎没有亲眼看到女儿醒着的时候。我下班到家时，她已经睡着了，我去上班时，她还没醒来。在深夜里，我只能摸摸她柔软的小手，看看她睡着时的可爱模样。
+
+我们的努力是值得的，只用了两个半月的时间，团队完成了所有的产品新功能，修复了所有的 Bug，新产品重新上线，老板给产品取了一个代号，叫做 Raffael（拉斐尔）。这是一个人名，拉斐尔是意大利著名画家，也是“文艺复兴三杰”中最年轻的一位，代表了文艺复兴时期艺术家从事理想美的事业所能达到的巅峰。也许这正是老板内心对产品的寄托，或许也是他对自己的勉励。
+
+在 2015 年春节前，公司顺利地拿到了红杉资本的 A 轮融资，我们用这笔钱度过了之后的两年。公司的业务有了明显增长，产品也添加了更多的功能，团队规模也逐渐壮大起来，我也逐渐找到了做一名 CTO 的感觉。
+
+谈谈技术人员的择业问题
+
+作为一名技术人员，不管是程序员还是 CTO，在面临跳槽时，我们该如何选择呢？是否存在科学的判断方法，避免我们跳槽不慎变“跳坑”呢？
+
+其实早在两千多年前的春秋时期，孙武就提出过这样的观点：
+
+
+故校之以计，而索其情。曰：主孰有道？将孰有能？天地孰得？法令孰行？兵众孰强？士卒孰练？赏罚孰明？吾以此知胜负矣。（节选自《孙子兵法》始计篇“七计”）
+
+
+我尝试将孙武的文言文翻译为以下白话文：
+
+
+所以，可以通过比较双方的具体条件来探究战争的最终胜负，即哪一方君主更得民心？哪一方将帅更有才能？哪一方更得天时地利？哪一方军纪更为严明？哪一方兵力更加强大？哪一方士卒更加训练有素？哪一方赏罚更加公正严明？我通过这些就能够料知谁胜谁负了。
+
+
+尤其对于 CTO 这类技术高管而言，看似在公司级别很高，但跳槽风险也巨大。空降之前，不妨用孙武这“七计”加以判断，我将其诠释为“择业七计”。当我们在对比未来要去的公司，不知道该去哪一家时，不妨一试。
+
+
+主孰有道？→ 哪家老板更有战略？
+将孰有能？→ 哪家领导更有才能？
+天地孰得？→ 哪家项目更合时机？
+法令孰行？→ 哪家制度更加合理？
+兵众孰强？→ 哪家规模更加强大？
+士卒孰练？→ 哪家员工更加精炼？
+赏罚孰明？→ 哪家薪资更吸引人？
+
+
+第一步，比较老板，他的方向是否明确？眼光是否长远？性格是否喜欢？这些问题其实都能在面试的时候找到答案，我们更多的是抛出一些问题，看他的回答是否让自己满意。他在了解你，你也在了解他，两人就像谈恋爱一样，他将是你比面对自己老婆的时间还要多的人，合作前花再多时间聊都不嫌多。
+
+第二步，比较公司各个职能部门的领导，尤其是将来和自己密切共事的几位领导，如果有可能的话，最好在面试的时候要求和他们当面聊聊，通过交谈可初步判断出他们的才能。能够胜任 CTO 这个岗位，我们必须培养自己与非技术同事交流与合作的能力。
+
+第三步，判断公司做的项目是否赢得市场？是否适应当前时机？第四步，比较公司的管理制度与企业文化，判断一下自己是否能接受。第五步，比较公司的市场份额与人员规模。第六步，比较员工的基本素质。第七步，比较薪资待遇。
+
+如果你打算做空降 CTO，以上七个步骤，千万不要搞颠倒。
+
+写在最后
+
+我对担任空降技术高管的经验，归纳为以下4点：
+
+
+空降兵要为人亲和；
+谨慎引入空降部队；
+快速培养左膀右臂；
+全力以赴完成目标。
+
+
+我对空降技术高管的团队管理思路，归纳为以下6个步骤：
+
+
+学习公司业务；
+理解企业文化；
+调整研发流程；
+优化技术架构；
+建设团队文化；
+让管理自动化。
+
+
+我的团队管理秘诀是：
+
+开心 → 交心 → 关心 → 同心
+
+先让团队玩在一起，开心工作，时常和大家交心，问问大家工作上需要哪些帮助，关心身边每一位同事，团队才会与自己同心。
+
+如果说“钱、事、人”三者，我们需要根据优先级排一个顺序的话，我认为一定是：人、事、钱。人对了，才能把事做好，才能赚更多的钱。
+
+作者简介
+
+黄勇，TGO 鲲鹏会上海分会会员，畅销书《架构探险》作者，开源软件作者，拥有十年以上互联网软件从业经验，擅长系统架构与技术管理。喜欢阅读，热爱交流，乐于分享。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/045选好人生下一站--CTO空降上篇.md

@@ -0,0 +1,85 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            045 选好人生下一站--CTO空降上篇
+                            你好，我是易建科技技术副总裁钟忻，今天我想跟大家分享的是关于CTO空降的话题，本篇文章是上篇，探讨如何做好空降前的准备。
+
+对于CTO（技术总监）来说，他们已经成为公司或部门技术的最高负责人，实现了人生一个小目标，成为众多技术人崇拜的对象。那么CTO的下一站又在哪里？当自身发展遇到瓶颈，决定再次起飞时，选择合适的着陆地点也许就决定了是否能够抢滩成功。
+
+与自己对话——下一站在哪里？
+
+关于这个问题，我跟圈子内许多CTO朋友聊过，也看过一些行业专家的文章，其实这本质上是一个个人成长的问题，我想无非分为如下几类：
+
+1.寻求更广阔的空间
+
+当CTO所在的公司业务增长放缓，团队趋于稳定，没有太多技术上的挑战出现时，因为技术出身的高管通常对自己都有着更高的要求，有颗不安分的心，所以，如果这时候有个成长型的公司抛出橄榄枝，提供更大的想象空间和可以另起炉灶、大展拳脚的机会，这对他们来说有着致命的诱惑力。
+
+新的公司或者有新的技术方向可以去追逐，或者是一个新兴的行业有着广阔的商业前景，能够带来更大的成就感，这些都是成熟型公司的CTO看中的。
+
+2.转型不同的角色
+
+另外我也看到周围有一些综合能力比较强的CTO，作为高管或者合伙人，本身在公司就承担了技术以外更多的业务的职责，希望慢慢转型成为CEO或者一个子业务的GM，这个时候，这种类型的工作机会对他们而言也是很有吸引力的。
+
+正所谓“不想当CEO的CTO不是好厨子”，未来科技对于行业的影响会越来越大，会有越来越多技术出身的CEO出现，这样的综合性人才是市场上非常欢迎的。如果能兼具技术背景和业务能力于一身，也是CTO未来可以考虑的一条不错的发展路径。
+
+空降前的“功课”——如何选好下家？
+
+当技术高管做出决定迈出下一步，或者有人抛出橄榄枝时，如何选下家就变成一个非常重要的问题。因为高管更换工作的风险远远大于普通的工程师，这一步必须慎之又慎。由于没有提前做好功课，我周围有些CTO从稳定的大平台出来之后，一年换一次工作，甚至更高的频率都是有的。
+
+因此，在想要施展一番抱负的冲动之下，理性的权衡还是非常必要的。我总结有以下几个重要的因素需要在空降前考虑：
+
+首先是企业诉求，需要考虑对方对CTO的诉求，按照个人理解的风险由小到大排列，无非是以下几种：
+
+1.拉升逼格
+
+该公司业务和团队都已经比较稳定了，但是需要更加体系化的管理和创新，想要吸引更多人才，提升技术实力等等。比如C轮以后的公司需要上市，原有的技术合伙人执行力可能足够，但是视野格局、宏观把控、人脉名气等诸多方面欠缺且无法迅速提高，因此需要一个能力全面经验丰富的CTO坐镇。这种在对企业进行比较仔细的考量后，我认为是风险比较低的一种很好的选择。
+
+2.救火队员
+
+该公司的业务模式已经确定，也有一个基本的团队框架，但是原有团队的技术能力已经不足以应付业务的需求，疲于奔命。甚至产品的稳定性等各方面都存在很大问题，有诸多技术挑战亟待解决。这个时候，他们需要的是一个技术能力过硬，同时能够很好的进行团队沟通协调，迅速灭火，稳定局面，把业务带入正轨的CTO。跟上一种情况属于锦上添花相比，这种情况就属于雪中送炭了。但同样，因为企业的诉求比较明确，只要是方向对口，自身实力过硬，我觉得也是比较好的选择。
+
+3.互联网“焦虑”
+
+该公司有着成熟的业务和稳定的营收，但在互联网催生的一波波技术大潮冲击之下，公司高层要么是想未雨绸缪，要么是看到互联网巨头正在逐步渗透到自己的领地，产生了危机感，加上公司本身对人才的吸引力也不够，技术团队老化严重，于是产生了从外部招聘技术高管，吸纳新鲜血液，尝试业务创新的念头。这种情况，由于公司原有的结构比较固化，新业务一般也不清晰，对于CTO来说，有着比较大的风险，需要慎重对待。
+
+其次是企业文化，在搞清楚企业诉求之后，如果觉得宏观层面风险不大，那就要考虑微观层面的适应性问题了，主要可以从以下几个方面着手：
+
+1.业务状况
+
+公司所处的行业，是否具有一定的行业壁垒，还是很容易被复制。目前的收入、利润、现金流是否稳定，资金是否充足，这决定了公司能够给CTO多大的时间窗口来施展才华。
+
+2.管理模式
+
+公司是什么样的组织架构和文化，公司的工作氛围如何。CTO在公司组织架构中处于什么样的地位，能够掌握多大的资源和话语权，这决定了CTO到岗以后能够发挥多大作用。
+
+3.人员状况
+
+现有技术团队的状况，是否短期通过简单的调整就可以胜任，还是需要大幅度引入外部人才。如果是后面的情况，那CTO在加入之前就要做好相应的准备，通过迅速招人来扭转局面。
+
+最后是渠道问题，是通过猎头还是熟人推荐。
+
+对于求职来说，猎头是绕不开的话题，但我想说，对于技术高管，选择猎头的风险是非常大的。如果CTO本身有足够大的名气和人脉，能够获得非常理想的工作机会，这是最佳的选择。因为通过人脉去了解到的企业的信息是比较准确的，另外跟对方的高层有一定的熟悉程度，也大大降低了加入以后磨合的风险。
+
+那么猎头推荐的机会到底看不看呢？其实，我觉得通过猎头是一个比较好的了解外部市场的机会，不必太排斥。比如我在上一家公司的时候，很多大企业需要云或者大数据背景的机会都会找到我这边，接触一下，多了解一下外部的信息我觉得没什么不好。
+
+但是反过来说，单纯听猎头的一面之词，以及通过几次面试跟企业的简单接触，就决定加入，对CTO来说是不可取的。因为面试的时候，大家展现的都是最好的一面，也许入职不久就会发现很多之前完全预想不到的情况。
+
+所以，最好的做法就是在了解到机会之后，通过自己的人脉找到内部员工了解真实的情况。如果没有特别靠谱的信息渠道，那么不妨等等再做决定。
+
+临渊羡鱼，还是退而结网
+
+作为CTO，大家都知道，行业是有周期的，所以看机会的时机也是很重要的。从2016年开始，我明显感觉互联网创业的机会越来越少了，而AI的机会多起来了。毕竟对于CTO来说，更换工作的风险和成本都是很高的，因此，我个人觉得在行业高峰期，可以适当激进一些，因为这个时候机会比较多，即使失败，找个下家也是容易的。但如果在低潮到来的时候选择冒险，那么一旦失败，可选择的余地就会小很多。这个时候不妨慎重一些，在稳定的平台里面再多修炼一下也未尝不好。
+
+最后，小诗一首，送给大家。明天的CTO空降下篇更精彩，请多点赞：
+
+烽火照西京，心中自不平。牙璋辞凤阙，铁骑绕龙城。雪暗凋旗画，风多杂鼓声。宁为百夫长，胜作一书生。
+
+作者简介
+
+钟忻，易建科技技术副总裁兼云服务事业群总经理，TGO鲲鹏会北京分会会员。2003年清华大学自动化硕士毕业。曾在Turbolinux、IBM、Intel等多家IT公司担任资深软件工程师。13年底到16年初担任乐视云平台高级总监，主导了乐视IaaS、PaaS平台从无到有的全过程。目前负责易建科技上千人研发团队的技术体系的搭建，以及整个海航集团的IDC和基础云平台的产品研发、运营和市场开拓。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/046走出至暗时刻--CTO空降下篇.md

@@ -0,0 +1,79 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            046 走出至暗时刻--CTO空降下篇
+                            你好，我是易建科技技术副总裁钟忻，昨天跟大家分享了CTO空降前该如何做好准备，今天接着上一篇，探讨当CTO迈出了职业生涯关键的一步，空降到新的平台之后，该如何一步步开展工作，迅速发挥作用，得到公司上下的认可呢？我想无非是从做事和做人两方面来看。
+
+做事
+
+首先说说做事，CTO可能需要经历如下三个阶段，才能到达比较理想的状态。
+
+1.蜜月期——提理念，找突破
+
+一般CTO愿意接受新的工作机会，双方肯定都是比较认可的，而且无论是公司管理层还是CTO本人都是见过大风大浪、比较理性的，所以我认为蜜月期一般来说都不会有太大问题。
+
+蜜月期，公司管理层一般都会要求CTO对产品团队等做系统的梳理和规划，提出新的想法和见解。而对于经验丰富的CTO来说，通过迅速深入一线沟通了解情况，并凭借之前的经验和良好的技术视野，在短期内拿出一份系统性和实操性都比较强的方案，并得到管理层的认可，一般都不是太大问题。加上双方刚刚接触，展现的更多的还是好的一面，对对方也都会比较宽容，因此，蜜月期通常都能很好的渡过。
+
+另外，CTO入职本身就是一个比较高调的事情，新来的技术高管无疑会吸引很多的目光，所以保持低调，少说多做，反倒是比较理想的选择。在面上取得系统性的突破肯定不是一日之功，但是在一些点上迅速发现问题做出亮点还是很有可能的。比如迅速引入或者落地一些工具和方法，改进一些流程和制度，提升团队士气；或者聚焦在一些系统的稳定性问题上，迅速攻克技术难点，扭转技术团队的被动局面。对于技术功底扎实、经验老道的CTO来说，这些都不是太大的问题。
+
+2.考验期——苦干实干，牢底坐穿
+
+我有几位师兄弟，之前都担任过行业领头羊或是上市公司的CTO或者技术VP，大家在讨论空降这个话题的时候，都比较认同第二个阶段对CTO是比较严峻的考验。我相信大部分技术高管，无论是客观还是主观的原因，没能顺利空降，问题也都是爆发在这个阶段。
+
+其中一位有一句名言：“我所见过的技术高管，蜜月期以后还能活下来的，都是搞过封闭开发的”。无论这句话有多少主观成分，还是充分体现了CTO这个职位面临的压力和挑战。有的是在工作深入开展以后，发现跟公司管理层在管理理念、做事风格等多方面存在很大差异。有的是在取得一些工作进展后，让老板的期望值越来越高，承担的工作也越来越多，到达一个瓶颈以后，很容易出现顾此失彼、捉襟见肘的局面。
+
+我本人从技术总监到技术高管，一个很深的体会就是，虽然都是独当一面的技术负责人，但总监跟CTO有一个本质的不同。总监的上司往往还是技术口的，而CTO的上司显然是业务口，很有可能完全不懂技术，所以沟通的成本和获得认可的难度无疑是几何级数的差别。
+
+那么对于CTO来说，在这种局面下，出色的抗压能力无疑是必须的。在跟公司管理层无法很好的达成一致的情况下，我认为还是尽量求同存异，不要有太多其他想法，毕竟老板在业务方面的理解和行业经验的积累上，一般来说还是远强于CTO本人的，先按照他的想法来执行，再通过实践来检验成果。
+
+另外在被动的局面下，超出预期无疑是非常困难的，但我认为这也是不容逃避的。一方面要顶住压力，另一方面要在老板不重视的方向和事情上，迅速做出成绩，超出预期，这无疑是走出困境的最佳选择。
+
+当然每个人的能力和精力都是有限的，事情太多铁打的金刚也扛不住。在适当的情况下，也可以学着say no。把精力聚焦在重要的事情上，抓大放小。这样虽然在一定时期会遭到一些质疑，但在长期看无疑是明智的，最终理性的老板还是会认可和接纳的。
+
+总的来说，所谓“封闭开发”这样的做法不一定是必须的，但是拿出态度来，打破自己之前的认知局限，真心实意的苦干实干，熬过“黑暗时刻”，光明总会到来。最终或多或少都会有一些突破和成果，公司的管理层也肯定能够看到CTO和团队的努力付出的。
+
+3.稳定期——全情投入，放眼未来
+
+熬过考验期，进入第三个阶段，无疑是值得高兴的。这说明CTO跟公司管理层有了充分的了解，适应了公司的文化，能力也得到了认可，可以更多的按照自己的想法来大展拳脚。往往这个时候，团队也比较成型了，沟通也更顺畅了，所以有时候会有些放松和麻痹大意。
+
+这个时候，作为CTO，应该有居安思危的想法。自己原有的思维格局和体系，可能很难突破了，因此，一方面要多关注团队成员能力的提升，给他们更多的指导；另外一方面则可以把眼光投向外部，多借鉴同行的先进经验，在框架性体系化上面打打基础，为迎接新的挑战做好准备。
+
+做人
+
+说完做事，再来说说做人，CTO本身就是一个重要的管理岗，跟方方面面都要打交道，因此，能得到各方的接纳对开展工作也是非常关键的。主要分为对上、对中和对下三方面：
+
+1.老板——如何做好向上管理
+
+取得老板的认可接纳，得到充分的授权，这是CTO做好工作的先决条件，这个道理大家应该都是非常明白的。在初来乍到的情况下，一定要密切的跟老板沟通，加快磨合的速度，搞清楚老板的真实想法。在上面的段落里也提到了，尽量求同存异，按照老板的想法执行，并且力求超出预期。
+
+2.同事——团结一切可以团结的力量
+
+跟平级的同事打交道，获得他们的支持也是很重要的，比如市场营销团队、财务人力等职能部门。CTO在这个时候更需要的是领导力、沟通能力，而不是管理能力。
+
+在具体操作中，我认为掌握两个要素比较关键。一个是取得共识，只要大家利益一致，对公司全局有好处，大家就能够达成一致，这样就好合作。另外一个是互惠互利，相互帮助。多换位思考，看看对方的难处是什么，在边界比较模糊的时候，尽量多做一点，毕竟你的最终的目标还是为了结果的达成，这个才是最重要的。
+
+3.下属——如何让下属信服
+
+空降还有一个蛮有意思的地方，就是怎么获得下属的支持。让大家忘记“前任”，迅速的接纳你，这样你的想法才能落地执行，这也是CTO工作的根本所在。作为CTO，在技术能力、经验和视野上肯定是远强于自己下属的，让他们在技术上信服一般不是难事。但怎么让原本不认识你的一大群人一下子能很好的执行你的想法，还是需要下功夫的。
+
+我自己总结下属有三种类型。一种是听话型，这类下属本身人就比较nice，跟谁都能很好的配合，在工作中也能够很快感觉到他对工作的热情和执行力，那么迅速委以重任就可以了。
+
+第二种是合作型，他们不会像第一类那么自来熟，但他们会比较有想法，也有能力。这类下属从管理者的角度，跟他充分的沟通，给他施展的空间，让他感受到你对他的支持和认可，那么也是比较好合作的。
+
+第三种就有点让人头疼了，权且叫反动型吧。由于种种原因，不配合你的工作，甚至原来在团队就是刺头。这种一般来说还是先尝试按第二种情况来处理，如果确实有能力也能够合作，那不妨多包容。但在某些情况下，为了维护权威性，在得到管理层的充分授权后，也可以考虑采取极端措施。
+
+在这里我分享一个有意思的事情，我之前有一名下属，脾气比较火爆，个性也有点封闭，做事风格跟我平常倡导的也完全不同，但是执行力非常强，因为一些历史原因和观念的差异，空降之后双方合作一直磕磕绊绊，好在工作也能往前开展。
+
+直到我离开公司后，有一次特别意外，他突然给我发微信对我表示感谢，我还挺感动的。因为我在管理上，一直提倡要成就别人来成就自己，也给过他不少帮助，他在时过境迁之后自己也意识到了这一点。CTO作为管理者，应该坚持做对的事情，时间会证明一切。
+
+到此为止，CTO空降的上下篇就要划上句号了，文章结尾把电影“至暗时刻”中丘吉尔的名言送给诸位：Success is not final, failure is not fatal, it is the courage to continue that counts。恰逢技术盛世，唯自信与勇气不可辜负，加油吧，少年们。
+
+作者简介
+
+钟忻，易建科技技术副总裁兼云服务事业群总经理，TGO鲲鹏会北京分会会员。2003年清华大学自动化硕士毕业。曾在Turbolinux、IBM、Intel等多家IT公司担任资深软件工程师。13年底到16年初担任乐视云平台高级总监，主导了乐视IaaS、PaaS平台从无到有的全过程。目前负责易建科技上千人研发团队的技术体系的搭建，以及整个海航集团的IDC和基础云平台的产品研发、运营和市场开拓。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/047空降领导者平稳落地要做的四道题（上）.md

@@ -0,0 +1,100 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            047 空降领导者平稳落地要做的四道题（上）
+                            你好，我是饿了么技术创新部高级总监史海峰，今天想跟大家分享的话题是“空降领导者平稳落地要做的四道题”。
+
+2016年11月底，我从当当离职，入职饿了么，担任当时饿了么北京研发中心的总经理。这种“天上掉下个领导来”的操作方式，职场上俗称“空降”。
+
+在我入职一年半之后，已经更名为技术创新部的北研团队规模超过90人，负责项目超过20个，并且在2017年9月，从0到1做了新零售行业风口项目“无人便利货架”。目前，团队核心成员稳定，我这次“空降”算是实现了“软着陆”。
+
+身在职场，难免跳槽。做管理到了一定职级，更难免以领导者角色进入新的组织，当然不一定是跳槽，也可能是在内部转调。我自己空降过，见过、经历过的空降也不少，听说过的行业新闻更多，其中有成功也有失败，比如郭士纳和陆奇，一个让大象跳舞，一个却黯然离场，结果大相径庭。
+
+那空降到底如何才能顺利着陆呢？带着这个问号，可以展开一系列问题。比如：
+
+
+众所周知空降操作难度大，为什么还要空降？
+空降有风险，从公司、团队、自身的角度看，空降的价值在哪里？
+墨菲定律当头，降落过程可能遭遇哪些问题，最糟糕的情况会有多惨？
+工欲善其事必先利其器，需要提前做哪些准备？
+怎样判断自己是否适合空降？
+衡量成败标准是什么？有哪些前提条件？
+落地后要做哪些动作，遇到各种情况如何应对？
+作为空降的团队领导者，该让谁满意？
+
+
+我将这些问题总结成四条，接下来将寻根溯源抽丝剥茧，一条条进行分析，并分享自己的一点经验。
+
+第一道题：空降的目标是什么？
+
+如果不是非常必要，无论是公司还是个人，通常不会选择空降。评判空降成败的维度可以有很多方面，但空降目的一定很明确，那就是达成公司对这个职位的预期目标，在此基础之上，才能考虑个人的目标。因此，在空降之前弄清楚该公司为什么需要空降技术领导者是非常重要的。
+
+空降是自上而下的管理动作，决策者安排空降一定是有某些特定原因的。在某些组织里，为了避免结党营私形成地盘，会存在空降轮岗的普遍机制，但技术团队更关注技术本身，相对涉及利益较少，团队文化也简单，一般不会有太多这方面的顾虑。
+
+不过，技术团队通常会按照职能或者业务分成很多领域，专业性强，要做好必须精专，一样有隔行如隔山的情况。因此搭建健康的梯队，打造良性的内部晋升机制是技术团队最常态的补缺方式，这种机制也能够激励团队成员，使团队得以有序可持续发展。
+
+公司需要空降的技术团队领导者，一般出于以下几个原因，而且很可能是多方面综合的结果。
+
+1.团队内部没有可胜任的人才，或者提拔有比较大的风险
+
+如果团队相对稳定，合格的领导者会安排好自身职位的后备人员，就像美国副总统一样，避免领导者本人成为系统的单点风险。一旦有变动，最稳妥的做法就是内部提拔。然而技术团队中技术好手很多，有领导者潜质可以做好团队管理的人才难求，有时后备力量还不足以能够全面接盘团队当前工作，如果晋升之后掌控不好甚至可能给团队带来二次动荡，因此需要空降。从这点出发，对空降者的能力要求会大大高于后备者，否则也可能引发矛盾。
+
+2.公司内部没有合适的可调配资源
+
+如果是公司内部其他技术团队有适合的人才，他们对于公司及当前团队的情况都会比较熟悉，因此，内部调配也是一种会优先考虑的操作。但内部调配要看是否可行，如果该领导者自身没有好的后备者，或者对于团队非常重要，调不开，则不如从外部招聘人才，把这种资源空缺的问题，转嫁到行业其他公司，甚至是竞争对手，此消彼长，一举两得。
+
+3.组织结构调整或者他人兼任不是最佳选择
+
+有些公司会通过组织结构调整的方式，把团队拆分到其他团队，或者合并到另一个大团队中，“从根本上”消灭团队领导空缺的问题。但这种方式也需要避免引入新的问题。如康威定律所述，技术团队的组织结构是由业务形态决定的，自有其领域划分，强行拆分合并，反而会带来结构性的内部问题。还有一种方式是组织结构不变，由他人兼任，这个方式会更可行，但无论如何都要有能Hold住更大规模团队的人选才OK。
+
+4.团队问题需要外力解决，外来的和尚好念经
+
+每个团队、组织都有自身的问题，有时候内部进行变革，会有更多的阻力，以及局限。此时，引入外力，用新鲜血液带来更多不一样的思考和操作是一个不错的选择。毕竟外来的人员没有包袱，更有活力和魄力，也就是俗话说的，外来的和尚好念经。
+
+5.团队需要更强的领导者
+
+这是最常见的，也几乎是最主要的原因。技术团队对公司来说是非常宝贵的资产，用好了能创造远超预期的价值，用不好则是巨大浪费。因此团队领导者非常关键，要尽可能胜任，能够快速的融入团队，并带领团队有所产出。
+
+技术团队领导者时时刻刻都要挂在头顶的就是目标，到新的团队，这一点最最重要了。一定要搞清楚公司对自己的要求是什么，要解决什么问题还是搞定什么项目，有什么是必须拿下的，多长时间内要达成，团队对自己有什么期望等关键信息，越详细越清晰越好，如此才能心中有数。
+
+技术领导者选择空降，也一定是各方面综合考量之后做出的慎重选择。可能是职业发展天花板，也可能不满足于现状，想跳出舒适区，迎接新挑战，追求更高的成就，也可能是喜欢新公司的味道，跟上级、老板确认过了眼神，大家都找到了对的人。但无论如何都得要达成目标做出成绩，甚至超出预期。
+
+目标就在前方，有没有信心，有没有底气？迎接挑战的勇气通常来源于对自身能力和目标匹配度的准确认知。这其中有常量，但变量更多，比如各种问题和风险。
+
+第二道题：空降会面临什么问题和风险？
+
+空降有风险，跳槽需谨慎。既然要空降，就必须清楚空降的难点有哪些。简单来看，包括但不限于熟悉度、人员、公司、团队、目标、产出等诸多方面，可谓问题多多，困难重重。如果只看见表面的光鲜，风险意识不足，疏忽大意很可能开局不利马失前蹄。
+
+1.团队陌生，有距离，易产生隔阂
+
+不同于自己从0组建或者内部晋升所负责的团队，空降到一个团队，团队成员彼此之间都很熟、很有默契，带头大哥反而是个陌生人，太尴尬了！团队成立的时间越长，老成员越多，这种情况越明显。也就是说，团队的内部凝聚力越强，越有认同感，越难融入其中。
+
+2.可能遭遇抵触，发生排异反应
+
+新的领导者作为焦点人物，一举一动都会被关注，作为陌生人进入团队，所有人都会“听其言，观其行”审视你评判你，一旦表现不佳引起团队集体反感，后果很严重。每个人对新任领导的感受都是不同的，可能是上升空间被封闭，也可能跟前任感情太好，或者背景不同、认为你技术水平不够、管理不到位，甚至是单纯看你不顺眼，都会形成负面情绪。
+
+3.组织文化不熟悉
+
+不怕干不了，就怕不知道。每个组织的文化、运行机制都有各自的特点和合理性，而且多数的协调机制都不是白纸黑字明面上的，不知道可能就会闹出大笑话。跨不同行业、不同规模、不同领域的空降，更容易遇到此类问题，比如互联网和传统IT、创业公司和行业巨头、国企和外企。
+
+4.团队状态不佳
+
+有的团队正处在比较糟糕的状态，人心浮动，情绪敏感，士气低迷，甚至陷入了恶性循环，比如骨干流失，新人没人带感觉难以成长，工作效率非常低，系统经常故障，在公司内部的口碑很差。集体的惯性是很大的，破坏力也强，扭转颓势不易，但必须尽快发现问题根源，越快解决越好，至少不能持续恶化。
+
+5.时间窗口窄
+
+无论有怎样的问题，只要团队还在，就要有所产出。留给空降领导者的时间不会太多，短则三个月，长则半年，基本就是试用期的长度。另外，技术团队多数面向业务，工作状态、产出成果都要由业务方来评判，业务不满意，头一个要顶雷的就是团队领导。
+
+今天，我跟大家分享了空降可能会遇到的各种挑战与风险，可能会有泼冷水之嫌，但凡事未虑胜先虑败，提早考虑可能的风险，并采取相应的措施规避，总比空降之后以脸着地要好得多。
+
+明天，我将跟大家分享空降前的准备以及落地后的具体操作，欢迎继续关注。
+
+作者简介
+
+史海峰，贝壳金服 2B2C CTO，TGO鲲鹏会北京分会会员。负责总体架构规划、技术规范制定和技术预研推广，善于把握复杂业务需求，提出创新性解决方案，在项目中对系统架构进行持续改造优化。负责技术委员会组织管理工作，发掘最佳实践、推动技术革新，组织内外部技术交流。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/048空降领导者平稳落地要做的四道题（下）.md

@@ -0,0 +1,83 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            048 空降领导者平稳落地要做的四道题（下）
+                            你好，我是饿了么技术创新部高级总监史海峰。昨天，我跟大家分享了技术领导者空降会遇到的风险和挑战。今天，我将继续空降这个话题，跟大家聊聊空降技术领导者需要提前做的准备，以及如何平稳落地这两道题。
+
+空降能否成功，无论提前做了多少准备，实际跳下去的那一瞬间，仍然要面对巨大的不确定性。至于如何着陆，这是一个不断调整变化的过程，而且难以谋定后动，必须保持高度紧张，快速响应，确保不以脸着陆，给大家呈现空难现场，累及无辜。
+
+第三道题：要提前做哪些准备？
+
+凡事预则立不预则废。很多战争的结局，虽然看似是因为一些偶然因素，但其实真正起决定作用的都是必然因素。例如美国参战，二战的大局就定了，原子弹只是起到了催化的作用，促使日本投降。因此，既然要空降，就要做好充足准备，以便遇到问题时能从容应对，避免忙中出错。
+
+1.做好情报工作
+
+尽一切可能搜集团队情况，掌握团队职责、团队由来、核心成员、当前问题、leader为何空缺等信息。信息渠道包括且不限于面试考官、猎头、同行朋友、技术媒体、知乎、脉脉、内部员工。
+
+如果方便，不妨与原来的领导者直接沟通，他是最了解这个团队、这个职位的人。也可以要求与团队核心成员、同级的关键人物见面沟通，聊历史、现状、问题和未来，以便获得更多的感性认识，并对主要干系人的脾性有所掌握。
+
+另外，对于整个公司的发展史、创始人、CTO、技术优势、当前业务等方面的信息，也要尽可能了解，多多益善。
+
+2.定位优势，获得资源和支持
+
+结合目标，盘点自己的优势在哪方面，以及怎样才能获得支持，具体能够在哪些方面有帮助。优势可以体现在技术能力、行业视野、影响力、所拥有的资源等，比如要招聘补充团队骨干，行业资源丰富的话，可以提前进行盘点和沟通。
+
+另外，上级为了确保空降成功，一般会提供一定的支持，“扶上马送一程”，比如内部培训、招聘名额、预算费用、临时抽调人力等资源，甚至包括直接参与的推动和协调。
+
+3.做预案
+
+未虑胜先虑败，明确了目标，对于可能面对的风险和问题，要做好充分的心理准备以及行动计划，也可以与有相关经验的同行多多交流经验。
+
+另外，如果软着陆失败，就得硬着陆，永远要有Plan B。墨菲定律，怕什么来什么，躲是躲不过的，比如团队短时间离职超过1/3，就得知道得怎么才能快速招到人，甚至拉一个团队过来都可以；比如有人带头对抗，就得狠下心快速剥离不能称职工作的刺头；比如关键技术问题解决不了，就得知道如何快速找到合适的外援。
+
+第四道题：落地时要做哪些动作？
+
+做好了准备，调整好了心态，接下来就到了实施空降行动的时刻。开弓没有回头箭，从跳出舱门这一刻起，前面的所有铺垫都得化为一连串高难度动作，在有限的时间内不断调整姿态，以期平稳落地。
+
+1.开场
+
+新官上任怎么办？一般会由上级、HR或者原领导负责引荐给团队，先是核心成员见面，然后是全体会，登台亮相发表“就职演说”，这时一般要介绍自己的背景和成长经历，阐述自己对团队的定位、设立未来目标，并强调自己的工作风格，比如肯定团队成绩、会关注哪些项目、争取哪些资源、多长时间内认识每一个团队成员、欢迎随时沟通等等。
+
+开场第一印象非常重要，衣着、谈吐要得体、有亲和力，最后要有互动，这个环节非常考验应对能力。
+
+2.观察
+
+走马上任之后不必着急三把火，先多观察，参加各种会，多看各种文档，摸清楚公司的技术体系、系统架构、项目和团队管理流程，以及公司整体的组织结构和运转机制等。另外，对于业务型技术团队，新任领导者务必在第一时间拜访业务伙伴，建立联系，了解他们的痛点和期望。
+
+在观察期内发起团建活动更有利于熟悉团队文化、融入团队，要多做正式和非正式的沟通，补充核实之前的情报，也增加团队成员对你的感性认识，找到认同你的支持者。比如我很少喝咖啡，但换了新工作后，为了方便沟通，一年喝的咖啡超过了前半辈子的总和，和团队的骨干、平级的团队负责人都进行过沟通。
+
+观察是为了确认团队情况是否与预期相符，深入其中，之前的所有信息才会变成真切的现实场景，而且不同来源的信息可能大相径庭，不同人的思维和看法也可能各有千秋，需要分析判断，不断完善自己的认知。
+
+3.上手
+
+掌握了具体情况之后，要结合实际情况调整预案，然后逐步落地，制定技术路线、优化流程、立规矩、做奖惩、建立领导权威。
+
+需要注意的是，初期发起任何调整前都要做好充分沟通，保证信息公开透明，尽可能传达到所有的团队成员而不失真，以便获得他们的理解和支持，调动起他们积极性，确保方案得到切实执行。
+
+这其中，明确关注点和量化底线很重要，比如出现线上故障、紧急部署、项目延期必须第一时间上报，比如周报务必准时提交，比如重要会议迟到罚款等。通过这些方法，在预定周期内拿出成果，才算走稳了第一步，才能获得公司的初步信任。
+
+一般而言，空降领导者要首先确保团队稳定，一旦出现动荡，就会大伤元气。当然，如果为了达成目标，需要大刀阔斧，也不能犹豫，畏手畏脚。如果团队缺乏骨干，就拉知根知底信得过的得力帮手进场，能快速撑起大局。如果人员与分工不匹配，就调整组织结构，不必顾忌因人设岗，合理配置能减少错位和内耗。过程重要，结果更重要。
+
+4.原则
+
+有一个原则是空降领导者一定要遵守的，那就是空降之后你就是团队的一员，要为公司、为团队负责，一切行动都应该把公司和团队放在前面，而不是考虑自身利益。坚决不能把自己当外人，你把自己当外人，就会真的成为局外人。另外，空降领导者自己表现得再好，团队不行，就是失败，反之，团队取得成果也就是你取得成果，这点也是要注意的。
+
+在一个已经形成文化的公司，要做的是适应既有文化，抓住重点，掌握团队话语体系并融入自身工作。作为团队领导者，应该更专业，更有大局观，更有管理套路，更符合公司对领导者的要求。
+
+每个人都是空降兵
+
+刘猛在小说《最后一颗子弹留给我》中，对空降兵有句概括度极高的名言——“空降兵天生就是被包围的”，后来这句话随着小说改编的电视剧《我是特种兵》热映而成为经典台词。
+
+没错，空降兵要定点空投、深入敌后，在险境中站稳脚跟、打开局面、完成任务。生活之中，谁又不是空降兵呢？从呱呱坠地降落人世，到离家求学，到毕业后进入职场步入社会，到组建家庭，职业调整，甚至是退休养老，都在不停地适应新环境。
+
+适者生存，是人生常态，每个人都是空降兵，要一次次的投入陌生的环境，能做的就是成为战场主宰，掌控自身命运，决定战局成败。
+
+作者简介
+
+史海峰，贝壳金服 2B2C CTO，TGO鲲鹏会北京分会会员。负责总体架构规划、技术规范制定和技术预研推广，善于把握复杂业务需求，提出创新性解决方案，在项目中对系统架构进行持续改造优化。负责技术委员会组织管理工作，发掘最佳实践、推动技术革新，组织内外部技术交流。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/049打造高效的研发组织架构：高效研发流程那些事（一）.md

@@ -0,0 +1,105 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            049 打造高效的研发组织架构：高效研发流程那些事（一）
+                            你好，我是箴亚管理顾问公司负责人，同时也是TGO鲲鹏会台北分会学习委员游舒帆，今天想跟大家分享的话题是“高效研发流程的第一步，打造高效的研发组织架构”。
+
+要谈高效研发流程这回事，首先我想先跟大家聊聊高效这词，我对高效的定义是：更快的将事情做对、做好。也就是说产出要快，内容要对，而且质量要好，又快、又好、又有价值才符合我对高效的期待。
+
+“快”，在互联网时代，通常强调的是应变得快、调整得快，这与组织架构、分工，以及决策过程有关。“好”，就是交付的质量，说得出做得到，总是能交付出可预期的成果，这与软件工程的成熟度有关。“有价值”，则是源自于方向与优先级正确，这与企业战略与目标设定有关。
+
+因此，谈高效研发流程，我们便不能只谈研发流程本身，必须将视野拉到外部环境、企业战略与组织架构等层面来思考。
+
+两种最高效的场景
+
+在我过去接触过的千千百百种流程里，其中有两类场景是最高效的：
+
+第一类，制造业的生产线。 每个关卡、每个环节都被精密计算，关卡与关卡间毋须沟通，也甚少出现停顿等待前一个关卡的状况。各关卡只需要负责完成它所负责的那项任务，内容的变化性极少，突发状况也几乎都被控制，成果的可预测性极高，可以大规模、重复的产出相同的成品。
+
+第二类，全栈型员工。 毋须分工，毋须沟通，可以自己一个人从厘清需求、设计架构，到编写前后端代码，同时搞定测试与布署等所有事情。少了沟通这个环节，他不用分心向其他人说明自己的想法，不会有冲突，也不用相依于其他人的工作，这种状况下，工作能不高效吗？
+
+然而，这两种场景都有很大的局限性，第一类场景无法很有效的应对高变化性的环境与需求，即便在如今智能制造的环境下，多样少量的按需生产仍有极高的局限性，想当然也很难适用于现今多变的软件与互联网环境。
+
+第二类场景的局限性则在以下两点：第一，生产力有限，面对较大规模的工作量时，团队分工显然会更高效；第二，专业性问题，全栈型员工并不意味着所有的技能点都点满。
+
+从上述两种极端的案例中，我们可以先了解到一个最基本的观念，那就是“流程高效的前提是对应了适当的场景，而场景，则源自于我们所面对的挑战以及所发展出来的战略与组织架构”，这与我们开头提到的又好又快相互呼应。
+
+四种企业组织架构
+
+前面一段我们提到了两类高效的场景，第一类是高度确定性场景，第二类则是高度不确定性场景。这个部分我将跟大家简单分享一下我经历过的几种主要的场景，以及对应的战略与组织架构。
+
+大家可以先透过以下这张汇整表对这几类组织结构有个基本认识：
+
+
+
+1.功能型
+
+讲究专业分工，基本上制造业或传统产业，大多仍沿用这种组织架构，因其所面对的环境变化性小，流程与技术的变化性也相对较小，在稳定状况下，明确的分工有助于效率的提升。
+
+2.产品型
+
+又称BU(Business Unit)型，通常是为了快速抢占市场而组成的团队。功能型组织分工明确，但容易形成谷仓效应，彼此各自为政，不利于战略的快速推进。如果企业资金充裕，且追求快速推进，一般会让各产品线或BU自建销售、营销、服务等相关功能部门，并且各自进行管理，所有功能的主管权集于一人身上，决策相对高效。当然了，对应的或许是资源的重复投入问题。
+
+3.混合型
+
+一家经营5年以上的企业，一般会具有多个产品或事业。某个产品A已经相对成熟，对变化的可预期性提高，此时可能会从产品型组织转换成功能型组织；而另外有个产品B则尚在起步阶段，仍须快速推进，产品型组织就相对适合。这种状况下便会出现功能型与产品型组织并存在企业内的状况，就我过去的经验，大多数的大型企业最终都会走向这种型态。
+
+4.战斗小组
+
+当你面对极端不确定的环境，例如全新市场、新科技早期的技术探索等，组织过大的产品型团队一来成本高，二来效率也会受到限制。此时，最佳的解法通常是派出2-3人组成战斗小组，在这个团队中所有人都是多能工，每个人都能同时处理多个职能的工作，如同初创团队一般，小而全的高效运作。
+
+以创业团队来说，刚起步时大多都是创始团队组成战斗小组，随着市场需求的厘清与扩张，会逐渐转为产品型，然后随着分工愈来愈清晰，制度愈来愈完善，会步入功能型，等开始切入第二个产品或事业时，就会变成混合型组织。
+
+企业组织架构与研发组织架构如何高效匹配
+
+前一段我们谈到了企业组织架构，这个段落我将分享研发组织架构如何与企业组织架构高效匹配。
+
+企业在草创初期，走的大多是战斗小组模式，研发在此时还没有形成一个独立编制。但随着企业日渐成长，公司规模成长到百人规模，业务、营销、服务都成立了独立部门，研发团队也来到20-30人的规模，为了有效的管理与确保研发资源的最有效运用，研发通常也会被独立成一个部门，而企业内，也会自然的走向单一产品型或功能型组织。
+
+1.集中式的研发团队
+
+习惯上我会称这个阶段为集中式的研发团队，这一时期基本的运作模式如下图，各部门对研发部门提出需求，研发部门则依循一套机制来排序所有部门的需求，并且按照谈定的顺序进行开发工作。
+
+
+
+然而，企业在此时仍在追求快速成长，因此销售与营销的需求往往会优先被考虑，而服务与后勤的需求，以及研发团队针对产品或技术架构优化的需求，则往往被滞后。需求顺序会偏重支持短期的营收增长，而客户服务与产品优化等长期项目则严重被忽略。
+
+2.分布式的研发团队
+
+有鉴于集中式研发团队的问题，许多企业会在此时选择扩张或重整研发团队，将一部分的研发资源放在处理各功能部门的短期性需求上，我习惯称这样的团队为功能部门研发团队；另一部分研发资源则专注于产品与技术的持续进步上，这个团队我则习惯维持研发团队这个称呼。
+
+
+
+经过调整后，各功能部门都将拥有一个属于自己的小规模研发团队，所有的需求都可以先提交给这个团队。若需求本身较紧急，且规模较小、复杂度较低，那就由这个团队直接处理，若判断后认定为长期需求，则将需求pass给研发团队来评估与开发。
+
+这样的组织架构，虽然可以同时兼顾长期与短期的需求，但那些被分配在功能部门的研发成员们则难免会有所怨言，会认为自己所做的事没有太高的技术含量，更多的是例行庶务与简单的编程工作，时间久了便会失去工作热情。我们曾经尝试过轮岗，让成员能在各团队间轮替，但在几次实践之后，发现这样的做法成效并不好。
+
+因为所有人都倾向于做那些看起来价值更高的事，如果技术领导者在做组织分工时，已经先排出团队价值的高低，那被分派到低价值团队的成员，自然会觉得自己的工作价值不高，会觉得自己不被重视，团队的向心力、热情与使命感都会大幅降低。
+
+为了有效的解决这个问题，我们又尝试了第三种组织架构——矩阵式研发团队。
+
+3.矩阵式研发团队
+
+矩阵式组织架构最主要的特色在于，重新定义了之前提到的功能部门研发团队的角色。过去，我们指派给这个团队的任务是支持功能部门排除问题与开发短期需求，现在，我们则把各个功能部门定义成一个个独立的产品，每个产品都有单独的产品经理负责，而这个产品经理的核心任务就与各功能部门的产出直接挂钩。
+
+例如，销售系统被定义成一个独立的产品，它拥有自己的销售PM，目标就是让销售部门达成所有KPI，可能是业绩、退货率、客单价提升等。
+
+当角色从消极的支持转为积极的负责后，团队的定位就更加清晰且重要了。
+
+
+
+此外，推动矩阵式组织的另一个观点是，产品经理可以通过改善产品，或通过运营的手法来促使业绩达成比如30%的增长，然而产品经理始终是产品专长，对于销售、营销、服务的理解并不见得非常深入，因此，如果能在销售、营销、服务等岗位上也设立产品经理的职务，肯定能对增长带来重大效益。
+
+举例来说，如果销售PM能通过技术带来30%的销售效率提升，就能一次性让多个产品同时受惠；如果服务PM能通过技术更个性化的服务顾客，有效的降低了比如15%的退换货，也有机会让数个产品都得到提升。过去经验里，这些PM本身都熟稔技术与业务知识，能同时从两方思考系统问题，所提出的解决方案往往会比纯技术PM或纯业务PM来得更加到位。
+
+从这个角度来思考，功能部门研发团队的重要性便明显提高了，他们能直接为公司的效益带来贡献，团队成员们有了相对清晰的目标，使命感与热情便有了非常明显的提升。
+
+本文跟大家讨论了较多关于场景与组织架构的内容，往下几篇，我将分别与各位聊聊关于研发流程管理的选型、研发管理过程中的那些坑，以及如何打造追求更快、更好、更有价值的组织文化与人才梯队。
+
+很高兴能与大家交流关于高效研发流程这个话题，咱们明天见。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/050你的研发流程符合你的组织架构吗？谈高效研发流程那些事（二）.md

@@ -0,0 +1,87 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            050 你的研发流程符合你的组织架构吗？谈高效研发流程那些事（二）
+                            你好，我是箴亚管理顾问公司负责人，同时也是TGO鲲鹏会台北分会学习委员游舒帆，今天想跟大家分享的话题是“高效研发流程的第二步，研发管理流程的选型”。在上一篇文章中我与大家分享了组织架构与打造高效研发流程间的关联，本文将着重于研发过程的探讨。
+
+刚出社会时，我在一家ERP软件公司从事研发工作，我在那里接触到了非常正规的软件工程，也见识到当研发流程与业务特性匹配时的高效，以及不匹配时产生的诸多问题。在2000年初期，软件开发大多仍遵循瀑布式(Waterfall)方法，必然得先进行需求收集、分析、设计，然后进入开发与测试，经过一道道程序后将成品完整的交付。
+
+在ERP软件公司的那些年，我也参与了软件成熟度模型CMMI Lv4的导入与认证，过程中，我见识到了CMMI的严谨之处，同时也体会到严谨背后带来的低效与冗余。由于当时我所负责的产品处于需求不明确、市场性待验证的状态，如果要依照CMMI的规则产出完整的需求列表与完整的分析文件，估计是不可能的。
+
+因此在过程中我试着提出用假设性需求，以及用雏型替代成品的方法来进行市场验证。出乎意料的是，这个提议获得了CMMI顾问团队的认同，而这也是我对CMMI有所改观的转折点。公司内推动小组的负责人告诉我：“CMMI本来就是一个模型，每家公司得依照自己最适合的方式建构流程，但最终须能达到CMMI要求的水平。”
+
+2011年，我开始负责SaaS相关业务，也首次接触了敏捷观念以及Scrum，与此同时，互联网开始进入火爆增长期，所有的企业都在求新求快，技术团队也被要求要具备更灵活、更弹性、更迅速的特性，只是一两年时光，国内所有公司都在讨论敏捷开发，而不再有人讨论PMP和CMMI所主张的瀑布式项目管理与研发流程管理方法。
+
+2013年，我开始在团队中大量引用敏捷观念，通过频繁的交付来验证用户与市场需求，也在技术社区中与许多朋友交流项目管理与软件开发方法，我看见越来越多的人想拥抱敏捷，但同时我也发现，许多人对敏捷其实一知半解，并且对PMP及CMMI有着错误的偏见。
+
+2015年，我进入互联网公司后，人人口中所谈的都是敏捷，万一在讨论过程中有人提到CMMI或PMP，就会有人露出鄙视的眼神，他们误以为过去项目做不好，是PMP与CMMI所造成的，却未曾思考过，或许项目失败的真正原因不在流程与工具，而是运用的那些人。
+
+关于瀑布式或敏捷开发方法的选择
+
+在前一篇文章中，我提到当企业内外部状况稳定，需求的变化性较少，可预测性高时，功能型组织是相对适合的组织架构，而相同的概念，其实也适用于传统的PMP管理方法。PMP强调程序、输入(input)、输出(output)与权责，这与功能型组织不谋而合；相较之下，敏捷强调的快速响应、迭代，则与产品型组织或战斗小组更加匹配。
+
+当一家公司内可能存在多种组织架构时，是否也意味着应该存在多种开发流程呢？我的答案是”肯定的”，当我们过度坚持公司内只能有少数一两套程序，硬要逼所有人配合时，其实已经与敏捷所追求的“专注于更快的创造价值，持续精进”的理念背道而驰了。
+
+最近几年，我一直在同时并行管理多种组织与开发流程，接下来将跟大家分享在不同的场景下我是如何选择的：
+
+1.需求具备高度不确定性，重要性高，但时程紧迫度一般
+
+例如新商业模式的探索、从2B跨入2C的新产品等，这样的任务我一般会以战斗小组的形式组成团队，团队成员会根据当下需求随时做调整，可能是1位产品经理配2位研发工程师，也可能是3位具备分析能力的资深工程师。
+
+这样的团队基本上不会有太明确的分工与流程来局限他们，团队可以选择自己熟练的工具，协议合适的分工，唯一的目标就是把问题给解决掉。
+
+2.需求有一定不确定性，且时程紧迫
+
+例如要赶及在某一天推出新产品或新feature，藉此创造市场话题。这样的任务一般我会交由产品型组织来完成，而为了持续降低不确定性，他们需要频繁的交付成果以验证市场反应，以期在deadline之前把产品交付出来。在我过去几年实施敏捷的经验里，这一类的项目约占总项目的7成左右。
+
+在这类项目中，为了同时兼顾效率与质量，团队基本上会依循一定的程序进行项目目标定义、需求厘清、开发、测试与布署，而在分工上，一个人可能会同时兼任多种角色，例如资深工程师除了要写代码外，也要负责架构设计与需求厘清，而产品经理可能同时兼任项目经理与原型设计。
+
+复杂度较高的项目，可能设有独立的项目经理，否则多数状况下产品经理必须兼任项目经理角色，他们必须对项目负责；而架构师与用户体验设计师则不见得会参与每个项目，除非项目涉及较大的架构变迁或选型，以及明显的用户体验缺陷或改进。
+
+分工的方式会根据不同的项目而有所不同，唯一的原则就是，分工必须是必要的，如果只是在工作流程上卡一关，但没有对项目带来实质效益，那分工便非必要。
+
+3.需求具有高度确定性
+
+例如与战略伙伴合作的项目，彼此已经先把所有需求厘清，并且敲定了验收时间。这样的项目一般我会另外组织项目团队，按瀑布式开发流程推进，并切出几个重要的里程碑进行阶段性验收。
+
+如果敏捷是藉由更快且更频繁的交付，以期降低不确定性并更快的创造价值，那么在目前的项目中，需求基本上已经非常明确，时程也按着彼此协议好的时间进行，中间其实不存在太多需要通过迭代来验证的内容。唯一需要的是按表操课、如期如质的将成果交付出来。
+
+独立的团队，明确的计划、分工与权责，加上里程碑查核，这类案子的稳定度是最高的。所以时至今日，多数的外包项目，都还是依循着这种程序，否则将在报价、管理与验收上产生诸多困难。
+
+上述内容汇整后，可以用下面这张图做个概括性的理解，根据目标与需求的不确定性的高低，所采取的项目管理方法、团队组织与分工方式也不同。
+
+
+
+追求敏捷，但更要重视项目管理基本功
+
+在领导团队时，我特别强调项目管理的基本功，因为我认为多数的问题都是出在基本功不够扎实。在项目开始前与进行中，一般我会对产品经理提出很多问题，以确保项目能如原先预期推进。
+
+在项目启动阶段，一般会由团队就已知信息先拟定draft plan，其内容主要是陈述项目要做哪些事？打算如何进行？由谁来做？预计花费多少时间？以及将得到什么样的结果？
+
+而当团队将计划产出后，我会问产品经理：“这个项目中有哪些不确定性，可能会导致你无法准时交付？”项目管理早期的主要问题大多是“需求不够清晰”、“不确定人力资源能否配合”、“对工作的估时过长或过短”、“技术可行性待验证”、“老板可能还会改动需求”等等，而这些，就是导致项目进行阶段会频繁发生变更(change)的原因。
+
+相对的，如果你在规划时期，就已经先把这些问题排除了，那运行时会面临的变更就相对减少了，案子的进行也会相对轻松许多。
+
+
+
+这些对我来说都是项目管理的基本功，敏捷虽然强调拥抱不确定性，并欢迎随时的更动，但不意味着我们要对那些不确定性置之不理，而是要尽快的让不确定成为确定。 敏捷强调不断进步与反馈，我们必须通过一个又一个项目的磨练，让自己能把需求看得更清楚，对时程估算得更准确，能更有效的对齐老板的期待，而要做到这些，团队就需要逼着自己不断进步。
+
+若你对Scrum架构有所研究，你便会发现best practice里头强调的架构，其实正是针对上述几个最常见的项目不确定性而来的。例如，针对时程，Scrum强调固定的交付周期，以1-4周为佳，而且强调是固定团队，在过程中也尽可能避免团队成员同时参与多个项目，在这个基础上，再来讨论这样的团队，在一个迭代时间内可以完成多少工作。
+
+Scrum给出了一些框架与规范，确实有助于提升团队的项目管理水平，如果团队原本的项目管理能力只有60分，或许导入Scrum后能提升到80分，但如果要做到90分，团队还是要根据所遭遇到的问题进行持续不断的改善。
+
+进步，是永远不变的追求
+
+曾有一个team leader在一次会议后问我：“老大，不断打破与调整流程，让大家忙得要命，背后追求的到底是什么？”
+
+我说：“进步。忙是一时的，但你想想一年前我们做一样的事情花多少时间，现在又花多少时间？针对一个异常，过去我们是发生后才知道，现在我们已经可以弭平于未发之时。从前我们没日没夜的工作，换来的却是很多谩骂，但现在我们花更少的时间，却换回更多的掌声，因为我们持续在进步。”
+
+如果需求管理不当、时程估算误差过大、未以正确的态度面对不确定性、项目过程控管差劲，却总是靠着团队加班来填补落差，团队可以靠着热情撑过一小段时间，但随着时间延长，团队总是会乏力，身为技术领袖应该要以持续进步为己任，而不该沾沾自喜于团队的超时工作。
+
+记得，永远都要追求更快、更好、更有价值，别用战术上的勤奋，来掩饰战略上的怠惰。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/051聊聊研发流程管理中的那些坑：高效研发流程那些事（三）.md

@@ -0,0 +1,89 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            051 聊聊研发流程管理中的那些坑：高效研发流程那些事（三）
+                            你好，我是箴亚管理顾问公司负责人，同时也是TGO鲲鹏会台北分会学习委员游舒帆，今天想跟大家分享的话题是“高效研发流程的第三步，研发流程管理中最困难的那些事”。
+
+前两篇文章中我与大家分享了组织架构与研发流程的选型，这两者都是高效流程的基础，可以让团队做好事(Do thing right)，但却不见得能做对事(Do right thing)。
+
+我曾在台湾敏捷峰会上分享过一句话，在这里也分享给大家：“如果敏捷走不出技术团队，就不可能真正敏捷”，一样的观念“研发流程如果只着眼于研发工作本身，就不可能真正高效”。因为研发团队不是独立存在的，其本身的工作与外部具有一定的相依性，例如需求、营销、运营、服务等，如果我们不能有效的管理这些事，只会事倍功半。
+
+本文我将会着重就研发管理过程中最困难的几件事：需求管理、优先级、迭代与交付方式、跨部门沟通与数据驱动等主题与各位分享我的经验与看法。
+
+1.需求管理
+
+所谓的需求管理，并不是单指整理出需求列表，而是需要对这些需求做有效的管理，让团队能满足老板与客户的期待，所以我也常说需求管理本质上其实是期待管理。
+
+在谈期待管理时，我常常用这张图来跟团队沟通：
+
+
+
+我总是问团队：“你们清楚老板想解决什么问题吗？”因为很多时候，项目团队往往只看到有件事得做，而时程已经被压上去了，所以匆匆忙忙的开始项目工作，但却很少花时间去理解这个项目背后的为什么。一年下来，做的项目也不少，但却没有几个项目真正解决问题。
+
+如此，老板的需求没有真正被满足，对团队的信任感自然也不会太高，而这样的企业，一般效率也不会太高。
+
+如果公司的组织架构是属于多阶层式的科层组织，那这个问题会放的更大，老板可能只是想解决一个很简单的问题，但经过层层解读与转达后，最后收到的需求是要做一整套系统。导致原先只要一两周时间就能解决的问题，却往往得拖上半年一年之久。
+
+要真正做好期待管理，团队必须在承接每个项目时，都往上层去了解源头的问题，这就是所谓的上游信息。当团队能真正理解老板与客户的真实期待，并逐一解决时，需求管理这件事才可能真正做好。
+
+2.排定优先级
+
+排优先级，一直都是件难事，我们如果想在相同的时间内创造出更多的价值，那决定先做什么，不做什么就成了关键点，所以优先级的规则至关重要。过去我们曾经采取过几种排定优先级的方式：
+
+第一种，权力决，通俗一点来说，就是由权力大的人来决定，排第一的通常是老板或业务部门最高主管。权力决有另一种变形，那就是让承担该业务的主要负责人来做决定，例如产品经理决定产品优先级，业务主管决定业务需求优先级。权力决的好处是决策者明确，然而缺点是官大不一定学问大，有权力的人，对现场的把握度可能反而是最差的。
+
+第二种，共识决，由大家共同决定项目的优先级，严谨一点的甚至会成立一个委员会来定期处理此事，然而就过去经验，如果没有适当的机制来维持客观性，共识决与认可决的背后其实仍是权力决。
+
+第三种，数据决，由大家共同协议一个项目价值的运算公式，例如能带来多少业绩、改善多少服务满意度、提升多少用户增长或留存率、降低多少人事成本等。每个项目都会被算出一个权重，然后依此权重值进行所有项目的排序。这个做法的好处是客观，所有参数都是经过讨论后得到的共识，缺点则是对项目价值的计算不会一开始就很精准，必须经过一次又一次的修正后才会越来越准。
+
+过去这些年来，一般种况下我是倾向使用数据决，如果过程遭遇争议，便辅以权力决或共识决。
+
+3.迭代与交付方式
+
+如本文开头所述，如果研发团队能将视线从团队内移往团队外，并面对真正的问题，那我们应该会把重点放在快速迭代，创造价值，而不该单单着眼于开发迭代，这句话的意思是“解决问题，不必总是仰赖技术”。
+
+专业人士因为拥有一身绝活，所以思考问题时总想着运用专业来解决问题，技术人在面对问题时也时常会想用技术来解决，然而有许多事情其实可以靠流程解、人工解、沟通解，不见得总是得仰赖技术。过去在带领团队时，我给了团队绕路解、临时解、根本解几个规则，让他们在规划与思考时能有依归。
+
+问题发生的当下，依循处理问题的三段式方法，一定要先能提供一个绕路解，也就是workaround，但身为研发人员，我们都很清楚workaround不代表问题被解决，如果不根本解决问题就会累积技术债。所以我们还是要从根本来解决此问题，但如果根本解的时间太长，用户无法忍受，你就要提供一个临时解来缓和用户的痛苦，不能根除也要先能止痛。
+
+这样的做法，基本上能同时考虑到技术与运营两方，在内部讨论时很容易取得共识。
+
+而面对需求，我们也强调三段式方法，如果有个需求可以每月创造2亿的营收，但完整做完需要花4个月的时间，我们会将这个需求细拆，找出其中相对有价值的部分先做，可能只花1周的时间，就能达到20%效益；紧接着在4周内再推出第二个版本，这个版本已经能创造60%效益；最后再推出根本解，实现完整的需求。
+
+当我们着眼于更快的创造价值时，迭代的方式与周期便可能有多种方法，而三段式方法是我们过去用过的，效率非常好的一种方法。
+
+“解决问题，不必总是仰赖技术”这个观念我们也在持续推广到研发部门外，让大家了解不是凡事都得靠系统，如果时间真的急迫，但研发部门暂时排不出资源，我们也会从专业角度提出其他建议方案。
+
+过去产品团队曾提出一个很棒的产品点子，在早期规划时产品经理与设计团队对于功能产生诸多歧异，并且技术团队做了初步评估，认为要完成这个功能最少需要四个月的时间，我们就这样僵持在会议室内。
+
+此时有位同仁提出了一个很好的建议。他说可以找客服部门合作，请他们找40位客户，并告诉客户我们将提供一项新服务，邀请他们抢先体验。而初期，便由客服部门同仁通过人工来服务客户。
+
+我当下觉得这个建议可行，便去找客服主管讨论此事，她听完后觉得很不错，虽然会增加一部份工作量，但能协助产品部门更快的把好的产品功能产出，这些投入非常值得。
+
+人工处理的好处是调整效率高，早上客户反映有状况的地方，下午就可以修正，这种效率是技术做不到的。这个人工服务的时间大概维持了一个半月左右，过程中流程调整了多次，服务内容也修正了好几次。我们可以思考，如果是交由系统来迭代，我们需要花多少时间才能迭代出这个结果呢？
+
+不过，虽然人工迭代的效率高，但人工毕竟无法处理大批量的工作，这部分还是要交由系统去处理，然而有效结合人工与系统，将可能创造最高的迭代效率。
+
+4.跨部门沟通
+
+在我过去经验中，技术主管最常求助于我的问题有二：第一个是向上管理问题，不知道如何有效的跟老板沟通；第二个则是横向的跨部门沟通问题，彼此之间KPI不同，目标不同，讨论时常谈不到一个点上。
+
+其实上述两个问题的解决方法是一样的，都是要掌握上游信息，解决上游问题，我说服团队成员学习向上管理，运用的是本文前头提到的，不断去追问 “为什么” ，只有掌握了为什么，才能知道自己做的事情到底对不对。
+
+而我用来说服团队做好横向沟通则会辅以一个故事：“如果今天你住在河川下游，河川的上游住了另外一群人，上游这群人每天都会在河里倾倒垃圾，所以位居下游的你，要不没有干净的水好用，要不就要喝脏水，此时你会怎么做？”
+
+“我会搬到他的上游去。”“那他也会继续搬到你上游，互相伤害。”
+“我到上游去将河道分成两条路线。”“好方法，但工程浩大。”
+“我会去劝导他们不要这样。”“一开始有用，两天后可能又故态萌发了。”
+
+通常经过一轮讨论后，大多会得出这个答案：“我去帮他们建立垃圾处理机制”。不管我提问的对象是什么背景，这个简单的答案通常都不会在一开始就出现，原因很简单——我们都认为那是对方的责任。所以我们会直觉的绕开对方的责任圈，我们只在圈外打转，顶多作柔性劝导，而不愿直接有效的帮对方解决问题。
+
+我常灌输大家一个观念，如果我们的上游出问题，不论他是没能力、没资源或是不愿意解决，问题就是在那，如果不帮他解决，我自己就得蒙受其害。这种情况下，那件事不再是别人的事，而是我们的事。当所有部门都理解了这个观念，都能协助上游解决问题，并给下游干净的水源，那跨部门沟通便不再是问题了。
+
+当决策、运营与开发都在正确的组织架构、流程上，而上下、横向之间的沟通都没有阻碍时，研发流程才真正实现了高效。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/052数据如何驱动研发高效运转？谈高效研发流程那些事（四）.md

@@ -0,0 +1,78 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            052 数据如何驱动研发高效运转？谈高效研发流程那些事（四）
+                            你好，我是箴亚管理顾问公司负责人，同时也是TGO鲲鹏会台北分会学习委员游舒帆，今天想跟大家分享的话题是“高效研发流程的第四步，数据如何驱动研发高效运转”。
+
+在前一篇文章时，我曾提到数据决，因为我认为数据是支撑决策的关键要素之一。当我们作决定时，通常会希望有些数据来协助判断，例如用户增长衰退，我们通常会想了解是哪些渠道没有达到原先预定的目标；找出渠道后，我们会想进一步了解原因是转化率下降，还是流量下降了，并一步步找出源头问题。这一决策过程中数据的重要性不言而喻。
+
+我记得在一次业务会议中，当月业绩落后了20%，业务部门主管汇报业绩落后原因时直接挑明了说“业绩落后的原因是因为产品出了问题”，我连忙追问：“请问影响了多少个百分比？”对方回答我：“总之很多，好几位业务主管都跟我抱怨这件事。”我又问：“请问是哪几位业务主管？”对方一时答不上来，只含糊地说了句：“总之是产品的问题。”
+
+幸好一直以来我都有收集跟解读数据的习惯，我当下回复：“我可以告诉大家影响的比例有多少，大概是2%，共有8位客户受到影响，而剩下的18%我也可以给大家解释问题的地方大概在哪里。”
+
+这个状况在一定规模的公司里很常见，技术或产品部门背黑锅事小，决策错误所衍生的问题事大，因此，如果我们要持续做对事情，就要有能力掌握更充足的信息与数据来支撑我们作决策。
+
+为了让数据更高效的助力经营决策，我曾提出企业应该具备数据策略，所谓的数据策略，顾名思义就是企业如何采集、储存、管理、使用数据，并对企业整体带来帮助。而在这个前提下，我们可以说数据策略是衍生自企业策略，而且数据策略与企业策略间的关系越来越紧密，企业不该只盯着落后指针看，而是要从数据中挖掘出洞见，并采取行动。
+
+而为了让数据能真正发挥效用与价值，我也根据过去经验，整理出了数据策略落地的五个步骤，下面详细跟大家分享。
+
+首先，所有的数据策略，都需要从企业整体策略出发，举例来说，如果今天营销部门的年度策略中有一项是“落实精准营销”，目标是藉此“提高客户年消费金额(从5,000元–>5,500元)与成交率(从3%–>4.5%)”，而在这样的策略之下，营销部门认为进行交叉销售、做个性化商品推荐有助于达成这个目标，所以他们对研发与数据团队提出了相应需求。
+
+Step1. 依据策略提出数据需求
+
+当我们厘清了营销部门的需求后，我们通常会提出一个问题：“你要数据帮上忙的地方是什么？你要数据回答你什么问题？”
+
+这个问题你必然得回答，基本上数据能协助你解答你有疑问但还不知道答案的问题，但如果你连自己的疑问是什么都讲不清楚，那数据通常就无法帮上忙。
+
+过去我在BI年代，总有人期待BI的dashboard可以直接告诉他经营上所有的问题，然而现实是“BI只能让你更清楚全貌”。到了大数据与AI的年代，仍有不少人抱有这样的想象，我总会告诉大家“如果有了大数据技术就能搞定经营的大小事，那你还犹豫什么？花钱买解决方案就对了”，然而事实并非如此。
+
+如果你要开始做数据化管理，首先要思考的问题就是，你要数据回答你什么问题？
+
+在之前提到的这个营销案例中，我们能得到以下答案：
+
+
+我想知道A/B商品、A/C商品或A/B/C商品同时在一张订单的状况，这有助于我进行交叉销售。
+针对25-45岁白领女性，找出其中买A品牌的口红比例显著高于买B、C品牌的群体，我想要知道特定族群对品牌的偏好性，这有助于我推荐合适的商品给客人。
+
+
+Step2. 确认数据处理目标
+
+有了清晰的数据需求，数据团队就能从这样的需求去讨论他们要对数据做什么样的处理，才能得到所需的信息，可能是分析、汇总、统计等等，而处理完后的预计产出物我称之为数据目标。
+
+因此，在之前的案例中，“想知道A/B商品、A/C商品或A/B/C商品同时在一张订单的状况”这一需求的数据目标是：
+
+
+找出所有的畅销品清单，根据过去公司对畅销品的定义，就是销售数量>50,000件的那些商品；
+找出所有购买畅销品的订单与顾客；
+分别以订单与顾客为源头去找与那些商品同时出现的其他品项。
+
+
+而“针对25-45岁白领女性，找出买A品牌的口红比例显著高于买B、C品牌的群体，想要知道特定族群对品牌的偏好性”这一需求的数据目标是：
+
+
+找出25-45岁的白领女性顾客清单；
+找出上述顾客购买的订单；
+分析这群顾客对畅销品购买的显著性。
+
+
+Step3. 盘点与汇整既有数据
+
+有了预计产出物，接下来就是要实际去看看手边的数据是否足够了，在盘点数据时除了内部数据外，也要同时思考外部数据。而当你盘点完内外部数据后，应该先做一次基本的汇总动作，确认这些数据是否充足。
+
+以上述案例来说，或许在处理第二项需求时，发现会员数据中，有填写年龄的只占总数的10%不到，这可能导致最终成效不如预期，因此盘点后，判定缺了年龄的数据。
+
+Step4. 盘点新数据采集需求
+
+如果数据盘点完后发现有所不足，那就要提出数据采集需求，并提列为数据行动方案。以这个案例来说，就是要想办法去采集会员的年龄数据。
+
+Step5. 拟订数据行动方案
+
+在执行完上述程序后，我们要将所有提到的工作事项列为行动方案，然后有计划、有分工的逐步落实，如此才有可能让数据落地，真正开始助力运营工作。
+
+研发工作是一个科学与艺术活，我们掌握着技术与数据，只要能让团队多一些商业与策略敏锐度，培养从数据角度去解读各种症状的意识，研发部门是完全可以助力业务快速推进的。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/053如何打造高效且敏捷的组织文化？谈高效研发流程那些亊（五）.md

@@ -0,0 +1,101 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            053 如何打造高效且敏捷的组织文化？谈高效研发流程那些亊（五）
+                            你好，我是箴亚管理顾问公司负责人，同时也是TGO鲲鹏会台北分会学习委员游舒帆，今天想跟大家分享的话题是“高效研发流程的第五步，打造追求‘更快、更好、更有价值’的组织文化”。
+
+前面四篇，我们把一个组织的骨架(组织)、血肉(研发流程管理)跟循环系统(需求、跨部门、数据驱动)都装上了，最后这篇，我们要来为组织注入灵魂，也就是团队的文化与价值观。
+
+价值观是如何形成文化的？
+
+几乎每一个大公司，都会谈使命、愿景与价值观。其中，我特别想跟大家聊聊价值观，价值观其实就是我们看待事情的原则，它会左右我们面对问题时的决定。
+
+而文化，其实是价值观实践出来的结果。当我们强调客户第一，强调诚信，而且公司通过一个又一个案例来告诉大家，什么叫客户第一，什么叫诚信，当大家都按着这些规则来决策与做事，做久了，就会形成文化。所以，文化其实是做出来的，而不是说出来的，大家对文化的感受，是我们怎么做，怎么思考，而不是我们说了什么。
+
+当价值观根深蒂固后，所有员工都会明白，当面临抉择时，只要按着价值观去做决定、去思考就不会错，因为他们知道，这问题即使去问老板，老板也一定会做相同的决定。当员工都知道该怎么做决定时，就不用事事请示领导，决策权分散出去，组织运作才会高效。
+
+所以我才说，文化与价值观是高效研发团队的灵魂，因为当大家都清楚我们追求什么，重视什么，该怎么做才符合我们的价值观时，再辅以专业知识搭建起来的组织架构与流程，团队便会自然的让一切更好。
+
+打造高效且敏捷的组织文化
+
+更快、更好、更有价值，这是团队不变的追求，那么该如何落实在日常，让团队清楚我们追求什么，以及我们重视什么呢？以下我拿几个常见的案例来跟大家分享。
+
+1.解决问题，别只是提出问题
+
+在团队内，我一直要求大家不要只会提出问题，而是要解决问题。当跨部门合作有灰色地带的工作时，产品经理或项目经理就应该先吞下，待问题解决后再来讨论由谁处理比较好。原先公司内没有人是从业务前线一路衔接到后勤运营与服务的，导致产品上市过程有许多的信息丢失，导致各部门认知有落差，进而影响了客户，当时我就要产品经理负担起这个责任，从前到后将所有问题都连接好。
+
+跟老板之间沟通有问题，我就要大家去掌握上游信息，与横向部门之间沟通有问题，我就要大家学习上下游思维。关于上游信息与上下游思维，我之前也有提到过，大家可以回顾前两篇的内容。
+
+经过一次又一次的案例，大家便清楚，当发生问题时，永远都要去思考怎么解决问题，而不是把问题丢给别人解决。
+
+2.具备主人翁精神
+
+在整个团队中，我对leader、项目经理、产品经理、资深员工的要求是显著严格的，因为我认为这些人是榜样，也是传递团队价值观跟文化的载体。所以让他们认清他们该承担的责任是非常关键的一件事。
+
+有一次我在与一个项目经理沟通项目状况，他告诉我他经过几番折冲，终于让业务部门与营销部门愿意配合项目进行，我仔细听他陈述结论，过程中我越听越觉得不对劲，后来我直接打断他。
+
+我说：“因为业务部门无法配合，所以你做了部分妥协，有些事情暂缓不做，而因为营销部门有资源调度的困难，所以你决定另一部分也不做，所以本来要做100分的东西，妥协后只剩下了60分，对吗？”
+
+他回答我说：“对啊，案子能推进比较重要不是吗？”
+
+我说：“这个思维有问题，只有60分的东西还要做吗？你让团队10多人跟着你忙了大半个月，结果弄一个60分的东西出来，这像话吗？”
+
+所谓的负责，不是只把工作做完，而是要做好且做完，100分的结果是我们这个项目的目标，沟通过程中如果碰到问题，你应该是在不折损目标的状况下去思考解决方案，而不是牺牲目标让事情得以进行。
+
+对成果负责，对团队的价值负责，对自己的成长负责，这就是我所强调的主人翁心态。
+
+3.追求又快、又好
+
+曾有一次，有个QA leader告诉我某个项目的测试时间需要三周，我一听觉得有点玄，因为开发时间一周，但测试却要花三周，不太合理。我问他为何需要这么久，他摊开了测试案例告诉我，因为需要测试的案例高达2、300个，这些时间无法节省。
+
+我接受了他的说法，也接受了三周这个时间，但我紧接着跟他说：“下一次同样的案例，我希望在2周，甚至更短的时间内解决。”
+
+他马上回我：“怎么可能？要快，就会降低质量，两者很难兼顾。”
+
+我说：“我并没有限制你的方法，你可以尝试自动化测试，团队自己学，或者对外招聘有经验的人进来；如果你觉得是系统架构造成测试复杂度提高，那你可以跟工程师团队讨论如何调整架构；如果你觉得是产品设计有问题，那你可以去找产品团队讨论。我甚至没有说你不能跟项目经理沟通，可不可以先针对80%的用户上线，有这么多方法，为什么都不去尝试呢？”
+
+经过这样的启发后，这名QA leader很快组织了自动化测试团队，也让原先的测试人员开始学习自动化程序的撰写，测试效率在半年间便有了很大的提升。
+
+对于运维团队，一开始大夜值班同仁一个晚上会接到2-3通on-call电话，我说我们要在一个月内把频率降低到一个晚上最多1通，后来我们用两周的时间做到了。紧接着我说要把大夜的异常问题减少80%，后来我们用2个月左右的时间做到了。过去我们找到一个异常问题，平均需要15分钟，我提出要在3个月内缩短到3分钟，后来我们也在三个月内做到了。
+
+当我们不断的提出追求又快、又好的要求，并跟着团队一起实现它，过程中团队便会意识到这些事情原来是可能的，而且本来就应该是这样做的，这个价值就会深植于大家内心。
+
+4.追求更有价值
+
+然而价值才是我们最终追求的东西，如果我们做的事情没有价值，那快与好的意义便失去了。所以在带领团队时，让每位成员清楚自己工作的价值是很关键的一件事，因为如果一个人不清楚自己做的事能为自己、为团队、为公司，甚至为世界带来些什么，他就不会对这件事具有热忱。
+
+如果你无法清楚说明你手边每件事对公司的价值，那你其实就不应该做这件事。很多人之所以每天都有忙不完的事，就是因为例行事务，因为被别人交办事项，但他们却未曾思考，为何要做这些事？或者，除了这些事，难道没有其他更值得做的事了吗？
+
+所以我们要培养团队的意识，在接收到每个任务时，一定都要提问或思考：
+
+
+“这件事是源自于公司哪个策略？”
+“是解决哪个问题？”
+“能改善哪个数字指针？”
+“能改善多少呢？”
+“很棒的事，别人不做，我们要不要自己来做？”
+
+
+这些问题看似尖锐，但却是关键中的关键，如果我们无法回答这些问题，又依据什么来判断工作的优先级呢？而为了让团队专注于更有价值的那些事，我们就要持续搬开那些阻碍我们前进的绊脚石。
+
+当大家都明白，判断价值，价值排序的重要性，也理解应该持续追求又快、又好，并勇于面对各种问题与挑战，以主人翁心态，对结果、对团队、对自己负责，高效的团队文化便自然形成了。
+
+过去几年，团队能产生大规模的组织、流程、制度的进步，背后都是因为团队文化已经被建立，否则要说服大家，并驱动数百人前进，难度是非常非常高的。
+
+如果你正面临团队文化建立的问题，我建议你可以按这个步骤来落地：
+
+
+思考企业的价值观是什么？而哪些行为符合这些价值观？
+在这样的价值观下，你希望你所带领的团队有什么样的思维与行为？
+与你的下一线主管进行价值观讨论，确保大家对价值观的认知是一致的。
+不断在各种场合中，藉由案例来告诉大家你是如何解读这些价值观的。
+持续的落实与检讨。
+
+
+关于高效研发流程的那些事，这系列文章到此告一段落了，希望很快有机会能跟大家分享其他的主题，谢谢各位的耐心学习，若大家有任何问题想要讨论，也欢迎大家留言与我联系。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/054打造高速运转的迭代机器：现代研发流程体系打造（一）.md

@@ -0,0 +1,185 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            054 打造高速运转的迭代机器：现代研发流程体系打造（一）
+                            你好，我是爱范儿CTO兼知晓云负责人何世友，今天想跟大家分享的话题是“打造高速运转的迭代机器”。
+
+现代移动互联网对研发流程提出的新问题
+
+移动互联网时代的产品研发，基本上是两个特征，分别对应老板和用户的要求：
+
+
+迭代速度再快一点，一分钟上线一个特性；
+交付质量更高一点，半个 bug 也不能有。
+
+
+而且没有上限。
+
+而速度和质量，是一个肉眼可见的相悖的存在——速度快了自然要牺牲质量，质量高了自然要牺牲速度。但在移动互联网公司的意识形态里，再相悖，那也是把大象塞进冰箱的问题，因此也就对研发流程提出了新的挑战。本文试图就该问题分享我的经验所得。
+
+正式解决前，我们伪随机地“采访”几位围观群众。
+
+问：如何搞定更快迭代？
+
+
+开发工程师：给我精确可实现的需求，我一人能干三人的活。
+运维工程师：给我更多一点机器干活，我让机器随时随地跑构建、测试、部署。
+其他各种师：大家高效沟通快速复盘，地毯式推进。
+
+
+问：如何产出更高质量？
+
+
+项目经理：迭代中各工序完整，涵盖各职责。
+其他各种师：沟通全面无疏漏。
+运维工程师：更多一点机器背锅。（滚……
+所有人：产品、研发、测试、构建、部署各环节紧密关联，随时可回溯，随时可加入新人。
+
+
+项目规模或大或小，周期或长或短，都是由一个又一个版本迭代构筑起来的。当我们在谈研发流程时，实际上在谈的，就是这不断重复的迭代过程。因此，打造研发流程，就是要打造一台高速运转的迭代机器。
+
+打造迭代机器
+
+工业时代的崛起，运转在工厂车间永不停歇的传送带是成功的基石。这条传送带贯穿了各个环节，配合精确的时间控制，最终形成产出效率最大化的流水线。纵观整个产品迭代周期，我们需要立即着手做的，恰恰就是找到这一条传送带。
+
+那什么是研发流程里边的传送带呢？
+
+迭代过程总览
+
+一个标准的互联网产品的一次迭代大概长这个样子：
+
+
+
+这个过程中，参与角色有：
+
+
+PO（项目负责人）
+PM（产品经理/项目经理）
+Designer（设计师）
+Developer（泛指各种研发岗位，开发者、架构师、运维等）
+Tester（测试工程师）
+
+
+各环节的交付物有：
+
+
+Story（一段需求描述）
+Product Document（产品文档、原型）
+Task（任务，由各岗位在项目管理平台创建并维护）
+Design（设计稿、交互稿、切图素材）
+Test Case（测试用例，由测试工程师编写并发起评审）
+Tech Design Document（技术设计文档，由开发者在开始编码前编写）
+Code Commit（一次代码提交）
+CI Build（持续集成系统自动化构建）
+Test Run（一次测试）
+Deployment （一次部署）
+
+
+各环节与环节之间的转场动作有：
+
+
+Review（审核、讨论、修改）
+Acceptance（验收）
+
+
+需要注意的是，这里的角色、交付物并非限定因素，各团队可以根据自身因素和项目规模应用不同的角色设定和交付物设定，大可不必纠结。
+
+可以看到，一次可短至一天内完成的迭代，涉及到 5 种角色、10 种交付物，同时，每个角色之间、交付物之间，都会由各种审批和验收的动作填充。一眼看上去复杂到爆炸。
+
+而我们作为技术管理者，需要将这些角色和交付物和动作管理起来，这是打造研发流程的基础。
+
+现代化的项目管理工具
+
+要做管理，必然离不开管理工具。项目管理工具在近 10 年里得到了很多厂商的青睐，纷纷投入研发力量，于是我们如今可以用上 Redmine、Jira、Trello、Tower、Teambition、Worktile、禅道等各种工具。
+
+其中，受 Trello 的影响，近些年的项目管理工具多实现的是简洁的“看板”管理方法，成品往往具有简单好用的特征。老牌的 Jira 则同时支持 Scrum、看板（Kanban）管理方法。Scrum、看板均是敏捷开发流程的实现，并不存在特别大的区别，各团队可以根据自身的喜好选择，这并不是重点。
+
+但如果项目管理工具还只是让项目中的各角色在上边手工创建、更新任务卡片，那一定会成为项目推进中的阻碍。现代项目管理工具一定要将交付物管理、串联起来。管理工具的目的是为了维护任务状态，而任务状态事实上是实际任务完成与否的反映。也就是说，管理工具需要具备从交付物所在平台获取动作事件，将其转换成任务的流转，并完成任务状态更新的功能。
+
+比如说，工程师的任务是写代码，当他做了一次代码提交，就意味着这个任务完成了，如果还需要他手动去任务管理平台更新任务状态，就比较多余。因此，任务管理平台需要具备从代码仓库获取代码提交事件的能力，并自动更新对应的任务状态。
+
+可以说，项目管理工具就是上文提到的研发流程里的传送带。
+
+这条传送带承载了任务的流转，更需要承载一个任务所有交付物的关联。一个任务，包含产品原型文档、设计稿、技术设计文档、代码、测试用例、测试结果、CI 构建、部署等诸多交付物，把这一切串起来，可以解决什么问题？
+
+回溯。
+
+可回溯的迭代
+
+
+
+“得益于”不断提速的迭代流程，互联网项目的代码腐化速度，早就从年提升到月。一个“正常”迭代的互联网产品，即便立项时的架构设计文档写得再细致出色，每次迭代时的代码写得再易读注释清晰，3 个月后，来一个新人，一定搞不懂为什么代码会写成这个鬼样子。
+
+为什么？
+
+因为无法追溯。
+
+代码的每一次更改，都是在响应当次迭代的产品变更。虽然每一次产品变更都可以通过产品原型的更迭得到留存，但因此导致的代码更改乃至架构微调，却无法产生对应关系。
+
+那通过任务管理平台来关联产品变更和代码变更呢？这样每一个产品变化导致的代码变化以及当次的测试、构建、部署结果都是串起来的，当需要回顾事故现场时可以将这些关键交付物拿起来看。应该可以解决所有问题了吧？
+
+还不够。
+
+不断迭代的技术架构设计
+
+
+
+虽然可以通过这些元素的串联还原当时的迭代详情，但依然可能出现搞不懂代码为什么写成这个鬼样子的困惑。因为已有元素的提供，可以搞清楚代码变更的罪魁祸首，但无法还原现场。在此，需要的是完善的、不断迭代的技术架构设计文档。
+
+举个例子：电商业务产品想增加送礼功能，用户 A 下了一个订单付完款，用户 B 填写收货地址。产品变更简单，增加一个用户 B 更新地址的流程就可以。但对应的代码变更则大了去了，这一个礼品功能的增加，可能直接导致订单架构的变化。这时候如果没有技术架构设计文档的补充，对当时的需求进行分析和架构变更设计进行记录，产出的代码一定是不好理解的。
+
+现代的软件工程构建，再也不是一座桥梁的构建模式——蓝图画好了就打死不改。代码可以不断迭代，同样的，蓝图，也就是技术架构设计也应该不断迭代。而设计文档，就是技术架构设计的迭代交付物，在整个迭代过程中，至关重要。
+
+至此，迭代过程可以做到完全可追溯，这对保证项目质量起到非常大的作用。一个新人刚加入项目，不管是从代码提交记录，还是从设计文档的修改记录，还是从每一次构建部署的记录，都可以追溯到关键节点。如此一来，项目的生长轨迹，再也不用依靠老同事的口耳相传得以维系，其腐化速度也能得以缓解。
+
+一个快速迭代成长的项目，就需要这样的基础。在这个基础之上，如何快速推进？须知，参与项目的不仅有人类角色，还有各种交付物所在的系统——在线文档协作平台、代码仓库、测试用例管理平台、CI 构建平台、自动化部署平台等。这些角色/机器之间，也需要沟通。
+
+沟通，不仅是人和人
+
+
+
+迭代中的沟通，一般有这么几种需求：
+
+
+角色之间的沟通，讨论、约定、解决冲突；
+群组内的沟通，头脑风暴、计划宣布等；
+就某一话题进行多人沟通。
+
+
+沟通工具要满足的条件之一，就是所有沟通结果可留底用于未来追溯。因此重要的信息，邮件依然是最佳选择。通常在项目启动、验收等关键时刻，邮件确认是最合适不过的。
+
+平日的沟通交流，则以效率优先，大多数是发生在即时聊天工具上的。微信提供了非常便捷的讨论组功能，外部联络时非常高效，可以瞬间圈起公司内外相关人士进行畅聊。但日常工作中，很多时候会有临时的话题需要进行多人沟通，沟通完就散。
+
+举个例子，#codereview 群组里，CI 构建系统发了一条最新的测试失败消息，相关的开发者需要就这一个失败进行讨论。直接在 #codereview 群里讨论吧，消息一多就冲垮了，有噪音；拉一个新的群组吧，又太费劲了。这种情况下，Slack 提供的 Thread 功能就能派上用场。
+
+
+
+此外，研发流程里参与的角色一半以上都是机器/系统，因此，沟通工具优先要满足的，其实是如何让机器和人对上话——这就是现代沟通工具的特征。在同一个沟通工具里，人类角色可以像和其他人类角色沟通一样和机器沟通，如接收机器的通知（如上图所示，有代码提交的通知、告警通知等）、向机器发送指令等。
+
+用机器打造迭代机器
+
+项目管理平台这条传送带，让一次迭代里的各个角色、任务可以快速进行流转，并从流程上充分利用时间、减少损耗。一个需求，粒度划分越细，就越可以做到精确可控。然而，一次需求从代码到上线，这中间的过程是漫长的——
+
+编码⟹静态检查⟹单元测试⟹测试⟹代码审查⟹构建⟹部署⟹运维……
+
+我们要做的，就是尽可能的自动化，让机器包揽所有能干的活。这样一来，迭代过程，不仅可以无误差运转，甚至连运维的工作都可以更加高效——
+
+编码【人类才智】⟹静态检查【机器】⟹单元测试【机器】⟹测试【机器】⟹代码审查【人类才智】⟹构建【机器】⟹部署【机器】⟹监控【机器】⟹自动扩（缩）容【机器】。
+
+除了两个必须要人类参与的步骤，其他环节机器均可以胜任。
+
+可能有人会问：研发团队写这一套自动化流程，得花多大成本（时间、金钱）？是不是和研发产品缘木求鱼了？答案是磨刀不误砍柴工。
+
+至于成本嘛，感谢开源社区和相关服务提供商，几乎都是现成的、可以花合理价钱买到的。篇幅有限，这里我就不展开了，下一篇文章我将跟大家简单说说各环节的现有解决方案及选型，敬请期待。
+
+研发流程是一个团队打造产品的过程，这里边一个最基本的性质就是生长、不断的生长。而产品快速度、高质量的生长离不开高速运转的迭代机器，本文就迭代机器的打造给出了我自己的经验与答案，存在疏漏在所难免，欢迎大家在评论区提问讨论。
+
+作者简介
+
+何世友，爱范儿CTO TGO鲲鹏会广州分会董事会成员，学习委员。从校园创业到跨国团队技术顾问再到如今，专注于高并发网络、机器学习、移动APP（部分硬件）、团队管理。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/055用机器打造迭代机器：现代研发流程体系打造（二）.md

@@ -0,0 +1,138 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            055 用机器打造迭代机器：现代研发流程体系打造（二）
+                            你好，我是爱范儿CTO兼知晓云负责人何世友，今天想跟大家继续聊聊“打造现代研发流程体系”这个话题，并将着重跟大家分享其中“用机器打造迭代机器”这一部分内容。
+
+在上一篇文章里，我们分析了研发流程中的关键环节，并给出了对应的解法。它们分别是——
+
+1.高速运转的传送带
+
+现代化的项目管理（任务流转）工具。
+
+2.可追溯的迭代
+
+通过传送带，将每一次迭代的产物，如代码提交、架构设计变更、测试构建部署等串联并存储起来。
+
+3.重要角色的沟通
+
+用一个通用平台，如Slack，在解决人与人之间通讯的基础上，重点解决系统工具与人之间的沟通问题。
+
+4.用机器打造迭代机器
+
+受限于文章的篇幅，上篇文章中只是简单说到了因为迭代的步骤很多，所以要让机器包揽大部分环节，估计很多读者并不能十分感同身受。本文将对此做详细解释：为什么要用机器打造迭代机器？
+
+迭代频率越高，对迭代里的自动化程度的要求就越高。打个简单的比方，如果项目要求一天迭代两次，测试工程师就要一天走完两次主流程回归测试。此时，人工就是最大的瓶颈。一个项目分分钟有成千上万个用例，依靠有限的测试人员分拣完成，那就是纯体力活了。而对质量的要求越高，主流程的覆盖范围就越广。单就这一个环节，如果没有机器的参与做自动化，就会成为一个不可调和的瓶颈了。
+
+之前提到，构成自动化流程的大部分工具都是现成的、可以花合理价钱买到的，本文就将重点介绍研发流程里的各种工具们，以及不同场景下的具体选型。由于这些工具被正确配置完成之后，拥有脱离人工干预在不断电的情况下自我运转的能力，我们亲切地称之为迭代机器里的机器们。
+
+迭代机器里的流水线
+
+
+
+编码【人类才智】⟹代码审查【人类才智】⟹静态检查【机器】⟹单元测试【机器】⟹测试【机器】⟹构建【机器】⟹部署【机器】⟹监控【机器】⟹自动扩（缩）容【机器】。
+
+这是一个环环相扣的流水线，每一个步骤都由一个机器角色完成并推送到下一个步骤，最终完成全程；一旦其中一环无法完成，则本次迭代就宣告失败，需要返工。
+
+通常这样的流水线跑在 CI 系统上。CI 系统，Continuous Integration，持续集成系统。常见的 CI 有 Jenkins、Bamboo、Solano CI 等。这些系统各有千秋美丑，本文不赘述对比，各位可根据团队背景和成员喜好进行选择，只需要看这个系统是否具有真正意义上的可定制拓展性，以及规模可观的第三方服务的接入支持。
+
+下边将围绕流水线中的几个重要环节进行描述。
+
+静态检查、单元测试、构建
+
+静态检查、单元测试和构建环节发生在每一次代码提交之后，由代码版本库的代码提交事件触发执行，如 Github、Bitbucket、Gitlab 的 Webhook 等。
+
+1.静态检查
+
+静态检查由各语言的语法 Lint 工具和bug 检查工具组成，前者包括 JS 的 eslint、Python 的 pylint 等，后者包括 Java 的 findbugs 等。
+
+2.单元测试
+
+基本上每种语言、每种框架都有支持单元测试，如 JS 的 Mocha、Python 的 unittest、Java 的 JUnit、Go 的 testing 等。工具本身都是比较类似的，各语言开发者都应该很熟悉。难在代码编写时的测试用例覆盖，这是一个需要仔细权衡覆盖度和时间的过程。
+
+在实践中，比较推荐的是，让测试工程师参与到单元测试编写中来，每一次项目的测试用例评审，一部分用例一定要转化为开发工程师的单元测试。或者说，测试工程师需要参与到开发工程师的单元测试审查和覆盖率评估中，对应的，开发工程师也要参与到测试用例评审中。这二者相结合，黑白盒、单元集成测试才能真正有机的为项目质量负责。
+
+3.构建
+
+构建（Build）是需要开发工程师根据项目的部署策略编写对应的构建打包脚本。例如前端的 webpack、后端的 maven、客户端的打包等。不过基本上要做的事情就是将原本由工程师在本机上跑的脚本移植到 CI 系统上，这个过程本身不带来多少成本。
+
+自动化测试
+
+自动化测试由测试工程师维护，由两块工作构成：测试用例管理、自动化测试脚本编写。
+
+1.测试用例管理
+
+测试用例管理流行的工具有 Excel、Qmetry、TestLink 等。没错，Excel 在众多公司中依然是管理测试用例的好工具。当然在我们讨论的场景里，Excel 已经不堪其用。管理测试用例，是为了让测试用例和对应的需求描述，也就是 User Story 关联上。从而让每一轮测试执行，也就是 Test Run 的结果，不论是成功或失败，都自动回传到关联的任务状态里。
+
+
+
+同时，平台级的用例管理，可以让用例迭代起来，和项目一起生长，这和前文提到的架构设计文档的迭代一脉相承。甚至，用例要作为项目推进中的自动化测试的组织枢纽，串联起自动化测试和实际任务的状态流转。
+
+2.自动化测试
+
+这里的自动化测试，主要指的是黑盒测试和集成测试，和开发工程师维护的单元测试做一个区分。常用的框架有 LoadRunner、Selenium、Appium 等。这是一个十分耗时耗力的过程，常见的做法是梳理经过每一次迭代的测试用例，最终形成一个主流程用例集。
+
+主流程的特征是产品特性基本稳定，不会在短期内有较大改动。测试工程师需要对主流程的测试用例进行测试覆盖，例如通过 Selenium 进行 UIUE 的用户交互过程录制等。而有了主流程的覆盖，每次迭代的发布，才能够真正的做到 push on green。否则，每次发版还得测试人员手工回归确认，那基本就是一个跨不过去的时间鸿沟了。
+
+部署、监控、自动扩（缩）容
+
+1.部署
+
+Devops 的兴起让运维得到解放，Docker 的流行也让社区疯狂，似乎非 Docker 不可，不上容器不是好技术团队。其实不见得。重要的是达到目的，而非工具，一定要根据项目实际情况进行技术选型，不要因为一种便利引入额外的麻烦。
+
+目的是什么？目的是让机器自己完成自动化部署。
+
+而通过前面介绍的工作，CI流水线上已经有了经过完整测试的构建产物，于是部署阶段只剩下：
+
+
+开启并初始化机器，并完成系统环境配置，通常可以用预先准备好的镜像文件完成该步骤；
+上传构建产物到机器上，启动服务；
+将流量或任务分发到新的机器上；
+下线旧的机器。
+
+
+这里边有机器的运维、服务的部署、负载均衡器配置等，每一项业内都有非常不错的工具可以用。比如我们在爱范儿目前用的是——
+
+
+使用 Ansible 完成环境的自动配置，结合AWS的ami镜像完成机器运维部分；
+使用 Fabric 结合AWS的CodeDeploy完成的部署流程，并在此基础上完成了 Auto Scale。
+
+
+AWS 的 CodeDeploy 非常好地利用了AWS的基础设施，可以一键完成上面提到的 1、2、3、4这几个环节。而在使用 CodeDeploy 之前，团队写了一系列脚本去做这块的工作。
+
+Auto Scale 常见的做法是在监控系统里定义一系列的 Metrics，设定阈值，比如，“过去 2 分钟内机器 CPU 达到 60% 以上”就是一个完整的阈值条件定义。然后为这个阈值配置一个动作，比如“过去 2 分钟内机器 CPU 达到 60% 以上，部署并上线 4 台新的应用服务器”。而怎么部署并上线新机器就是上文的 CodeDeploy 的活儿了。
+
+2.监控
+
+监控分异常监控和性能监控。
+
+异常监控配合日志收集器工作，如前端的 Sentry，后端的 Cloud Watch（AWS）、loggly等。基本的工作原理是从日志中获取错误信息，并进行统计，达到设定的阈值就开始报警。异常监控系统经常对接的是电话告警系统，为 OnCall 的工程师提供错误叫醒服务。
+
+性能监控分微观和宏观两个维度：
+
+
+APM 探针实时收集应用服务器代码层面的性能信息；
+机器状态（cpu、mem、load）、应用服务响应时间等。
+
+
+这两者结合可以无死角反映服务状态，对接到 Auto Scale 系统后可以在大多数情况下完成自动化运维。
+
+APM 探针服务，常用的有 NewRelic、AppDynamics 等，国内也有听云、OneAPM 等一众厂商。区别基本上就是价格和第三方支持完备度，近些年各大云服务商也在做这些周边支持，选择上并不是难事。也有一些团队将机器状态等信息归到异常监控里，而我们归到性能监控，主要是站在能否让机器自己治理的角度。毕竟，放到异常监控，OnCall 的工程师更容易醒，但醒了不也是要做 Scale 的事情嘛。
+
+说到这里，大家在迭代流水线中的各个环节上都用了哪些工具呢？欢迎在留言中告诉我们，供大家参考。
+
+一些待完成的和待思考的
+
+然而，一台高速运转的迭代机器中，人类角色才是真正的瓶颈。或者说，高速迭代对人员的要求会更高。因此，团队的成长便更为重要，也更值得探讨。坊间有一句话，互联网公司都是轻资产，值钱的就是人、流程、代码。
+
+那如何打造一个高速成长的团队呢？希望有机会可以和大家探讨。
+
+作者简介
+
+何世友，爱范儿CTO TGO鲲鹏会广州分会董事会成员，学习委员。从校园创业到跨国团队技术顾问再到如今，专注于高并发网络、机器学习、移动APP（部分硬件）、团队管理。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/056有了敏捷开发，那交付期限去哪儿了？.md

@@ -0,0 +1,100 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            056 有了敏捷开发，那交付期限去哪儿了？
+                            你好，我是明道创始人任向晖，今天想跟大家分享的主题是敏捷开发中交付期限控制的问题，以及其他行业带来的启发。
+
+今天，软件行业已经无人不知敏捷开发，实践者也不局限于互联网产品公司，即使是传统软件开发团队，也十分愿意采纳敏捷开发。温和的看板之于严苛的期限，当然前者要友善得多。SCRUM能够得到普及，和它宽慰人心的作用是分不开的。
+
+敏捷开发宣言
+
+敏捷开发思想的确在改变软件行业面貌。它让小型团队可以摆脱过于笨重的项目计划，让产品设计和开发避免闭门造车，不至于让程序员的青春年华浪费在那些因为失败而没有投入使用的软件项目上。
+
+它同时也推动了需求方和开发者之间的持续透明沟通，让团队开始意识到，高频度的沟通是提高软件交付质量的原动力。敏捷开发还将工作的起点转换到客户的具体问题解决上（User Story），而不是从一个看似完善的产品需求文档出发。
+
+2001年，17名软件工程师发表了著名的敏捷宣言，全文只有聊聊数十个字：
+
+
+我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：
+
+个体和互动 高于 流程和工具
+工作的软件 高于 详尽的文档
+客户合作 高于 合同谈判
+响应变化 高于 遵循计划
+
+也就是说，尽管右项有其价值，我们更重视左项的价值。
+
+
+在应用敏捷开发的数年中，我们自己从中得到了很多的收益。作为SaaS软件产品，采纳敏捷开发模式几乎是从本能出发的。至少，我们没有和客户的合同谈判，也并非为特定客户交付一个软件项目，而是自始至终地改良属于自己的产品。
+
+在相对稳定的冲刺周期内（2-4周），交付短期可估量的特性通常不是很大的挑战，即便有1-2天的延期和缺陷修复，看起来也没有严重的商业后果。
+
+期限之殇
+
+但软件开发行业的大部分从业者其实并不是产品开发者，而是服务于提供IT服务的外包开发商。他们按照合约的要求，需要在固定的期限之内给客户交付可用的软件。敏捷开发宣言似乎并不能完全打动他们的客户，因为期限不仅是开发合同的要件，还会直接影响客户的业务运营。在一桩典型的外包开发项目上，的确很难应用敏捷开发模式。
+
+即使是像明道这样的产品型公司，也不能完全通过敏捷开发模式来覆盖所有的开发活动。对于全新的重构、大型版本的迭代、技术债的偿还、复杂的特性交付等情况，就几乎不可能在2-4周的时间范围内达成。我们经历过的最漫长迭代周期超过四个月。虽然这当中肯定有决策失误的原因，但没有产品能够完全幸免这样的遭遇。即使像Salesforce, Asana, Atlassian这样的高水平SaaS产品企业，都有过那些结果糟糕，却又不得已为之的长跑型迭代。
+
+
+
+这张图是敏捷开发模式下典型的任务板模型。乍一看是非常直观且有效的开发管理模式。但它只能支持日常特性迭代，在固定周期内完成合适数量的User Story。而且，在In Process这个狭窄的看板中，其实掩盖了过程控制问题。如果这个In Process不能在1-2周内完成编码和单元测试，整个冲刺就高概率地会失败。
+
+SCRUM方法要求在这种情况下进行复盘，找出项目延期的原因，在下一次迭代中针对性改善。但从很多产品团队的反馈来看，这个原因通常总是被归结为User Story放得太多了，或者定义得太模糊了，而很少有去复盘设计开发过程中的进度控制问题。
+
+所以，SCRUM在带来价值的同时，并不能天然地保证团队准时的交付。而如果要做到准时交付，团队也不能通过牺牲特性交付量来实现，因为企业永远受团队协作、销售业务需要、竞争等要素的压迫。
+
+无论是传统的开发项目，还是敏捷开发项目，我们到底应该怎样来实现高成功率的进度控制呢？
+
+其他行业的启示
+
+要为软件行业找到按期交付的办法，我们可以从其他对工作交付期限有更高要求的行业中寻找灵感。在众多行业中，建筑工程管理和按单制造业是符合要求的两个行业。
+
+建筑工程受制于客户合约、租赁器材的高成本、人员计划的约束等因素，对于项目执行的节点要求非常高，项目或者项目内的大节点延期会带来大额的损失和违约风险。完整的建筑工程项目计划大多用甘特图绘制完整，其中包含任务的前置关系、资源的约束，并且项目计划被允许保存为基线，用来和实际进度定期比较。
+
+同时，通过专业的项目管理软件（例如Project），项目经理还要识别出众多任务中的关键路径（Critical Path），在关键路径上的任何任务延期，都会导致整个项目的延期。相反，如果一个任务不在关键路径上，那么它可能有一定的缓冲空间。
+
+按单制造业根据客户性质的不同，按时交付的刚性有所区别。但整体上都面临客户合同的约束，即使延期也必须在合理范围内。如果是在工业上游的制造业，他们面临的交付压力就会非常大，因为一旦延期交付，影响的是后续供应链的生产计划。想象一下苹果公司对富士康等装配企业的要求，再想象一下富士康因此给上游材料、工具、模具等制造企业的交付要求。
+
+因为这两个行业面对的现实挑战，他们自然会因为内在的压力形成一些有效的做法，来实现更可靠的按期交付率，这些方法和原则可能对软件业有所启发。
+
+1.专业的WBS分解
+
+如果打开一个建筑工程项目管理文件或者一家模具制造厂的工单分解和排程表，外行肯定像看天书一样，因为你没有受过工程专业训练，不了解各门类产品具体的生产工艺和制造程序。反过来说，如果这两个行业的任务和里程碑分解结果你都看得懂，那就说明它无法起到真正的过程管理作用。
+
+对于外行来说，也许最多能够猜测出来的建筑工程里程碑就是打地基、结构封顶、内装修和外装修了。但这些所谓的里程碑每一个都可能需要数个月的周期才能达成。而实际上，一个普通民用建筑的里程碑就需要数十个分部分项专业才能列举完整。
+
+分解的WBS任务有大有小，建筑业的最小工作包从一两天到一两个月不等。无论长短，它都有一个专业衡量，即便它来自的是经验判断。一座小型建筑的施工准备是2天，土方开挖和基底清理要20天，楼层主体每层要20天，这些预计工期在行业内已经成为显性的知识。
+
+专业的任务分解、工期预估、流程次序和里程碑定义是进度管理的基础，有了这些信息，我们才能够实现第二步——持续跟踪。
+
+2.持续的进度跟踪和关键里程碑
+
+这两个行业都有高密度跟踪进度的实践，而且大多有专人负责。建筑业一般在项目部有施工日志要求，并依据日志通过专人来负责更新进度表，制造业则有每日站会（一般就在车间里）和生产经理来管理排程。
+
+进度跟踪的基本逻辑在两个行业有所不同。建筑业通过原有的基线对比，来准确协调各分部施工方、分包商、材料供应商和施工人力资源的准备、入场和验收。准备完成、入场和验收完成是建筑业各个分部分项工作的核心里程碑。
+
+制造业则紧紧围绕工件，依据工件在制造程序上的流转来确定进度，如果进度滞后，则要及时修改剩余的制造程序排期，所以大体可以认为工件在单个制造工序上的完成是制造业的关键里程碑。
+
+3.遇到问题后的快速会商
+
+软件行业中的从业者，经常被一件事情困扰，那就是需求的不明确和经常的变更，尤其是自有软件产品开发项目。很多软件开发的延期会将责任归咎在需求的含糊和变更上。
+
+我以前总以为像建筑工程这样的项目不太会有经常的变更。设计图纸和施工工艺一般不存在含糊的情况。事实看起来的确是这样，一座机场可容不得在开工了一半的情况下突然决定增加一个候机楼。但是，这并不意味着其他行业不存在变更和其他意外的问题。
+
+实际上，局部的施工修改和变更随时都可能发生，施工中遇到的实际环境和设计条件存在差异，因为环境、设备、材料、人员能力和工艺有效性带来的突发问题层出不穷。制造业甚至总结出了“人、机、料、法、环”（分别指人员、机器、材料、方法和环境）这几个生产影响要素。
+
+那么遇到问题该怎么办呢？从这两个行业观察到的方法和我的本能直觉一致——集体会商！
+
+制造业的现场管理和站会不是没有道理的。在生产过程中发现和产生的问题，最好的解决办法就是在制造现场，站在车间里解决。建筑业也是一样，除了工程师可能要带上安全帽进入施工现场以外，工程项目部也永远都设在施工现场一两百米的距离之内。
+
+我在采访一些工程项目部的时候，发现所有的项目部经理办公室都有一个大大的沙发区，项目经理很难离开这个现场，因为他们随时要召集不同职能的人会商问题。
+
+总结一下，专业的WBS分解、持续的进度跟踪和关键里程碑，以及遇到问题后的快速会商，从建筑工程业和按单制造业这两个行业总结出的这三个要点看起来非常简单，也不难理解。但反观我们的软件业，在全行业拥抱SCRUM的同时，似乎丢失和忽略了一些原则。这也许就是我们管理交付期限更为困难的原因。
+
+受限于篇幅，本期主要跟大家分享了敏捷开发中项目期限控制的问题，以及其他行业带给我们的启发，下期，我将跟大家分享软件业具体该采取的做法。感谢您的收听，我们下期再见。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/057敏捷中的期限之殇，软件业该怎么做？.md

@@ -0,0 +1,83 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            057 敏捷中的期限之殇，软件业该怎么做？
+                            你好，我是明道创始人任向晖，上期内容跟大家分享了敏捷开发中项目期限控制的问题，以及其他行业带来的启发。今天，想跟大家聊聊想要更好地控制项目进度和周期，软件业该怎么做？
+
+1.将进度要素纳入敏捷开发
+
+其实敏捷开发宣言中也并没有完全抛弃进度，它只是说响应变化要优先于遵循计划。而因为迭代更新的周期相对稳定（2-4周），所以看起来敏捷开发模式没有延期的问题。再不济也是割舍了一些完不成的特性，作为一个不算成功的迭代来复盘。
+
+预测在2-4周内能够完成的特性开发量相对容易，稍有经验的ScrumMaster都能够基本估准确。但并非所有的软件开发迭代都是这么短的周期。在新版本开发、复杂的企业SaaS特性开发中，一个迭代经常需要超过一个月，再加上必要的测试和灰度发布，可能轻易超过两个月。我统计了一些常用APP的版本更新历史，发现80%以上的APP更新频度在两个月以上。
+
+所以，我们必须要把进度要素重新纳入敏捷开发的管理范畴内。
+
+这意味着，看似简洁的SCRUM开发看板，在In Process（开发中）这一栏中的任务内容，需要建立另外一套计划和跟踪系统才能实现更可靠的进度控制。
+
+而在敏捷开发之外，传统的软件开发计划和建筑工程项目管理相比，大多也欠缺详尽的进度计划，而只是笼统的定义了几个粗放节点。如果是业务部门人员和外包客户达成协议，软件工程人员往往在交付时间要求上缺少发言权。很多软件外包项目的所谓开发交付计划都是根据客户要求的时点往前倒推而已。很多时候，别说客户了，就连自己人也很容易拿交付的时点来倒逼开发团队。
+
+是不是应该倒算排期是一个很难回答的问题，企业总是面临客户的需求压力和竞争压力。问题的关键不在于交付期限的来源，而是有了交付期限以后，我们应该怎样细分软件研发工作的关键里程碑。
+
+2.软件研发的关键里程碑
+
+软件研发的里程碑到底应该怎样定义？我相信这个问题很多研发团队都做过探索。按照设计交付、编码完成、测试发布和验证发布这样的粗线条节点划分虽然容易，但对进度管理并没有实质性的帮助。而且，对于敏捷开发项目来说，设计交付甚至都不是一个一刀切的工作，有一部分细化设计工作完全可能在编码工作开始以后再进行。
+
+当我们从建筑工程行业寻找灵感的时候，发现他们的关键里程碑是各个分部分项工程的准备、入场和验收，而且每个分支工程所需要的工时在计划时能够比较准确地衡量。虽然软件开发远远没有建筑工程的分工项目那么多，但是要做到可靠进度管理的基本前提是一样的。
+
+制造业的规律也同样提供了线索。工件在工序上的转移是一个明确的物理过程，进入B工序的前提是完成A工序，每个工序所需要的工件加工时间只要能够被精确衡量，整个制造过程所需要的时间和资源就能够被事先计划清楚。而这个计划过程是在工件进入加工之前用专门的排程工作事先完成的。
+
+那软件业如何采用类似的思想来提高自己的进度管理水平呢？
+
+首先，软件开发要根据前端开发、后端开发和测试的主要专业分部建立细化的专业里程碑。一般前端开发工作依据设计阶段产生的页面来清点前端组件开发工作量。在模块化开发的过程中，还要注意对通用组件的合并归纳。一般而言，页面数量越多的应用，前端开发的工作量越大，模块化程度越低的项目，工作量越大。后端开发则根据数据对象和功能特性的设计来细化出接口列表和数量。如果不涉及特殊计算，大部分企业应用的开发工作量和接口数量成正比。而黑盒测试所需要的时间则和以上前后端开发量的总计成正比。
+
+
+
+理解了这个规律，再复杂的软件开发项目也可以像建筑工程那样列出整个开发测试工作的关键里程碑。
+
+在分割这些里程碑的时候，达成里程碑所需要的工作时间一般要细化到一周工作量以内的颗粒度，否则开发过程中的按周检查就失去了意义。
+
+那谁能够有这个专业能力来定义这些关键里程碑呢？其实和建筑工程一样，团队并不需要一个全能的高手，而是应该由负责前后端和测试工作的专业工程师一起评估给出。制定计划和执行计划的人如果是一致的，计划达成的概率就会更高。当然，因为前后端开发工作不可避免地需要相互协调，以确定科学的次序，所以这个制定过程总是依赖产品和研发人员的集体会议。但这样的会议因为目标清晰，就是为了产出里程碑列表，所以效率可以得到保证。
+
+下图就是一个根据以上原则和方法创建的复杂开发项目关键里程碑列表。为了便于每周的检查和跟踪，特意没有做成甘特图模式，而是将里程碑项目根据期限进行分组，每组就是一周内应该达成的里程碑。开发小组在周末进行的检查完全基于这个开发进度计划。
+
+
+
+按照这个方法，能不能根据迭代的总期限（比如四周）进行倒推呢？当然可以！而且，这样的倒推，才让敏捷开发中重要的响应变化原则得到体现。在没有可靠进度计划之前，产品研发团队对于一个迭代所需要装进去的开发内容总是容易产生争议，大部分争议集中在用户价值上。但是，用户价值是需要使用数据加以佐证的，在新产品、新特性的开发过程中，往往还没有足够的用户数据来帮助决策，这时候，特性功能对交付时间的影响就成了另外一个关键决策要素。
+
+当我们不得不尊重一个大版本的交付总期限时，团队就能在细分到每周的开发里程碑表中找到均衡，更容易达成一致。有时候，团队会毫不犹豫地在开发计划中将某个特性划去，因为它极有可能带来整个项目延期的风险。
+
+以上介绍的是在敏捷开发模式下的进度计划要素。这个基本方法当然也可以用于一个全新产品和项目的研发过程，只不过，这时除了具体的模块定义、接口定义和页面组件定义带来的开发工作时间计划外，还需要留下足够的项目整体架构时间。这些初始化的架构工作包括项目成员参与技术方案调研和论证、数据结构的初始化设计、通用类库的定义，以及在这个过程中和产品需求方的沟通工作等。根据需求来源的性质和清晰度差异，它们通常要占据团队2-4周的时间。
+
+3.跟踪、响应和及时沟通
+
+制定和落实了进度计划，是不是就不会有意外呢？当然不一定。无论是自己的产品，还是客户的委托开发项目，变更有的时候是难以杜绝的。为了保证最终交付的质量，我们宁可冒险去接受某些变更，也不会对已知的失误无动于衷。
+
+但接纳变更，响应变化的前提是持续对里程碑计划进行维护。让最新版本的里程碑计划能够体现出变更后的情况。和其他行业不同，软件行业一般不需要做完整的基线对比，所有的变化都应该反映在从今天往后的新计划中。从这一点看，对进度的控制并不破坏敏捷项目管理的基本原则。
+
+此外，当周不能完成里程碑的原因不仅仅是需求的变更，还可能是开发过程中遇到的技术实现问题。我们永远无法保证研发人员事先已经掌握了所有的技能和知识，开发过程中随时可能会遇到成员的能力瓶颈和信息断层。解决这个问题的办法和建筑业、制造业一样——及时的会商。
+
+开发人员有时会怯于提出问题，担心自己遇到的阻力会影响团队的进度，所以一个人闷头花了过长的时间，而事实上可能有更好的解决方案或者完全可以接受的变更。为了保证能做到这样的及时会商，团队可以约定在周中（比如周三下午）安排一次期中检查，由产品、研发和必要的管理层一起参加，主动去发现这样的执行瓶颈，以避免到周末的时候面对不得不被动接受延期的现实。当然，为了做到更高密度的跟踪，研发团队内部也应该坚持SCRUM开发要求中的每日站会。
+
+所以，在研发过程中，跟踪进度、响应问题和及时主动沟通是保证进度的基本手段。
+
+4.按期交付的激励
+
+最后，我们要谈一谈按期交付的激励问题。很多开发团队为了解决按期交付的问题，都设计过各种各样的激励计划，其中最常见的就是项目按期交付的额外物质激励或者假期奖励，名曰项目冲刺奖。甚至还把提前交付的时间长度作为奖励的一个变量。
+
+从我们长期的研发管理实践看，这样的做法有百害无一利。因为，它会让管理的重心盯向结果，而不是必要的过程，从而忽略投入在那些让项目如期完成的原因上。
+
+过度强调如期交付的奖励，会让团队成员忽略质量，不愿意花费时间在计划和沟通上，而且一定会制造研发人员和产品设计人员之间的矛盾。如果前者对交付时间负责，后者对用户满意度负责，这之间的冲突和撕裂是可以想象得到的。
+
+最好的按期交付激励应该落到平时。如果能够细化到按周评估的里程碑，就给了我们庆祝small win的机会，按周的如期交付也是如期交付，同样值得奖励，甚至如果周四就完成了当周的开发里程碑，周五就可以是一个自由工作时间。
+
+对于软件研发人才，更宝贵的激励是能力的迅速提升。如果研发成员都参与过进度计划工作，尝试过科学拆解研发里程碑，他们将来的能力将不仅仅是更出色的程序员，而是能够管理更复杂项目的主管人才。
+
+这种体验，只要是做过相关工作，尝到过胜利果实的研发人员都能够迅速体会到。这就像在足球赛场上，赢得最终比赛是激励，但除此之外，如果球员能够组织一次有效的进攻，赢得一个进球，或者成功化解和阻挡一次险恶的进攻，这些都是非常有效的激励。
+
+最后，你们是如何控制项目进度和交付期限的呢？欢迎在留言中告诉我们。感谢您的收听，我们下期再见。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/058如何打造个人技术品牌？.md

@@ -0,0 +1,81 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            058 如何打造个人技术品牌？
+                            你好，我是余晟，一个老程序员，一路坎坷走来，积累了些技术品牌和演讲的经验，今天，想跟大家分享该如何打造个人技术品牌。
+
+技术品牌，它到底是公司的资产，还是个人的财富？
+
+我们都知道，公司有了技术品牌，在招聘方面会获益良多。那么个人的技术品牌呢？它能给个人带来什么？起码就我的经验，个人技术品牌有几点收益是相当明显的。
+
+1.个人技术品牌降低了你找工作的难度
+
+我至今仍然庆幸，自己刚工作不久就发现了一个秘密：有些人找工作不靠投简历，全靠朋友介绍。后来更是发现，好工作往往也不公开招聘，全靠有熟人引荐。那么，上哪里去找那么多的熟人呢？一个人的精力和交往范围有限，这时候技术品牌就显示出强大的辐射力了，如果你之前研究过相关的领域，网络上可以检索到你的研究成果，而且这些成果是靠谱的，那么即便没有熟人背书，其他人也会认为你是靠谱的，好的职位也愿意为你开放。
+
+2.个人技术品牌拓展了你的交往范围
+
+如今每个人的时间都很宝贵，有时候明明两个人很聊得来，深入聊下去会碰撞出许多火花，但因为素不相识，很难在初次见面就找到沟通频道，所以擦肩而过。如果有个人技术品牌，你的每一篇文章、每一次演讲，都是你的副本，都可能被人认识、记住。所以初次见面，寒暄上一两句，人家可能就会说：我看过你关于某某的文章，我是这么想的…… 这样，打交道自然容易很多，也容易建立起信任。
+
+3.个人技术品牌可以提供额外的职场保护
+
+大家都知道职场凶险，翻脸比翻书还快，卸磨杀驴、兔死狗烹的事情并不罕见。如果很不幸你遭遇了这样的事情，当然可以求助媒体和劳动仲裁，只是结果不一定乐观。但如果你有个人技术品牌作为后盾，对方多半心存忌惮，动手之前总要仔细掂量掂量，不敢把事情做绝。或者即便下了黑手，你也不会吃闷头亏，总能讨来几分公道。看看近年的几个例子，你就会知道我所言不虚。
+
+既然个人的技术品牌有这么多好处，怎么做才能建立它呢？其实无非靠两样本事：写作、演讲。偏生大多数技术人都很内向腼腆，无论写作还是演讲，都不是天生就有优势的。所以在这里，我提供一些可行的经验来供大家参考。
+
+1.写作从翻译开始
+
+对我们大多数人来说，写作一直是让人头疼的。经常有人问我：写作有什么秘诀吗？其实没什么秘诀，就是要多写。但他们会说：我就是写不出来…… 既然如此，那就从翻译开始吧。大家起码能阅读技术文档，能就技术文档和同事交流，所以翻译的难度不会太大。 在翻译中要注意以下几点：
+
+第一，翻译和阅读不一样，翻译对原文的理解要求更高，否则可能发生错漏而毫无觉察，所以最好从自己熟悉领域的资料开始翻译，这样更有把握；
+
+第二，翻译完成之后不必立刻发出来，可以过几天再以“没读过原文”的心态仔细看看，确保读者能看懂，发出来之后当然还可以再修改，但原始版本可能已经四处流传了；
+
+第三，翻译时可以加上一些自己的观点和评论，如果能把技术和自己的实际经验结合起来就更好，纯粹的翻译不容易凸显自己的特点，对中文读者的参考作用也有限；
+
+第四，记得在每次发表翻译稿时注明自己的身份，可以借助其他的平台，但尽量不要做这些平台上无私贡献流量的无名氏；
+
+第五也是最后一点，一旦开始做就要持之以恒，如果能就同一主题翻译十篇以上有份量的文章，无论是对自己理解的加深，还是对技术品牌的塑造，都是非常好的。
+
+2.技术写作要真诚严肃
+
+如果已经熟练翻译，就可以开始尝试自己原创技术文章了。这时候要注意的是，态度必须真诚严肃。
+
+有许多人希望建立自己的技术品牌，做法却非常虚浮潦草：或者是无责任转载，或者是浮光掠影走马观花，即便想认真做点介绍也是囫囵吞枣。其结果就是，当大家在网上搜索某方面的技术文档时，看起来资料很丰富，点开一看却发现每篇文章都大同小异，一些错误以讹传讹，感受非常差劲。
+
+这正是目前中文技术文档的现状，所以久而久之，大家都养成了差不多的习惯：不但要看文档的标题，还要看文档的出处，是不是来自靠谱的作者、靠谱的团队。如果是，才点开。但这也意味着，如果你建立了良好的技术品牌，是很容易被广泛认可的。
+
+所以在技术写作时，务必保持真诚严肃的态度。所谓真诚，是指不浮夸、不吹嘘，做了八分绝不说成九分，懂了五分绝不说成六分，不懂的可以承认自己不懂，或者给出解释并标明是猜想。
+
+所谓严肃，指的是讲逻辑、讲证据，我自己在写技术文章时，常常发现自己之前解决问题的思路竟然是有问题的，或者有一些资料理解错了，或者拿到的证据已经过时，于是需要重新查证、理顺思路。在这个过程中自己的认识深化了，最终的结果也得到读者的广泛认可：原来这类问题，看这篇文章就足够清楚了。
+
+3.写作过程中务必多交流
+
+技术品牌虽然好，但很多时候它属于“自找麻烦”，因为它并不是技术人的必须选项。于是，建立自己技术品牌的道路必然是孤独的，半途而废的例子我实在见过太多了。所以，有志于建立自己技术品牌的人，当然应当加强交流、互相协作。
+
+具体来说，看到其他人高质量的劳动成果，应当表示赞美，即便其他人“抢先”发表了翻译稿或者意见也不要愤恨；在论述相同主题时，如果借鉴了人家的成果应当大方说明，即便没有借鉴甚至观点都不同，也可以以“延伸阅读”或者“参考阅读”的形式链接过去；如果发现其他人的论述比自己的更高明，甚至指出了自己的错误，也应当大方承认不足，以学习心态虚心对待。
+
+如果能做到上面这些点，自己的技术品牌就不是茕茕孑立，就不是单纯凭快、新、奇、孤傲赢得观众了，还有来自其它技术品牌的延绵活水。同时，你自己也会被更多的技术品牌创造者所接纳，进入他们的圈子。圈子的温暖，圈子的力量，圈子所能提供的视野，都远远大于埋头苦干的个人。
+
+4.技术演讲要循序渐进
+
+与写作相比，技术演讲是更高的挑战，也会带来更多的好处：鲜活、形象、有现场的互动，后续还可能有媒体报道。
+
+但是演讲的难度也更高：写作可以反复加工，直至拿出成品为止，演讲却没有反复上台的机会。写作可以不必直面观众，以文字作为中介，演讲却必须与观众做直接沟通。 不过这些都不会是太大的困难，通常来说，要成为演讲者，应当注意下面几点。
+
+第一，舍得削删。写作是比演讲更为自由的，空间也更大，所以写作时往往可以对某个主题做大而全的论述。但是演讲的时间有限，观众的注意力和耐心也更有限。所以设计演讲稿时务必对写作的内容做大的削删，去掉细枝末节，只留下最重要的点。
+
+通常来说，三十分钟的演讲，能讲清楚三到四个点就很不错了。所以不必舍不得自己辛苦准备的材料，因为堆积材料反而会喧宾夺主，模糊观众的印象；也不必担心听众接收的不够全面，只要准备好完整的学习材料在演讲完后下发就可以。
+
+第二，反复练习。或许你对某个问题已经滚瓜烂熟了，但这并不意味着你一定能讲好它。如何保证能讲好？除了多练习，没有其他诀窍。你可以从“讲给身边人”开始练习，对身边人讲两三遍，确保他们能听懂，你也能讲得流畅。然后，尝试给更远一点，更大一点的团队来讲，同样确保他们能听懂，你也能讲得流畅。然后再尝试给更远一点的、更大一点的团队去讲……
+
+注意，这里说的“讲”不是简单的重复。每次讲都要全神贯注，讲完都要认真反思，对暴露出的问题，要有针对性地解决。按照我的经验，即便没有任何演讲经验的人，练三次基本可以给三五个人的观众讲清楚，练十次基本可以给一百以内的观众讲清楚。前提是，一定要有足够的耐心来练习——无论练三次还是练十次，针对的都是同一个主题。
+
+第三，也是最后一点，仔细观摩优秀的技术演讲，用心推敲，也是提升自己演讲水平的有效途径。我们去观看技术演讲时，往往只关心“讲了什么”，而不关心是“怎么讲的”。只有自己要去演讲的时候，才会深刻体会到“原来把懂的事情讲明白”，并不是太容易的事情，不是一味堆积“干货”就可以的。
+
+既然要做好技术架构应当多学习先进经验，那么做好演讲也需要多学习先进经验：是一路平铺直叙，还是用悬念引导？是文字数据优先，还是图形表格为主？这些问题，坐在家里空想是没有用的，多去看看优秀的演讲，会让你在技术品牌的塑造上少走很多弯路。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/059技术演，有章可循.md

@@ -0,0 +1,63 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            059 技术演，有章可循
+                            你好，我是余晟，一个老程序员，一路坎坷走来，积累了些技术品牌和演讲的经验，今天，想跟大家分享如何做好技术演讲。
+
+技术演讲，是树立个人和公司技术品牌的重要手段。相比撰写技术文章，它的效果也更生动、更直接，加上现场的互动，以及后续媒体的报道，往往能给人留下更深刻的印象。
+
+但是做技术演讲也比写技术文章更难，因为做技术演讲时，你没有反复修改的机会，你必须直面观众、实时答疑，你的错误会被放大甚至广为传播…… 技术好的人未必能写得好技术文章，技术文章写得好的人也未必能做好技术演讲。不过，技术演讲也不是像天书一样无法琢磨，只靠天赋灵感，还是有一定章法可循的。下面，我就提供几条做好技术演讲的个人经验。
+
+1.严肃对待
+
+许多技术不错的人之所以做不好技术演讲，甚至讲自己熟悉领域的东西也讲不好，问题不在于技术，而在于态度。技术演讲不是把已有技术内容做点包装就可以拿出去的，通常它在两方面都有着更高的要求：1.你必须更深入思考已有的技术内容；2.你必须以空杯心态对待演讲过程。
+
+更深入思考已有技术内容，也就是“知其然也知其所以然”。或许你解决了某些问题，但误打误撞也是可以解决问题的。所以在技术演讲之前，必须反复问自己：分析思路是对的吗，查证的资料是可信的吗，掌握的数据是最准确的吗，看的书是最权威的吗……如果不是，一定要仔细查证，并且保证各环节之间的逻辑是自洽的。
+
+也许你以前花十来分钟，看了篇文章就恰好解决了某个问题，但对外讲的时候，你务必查阅各种资料，把思维的来龙去脉、概念的内涵外延都弄清楚，所花的时间可能几倍甚至几十倍于十分钟，但它是必须的。否则，如果台下观众更有经验，你可能会出丑；如果台下观众没有经验，你的演讲稿可能导致谬种流传，危害更大。
+
+以空杯心态对待演讲，也就是认清“我懂了”和“我能让你懂”是两个完全不同的问题。自己弄懂，可能和自己经年累月的思考有关，也可能需要以自己之前的知识积累做背景。但是让观众懂，而且是在演讲的几十分钟之内让观众懂，就必须把自己从“假想观众”中区分开来，哪些是自己特有的思维习惯，哪些是自己特有的背景知识，哪些是自己特有的学习方式…… 这些思维习惯、背景知识、学习方式，和典型观众有多少重合？以及，观众有没有办法在这几十分钟内倾注注意力来听取你的表达？要知道，如果你在上面演讲，观众在下面玩手机，你是一点办法也没有的。
+
+2.了解观众
+
+就像开发系统要了解问题背景一样，做好技术演讲也需要了解你的观众。通常，你需要问自己一系列的问题，比如：他们来自哪些领域、哪些公司？主要做的是什么工作？一般都有多少年的工作经验？喜欢听什么样的内容？……
+
+如果你不清楚，可以询问主办方，负责任的主办方应当会向你说明。如果主办方也不清楚，对于系列活动，你可以搜索之前活动的报道，看看相关的微博微信，了解观众的评价和反馈。如果不是系列活动，你不妨问问身边哪些人有兴趣，听听他们的看法，做个大致的判断。如果实在不清楚观众是什么样，你可能要重新考虑自己的选择。
+
+千万不要以为这步很多余。如今各公司都在强调用户画像，了解用户才能保证产品成功，演讲也是这样。如果来的都是90后，举《我爱我家》的段子来搞活气氛，估计只能导致尴尬；如果来的都是国内的初阶技术人员，过多的英文缩写、文献出处，也可能影响演讲效果。
+
+3.制作大纲
+
+不知道你有没有听说过“纲举目张”，提起渔网的粗绳一抛，网眼就自动张开了。对演讲来说，大纲就是那根粗绳，具体内容则是一个个网眼。演讲的素材固然重要，但也必须按照一定的结构和脉络组合起来。我听过的一些技术演讲，演讲者本身有比较好的技术积累，但讲得杂乱散漫，原因就在于没有大纲。
+
+好的大纲一定是重点突出的。演讲和写文章不一样，写文章有充分的时间和空间堆积材料，做到完整全面，演讲的时间却相当有限，观众的注意力更是难以把握，所以大纲一定要保证重点突出。无论你之前多么辛苦，知识多么丰富，大纲的要点只能根据演讲时间来。通常的经验是，按“每八到十分钟一个要点”的节奏来安排，三十分钟的演讲只能包含三个重点，四十分钟的演讲只能包含四到五个重点。
+
+好的大纲一定是有悬念和起伏的。我们解决问题往往是按时间顺序来进行的：识别问题、了解背景、验证方案、开发测试、部署验证。但是在演讲时，即便你敞开胸怀毫无保留，按照这个顺序来讲也未必能让观众满意，因为实在是太普通、太千篇一律了。相反，如果你先把最终结果摆出来，吊起读者的胃口，然后逐步展开，并且在其中穿插各种生动的故事，让观众先以为“如此这般”，继而恍然大悟发现并非如此。内容还是那些内容，但效果一定会好得多。
+
+4.现场互动
+
+在电视剧可以插播广告的时代，大概每10分钟左右就会播一次广告，这是有心理依据的，因为人在无外界约束状态下能集中注意力的时间大概就是10分钟。所谓“无约束”，指的是没有老师盯着，没有监视器对着，人可以随时撤出“注意”的状态。很可惜，技术演讲的观众也处在这种状态下。
+
+怎么解决这类问题？安排与观众的互动是一个相当巧妙的手段。纯粹的演讲更像是单方面的输出，一切都在按部就班、顺理成章地发生。但是互动会引入意外的因素，让听众感觉新奇，把大家已经有些溃散的注意力重新聚集起来。所以一个好的做法是，写完大纲之后，每10分钟左右留出一个空档，设计合适的互动插入进去，这样往往可以起到很好的作用。
+
+更重要的是，现场互动可以让演讲内容更接地气。有时候，演讲者讲的很好，但观众无法把演讲的内容和自己之前的经验结合起来。这时候如果有人提出有代表性的问题，就容易很好地化解众多观众的普遍困惑，让演讲的效果再上层楼。
+
+有些人喜欢安排“托儿”来互动，因为担心互动出现意想不到的局面。在我看来，除非演讲者自己不够自信，而“托儿”的水平又很高，能做到不留痕迹，否则这样搞反而会弄巧成拙。只要演讲者的准备足够充分，对待观众完全是可以以逸待劳的，很难会出现意想不到的尴尬。
+
+5.反复排练
+
+我经常讲，技术演讲其实完全不需要什么天赋，完全是个熟练工。所谓“熟练工”，就是反复练习多遍之后，动作顺理成章，不会有任何走样。
+
+你有没有在技术演讲中忘过词或者讲话磕巴？有没有在讲的过程中忽然脑子一片空白？有没有讲到后面才发现前面漏掉了一些东西？…… 这一切现象，虽然会影响技术演讲的效果，但都是正常的。它们都是在不熟悉技术演讲时的正常现象，都是可以通过反复训练加以解决的。
+
+排练要排练到什么程度？我可以提供一个大致的参考公式：如果观众在10人以下，排量一遍就可以；如果观众在30人以下，排练两三遍就可以；如果观众在100人以下，排练三到五遍。前面的每一遍排练，都要计时，都可以随时中断，把想到的可以改进的点记录下来，每一遍完成之后认真复盘，再开始下一遍排练。最后那遍排练应当忘掉计时，不许中断，相当于“上线之前的最后验证”。注意，这里说的排练，是在全部素材已经准备好，PPT已经成型的情况下进行的，不包含之前的准备时间。
+
+如果观众超过100人…… 这时候你大概不需要看这篇文章了，去看看报道，雷军、罗永浩、乔布斯在发布会之前花了多少时间排练，你会有大致的答案。你也会更深刻的意识到，做好技术演讲真不是件容易的事情，怎么重视都不为过。
+
+以上就是我总结的关于技术演讲的经验。希望对你有用，也希望你不要嫌烦。毕竟，认真对待演讲，既是对观众负责，也是对提升自己的机会负责。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/060正确对待技术演中的失误.md

@@ -0,0 +1,71 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            060 正确对待技术演中的失误
+                            作为技术leader，不论是为了布道公司技术产品，还是为了打造个人技术影响力，在公众场合演讲是不可避免的。优秀的演讲能力几乎已经成为职场升级中的一门基础技能。
+
+然而，演讲并不是一件简单的事情，对于上台表达自己，人们普遍都会感到害羞、恐惧、焦虑。对本来就苦手于沟通和语言表达能力的程序员来说，演讲更是难上加难了。
+
+不少研究都表明，在人们最恐惧的事情中，当众演讲当之无愧的名列榜首，甚至超过了死亡。即使是最伟大的演说家丘吉尔，也把当众讲话列为人生三大难事之一。
+
+许多人对演讲恐惧，是因为害怕犯错误，这种恐惧心理导致人们还没有开始演讲，就已经打了退堂鼓，心理暗示一旦发挥作用，演讲的效果就可想而知了。对此，《演讲之禅》的作者斯科特•博克顿指出，演讲中很难避免一切错误，而是要正确看待它。
+
+斯科特在书中写道：“我很清楚自己会犯一些低级错误，但在演讲中，不犯错几乎是不可能的，而且，完美的表演也会显得有些枯燥无味。因此，我不在乎完美，只在乎我的演讲实用、适宜，并能表达我的心声，而追求完美很有可能会成为它们的拦路虎。”
+
+在演讲中犯点小错误，有时并不是一件坏事，特别是对初次演讲的人来说，它能让我们对演讲产生敬畏，懂得站在台上绝非易事。好的演讲者，几乎都是跨过一个个坑而来的，比如没弄清听众需求、演讲主题老旧、啰嗦的开场白、内容重点失衡、幻灯片出错、语速过快、语调平淡、演讲超时、没有交流等等。
+
+可以说，在演讲中，错误肯定会发生，重要的是如何定位错误以及如何应对错误。
+
+1.接受不完美的演讲
+
+完美的演讲几乎是不存在的，即使你对内容做好了充足的准备，私底下也排练了很多遍，但当你站上演讲台，面对台下黑压压的一大片人群的时候，你还是极有可能会因为紧张而忘词、磕巴、漏掉准备好的内容。更不用说，如果没有做足准备，那上台之后脑袋一片空白、磕磕巴巴、词不达意也不是什么稀奇的事情。
+
+另外，演讲是一个存在交互的场景，现场的听众、环境、设备都会对最终的演讲效果造成影响。因此，要接受不完美的演讲存在，不要试图避免一切错误的发生，否则，当一些小错误发生时，你反而会猝不及防，甚至可能把小错误变成大失误。
+
+同时，也不用对自己太过苛刻，演讲中的一些小错误可能只有自己知道，听众很多时候是注意不到的。
+
+要知道你怎么对待错误，听众就会怎样对待错误。如果不小心说错一句话，你反应得像是世界末日，在台上磕磕巴巴支支吾吾，那么听众就会看得清清楚楚，视之为惨剧。反之，如果你泰然处之，视之为趣事，听众也自然会照样学样，轻轻跳过这一节。
+
+斯科特在经历一场自认为失败的演讲后，去询问观众的反馈，却发现不仅没有人在乎，而且根本就没有人发现他的失误，记住这一切的只有他自己而已。
+
+正如戴尔•卡耐基在《成功演讲指南（Public Speaking for Success）》中所说的：“演讲结束后，演讲大师常常会发现自己的演讲有4个版本：一个是他们准备要讲的，一个是他们所发表的，一个是报纸报道的，一个是讲完后反思的。”
+
+所以，接受不完美，在台上放松自己，对演讲而言反而是更好的状态，越轻松表现得越好。
+
+2.演讲前的准备必须慎重
+
+演讲不会完美，并不是你放弃准备，试图到台上自由发挥的理由。不论你是因为什么原因站上演讲台的，一旦你站了上去，你现场的表现以及所表达的观点，就会对你的个人品牌造成影响。
+
+讲得好了，听众自然会觉得这个老师特别有料，会愿意跟你做更多的私下交流，也愿意传播你的观点，这对个人甚至公司技术品牌都是很大的提升，反之则会造成对技术品牌的伤害。
+
+而要想做好演讲，前期的准备和练习熟悉是不必可少的，这个过程会耗费大量的时间和精力，那这些时间应该花在哪些方面？斯科特提出了四项建议：
+
+
+要有一个鲜明的立场。所有演讲都要有中心观点，你需要知道你的中心观点是什么。如果你还不够了解你将要讲的话题，那你一定要在演讲前解决这个问题。即使是一句“这五样东西是我所喜欢的”也表明了你的观点，因为还有无数的事物不在你的选择范围之内。每当我听到一个糟糕的演讲，我都想问演讲者：“你的演讲到底想表达什么意思？”或者“你到底想说什么？”
+认真了解你的听众。你要弄明白他们来听你演讲的原因、他们的需求、背景知识、兴趣爱好，以及他们渴望从你这里学到什么东西。若果没有足够时间来将演讲主题研究透彻，那你至少要了解听众。结果可能是你发现自己对某个课题的理解并不是很透彻，但是你至少比你的听众要了解得多。
+让观点简洁明了。如果你用10分钟才能讲清楚自己的论点，这可不是什么好事。你的论点就是一种声明，而论据则是用来论证观点的。论点必须是精炼、简明的，而论据则可能稍长，但是绝不能让听众听得云里雾里、不知所云。一个不算失败的演讲至少是立意鲜明的，而不会令观众听得稀里糊涂、毫无趣味，而一个糟糕的演讲总是让你找不到重点。
+为与自己意见相左的观点做好准备。如果你的听众专业知识过硬，他们就很有可能会与你观点相左，并在现场提出反驳意见。如果你不知道这些与你意见相左的观点，那你就无法提出好的论点，无法与对方更深度的沟通。
+
+
+最后，演讲者还需要大量的练习，那些前期不多加练习，却期待一上台就能够即兴发挥、侃侃而谈的想法是根本不现实的，必然会得到来自演讲台的深刻教育。
+
+3.演讲后的复盘必不可少
+
+接受不完美并不代表接受错误，我们要做的是在演讲之后及时复盘、查漏补缺。一般演讲都会有视频记录，我们可以回看自己的演讲录像，不要感到尴尬和害羞，这可以帮助我们客观的了解自己讲得到底如何，演讲中出了什么差错，哪些地方没有达到自己的预期，然后找出到底是什么原因导致你犯了这个错误，是否有方法可以改进，保证下次不会出现一样的失误。
+
+
+比如开场白太啰嗦，那就为自己设计一个开场白，并不断练习到产生肌肉记忆，下次演讲的时候可以不假思索的说出口。
+比如内容重点失衡，那就在准备的时候，对内容做更详尽的规划，设计出每个部分需要花费的时间，并加以练习。对技术演讲而言，可以采用“坑-解决方案-总结”这种3段式的经典结构，并将内容重点放在第二部分优化解决方案上。
+比如幻灯片出错，这种是完全可以避免的错误，除了自己检查之外，还可以请同事朋友帮忙检查幻灯片。
+比如语速过快，那就有意识的调整、训练自己，也可以在演讲中时时提醒自己要放慢语速。
+
+
+诸如此类，问题并不可怕，即使职业演讲家，也会经历失误、出丑，重要的是不断练习、不断改进，这样，每一次失误都会是一次人生财富。
+
+你呢？你在演讲中是否犯过错误呢？是如何应对的呢？欢迎留言告诉我们。感谢您的收听，我们下期再见。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/061刘俊强：技术最高决策者应该关注技术细节吗.md

@@ -0,0 +1,116 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            061 刘俊强：技术最高决策者应该关注技术细节吗 
+                            作为公司的技术最高决策者，身上肩负了很多的职责，不光有公司的技术路线图、投资标的公司的技术尽职调查以及关键技术趋势研究等战略级事务；还有工程团队文化建设、技术布道等帮助公司健康发展的关键事务；还有跨部门沟通、为其它部门提供服务能力帮助他们一起成就公司愿景等。
+
+在目前典型公司架构中，工程团队或技术团队的总负责人便是该公司的技术最高决策者，那么本文要讨论的技术最高决策者就是 CTO（首席技术官）或 VP of Engineering（技术副总裁或工程副总裁），这个一般根据公司的实际职位设置情况来，本文默认 CTO 为技术最高决策者。
+
+技术或工程团队日常工作中会有很多的技术细节类工作，例如技术框架选择、高可用架构设计以及持续集成等，那么一般困扰我们的是，作为技术最高决策者跟这些技术细节的边界是什么？是否应该关注这些技术细节？
+
+我接下来将先简单梳理下CTO的工作职责内容，然后我们再看是否应该关注技术细节，在本文阅读完毕后，希望你自己也能够根据现状进行思考。
+
+CTO 的使命与职责
+
+CTO 的使命我们可以从三个维度来进行说明：长期的技术战略、技术布道者以及工程团队文化建设，里面仅第三项是完全的对内事务，前面两项都是内外结合型事务。接下来我们将分别来看看这三个维度的使命是怎样的？
+
+CTO 的使命——长期的技术战略
+
+
+CTO 必须不断推进、阐述并坚持公司的技术战略方向；
+CTO 需确保公司在激烈变化的竞争下持续提供最佳技术；
+CTO 需要通过信息获取提取来指引支持公司下一步发展的关键趋势，从而将外部世界与公司内部联系起来，实现业务和技术战略之间的适当平衡，使得公司的技术战略与其业务战略保持一致。
+
+
+CTO 的使命——技术布道者
+
+
+CTO 必须围绕公司的长期愿景来激励内部人员，并向外部表达并使他们相信世界或行业未来发展方向，而自己的公司是带领大家抵达未来的最佳选择；
+CTO 必须对市场需求具有权威性，必须对客户可信，并且能够向各类的受众阐明公司商业价值和投资回报率。
+
+
+CTO 的使命——工程团队文化建设
+
+CTO 负责一个公司的技术或工程团队，那么如何建成健康的工程团队文化便尤为重要。
+
+
+CTO 必须团结起来工程团队，来实现公司的长期技术目标；
+CTO 必须能够激励新员工加入工程团队，并且帮助找到渠道并识别合适员工；
+CTO 必须帮助建立和维护工程文化，以确保公司能够持续留住和吸引顶尖技术人才。
+
+
+上面我们提到了CTO的使命，从三个维度共8个要点进行了说明，希望大家能够对 CTO 的使命有些了解。如果我们要看作为公司技术最高决策者是否应该关注技术细节这个问题，我们还需要看下CTO对公司内部各组织的具体职责是怎样的。
+
+一般分为以下5个主要组织或团队：CEO 或战略、工程/产品、销售、商务拓展以及市场营销。下面将针对这CEO或战略、工程/产品两个团队阐述下 CTO 的一些主要职责：
+
+CTO 对内主要职责——CEO 或战略
+
+
+预测可能对公司产生重大影响的任何技术拐点，并且保持领先；
+根据公司长期技术战略，向 CEO（以及 CFO/COO）就公司的大规模技术投资时机和机会点提供建议；
+为 CEO 提供有关公司技术方向的不同”选项“，并提供足够的决策依据信息，以确保在任何给定时间都是最佳技术选择；
+
+
+CTO 对内主要职责——工程/产品
+
+
+虽然 CTO 不需要为产品日常交付情况负责，但也应该与产品或工程副总裁密切合作，以确保整体发展方向与公司的战略技术保持一致；
+CTO 应该确认在既定技术战略下，公司技术资源投放的优先级，并交给工程团队予以执行；
+需要帮助技术或工程副总裁集思广义，了解工程团队面临的各种挑战，在很多方面，CTO 和工程副总裁需要保持联系；
+持续优化整个组织，以达到技术资源最合适的收益比；
+确保工程团队在壮大的同时，保持技术的一致性，并在必要时进行技术仲裁；
+建立合适的创新机制，例如黑客马拉松或内部孵化计划；
+帮助招募和员工留存工作。
+
+
+是否应该关注技术细节？
+
+本文前面说了很多关于CTO的使命与职责，那么作为技术最高决策者是否应该关注技术细节呢？在此先说结论，符合其使命和职责方向的技术细节需要关注，此外的技术细节不必要关注。接下来本文将阐述此结论的由来以及会举证一些事例便于理解。
+
+CTO 全称为 Chief Technology Officer（首席技术官），重点要注意的是 Officer，也就是高级管理者的角色，首先需要对公司的长期技术战略进行负责，保证公司在技术拐点产生时能够作出正确的判断并制定应对策略。这样就需要 CTO 对外部世界的技术动向和趋势能够收集到足够的信息并进行分析整理，从而得出结论。
+
+例如 2007年6月苹果公司发布了跨时代产品——第一代 iPhone，成为了移动互联网发展元年，之前 Symbian 系统的智能手机更多的还是基于 WAP 网络，iPhone 全触屏体验、高速好用的内置浏览器、全新的智能手机操作系统 iPhone OS 以及应用商店体系给行业带来了翻天覆地的变化。
+
+CTO 需要了解 iPhone 的详细产品功能以及技术规格等技术细节，并对 iPhone 相关移动网络技术进行调研，从而来分析判断 iPhone 及移动互联网发展趋势，来看公司的技术战略是否需要进行相应调整。
+
+我们现在回顾移动互联网过去10年，是几家欢喜几家愁，有些公司借着移动互联网技术东风发展迅猛，有些公司没有及时调整战略进而发展受限甚至慢慢衰退，比如之前超级依赖短信 SP 的公司。
+
+移动互联网的技术拐点来临的时候，我亲身经历过技术趋势分析和公司技术方向调整，当时公司在2007年开始做移动互联网方向的尝试，因为我分析认为未来的趋势是基于手机的移动互联网，只是当时是基于 WAP 和 Symbian 系统来做的，体验和能力都不好，因此决定先做互联网 Web 2.0 方向项目。
+
+在同年 iPhone 发布后，研究后觉得 iPhone 走的方向是智能手机未来（当时国内 3G 牌照尚未发放），决定投入少量人力研究和保持关注 iPhone OS，次年苹果公司发布了 iPhone OS SDK 1.0，我们就立马组建了 iPhone 客户端团队进行移动互联网应用开发。由于国内 3G 牌照未发放，当时相应的一些 3G、GPS 测试就到香港和深圳进行，由于我们在移动互联网方面的提前布局，也帮助公司顺利拿下下一轮投资。
+
+前面有提到 CTO 需要在外部激烈竞争下保证公司使用的是最佳技术，这里的“最佳技术”并非是指最为花哨或最为前沿的技术，每个公司有着自己的业务背景和历史债务问题，选用对于公司技术资源投入产出比最高，且为符合日后技术发展趋势的技术方案才是“最佳技术”。
+
+那么这里我们以火热的技术架构设计风格——微服务——为例说明下。众所周知微服务架构设计风格并非只是技术上的，如果要在公司中选用的话，需要具备持续集成/持续发布的实践基础，同时要对企业组织架构进行相应调整，那么作为 CTO 需要针对微服务架构设计风格对于公司选用的收益及风险进行评估，以及需要来看跟公司业务发展方向是否一致，这样的微服务相关的技术细节是需要 CTO 进行了解和关注的，这样才能够尽量作出正确的判断。
+
+前面用行业新产品带来的大趋势或技术拐点以及新技术架构趋势的例子，来说明哪些技术细节是技术最高决策者应该关注的，那么反例有哪些，也就是哪些技术细节不应该被关注？
+
+作为 CTO 不应该将时间投入到产品日常迭代和编码这样的技术细节中，例如具体技术框架选取、架构方案设计以及代码评审等，其中亲自上阵写代码是最应该被禁止的。为何呢？因为每个人的时间都是有限的，CTO 需要将时间更多的花在跟公司未来、技术趋势以及商业拓展相关的事情上。
+
+上述具体技术事务应该有技术副总裁和技术总监来进行完成，CTO 需要提前做好指引工作，跟工程副总裁制定好技术方向原则，以指引工程团队具体工作。
+
+有的 CTO 会参与到具体执行工作中去，一般的理由有“团队小”、“该领域我是专家”、“这项工作团队其他人的交付速度与质量不如我”，其实这些理由后面恰恰对应的待解决的问题，例如：
+
+
+“团队小”：需要反思这个阶段是否需要 CTO 这样的职位，或者给予技术联想创始人更为合适，或是招募优秀团队成员加入；
+“该领域我是专家”：需要将知识经验分享给团队成员，或是招募该领域其它专家，因为你自己很容易成为单点，这样是很危险且不负责任的，如果你持续这样想，另一种可能是你并非适合 CTO 职位，或更为适合首席架构师；
+“这项工作团队其他人的交付速度与质量不如我”：意味着没有招募到合适的团队成员，这个问题应该被纠正。
+
+
+写在后面
+
+作为公司技术最高决策者首先需要明确自己在公司承担什么职责，这样才能够清楚怎样的技术细节是应该关注的，哪些技术细节是不需要关注的。正如前面所说的结论 “符合其使命和职责方向的技术细节需要关注，此外的技术细节不必要关注” ，使命和职责是需要先明确的。
+
+本文是以 CTO 的角色来进行的说明，那么实际工作中的情况可能会不一样，例如公司没有 CTO 仅有工程/技术副总裁，这样的时候就需要重新来明确使命和职责，再确认技术细节的边界。
+
+总而言之，技术最高决策者需要明白的是，这个岗位的职责是要为公司业务发展及未来负责的，因此技术细节边界的确立有助于更好地分配时间来帮助实现公司愿景。
+
+作者介绍
+
+刘俊强（微信公众号：程序员精进）现任腾讯云资深架构师，TGO 鲲鹏会深圳分会董事会成员，小组委员，曾任迅雷技术总监、某互联网公司技术副总裁，10+年以上互联网开发经验，8年以上技术管理经验。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/062张溪梦：技术领袖需要具备的商业价值思维.md

@@ -0,0 +1,83 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            062 张溪梦：技术领袖需要具备的商业价值思维
+                            你好，我是GrowingIO 创始人兼CEO张溪梦，今天想跟大家分享的话题是“在高速成长、竞争的市场里，技术领袖如何帮助企业产生最大规模的价值”。
+
+先来看什么是Growth？Growth is connecting more people to the existing value of a product。这句话里有两个非常重要的部分：第一，产品必须有核心的价值（existing value），我们必须要有一个核心的产品价值能够传递给我们的用户，这是所有增长的核心。第二，连接，让更多的用户和既有产品的价值进行关联和挂钩。
+
+Gartner在2017年发布的调研表明，在全球顶尖的公司里，至少有25%的业绩是由企业内的CTO或者CIO通过创新或技术优势，直接转化为财务结果、客户优势和市场份额，实现增长。
+
+Gartner调研的一般都是大规模企业，在这种大型企业里，技术或者说IT往往被定位成一个更偏支持的部门。三年前，Gartner的调研显示CEO对技术最高的期待是数据化。近两年，对于CEO来说，最高优先级的工作是增长，而第二位就是如何用技术来变革企业内部，产生更大规模的增长。
+
+在这样的背景下，对技术领袖也提出了更高的要求。
+
+1.思维的进化：以支持各部门为中心（Focus inside the wall）—以客户为中心（Focus outside the wall）
+
+很多时候，我们的思维还停留在墙内，以支持各部门为中心，做的更多的是满足各个不同部门的需求。但在当今阶段，真正有技术领导力的领袖必须要到墙外去关注客户，去以客户为中心做事。
+
+回国创业这几年，我发现即使是为客户服务，我们的产品、技术也是从造榔头开始，而不是去思考用户身边还有哪些钉子需要解决。
+
+技术领导者必须要以客户未被满足的需求为主导，去思考技术创新和解决方案。否则，我们所创造的产品的价值影响力就会很低，它对这个世界的影响及带来的转变也会很低。
+
+未来，技术领袖的关注焦点一定是从公司内部转向公司外部，从以支持各部门为中心到以客户为中心的思维进行转化。
+
+那以客户为中心需要考虑哪些要点呢？
+
+
+客户是谁？
+客户未被满足的需求是什么？
+如何用我们的技术、产品，来大规模的满足这种的需求，解决客户的问题，同时拉动自己的业务增长。
+
+
+这是第一个趋势，要求技术领袖从纯技术导向的思维转变为客户导向的思维。
+
+2.技术领导力的进化：研发的能力（I can build everything）—整合的能力（I will leverage others）
+
+过去的十年里，特别是我早年在湾区工作的时候，大部分软件都是企业内部自研的。以领英为例，分布式消息系统Kafka就是领英自己研发的。因为领英是一家数据驱动的公司，需要工具来处理大量的数据，但当时市场上并没有这样的解决方案，所以工程师们只能自己动手，花了大量的时间开发了Kafka等一系列的工具产品。
+
+但在今天，如果我们想提高效率，真正把技术投入在最能满足客户需求的聚焦点上，我们就不能再保持过去这种Build Everything的思维，而是要具备一种整合能力，即Leverage不同的工具和技术，迅速组合成新的产品和服务来支持业务增长的能力。这种能力对不少CTO、CIO、技术领导者而言是一种新的挑战。
+
+还是以领英为例，八年前我刚加入领英的时候，领英使用的外部工具非常少，基本都是内部自研的，但到我离开的时候，公司里已经集成了近两百种不同的SaaS服务。这些SaaS服务，在某种程度上解决了公司内部的运营、营销、财务、客户管理、数据管理等诸多问题，公司能够把所有精力都放在增长核心业务上。
+
+我在领英待了五年，这五年里它的业务增长了接近40倍，其核心原因之一，就是能够善用这些产品和工具来提高内部的效率，做到高速的增长。
+
+这是第二个趋势，要求技术领袖从Build Everything的构建思维转变为整合的思维。
+
+3.视野的进化：仅聚焦某部门或职能 （Biz function focused）—连接企业各部门（Cross enterprise）
+
+以前，技术更关注的可能是如何支持公司内部某个部门的需求，在大部分的公司里，技术也被定位为更偏向于支持业务的部门。但本质上，我认为技术是企业内部连接所有部门的第三种力量。
+
+那其他两种力量是什么呢？第一种力量是财务，第二种力量是人力，这两种力量是能够打通企业内部所有部门的。而未来十年、甚至五十年真正能够引领变革、穿接所有部门的第三种力量是科技。技术能使企业内部体系的运营效率得到大幅度的提高，对外能更好的服务客户。
+
+想要提高内部效率或产出，我个人认为是无法靠招聘大量的人力来解决的，而是要有效的打通内部企业的各种系统、流程，这一过程就需要我们在技术上有很大的创造力、很高的执行力及整合力。
+
+这是第三个趋势，要求技术领袖进化视野，让技术具有连接企业所有部门的能力。
+
+4.角色的进化：关注交付、实施和执行（Keep the lights on）—商业战略导向（Strategic partnership）
+
+即使在很多技术占主导的公司中，技术还是要跟着产品、业务往前走，它会更关注执行，保证系统不会宕掉、提高开发效率、交付更好的业绩等。
+
+但我个人认为，过去的十年里世界经济的高速发展，其中一大部分都是技术创造出来的新增GDP，而不是因为全球人口的增加。
+
+因此，一个好的技术领袖，要变成一个战略思考者，而不只是一个战术执行者。战略思考者就要求我们的创新必须具备产品化的思维，做的东西要能够吸引很多用户。无论这种用户是行业里的客户，还是企业内部的各种部门。
+
+这是第四个趋势，技术领袖必须转变成商业战略导向的思维，通过解决业务的问题，拉动增长，完成创新-战略-执行-结果的过程，更要从单纯的战术执行者转变为Strategic Partnership，和公司的CXO们一起为，企业的增长做出各种准备和努力。
+
+最后想跟大家分享一下可口可乐的例子，2017年初，可口可乐取消了首席营销官CMO职位，取而代之设立了首席增长官CGO这一职位。
+
+大家知道，可口可乐市值约700亿美元，其中品牌价值约为620亿-640亿美元，几乎占到了这家公司整体价值的90%。可口可乐在过去近一百年的时间里，都在引领全世界营销的变革和趋势，而CMO这个职位正是它在25年前引领型地创造的。如今，也是它走在前列，用CGO代替了CMO。
+
+以前CMO主要管营销，如今CGO会管所有的业务线，除了营销之外，还会管理新品研发、创新、数据等。这意味着所有的技术领袖都有巨大的机会成为一个企业的首席增长官。
+
+去年，Forrester研究表明，全球100强企业中大约5家公司设有CGO，今年，它预测世界100强企业中至少会有8家新的公司设立CGO。这意味着在未来，很多技术引领者将有很高的可能性变成公司的二把手或者一把手。
+
+因为，如果未来增长是通过技术和产品来驱动的，那么公司的第一把手就应该是技术领袖和产品领袖，而不只是一个做营销的人。
+
+本文整理自GrowingIO 创始人兼CEO张溪梦在GTLC全球技术领导力峰会上的精彩分享。在创立GrowingIO之前，张溪梦曾任LinkedIn美国商业分析部高级总监，创建了LinkedIn近百人的商业数据分析和数据科学团队，也被美国DataScienceCentral评选为“世界前十位前沿数据科学家”。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/063未来组织形态带来的领导力挑战.md

@@ -0,0 +1,61 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            063 未来组织形态带来的领导力挑战
+                            当我们谈论领导力的时候，一定要考虑到当前所处的时代，相比之前，如今的互联网更加垂直、个性和人性化。市面上有很多Web1.0、工业4.0时代出版的管理书籍，里面涉及到术的层面的内容很多，有着各种各样的管理方法，但那些方法拿到现在已经不太好用了。大家有做管理的话，可能会发现用原来的方法管理员工，好像没那么灵了。
+
+VUCA 时代
+
+有社会心理学家认为，新技术的发展速度远远超过了社会人文的发展速度，导致人们的人文观念、价值观和行为方式在新技术的革命浪潮中无所适从，很多被证明行之有效的范式和秩序正在被颠覆。
+
+有个概念正是描述这一情况，即VUCA。何为VUCA？V是Volatility，代表易变性；U是Uncertainty，代表不确定性；C是Complexity，代表复杂性；A是Ambiguity，代表模糊性。
+
+也就是说，如今，世界已经进入VUCA 时代，我们正面临一个易变的、不确定的、复杂的、模糊的世界。在这样的VUCA时代，不知道接下来会发生什么、也不知道如何来做应对的准备，每个组织与个人都有一种对未来不确定的恐慌感，长远规划越来越成为不可靠的事。
+
+以3D打印为例，不知道大家对3D打印当年的热潮是否还有印象？2013年的时候，3D打印是一个大风口，除了媒体炒作、资本追逐之外，国家也大力扶持，甚至认为3D打印除了民用领域之外，还可以用在航天领域。当时全球有两家3D打印相关的公司，市值加起来超过了100亿，但仅到2013年底，两家公司的市值就跌了80%，这个巨大的变化是很多投资者包括群众都没有想到的。这就是易变性的一个表现。
+
+在VUCA中，对领导者来说，最难的就是模糊性。如今，大家可以在一定程度上在自己的认知范围内，有一个短周期的预判，但对于大的经济环境和形势缺乏预判能力，没有办法很清楚地去做战略规划。因为社会变化太快，机会到处都有。
+
+这种不确定的时代，企业需要适应时代要求，不断自我变革与创新，其中最难的、最深层次的变革就是组织与人的变革。而对领导者的要求就是要敏锐感知影响组织与人变革的因素，洞见组织变革的趋势，使组织有前途，工作有效率，人才有活力。
+
+人性与需求
+
+关于人的变革，面对时代的差别，我们主要看什么呢？是思维。而思维又可以从人性和需求两个层面出发去改变。
+
+第一，讲思维时看人性。传统认为人性是非黑即白的，但现在没那么容易区分了，而且善恶是动态发展的。
+
+同一个员工，可能在A公司工作表现、工作态度等诸多方面都不好，但跳到B公司后可能就截然不同。我们就流失过这样的员工，在公司时我们恨不得马上把他开掉，他也觉得不受待见，就跳槽去了旁边的公司，结果在那家公司表现非常好。
+
+我私下约他出来聊天，他说在那儿Leader信任他，同时给他空间，而在我们这儿不被重视，每天被卡得死死的，这儿不行那儿不行，很多项目很努力地做完后连一句表扬的话都没有。
+
+第二，讲思维时看需求。大家都知道马斯洛的金字塔，常规来看，我们在公司里面讲需求，会先看是不是满足员工最基本的生存、舒服、安全等需求，然后再一级一级往上看。但是现在是混序的需求，作为Leader，就需要能够鉴别员工的需求在什么地方？哪个需求对他而言是最重要的？经济有时候不再是他们的主流需求，其他情感、归属、自我实现等方面的需求反而可能会浮现出来。
+
+因此，我们要从人性和需求的角度出发，用动态的或生态的思维去看待人才。
+
+未来的组织
+
+除了人的因素之外，组织是领导者在这个复杂多变的时代需要去敏锐感知的另一个因素。那未来的组织变革有哪些特征呢？
+
+如今的组织，不管是IBM还是谷歌，它们都有一个边界。在公司里，我们做一个项目，会去找技术、产品、销售等各个方面的人组成团队，这些人都是同属一个公司的员工。
+
+但在未来的组织中，工作形态及组织形式可能有一些变化，会大幅度减少人跟人之间的关系绑定，部门之间的边界也变得越来越模糊，人才共享成为新常态，大量随需而动的“云团队”不断涌现，增加了组织的敏捷性。比如很多企业开始尝试的项目制，就是这种组织形态的一种体现。
+
+而这需要人才能够拥抱变化，随时能够换部门、换老板、换任务、换同伴、换KPI，对人的环境适应性提出了很高的要求，也对领导者提出了更高的要求。
+
+此外，公司外部的人才共享也将成为可能。举例来说，在座的400位中，只有第一排的同学是全职员工，剩下的都是市场流动人才。当我决定做一种智能翻页器时，第一排的全职员工负责供应链、材料、软件等方向，然后由他们去市场上找到合适的顶尖的人才，于是产生了人才投标。通过这种方式会产生一些真正可以中标留下来的人才。而这些不断通过人才投标，总能留下来的人才，或者总能拿到项目的人才就叫做头部人才，他们会拿到市场上几乎80%的机会。剩下的人就变成要抢剩下的机会。
+
+这对于企业的好处在于，企业将永远能够拿到市场上更好的资源，而且不用花费大量的人力成本。
+
+在这样的组织形式下，首先，未来组织最重要的职能将变成赋能，而不再是管理或者激励，当然现阶段还是激励对团队来说更重要。
+
+其次，未来的团队将偏向小而美，取得的成果跟团队规模没有任何关系，而是跟人才质量和人均效能有关。例如，现在公司有一百人，这一百人的产出能不能实现真正的最大化？几乎没有公司这么算过，只是感觉员工很努力了就可以了，但是如果算一算，就会知道其实很多员工相当于是在浪费公司的时间或者金钱。
+
+最后，未来将有全新人才的配置方式，当人才共享成为常态之后，自然会对领导者的能力提出更高的要求。举例来说，第一，如果未来是有少部分人是全职员工，我们自然希望留下的是最好的人才，那么对于Leader来说，如何留住这些顶尖人才就成为一大挑战。第二，如果以之前提到的项目制的方式工作，除了少部分全职员工之外的大多数人都是市场流动人才，之前跟Leader并没有关系，那他们去了公司以后，作为Leader该去如何影响、领导他们并与他们沟通，这些对于Leader来说也是非常大的挑战。
+
+本文整理自TalentX咨询公司创始人兼CEO Tina Jiang在GTLC全球技术领导力峰会上的精彩分享。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/064如何判断业务价值的高低.md

@@ -0,0 +1,62 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            064 如何判断业务价值的高低
+                            众所周知，决策是在一定约束条件下，为实现个人、团队或企业目标而按照一定程序和方法，从备选方案中择优选择一个最合适方案的过程。
+
+因此，任何决策都要作出某种选择，而选择是否正确，取决于对决策对象的认知和价值判断是否正确。决策离不开价值判断。
+
+软件开发行业也是如此，特别是在敏捷开发中，很多时候都是根据业务价值来决定特性或故事的优先级排序，可以说，业务价值是敏捷观念的核心。
+
+为什么关心业务价值
+
+那么，人们为什么要关心业务价值呢？Joe Little梳理了四个原因。
+
+原因一，这个世界上有无数有趣的事情值得去做，所以，问题就不在于是否能找到有趣的事情去做，而在于决定哪些是最重要的需要去做的事情。这正是我们关心业务价值的原因之一，人生苦短，总要去做一些“真正有意义”的事情。
+
+原因二，业务价值有利于保证团队成员共享一个一致的目标，来判断他们的行为是否正确。可以说，业务价值调动了团队成员的自然动机，并给了他们一个基点，可以将与团队工作相关的任务按照自然的顺序进行排列（比如谁做什么，系统架构怎么做等）。
+
+原因三，在软件这个充满了变数的混沌世界中，把握业务价值可以给人一种处变不惊的魄力。变化是永恒的，这包括人们的遗忘、客户群体的变化、客户需求的变化、之前的评估渐渐失效等等。但只要我们对业务价值有适当的理解， 它就可以在这变化的漩涡中充当一个恒定的标杆。
+
+判断业务价值的高低
+
+那如何判断业务价值的高低呢？Pascal Van Cauwenberghe认为，如果是先编写用户故事，然后再估计它们的业务价值，这一做法会存在严重的缺陷，因为我们很有可能在前期浪费大量时间在低价值甚至是零价值的用户故事上。
+
+好的做法是首先回答这个问题：“我们如何才能找到传递了业务价值的用户故事？”这显示了一个不同的过程，即我们需要首先定义我们打算实现的业务价值，然后生成那些有助于业务价值实现的用户故事。
+
+落地到具体执行过程中，可以按以下步骤来进行：
+
+
+在开始一个项目或者产品之前，我们首先要决定想要实现什么样的价值（或者利益）；
+要找到并改善传递价值的业务流程；
+要找到并改善使得传递价值的过程有效的辅助业务流程；
+当团队需要用户故事的时候，采用上述步骤中积累的价值最高的流程，然后针对团队的需要以正确的粒度将其分解为用户故事。
+
+
+而实现这些业务流程的用户故事显然有助于业务价值。
+
+然而，尽管大家都知道业务价值、以及依据业务价值做决策的重要性，但在实际的项目过程中，我们依旧会遭遇各方面的挑战，比如：需求来自多个方面，每个业务人员都将解决自己的问题视为首要优先级事项；领导拍脑袋提出的不合理要求极有可能会打乱原有计划。这样被动的需求接收模式让研发团队很难坚持进行业务价值判断。
+
+对此，姚安峰认为，我们在执行中应该换一个方式。首先，包括技术、PO、业务人员在内的项目团队以及其它相关利益者需要共同理清产品的愿景。也就是要弄清楚为什么开发这个产品？对它的期望是什么？什么是这个产品主要的卖点？相比旧的版本或其他竞争对手，这个产品能带来的改进或差异化竞争力在哪儿？是不是项目相关的各方人士都理解并认可该愿景？该产品的愿景是不是与组织战略方向一致？
+
+明确了愿景后，我们就要对如何达成这个愿景进行规划，产生演进路线图。任何产品都有一个从探索到消亡的过程，都将遵循产品生命周期法则。比如一个在线教育应用，当前的目标是在6个月内发展一定用户基础并获得反馈。那在这个阶段，一个吸引人的用户推荐系统是不是更有助于实现目标？一个健壮的会员管理功能呢？一个完善的收费会员体系呢？显然有不同的答案。
+
+产品生命周期决定了在不同的阶段产品应该有不同的策略，从探索期，发展期，成熟期，直到衰退期，“业务价值”的内涵是一直在改变的。而产品规划是预测性地对这些阶段进行设计，并制定每个阶段应该采取的策略，这其中就包括每个阶段的价值取向。更进一步，大的阶段还可以分为一系列连续的小阶段、小目标，比如每个季度或每个月都应该有一个产品要达成的关键目标。
+
+有了团队一致认可的阶段性目标后，当团队分析一个特性或故事时，基本只要看它们与目标的相关性就可以了。只有与该目标强相关的特性或故事才能被优先纳入版本计划或迭代计划中，而与目标不强相关的优先级就往后放。如果这样做出来的计划大家认为不合理，那就要回去重新审视之前设定的目标是否不恰当了。产品的特性或故事是否符合产品规划、是否符合当前的阶段性目标是进行“业务价值”判断的最重要方法。
+
+在基于阶段性目标进行“价值”判断时，建议从“是否不可替代”的角度进行思考，即对每一个特性或故事都问问自己：如果暂时不实现它，我们想要进行的探索能否达到目的？想要改造的业务流程能否实现？用户的期望能否得到满足？是否可以暂时采用其它替代的手段达到同样目的？
+
+如果我们每一次都把目标设定得足够小，这样的思考就可以帮助我们排除很多暂时价值还不够高的工作，从一堆看似都和当前目标相符的特性或故事中找出真正价值最高的部分，从而更快将一个版本交付出去。
+
+总结
+
+上面分别谈了谈进行业务价值判断时需要认真思考的几个角度。可以看出，进行价值判断需要考虑很多因素，但如果为了避免判断错误却花过多时间进行讨论，而迟迟不去实践，反而会错过实现价值的机会。在互联网和传统企业都努力追求创新的的今天，需要的是快速迭代与反馈验证，以及基于反馈的快速调整；而所谓准确的预测、判断并不能有效避免失败，只有基于快速反馈验证的迭代式演进才能降低可能失败的风险。
+
+最后，需要注意的是，所有这些分析和判断都是在特性或故事被实现之前进行的，是一种预测。而预测是导致绝大多数失败的恶魔，只有实践才是检验真理的唯一标准。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/065如何打造高效的分布式团队？.md

@@ -0,0 +1,68 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            065 如何打造高效的分布式团队？
+                            在如今全球化趋势下，因为业务需要或人才竞争，许多互联网公司都建立了远程团队或者说分布式团队。但分布式团队在日常工作中确实会面临许多问题，需要付出更多的努力来克服距离带来的内在挑战。
+
+挑战一：如何增加分布式团队之间的熟悉度和亲密感？
+
+Doximity工程部门副总裁Bruno Miranda表示，和队友尽快建立个人联系非常重要。我们会要求新员工至少第一周要来办公室，和总部的团队见面，一起吃午餐，最重要的是和他们的导师建立个人联系。我们也鼓励远程员工不时地来办公室，这样的线下碰面对各自的团队都是有益的。
+
+另外，我们每个季度都会抽出几天时间把团队成员聚在一起，回顾之前的工作，分享经验教训，提前规划下季度的工作等。这样每季度一次的聚会也让我们有时间进行面对面的团队建设，如滑雪、骑马等，高质量的休闲时光，也强化了同事之间的个人联系。
+
+除了面对面的团建外，我们也鼓励各地的员工在线上围绕感兴趣的话题进行即时交流。话题可以非常宽泛，从滑雪到游戏再到音乐都可以。这类对话通常是和业务不相干的，只是提供一个非正式的讨论媒介，让人们有个地方可以增进个人关系。其作用有点类似于公司里的茶水间，为人们增进关系提供了一个舒适的地方。
+
+Passive Management公司创始人Janis Janovskis表示，关键是要强调沟通的重要性，鼓励人们将他们当前的状态分享给他人，例如他们是感觉受挫、焦虑或是快乐等等；也要鼓励团队成员将他们的状态变化告知其他人，例如他们是打算去吃午餐或是去倒杯咖啡。在办公室中，彼此能看到的一切状态都是透明的，但对于远程团队来说，就必须通过一些沟通协作工具分享自己的状态，来保证成员间的亲密感。
+
+另外可以增加虚拟的线上聚会，比如视频会议，但尽量不要为了某些平淡的话题而进行视频会议，而是要仔细挑选主题，比如让团队中的某人为某个有趣的话题准备10-20分钟的演讲。甚至可以选择一些主题让成员轮流演讲，给团队中的每个人都有发挥的机会。
+
+挑战二：如何做好分布式团队的项目管理？
+
+Bridge Global创始人Hugo Messer表示，前提是要让分布式团队的成员都清楚他们正在执行的项目。然而在现实中，我们会发现很多远程团队对他们正在搭建的产品完全不了解。对此，我们可以问自己和团队成员以下几个问题：
+
+
+是否位于所有地方的团队成员都了解业务层面的产品愿景和项目情况？
+是否每个人对产品的定义都相同？
+是否所有团队成员都参与到了制定产品愿景、创造项目路线图和backlog细化研讨会中？
+产品愿景和项目路线图是否对身处各地的所有团队成员都可见？
+是否所有团队成员都直接与业务相关者和用户紧密合作？
+
+
+作为管理者，我们可以通过各种项目管理工具、协作工具将产品内容和项目进度与分布式团队成员共享，更要有意识的让他们了解更多有关项目和产品的信息。
+
+敏捷专家Tanya Kumari则表示，要制定一个连接各团队的项目路线图。分布式团队意味着成员所处的空间甚至是时间不同，这让计划变成了一项挑战，因为你无法像了解身边的团队那样了解一个远程团队。
+
+因此，我们需要制定一个项目路线图来传达行动计划，不管团队成员身处何方，都可以通过这个路线图来了解项目或产品是如何随着时间推进、演化的。在这种情况下，类似滚动计划这样的方法就可能更有效，对于时间上比较近的事情就详细地计划，而时间上比较远的事情就做大概的规划。
+
+这样一份在多个团队之间共享的计划将为团队的日常工作提供一个关键的上下文，并对竞争环境的变化作出响应。我们所要做的是把它分解到月、周、天，定义每天的可交付物，对于最终目标的实现负责。
+
+Kumari还表示要打造有意义的自动化。当项目时间比较长，或者需要管理远程团队时，创建一套自动化流程就特别有价值。自动化可以从多个方面节省时间：它可以快速跟踪整个交付过程并报告这个过程，让过程尽可能地高效、简洁，并赋予参与者责任感等。
+
+如今，不少厂商都提供了构建自动化流程的工具，不过投资一种综合性工具，可以减少不同过程中需要的工具，确保过程不会重复。例如，Jira就是团队规划并构建优秀产品的一个跟踪器选项。许多团队选用Jira捕获并组织问题、分配工作及跟踪团队活动。
+
+以奥迪为例，奥迪在全世界雇用了数以千计的工程师、设计师、软件开发人员和QA团队，办公室遍布全球，但它的研发中心（R&D）都在德国。2007年，他们开始用Jira跟踪问题，并用Confluence管理知识，如今，这两个工具被用来支持所有的团队和项目。例如，在路试场所，测试人员在试车过程中会把软件缺陷记录进Jira中。而除了跟踪外，团队会使用Confluence存储文档、部门协议、会议记录、政策法规等，帮助企业保持高效、透明。
+
+除此之外，还可以使用Google Drive作为文档库，进行文件共享；使用Bamboo、BitBucket等作为版本控制工具监控和推送代码；使用Slack进行实时、有感染力的谈话，以便快速进行评审、修改、决策等。
+
+挑战三：如何解决沟通协作问题？
+
+如今，技术不断发展，视频会议、屏幕共享以及异步通信的广泛应用帮助我们实现了这种便利的工作环境。Bruno Miranda表示，他们在测试了六种解决方案后，最终选择了一套自己觉得效果最好的技术。
+
+
+视频会议：我们的会议室中都配备了ChromeBox、会议系统和一个大型的壁挂电视。ChromeBox直接集成了谷歌日历，让参与会议变得轻而易举。我们以前试过其他的系统，如Skype和HighFive等，但对于我们来说，它们未能提供与谷歌日历的稳定集成。
+异步聊天：市面上有不少聊天工具，我们选择的是Slack，因为它提供了我们需要的集成，可以把工作统一到一个平台上，包括来自DevOps栈的警示讯号、日历提醒、自动回复等。
+屏幕共享：在促成分布式沟通方面，屏幕共享无疑是其中一项比较显著的技术改进。不管我们是在帮助同事解决一个配置问题，还是结对编写一段比较难的代码，亦或是仅仅共享一个幻灯片，可以快速共享屏幕的能力会让整个过程变得更愉快。Slack内置了语音电话和屏幕共享，它甚至允许任意一方控制另一方的屏幕。
+语音呼叫：异步的文本聊天很有效，但对于沟通来说，文字并非最有效、最直接的方式。我们测试了几款在线语音呼叫工具，最终还是选择了Slack，因为它已经是这个工作流中不可或缺的组成部分。Slack让我们有能力从文本聊天快速、无缝地转到语音呼叫，再到屏幕共享，再到视频。
+
+
+除了以上提到的这些，市面上有很多不同的沟通协作工具和技术，包括国内的Tower、Teambition、明道、钉钉等，大家可以在尝试后，根据自己公司或团队的业务特性选择最适合自己的沟通协作方式。
+
+结语：打造一个高效的分布式团队存在一定的成本和学习曲线，但业务需要和人才竞争让分布式团队变得越来越普遍，因此，对于技术管理者来说，如何不断改进流程，建立高效的分布式环境，让信任、协作和创造性流行起来，已经成为管理中的必修课。
+
+那么你是否在管理分布式团队呢？你是如何让团队高效协作的呢？欢迎留言与我们探讨。感谢你的收听，我们下期再见。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/066如何打造有活力、持续创新的研发团队？.md

@@ -0,0 +1,111 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            066 如何打造有活力、持续创新的研发团队？
+                            你好，我是运满满CTO王东。今天想跟跟大家分享的主题是如何打造有活力、持续创新的研发团队。
+
+运满满是一个车货匹配的货运调度平台，也提供很多增值服务，整个行业非常大，发展非常快，因此对技术和团队也提出了很高的要求。
+
+在具体的执行中，我们花了大量的心血，从业务支撑、技术驱动、文化塑造和团队建设这四个方面出发，打造一个有活力的、持续创新的研发团队，以支持业务的快速发展。
+
+一、业务支撑
+
+快速发展已经成为互联网公司的一种共识，那么在快的情况下，怎么面对业务支撑？尤其是当业务多，团队人手不够，大家又想做技术驱动、平台升级的时候。
+
+我们的做法是跟大家做了一个共创，把业务分成日常项目和重点项目。在互联网领域，所谓重点项目就是能影响市场抢占度，甚至影响公司成败的项目。因此，对于重点项目，我们有一个明确的要求，即0排期，让重点项目能够随时启动、快速上线，以雷霆之势赢得战略优势。
+
+以运满满为例，我们是一家强运营公司，前线销售人员面对的情况多变，因此他们的KPI、运营方式、所需的数据支撑也一直在变，这就需要CRM系统也能跟上这种变化速度，给他们最大的支撑。
+
+面对这种情况，我们就把CRM建设作为重点项目，高速迭代，在3个月内完成了58次发布，支持14个业务扩展了109个需求。
+
+这是我们最根本的态度，重点业务一定要好好支撑掉，然后才会去做技术驱动。
+
+如何保证业务支撑
+
+那在具体执行层面，如何保证业务支撑呢？毫无疑问，架构和技术是基础，但你会发现架构永远跟不上新业务的发展。这时，在平台化还没有实现、工具化还没有完善的情况下，我们就需要先靠项目管理和人员素质来解决这个问题。
+
+首先，要理顺整个项目管理流程和节奏，我们有几个原则，包括早进入、并行化、反向推动、Deadline、公告等。
+
+以并行化为例，在开始聊想法、MRD、运营计划的时候，核心产品经理、核心架构师、核心设计师要同步参与；在出商业计划的时候，基本的整体架构设计就应该已经完成了；在出产品PRD的时候，基本的概念设计就应该已经完成了；真正到开发的时候，测试用例和自动化测试脚本等就应该已经同步的完成了。尽量分解并行，以此来提高效率。
+
+其次，要打造项目机动组织。举个例子，大家排期的时候经常会提到人员不够，我们的做法是对整个团队做一次大的封闭培训，要求大多数成员特别是高T的同学要非常熟悉每个系统，尤其是核心系统。这样，当某个系统模块比较紧急需要人手的时候，我就可以随时把其他系统的人调过去，尤其是高T的同学，他再带上两个研发的话，可以快速的把这个模块做起来。
+
+对于一家较大规模的公司来说，人员肯定是不缺的，关键在于组织是否足够机动，能否做到员工兵力的机动调配，去支撑重点项目，尤其是脉冲型重点项目。
+
+除了这两点，还需要其他项目管理原则、项目公约、项目同步机制等，通过共享的方式，让大家都能看到项目进度，都能参与进来，真正做好项目管理。
+
+业务支撑遇到的问题
+
+在保证业务支撑的过程中，我们会遇到各种问题，最典型的有以下3种：
+
+
+过来的所有需求都说非常重要、非常紧急，但是拼完上线了，业务那边却不做数据反馈或者根本不用，团队这边也不知道效果到底怎么样。
+因为都是机动支撑，做完这个版本，也不知道下个版本做啥。
+团队也想给业务打枪造炮，但看不到业务蓝图、路线图和运营思路，感觉就像高级外包一样，完全没法和业务一起思考，一起做系统架构，导致没有成就感。
+
+
+为了解决这些问题，我们和团队又完成一次共创，提出了一个概念，即由单纯只关心“技术指标”的“需求翻译机器”、“架构优化机器”，转变为从技术视角去推动平台业务发展的业务架构师。不断锻炼“寻找技术和业务完美结合点的敏锐嗅觉”，保持“跨界”的核心竞争力。这个概念最初是天猫架构负责人大少提出来的，当我们再次用在满满团队，发现也非常适用。
+
+具体到执行层面，可以从以下几个方面出发。
+
+
+了解你的用户，我们会让研发团队到前线去跟真正的用户接触，做前线业务同学、运营同学做的事情，听他们的声音。同时要重视用户的反馈，我们的做法是每两周会把所有在线用户的问题拿出来分享给整个团队，让他们去了解用户的需求。
+体验你的产品，我们会强行要求每个同学都得用自己的产品，频率可以不高，比方说一两周一次，但一定要亲自去使用，同时要注意在使用的过程中提出问题。
+关注线上数据，同样也是要求每个同学都关注线上数据，还会不定期抽查，比方说上线了一个新模块，那这个模块最近数据怎么样了？涨和跌的原因是什么？数据的变动又跟哪个项目有关系等。
+懂你的行业，这方面我们也做了很多举措，比如汇集行业资讯，开展行业分享，引入行业专家等。通过这些方式，让大家了解这个行业究竟是怎么运转的，也真正了解业内司机的痛点。当我们足够了解对方的时候，大家才会带有情感和思考的做事。
+心中有一张大图，即做每一个功能都要思考整个架构，思考业务的运营，而不是只做单点思考。同时，还要思考要实现这个功能，底层需要有哪些支撑等。
+
+
+当每个研发人员脑袋里都有一张完整的大图，同时又很懂行业、懂用户，他的参与感就会很高，这些是我们经历过共创、碰撞后提出的硬性要求和做法，目前执行下来效果非常不错。
+
+二、技术驱动
+
+前面提到，我们通过种种措施很好的支撑了业务，但技术同学不仅仅想要得到业务上的成就感，还希望得到技术上的成长。那怎么帮他们寻求成长，并且与真正的商业结合，让公司认可呢？
+
+1.架构升级，包括服务化、中心化、中间件、平台化等
+
+架构升级对于整个研发的拉动作用是非常明显的，以大家都在做的服务化为例，拆分完之后，模块直接松耦合，可以独立发展和演变，团队也能快速扩张。像运满满一开始也是一个All In One的App，后来服务化拆分之后，团队就可以迅速打起来。
+
+服务化做起来之后，一定要跟上中心化、平台化，底层一定要有一个很强大的中台做支撑，这样才能支持新业务的快速扩张，也能支持已有业务的快速变化。之后还可以去思考怎么在平台里去做业务监控、做数据分析等，慢慢会沉淀出很多中间件。
+
+所以，整个架构是在不断演进、不断升级的，这对于技术同学来说就是一个很好的Topic，激发大家的激情，让他们自驱动的去思考还可以做什么，来让效率更高、稳定性更强。
+
+2.工程效率，包括动态化、配置化、工具化、自动化等
+
+工程效率对业务会有比较直接的支撑，而我们做技术驱动的整体思路，就是把工程效率中的每条线、每个子模块，都去做动态化、配置化、工具化、自动化。
+
+从发布到运维，从测试到自动化，我们大概做了六七十个系统来打造我们的工具体系。这样一个工具体系的打造，首先大家会有成就感，自己做出的工具有效的帮助自己提高了工作效率；其次这些事情都有一定的技术挑战和技术深度，让整体团队的技术氛围得以增强。
+
+3、稳定性，通过系统保障系统
+
+稳定性是研发不变的一个主题，当公司体量越来越大的时候，稳定性就越来越重要，可能一个功能宕机5分钟，就有几万通电话打进来。在稳定性上，除了形成很多固定的流程机制外，我们还通过系统来保证系统，包括测试/灰度、降级/容灾/回滚、监控告警等。
+
+4、用户体验，包括性能／交互、可用性、新IO、安全特性等
+
+稳定性和工程效率是研发中两个基础的部分，能够在早期和中期很好的带动研发技术氛围，但最性感的还是用户体验。
+
+用户体验是非常大的一个课题，需要长期的去监控、去治理。除了已有性能的不断优化外，我们还可以采用一些新技术来提升用户体验，比如当前很火的自然语言处理、人脸识别等。
+
+以自然语言处理为例，它的知识图谱跟所处的行业有着密切的关系，比如我们就用它来做智能助手、智能客服，帮助司机解决使用问题，甚至帮助他们语音发货等。
+
+这就是新技术跟行业、跟产品的结合点，而对技术团队来说，每一个结合点都是一个很好的技术驱动的方向。
+
+5、运营效率，包括系统化、智能化等
+
+每家公司不一样，运满满的运营基因很强大，大概有3000多名运营人员，所以怎么提高运营效率，怎么让他们更高效的获取用户、服务用户、拓展业务，也是我们的工作重点。
+
+从这个维度出发，也能衍生出很多Topic，比如各个系统怎么去做自己的优化，通过系统化、智能化的手段大幅度提升运营效率。
+
+值得注意的是，我提的这几个方向并不一定适用于每个公司，只是提供了一个思路，沿着这些方向去思考，总能找到适合自己的做技术驱动的方式。
+
+最后，我们期待的团队必然是充满活力创新，每个人都在贡献idea，尝试优化产品和系统，参与到业务创造以及技术改变商业的过程中来。今天主要聊了如何从业务支撑和技术驱动这两个方面出发打造这样的理想团队，希望我们的一些做法能给大家带去参考。
+
+作者简介
+
+王东，运满满CTO，资深技术专家与管理者，曾先后负责过10多条亿级用户的产品研发管理工作，历任天猫高级技术专家、360高级总监、百度主任架构师，有过两次创业经验。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/067如何打造独属自己的工程师文化？.md

@@ -0,0 +1,118 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            067 如何打造独属自己的工程师文化？
+                            你好，我是运满满CTO王东，今天想跟大家分享一下如何打造并落地适合自己的文化。
+
+之前的文章中谈到了业务支撑和技术驱动，这两点是打造有活力的、持续创新的研发团队的基础。除了这些自上而下的推动外，很重要的一点是通过打造优秀的工程师文化，激发研发团队成员的自我驱动力，让他们由内而外的真正去思考公司业务的发展和创新。
+
+文化是什么
+
+谷歌、Facebook、亚马逊等都有很强的工程师文化，以亚马逊为例，它的工程师文化包括：通过解决问题来改造世界、基于事实与科学规律、实践务实、逻辑的、专业的、创造性、不断的更新知识、好奇心驱动、对质量的重视、注重效能与效率、交流与传播等。
+
+我们经常跟国内外的公司交流，学习他们的文化和做法。交流是一个非常重要的打开团队思路的方法，给团队制定目标之后，除了让大家自己思考之外，也要让大家多多出去交流，看看其他公司是怎么做的，开开眼界。
+
+谷歌、亚马逊等公司的工程师文化的确非常好，但这不代表我们能全盘学习、拿来就用。每个公司都有自己的独特之处，因此，每个公司都应该有自己的文化，要结合自己当时的状态、行业的状态，以及未来发展后的状态，来定义自己的文化。
+
+如何制定文化
+
+那运满满的文化应该是什么样的呢？我们一方面学习和借鉴了很多优秀的文化，一方面也在思考属于自己的文化应该是什么样的。在具体的操作上，我们管理层进行一次共创，确定了以下几个方向。
+
+一、有担当
+
+我们是一个运营基因很强的公司，需要把业务支撑的特别好，又是一个典型的分布式系统，系统大了之后，有上层、有底层、有中间件，每个人都要Owner一个事情或系统，那这之间的权责怎么划分，沟通怎么解决都是问题，所以第一点就是有担当。具体来说：
+
+
+对于自己Own的事情和系统负责，不是简单的别人给你派活，你来做，而是要有强烈的责任感，出了问题要第一时间跳出来想解决方案，而且要一竿子跟到底去真正解决问题。
+要去总结和思考自己Own的事情和系统，看怎么才能把它们做的更好，是沿着业务支撑的方向走，还是沿着技术驱动的方向往前走。
+要推动自己Own的事情和系统去跟外部合作，并拿到结果。
+要站在客户的角度去思考问题。
+
+
+二、执行力、速度感
+
+国内的互联网迭代速度快，竞争激烈，格局此起彼伏，以运满满为例，我们有车货匹配这个Idea的时候，市场上大概有100多家公司在做类似的事情，而且很多事情先做和后做可能就是一个颠覆性的变化。那我们怎么才能制胜？因此我们提出的第二点就是有执行力和速度感。
+
+但要注意的是，执行力和速度感并不是加班，而是要擅总结、有方法。就是你要不停的熟悉项目和系统，主动总结和思考，去发现问题和改进问题，然后主动去沉淀出相关的技术和工具。
+
+这才是真正执行力和速度感，是来自你清晰的思路和深厚的功底，是一个厚积薄发的过程。
+
+三、有挑战、做精彩
+
+之前提到的两点，是我们为了应对公司当时的状态，对大家提出的要求。同时，我们觉得谷歌、Facebook等公司让工程师们向往，是因为它们是真正有技术创新和活力。而运满满的技术驱动也变得比重越来越大，很多技术会直接产生用户价值。因此，我们提出的第三点就是有挑战、做精彩。
+
+具体来看，一是要弄清楚重点是什么，必须要在重点事情上拿结果；二是要提出和做到有挑战的事情。
+
+现在很多公司都在用OKR，但我们考核的可能不是你OKR的达成率，而是你OKR的挑战性或者精彩性。我们可以从你的OKR中看出你想创造的价值是什么？实现的思路是什么？思路中有几个核心问题需要解决？具体打算怎么解决？
+
+如果能把这些都想清楚，做出来的OKR自然会比较好。对于那些先定一个不太难的OKR的做法，哪怕把它完成了120%，我们也并不赞同。
+
+四、大声说话、开放皮实
+
+很多国外的互联网公司，包括国内的阿里等，有个特别好的文化是员工之间开放交流，思想碰撞。大家对如何做好一件事情有不同的看法，在交流、碰撞的过程中，就能把自己的方案逐渐完善。
+
+所以，我们提出的第四点就是大声说话、开放皮实，鼓励大家乐于和勇于把自己的观点表达出来。包括我们在员工晋升、表彰的时候也会考虑这一点，看他是不是愿意表达自己的观点。因为表达观点一般代表他进行了思考，有自己的想法，尤其对工程师而言，当他们有思考、有想法的时候，一般都会愿意表达。
+
+同时，越有想法、越爱表达的人，我们越会考虑对其重点培养，会基于他的思考跟他有针对性的沟通，告诉他怎么样能思考的更深入，让想法更具可行性等。
+
+以上这些就是我们当时定义文化是的思路和做法，其实是兼容了国内互联网公司要拼、要快的风格和一些国外互联网公司要创新的思维。
+
+当然每家企业都不一样，我只是分享了我们的做法，提供了一些参考思路，最主要的还是结合自身公司业务的重点、团队发展的重点、对未来的期望等，创造和融合出属于自己的文化。
+
+文化如何落地
+
+文化定义出来后，该如何落地呢？毕竟改变一群人，让大家认同团队文化并将其当作自己的观点是一件很难的事情。
+
+我们的做法是又进行了一次共创，当然不是直接把结果告诉大家，而是带领团队去思考。没有这个自己思考的过程，团队不会认同你，或者即使表面认同了，内心也会有疑问。当时，我们提了一堆问题供大家思考，包括：
+
+
+什么样的研发就算一个好研发?
+什么样的测试就算一个好测试?
+什么样的运维就算一个好运维?
+我们认同什么样的人？
+我们Hire什么样的人？
+我们做什么样的 Leader？
+
+
+捋完这些问题之后发现，大家对于“好”的定义和认知是一致的，然后，我们又把它提炼精炼了一下，首先在管理层上达成了共识，定下对于“好”的定义。管理团队达成共识之后，接下来就是推广到全体员工。
+
+首先，管理者是关键，要律人律己。
+
+具体的做法上，一是要根据之前的共识确定选拔标准，不再是之前简单的能把活干了就OK，而是要看他是不是够快，是不是有创新能力，这些将成为提拔人才的标准。
+
+二是各个管理层隔几个月要做一次群Review，反思自己哪做的好，哪做的不好，先保证Leader层面的味道。这样就形成了一个机制，管理层能对文化有比较清晰的认知，如果有员工不符合团队文化，他们也会比较敏锐的感知到。
+
+其次，落地到员工。这不是简单的弄个文化墙就能搞定的，而是要落到具体的关键事情上。
+
+1.树榜样、荣誉体系
+
+我们每三个月有一个开放日，会跟大家讲一下公司的目标、规划和发展情况，以及下一个季度技术和产品的规划等，同时会对优秀员工进行表彰，设立的奖项则完全匹配之前提到的文化。
+
+比方说有担当奖、最快执行力奖，这个一般是给打了攻坚仗的项目，同时会让这个项目总结他们是如何有速度感、快起来的，在管理、执行上沉淀了哪些工具和措施。
+
+还有创新奖，主要看大家有没有自己的Idea，能不能想出对用户有帮助的功能，或者行业里边哪些技术可以和我们结合。这些都是荣誉上的，我们会大力打造荣誉体系，并树立榜样来进行鼓励。
+
+2.员工 One One、项目管理
+
+我们会跟员工做 One One的深度沟通，对于我们追求的快、速度感、执行力、Ownership等特质，他们究竟做的怎么样，有哪些地方值得表扬，有哪些地方需要加强等。另外在项目复盘的时候也会复盘这个东西。
+
+当你鼓励什么的时候，什么就会生长起来，当你反对什么的时候，什么就会消失掉，如果你一直鼓励这些文化，它们就会慢慢深入到每个人心中。
+
+3.Hire、Fire
+
+作为管理者，有时候还是需要比较坚决的，因为文化这个事情并不是每个人都能认同和融入的，但不认同并不代表他不好，也许只是不适合。
+
+所以，在这件事情上要坚决一点，对于认同我们、在这儿做出贡献的人，我们就一定要对得起他；如果大家真的观点不一样，那还是尽早分开，避免更多的沉没成本。
+
+这样也是避免被底下的同学影响，因为我们要的是影响而不是被影响，是感染而不是被感染。
+
+最后，我们通过一年多的运营，成功把这些文化贯彻了下去，希望我们打造文化并将其落地的过程能带给你一些启发。
+
+作者简介
+王东，运满满CTO，资深技术专家与管理者，曾先后负责过10多条亿级用户的产品研发管理工作，历任天猫高级技术专家、360高级总监、百度主任架构师，有过两次创业经验。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/068如何打造一个自组织团队？.md

@@ -0,0 +1,83 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            068 如何打造一个自组织团队？
+                            敏捷宣言的原则中提到，“最好的架构、需求和设计都出自自组织团队。”这带来几个问题：什么是自组织团队？我们为什么需要它？又该如何领导一个自组织团队呢？
+
+什么是自组织团队
+
+技术人是典型的知识工作者，他们需要解决全新的问题，需要具备较强的学习知识和创新知识的能力，他们的劳动兼具知识性、创造性、灵活性等多种特性。
+
+因此，对技术人来说，通常只能管理目标，而不好以严格的操作规范来管理过程，同时，他们必须要自我管理，必须要有自主权。正如Scrum指南中说的，“自组织团队要自我决择如何最好地完成他们的工作，而不是由其他外部团队来决定。”
+
+具体来说：
+
+
+给予自组织团队令人信服的使命，并为他们指定清晰的边界，与其他组织单位、资源达成一致。
+在一定的边界范围内设立团队自己的规则，并且确保所有人遵守。
+在这些边界内给予自组织团队自管理的权利，不需要定向控制和监督，由他们自己监控和管理自己的进度。
+可以给自组织团队安排一个目标，并查看他们的进展如何，不过你只需要在他们需要的时候提供帮助。
+自组织团队想要知道，并且知道项目和产品的所有内容，理解需求，不会害怕提问题或提出建议。
+自组织团队有主人翁意识和承诺意识，他们对自己的工作感到自豪，并承担相应的责任。
+7.自组织团队利用成员所有领域的专业知识，演化、调整并且能够解决广泛的任务。
+
+
+为什么需要自组织团队
+
+当今社会正经历着巨大的变迁，而这些变迁带来了新的挑战，可以说，我们正面临一个易变的、不确定的、复杂的、模糊的世界。
+
+而一个组织要想成功，就必须充分利用这些变化带来的机遇，同时对危机有足够的准备。如此，管理者就不可避免地要去应对无穷无尽的不确定性、不可预测性和各种风险。
+
+面对这样的情况，“业务敏捷性”成为必须，作为技术领导者，要充分利用手上的机会，要充分挖掘新的可能性，以逐步建立竞争优势。
+
+而自组织团队是敏捷的一种体现，它比微观管理的团队更加高效地协同工作，团队成员接受新事物、学习新知识的能力更快，他们在工作中的动力和得到的乐趣也更大，因此，在人才极度宝贵的软件行业，自组织团队会带来更高的回报，传递更多的商业价值。
+
+此外，自组织不仅是一种团队形式，更是一种管理手段。在此前已经固化的业务流程中，管理者必须自己一手设计出一个高绩效的团队。他必须有能力设定明确的目标，建立正确的决策模式，有效调配资源等。不少团队依旧遵循着这种管理模式和价值观。而在自组织的管理模式中：
+
+
+提倡自我控制的现代文化取代了旧式的命令和控制手段。
+专注于自我控制，是为了表达对知识型工作者的尊重，并充分利用他们能力的唯一途径。
+新型的面向关系网的领导方式，与面向层级的管理方式并存，目的是为了充分利用专家资源，并能够对环境变化作出快速响应。
+鼓励分散式的决策，同时，运用可视化管理了解全局、建立快速反馈通道、精心选择团队绩效指标，以使各个团队更加齐心，并激发他们内在的驱动力。
+
+
+如何领导一个自组织团队
+
+如果我们同意自组织团队就是我们需要的和想要的，那么接下来的挑战就是如何建立并领导一个自组织团队。
+
+1.授权给团队
+
+内外部各种因素都表明我们必须要改变我们组织的运营方式。为了变得更敏捷，我们必须把权力和权威交给更贴近客户的人，并充分授予他们信息，给他们时间思考、学习并改进。
+
+要达到这些目的，唯一的办法就是授权给我们的团队，让他们竭尽所能，不仅仅是完成指派工作任务，而是要激发他们的创造力和自我驱动性，让他们自我决定、自我执行、自我监督、自我控制。这是一种自然而然的尊重，技术人，也就是知识型工作者，必须要有自主权。
+
+另外，自组织团队不是一夜之间就能崛起的。自组织对赖以生存的土壤本身就有各种苛刻的要求，更不用说还时常被微观管理所妨碍，也受累于缺乏工作流程设计，所以想利用自组织流程，必须进行彻底的变革。
+
+同时，团队的自组织过程是永远不会结束的。他们必须持续地、用感知和响应的方式调整需求和上下文来重组自己。换句话说，自组织团队是一个进行中的过程：每一次的设置更改，组织和团队就需要重复整个过程。
+
+2.允许自治
+
+我们用足球队来打个比方，一旦比赛开始，一支足球队就是一个按着特有方式变化着的自组织单位。要成为一支成功的队伍，即赢得比赛，队员需要有互相帮助的意愿和能力。这需要多方面的技能：
+
+
+能够专业地理解和把握自己在团队中的具体角色（门将、后卫、中场、前锋），以及为了成为一个真正的团队，这一角色应该如何与其他角色进行配合。
+动作和控球技巧，比如跑、冲刺、拦截、弹跳，以及传接球、盘带、过人、射门等。
+战术，对整场比赛以及每次配合流程的理解，比如在不同情况下，每个球员必须决定是参与进攻还是留在后场进行防守，在正确的时候出现在正确的位置上。
+战略，能够具备对当前球场形式的大局观。能够阅读比赛的局势并采取相应的措施。无论球场上的形式变化是由队友还是对方球员触发的，都能够立即做出响应。
+
+
+那教练的角色是什么呢？他是否控制着比赛？他是否操纵着他的团队？他是否监控着每个队员的活动？他是否真正参与其中？实际上，他的影响力是有限的。
+
+无论教练是否足够大牌，哪怕他在教练区急得上串下跳，冲着关键球员发号指令，但他没有任何机会去控制球场上正在发生的一切。球队的成功只能靠场上队员的努力才能达成。
+
+这是否意味着教练是多余的呢？当然不是，从一个系统的观点上看，教练对球队的组成、战术、训练计划、踢球风格等等产生着深远的影响。在比赛中，他能够换下一些队员，也能够利用中场休息时间对上半场进行反思并布置战术。
+
+有趣的是，教练最主要的任务是观察，他们观察每一个球员自身的表现与球队的配合，以及和对手对抗的情况。此外，教练会根据观察结果提供专业的反馈。从某种程度上说，教练的主要作用是通过搭建提供积极反馈的回环，创建正确的意识。正如自组织团队中的领导者一样。
+
+结语：我们观察到，这个世界唯一不变的就是变化本身，所以我们需要“业务敏捷性”。而我们过去运作组织的方法已经过时了，那些由教练式领导者指引的自组织团队才是新运转体系的核心。而在这一组织形态下，权力下放和允许自治是让知识型员工重拾和保持工作热情的必要措施。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/069茹炳晟：QE团队向工程效能团队转型的实践之路.md

@@ -0,0 +1,83 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            069 茹炳晟：QE团队向工程效能团队转型的实践之路
+                            你好，我是茹炳晟，目前担任eBay中国研发中心测试基础架构技术主管，今天想跟大家分享的话题是QE团队向工程效能团队转型的实践之路。
+
+在软件开发和项目执行中，工程效能问题一直是技术管理者考量的关键。加快研发效能和提升工程师团队效率及质量，需要在软件智能化上迈出创新步伐。
+
+目前，包括Google、eBay等跨国互联网公司的研发团队都在经历“去除QE（Quality Engineer质量工程师）”的组织架构转变，为此Google也暂停了 2017 GTAC并寻求向Engineering Productivity即工程效能的转型。相应地，QE团队也正在逐渐向工程效能团队转型。
+
+工程效能团队的好处在于，假如你的研发团队规模为100人，那么工程效能团队可能需要15个人，但当你的开发团队翻了10倍，达到1000人规模的时候，工程效能团队的人数可能仍旧是15个到20个之间。
+
+所以，随着开发团队人员的增多、规模的增大，工程效能团队的输出和价值会越来越大，这也是为什么很多大型互联网公司、尤其是全球性的互联网公司都热衷于采用这种模式。
+
+如今，谷歌等国外大的互联网公司已经基本实现了向工程效能的转型，国内虽然具体的实践还不多，但很多公司都在做类似的尝试。
+
+在这种模式下，整个测试策略发生一个变化。传统的测试由3个部分组成，底层是单元测试，中间是API测试，最上面是GUI测试，是一个类似金字塔的三角形。其中，单元测试由开发人员来负责，API测试和GUI测试都由专职的QE或QA来做。
+
+但到了工程效能模式下，除了单元测试，API测试和GUI测试也将由开发人员来做。这意味着，开发人员需要兼任测试的角色，克服从开发到测试的思维局限性。同时，还需要一个很高效的测试平台基础架构，提供一个便捷的测试执行环境，以支持开发人员方便的获得测试数据、执行测试。
+
+原本的功能测试团队则蜕化成现在比较热门的探索式测试，测试开发人员则转变成工程效能开发的角色，去做测试平台相关的开发。
+
+在这个转型过程中，如何运用原本QE团队积累的技术优势来设计和构建高效的测试基础架构就变得尤其重要，本文将着重分享如何通过架构演进来改善测试执行环境，以达到工程效能的提升。
+
+测试执行环境之疼
+
+为了提升工程效能，一般会对测试执行环境提出以下要求：
+
+第一点，对使用者而言,测试执行环境的“透明性”。所谓透明是指，假如我今天要用测试环境跑一个Mobile的Native测试，需要某个版本、某个分辨率甚至某个品牌的手机，但这些设备不需要自己准备，只要提供相关的参数，后台就会帮我把其他事情准备好，并且把相应的测试分发过去。对使用测试环境的人来说，他希望整个测试执行环境是透明的。
+
+第二点，对维护者而言，测试执行环境的“易维护性”。所谓易维护是指，不希望有上千甚至上万台机器的测试执行环境需要人工维护。因此，我们引入了容器化技术，用Docker来准备整个测试执行环境。
+
+第三点，对于大量测试用例的执行而言，执行能力的“可扩展性”。引入容器化技术之后，可扩展性自然而然就解决了。我们会根据单位时间内测试用例的排队数量，通过算法来决定这个集群里需要多少台机器才能在规定的时间内执行完全部测试用例。这样整个集群的伸缩也全部由自动化工具来完成，能做到对使用者完全透明。
+
+第四点，Mobile移动终端的多样性与碎片化，这使得搭建一个包含各种iOS和Android设备的集群成为挑战。
+
+这些都是测试执行环境会面临的问题，我会分享一些我们的实践，以及我们是如何通过架构演进来不断完善测试执行环境的。
+
+第一版：基于Jenkins触发测试执行
+
+这是最早也是最典型的测试执行环境，即基于Jenkins触发测试执行。我们把测试用例放在Github中，Jenkins会去获取这些用例，再在远程固定的测试执行环境中去跑这些用例。
+
+第二版：基于Test Runner／Test Execution System
+
+因为Jenkins中跑测试的脚本会越来越多，因此，基于第一个版本，我们在Jenkins脚本的基础上，封装了一个Test Execution Service，这个服务会对Jenkins中的Job进行版本管理、用例管理等，以方便发起所有测试，同时这个服务不仅提供UI界面以方便开发的使用和对用例的管理，还提供Restful API接口用于与CI/CD的无缝集成。
+
+第三版：基于Selenium Grid提高测试并行执行能力
+
+原本在整个架构中，远程测试执行环境这一部分是一个固定的测试环境，都是VM，而在这个版本中，我们用Selenium Grid搭建了一个Hub，可以容纳上百台机器，下面挂了很多包含不同OS和浏览器版本的Node。
+
+Selenium Grid其实是一个小的集群，这个集群通过一个中央节点来接收所有的测试请求。拿到请求后，它会先去查看该测试请求是要跑在什么操作系统上的什么浏览器上面，再去查看自己的节点里面有没有相应的机器。如果有，它就会把这个测试发到机器上去执行。
+
+第四版：基于Jenkins Cluster提高测试并行执行能力
+
+随着测试用例变多，原本远程测试执行这块是瓶颈，但有了Selenium Grid之后，这里的瓶颈问题已经被解决，现在当有大量测试请求集中到来的时候，所有的测试用例都开始在Jenkins上面排队，Jenkins的单节点就成为了瓶颈。基于这个问题，在第四个版本中，我们把Jenkins打造成了一个集群，解决掉了系统的瓶颈点。
+
+第五版：基于测试负载，用Docker实现Selenium Grid的动态扩展与收缩
+
+经过前面四个版本的演进，看似整个测试执行环境的基础架构已经比较完善了，但是在eBay内部有个很现实的问题，相信不少有全球性业务的公司也会遇到，即我们一套测试用例可以在全球各个站点上执行测试，同一个测试用例如果乘上支持的国家数量之后，用例数据就会爆增。在这种情况下，Selenium Grid里放多少台Node合适就成为了问题。多了的话平时会浪费，少了的话等用例来了又需要排队。
+
+我们的做法是，用Docker实现Selenium Grid的动态扩展与收缩，做了一个Auto Scaling的服务，根据前面的用例排队情况来决定需要多少Node，动态的去扩张整个Node的数量级。
+
+这样做还带来另外一个好处，Docker化之后自然而然就解决掉了测试执行环境的维护难题，可以通过Docker主要维护Image镜像，后面的东西全部是自动化的，不需要做太多管理。
+
+除了以上提到的架构演进，我们还通过Appium和Selenium Grid搭建了一个移动终端的测试执行集群，集群里面放了各种各样的手机设备，开发人员指定要哪个品牌哪个型号的机器，测试系统就会自动到这个集群中搜索，如果有符合要求的机器，系统就会自动把测试发上去，执行完成之后再自动结束。开发人员都不需要知道这个集群搭建在哪里，他只要调用服务就可以使用。
+
+这样一来，对于开发人员来说，他们做测试时就完全不需要考虑测试执行环境的问题，他们只要弄清楚自己的需求就可以了，整个测试执行环境对他们而言是非常透明的。同时，这样一个基础架构的维护成本也非常低，只需要工程效能团队定期维护就可以了。
+
+结语：为了进一步提高软件开发效率，测试环节也是需要技术管理者们重点关注的方向。如今，测试正在经历去除QE，向工程效能转型的过程 ，在这一过程中，开发人员将更多的介入测试环节，因此如何提供给开发团队简单、易用、高效的测试基础架构就变得尤为重要。本文分享了测试执行环境架构的演进过程，希望能给有意向转型的团队提供参考。
+
+不知道你的团队目前在采用怎样的测试策略呢？测试执行环境又是如何搭建的呢？欢迎留言分享。
+
+感谢你的收听，我们下期再见。
+
+作者简介
+
+茹炳晟，eBay中国研发中心测试基础架构技术主管，具有超过12年的软件测试经验和3年开发经验，和丰富的测试框架设计与自动化测试经验。另外，他还在【极客时间】开设了专栏“软件测试52讲”，系统梳理软件测试的知识体系。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/070技术、产品、管理的不同视角.md

@@ -0,0 +1,91 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            070 技术、产品、管理的不同视角
+                            你好，我是bilibili主站技术中心总经理王昊，今天想跟大家分享的话题是技术、产品和管理的不同视角。
+
+我们在工作中难免会跟技术、产品、管理等角色打交道，那么不同角色的世界观有什么不同呢？怎么平衡多个角色之间的关系，怎么协调多角色团队的工作呢？
+
+技术、产品、管理眼中不同的世界
+
+技术眼中的世界有4个关键词，分别是工作、设计、选型、优雅。他会关注自己的设计方案是否优秀；该选用什么样的技术选型才合适，比如是选用SQL还是MySQL；自己的代码是否足够优雅等。
+
+产品眼中的世界也有4个关键词，分别是用户、需求、方案、细化。他会要求自己理解用户，了解他们的需求，并满足他们的需求；针对用户的需求提出相应的解决方案，并将方案细化到可执行程度。
+
+管理眼中世界的4个关键词则分别是目标、指标、拆解、梯队。他关注的是自己是否能达到目标和相应的指标，如何对任务进行合理拆解并制定阶段性目标，如何建立完善的人才梯队，做好人才储备等。
+
+这三个角色眼中的世界都是不一样的，这导致他们看待同一件事情的视角也是不一样的。
+
+技术人首先看到的是工作，一个确定性的工作，而且技术人特别喜欢解决确定性问题，有输入有输出。一个任务的要求是什么、边界在哪里，确定这些问题之后，他就非常容易把它分解开，并把它完成。
+
+技术人的追求在于，他希望自己在做这些事情的时候，够优雅、够简洁、够高效。而产品解决的往往是非确定的问题，比如好，不好；好用，不好用；流程，不流畅；酷，不酷等，这些都是没办法做具体的、确定性的界定的。
+
+举例来说，工程师面临的问题，可能是把宽带节省30%，把QPS从1700提高到2000等，都是非常数字化、确定化的。而产品经理不是这样的，他们面临的问题，往往是让用户更满意、让用户觉得产品更厉害等，都是非确定性的问题。
+
+而管理跟技术和产品都不一样，管理面向的是目标，他关注的是指标，比如这个产品月活提高30%，成本减少50%，梯队规模控制在1000人以内等，都是数字性的具体指标。
+
+由于大家的视野和视角不同，彼此之间会产生很多隔阂和误解，网上很多段子就是由此而来。而避免这些情况发生最好的方法就是加强沟通，具体可以从以下3个方面着手。
+
+
+以团队实现为目标，把自己的视角从程序员拔到更高的高度，从团队价值的角度出发，思考和对话。
+换位思考，多去想想如果你处在对方的位置，你会怎么想怎么做，这样的换位思考能有效避免形成误解和误区。
+用对方能听懂的语言做表达，很多时候，技术人员习惯用技术语言来表达，比如异地多活很重要，一个典型的技术语言，但产品经理或管理者可能不清楚这个词具体是什么意思。因此，技术人员在跟对方沟通的时候，需要把技术语言翻译成产品语言或指标性语言，比如“在任何异常情况下保持服务稳定很重要”，这样，他们也更能理解你所做的事情的价值。
+
+
+技术如何转型产品
+
+对于技术人来说，一般有4个职业发展路径，第一个是从工程师到研究员到高级研究员，最后成长为科学家，是偏专业研究的一条路径；第二个是从工程师到高级工程师到架构师再到主任架构师，这是偏工程实现的一条路径；第三个是从工程师到项目经理到经理再到部门总监，这是偏管理的一条路径；第四个是从工程师到产品经理到高级产品经理再到产品架构师，这是偏产品的一条路径。
+
+对于程序员来讲，如果最后以CEO或COO作为自己职业发展的目标，那么可以换一个方向，尝试选择后两条发展路径，试着培养自己的产品思维和管理思维。
+
+先来看产品思维。其实不同产品经理的侧重点各有不同，可能在技术人员眼里，他们都叫PM，但其实PM各有不同，有的偏交互的，做用户产品；有的偏策略的，做商业产品；有的偏运营活动的，还有的偏活动策划型等，每种产品经理的世界也各不相同。不过，所有的PM都有相同的特点：
+
+
+他们都有改变世界的理想，这一点很重要。程序员的理想是什么？是这个事儿做得得酷，未必是我一定要改变这个世界。但好的产品经理不是，他们一般都有一个改变世界的理想，这样才能推动他们前进。
+相对理性的技术人员来说，产品经理一般会更偏感性思维，特别是偏交互型的产品经理，他们的Sensitive更强，能敏锐的捕捉用户的需求。
+在产品经理的思维中，他们会先考虑一切都是可能的，比如飞机不用轨道就能起飞，在他们眼中应该也能实现，因为这样才能放飞自己的想象力，这点跟技术人员有很大的不同。
+产品经理常说就差一个程序员了，他们一般不会考虑实现的问题，在他们看来，具体怎么实现，都是可以扔给工程师去解决的。
+
+
+技术转产品的优势和劣势
+
+以上这些都是我观察到的产品经理思维上的特别之处，跟技术人员有很大的不同，如果技术人员选择走产品这条路，具体该怎么走呢？有哪些需要注意的地方呢？
+
+先来看，技术转产品的话，有什么优势？
+
+
+技术人员有较强的逻辑思维能力较强；
+技术人员知道什么可能实现。
+
+
+具体来说，技术人员有更强的逻辑思维的能力，就会有较强的全局视野，做事情就会更有计划性，知道怎么把任务做好拆解，在具体执行中分成几步去做更合适，这一点很重要。
+
+同时，因为技术人员知道什么可能实现，他就不会被技术团队忽悠，反之，一个不了解怎么实现的产品经理很有可能会被他的技术团队忽悠。做到以上两点之后，技术人员就能从源头开始强有力的把控整个项目的进展，这是非常重要的优势。
+
+接着来看，技术转产品的话，劣势在什么地方？
+
+
+太过注重可实现性。这在技术人员做工程的时候，是一个很好的优势，但当他进入另外一个角色的时候，就可能变成劣势。因为太注重可实现性的话，就会限制自己的想象空间，会被制约想象力。因为很多东西在一开始的时候都是不可实现的，而正因为它们当初的不可实现，才给了我们更多的机会。
+缺乏同理心。在技术人员眼中，世界一般都是客观的、数字化的、Coding化的，但是真实的世界都是由人组织构成的，所以需要我们用心去感受别人是怎么想的，这个功能为什么用户喜欢或不喜欢，这样的同理心，技术人员会相对欠缺一些。
+思维太过理性。然而产品有时候需要的是感性，当理性的思维碰上感性的需求，就会产生冲突。举个例子，一个产品有10个功能需求，一般技术人员会思考怎样用最少的代价把这10个功能都实现了，最后可能每个功能都只做到60分或80分。但其实，重要的不是把功能全部实现，而是选择其中的一个作为突破点，做到120分，这就足够了，其他的都可以不做。所以，性价比不是决定性因素，有突破点才是决定性因素。这一点，很多从工程师转到产品经理的人都不容易参透。
+
+
+结语： 今天跟大家分享了技术、产品、管理的不同视角，每个角色都有各自不同的世界观，为了避免产生隔阂，技术人员需要从以团队实现为目标、换位思考、用对方能听懂的语言做表达三个方向出发，锻炼自己的沟通技巧。
+
+同时，技术人员有着不同的职业发展路径，转向产品，以产品架构师为目标是不错的选择。而当技术人员选择转向产品时，需要克服自己太过注重可实现性、缺乏同理心、思维太过理性的短处，发扬自己逻辑思维能力强、了解可实现性的长处。
+
+你觉得技术、产品和管理的不同视角主要体现在什么地方呢？技术转型产品时需要转变哪些思维呢？欢迎你在留言区分享。
+
+感谢你的收听，我们下期再见。
+
+作者简介
+
+王昊，bilibili主站技术中心总经理，曾历任百度基础架构部架构师、高级技术经理，网页搜索部副总监，移动应用部总监，是百度分布式存储领域的早期开创者，推动了百度分布式存储技术的自研、应用。
+
+（本文整理自bilibili主站技术中心总经理王昊在ArchSummit大会上的分享，有删减。）
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/071什么样的人适合考虑管理角色.md

@@ -0,0 +1,79 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            071 什么样的人适合考虑管理角色
+                            你好，我是bilibili主站技术中心总经理王昊，今天想跟大家分享的话题是技术人转管理过程中的考量。
+
+之前的文章中提到，技术人一般有4个职业发展路径，第一个是从工程师到研究员到高级研究员，最后成长为科学家；第二个是工程师到高级工程师到架构师再到主任架构师；第三个是从工程师到项目经理到经理再到部门总监；第四个是从工程师到产品经理到高级产品经理再到产品架构师。
+
+除了第一条专业研究的路径之外，其他几条路走到后面或多或少都会需要管理技能。即使是架构师，也需要带领一个技术团队，在技术上达成目标，更不用说总监、产品经理这样的角色了。
+
+那什么样的人适合考虑管理角色呢？转型为管理者需要具备哪些素质？在回答之前，想先问大家两个问题。
+
+问题一：提到曼哈顿工程你会想起谁？
+
+曼哈顿工程是美国在二战期间实施的利用核裂变反应来研制原子弹的计划，最后成功按计划制造出两颗实用的原子弹，整个工程取得圆满成功。
+
+那么，当提到曼哈顿工程的时候，你会首先想起谁？一般人们的答案都是爱因斯坦、费米、奥本海默等技术英雄。
+
+爱因斯坦虽然没有真正参与曼哈顿工程，但他写给总统罗斯福的信，是曼哈顿工程启动的原因之一。费米领导的小组建成了世界上第一座铀—石墨原子反应堆，从实践上证明了链式反应理论的正确性，为原子弹的制造奠定了坚实的基础。奥本海默则是原子弹计划的负责人，被称为”原子弹之父”。
+
+但很少有人知道这个工程的管理者是当时的美军上校格罗夫斯，他管理了10万多人，历时3年，耗资20亿美元实现了曼哈顿工程这个项目。
+
+可以看到，当提到曼哈顿项目的时候，人们首先想到的是其中技术英雄，很少有人知道它的管理者是谁。管理者的光芒会被掩藏在技术英雄之后，这是技术人转管理时需要考虑的问题。
+
+问题二：对于团队，哪一件事情更重要，是使命还是人？
+
+这个问题我在不同的场合都分享过，也做过一些现场调查，发现了一个很有趣的现象。如果当时的听众大部分是工程师，那么调查结果是选人；如果听众大部分是管理者，那么调查结果就变成选使命，而且管理者的级别越高，选使命的人会越多。
+
+这不是一个有正确答案的问题，它的答案没有多错，没有好坏。只是从中能看到，不同的人的视角是不一样的，他们的价值观也不相同。
+
+因此，当技术人思考自己是否适合做管理时，不妨先问自己这两个问题。
+
+什么叫管理者
+
+回到管理者本身，我给管理者做了3个简单的定义：
+
+
+以实现为目标，不以技术先进为目标。技术先进不先进不重要，能做出来最重要。
+以团队实现为目标，不以自己实现为目标。自己的团队能做出来最重要，是不是我做的不重要。
+以帮助团队实现为目标，不以自己提升为目标。我级别升不升不重要，我们团队能做更多的事最重要。
+
+
+这就是管理者视角和技术人员视角的不同。所以，当我们提到曼哈顿工程的时候，所有人第一时间都会想到其中的技术英雄，它的管理者是默默无闻的，但其实他才是这个工程的灵魂。没有他，只靠工程师和技术专家的话，很难把这么多人组织起来，在这么短的时间内，完成原子弹的研发及制造。
+
+所以，对管理者来说，团队的使命更重要，团队的人和人的发展相对来说要欠缺一些。
+
+这是我问了自己这些问题之后得出的答案，是我的观点，但每个人首先得有自己的世界观，你认为什么样的人适合做团队管理，可以有你自己的答案，这并没有一个标准或对错。
+
+另外，管理者要以成功为目的，不以成名为目的；要关注目标达成重于实现路径；要有站在台下的精神准备；还有一点非常重要，受得了委屈。
+
+举例来说，很多公司都会奖励表现突出的员工，会组织在大会上颁奖，这是一个很大的荣耀。这时候，你是愿意作为那个在台上领奖的人，还是在台下看着自己团队成员领奖的人。
+
+如果是前者，你可能在管理道路上走不了太远，反之，如果你愿意站在台下，看着自己团队的成员领奖，享受荣光，你的管理道理才可能走得更远，这就是最大的区别。
+
+但是，能克服这一点的工程师并不是太多，因为骨子里，工程师都有追求卓越的思想，看到别人领奖，他会想我也能做到这样，下次就该是我上台了，能放下的、愿意隐藏在团队光芒背后的技术人员毕竟是少数。
+
+另外，很多工程师都受不了委屈，当一个功能没有实现，经理问他的时候，即使他嘴上没有反驳，他心里也极有可能反驳说，你又不给钱，又不给机器，我怎么能做到呢？
+
+但管理者不能这样想，他需要背目标，一旦不能实现，即使问题出在其他地方，那也是他的失职，得受得了这个委屈，这也是工程师和管理者很大的不同。
+
+结语：今天跟大家分享了管理者具备的特质，以及技术人员转管理过程中需要思考的问题。总结下来，管理者是以实现为目标，不以技术先进为目标；以团队实现为目标，不以自己实现为目标；以帮助团队实现为目标，不以自己提升为目标。而要成为一个合格的管理者，需要以成功为目的，不以成名为目的；要关注目标达成重于实现路径；要有站在台下的精神准备；还要受得了委屈。
+
+因此，当技术人思考自己是否适合做管理时，不妨先反观自己是否具备这些特质，又是否有了接受这些特质的心理准备。
+
+你觉得管理者最重要的素质是什么？技术转管理的过程中最需要关注的点又是什么呢？欢迎在留言区分享。
+
+感谢你的收听，我们下期再见。
+
+作者简介
+
+王昊，bilibili主站技术中心总经理，曾历任百度基础架构部架构师、高级技术经理，网页搜索部副总监，移动应用部总监，是百度分布式存储领域的早期开创者，推动了百度分布式存储技术的自研、应用。
+
+（本文整理自bilibili主站技术中心总经理王昊在ArchSummit大会上的分享，有删减。）
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/072创业公司如何招到合适的人才.md

@@ -0,0 +1,72 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            072 创业公司如何招到合适的人才
+                            对于科技公司来说，技术人可以说是最核心的宝贵资产了，然而招聘几乎是所有科技公司都头疼的事情，尤其是对创业公司来说，如何招到一个优秀又合适的人才更是前期会面临的极大的挑战。那么，如何招到合适的人才呢？
+
+1.花更多的时间去做招聘
+
+创业初期必然非常繁忙，四面八方涌来的事千头万绪，但是，再忙，招聘依然是所有事情里最重要的。你需要花更多的时间去看人，获得那些有潜力的候选人对你的公司的垂青，并且和所有来面试的人面对面交流。
+
+雷军就曾说过，“如果你招不到人才，只是因为你投入的精力不够多。我每天都要花费一半以上的时间用来招募人才，前100名员工每名员工入职我都亲自见面并沟通。”他曾经在一周内有5天、每天超10小时说服一位跨国公司高管加入小米，但到最后对方还是选择了放弃。
+
+他还有一个切身体会，“不少创业者抱怨找不到人。其实，无论什么样的企业，找优秀的人都很困难。解决这个问题只有两种办法：一，花足够的时间去找人，至少花70%的时间；二，把现有的产品和业务做好，展示未来的发展空间和机会，筑巢引凤！”
+
+雷军都如此，我们作为创业者，为了打造优秀的团队，需要花费足量的时间和精力在招聘上。
+
+2.自己强，才能吸引到相对强的候选人
+
+我们要招人，但更多的时候，我把它称之为吸引人。在阿里、腾讯、百度等大公司，不需要管理者自己去吸引人，每天光是HR送来的简历都挑不完，但是到了创业公司，体量没有阿里、腾讯、百度那么大，就需要靠我们管理者自己去吸引人。
+
+那怎么吸引人，简单来讲就是对方想听什么、需要什么，我们就给他什么。一般来说，技术人需要的就六个字——跟对人、做对事。每个人都认为自己是千里马，希望遇到自己的伯乐，我们作为伯乐，该怎么对待我们的千里马呢？
+
+我的一些经验，首先，要跟对方表明自己也是技术出身，比方说秀秀自己的GitHub项目，让对方知道自己不是不懂代码的纯管理者，大家都是同一个圈子的人，会理解你们的想法与需求。人最怕的就是别人不理解自己，技术人也不例外。
+
+这是基础，在这个基础上取得信任之后，才好跟对方沟通公司是做什么的，具体业务是什么方向，有哪些挑战等。但我们作为技术管理者，很少拿业务去吸引人，一般都是拿技术上的挑战去吸引人，比方说加入我们可以做Docker、做虚拟化、自己搭框架等，可以在拓展业务的同时，很好的兼顾技术上的锻炼和发展。
+
+总的来说，一定要让他们感觉到你这个老板是靠谱的、是懂他们的，后面才是业务上的、技术上的挑战，最后才是具体的薪资水平。
+
+3.扩大团队与leader的影响力
+
+有技术大V曾分享过，他通过影响力得到的最大的收获就是便于“勾引”各种人才。有了影响力，就有了关注度和话语权，一个有点知名度的公司，与一个毫无知名度的公司，对人才的吸引力，天差地别。那么如何提升影响力呢？
+
+
+第一，多参加业界交流会——如果你之前不是技术圈大V，那么可以主动参加一些活动，行业相关的也好，技术相关的也好，多多分享自己及团队的技术和创业心得，建立良好的公司形象和技术团队形象，通过媒体扩大影响力，这是团队扩展人脉和影响力的有力途径。尤其是一些圈内认可度较高的大会，说不定你想要的大牛就在那里。
+第二，选定一个技术方向着力打造技术品牌——对于技术人来说，技术团队的实力水平是非常重要的考量因素，因此，可以有意识的选择某个具有核心竞争力的技术方向，来打造技术品牌，比如在相关的技术大会上分享，撰写或翻译该技术的优质文章，如果是开源技术，还可以积极贡献开源社区等。
+第三，看到优秀内容主动在对方博客圈里留下痕迹——越是牛人，与他心灵相通的圈子越窄。要想搞定他们，最好的办法就是寻找牛人的博客，看到优秀的内容就主动勾搭，跟对方聊一聊技术、行业相关的话题。你要相信，在你够强的时候，通过跟别人的沟通交流，自然而然会得到他们的认可。
+第四，在职员工推荐——这其实是最好的一种口碑传播的模式，在职员工了解你公司的业务状况，他会根据你的请求和需要推荐员工。但是，也容易出现小集体和抱团的情况，不过创业公司规模较小，大家朝夕相对，不容易出现这种情况。
+
+
+4.不要完美，合适就行，有潜力最重要
+
+很多时候，大家在招人的时候都想着一定要打造一个梦之队，不管什么方面都要最牛的人。但这很显然是不现实的，就算有人一时冲动被你忽悠过来了，能不能留住也是个大问题。
+
+90分容易，100分难，100分的人你肯定要付出200分的代价。这代价不只是公司钱财上的代价，还包括管理的成本，你需要花费更多的精力让他融入现有的团队，然而就算成功融入了，之后团队如何平衡也是个大问题。当前互联网行业早就已经脱离早年一个程序员搞定一个系统的时代了，一个软件动不动就是几十万行代码，一个人根本搞不定，都得靠团队通力协作完成。所以，很多时候不用特意去追求明星程序员，合适的才是最好的。
+
+另外，潜力仍然是衡量一个人是否有发展前景的最重要标准。如今，IT行业发展快速、复杂多变，对公司来说，胜任的人才固然重要，但潜力人才更是可贵。
+
+那什么才是有潜力的人才呢？一般可以从以下三个方面出发进行判断。
+
+
+是否具备正确的动机，以强烈责任感和极高投入度去追寻一个的目标。
+是否具备极强的好奇心，渴望获得新体验、新知识以及别人反馈，以开放心态学习和改进。
+是否有面对挑战的决心，在面临挑战或在逆境中受挫时，依旧能为目标不懈努力。
+
+
+5.从招人变为找人
+
+对于优秀或稀缺人才，千万不能端着，要主动出击，放下身段，以真诚打动和吸引他们。毕竟，优秀的人才是从来不缺机会，一定是我们去求才。在求才的过程中，往往还要拿出锲而不舍的精神，正如之前提到的雷军，为了找到一个非常资深和出色的硬件工程师，连续打了 90 多个电话，而为了说服他加入小米，他和几个合伙人轮流和他交流，整整 12 个小时。
+
+尽管穷追不舍、软磨硬泡之后，人才也不见得跟你回家，但你不这么做，优质人才几乎是不可能会主动跟你走的。
+
+结语： 创业团队想要招到优秀又合适的技术人才，从来不只是HR的事，而是CEO、CTO以及整个公司的事情，在具体操作上，我们可以从花更多的时间在招聘上；增强自己作为技术leader的实力，用实力来说服候选人；扩大团队与leader的影响力，吸引人才主动来投；制定合适的人才标准，选择最合适的人才而不是最完美的；从招人变成找人，求才若渴，主动出击等几个方面出发，来应对招聘挑战。
+
+你们呢？是否也为招人感到困扰呢？你们又是怎么应对招聘难题的呢？欢迎留言分享。
+
+感谢你的收听，我们下期再见。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/073用数据来分析管理员工.md

@@ -0,0 +1,65 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            073 用数据来分析管理员工
+                            上周，我们聊了创业公司招人的话题，今天，我们接着聊聊把人招进来之后该怎么育人和用人。
+
+所有的公司都有新员工培训这个环节，只是重视程度不同，之后进入正式工作后，还会有团队leader不断的培养。每个人的特质都不同，很多时候我们很难招到跟团队完全Match的人，但如果育人和用人跟得上的话，在把员工变得更好的同时，也能让团队更高效。
+
+一般来说，我会把团队成员定义为三类，一个是核心骨干，一个是骨干，一个是普通同学，不同的人有不同的带法，也就是不同的育人法和用人法。
+
+实际操作中，育人是要花费大量时间和精力的，而我们每天放在工作上的时间是有上限的，很难做到雨露均沾。假如你的团队现在有10个人，采用平均主义，在每个人身上花的时间都一样，那你将会累死而且很可能效果不好，因为有些人是无底洞，并不值得投入很大的时间和精力。
+
+就跟买股票一样，如果要选十只股票，那你肯定会分析考虑，做出取舍。如果平均每只股票都买的话，那还不如直接买大盘指数。
+
+所以一定要将人才分档，把我们的大部分精力放在骨干、核心骨干上，下面分享一些我的具体做法。
+
+1.以事育人，因材施教
+
+王阳明说过，人须在事上磨，如果我们只用嘴说，就太肤浅了。为什么我们听完课之后要做笔记、做功课，还要考试，同样的道理，很多时候，我们在培养下属、管理干部的时候，必须用一些事情让他们得到锻炼、让他们证明自己。比如说我希望他们在项目管理上做得更精细化一点，那就对他们提出要求，通过具体的工作来磨炼他们。
+
+很多时候，我们还需要将我们的同学扶上马，送一程，比方说他技术很厉害，那我们就可以给他设计一个阶梯型任务，让他逐步适应这个新工作，发挥自己的能力。
+
+同时，我们要因材施教，因为不同的人的性格都不一样。有些同学是外放型的，他就适合往业务方向发展，有些同学是内敛型的，他就适合沉下来做基础建设、做工具系统。
+
+2.言传身教，多做政委
+
+我带过很多新人，新人又分两类，一类是能力强的新人，他们有很丰富的经验，不需要怎么教，给他们定任务、做计划就好了；一类是能力不强的新人，但人很聪明又好学，比方说校招来的新人，值得培养、忠诚度高，但是缺乏经验，这时就是16字经验，“我说你听，你说我听，我做你看，你做我看”。
+
+举个例子，小明刚毕业进来，很聪明、很积极，但是没经验，那我就直接派任务给他，比如帮我做个监控的日志分析，那么“我说你听”“我做你看”就是先先口把口、手把手的教他用哪些工具、怎么用怎么分析等，带他做一两次，“你说我听”“你做我看”就是我带着他做了几次之后就放手让他自己去做，看他是否真正掌握方法，同时还要定期考校他，让他总结分析这里面的要点与诀窍。
+
+同时，我们还要多做政委，留人即留心，功夫在平时，平时要多跟员工沟通，多做知心大哥大姐。有机会多带着团队出去吃吃饭、撸撸串，利用这些机会或者每次团队建设的时机，大家一起聊聊工作、谈谈人生、关心关心他们的现状。
+
+除此之外，我们还要结合团队和个人发展目标，和下属共同制定他们的长线规划，这很重要，要让他们感觉到leader是在很用心的帮助自己成长。让他们感到被关怀、被重视，而这样的情绪必然会积极的影响到他们的工作效率。
+
+3.容人之短，用人之长
+
+在用人这方面，我经常把团队成员分为四种：有心有力、无心无力、有心无力、 有力无心。
+
+第一种有心有力，这类同学态度认真、能力胜任，即使有时活给少了，他们也会主动提出来。这类同学是最不需要操心的，给他们定一个明确的目标，他们就能向着目标自驱动的前进。
+
+第二种无心无力，这类同学你给他三次机会，两次考核，不行就让对方走人，没必要对其倾斜资源，要时刻记住把自己的大部分精力放在骨干和核心骨干身上。
+
+第三种有心无力，这类同学很努力，经常发现在加班，很辛苦，但就是出不了成果。这个看情况，第一他是老员工，他已经形成了不太好的工作习惯，你需要花很大的精力去改变他的做事方法；第二他是刚来的新员工，刚适应环境，那就需要快速的给他换个岗位试一试。
+
+我们公司有个规定是，当员工子当前岗位做满一年，只要他在当前岗位达标，那么想去公司任意岗位都可以申请，只要对方愿意收，当前团队就不可以拦着，必须放他走。这也是让人才流动起来，让公司整体的人才氛围更活跃、更好。很多时候硬留着对方，你痛苦他也痛苦，还不如换一换，他可以多个机会发挥自己的能力，你也可以多个空缺招来更合适的人才。
+
+第四种有力无心，这类同学最麻烦的，能看出他技术实力不错，看他写的技术博客、发表的技术文章、写的技术报告都有模有样的，但就是天天干活心不在焉。有贡献，但是心不在，这里面很大的一个可能就是他已经对当前岗位非常熟悉，做这些事情驾轻就熟，但却没有了挑战性，不用花太多心思就能达成考核需要。
+
+这种老员工一定要好好留下来，不能浪费了，家有一老，如有一宝，既然他还没有走，说明他还是认可团队的，所以需要给他更多的挑战和发挥空间，实在不行，也可以主动帮他找出路，比方说从业务支撑团队转到基础设施团队，进行一些工作方向上的调整。
+
+这里面很重要的就是“用人不疑，疑人不用；容人之短，用人之长”，但是知易行难，我也还在不断修炼中，有时也会有抱怨，但是你既然用了他，作为管理者就要尽量帮他发挥长处、规避短处。比如我用了小明，他不擅长对外沟通，那帮他组建团队的时候，就可以选择善于沟通的搭档，发挥各自的长处。
+
+结语：在我看来，每一个管理场景，总有一个最佳实践，所以我非常喜欢给我的员工做画像，因此才有之前提到的核心骨干、骨干、普通同学之分，才有有心有力、无心无力、有心无力、有力无心的区别。我们用大数据来分析我们的客户，为什么不能用数据来分析我们自己的兄弟，让他们在公司呆的更开心呢。
+
+即使真的留不住对方，我也会珍惜每一个同学离职的机会，跟他开诚布公地聊一聊，让他给我开个药方，告诉我是哪里没有做到位，怎样可以做得更好。每一次的员工离职，都是我的一次反思、学习的机会。
+
+关于育人和用人，你是否有独家实践呢？欢迎留言跟我们分享。
+
+感谢你的收听，我们下期再见。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/074为什么给了高工资，依然留不住核心员工？.md

@@ -0,0 +1,87 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            074 为什么给了高工资，依然留不住核心员工？
+                            在如今这样一个科技时代，人才几乎是每家公司的重要资产，各大公司都希望能够留住宝贵的人才，很多老板不惜“一掷千金”。
+
+但碰到的问题是，奖金酬劳投入得越来越多，却依旧没有摆脱人才流失的烦恼，特别是没有留住那些具备关键技能或表现杰出的核心员工。
+
+最近参加一个技术管理相关的闭门会议，正好聊到员工招聘、留存的的话题，有个创业的朋友A抱怨道：“给了那么高的工资，还有期权，好员工还是留不住。”
+
+前不久，他团队里负责iOS开发的一个核心员工离职了，创业公司本来人就少，没有合适的人接手，导致产品的迭代节奏完全乱掉。最后没办法，他作为CTO只能自己顶上了，真心很累。
+
+在大公司，人才体系和储备都比较完备，某个核心员工离职产生的影响可能没那么大，能比较容易的找到其他人顶上，而在创业公司，更多的时候都是一个萝卜一个坑，负责某个核心业务的可能也就那么一两个人，人一走整个步调就全乱了，超级麻烦。
+
+对于这个问题，当时参加会议的不少朋友都遭遇过，也都分享了自己的经验，我觉得很有代表性，就记了下来跟大家一起分享，欢迎一起探讨。
+
+1.高工资真的高么？
+
+据一项调查显示，在所有跳槽者中，有52.5%的人都是由于原单位的工资低而跳槽的。
+
+在上面提到的这个例子中，离职的员工是A公司最早的一批员工，之前的底子并不是很好，初始薪资并不是很高，但由于创业期需要多面手，而此人学习能力又比较强，因此慢慢成长成为研发团队的核心人物。于是，加薪、期权都有了。
+
+然而，人的能量会随着他能力的提升、地位的升高而逐渐增加。受限于公司的薪酬体系，尽管给他加了薪，但可能在他看来，加薪的程度其实并没有跟上他的成长速度和他在团队里的重要程度。同时，对高层领导来说，他又没有不可或缺到为他破例，打破薪酬体系的程度。
+
+久而久之，他就对现状产生了不满，从而逃离。个人能力越强的人，越容易对现状，比如薪资，产生不满。
+
+至于期权，很多创业在招核心人才，或是留核心人才的时候，往往更愿意提供看不到摸不着的期权，这样一方面可以节省成本，一方面也可以将员工绑上战车。
+
+但是，对于员工而言，这更像是一种投资，而且这种投资的回报时间比较长、风险比较高，相较之下，他们可能更愿意去能够提供高薪水的企业。毕竟并不是所有人都能认同创业项目的价值所在，也并不是所有人都愿意承担创业的风险。
+
+所以，不妨先问问自己，高工资真的高么？真的符合员工的价值，达到员工的预期了么？
+
+2.激励到位了么？
+
+另一个参会的朋友B提出了他的看法，对于这些核心员工来说，高工资真的是他们心中最重要的考虑条件么？
+
+在管理中，高工资和奖金都是很有效的金钱激励手段，然而，还有很多非金钱激励手段，包括目标、成长、认可、授权、尊重、沟通、信任、文化等。心理学界相信非金钱激励至少与金钱激励效果相当。
+
+对此，剑桥大学两位教授做了一次实验，以美国快餐连锁店员工为对象，比较了金钱激励和非金钱激励对他们的相对影响。研究结果表明，两种激励手段都显著提高了该店的利润和客户服务质量，同时降低了员工离职率等。
+
+具体来说，金钱激励使免下车取餐的服务响应时间加快了19%，而非金钱激励使得免下车取餐的服务响应时间加快了25%；金钱激励使员工离职率减少了13%，非金钱激励使员工离职率减少了10%，可以看出非金钱激励的效果非常强大。
+
+总的来说，金钱激励是很有必要的，然而，金钱并不总是最有效的激励方式，当员工已经具备足够高的薪资水平时，他们反而会更看中非金钱激励中包括的工作本身的意义、被认可程度、自主性、成长机会、进步空间等内容。
+
+所以，不妨问问自己，除了高工资外，你的非金钱激励到位了么？
+
+3.Leader沟通到位了么？
+
+业界一直都有个说法，80%的人离开公司都是因为上司，而缺乏沟通又是其中最主要的原因之一。朋友C分享了他的经历，他也是创业公司CTO，只是公司规模更大一些，正处于业务高速发展、团队快速扩张的阶段。
+
+
+业务的快速增长带来了各种技术挑战，核心岗位的人手又不充足，我作为技术最高负责人，不得不投入到各种具体事务中，有意无意减少了和团队的沟通，很多同学可能3个月都没有单独沟通过。
+
+缺乏沟通带来了各种误解，尤其是几个早期员工，他们其实对公司有很多想法和意见，但因为没有向上反馈的渠道，慢慢地就变成了抱怨和愤怒，他们被猎头挖角我也全然不知。等到他们集体提出离职时，我才猛然惊醒，再去跟他们沟通却已经没办法挽回了。
+
+因此，以我的经验，如果不能及时了解团队中的思想状况，不清楚他们的诉求点，很容易遇到你并不想要的“意外惊喜”。
+
+之后，我采取了几个措施来加强沟通，一是请求HR部门配备了一个HRBP来协助我；二是要求每个团队的Leader每两周都要跟他们团队的成员做一次一对一沟通。而我则在每周五的时候，跟我下属的Leader们开一次一对一的工作例会，并在每个月月底的时候召开一次全员例会，内容包括欢迎新入职同学、总结本月重要项目的进展以及存在的问题、介绍下个月重点要做的事情，让大家对当前的工作有一个整体的认识，并清楚知道自己在全局中的作用。
+
+另外我还制作了一个表格，根据员工的入职日期、级别和岗位的重要性列了一个沟通计划表。我把每个月分成四周，黄色的表示计划要沟通的，绿色的表示已完成的一对一沟通，蓝色的表示一对多的沟通。每一次沟通都做好沟通纪要，通过这个方式，我能比较好地保持和团队紧密沟通，了解他们遇到的问题，将问题提前解决掉，即使不能全部解决，真到问题出现的时候也不至于毫无准备。
+
+
+总的来说，技术管理者要想搞清楚团队成员的诉求和不满、留住核心员工、打造一个有战斗力的团队，沟通无疑是最重要的。
+
+所以，不妨问问自己，你跟这些核心员工的沟通到位了，真的理解他们的不满和诉求了么？
+
+4.未来有希望么？
+
+最后，还有非常现实的一点，就是你的公司是否给员工看到了希望。我们聊管理的时候，经常有这么一种说法：公司本身的高速发展，是对团队最好的管理，也是对员工最好的激励，自然也能吸引更多的核心人才留下。
+
+比方说小米，从传统的管理来讲，小米内部的扁平化结构带来了很大的管理挑战和压力。但在实际中，由于小米的快速发展和扩张，很多员工都像打了鸡血一样，将热情和激情投入到了工作之中。
+
+可以说，这是非常关键的一点，如果公司特别有活力和前途，每个人都很有干劲和激情的话，其实不用在管理上做太多的事情。但如果一个公司本身在走下坡路，或者是创业看不到方向和未来，那不管管理多么精细、工作安排多么合理、对员工激励多么到位，真正想做事的员工是没有什么成就感的，很容易就会选择离开。
+
+所以，不妨问问自己，公司真的给了这些员工未来的希望了么？
+
+结语：对于员工为什么会离职，其实马云已经总结很全面了，一是钱没给到位，二是心委屈了，上面提到的不管是高工资、非金钱激励、有效沟通还是未来发展前景，其实都能包含在这两点之内。不过知易行难，但有了方向之后，可以试着朝这些方向不断努力，找到留住核心员工的方法。
+
+你是否遭遇过核心员工离职呢？你认为最主要的原因是什么呢？欢迎留言讨论。
+
+感谢你的收听，我们下期再见。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/075刘俊强：一本正经教你如何毁掉一场技术演.md

@@ -0,0 +1,111 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            075 刘俊强：一本正经教你如何毁掉一场技术演
+                            你好，我是腾讯云资深架构师、TGO会员刘俊强，有着10+年以上的互联网开发经验，8年以上的技术管理经验。今天想从反面出发，跟大家分享如何做好一场技术演讲。
+
+演讲（Presentation）是一种常见的经验分享交流以及个人品牌提升方式，回顾这些年，我做过 QCon 讲师、在线课程讲师，在企业内外做过各种技术及管理的演讲分享，因此，最近思考总结了如何做好一场技术演讲的关键要素，以帮助更多的同学做好自己的技术演讲。
+
+本文不会直接告诉你如何做好一场技术演讲，而是要开个脑洞，假设你自己要毁掉平行宇宙中另一个自我的技术演讲，那么你到底要怎么做才能达到目的呢？不急，下面我们慢慢来捣乱。
+
+通常我们将一个技术演讲划分为三个阶段，即内容准备阶段、演讲前准备阶段以及正式演讲阶段，那么秉着不捣乱不甘心的态度，接下来就教你怎么在这三个阶段毁掉自己的技术演讲，想到要做坏事内心还有点小激动呢。
+
+内容准备阶段：含糊定位、结构混乱
+
+在我们决定做一场技术演讲时，我们对于该演讲的目的应该是明确的，一般来说，一场技术演讲的目的分为以下几类：
+
+
+告知（To Inform）：产品技术新特性或版本发布的告知等，例如《Spring Boot 2.0 特性介绍及未来路线图》、《Istio 1.0 正式版发布》；
+教育（To Educate）：阐明一门新技术或框架的使用方法等，例如教会工程师《基于 Spring Boot 2.0来构建Web应用程序》、《基于无服务函数计算来构建数据流分析系统》、《基于 Kotlin 协程实现异步编程》；
+说服（To Convince）：说服决策者来批准或使用自己的技术提案，抑或是研究预算等，例如《基于Spark的数据分析系统的投入产出分析》、《基于 Service Mesh 的海量容器管理平台实践》、《腾讯织云智能监控实践》；
+行动引导（To Lead to Action）：针对已有解决方案引导人员进行行动实践等，例如《微服务改造实施规划》、《XX项目性能优化专项》；
+
+
+不难看出，做一个技术演讲成功的前提是目的明确，知道这场技术演讲主要要解决什么问题，那么，毁掉演讲的根基便是不去弄清楚这场演讲的主要目的，让另一个自我仅知道要完成一个技术演讲，但不知道做这个演讲的目的何在，或是引导另一个自我弄错这场技术演讲的目的，本来是”说服”类的咱给他引导成”告知”类的，想想台下听众一脸懵的表情，是不是心里已经开始暗爽了？
+
+捣乱完了技术演讲目的，下面该在内容准备这块继续使坏了，关于内容准备的要点，我将其总结成“演讲的4W2H”：
+
+
+What：演讲要讲什么内容，内容的主题主旨是什么样的；
+Why：为什么需要这场技术演讲，能够解决什么样的困惑或问题；
+Who：演讲的受众是什么样的人群，是资深工程师还是技术管理者；
+Where：演讲的地点在哪里，是公司内部分享还是付费大会，对应的受众人数有多少；
+How：准备如何完成这场演讲，例如采用什么演讲风格、演讲辅助工具以及演讲结构；
+How Long：演讲的时长是多久，15分钟还是30分钟、40分钟？
+
+
+在“演讲的4W2H”中，Why是核心冲突或需求，通常来源于工程实践或行业中具体遇到的问题，抑或是大家期望了解的行业趋势，简单来说这个 Why 便是这场演讲能够带来的核心价值。
+
+而 Who、Where及How Long 是演讲的限制因素或条件，每场演讲都有客观存在的限制性因素，演讲者必须在这些限制条件下进行内容准备和演讲呈现。
+
+最后的 What和How 便是演讲者主要发挥才华的地方，如何有效地梳理内容结构并用合适的技巧来进行呈现便是演讲者的功力体现。
+
+作为带脑子、有技巧的演讲捣乱者，咱们就不期望在核心价值和客观限制条件，也就是 Why、Who、Where、How Long 这些方向上误导另一个自己了，相信另一个自己的智商也没那么容易被误导。那要捣乱的突破点就是 What 和 How 了，在这里我整理了一些有效的捣乱手段，一般情况下，几条就可以成功毁掉一场技术演讲，要是能够全部命中，那这场技术演讲也就万劫不复了：
+
+
+演讲要呈现的内容过多，不进行收敛导致主题不止一个；
+不明所以的幻灯片排版，如满屏代码、多种字体颜色混用、不使用图片、使用与内容无关的图片、整张幻灯片全部是文字以及花哨的幻灯片设计等；
+混乱的幻灯片结构，如迷之跳跃的幻灯片、内容不做分区或内容分区后不具有联系等；
+直奔主题讲内容，不准备开场和结尾，开场可以帮助观众明确演讲主题，结尾可以帮助观众回顾演讲主题。
+
+
+另外，咱们更不能让另一个自己知道一些成功演讲的通用技巧或是公式，来帮助他进行结构组织，例如“演讲结构组织的 OIBCC”：
+
+
+Opening：获取观众的注意力；
+Introduction：为何会有这场演讲；
+Body：演讲的主要内容及观点，通过统计分析、图表、示例及故事等手法来支持演讲的主要观点；
+Conclusion：回顾主要内容及观点；
+Close：与开场呼应的一句话，让观众有强烈记忆点。
+
+
+总结一下，从内容准备的各个方面来看，要毁掉一个演讲的要点就是：随意的演讲结构、不明所以的幻灯片结构与排版。比如我们可以在一场演讲中放飞自我地进行表达，不管是否与主题相关，也不管是否符合表达逻辑；视觉和排版上也拿来主义，这一页是苹果风格，下一页就跳到word艺术字风格……这样，内容准备阶段就可以毁得彻彻底底了。
+
+演讲前准备阶段：不充分的排练
+
+前面花了不少篇幅来介绍怎么在内容准备阶段进行捣乱，确实，充分的内容准备是一场技术演讲成功的主要因素，基本可以占到60%的比重，那么毁掉了前面的60%是否足够呢？
+
+不达目的不罢休、捣乱就要彻底的心态告诉咱们，只毁掉内容准备阶段是不够的，一定要继续祸害这场演讲。而在演讲前准备阶段毁掉一场演讲的方式就是不充分的排练，最好是完全不排练。
+
+在演讲中，演讲者需要通过各种技巧进行阐述来让观众接受他想传达的内容。知名的传播理论家 Albert Mehrabian 教授研究出了“7/38/55法则”，他总结，你传递的信息或旁人对你的观感主要取决于三个要素：实际言语（内容）占7%，语气（说话的语调、声音的抑扬顿挫等）占38%，肢体语言（手势、表情、仪态等）占55%。
+
+根据这个法则，咱们要让另一个自己忽略 38⁄55 这两项，即肢体语言和语气，而是将注意力全部放在只占7%的内容本身上，这样他就会认为内容准备好了就万事大吉了，咱们干坏事也是尊重科学的。
+
+演讲者排练的主要目的就是让自己在语气和肢体语言上完成肌肉记忆，这样实际演讲时，就不会因为焦虑和紧张造成走形。
+
+排练的另外一个重要作用在于让自己在时间的把握上更游刃有余，有经验的演讲者一般都会提前将演讲讲义打印出来，进行真实的计时演讲排练，帮助自己修正演讲中不合适的内容结构及表述节奏，并且充分的排练能够帮助演讲者准备更多的素材以便应对不同的演讲状况。
+
+正式演讲阶段：照本宣科、忽略反馈
+
+终于到了正式演讲阶段了，这个时候怎么来捣乱、毁掉这场演讲呢？演讲时毁掉演讲很简单，就是照本宣科、不根据现场反馈做灵活调整。
+
+一定要让另一个自我认识到，为了跟你们这些观众做演讲，哥们已经花了n多时间和心血、脑细胞不知道死了多少来准备内容，接下来我来说，你们好好听就行了，让我来 carry 全场，什么弄清楚观众群体、吸引观众注意力，不存在的。
+
+通常来说，一场技术演讲要给观众带去新观点、新知识或是新思考方式等，让观众打破原有认知来接受演讲者的内容是有难度的，所以，在正式演讲时，成功的演讲者会根据现场观众的反馈等来调整自己的语速及内容等。
+
+演讲者需要时刻将注意力放在观众身上，观察观众的反馈，反馈可能是表情、眼神或是动作。根据反馈来判断内容对观众的吸引力以及他们的接受程度，对于他们不感兴趣的地方，演讲者可以灵活跳过以节省时间，而那些他们听不懂的地方，演讲者可以再着重介绍讲解。
+
+另外，观众的注意力每隔一段时间就会不集中，因此，成功的演讲者一般会在演讲中埋一些耍宝或是有冲击力的观点，来保持观众的注意力始终在自己身上。
+
+写在最后
+
+前面我们说了很多关于毁掉一场技术演讲的方式，简单总结下就是这些要点：
+
+
+毁掉演讲的根基便是让自己不清楚这场演讲的主要目的。
+内容准备上毁掉演讲的要点就是随意的演讲结构、不明所以的幻灯片结构与排版。
+在演讲前准备阶段毁掉演讲的方式就是不充分的排练，最好是不排练。
+演讲时毁掉演讲很简单，就是照本宣科、不根据现场反馈做灵活调整。
+
+
+本文介绍了如何捣乱毁掉平行宇宙中另一个自己的技术演讲，当然这里是卖个脑洞开个小玩笑，通过反向操作的方式来帮助大家了解如何做好一场技术演讲，哪些问题是要避免的。最后，期望大家都能够在技术演讲上做得越来越棒。
+
+作者介绍
+
+刘俊强（微信公众号：程序员精进）现任腾讯云资深架构师，曾任迅雷技术总监、某互联网公司技术副总裁，10+年以上互联网开发经验，8年以上技术管理经验。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/076内部技术会议的价值.md

@@ -0,0 +1,75 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            076 内部技术会议的价值
+                            现如今，技术在公司中的重要性越来越高，几乎所有业务的发展都离不开技术的支撑，但很多时候，技术的价值会被低估。
+
+究其原因，往往是因为公司其他部门乃至CEO不了解技术在背后到底做了些什么，是如何保证系统平稳运行、快速响应的，也就没法很准确的了解技术的价值和意义。
+
+内部技术会议
+
+一个很好的解决方法就是推动公司内部技术会议的举办，邀请技术／工程团队之外的其他团队参与这项活动，向公司展示技术团队的成就，也让他们更了解技术团队的具体工作。我一般将其命名为“技术开放日”。
+
+同时，内部技术会议还可以帮助技术团队与其他部门，如产品或运营等建立联系，在一种更友好的环境中彼此交流，探讨大家正在从事的项目、感兴趣的技术、正在进行的工作等，对彼此有更深入的了解，也减轻跨团队沟通中的障碍。
+
+在经过尝试，并收集参会者的反馈后，我们决定每六个月举办一次为期半天的技术开放日活动，具体形式包括内容分享、小组讨论、Open Space等，当然也少不了零食饮料和八卦闲聊。
+
+除了这种纯粹面向内部的技术会议之外，我们也可以邀请外部的发言人和参会者参与，这样的话会更有益于技术品牌的打造和传播。
+
+我有个朋友是一家旅游网站微服务团队的技术leader，之前他们公司技术团队举办了一次技术开放日，对外招募了300多位参会者，分了他们在架构演进、微服务、Docker、混合开发等热门技术话题上的应用经验。
+
+当时活动在技术圈中大获好评，除了对外展示了自己的技术水平，树立了公司的技术品牌之外，还有一个好处是让CEO等领导层看到了技术团队的能量，大大提升了技术团队在公司内的话语权。
+
+如何举办一场内部技术会议
+
+内部技术会议的举办没有什么“标准方法”，主要取决于你的团队、部门或组织的需求，但受众的选择一定要尽早确定：到底该邀请谁参加？谁能从会议中获得最大收益？
+
+这些问题的答案可以帮助你确定会议活动的规划框架，因为随着参会者类型的增加，会议讨论的关注点也要随之改变，以尽可能满足受众的需求。
+
+无论打算如何开展自己的内部技术会议，都要为与会者提供足够的时间和空间，并帮助他们做好安排，让他们能全身心投入到活动中，让活动收益最大化。
+
+1.选择合适的分享者
+
+基于技术会议的一大目标是向公司展示技术团队的形象和成果，所以分享者的选择必须具有代表性。比如尽量选择某个技术成果的一线负责人，这样他能更详细的阐述项目推进过程中遇到的难题、踩过的坑、解决的思路、具体的解决方案等，会更形象更落地；尽量涵盖不同部门、不同背景的分享者，如开发、运维、安全等不同方向的工程师，这样对外技术团队展示的形象会更饱满，对内也能给平时比较“默默无闻”的技术团队展示自己的机会，提升他们的积极性和荣誉感。
+
+2.为缺乏经验的分享者提供指导
+
+很多技术人其实都缺乏分享演讲的经验，他们往往无法很好的完成一场技术演讲，将自己想传达的内容完整、有效的传递出去。比如准备的演讲素材太过技术、太过深奥，导致其他部门的听众无法理解演讲内容；或是无法准确预估自己的演讲时间，事先准备太多的幻灯片，导致最后演讲潦草结束或超时过多等。
+
+因此，我们可以给他们提供指导，保障他们的演讲内容是合适的，深入浅出，简单易懂的；同时，可以在活动开始前几天跟他一起对演讲进行排练，以此更好地掌控时间。
+
+3.参加活动的过程中，本职工作也不能停摆
+
+技术人员平时工作繁忙、研发任务重，所以，最大的困难在于要让大量的技术人员在半天甚至更长的时间里暂停自己的本职工作。尤其如果是分享者的话，还需要抽出更多的时间来准备演讲内容。
+
+为了缓解这一问题，我们可以在前期活动规划的时候就安排一个“战情中心”，提前为他们做好相应的安排，确保重要的支持工作不被中断。
+
+内部技术会议的好处
+
+内部技术会议往往可以带来立竿见影的显著收益，此外还会带来一些隐性的长期收益。
+
+第一，会议可以为技术团队的员工创造一个机会，借此在不同团队之间建立联系，加强员工之间的交流，通过共同学习促进交流和创新，并极有可能在交流中碰撞出全新的灵感和创意。
+
+第二，参与者将有机会加入自己最关心的对话中，在一个友好的空间里分享自己的观点，让以前被埋没的看法和观点影响更多的人，并有机会找到跟自己志同道合的伙伴。
+
+第三，内部技术会议是发现和鼓励“默默无闻的”人员、团队和成就的好机会，借此可以展示可能被埋没的团队项目，或者那些虽然不被广为人知但同样很重要的工作，比如运维团队、底层支持团队等。借此让大家更好地意识到自己的价值。
+
+第四，在内部活动中演讲可以让员工挑战自我。即使他们分享的是他们经常向周围人传达的想法，但如果想要登台演讲，他们必须考虑到很多实际情况，重新梳理自己的实践，进行更深入的研究，真正吃透自己想要讲的东西。很多会议的分享者会告诉你，在活动中分享可以获得的最大收获是在整理和完善自己所要讲述的内容的过程中学到的新知识。
+
+第五，团队很容易会变成一种小型的回音室，因此更好的做法是让大家时不时抬头听听别人在说什么。随后他们可能会感觉，原来不光是我，其他人也在谈论这些问题。
+
+最后，内部技术会议最主要的收益最终都将归结为社交：促进人员和团队之间的互动、信任和理解。
+
+结语： 在这种技术会议中，所有的分享和讨论话题都可以由公司内部人员负责，而受众也都是公司同事，让大家自行选择能引发热切讨论的话题，这样可以提高大家的积极性。
+
+你可以将这种活动变为真正的展示与交流活动过，邀请公司其他人见见你的工程师和团队，听听他们在工作中遇到的挑战、取得的成果，并在技术部门和其他人员之间建立有效的对话途径，也让大家更清晰的了解技术的价值与意义。
+
+你是否在公司内部推动过技术会议的举办？收获了哪些好处？欢迎留言分享。
+
+感谢你的收听，我们下期再见。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/079程军：从0到1打造高效技术团队的方法论.md

@@ -0,0 +1,122 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            079 程军：从0到1打造高效技术团队的方法论
+                            你好，我是贝壳研发总监、TGO会员程军，今天想跟大家分享一些我关于打造高效技团队的认知，希望对你有用。
+
+我的分享主要分成三篇，第一篇讲我对高效技术团队的看法以及我的方法论；第二篇讲我过去成功的实践，以及为什么这么做才能成功；第三篇讲我踩过的坑，以及从中得到的教训，自我复盘和螺旋上升。
+
+曾国藩有言：“凡成大事，以识为主，以才为辅；人谋居半，天意居半。”以前不曾体会这句话中的奥秘，经过最近几年的实践，才发现这里深藏着人生的成功哲学。
+
+“识”我认为就是一个人的大智慧、格局，有远见。“才”是一个人的小聪明，注意这里的小，意在小角度细枝末节的把握。
+
+如果将这一观点套用到搭建高效技术团队这件事上，“识”和“才”分别是什么呢？
+
+“识”是了解公司战略，并弄清当前所做的产品线对公司战略的达成有什么帮助等。“才”是先找leader还是干活的、选Java还是Go等人员招聘、技术选型等方向的具体事宜。不难得出结论，“识”是最重要的。
+
+因此，要打造高效技术团队，先站在你可以认知到的全局高度去思考，比如我会去了解我的团队在公司组织架构中所处的位置，去了解公司的整体战略以及我所负责的产品对公司战略的影响。接着，作为leader，当务之急就是思考怎么做才能支撑这个产品战略。这就是指导我从0到1搭建高效技术团队的方法论。
+
+在这个方法论的指导下，为了满足产品需求，并和领导沟通团队当前的短期目标，作为leader，我目前最重要的事就是快速组建核心团队。这又该如何破局呢？
+
+按照我的方法论，可以分解成三点：
+
+
+我们的雇主品牌怎么样，我们需要什么样的人才？
+符合这些要求的人才在哪里？
+我们用什么方法和渠道去接触这些人才并且吸引到这些人才？
+
+
+通过执行上面的步骤，我们初步打造了一支团队，然而，团队组建起来就一切OK了么？事实上一切才刚刚开始，往后还有无数的挑战需要克服。那到底是什么支持我们做到更多更好呢？
+
+其实在回答这个问题之前，我们要扪心自问一个问题，你选择软件行业的初心是什么？ 我摘录了一些同学的精彩回答：
+
+
+高级工程师甲：看到师兄工资很高经常带着学妹下馆子，还时常在朋友圈晒他们在世界各地玩，也就跟风选择了。
+架构师乙：能有一个自己的Github Star超过100的开源系统就知足了。
+技术总监丙：希望若干年后，我可以指挥几十号人马奋勇打敌，打造一个一个公司明星级别产品。
+CTO丁：希望有一天，可以打造一款全国人民在用的真正解决用户需求的产品，并希望有机会以杰出校友的身份回到大学，给学妹学弟讲一讲这些年所经历的痛苦和快乐。
+
+
+接着问题又来了，你的初心是什么呢？ 请默默的问自己。
+
+于我而言，我个人的初心是可以有一支团队一起打造一款真正解决人类自身bug的产品（比如之前我在饿了么，就是解决人类懒这个bug，但是负责的面还比较窄，只是一条比较独立的产品线）。
+
+然后继续问自己，你的初心可以支持你走多远呢？
+
+李嘉诚曾经说过一句话，你想过普通的生活，就会遇到普通的挫折。你想过最好的生活就会遇到最强的伤害。这个世界很公平，你想要最好，就一定会给你最痛。
+
+而你的初心就是支撑你往前走的动力，如果你不能痛定思痛，不能深刻意识到自己最终想要的，那么一切困难挑战对你来说都是外界强加的，会非常痛苦。
+
+那具体到执行中，我们在打造高效技术团队时，要怎么把“识”做好呢？我们可以从人、工程师文化、工程师绩效评价三个方面出发。
+
+“识”的第一点是关注人。
+
+从图中可以看出，我们做事的方法论是有先有目标，然后通过阶段反馈看结果，另外需要有一个抓手，而这个抓手核心就是人，或者说关键人物。
+
+
+
+大家都知道一家公司的成功公式是：成功= 战略 * 组织能力。然而，战略是由团队领袖思考和决定的，组织能力也是由这帮人来打造的，因此，这个公式核心还可以写成：成功= 人 * 人。当然，这里的人并不是普通的人，而是指关键人物。
+
+举一个例子，饿了么从大学宿舍开始创业到最终被阿里以95亿美金收购，创始人有一句话我很认同，“The way to do really big things is to do really small things and grow them bigger”。这就是目标，也是我前公司CEO认知外卖这件事可以做成的价值观，并且最后成为所有的饿了么同仁都认同的价值观。
+
+对，他就是关键人物，他输出的价值观指导我们做什么事、我们做事的目标以及我们最终形成的价值观。
+
+上面从整个公司的维度出发，那具体到一个技术团队，成功的两个要素战略和组织能力中，战略就是我们团队的目标，能高效完成一个个的产品就是我们的组织能力，土壤就是这两者从孵化到发展到成熟到衰败的沃土，也就是团队的价值观。
+
+“识”的第二点是工程师文化。
+
+工程师文化的核心体现是团队气氛、做人原则和做事方式。
+
+
+
+团队气氛包括分享、开放和打破边界；做人原则包括敢承诺、自驱动和自省；做事方式包括讲逻辑、追求效率、自我闭环。
+
+其中，我想重点分享一下打破边界这件事。以前，我们的管理经验都是把产品、前端、后端、QA等团队割裂的，即使这些团队每天都在一起开早会、过技术方案设计，一起加班，一起推动产品上线，但其实，他们之间的沟通依旧存在或多或少的障碍，总感觉缺那么一点，意犹未尽。
+
+
+比如开发和QA说我这个功能是异步实现的，QA妹子一脸懵逼。
+比如前端同学问后端同学你们数据库怎么设计的，后端同学会心一笑。
+比如由于核心流程有漏洞，产品突然有一个紧急需求，开发和QA同学就不能理解，你产品之前设计的时候为什么没有想清楚。
+
+
+我们的做法是，组织一些头脑风暴，把干系方拉在一起相互交流，大家会相互问一些平时不会问也没有场景问的问题，彼此知无不言。小的知识点当场就能回答，复杂一点需要体系来讲的则可以加入分享池。但这都是术而已，还更多打破边界的形式，你们有什么好的做法么，欢迎在留言区分享给大家。
+
+通过这样的工程师文化驱动并持续一段时间，就会发现我们其实已经是一支快乐的学习型的团队了。
+
+“识”的第三点是做好工程师绩效评价。
+
+从图中可以看出，工程师绩效评价的核心是，怎么评判我们达成的结果符合预期，其关键是结果是否超过预期，以及个人在其中是否有成长并实现个人价值。大公司则有能力模型来直接定义每个技术级别在每一个考核项中需要达到的能力水平。
+
+
+
+我们总是要求工程师按我们的文化做事，但是符合团队文化对工程师本身有什么好处呢？有，那就是极高的工程师绩效评价。有了这些好的评价，物质和精神的认可都会随之来到。
+
+那作为leader，怎么判断团队成员到底做的好不好呢？以下几点你可以参考：
+
+
+可以把他负责的事在指定的时间截点做成。
+做完之后他会思考有什么改进的办法，能让下次做的更好，并分享给其他的人或团队。
+他会想着帮团队其他人员甚至团队本身解决问题，而不是只干好自己的。
+他会去思考自己的工作结果是不是切中客户的需求，会去尝试帮自己的客户找到最合适他的需求，同时在多个关联方中平衡。
+他会突破自己所在的认知高度去思考自己的工作，并站在他的下一个职级能力的角度，去看到问题的本质并给出最优的解决方案，学会取舍。
+
+
+综上所述，其实工程师绩效评价的核心就是否超出预期，而有了这些好的评价，大家可以升职、加薪、迎娶白富美，反之就要继续回去写bug、继续打怪升级。
+
+结语
+
+我从曾国潘的名言开头，接着给你介绍了我们要快速组建团队的原因，以及组建团队从哪几个方面入手。接着我们找到了到底是什么支持我个人和团队往前走，抓手是初心和达到目标后我们可以得到的回报，不管物质还是精神上的。
+
+留一个思考题给你：按照我的方法论，目前你们团队最重要的事情是什么？欢迎给我留言，我们一起探讨和学习，共同进步。
+
+感谢你的收听，我们下期再见。
+
+作者简介
+
+程军，现任贝壳技术总监，曾任饿了么技术总监、1号店架构师，10年以上互联网开发经验，8年以上技术管理经验。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/080技术Leader的持续成长.md

@@ -0,0 +1,105 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            080 技术Leader的持续成长
+                            你好，我是百度网页搜索部主任研发架构师马晋。今天想结合自身成长经历跟大家分享技术leader的持续成长这一话题。
+
+技术人走上管理岗位，度过初期阶段后，很有可能发现产品和技术架构已经趋于稳定，团队初具规模，业务流量也在稳步增长，整体慢慢进入一个稳定阶段。
+
+这时，如何驱动自己保持动力，在技术和管理上进一步成长，并带动整个技术团队成长，是技术leader们面临的新挑战。
+
+技术leader的持续成长
+
+大部分情况下，技术leader就是团队的天花板，你的成长才能够带动身后整个团队的成长，如果你止步不前，后面同学的成长空间也会受限。
+
+因此，作为技术leader，首先要保持动力，追求卓越；其次要培养产品的洞察力，通过横向产品的拓展，带给团队成员更多的锻炼机会；最后要打造自己的技术影响力。
+
+1.保持动力，追求卓越
+
+在保持动力，追求卓越这一点上，首先要保持对技术的深远追求，打造极致的用户体验。比如我所在的网页搜索团队之前做的千亿网页精细排序和索引更新实时化两个项目。
+
+以千亿网页精细排序为例，最初的排序系统中，下层是一个召回模型，上层对召回结果做精细化排序，然而由于响应时间的问题，我们不可能在最顶层模块做更多的结果计算，而这会对最终的排序结果产生一定的影响。
+
+当然，这种影响是非常小的，在整个搜索中可能只占长尾的5%，在82原则中，我们甚至可以不去在意。但出于技术上的追求卓越，我们应当把它做到更好，让其他竞争对手难以望其项背，甚至直接放弃追逐，这样的理念是非常重要的。
+
+因此，我们设计了新的架构，把所有精细化计算打散到最底层的召回模块中。这么做会使架构的复杂性变高，会使底层排序模块变重，会带来很多架构上的调整等等，会有种种困难拦路。尽管如此，我们还是下定决心去做，最终，这个项目获得了2016年百度的最高奖。
+
+在技术成长的过程中，一定要保持这种追求卓越的精神和态度，这是非常重要的，而且要把这种精神传递给下面的梯队，让他们每个人都把这种追求卓越的理念根植在内心深处。
+
+如此，团队中的每个人都有追求卓越的想法，就会主动对系统和产品提出改进思路，从反向推动我们前进和成长，也就形成了团队的动力。
+
+最后是生活的动力，这是非常现实但却无法忽视的方面。现代人都面临着生活上的各种压力，但这些压力也是我们努力的动力，毕竟人类天然的会追求更好的生活。
+
+2.产品洞察力
+
+产品洞察力是工程师团队比较欠缺的一块，但这又是工程师想要更进一步必须具备的能力。比较好的提升方式是多跟产品团队交流，不要抱有偏见和抵触。另外想更进一步的话，可以走出办公室，走进站长圈，多跟站长们接触交流，听听他们的想法。
+
+3.技术影响力
+
+工程师应该更多的表达自己，不论是在公司内部还是公司外部，要主动走进公司讲堂、走进行业讲堂、拥抱开源社区。多跟团队内外的朋友分享自己的观点，以此来提升自己的技术影响力。
+
+当你在讲台上的照片出现在媒体上、出现在内部员工群里的时候，对你自身技术品牌的打造会有极大的好处，对于提高团队凝聚力也有一定的好处，甚至招聘也会受益，毕竟程序员是很愿意崇拜和追随技术大牛的。
+
+推动工程师团队的成长
+
+工程师团队的成长要素，我将其总结为以下几点：
+
+
+以团队带动个人
+技术氛围建设
+团队活动组织
+工程师文化传承
+团队合作障碍
+
+
+我重点分享技术氛围的建设和打破团队合作障碍这两点。
+
+技术氛围建设
+
+技术氛围建设可以从学习小组、技术交流、挑战比赛这三个方向着手打造。
+
+1.学习小组
+
+大家在学校里、实验室里应该都有过学习小组的经历，导师把大家组织在一起，分成几组一起看论文，然后互相分享自己的学习心得。
+
+这个场景在公司里同样适用，而且是一种非常好的模式，能够强制性的启发一些同学的思想和认知。这样，能帮助团队同学在做具体业务的同时，还能了解跟进业界在学术、技术上的最新进展，是非常有价值的。
+
+百度比较成功的一次小组是机器学习小组，当时网页搜索团队有20人报名参加，最后坚持到底的同学都成为了机器学习方向的骨干力量，分布在网页搜索的各个团队，也有人去了其他团队、其他公司成为了技术骨干，可以说是一个成长的快车道了。
+
+2.技术交流
+
+现在业界的技术交流是比较频繁的，有或大或小各种领域的诸多技术会议。除了派团队工程师出门参加活动之外，我们也可以自己组织，邀请感兴趣领域的技术大牛来团队做交流。这时，就需要注意提前收集团队的问题，了解团队的需求，有针对性的邀请讲师，并提前跟讲师做好沟通，让讲师分享的内容能对于团队更有价值。
+
+3.挑战比赛
+
+竞争机制是非常重要的，有竞争才有趣味，才能产生结果，否则事情很有可能就不了了之了。所以，组织一些挑战比赛就很有必要，百度就有Hackathon文化，每个月末都会抽出一个周末24小时或更长的时间，把工程师，甚至产品、设计等人员聚在一起，大家组队参赛，在规定时间内完成计划的项目，将自己的想法落地。
+
+同时还会将大家分组PK，看最后哪一组能获胜。当然输赢其实并不是很重要，最重要的是让大家在实践中得到学习和成长。
+
+就我的实践而言，小团队的组织建设，应该采取强制性的手段，每个同学必须发言、必须思考；大团队则可以以兴趣驱动，筛选出真正对于某些方向和领域感兴趣的人，因为只有兴趣才能驱动他们坚持往下走。
+
+团队沟通障碍
+
+沟通其实有各种各样的技巧，但打破团队沟通障碍最重要的还是共赢和竞争。所谓共赢，即目标导向，大家在共同目标下通力协作，彼此形成合力，更快更好的实现未来目标。
+
+当然，有些事情是很难沟通和协调好的，这时候就要在内部引入一些竞争机制，多团队竞争同一个目标也是一个选择，并非坏事。而且竞争并非你死我活，最终目标还是把事情做成功。具体是选择共赢还是竞争，大家可以根据实际情况来做决定。
+
+结语
+
+今天跟大家主要分享了技术leader该如何驱动自己保持动力，在技术和管理上进一步成长，并带动整个技术团队成长。关键是要保持对技术的卓越追求，同时不断培养自己的产品洞察力和技术影响力，让自己持续成长，并做好榜样，带动团队成员的成长。同时，作为技术leader，可以尝试从技术氛围建设、工程师文化传承、打破团队合作障碍等方向着手，推动工程师团队的成长。
+
+你是如何驱动自己保持动力持续成长的呢？欢迎在留言区跟大家分享你的经验。
+
+感谢你的收听，我们下期再见！
+
+作者简介
+
+马晋，百度网页搜索部主任研发架构师，致力于搜索引擎索引性价比、检索架构等相关方面工作，推动百度索引规模的不断成长，主导百度索引规模从数亿成长为数千亿的一系列架构升级。
+
+（本文整理自马晋在ArchSummit全球架构师峰会上的分享，有删减。）
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/081游舒帆：一流团队必备的商业思维能力.md

@@ -0,0 +1,98 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            081 游舒帆：一流团队必备的商业思维能力
+                            你好，我是箴亚管理顾问公司负责人、TGO鲲鹏会台北分会学习委员游舒帆，今天想跟大家分享的话题是“一流团队必备的商业思维能力”。
+
+还记得在今年在北京的GTLC全球技术领导力峰会上，大家讨论到一个议题，“CTO愈来愈被要求要COO或CEO化”，众CTO不约而同的提到“CTO再也无法只站在技术角度思考事情，必须要更深入企业经营，理解客户与市场，才能带领企业快速增长”。
+
+其实，我认为CTO被要求COO化是一个伪命题，核心问题是企业沟通与创新的低效。
+
+首先，传统CTO专注于技术领域，对公司业务理解少，对市场与客户的掌握度也不足，因此总是被动等待CEO或业务部门提出需求或下决定，研发部门则负责承接需求往下开发。其次，研发部门手上握有技术与数据，但对商业的理解不足，很难提出具有洞见的策略，并运用技术来驱动企业创新与增长。
+
+所以，CTO COO化的消极原因是能有效提升业务与研发对接的效率，而积极原因则是期待研发团队能成为企业的战略角色，带领企业走出另一条增长路线。
+
+过去几年，我在团队内实施了一项大工程，我称之为“商业思维建构”。
+
+商业思维建构的目的是让经营的思维与知识普及到研发主管与团队身上，我所谈论的不仅仅是让研发参与到业务活动中，而是包含了弭平研发与业务部门间的横向沟通落差，以及工程师与高阶领导间的上下沟通落差。
+
+做业务的，不会理解研发，做研发的，也不会理解业务，彼此之间总有许多误解与纠葛；基层员工不理解主管，主管不理解老板，老板更不明白为何员工总是与他对立，彼此间的壁垒愈来愈大，在解决问题与确认需求时，往往需要经过多次修改、讨价还价，才能产生一个双方可以接受的版本，最后心不甘情不愿地妥协。
+
+其实双方的角度（老板vs.员工、业务vs.研发）、知识领域（销售、技术）、承受的压力（业绩达成、项目进度）本来就不同，考虑点很难完全一致。而这就是组织沟通中最常发生问题的地方。
+
+我推动的“商业思维建构”工程的基本构想，是要让团队成员更熟悉公司运作，掌握企业经营的本质，理解公司策略，藉此弭平基层与经营层之间因为组织位阶造成的差距；同时也让团队同仁跨越研发的边界，更深入接触功能部门，包含流程、制度、日常工作等，甚至开始要求他们学习业务、营销与服务相关的知识，藉此缩短彼此在专业知识上的差距。
+
+我在公司运作了这个工程一两年，成效颇丰，不仅沟通变的更高效了，许多制度的推动也愈来愈顺畅。最棒的一点是，当许多工程师理解了商业知识后，能反过来运用技术，以业务部门想象外的方法达成公司目标。
+
+为了方便大家记忆，我试着将我实践的内容汇整成商业思维四力，这四力分别是数据力、运营力、策略力与敏捷力，以下是这四力的概述，往后几篇我则将针对此四力做深入剖析。
+
+数据力
+
+首先谈数据力，我从公司的财务面开始谈起，告诉大家收入、成本与现金流的观念，内容涵盖了固定成本、变动成本、毛利、净利等基本观念，并进一步拆解收入结构，让大家清楚公司靠什么赚钱，哪种商业模式的获利最佳；再拆解成本结构，让各位明白钱都花在哪些地方，哪些地方在浪费钱；再接着拆解客户结构，让大家更清楚哪些族群的客户最忠诚，贡献了最多的业绩。
+
+接着，我进一步提到提升业绩的方法。我简单说明客户分群、分级，精准营销、交叉销售、客情维系、渠道管理、转换率优化等概念与公司内的做法，并运用案例来告诉大家怎么从数据中找出经营的问题，例如业绩未达成的原因，名单转换率下降的原因等。
+
+我告诉大家，这些都能从数据反映，也是研发部门能产生巨大价值的地方，过去我们空有数据，但却在等待CEO或业务部门的指令，现在我们知道这些数据背后的价值了，你还会得物而无所用吗？
+
+说完这些，大家顿时清楚了公司的运作机制，也了解高管们常常挂在嘴上讲的那些数字背后的意思。更重要的，大家都搞清楚了一件事，那就是「如果你不知道手上的工作能为哪个数字产生贡献，那你根本不应该做这件事」。
+我后来发现，其实不仅研发与后勤人员对数字观念陌生，连业务、营销人员也是一知半解，我有必要去普及这些知识。
+
+运营力
+
+第二部分是运营力，过往我们熟知的运营，大多是套用增长黑客的AARRR模型，从用户获取、激活、成交、留存到推荐，有节奏与计划的去转化用户。而运营力强调的不仅仅是让研发部门熟悉运营的知识，更要能善用数据与算法等技术性手法，更大规模且更精准的做好运营工作。
+
+我所追求的是不用人工介入，系统与算法便能持续做好运营工作，相较电商过重的人工运营，我更乐意研究Netflix与今日头条这种仰赖推荐算法的运营方式；相较于运用黑客手法来创造短期爆量，我更崇尚运用正规手法来实现长期稳健的增长。
+
+我认为运营不能只靠出奇制胜，总想着靠创意来运营，而是该守正出奇，先将该做且能做的先做好，剩下的才来考验创意。在这个前提下，运营力本质上更强调用户的健康程度，也同时考虑了规模化过程，运营如何日益高效。
+
+策略力
+
+第三部分谈策略力，过去在工作中我最常问team member：「你知道这项目是怎么来的？为什么而做吗？」，我发现能正确回答这个问题的人少之又少。
+
+其实这问题背后，我问的就是策略与目标。企业在做策略规划时，往往都是一群高管聚在一起，根据目标讨论出策略，接着就定行动方案，而这些行动方案就化为一个个项目，分派到各个部门。
+
+但如我前面所说，高管们熟悉策略与经营，但已经脱离一线工作太久了，他们订出来的行动方案真的能解决问题吗？
+
+坦白说，出错的机率非常高。
+
+高管们当然不是故意的，而是因为专业领域与组织位阶差距造成的误判。如果策略本身没错，但行动方向有错，承接需求的人又没搞清楚具体要解决什么问题，就贸然投入去做，最后的结果就是多做多错。
+
+实务上，多数的员工并不清楚手边的任务是为何而做，更不清楚它是连结到公司的哪个策略目标。从商业思维的角度，我们希望每个员工都要能清楚陈述他所做的每件事情的价值为何？具体能为哪个目标或指标起到贡献。
+
+习惯上我会运用OKR与策略地图方法来有效连接企业、团队与个人目标，通过过解构目标策略行动间的连结性，每个团队成员对自己的价值会有更清楚的认识，对企业的认同感与向上的沟通能力也会因此大幅增强，战略能力也会在这过程中不断培养起来。
+
+敏捷力
+
+最后是敏捷力，敏捷是互联网的基础观念，本质上就是用来应对外部环境的不确定性。敏捷所谈的快速交付、试错、迭代等观念，都是为了让企业在面临不确定性时，能套用的一些基本规则与做法。
+
+在推动团队敏捷化过程，我并没有引入任何的敏捷框架，唯一的指导原则就是“持续追求更快、更好、更有价值”。
+
+
+“快”，通常强调的是应变的快，调整的快，这与组织架构、分工，以及决策过程有关；
+“好”，就是交付的质量，说得出做的到，总是能交付出可预期的成果；
+“有价值”，则是源自于方向与优先级正确，这与企业战略与目标设定有关。
+
+
+在过去，敏捷的推动大致只限于技术团队内部，但我一直认为跨不出技术部门的敏捷都无法真正敏捷，因此我也将上述观念推到营销、销售与服务上，让所有人都理解敏捷的真正价值与必要性。
+
+总结
+
+商业经营不仅仅是经营层或业务部门的责任，而是人人都该为经营尽一份心力，商业思维萃取了企业经营最核心的几个关键点，有助于提升团队对商业的认知。
+
+数据力与策略力能有效弭平组织位阶与专业领域落差的关键知识；运营力则让所有人能聚焦于用户身上，运用技术与非技术的方法来做好运营工作；而敏捷力则让我们从开发团队敏捷，走入全组织敏捷，让企业高效运作。
+
+思考题
+
+你所在的企业与团队内部存在哪些沟通上的落差？除了建立商业思维外是否还有其他做法？欢迎在留言区跟大家分享你的经验。
+
+感谢你的收听，我们下期再见！
+
+作者简介
+
+游舒帆，昵称gipi，箴亚管理顾问公司负责人、TGO鲲鹏会台北分会学习委员。技术起家，后走入管理、产品、营运相关领域，历任鼎捷软件技术总监、TutorABC研发总监，熟悉B2B软件与在线教育。长年耕耘技术、管理与商业领域，现从事顾问、培训与教练工作，期许自己为社会输送更多的卓越领导者。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/082游舒帆：数据力，透过数据掌握公司经营大小事.md

@@ -0,0 +1,105 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            082 游舒帆：数据力，透过数据掌握公司经营大小事
+                            你好，我是箴亚管理顾问公司负责人、TGO鲲鹏会台北分会学习委员游舒帆，今天想继续跟大家分享“一流团队必备的商业思维能力”这一主题。
+
+上一篇文章中，我们谈了商业思维的概论，本篇将与大家分享商业思维中的数据力——如何透过数据来掌握公司的大小事？谈数据力时，我基本不谈资产配置或资金操作这种高度专业性的财务内容，而是聚焦于经营上的关键数据，即销售与销售创造的财务结果，藉此建立正确的数字观念。
+
+数字观念之利润率观念
+
+谈到数字观念，一般我们还是会谈到利润率，利润又可分为毛利率与净利率，而提到利润率，就必须得先谈谈收入与成本的观念。从毛利与净利的角度来看，成本可以分成两大类，即变动成本与固定成本，变动成本指的是会随销货量多寡而变化的成本，例如运费、广告费等，固定成本则是不随销货量而变化的成本，例如办公室租金、人事费等。
+
+毛利指的是收入扣除变动成本后获得的数值，这个数值除以收入即得毛利率，净利则是毛利扣除固定成本后获得的数值，这个数值除以收入即得净利率。
+
+有了对利润的基本观念后，我们就要进一步探讨，如何有效的提高经营利润？这个问题的答案很简单，其实就是提高收入与降低成本，听到这，你可能会觉得很像在讲废话，但如果我进一步追问：“你知道公司收入怎么来吗？”、“透过那些产品或哪些服务？个别的占比是多少？”、“透过那些渠道获客？个别的流量与营收占比又是多少？”这三个问题，营销团队应该要能立马答得出来。
+
+然而从产品或渠道来展开收入状况，这只是单一维度的数据，很容易取得，但若我把产品对应渠道做一个二维的展开，让我们进一步了解“什么产品在哪些渠道上卖的好”，这将有助于我们在正确的渠道上铺货。
+
+若我们在产品与渠道的维度上再加一个客户维度成为三维数据，那我们就能看出“哪些客人通常在什么样的渠道上购买什么样的商品”，这就是新零售中所谈论的人货场的典型场景。毋需大数据，也毋需CRM，只要具备基础的数据观念，程序员就能轻松做到这件事。运用一个很简单有效的案例，就能展现数据的威力了。
+
+数字观念之成本观念
+
+接着谈成本，我觉得多人在收入上的观念还可以，但成本观念往往很差，我不只一次听到销售人员跟我说“这产品2万元，打个五折我们都还稳赚，售价不用订这么贵比较好卖”。我当下问他：“你知道我们的成本多少钱吗？然后运营这个客户，服务这个客户都不用花钱吗？”，他顿时答不上来，其实这个产品的利润并不高，折扣打到55折以下就要亏本了。
+
+其实，多数员工是缺乏成本观念的，所以我还是会不厌其烦的要大家搞清楚每个产品的成本结构，这样才清楚促销的最低门坎应该抓在哪。将上述的收入与成本合并检视后，你看到的不再是整体的利润状况，而是能进一步看到单一产品、单一渠道以及特定产品加特定渠道的利润状况。
+
+如果你是做产品的，掌握这些信息，会有助于你更好的做产品订价与成本的控制；如果你是做运营的，这将有助于你精算在获客、留存等运营工作所能投入的资源；如果你是写程序的，你能运用数据将这些信息呈现出来，并有理有据的跟产品经理沟通方案的正确性。
+
+找出最佳获利商业模式
+
+到这边，帮大家再一次把利润率的观念重新复习了一次，接着要跟大家探讨另一个重要的话题。
+
+“我如何知道做一单生意是否赚钱？”
+
+会计师或财会人员会跟你说看毛利或净利，然而毛利只看变动成本，服务这位客户的人事成本并不会被计算在里头，因为在传统的会计科目上，人事成本一般被归到固定成本里头。若我们改看净利，里头又涉及了太多非直接与客户相关的费用，例如厂房租金、折旧费用等。
+
+若真的要知道做一单生意是否赚钱，成本应该是这么算的，将客户获取成本加上运营与服务成本。而所谓的客户获取成本指的是从触及客户开始，到客户下订单付钱为止所花的成本。纯互联网或纯电商，一般算的就是广告与生产成本，但若你是透过电销或面销来完成订单，那你必须将业务开发的时间成本也算进去，这才是真实的客户获取成本。
+
+而这一单生意到底赚不赚钱，就要看这张订单的客单价是否超过客户获取成本了。
+
+在此我拿Netflix这家在线视频公司为例，Netflix在美洲区，标准的会员服务一个月约收费7.99美元，但Netflix在美洲区的客户获取成本约100美元，这意味着客户最少要持续订阅超过13个月，Netflix才能回本。而Netflix的流失率约5%，意思是每个客人的平均订阅达20个月，换算成客户终身价值约为160美元，这是一种能稳健获利的商业模式。
+
+实务上，若我们能把上述的观念厘清，产品经理大多能更深刻的理解产品的商业模式，以及问题在哪；而运营团队也会更清楚自己的目标应该设定在哪，以上述案例来说，就是低于5%的流失率；而开发团队，则会妥善运用数据，来做精准的服务推送，藉此提高用户体验，进而降低流失率。
+
+指标管理
+
+把最核心的利润观念谈完，紧接着我想跟大家再聊聊指标管理。程序员都很讨厌被指标给限制，讲白一点，我们都不喜欢为了达成指标而做事，但成为领导后，我们却又不得不面对指标，因此我们有必要对指标有个新的认识。
+指针跟目标有很大的关联，指针是用来衡量目标是否被达成，若我们所做的事情无法对某个重要指标产生影响，这意味着我们不该做这件事。在指标管理上，有三个很重要的观念：
+
+第一，指针必然要连动到目标，否则指针达成也不意味着目标实现了，详细内容我们在第四篇讲策略力时会谈的更深入。
+
+第二，永远要关注领先指标，而非将重点放在落后标上。所谓的落后指标指的是业绩、利润率，这是结果指标，是落后的，若我们要有效改善落后指标，我们就必须要掌握领先指标，以电商来说就是曝光数、浏览数、订单数以及对应的转化率，以B2B来说，就是名单数、拜访数与成交数以及对应的转化率。
+
+当周、当月的业绩是否能达到，不用等到业绩出现，只要我们盘点手上掌握的曝光数、浏览数、名单数、拜访状况大概就能推估出结果，而且准确率可达80%上下，而提早知道状况，营销与销售部门便能更快提出应急方案，不用等到营收数字未达标时才处理。
+
+第三，守正而出奇，降低外部依赖性，不能把希望全寄托在难以控制的因素上，例如付费广告、黑客手法或期待一夕爆红，广告可能被垄断，黑客手法可能被封锁，活动爆红有时可遇不可求。反之，把握度高的旧客户、原生流量我们一定要拿下来，先守住应得的，不足的部分才思考如何出奇致胜，是谓先守正，后出奇。
+
+每个业绩周期开始前，我一定会先盘点一下可能的业绩数字，如何盘点呢？基本就按下方顺序进行：
+
+
+该周期内会有多少旧客符合回购资格？乘以平均回购率与客单价，可以大概算出一个因回购而创造的业绩数字。
+有多少客户可能会帮我推荐新客户？进一步算出因推荐而创造的业绩数字。
+有把握的原生流量又有多少？进一步算出原生流量创造的业绩数字。
+有多少旧名单能运用？这可以算出持续转化旧名单所能带来的业绩数字。
+
+
+上述四项做完，已经能达成当月业绩的60%，剩下的40%就是我们真正要努力的地方，可能是广告、营销活动，也可能是增长手法，带来瞬间流量或提高转化率。然而不论是哪一种，掌握正确的数据，提高可预期性，是数据化管理最核心的原则。这部分的细节，我将会在第三篇运营力中跟大家深谈。
+
+数据模型与用户画像
+
+最后，跟大家聊聊数据模型与用户画像，这两者都高度仰赖数据支持，过去我常用的数据模型有三个：流失模型、续订模型与推荐模型，能让我们知道什么样的客户会流失、续订与推荐。
+
+举例来说，我将流失客户的个人属性数据与行为数据拿出来做统计分析，找出高相关性的因子，后来发现，只要客户符合下述三个条件时，流失率高达90%：
+
+
+上次消费日期距今超过6个月
+近一年消费次数低于2次
+近一年消费金额低于2,000元
+
+
+这就是流失客户模型，也是流失客户的基本画像，接着拿所有的客户名单去跑这个模型，把符合上述条件的客户清单找出来，这份清单就是潜在流失客户清单，若知道这群人将会流失，我们就必须要有对应的行动来防止他们真的流失。同样的手法也适用于回购、推荐，甚至其他事情上。
+
+结语
+
+数据，能让我们掌握现况，找出规律。很多时候，企业并非在战略上输掉，而是在日复一日的工作中没有确切的掌握现况与抓住规律，因此在执行上盲目乱窜，却认为是战略错误，岂不可惜。
+
+回到本文的开头，三大模型有效的降低了流失率，提高了推荐率与回购率达5-10%，以利润率来看，我们提升了10%以上，团队检视自己工作产出时看到这样的成果，每个人都开心的不得了。
+
+过去我们将业务、数据、研发团队分开，后来发现光是反复沟通彼此的需求就耗费掉80-90%的时间，后来我直接让工程师去学习数据科学，并亲自指导商业知识，团队的推进效率因此提升了4-6倍，原先花了一年都没搞定的三大模型，新团队在短短2个月内就一一产出了，而这正是商业思维最关键的魅力所在。
+
+思考题
+
+你所在公司的经营数据是否能完全揭露给员工？哪些可以揭露，哪些不能揭露？不能揭露的原因为何？如何让对的人握有数据，让数据真正发挥效用呢？欢迎在留言区跟大家分享你的经验。
+
+感谢你的收听，我们下期再见！
+
+作者简介
+
+游舒帆，昵称gipi，箴亚管理顾问公司负责人、TGO鲲鹏会台北分会学习委员。技术起家，后走入管理、产品、营运相关领域，历任鼎捷软件技术总监、TutorABC研发总监，熟悉B2B软件与在线教育。长年耕耘技术、管理与商业领域，现从事顾问、培训与教练工作，期许自己为社会输送更多的卓越领导者。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/083游舒帆：运营力，让用户出现你期待的行为.md

@@ -0,0 +1,111 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            083 游舒帆：运营力，让用户出现你期待的行为
+                            你好，我是箴亚管理顾问公司负责人、TGO鲲鹏会台北分会学习委员游舒帆，今天继续跟大家分享“一流团队必备的商业思维能力”这一主题。
+
+这是本系列第三篇文章，今天要来跟大家聊聊运营力。关于运营，我想大家都不陌生，不论你听过的是互联网运营的拉新、留存、促活，或是增长黑客所谈的AARRR，抑或是营销4.0所谈论的5A都不打紧，我今天想跟大家聊的是“为何所有人都该理解运营，以及研发人员掌握运营知识后，又有什显着效益”？
+
+依托数据与运算技术的精准运营
+
+若要用一句话谈运营，我是这么说的“运用在线或线下手法，让用户产生你期待的那些行为”，诸如点击、购买、使用、播放等。成功的运营会增强用户的黏性，也会间接提升公司经营绩效。
+
+运营是围绕着用户而生，不论是产品、内容、活动、渠道等运营工作，本质上都是为了服务用户。
+
+
+产品运营，让用户更多的去使用某些产品功能；
+内容运营，提供用户更多有用、有趣的内容，让用户心有所感，甚至愿意分享；
+活动运营，跟用户做更多的在线、线下互动，提高彼此的熟悉度与信任感；
+渠道运营，保障跟用户接触的每个环节都能提供良好的用户体验。
+
+
+流量红利消失的年代，营销领域的专家们纷纷提出企业不该再把过多的重点放在增量市场，而该更多的关注存量市场，观念上也该从经营流量，转往经营流量池。其实相同的概念我在前一篇的数据力中已经提到，企业必须先守正，而后出奇，而守正谈的就是做好相对可控的存量与流量池。
+
+要做好流量池管理，关键是给用户提供更棒的服务体验。如今，标准化的服务模式已经愈来愈难取悦客户了，要让用户开心、买单，就非得提供差异化甚至个性化服务不可。精准运营，这个观念与精准营销是一致的，精准的背后仰赖的是对数据的分析与洞察。
+
+以用户喜欢的方式，在正确的时间点，提供用户感兴趣的信息，这就是精准运营的关键所在。当你知道用户不接电话、不看短信、不点击邮件，只偏好微信讯息时，那你就要尽可能用微信来与他互动，并在他闲暇的时间，给他推送他会想看的内容或活动，这样才能实现精准运营。
+
+你喜欢今日头条，因为它内容推的够精准，让你一篇又一篇的读下去；你续订了Netflix，因为它推荐给你的影片你很喜欢，让你看完一部又一部。
+
+这些，都仰赖足够的数据与运算技术，今年在北京的全球技术领导力峰会上，GrowingIO创始人张溪梦在演说时援引了Gartner的一段话：
+
+“全球25%的业绩将被具有企业家精神的CTO透过创新以及技术优势直接转化为财务结果与市场份额。”
+
+我认为这段话背后所谈的，就是靠数据与运算技术支撑起的精准运营。
+
+运营中常被忽略的议题
+
+前面花了一些篇幅说明运营与数据、技术间的关系，往下我想跟大家聊聊运营中时常被忽略的几个议题。
+
+首先跟大家分享一个真实案例，我有个朋友经营了一间以提供保健食品为主的品牌电商。有次他跟我闲聊时提到客户回购率一直停留在15%上下的问题，努力了一整年才提升了一个百分点，不知道该怎么办才好，他甚至觉得是产品出了问题，所以客人才不回购。
+
+听完他的描述，我问他：“客人们买回家后有没有开封吃，或者持续吃，这个你清楚吗？”
+
+他说：“这不确定，但应该都会吃才对。”
+
+我接着问：“那你觉得花了一大笔钱买在线课程的那些人，都会乖乖上课听课吗？”
+
+对方露出了疑惑的表情说：“不见得，但在线课程跟保健食品不能直接对比吧？”
+
+我跟他说我们不用瞎猜了，请你从那些应该回购却没有回购的客人名单中挑选100位，打电话逐一跟他们确认两件事，第一，确认他们是否有开封，第二，确认他们是否有吃完，然后下个礼拜我们再来讨论你收集回来的数据。
+
+不到一周，我接到他的电话，他说：“真的被你猜到，客人有85%左右是还没吃完的，而这些客人里面有20%甚至连开封都没开，只有15%是吃完但没有继续回购的。”
+
+从这个案例中，我们可以得到以下启示：
+
+
+运营的数据若出现断链，决策就容易失准，我们必须尽可能掌握客户在线与线下的数据。
+获取客户后，必须要非常关注客户的首次使用体验，这环节我称为用户的onboarding，其他常用的词汇还有AHA moment与first success，总之，我们要尽可能确保用户的首次体验。
+客户首次使用后，必须养成他持续使用的习惯，让他获得原先期待的结果，以保健食品来说就是身体变健康了，以在线课程来说就是他真的学会了，进步了。
+
+
+在此，我再举一个先前我负责的在线学习平台的例子，其实学习类产品与保健食品之间有两个显着的相似性，第一，都是属于重要而不紧急的商品，短期内不学、不吃也不会造成重大伤害；第二，都不是用一次两次就会产生效果，而是必须使用一段时间才会渐渐看到成效。
+
+前一篇的数据力文章中，我提到常用的数据模型有三个：流失模型、续订模型与推荐模型，能让我们知道什么样的客户会流失、续订与推荐。
+
+在这个例子中，流失模型告诉我们，一堂课都没上的用户，对比有上一堂课的用户，退费率高达7倍之多；而续订与推荐模型则告诉我们，用户上课频率的稳定度高度关联于续订率与推荐率。
+
+在这些前提下，我请产品经理与运营经理去思考，在用户生命周期中，我们存在哪些断链？我们又该如何解决？请试着提出可能的方案。
+
+第一次提案时，他们认为改善用户引导功能会有助于用户完成首次上课，但如何让用户持续上课这个问题暂时没有方向。听完后，我问了他们几个问题：
+
+
+假设用户连上网后都没有打开我们产品，优化了引导功能有什么作用呢？
+用户上完一堂课，我们如何确保他会上下一堂呢？
+
+
+经过约一个小时的讨论后，运营经理针对首次使用提出了一个很不错的做法，他说：“可以让电销业务在成交后直接帮用户订好首次上课的时间，并让服务人员在上课前两天与当天联系客户，确保用户能完成第一堂课。”
+
+这个建议很好，跳脱了产品的边界限制，将其他资源也拉了进来。
+
+产品经理针对让用户持续上课这件事也提出了他的看法，他说：“我们必须要建立订课闭环，过去我们的流程是订课、上课、课后练习，但用户何时会订下一堂课呢？这我们一点把握也没有，若是我们将流程调整为订课、上课、课后练习、再订下一堂课，这样就形成了闭环，用户就能一堂一堂接着上了。”
+
+这个建议也很棒，直接从使用流程上改变了用户行为。
+
+上述两个做法，在经过两次迭代后全面采用，而为了降低运营成本，数据与技术团队们另外编写了信息推送服务，将引导、提醒与推荐系统化，有效的降低了人力需求。其中涉及了产品、技术、运营、业务与服务过程，若我们仍按过去的习惯，纯粹以技术解或产品解，而未从用户角度思考，并将各种可能的资源考虑进来，那根本无法有效的解决这个问题。
+
+同时，在讨论现场我们重新绘制了用户生命周期，特别强调用户留存，将首次使用、闭环设计、沉睡客户唤醒、触动回购与推荐设计作为重点，有效的留住用户，并进一步扩大每位用户的终身价值。
+
+从上述两个案例，我们可以了解到，每个产品的用户行为与生命周期虽然不尽相同，但都需要仰赖运营才能有效留存用户。当不同职能的人都能接触到公司的运营知识与流程时，你会发现大家都能从各自的专业领域提出有效的解决方案。
+
+数据可以帮我们找出用户行为的规律性，而运营则能让我们进一步对症下药，规划适当的运营活动让用户产生预期行为。
+
+结语
+
+用户导向，用户思维，这是在运营力中我想强调的核心观念，运营不仅仅是运营或产品团队的责任，而是所有人的责任，每个人都该了解运营，并学习运营相关的知识，才能围绕着用户不断提高用户体验。
+
+思考题
+
+你的研发团队内是否有人非常熟悉用户与用户生命周期？公司运营的关键点在哪？如何有效提高研发人员的用户与运营思维呢？欢迎在留言区跟大家分享你的经验。
+
+感谢你的收听，我们下期再见！
+
+作者简介
+
+游舒帆，昵称gipi，箴亚管理顾问公司负责人、TGO鲲鹏会台北分会学习委员。技术起家，后走入管理、产品、营运相关领域，历任鼎捷软件技术总监、TutorABC研发总监，熟悉B2B软件与在线教育。长年耕耘技术、管理与商业领域，现从事顾问、培训与教练工作，期许自己为社会输送更多的卓越领导者。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/084游舒帆：策略力，让目标与行动具备高度一致性.md

@@ -0,0 +1,109 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            084 游舒帆：策略力，让目标与行动具备高度一致性
+                            你好，我是箴亚管理顾问公司负责人、TGO鲲鹏会台北分会学习委员游舒帆，今天继续跟大家分享“一流团队必备的商业思维能力”这一主题。
+
+前几篇文章我们谈了数据力与运营力，让我们对公司与客户的状况有了进一步的剖析，本文将与大家探讨商业思维中的策略力。
+
+策略力的原始目的是希望让所有人都清楚公司的目标，以及为了实现这些目标，我们订下了什么样的策略，紧接着，策略又是如何落地为一个又一个日常的项目与营运工作的。
+
+以传统的组织分工来说，研发团队通常位于后勤角色，多数都是以支持各业务部门的战略为主，然而战略经过层层传达后，实际执行项目的一线员工们往往无法获知自己每天的开发工作，究竟是为何而做，更不明白项目完成后，究竟会对哪个KPI或目标有具体帮助。
+
+有些人认为一线员工，尤其是研发同仁，并不需要了解公司战略与目标，只要专注的处理手上的项目就好。但我认为所有员工都必须要对战略与目标有清晰的理解，原因有四：
+
+
+第一，让员工明白为何而战，唯有知道自己这么努力是为什么，员工才会倾注百分之百的热情。
+第二，避免战略与现实脱钩，上层拍脑袋想出来的战略，很多时候并没有参酌一线员工的建议，不让听得见炮火的士兵参与战略的讨论与沟通，是许多企业最终战略失准的重要原因。
+第三，培养员工的战略意识，具有战略意识的员工，在做每一件事情时都会仔细评估与思考，确保能对公司战略与目标产生真正帮助，而不会像只无头苍蝇般四处乱窜。
+第四，让员工的绩效明确化，当员工所做的每件事都能连结到重要的KPI与目标时，员工的每分每秒就都能投入在有价值的事情上，回顾工作绩效时，一来，管理者易于评估，二来，员工也会很清楚自己的贡献与成长。
+
+
+在培养员工战略思维能力时，我的做法并不是单纯的告知他们公司的战略目标是什么，而是进一步引导他们去思考战略的成因。一般来说，我会以下面5个步骤来引导大家将战略推导出来。
+
+第一个步骤，检视现况，并标定机会。
+
+检视现况时我会先抛几个问题让大家有切入点，这些问题分别是：
+
+
+有哪些新的趋势议题与我们所属产业相关？我们是否能乘上风口？
+我们产业的关键价值活动是什么？是否能延伸在产业链的位置？
+我们的经营关键点与商业模式是什么？能看到什么突破口？
+平常我们仰赖哪些数据在做管理？哪些数据有改善或精进的空间？
+
+
+之所以要让大家思考这几个问题，而非直接从过去的经营内容中找出可改善的点并持续去调整的原因，是为了避免大家只着眼于短期，却忽略了长期的可能性。
+
+这几个问题思考完后，接着要标定出“可能的机会”，我们要在众多机会中指出“属于我们的”机会，也就是必须要在评估自身资源与可行性后，挑出那些确切可行的项目。
+
+谈到这时，你可能会有个疑问：“老板已经设定好自己的方向与目标了，我们还需要花时间做这些事吗？落实老板的战略不就行了？”
+
+我的答案是：“需要的”，因为企业的战略的形成有两种，一种是自上而下，由领导阶层定义好，并逐层往下展开，落实到第一线人员的日常工作中；另一种则是自下而上，由对现场掌握度最高的一线人员提出，并纳入公司的战略中。就算是研发部门也应该要有自己部门的战略，并有效的连结到公司整体战略上。
+
+企业的战略，其实人人都该关注，也该从你专业的角度提出你的看法与观点。若战略制定时，自上而下与自下而上能同时进行，双管齐下，走偏与白费工的机率就会大幅降低。因此，我认为“战略的制定与执行是全体员工共同的责任”。
+
+第二个步骤，设定目标。
+
+我们必须在第一个步骤中标定出的这些可能的机会中，找到最应该实践的几件事，设定目标。如果你是一个在线学习平台的CTO，你设定的目标可能是发展人工智能以提升学习体验，或者是提高用户使用平台体验，进而提高留存与完课率。如果你是运营总监，你的目标可能是用户规模的三倍增长，或者有效降低用户流失率。
+
+在此，我希望大家更审慎的设定目标，因为一个清晰的目标具有很高的引领效果，模糊的目标则会导致大家各自解读。那什么样的目标才算清晰呢？我认为必须要符合SMART原则：
+
+
+S是Specific，具体明确的，要完成的项目包含哪些事？不包含哪些事？
+M是Measurable，可衡量的，必须要有可量化的结果来确认事情已完成，否则很难去分辨「做好」与「做完」。
+A是Attainable，可达成的，这个目标不应该是遥不可及的，虽然我们常说要设定高目标才有高达成，但如果这个目标怎么看都不可能，那反而会让大家无所适从，而且资源的使用也容易失准。
+R是Relevant，具相关性的，承担这个目标的部门或人，他的工作项目必须要能高度关联于这个目标，否则便不该由他来负责。
+T是Time-bound，具时效性的，三个月达成100%用户增长跟一年达成100%增长，做法肯定会有很大的差异。
+
+
+第三个步骤，定义关键结果。
+
+当我们设定好目标，接着要怎么去衡量目标是否达成呢？我们必须要能看到几个关键的产出物或结果，也就是所谓的关键结果(Key Results)，往下我依循谷歌等知名国际公司运用的目标管理工具OKR(Objective and Key Results)来跟大家说明。
+
+举上述学习平台运用人工智能以提升学习体验这个目标为例，我们若要有效衡量这个目标是否已经完成，我们可能会想看到以下三个关键结果：
+
+
+第一，人工智能技术应用于的课件编辑，有效降低课件出错率自8%到4%；
+第二，人工智能技术应用于学生学习过程，提高学习满意度从8.9分到9.2分；
+第三，人工智能技术应用于课程的精准推荐，提高学生的周订课数从2.2堂到3堂。
+
+
+定义好关键结果，团队的努力方向就更明确了。谈到这我也必须要再次强调一个观念，那就是“别将手段当目的”、“技术也不是唯一解”，如果你在执行过程发现，不使用人工智能技术也能有效达成上述三个关键结果，而且做法更好更容易，那你就可以考虑放弃人工智能，因为人工智能是达成关键结果的手段，而非目的，降低课件出错率、提高学习满意度、提高订课数相对更接近目的。
+
+再往上推一层，我们的根本目标是提升学习体验，若执行过程发现这三个关键结果与学习体验的关联性并非最强，那你就该调整这个目标的关键结果，不要被定义好的东西给绑死了。而这也是OKR跟传统KPI间一个比较显着的差异，OKR接受来自执行层的反馈，随时可以依照现况去调整关键结果。
+
+第四个步骤，设定行动方案。
+
+有了具体的关键结果，那我们要做哪些事来达成这些关键结果呢？此时就落入到项目层级了，你必须为每个关键结果设定1-2个行动方案。
+
+举例来说，提高学习满意度从8.9分到9.2分，在讨论过程我们认为影响学习满意度因素的有老师、课件、学生参与度、师生互动、网络通讯质量等，而我们认为学生参与度与与师生互动影响最大，但也不排除有其他影响因素，因此我们制订了以下两个行动方案。
+
+第一个行动方案，采集学生上课期间的面部表情、对话与课后评价数据，并运用人工智能技术判断学生在课堂中的反应与参与度，如果学生表情显示有疑问，或者课堂的参与度不好，总是分心，那可直接提醒老师要多关怀该位学生。
+
+第二个行动方案，调整学生课后的评价功能，从只能评分的选单式改成选单加标签式，让学生在评分之余，还可以透过标签来反馈感受好与不好的部分，这能让我们尽可能掌握学生真实的感受。
+
+最后一个步骤，复盘。
+
+行动方案开始执行后，我们必须定期检视执行进度与成效，根据现况不断修正行动方案、关键结果，有必要时甚至连目标都要修正。
+
+总结
+
+识别机会、标定目标、定义关键结果、设定行动方案到复盘，合理来说，识别机会阶段，领导阶层的参与度较高，标订目标、定义关键结果阶段，则是领导阶层与基层共同参与，而设定行动方案则以基层为主来进行，最后的复盘则由基层根据现况汇整结果，提出观察与建议后与领导阶层共同决定修正方案。
+
+让员工具备策略力，让公司与团队上下都参与战略制订与执行过程，让所有人清楚自己是为何而战，员工的参与度会大幅提升，所有人都能紧扣着最重要的目标前进，我们才能真的让高层与基层间的沟通如臂使指般的顺畅运行。
+
+思考题
+
+如何清晰的描述公司的目标与策略？如何明确告知每个同仁，他在做的项目与哪个目标或关键结果有关？盘点你日常工作中，又有哪些其实是无法有效链接到任何目标或关键结果的？这几个思考会有助于你厘清现况，把时间花在真正重要的事情上。
+
+感谢你的收听，我们下期再见！
+
+作者简介
+
+游舒帆，昵称gipi，箴亚管理顾问公司负责人、TGO鲲鹏会台北分会学习委员。技术起家，后走入管理、产品、营运相关领域，历任鼎捷软件技术总监、TutorABC研发总监，熟悉B2B软件与在线教育。长年耕耘技术、管理与商业领域，现从事顾问、培训与教练工作，期许自己为社会输送更多的卓越领导者。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/085游舒帆：敏捷力，拥抱不确定性，与VUCA共舞.md

@@ -0,0 +1,92 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            085 游舒帆：敏捷力，拥抱不确定性，与VUCA共舞
+                            你好，我是箴亚管理顾问公司负责人、TGO鲲鹏会台北分会学习委员游舒帆，今天继续跟大家分享“一流团队必备的商业思维能力”这一系列文章。
+
+这是本系列最后一篇文章，今天要来跟大家聊聊敏捷力。敏捷这个词在互联网爆发成长的这些年，早就已经被谈到过火，但这么多年观察下来，我发现敏捷这词被过度的曲解与滥用了，怎么说呢？
+
+
+有些人以为每天早上开个站立会议、用白板来管理开发
+工作，这就是Scrum，就是敏捷实践；
+有另一群人，把需求变来变去，朝令夕改，让技术团队不断变更优先级，搞得大家疲于奔命，然后丢下一句“你们要更敏捷才行”；
+最糟糕的是那些，明明能花点时间就把问题厘清，少走许多冤枉路的事，却要急就章去做，然后碰个满鼻子灰才回过头来修正，说“我们要加快迭代速度，才能应付这些不确定性”，其实，很多不确定性都是自找的。
+
+
+对敏捷错误的认知，很容易导致错误的结果，在长鞭效应的影响下，流程最末端的研发团队与程序员们，却必须以超时工作来填补因为项目的不断变更而衍生的额外工作。身为技术领导者，千万不能以这种错误的敏节观念做事，否则最终将累死自己，也累死团队。
+
+若你想了解敏捷真正的精神，我建议你看看agilemanifesto.org上所述的敏捷12原则。
+
+拉回主题，为何我将敏捷力放在商业思维系列文章的最后一篇？
+
+首先让我们回顾一下前面几篇谈到的内容：
+
+
+数据力，让你掌握公司现况，而且有数据的支撑，我们跨部门沟通与做决策时，会更有依据，更准更高效是一个可以期待的结果；
+运营力，所有的任务都围绕着为客户提供价值，任何无法为用户产生价值的事，也无法为公司带来长期利润，这样的思路，有助于提高决策时的一致性；
+策略力，让公司的目标从上到下认知一致，所有人都知道为何而战，所有人都能站在战略角度思考，决策不容易失准，而且战略的调整速度也会快上许多。
+
+
+总结一下，数据力，让信息一致且透通；运营力与策略力则有效的凝聚了共同的方向与目标，三者对于企业的敏捷性都有极大的帮助。
+
+我曾在台湾敏捷峰会上与大家分享一句话，在这也分享给大家：“如果敏捷走不出技术团队，就不可能真正敏捷”。若我只在研发团队内推动敏捷，成效其实非常有限，因为外部的其他人，总是会成为我们走向敏捷的阻碍。
+
+因此，为了强化团队的敏捷性，我做了以下几件事：
+
+首先，我以矩阵式组织重组了研发团队。
+
+我将团队分成两种类型，一种归属于产品团队，另一种则划分到功能部门，每个部门由一到两个产品经理负责，让产品经理们可以深入的参与到公司的各个业务过程。
+
+当研发团队与业务团队能更紧密的参与彼此的工作，绩效也互相挂勾时，默契与信任感就会渐渐产生，信息更透通，行动也更敏捷了。
+
+第二步骤，建立彼此对优先级的认知。
+
+我在技术领导力第51讲中曾提到三种决策方式：权力决、共识决与数据决，这三种决策方法我更倾向于数据决，但前提是这个数据是大家能信任，而且认可的。
+
+为此，产品经理必须要跟业务部门一同敲定排优先序的规则。在排序之前，首先要将会影响优先级排序的要素陈列出来，例如提升业绩、提高用户体验、提高系统稳定性与性能等，给每个要素一定的权重值，并试算出每个项目的价值，价值愈高的优先级愈靠前。
+
+权重值与排序规则通常会经过几次的修正，最终才能为大家所认可，做这件事的目的除了更高效的去排序工作外，更重要的是提升了彼此对事情的认知，我们都清楚对方在意些什么，也容易凝聚共识与目标。
+
+此外，在面临难以抉择的选项时，业务部门也要给与产品经理足够的信任，尊重产品经理的专业决策。
+
+第三步骤，加快迭代脚步，将项目切小，并优先执行最有价值的部分。
+
+这个步骤看似简单，但若没有前面两个步骤来提升信任感与建立共识，落实的难度其实挺高的。过去项目较大，时程估期可能都在3-6个月，做价值排序时也是就整个大项目来计算。现在为了加快迭代速度，往往将项目切成2-4周交付一次，项目的顺序将有很大的变化。
+
+举例来说，原先有个项目A要依序完成1.2.3到10，共10项工作，为期4个月，项目的价值是带来4,000万业绩。现在我们若要将项目切为A1、A2、A3、A4四个迭代项目，我们必须针对原先的10项工作做重新的排序，可能A1先做1.3两个需求，完成后可以带来2,000万业绩，A2则完成2.4.5三个需求，完成后可以带来1,000万业绩，也就是说我们仅完成了50%的需求，却已获得75%的价值。
+
+剩余的A3、A4的价值只剩1,000万，拿来跟B1、C1等比较，重新排序后或许我们该优先进行B1而非A3。而这就是将项目切小后的好处之一，让我们总是能优先进行价值最高的工作。
+
+然而项目切小，对研发团队来说也是一个挑战，过去走waterfall的开发流程时，大家都很习惯将需求访谈期拉长，测试到布署的时间也往往估的较长，当项目最前与最后的工作都需要花费1周时，一个只有4周的项目开发时间便剩余2周了，这样的产出效率很难让人接受。因此，研发团队必须持续改善工作方法与流程，缩短项目的前后置时间，进一步提升生产效率。
+
+第四步骤，凝聚共识，持续追求更快、更好、更有价值。
+
+如我在前一篇策略力时所说，若你发现不利用人工智能技术就能创造出关键结果，那你可以选择不用。“解决问题，不必总是仰赖技术”这个观念我们也持续推广到研发部门外，让大家了解不是凡事都得靠系统，若时间真的急迫，但研发部门暂时排不出资源，我们还是会从专业角度提出其他建议方案。
+
+我在技术领导力第51讲中曾举了个例子，是请客服部门先以人工服务的方式来提供产品预计要开发的功能。这个项目之所以能顺利推行，很大一部分仰赖于我们始终追求“更快交付价值”这个原则，否则程序员不会提出这样的建议，我也不会采纳这种非技术解决的方案，而客服主管更不会同意这种高度依赖人力的服务方式。
+
+看到这，或许你会有个疑问，我们这样做难道不会只顾了短期需求而忽略长期吗？不会的，因为我们通过更短的交付周期，倒逼团队将每个项目的价值讲得更清楚，也因为更深入的参与了彼此的日常工作，沟通的落差减少了许多，并且因为具有足够的信任感，部门之间往往都能互相帮忙。
+
+第五步骤，针对面临较高不确定性的部门，持续协助导入敏捷流程。
+
+比如营销部门，过往他们最难回答的问题就是，一个活动举办后大概能创造多大的成效，导致大多数的营销项目最后都是超支预算才能达成原先的业绩目标。在营销项目上，我们以多个小项目同时推进的小步快跑的迭代方式，通过市场反馈与数据分析提高对现况的把握程度，更精准的达成了项目原始的目标。
+
+若要拿实质成效来说，过去需求多数都来自于业务部门与高层，在我们持续推动商业思维与导入敏捷约莫一年后，研发团队的工作中，仅有50%来自业务部门与高层，而剩余的50%则来自研发团队自提的需求。我们清楚如何呈现技术型项目的价值，也知道我们应该优先做哪些事才能帮助公司达标。
+
+总结
+
+当所有部门都正确理解了敏捷，而非把敏捷视为研发团队的责任，企业才可能真正敏捷，面对多变且不确定的环境时，才能同舟共济，以达成目标为首要。
+
+商业思维围绕着商业目标、用户与价值导向交付，将商业最核心的几个要素都含括在内，过去两年我不断在团队内传递这些重要的观念与知识，团队的凝聚力更强，组织运作也更高效了，创造的价值也提高了许多。
+
+本系列文章到此告一段落，大家可以回顾一下这几天我们谈到的内容。再次思考数据、运营、策略与敏捷在工作中扮演的角色，并适度的将这些知识与观念普及于团队内。若你在看完这几篇内容后有任何问题，欢迎提出讨论。
+
+作者简介
+
+游舒帆，昵称gipi，箴亚管理顾问公司负责人、TGO鲲鹏会台北分会学习委员。技术起家，后走入管理、产品、营运相关领域，历任鼎捷软件技术总监、TutorABC研发总监，熟悉B2B软件与在线教育。长年耕耘技术、管理与商业领域，现从事顾问、培训与教练工作，期许自己为社会输送更多的卓越领导者。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/086刘俊强：管理者必备的高效会议指南（上）.md

@@ -0,0 +1,88 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            086 刘俊强：管理者必备的高效会议指南（上）
+                            你好，我是腾讯云资深架构师、TGO鲲鹏会会员刘俊强，有着8年以上的技术管理经验，今天想跟你分享一份“管理者必备的高效会议指南”。
+
+在技术管理者的工作职责中，与团队保持良好沟通是必须的技能，而会议是沟通和完成实际工作的高效途径之一。
+
+你有没有过这样的经历，参加某次会议时感觉自己的时间被浪费了，恨不得立马逃离现场去别的地方？作为管理者，我们希望自己所带领的团队举行会议时，不会让与会人员也有如此感受，本文就将探讨如何让会议高效化，并从会议中获得最大收益。
+
+我将介绍一些举办高效有用会议的原则，会议之前的准备清单，确定最佳会议时间和创建会议议程的策略、贴士和技巧，以及在会议结束后该做的跟进工作等。
+
+需要提醒的是，本指南主要面向的是小组会议，也就是至少三人参加的会议，不包括大型技术会议。而对于一对一的私人会议，之后将有另一篇文章来探讨——《做好一对一沟通的关键要素》。
+
+成功会议的六个原则
+
+举行高效会议会有许多原则，这里整理出来六个必不可少的原则，整个指南中，我们将遵循这六个原则来组织构建我们的会议：
+
+
+明确目的：每次会议都应该有明确的目的，但事实是很多人都会随便开会，可能他们认为开会是个解决问题的方法。每次会议都应该有一个目标，这是我们举行或参加会议的原因，因此在安排会议并邀请其他人参加会议之前，首先要问自己这个问题，我想从这次会议中得到什么结果？
+确认时间：简而言之，会议应该开多长时间？虽然会议长度没有严格的标准，但是我们的经验表明，会议越短越好。另外，会议可能会经常超时，简短而安排有效的会议，能迫使参会者在有限的会议时间内做出明智的决定。
+必备议程：会议议程是参会者在会议中遵循的步骤大纲。议程可以帮助我们让会议更加专注，不让会议随意发散开来，本文稍后就将探讨如何创建议程，以及如何使用议程让每位参会者能够在会议中发表意见。
+做好准备：在参加会议之前，每个参会者都应该花一些时间准备他们的问题，以及如何让他人明晰这些问题。本文将分享一些简单的方法，让准备工作变得简单，也对提高会议效率很有帮助。
+专注重点：专注并坚持会议的目的，使会议参与者保持在正确的轨道上，让他们倾听、保持专注、避免多任务处理。重点缺失会使会议参与者容易分心，不能够专注地解决问题。
+会议负责人：会议由谁负责？会议负责人可以是行政人员、经理或指定的会议主持人。无论这个人是谁或他们位居什么职位，每次会议都应该有会议负责人，会议负责人确保会议遵循以上五个有效的会议原则。他们使会议专注于目标并实现目标、确保会议按时开始和结束，并帮助其他人为会议做好准备且保持专注。
+
+
+管理者越多使用上述六个高效会议原则：明确目的、确认时间、必备议程、做好准备、专注重点以及会议负责人，会让会议变得更成功而高效。
+
+会议类型
+
+没有一种会议类型可以满足所有需求，因此，面对不同的需求使用不同类型的会议是个好主意，可以实现最好的会议效果。有几种方法来对会议进行分类，这里我们使用时间维度，一般分为每日会议、每周会议和每月会议这三个主要类型。
+
+每日会议可以有很多种，例如 Scrum 会议或每日站会、碰头会等。通常每日会议的目的是让每个团队成员签到并报告当天正在进行的工作，然后迅速投入工作，因此，这种会议的关键是要保持会议的简短。虽然本文分享的原则也适用于每日会议，但这种会议一般不会有特别正式的会议议程，并且也不需要花太多时间来培训团队成员。
+
+下一种会议类型是每周一次，这也是最常见的会议类型。每周一次的会议一般来说更为正式，它的目的不仅仅是快速检查工作，还包括更多的合作和协调工作。因为这是最多的会议类型，所以本文的大部分内容会面向这种类型的会议展开。
+
+最后一种类型的会议是每月、每季度或每年会议，一般来说用于培训、评审以及工作回顾等。通常，这类会议的目的是宣布一个新的重要项目，或者是帮助团队达到更高层次能力的培训，抑或是对于一段时间内的工作总结和回顾等。因此，本文中的大多数原则也仍然适用。
+
+当你在看本会议指南时，不要试图一下子改善你所有的会议表现，而是选择这三个类型中的一个并集中思考怎么改善。在此我先提出一个问题，该如何使用在本文学到的原则来提高会议质量呢？
+
+会议中的具体工具准备
+
+随着技术的进步，我们开会的工具也在变化，例如投影、电视或在线会议等，相信不少人都有过因为工具的技术问题而造成会议停滞或拖延的经验，不过技术的进步也让各种会议工具的体验越来越流畅了。
+
+为了使你和其它参会者的会议更加有效，我这里提供了一个非常简单的清单，会议负责人可以在每次会议开始之前使用。这个清单一共覆盖三种会议方式，一个是电话会议，另一个是需要演示的会议，最后一个是视频或网络会议。在每次会议开始前大约一小时用这个清单是个很好的做法，可以确保工具技术的每个方面都被检查且正常运行。
+
+使用这个示例清单时要记住几件事，首先，它专为通常在公司或其他组织内部进行的小型会议而设计，并不适用于大型活动。此外，该清单的设计非常通用，适用于各种情况，因此，你可以根据自己的独特需求进行定制。
+
+
+
+在任何会议中，确保每个人都有机会被听到和看到是会议负责人的工作，会议中的具体工具，需要你根据自己实际需求进行评估，例如网络摄像头、投影仪以及在线会议系统等，并询问 “如果我购买使用” 这些工具，它会极大地 “提高会议质量” 吗？
+
+选取会议负责人
+
+前面有说到，根据我的经验当会议有指定的负责人时，会议效果最好。会议负责人的责任是使会议保持专注和富有成效，他们提醒参会者基本规则，并且负责会议计时。
+
+如何选择会议负责人可以根据你的方法来，一种简单的方法是基于职位，即让会议中最高职位者来做会议负责人，如技术经理、技术总监、项目负责人或首席技术官等，都可以担当会议负责人。这种方式的好处是已经包含了汇报架构和问责制，这种方法的缺点则是其他参会者可能就不会有机会来负责会议，另外，将职位最高者指定为会议负责人有时会让其他人觉得会议始终是由一个人控制或主导的。
+
+选择会议负责人的另一种方法是轮换，让每个会议参与者都有机会来担当，任何方式的轮换都可以。这种方式的优势在于，它为通常不具备管理或领导职位的参会者提供了发展和实践领导力的机会，并且可以增加团队成员的工作满意度。同时，如果该小组的每个成员都有机会让其他人对基本规则负责，那么通常会增加他们对这些规则的遵循程度。
+
+这种方法的缺点可能是，不同会议负责人带来的基本规则执行和重点不一致，小组内也有可能存在不想管理或领导的成员，强迫他们负责会议可能会带来反效果。另外，临时负责人可能不会像有经验的持续负责人那样做好准备，需要进行必要的辅导和指引才能很好胜任。
+
+不论选取哪种方式，只要你选择一种方式并始终如一地使用，并不断修正该方法的弊端，都会取得不错的会议效果。因此，无论是现在，还是在下次会议开始时，确保你的每次会议都有一位会议负责人。
+
+总结
+
+受限于篇幅，本文中，我和你分享了一些举办高效有用会议的原则，包括明确目的、确认时间、必备议程、做好准备、专注重点以及会议负责人，合理运用这六大原则，可以让你的会议变得更成功而高效。
+
+此外，我还和你分享了每次会议都要确保其有会议负责人，会议负责人可以是固定的，也可以是轮换的，各有其优缺点，但不论选取哪种方式，都要不断运用，并不断修正该方法的弊端。
+
+下一篇文章中，我将跟你分享创建会议议程的具体策略、贴士和技巧，以及在会议结束后该做的跟进工作等，欢迎继续关注。
+
+思考题
+
+你平时组织会议时有遵循这六大原则吗？如果没有，之后准备如何改善呢？
+
+感谢你的收听，我们下期再见！
+
+作者介绍
+
+刘俊强（微信公众号：程序员精进）现任腾讯云资深架构师，曾任迅雷技术总监、某互联网公司技术副总裁，10+年以上互联网开发经验，8年以上技术管理经验。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/087刘俊强：管理者必备的高效会议指南（下）.md

@@ -0,0 +1,82 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            087 刘俊强：管理者必备的高效会议指南（下）
+                            你好，我是腾讯云资深架构师、TGO鲲鹏会会员刘俊强，有着8年以上的技术管理经验。会议是技术管理者保持沟通、推动工作的必要手段，因此，如何确保会议高效且有效，是技术管理者必备的技能之一。
+
+昨天的文章中，我跟你分享了举办高效会议的六大原则，包括明确目的、确认时间、必备议程、做好准备、专注重点以及会议负责人。还和你分享了会议负责人的重要性，他能确保会议遵循其余五个原则，能使会议专注于目标并实现目标、确保会议按时开始和结束，因此，每个会议都要确保有一位会议负责人。
+
+今天，我将继续“管理者必备的高效会议指南”的下篇，与你分享创建会议议程的具体策略、贴士和技巧，以及在会议结束后该做的跟进工作等。
+
+创建会议议程
+
+这里我有一个会议议程的模板，根据你选择会议的类型，模板的某些部分不一定完整匹配你的需求，你可以随意调整这个议程模板并创建属于自己的议程模板。接下来，我将简单介绍该模板的使用指南，也就是怎么利用会议议程模板来举行高效会议。
+
+
+我们先看看这个模板的左侧，这些是你在开会时要记住的重要指南，是我们举行会议时的重要参考，因为往往容易被忽略，所以我们再拿出来回顾下，从上至下分别是：
+
+
+最终结果是什么？例如，在每次会议结束时，所有与会者都应该感受到被尊重，重视并且明确未来的行动步骤等。
+为什么要举行此次会议？例如工作协作或协调类会议，帮助减少合作时的摩擦等。
+与会人员，谁应该参加这次会议？何时举行会议，我们应该多久见面一次？
+如何衡量会议是否成功？比如与会者请求帮助，会上成功给予其完成工作的必要帮助。
+工具或资源需求有哪些？例如必要的资料（开发、产品），承诺完成的相关资料，会议记录和代办事项的系统等。
+
+
+再次强调，模版不一定完全匹配你的需求，你可以根据自己的实际需求来调整这些原则。
+
+接下来我们再来看看这个模版右侧的“会议执行步骤”，也就是会议该如何进行？
+
+首先是准时开始，然后，会议负责人欢迎大家，此时负责人应该帮助与会者感到宾至如归。第三步，会议负责人向与会者简短的演示或培训有关会议内容、工具资源等相关内容，这个过程应该控制在大约三到五分钟内。
+
+小组会议议程的第四步是让每个人快速报告他们在上次会议上所做的承诺，逐个询问每个人是否做到了，与会者回答是或否。接下来，将会议剩余时间减去五分钟留作总结时间，其余时间在成员之间平均分配，确保每个与会者都有发言权。举个例子，如果剩下30分钟并且有五个参与者，那么每个人将有五分钟的发言时间。
+
+在最后五分钟内，会议负责人或会议记录员需要回顾并总结每个人在会议期间所做的承诺，然后再次确认下次会议的日期和时间。如果是轮换会议负责人的方式，还要确认下次会议的会议负责人。最后，尽量尽早结束会议，最好不要超时，通常会议时间越短效果越好。
+
+跟进承诺任务
+
+与会者在上次会议中确定的工作任务或承诺，需要在本次会议时进行汇报。这个过程实际上非常简单，会议负责人利用上一次会议的会议记录，朗读每个人的承诺，并简单地问道：“你这样做了吗？”，如果答案是肯定的，那么会议负责人可以提供简短的回答，如 “干得好” 或 “谢谢”。
+
+但如果答案是否定的，会议负责人需要问对方“是什么妨碍你完成？” 或者 “遇到了什么障碍？”等类似的问题， 这比询问诸如 “你为什么不这样做？” 之类的问题要有效得多，因为后者非常强硬，并且经常会让人感觉是责备。这里我们不想责备或羞辱他人，相反，我们是要试图找到帮助他们完成工作的解决方案。
+
+会议负责人应避免参与有关此人未完成承诺工作的延伸讨论，我们需要的只是简要解释发生的事情。如果此说明生成了一个主题，小组或会议负责人希望与所有与会者进一步讨论，那么可以将其添加到任务列表中，以便稍后讨论。
+
+如果他们未能完成任务，则需要让他们对完成任务的日期和时间作出新的承诺，并在新的期限之前完成它。
+
+在收到关于上次会议的待办事项或任务列表完成情况的简要报告后，你需要在其之上记录任何新的承诺，然后保持会议继续进行。通过采用这种方法，你可以提高承诺的完成率，并使会议更有意义。
+
+如果你发现某人一直未能完成承诺的工作，那就需要进行一对一会议沟通了，而不要在小组会议中直接进行批评或指责。一对一会议是管理者协助员工履行承诺，以及探索导致员工缺乏后续行动力的深层原因的好方法。
+
+另外，在会议上，你可以寻找每个参与者都做得好的事情并对其进行评论，给予对方简短、真诚的赞美，表明你已经看到他们的努力和付出。
+
+结束会议
+
+会议议程的最后一步是审查每个人的待办事项或工作任务，在整个会议期间，与会者可能都已经承诺将在某个时间内完成某些事情，通常在这一点上，会议负责人会将其转交给记录员，并要求他们总结承诺。
+
+会议记录员会使用“谁、什么和何时”这三个要素总结每个人的承诺。换句话说，谁做出了承诺，他们要做什么，他们将在何时实现它，就这么简单。
+
+在会议记录员通读列表时，每个与会者都应该密切关注并确保他们同意正在审核的承诺。
+
+在审核了每个人的待办事项后，会议负责人就可以结束会议了，可以通过简单地确认下次会议的时间、会议地点以及确认任何其他会议来做到这一点。
+
+如果需要在常规会议日程之外更详细地讨论有争议的话题，会议负责人将提醒每个人特别会议，并确保会议排上了他们的日程。
+
+总结
+
+本文中，我们已经探讨了一个可以在任何公司使用的高效会议框架，以提高会议效率并专注于结果为目的。如果你遵循本指南的建议，会议的有效性及效率应该得到改善，我希望确保你的会议每次都变得更好，最好的方法是制定一个计划，不断重新评估会议的有效性，也许可以每季度一次，使用会议的一部分时间向每位与会者询问 “这些会议是否有效？”，并根据反馈不断改进。
+
+思考题
+
+在介绍完高效会议指南后，咱们不妨在此思考下，接下来你要进行每周工作回顾会议，使用本文的操作方法或技巧，该怎么来准备、执行会议并保证会议执行的有效且高效呢？
+
+感谢你的收听，我们下期再见！
+
+作者介绍
+
+刘俊强（微信公众号：程序员精进）现任腾讯云资深架构师，曾任迅雷技术总监、某互联网公司技术副总裁，10+年以上互联网开发经验，8年以上技术管理经验。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/088刘俊强：做好一对一沟通的关键要素（上）.md

@@ -0,0 +1,85 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            088 刘俊强：做好一对一沟通的关键要素（上）
+                            你好！我是腾讯云架构师、TGO鲲鹏会会员刘俊强。在《管理者必备高效会议指南》一文中，我们探讨了如何高效地进行一对多的会议，使小组会议成为有效的沟通渠道。
+
+今天，我想跟大家分享的是跟团队成员沟通的另一种有效方式，即一对一会议。一对一会议一般用于绩效面谈、员工问题指出以及职业发展规划等场景。定期的一对一会议为管理人员提供了解决问题的机会，并有效地回答了工作周期内出现的许多小而快速的问题。一对一会议还可以帮助员工提升技能，并能够有效改善团队的沟通情况。
+
+在本文中，我将跟大家分享举行高效一对一会议的原则，以及如何建立一对一的会议议程，如何分配待办事项并回顾待办事项，如何评估会议结果并跟进完成情况等。
+
+一对一会议的重要性
+
+一对一会议是管理人员和团队成员相互沟通、互相跟进，并了解彼此工作关系的重要渠道。定期举行的一对一会议是最强大的管理工具之一，可以使管理工作事半功倍。
+
+一对一会议是一个管理者和团队成员双方都应该感受到尊重和重视的场合，在这里，双方可以开诚布公地问对方问题。因此，一对一会议可以增强团队和你之间的信任感，并有效改善团队的沟通情况。
+
+需要注意的是，一对一会议不适合头脑风暴和项目创建类场景，这些通常更适合在项目会议或定期小组会议中被处理。一对一会议也不是批评和强烈纠正问题的地方，虽然偶尔会有反馈和小的修正，但如果出现有待讨论的严重问题，应该在一对一会议之外进行讨论。一般而言，一对一会议更适用于你每天或每周定期与团队成员沟通。
+
+谁需要进行一对一沟通
+
+当我们说到一对一会议时，有些人不太确定他们应该与谁举行这样的会议。为了帮助你确定一对一会议的最佳人员，我提供了一个简单的工作表，可以引导你完成决策的制定过程。
+
+
+
+现在我们来看看这个表格，第一列是“姓名”列，需要你在此写下经常一起工作的团队成员的姓名。第二列到第六列是评估列，我们将通过这几列的分数来评估你与每个团队成员的工作关系。
+
+其中，第二列是“管理关系”列，它的可选值是0或3，当答案肯定时填入3、否定时填入0，也就是，如果你管理着这位成员或者他在管理着你，就填入3，反之则填入0。
+
+第三列是“问题”列，即多久问对方一次问题；第四列是“委派”列，即多久委派任务给该成员，或多久被该成员委派任务；第五列是“协调”列，即是否经常与该成员协调日常安排；第六列是“跟进”列，即多久跟进一次该成员。
+
+这些列的分值都在0-3之间，0代表从来不、1代表很少、2代表偶尔、3代表经常。当然，填写时不需要特别精确，因为它只是一个主观的尺度，只是想借此找出需要一对一沟通的团队成员。
+
+填写完毕后，将第二列到第六列的分数相加得出总分，然后根据总分高低进行排序。我的建议是，经常与表格中排名前三、前四名的成员进行一对一会议。
+
+建立时间表
+
+在你决定跟哪些团队成员进行一对一会议后，下一步就是建立时间表。
+
+具体的会面频率以及会议时长，并没有一个标准答案，不过，以我的经验来看，最常见的一对一会议时间表是每月两次，每次会议时长为25分钟。因此，如果你不太确定该怎么处理，可以参考这个经验。
+
+如果你认为每月两次会议不够的话，频率可以安排更高一些，但次数越频繁，会议时间就应该越短。总而言之，会议安排上可以比较灵活，但要确保留有足够的时间讨论我们可能遇到的各种问题。
+
+确定了会议频率及时长之后，接下来就要将一对一会议排入你的日程，并让它形成定期模式，成为一种习惯。如果你不遵守时间表，一直错过会议时间，那会议的效果就会大打折扣。因此，坚持会议计划很重要，能让参会双方都感受到大家对于这个会议的重视和尊重。
+
+确定议程
+
+现在你已经建立了一对一的会议日程，接下来你可能想知道，议程是什么？应该涵盖哪些内容？下面我将提供一个简单的会议议程模板，你可以根据自己的特定需求调整此大纲。
+
+
+
+首先，准时开始会议，这确立了互相尊重彼此时间和会议本身的价值。
+
+其次，跟进上次会议中承诺的待办事项。如果对方达到预期，就可以赞美他，并问问对方从中收获了什么；如果对方没有达到预期，就可以问问对方遇到了什么阻碍，并对他进行指导修正。这很重要，因为我们在这些会议中所采取的行动与我们贯彻执行的能力一样宝贵，所以一定要检查参会者是否履行了承诺。
+
+然后，进行简单的成长辅导或培训，大约三到五分钟。无论与谁见面，这都是一个很好的学习机会，可以帮助彼此逐渐成长。接下来到了议程的第四步，让对方有机会向你倾诉他的需求，你要耐心地听，让对方有机会询问他想问的问题。议程的第五步，你将扭转角色，现在，你有机会向对方提问并提出要求，包括将任务委托给对方。
+
+之后，请回顾你们在会议期间彼此所做的承诺，这是你在下次一对一会议开始时需要检查的事情。最后，按时或早点结束会议，同样，这表明了对彼此时间的尊重。
+
+帮助个人提升
+
+当你是一名管理者时，一对一会议为你提供了一个帮助他人提升的机会，使你有机会为另一个人提供一些有针对性的培训。但由于一对一会议本身时长就相当短暂，所以，你需要保证培训内容简短、明晰，时长最好控制在五分钟内或者更短。那么，每次培训内容如何选择，用何种方法教授，你都需要仔细考量。基于时长考虑，我的建议是每次培训内容仅涵盖一个方面，尽量做到专注。这里有三种选择供你参考：
+
+第一种选择是涵盖另一个人已经请求帮助的事宜；第二种选择是覆盖对方最需要的事宜，你的选择取决于你与对方的互动及其在公司的表现；第三种选择是提供有关新系统的培训，如果你的公司更改了规则或实施了新系统，那么一对一会议可能是回顾这些改变的最佳时机。
+
+一旦你决定要培训对方，你就需要决定如何教他，同样有三种方式供你参考。第一种方式，你可以使用一个故事，如果是一个真实的故事就最好了。例如，你可以讲一个上周发生在你身上的事情，通过一个简短的故事来表达你的观点，要比直接告诉某人该做什么，所达到的效果更好。
+
+第二种方式，使用简单的视觉辅助，比如照片或其他道具。通过视觉辅助来对关键信息建立记忆点。第三种方式，使用视频。短视频非常适合一对一训练场景，彼此可以一起观看后进行讨论。选择适合你和你的团队成员需求的方式，通过在一对一会议中提供简短的培训，为另一个人服务并帮助他改进。
+
+总结
+
+定期举行的一对一会议是最强大的管理工具之一，可以帮助管理者解决团队管理过程中遇到的问题，可以帮助员工提升技能，还可以有效改善团队之间的沟通状况，使管理工作事半功倍。本文分享了举行高效一对一会议的原则，以及如何确定一对一沟通的对象，如何建立一对一的会议议程，如何选择一对一沟通的方式等内容，希望能对你有用。
+
+思考题
+
+你跟你的团队成员多久进行一次一对一沟通呢？这样的频率对你的管理工作有帮助吗？欢迎留言分享。感谢你的收听，我们下期再见！
+
+作者简介
+
+刘俊强（微信公众号：程序员精进）现任腾讯云资深架构师，曾任迅雷技术总监、某互联网公司技术副总裁，10+年以上互联网开发经验，8年以上技术管理经验。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/089刘俊强：做好一对一沟通的关键要素（下）.md

@@ -0,0 +1,79 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            089 刘俊强：做好一对一沟通的关键要素（下）
+                            你好！我是腾讯云架构师、TGO鲲鹏会会员刘俊强。定期举行的一对一会议是最强大的管理工具之一，他是管理人员和团队成员相互沟通、互相跟进，并了解彼此工作关系的重要渠道。用好一对一会议，可以使管理工作事半功倍。
+
+昨天的文章中，我跟你分享了一对一会议的重要性，如何确定一对一沟通的对象，以及如何建立一对一的会议议程等内容。
+
+我们来回顾一下一对一会议的流程。第一步是会议开始后，跟进上次会议中承诺的待办事项。第二步，进行简单的成长辅导或培训。第三步，倾听对方的需求。第四步，你转换角色，向对方分享。第五步，回顾会议并结束会议。
+
+今天，我将跟大家分享更多实践，包括如何在一对一会议中倾听对方需求并分享你的需求，如何评估会议结果并跟进完成情况等内容。
+
+跟进委派的任务
+
+开始一对一会议后，首先需要跟进上次会议中委派的所有任务。这就需要你保留每次会议中达成共识的待办事项列表。无论你使用项目管理工具还是在自己喜欢的工具中创建任务列表，都需要将这份列表保存好，将它用于每次的一对一会议中，以便询问每个任务的进展。然后，根据对方完成的结果，酌情给予简短的赞扬或纠正。注意要以简短评论的方式操作，举个例子，如果对方完成了委派的任务，那么只需一句“做得好”就足够了。
+
+你也可以询问对方在完成任务时收获了什么？这将让对方有时间停下来思考他所做的工作，并且创造了一个迷你教学时刻，让他跟你分享他获得的经验与见解，这些经验可能使未来的工作或委派任务变得更容易。
+
+还有一种情况是，他没有完成委托任务怎么办？你可以问他，是什么阻碍了你完成这个任务？这比单纯询问未完成任务的原因更加有效。
+
+举个例子，假如你问对方 “为什么不这样做？” 这可不利于你们增加彼此之间的信任。“为什么” 是一个非常强硬的词语，带有假设的责备态度。它会暗示对方，为什么你不能做到这一点？为什么你会失败？反之，通过询问具体的阻碍原因，可以了解到他未完成任务的具体原因，并帮助对方完成任务。在对方回答之后，你将更深入地了解如何帮助他完成任务，以及纠正未来可能出现的失误。
+
+如果你确实需要纠正某人没有完成委派任务的问题，那么，请以真诚的赞美来进行更正。通过遵这种简单的模式，你将成为对方一个值得信赖的资源，而不是一个要求严格的主管。这样的结果是，大家会欢迎你的观点，并在发生错误时更加关注错误，因为大家会觉得你认识到了他们的优势，而不仅仅是他们的缺点。这种跟踪委派任务的简单方法将使你与他人的关系保持平稳，并能确保对分配的任务负责。
+
+倾听对方的需求
+
+在上一篇文章分享的一对一会议的议程中，在简单开场和跟进委派任务之后，就是简单辅导和培训。而一旦你在一对一会议中为对方提供了重点培训，议程的下一步就是讨论需求和问题。
+
+如果你是会议负责人，请让对方先说，即管理者应该首先问对方“你有什么问题想问我？”你需要成为一个良好的倾听者，为对方创建一个安全的空间，让他在浏览任务列表时花些时间，确保他有机会询问他写下的任何问题，甚至在谈话期间想到的任何问题。
+
+接下来，你需要从了解如何帮助对方的角度，认真倾听他对你提出的所有要求，并尽最大的努力以任何可能的方式帮助他们。
+
+此外，清楚了解对方对你的期望后，当他们要求你做某件事时，一定要明确这件事相关的人、事宜及时间，这可以帮助你更好地准备以贯彻执行。最后，在听取意见和讨论之后，你应该酌情做出口头承诺，遵循并按照你所说的去做。
+
+在一对一会议中，你最重要的角色是为另一个人服务。当你们都有服务态度时，一对一会议就会变得更有意义。
+
+分享你的需求
+
+现在轮到你在一对一会议期间分享你的需求了，你必须直截了当的说出自己的想法。如果你想让其他人帮助你取得成功，首先要让他们了解你的需求。
+
+在会议中，如果另一个人需要花费很长时间来找你的需求，那对方就很难为你服务。因此，建议你在会议开始之前先了解自己的需求，这样，在一对一会议中，轮到你提出问题时，你就可以对照你之前准备好的任务列表，向对方提问。
+
+提问时，我建议你采用开放式问题，而不是封闭式问题或是否型问题，这会鼓励参会者深入挖掘他的答案。例如，问他是否喜欢这个想法，要比问他喜欢或不喜欢这个想法的什么地方更为糟糕些。
+
+如果你需要其他人的帮助，请具体说明你希望获得什么帮助，并描述当你获得他的帮助后，最终希望得到的结果是什么样的。
+
+接着，在你对他应该实现的结果进行具体描述后，让他清楚地告诉你，他执行每个项目所需的人员、内容和时间。如果你提出请求时，对方直接或通过肢体语言间接地表达出犹豫的态度，这时你应该先停下来，询问对方在想什么，避免让对方做自己不想做的事情。这样的话，一对一会议就成了真正的伙伴关系，让你们步调一致并相互尊重地完成任务。
+
+回顾并结束会议
+
+在一对一会议期间有机会互相提问时，应该专注于执行相关的问题，特别是你们会后要采取的行动。轮流简要介绍你们对彼此做出的所有承诺，确保重复每个事项的人员、事宜内容和时间。
+
+重复是有价值的，因为它可以帮助我们避免混淆和错误。另外，当重复人员、事宜内容和时间时，确保你允许对方自由地确定他的日程安排，以及完成任务的方式。而不是直接问他能在几天内完成这项任务，或能否在下周二完成这项任务。如果你需要协调时间表，那也没关系，可以跟对方协商，这样会比直接下达截止日期更为友好。
+
+如果你已经将任务委派给其他人，并且你认为有必要跟进他们，那么请为自己创建提醒，以便跟进该执行人。也可以让执行人在规定时间用电子邮件的方式向你汇报结果。你需要关注任务完成的结果，而不是关注完成任务时具体采取的步骤，这样更能使对方感受到尊重，并避免不必要的微观管理。
+
+最后，请务必按时或早点结束每次会议。如果你提前完成了会议的内容，这样很好，请保持并结束会议，没有人会抱怨会议提前结束。如果你尊重他人的时间，他们也会尊重你的时间，你越及时地结束会议并明确承诺，你就越能将一对一会议视为生产力的宝贵资源。
+
+总结
+
+在这两期的文章中，我们探讨了一个可以在任何公司使用的高效一对一会议框架，能使你的一对一会议更有效率并专注于结果。如果你遵循本文的建议，会议的有效性及效率都会有所改善。
+
+我希望你的一对一会议能够变得越来越好，最好的方法是随着时间的推移而不断改进。你可以与你的会议合作伙伴一起设置定期计划，不断重新评估会议的有效性和效率。如果你把对方的需求放在首位，并履行你对他们的承诺，那么，你的一对一会议将变得富有成效，并面向结果。
+
+思考题
+
+在介绍完如何进行一对一会议后，咱们不妨在此思考下，接下来你要如何使用本文的操作方法或技巧，来对自己管理的团队进行定期一对一会议，然后观察这一做法对自己工作的提升以及团队管理顺畅度的改善情况。欢迎在留言区分享你的实践情况。
+
+感谢你的收听，我们下期再见！
+
+作者介绍
+
+刘俊强（微信公众号：程序员精进）现任腾讯云资深架构师，曾任迅雷技术总监、某互联网公司技术副总裁，10+年以上互联网开发经验，8年以上技术管理经验。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/090程军：打造高效技术团队之招人.md

@@ -0,0 +1,125 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            090 程军：打造高效技术团队之招人
+                            你好，我是贝壳研发总监、TGO会员程军，之前跟你分享过从0到1打造高效技团队的方法论，今天想跟你分享一些我的实践及背后的成功原因。
+
+每一个人心中都有偶像，我的偶像是乔峰和李小龙。
+
+从乔峰那里我学到了铁汉柔情、处事侠义、国家问题大于一切，回忆其中的情节，依然会被那种义薄云天的气概、那种大碗喝酒的豪爽触动，感到痛快不已。
+
+李小龙，我之所以崇拜他，并不只是因为他武功高强，还在于他对武术的不断追求，他学习各类武术，汲取各家之长，从中国武术到世界武术，最终融合形成自己的“截拳道”。
+
+很显然我的偶像都是集大成者，是杰出并且成功的。从他们身上，我找到了成功的因素，即对已选择目标的坚持称之行和达成目标后的认知升级，我将其称为知行合一。
+
+然而现实生活中，每个能力不一样，能解决的问题大小也不一样，界定成功的标准也不一样，你又是如何定义自己的成功呢？
+
+回到今天的话题，如何从0到1打造高效技术团队？在我的实践中，最关键的就是要做好两件事：招人和做事。虽然老生常谈，但却至关重要。今天我主要跟你聊聊招人这件事。
+
+这是一个经久不衰的话题，从三国中的“刘关张”团队到西游记中的“西天取经”团队，不难发现，招人并选择合适的人是一个团队成功的关键因素之一。而具体到互联网行业怎么去招人，我认为两个最核心的因素是招聘渠道和识人。
+
+1.招聘渠道
+
+我们常见的招聘渠道有以下几种：
+
+
+我们的人脉；
+Boss直聘、脉脉、拉勾等招聘网站；
+猎头渠道；
+GitHub等技术网站及论坛；
+各种线下大会、线下沙龙，还有各种群等。
+
+
+有人会说，这个有过几年管理经验的都知道，但是具体到实操层面，你如何快速招到合适的人呢？你会选择哪些办法呢？
+
+我的做法是先把需求分类，一般分为核心骨干、高潜骨干、一线员工这三类，然后根据招聘规划列出总人数和分批的需求时间节点。
+
+其中，一线员工可以去boss直聘等招聘网站，效果比较好，注意多平等沟通、多研究这类网站的攻略，就可以花更少的钱达到更好的效果。
+
+通常，找到心仪的人才后，我会先简单问候，再添加微信，从他的朋友圈观察他是怎么样的人，然后找到彼此可聊的话题，并发掘他想要的东西，而这些恰好你能给的，具体策略可以详见后面的动力适配图。
+
+而核心骨干和高潜骨干，建议还是通过我们的的人脉或朋友推荐比较靠谱。因为这类人才都不缺工作机会，缺的是一个相对适合的自己的机会。
+
+对于高潜骨干，我们还可以通过猎头渠道从对手公司寻找，有时候会有非常不错的收获。对于这个渠道，我有三点建议想分享给你：
+
+
+第一，一定要找2家或3家适合自己的猎头公司，向猎头顾问讲清楚你的需求，并且定期review结果、反思过程，并落实改进方案。
+第二，猎头公司并不是越大越好，有时候公司小一点，但对方的专业度和资源投入度都足够的话，也是非常不错的选择，这些就需要你根据实际情况去判断和分析了。
+第三，建议扩大选择范围，不要把目光只放在竞对公司，思路开阔一些，办法就会更多一些，也有助于你更快的找到你想要的人才。
+
+
+2.识人
+
+谈到识人，各位都有都有自己的见解和做法，我也来先跟你分享一个识人的模型，如下图：
+
+
+
+这个模型主要分为知识、经验、能力、动力四个模块。
+
+识人的第一步，看知识和经验。
+
+这两个模块都可以很容易的从候选人的简历和自我介绍中判断出来，并不难。比如你想找一个高级软件工程师，具体的数据库索引怎么设计，简单的算法和数据结构理论就是知识，做了两个实际的软件项目并且有一定的业务量就叫经验。
+
+识人的第二步，看能力，以及他未来能做什么？
+
+这个一般都需要多轮现场面试来判断，墨子曾经说过，听其言，迹其行，察其所能，即通过判断对方的过去行为，来推测他的能力。
+
+那具体该怎么做呢？这里推荐一个模型——STAR法则：
+
+
+
+S是Situation，即情况；T是Task，即任务；A是Action，即行动；R是Result，即结果。
+
+这几点是我们在面谈中需要重点考察的，即“在什么情况下/什么任务中 –>候选人做了什么->带来什么结果”。
+
+举个例子，候选人说“我做了什么项目”，那就建议你再问问他“在这个项目里面具体都做了什么事情”？
+
+候选人说“一般是这么干的”，你就要追问“你当时是怎么做的”？这里候选人用了含糊的概念。
+
+还有一些候选人会做假设，比如“如果我是什么什么，我就能做到怎样怎样”，这些没有任何用，是无效的STAR。当我们遇到这种情况时，就要让他具体化、典型化并可量化，从而避免一些模糊、主观、假设或者不具体的STAR。
+
+通常，候选人说一个观点或者结果的时候，你不但要让他举一个具体的例子，还要让他说出来当时这么做的优点，以及带来的问题。
+
+因为这个世界是辩证的，每一种技术方案或者管理方法都有其优缺点，如果一个人说不出原委，或者你们聊的不透彻不痛快，那只能说明他从来没有认真思考过，或者即使思考了也深度有限，那就显而易见，对方并不是一个非常有能力的人。
+
+识人的第三步，看动力。
+
+那如何判断候选人是否有动力呢？这个动力本身就是如何自我说服换工作的内因，你应该见到过候选人换工作是因为女朋友异地恋的事吧。我一般会从三个框架去判断，你也可以参考：
+
+
+职位是否适配，也就是岗位的工作领域和职责，与候选人的个人爱好是否吻合，以及工作本身是否令人满意甚至愉悦。
+组织适配，也就是组织的运作模式和价值观所营造的工作环境和氛围与候选人的个人喜好的适配度。
+地点适配，也就是工作或者组织的工作地点，与候选人的个人喜好是否匹配。
+
+
+要进一步展开的话，下面这个动力适配图可以清晰的说明我的观点，图中，横轴描述的是候选人对工作的喜好程度，从不喜欢到喜欢，纵轴描述的是候选人期待的东西工作中有没有，从工作中没有到工作中有。
+
+
+
+比如，第二象限的工作中有候选人期盼的东西，但他不喜欢这份工作，和第四象限的候选人喜欢这份工作，但工作中没有他期盼的东西，这两种情况都会导致候选人不开心，也就是他的痛点。我们就按照这张图找出这些痛点并且视情况满足他，直到他感觉到爽点。
+
+这个理论还可以推广到日常的团队管理中，你是不是已经迫不及待想去尝试了：)，记得后面留言反馈我哦。
+
+总结
+
+这篇文章我和你分享了从0到1打造高效技术团队的两个核心因素，即招人和做事，并分享了如何将招人这件事落地，其中最关键的就是招聘渠道和识人两个方向。
+
+在识人方面，我分享了一个模型，可以从知识、经验、能力、动力四个模块来判断候选人合适与否。其中看能力部分我分享了STAR法则，看动力部分我分享了动力适配图，都是可供具体实践的理论方法，希望能对你有用。
+
+写到这里，我不禁想再点一支烟，眺望窗外漆黑的夜晚，我微微一笑。希望这篇文章可以启迪你的认知、进化你的认知。
+
+文章中部分灵感来自TGO鲲鹏会会员王福强老师，谢谢老师给与的指导和批评。
+
+留一个思考题给你：你在招人过程中有什么具体问题吗？欢迎留言分享，我非常愿意和你一起探讨和学习，共同进步。
+
+感谢你的收听，我们下期再见。
+
+作者简介
+
+程军，现任贝壳技术总监，曾任饿了么技术总监、1号店架构师，10年以上互联网开发经验，8年以上技术管理
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/091程军：打造高效技术团队之做事.md

@@ -0,0 +1,83 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            091 程军：打造高效技术团队之做事
+                            你好，我是贝壳研发总监、TGO会员程军。从我多年的实践来看，打造高效技术团队的关键就是招人和做事。
+
+上一篇，我跟你分享了招人的那些事，包括招聘渠道和识人两个大方向。
+
+其中，招聘渠道的关键是把人才需求分类，并根据不同的分类使用不同的招聘渠道，这样会获得更好的效果。而识人可以从知识、经验、能力、动力这四个模块出发，使用STAR法则、动力适配图等理论结合实践，快速提高自己的识人能力，找到合心意的人才。
+
+众所周知，招人的核心原因是为了做事，所以，我今天就继续跟大家聊聊做事这个话题。
+
+一、和业务心在一起
+
+在我看来，团队必须要有一个共同的目标、可迭代的协作流程，以及统一的评价机制。
+
+我之前在饿了么负责产品和研发落地，在实际执行中，我会先和业务负责人沟通好彼此做事的方法和节奏，最主要的是先确定下一个月的业务目标，然后产品和研发团队这边好确定产品的目标。
+
+我们每个月都会集中过一次下个月计划落地的产品功能，如果业务方OK，产品经理就会提前准备PRD，这样至少可以让团队提前了解下个月的规划，研发和测试团队也能提前准备，有一个缓冲，应了那句古话“兵马未动粮草先行”。
+
+如果碰到紧急需求，我们做法是紧急需求不需要排期，可以按约定砍掉一些P0需求。如果出现P0需求也砍不掉的情况，只能从灵活的组织能力出发，刚开始我们会从其他部门临时抽调人，后来的做法升级为在自己的团队中成立机动团队，这些人就是我们团队的特种兵，指哪打哪。
+
+再来聊聊评价机制，人一般很难找到自己的问题，或者说很多人其实知道问题所在但是就是改不了，不知道你是否有相同感触。所以，定期和业务负责人乃至上级领导one one沟通，让他们指出自己做的不好的地方、欠考虑的地方，是真的可以帮助自己和团队改进和提升。
+
+举个例子，曾经有业务负责人对我说，你们团队执行力很强，但是产品负责人没有自己独立思考的能力，比如在他没有接触过的产品领域，他给不出有建设性的意见，这个时候我才发现是做事上出了问题，本质是一个管理问题。
+
+还有一次，业务负责人毫不掩饰指出我性格中存在的一些问题，我会去深刻的反思，尽管改正很难，但是我知道这是一个大问题，我必须要去改正，或者如果改不掉，也要在做重大的决策时回避这个性格弱点。
+
+这也许就是成长烦恼，也是实践带给自己的重重一记耳光。引用前公司老领导说过的一句话，“未长夜痛哭者，不足以语人生”。
+
+二、技术力和产品力
+
+这一点这个专栏中很多人都已经写过，但在这里，我想分享几个我的认知。还是以前东家饿了么为例子，我将我在其中的三年分成三个时间段。
+
+第一个时间段是2015年~2016年，技术团队从几十人发展到500人左右。
+
+这期间，我可以毫不客气的说，我们根本没有什么产品力，先把业务的需求干完就可以，这个阶段要做的就是招人，干活，团队速度扩张快，但是工程效率低下，P0事故频繁发生，痛苦不堪。
+
+第二个时间段是2016年~2017年，技术团队从500扩张到1000人左右。
+
+这个时候慢慢出现一个大的问题，招进来的人是多了，可是响应新产品的效率依然很低。因此，这时需要沉淀我们的中台、中间件、工程效率工具及技术影响力。
+
+以技术影响力为例，饿了么第一个有影响力的项目是“多活”，严格意义上来说国内真正做到多活的不超过10家公司。在公司内部，为了沉淀技术力量，提升技术影响力，饿了么持续多次推动内部Hackathon比赛的举行，到2017年底，内部孵化的工具或者中间件就有200多个，还开源了更多的比如Element组件等等，这些都是非常生动证明。具体的细节，你可以搜索饿了么框架工具和GitHub上的开源项目。
+
+其实光做到上面那些还不够，我依稀还记得，当时公司组织架构在过完年后做了一个大的调整，还招来了2位国际大牛，一位是LinkedIn背景，一位是Facebook背景，就是为了补上我们技术和产品视野的短板。
+
+第三个时间段是2017年~2018年，技术团队规模突破1200+。
+
+这个阶段产品还能做什么，什么才是这个阶段的产品力？广义来上来说，互联网产品一定是流量为王，留存为后，但是最终你的模式要成功，要么可以赚钱自己造血，要么可以成为别人的护城河或防御工具。
+
+按上面的思路我们开始了双剑合并，选择加入阿里的怀抱，抽象一下，这其实是一个连接融合、过滤和筛选的过程，当然也是一个新的开始。
+
+三、如何打造产品力
+
+如何打造，其实想用文字表达很难。我思考万千，提炼一下就是内因和外因。
+
+内因的核心就是按公司、按产品当时的场景和需求，判断出所处的阶段和面临的挑战，找出未来的方向，并以此为基准制定策略、落实执行方案。
+
+举例来说，第二阶段的关键场景是，当时我们的业务订单量迅猛增长，从日330w单提升到日500w+单，这种强大的外部压力迫使我们必须要在内部去寻求突破，我们制定了两条方案，一是沉淀饿了么的技术，打造出更稳定、更高效的系统；二是找到更牛的同伴加入我们，弥补我们的短板。
+
+当然，这一切的根本是CTO给我们营造的技术环境。好的环境是能促使技术力、产品力发展壮大的土壤。
+
+而到了第三阶段，这时候从内因方面考虑，我们的首要需求是要盈利，为了满足这个需求，就到了必须要通过一些外界的条件来改变现状的阶段。显而易见，利用其它流量大于饿了么本身流量的产品是一个出路，但这还不够，想达成更长久的持续就要进行品牌之间的合作、连接、融合。
+
+总结
+
+这篇文章，我和你分享了打造高效技术团队的另一个核心要素，做事。而要做好事，首先我们要要和业务的心在一起，团队必须要有一个共同的目标、可迭代的协作流程，以及统一的评价机制。其次，要打造技术团队的产品力，而这就要从从内因和外因两方面做分析，但其中真正能产生正向改变的是内因，想清楚自己想要的，剩下的就是寻找突破的方法或手段。
+
+写到此刻，我抬头望向窗外，已经是凌晨5点43分的江城，点一只烟，猛吸一口，新的一天已经开始。
+
+留一个思考题给你：你是如何打造技术团队产品力的呢？欢迎留言分享，我们一起探讨和学习，共同进步。
+
+感谢你的收听，我们下期再见。
+
+作者简介
+
+程军，现任贝壳技术总监，曾任饿了么技术总监、1号店架构师，10年以上互联网开发经验，8年以上技术管理经验。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/092成敏：技术负责人如何做优先级决策.md

@@ -0,0 +1,75 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            092 成敏：技术负责人如何做优先级决策
+                            你好，我是技术领导力300讲的主编成敏，最近跟一些CTO交流，聊到技术负责人做决策的话题，颇有价值，想在这里分享给你。
+
+在整个技术团队中，技术负责人经常要做的无非是两类决策，一类是优先级决策，一类是扩展性决策。
+
+优先级决策
+
+一个公司有业务团队、有产品团队、有运营团队，还有客服团队等等，这些团队都有自己的目标，站在他们的角度，他们会提出许多需求给到技术团队。到技术负责人手上，可能各种各样的需求、项目排期已经排到六个月甚至更久之后了，而其他团队还在不断的提需求过来。
+
+在这种情况下，哪些事先做，哪些事后做，或者哪些事干脆是不用做的，就是技术负责人需要做的优先级决策。
+
+那根据什么来做决策？肯定不是看谁的嗓门大，也不是看这个需求是来自谁，比方说CEO。最终决定优先级的，是这件事情跟组织的目标到底有多大的关系，也就是优先级决策与组织目标直接关联。
+
+其中，最核心的一个原则就是不做不该做的事情，这是提升效率最有效的方式。
+
+交流中，有一个CTO当初是空降到现在的公司的，关于这个话题，他分享了一个他的例子：
+
+
+我作为CTO刚加入公司的时候，公司每周都有一个项目排期会，产品经理和技术负责人会参加，确定接下来要做的事情。会上基本上就是产品经理之间互相争论，最后他们确定下做哪些事，然后技术负责人把这些事排到to do list里去，做出排期。
+
+我参加两次之后就觉得这事不行，不能这么做，因为我发现，首先，这个排期表非常的长，长到每次都要滚好几页才能看完整个需求列表。其次，最老的一个to do list，已经是一年以前的了。我就特别不能理解，既然这个功能这么久没做好像也没影响什么，那当初为什么还要做。
+
+到第三个星期开会的时候，我就动手了，我对参会的产品经理说：“你们提需求可以，提什么都可以，我们作为技术团队，支持你们是天经地义的。但是，你们能不能不光提要求，也给我一个做这件事情的理由，或者这件事情做成能达成的结果。”
+
+所以，我就提了个要求，所有的产品经理在提需求之前要先回答我三个问题：第一个问题，为什么要做？第二个问题，做了之后会带来什么好处？第三个问题，这个好处在最终的数据上怎么体现出来。
+
+如果这三个问题你都回答了，那我们技术团队二话不说赶紧做，加班加点的帮你做。结果，整整一个月都没有人提新需求。
+
+
+回到今天的主题，怎么判断什么是不该做的事情呢？ 其实可以归纳为三点。
+
+第一，要求马上开始，却没有明确可度量的目标与交付时间的事情，先不要做。 比如CEO突然找到你说，有件事情我们必须得马上开始干。那什么时候要结果呢？说是越快越好。那要做到什么程度呢？说是越完善越好。那这件事你就可以拒绝掉，先不做了，等具体的目标、预期出来之后再做。
+
+第二，丝丝入扣、设计完美的大系统，先不要做，特别是如果还要花费很长时间才能出结果的话，那就直接拒绝掉，这种事情一定不值得做。技术人都有想造轮子的冲动，不管是自己去直接造轮子也好，还是推翻别人的东西，全都重构也好，技术人都会有这种冲动，这并不奇怪。
+
+之前跟一个读者聊天，他现在的工作是在一个大公司里面维护老代码，就跟我抱怨说，每次维护老代码都是一边改一边骂，最想做的就是把它推翻掉，全部重写一遍。
+
+但从另一个角度看，所有的代码在最开始的时候，其实都没有那么糟糕，它们是在演进的过程中逐渐变糟糕的。就算你新造了个轮子，解决的也不过是现在或未来一段时间内的问题而已，随着业务的发展、系统的演进，一样会变得糟糕。
+
+第三，要克制精益求精的冲动。 这也是技术团队普遍都有的一种冲动，总想把事情做到最好、最完美。但任何东西，只要有时间、有资源，就总有优化的空间。所以技术团队或多或少都会有这样的想法，你再给我点时间、再给我点资源，我能把它做得更好。
+
+但是这种“更好”是不是当前技术团队乃至公司需要的，资源是不是要放在这件事情上，是技术负责人需要衡量，并做出决策的。
+
+扩展性决策
+
+作为技术负责人，除了要做优先级决策之外，还要做扩展性决策。很多公司在发展过程中都会遇到这样的问题，目前的团队在现阶段是合适的，所选择的技术架构在现阶段是合适的，但一段时间之后，他就不再合适了，怎么办？
+
+所以，技术负责人很重要的能力就是管理扩展性，换句话说，你要对你业务未来的发展有一个大概的预计，然后在组织架构、人员构成、技术架构等方向为业务保留足够的扩展性。
+
+1.组织的扩展性，比如要不要独立出一个公共的技术部门，负责公司基础设施的搭建；比如要不要搭建一个研究型的团队，专门负责创新相关的研究；比如要不要把组织架构从功能型的重组为矩阵式的等等。
+
+2.人员的扩展性，这个其实可以归结为到底要招些什么样的人进来。需要考虑的是，现在的人才储备是不是最合适的，未来一段时间内，团队技术上会不会有大的调整，公司业务上会不会有新的发展。比如，如果公司想要拓展人工智能相关的业务，那技术团队就要先招一些人工智能、大数据领域的人才，做好储备，这些都会涉及到扩展性。
+
+3.技术的扩展性，现有的技术架构能不能支撑公司业务未来的发展，如果不能，应该做哪些事情来补充，比如是引入新技术，是升级架构，还是干脆重构系统等，都需要技术负责人提前做好决策。
+
+而做扩展性的决策的关键，依旧是看这件事情与组织目标之间的关联性，与优先级决策一样。因此，技术负责人一定要对业务、对业务未来的发展有足够的理解和认知。其实，这不仅是对技术负责人的要求，任何一个有想法的工程师，都应该这样要求自己。
+
+小结
+
+本文探讨了技术负责人经常要做的两类决策，优先级决策和扩展性决策。而这两类决策的关键都与组织目标有直接的关联，因此，技术负责人一定要了解公司的业务，清楚公司的目标，并将其拆解为技术团队的目标。
+
+最后，当你面临决策难题的时候，不妨先问自己几个问题：我要解决的问题到底是什么？我的团队在组织里的作用和价值到底是什么？这些价值需要用哪些方式来更好的达成？
+
+你在工作中是怎么管理优先级的呢？欢迎在留言区分享给大家。
+
+感谢你的收听，我们下期再见！
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/093兰军：团队研发效率低下的要因分析.md

@@ -0,0 +1,81 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            093 兰军：团队研发效率低下的要因分析
+                            你好，我是梅沙科技创始人兰军（Blues），今天想跟大家分享提升互联网产品团队研发效率的一些实践。
+
+研发效率未达预期是很多团队都会遇到的问题，项目延期的情况也并不少见。其原因也是多种多样，可能是因为遇到某个技术难题解决不了，可能是因为需求发生了变更，可能是因为设计提出了修改方案等等，表面上总有各种各样的突发情况导致延期。
+
+那延期之后要不要追责呢？一个问题留给大家。然而不论是否追责，这并不能从根本上解决研发效率太慢的问题，我们需要找出更深层原因，总结经验与教训，避免再踩入同样的坑。
+
+这里分享一个我从腾讯学到的分析方法：冰山模型的要因分析法。
+
+如图中所示，研发效率未达预期只是冰山露出水面的部分，只是表象，在水面之下，存在着各种各样的问题，是真正的诱因。
+
+
+
+我们可以粗略的将其分成三类：一是近因，即表面原因；二是过渡因，即深度迷惑我们的原因；三是远因，即改善后能从根本解决问题的原因。
+
+1.头脑风暴找原因
+
+所有这些原因都是从实践过程中不断发现、总结而来的，所以我会组织产品、技术、设计等所有相关人员进行头脑风暴，来找出研发效率低下的各种原因。做产品需求的时候头脑风暴，查找原因的时候，自然也可以用头脑风暴。
+
+问题头脑风暴的关键是尽可能多的列举，不要反驳，把所有能想到的问题都列下来。最后，我们列出了各种各样的原因，包括需求评审不到位、执行态度问题、执行能力问题、主动性不足、考核制度不完善、沟通不到位、不理解整体规划、招聘问题等等，涉及到方方面面。
+
+2.因果分析与评分
+
+仅仅找出原因还不够，为了解决研发效率过低的问题，我们还需要对这些问题进行分析与评分，找出其中的关键点。
+
+如图中所示，我将总结出的所有原因列成表格，分别在横向与纵向一一列举，再两两比较，进行打分，是“因”记-1分，是果记+1分。举个例子，A和B相比较，如果B是A的因，那么B得-1分，A得+1分，反之亦然。如果两者互不为因果关系就记0分。
+
+
+
+然后在表格最右一列对每一行的分数进行求和，得出每个原因所得的分数，并进行排序。按照之前的设定，是“因”记-1分，是果记+1分，所以可以看出分数越高，越代表这个原因是近因，只是表象；分数越低，越代表它是远因，更深层的原因，一旦改善能从根本解决问题。
+
+举个例子，我的表格中，得分最高的原因是“需求更改过多”，有8分，得分最低的是“导师指导不到位”，有-11分，显然前者只是一个表面原因，而后者是更深层的根本原因。
+
+那怎么判断其他原因到底处在哪个水平呢？我们可以把最高分和最低分分别除以2，得到的数字就是近因和过渡因，以及过渡因和远因之间的分界线。还是以我的团队为例，最高分8除以2等于4，最低分-11除以2等于-5.5，那么得分大于4的原因就是近因，得分小于-5.5的就是远因，而处于两者之间的就是过渡因。
+
+在用这种方法进行分析归纳之后，我们团队研发效率未达预期的近因包括：需求更改过多、产品架构能力不足、项目管理能力不足、项目推进意识不足、不清楚整体规划、交互能力不足、执行力不足、版本发布拖延等。
+
+过渡原因包括：版本计划周期过长、需求分析能力不足、合作分工不明确、目标路径不清晰、全局意识、没有方法、负面情绪、主动性不足、对项目理解不足等。
+
+而远因包括：招聘问题、专业培训不足、导师指导不到位等。可以看到，远因基本上都和领导者相关，很多时候，老板就是公司的天花板。
+
+另外，因为问题特别多，很多都没有逻辑性，所以需要找到它们共性的地方，并对其进行分类，大体上可以分为组织与制度问题、能力问题、沟通问题、招聘与解聘问题这四大类。然后在实际操作中，我们可以针对这四大类问题采取相应的解决措施。
+
+3.研发流程梳理
+
+以组织与制度问题中的研发流程为例，各个公司研发流程的整体步骤其实并没有太大区别，无非是先提需求，然后需求评审，评审通过后出设计方案和技术方案，接着是开发，开发之后是验收，包括产品验收和设计验收，待验收完，再开发提测。如果一切顺利，就可以进入发布环节，而在正式发布之前还有灰度发布，最终才正式发布，大体如此。
+
+我们也是按照这套流程做事，但细究之下，发现在实际执行中会遇到很多问题。目前，我们在使用的是腾讯的研发管理平台TAPD，它的默认流程没有问题，只是还不够细致。于是，我们对它进行了梳理，梳理之后发现中间的很多环节都可以进一步细化，以符合自己的研发流程需要。
+
+举个例子，光是需求一项，我们就梳理出了21种状态，包括：新需求状态、挂起状态、规划中状态、已规划状态、需求评审状态、已拒绝状态、设计资源分配状态、开发资源分配状态、需求讲解状态、技术方案评审状态、UI设计状态、UI稿评审状态、开发中状态、需求变更状态、UI验收状态、产品功能验收状态、开发提测状态、测试状态、产品发布状态、外网验证状态、已实现状态等。TAPD里面没有那么全，很多步骤都是我们自己定义的。
+
+定义完详细流程之后，需要进行流程的跳转，而流程跳转也是在这21个状态之间进行，非常复杂，所以我们需要确定每一个流程能跳到哪几个流程，每个流程的负责人是谁，下一步它能够进行怎样的跳转等等，把所有的环节都梳理清楚并明确负责人。
+
+这样梳理下来之后，整个流程图会很长、很繁杂，但对提升团队研发效率的效果非常明显。最初，没有细化流程图，也没有按照流程图做事的时候，遇到问题后，团队成员就会比较迷茫，不知道问题出在哪儿，也不确定该如何解决，甚至搞不清楚下一步的做法。
+
+当然，在总结、细化出这个流程图之后，我在团队中进行了很多探讨和培训，让他们能真正清楚这个流程，并约定好每一步的评审人员和把关人员，确保遇到问题时能够及时处理。
+
+小结
+
+研发效率未达预期是很多管理者都会头疼的问题，本文分析了这一问题背后的诸多原因，包括需求评审不到位、执行态度问题、执行能力问题、主动性不足、沟通不到位等，并通过冰山模型的要因分析法，将这些原因分为近因、过度因和远因三大类。
+
+同时，通过提炼共性，将这些原因分成了组织与制度问题、能力问题、沟通问题、招聘与解聘问题这四大类。在实际操作中，可以有针对性的从这四个方面采取相应的解决措施。
+
+本文还分享了改善组织与制度问题中，梅沙科技在研发流程梳理方面的实践，包括细化需求状态、定义详细的流程和流程跳转图，确定每个环节的把关人等，将细节掌控做到位。这样，即使出现问题，也能及时定位，快速解决。
+
+接下来，我还将分享为提升研发效率，我们在能力问题、沟通问题、招聘与解聘问题等方面的实践，欢迎继续关注。
+
+作者简介
+
+兰军（BLUES）：梅沙科技创始人，致力于教育+互联网行业产品打造，原迅雷产品总监，腾讯、YY语音高级产品经理，公众号ID：bluemidou，已经写了600多篇原创文章，欢迎交流。
+
+（本文整理自兰军在ArchSummit全球架构师峰会上的分享，有删减。）
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/094兰军：提升产品团队研发效率的实践（上）.md

@@ -0,0 +1,83 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            094 兰军：提升产品团队研发效率的实践（上）
+                            你好，我是梅沙科技创始人兰军（Blues），上一篇文章中，我们分析了研发效率未达预期这一问题背后的诸多原因，并将这些原因分成了组织与制度问题、能力问题、沟通问题、招聘与解聘问题这四大类。
+
+今天，我想结合梅沙科技的实践，跟大家分享改善能力问题和沟通问题的一些解决方案。
+
+1.沟通公开透明
+
+我们有着非常透明的内部沟通机制，每个人都能看到其他人的工作目标、工作进度周报等。
+
+跟大部分团队一样，我们每天进行晨会沟通，定期有周会和月会。一般晨会是早上九点半，如果遇到周二，晨会就变成周会，如果是每个月第一周的周二，就变成月会。相当于晨会周会月会都固定在早上九点半，只是不同的时间点开不同的会议。
+
+晨会中，我们主要看迭代表。如图中所示，迭代表中包含需求、迭代、任务、缺陷等内容。如果某个项目的迭代一切正常，就可以跳过它。如果出现问题，我们就会把这个迭代公开投影在会议室墙上，团队一起分析问题、解决问题。
+
+
+
+周会主要看周报，周报有四个模块，分别是本周工作小结、下周工作计划、每周关键数据，以及问题反思和经验沉淀。其中最关键的是每周关键数据这一项，团队中的每个成员都需要提炼出他所负责项目的数据，并在周报中公开分享给大家。周报的提交频率是每周一次，这是一个连续性的过程，有利于形成团队成员的自主管理。
+
+我们的周报是完全公开的，每个人都可以看到公司其他人的周报，所以每个人的工作都是透明的，遇到问题会有团队中的成员给出解决建议，同时，周报中所沉淀的经验也可以被其他人借鉴和吸收。
+
+2.内部数据透明
+
+其实，我现在已经不太管具体的产品和开发方面的工作了，但是我会关注两张表，一张是产品前端表，一张是产品后端表，从中可以看出产品的流畅程度与稳定系数。
+
+通常，在前端数据中，我会看页面的访问量，以及页面加载速度这两个关键数据，它们可以反馈出前端开发的质量，甚至技术实力。
+
+在后端数据中，我一般看后端接口的调用速度，比如，每天调用接口的次数、接口调用的反馈时长，接口调用的平均耗时、访问次数等等。如果访问次数很高，但调用速度慢，其中必然存在问题。如果接口特别多，但很多接口都没人访问，也会有问题，具体还需要根据产品设计来判别。
+
+所有的这些数据在内部也是透明的，不止是我，其他团队成员都能查看。
+
+3.能力提升培训
+
+上一篇文章中提到，专业培训不足是导致研发效率未达预期的远因之一，既然如此，我们就要在平时加强员工各方面的培训。
+
+在梅沙科技，我们非常注重员工的能力提升，在我看来，提升人员能力也是提升团队效率的一种方法，它能有效改善部门之间的沟通问题，减少矛盾。
+
+举个例子，产品经理经常会问开发人员“某功能能不能做”这类问题。长期以往，开发人员也会感到烦躁，所以我的解决方式就是让他们互相培训，互相学习。也就是开发同学有责任去培训产品经理，帮助他提升技术水平和素养，让他自己去判断某个功能能不能做，以此提升工作中的沟通效率。
+
+我们公司的培训方式有两种，一种是内部培训，一种是外部培训，内部培训又分为互相培训和学习分享。
+
+首先，互相培训是各小组之间的经验教授与课程分享，比如，产品经理可以给设计同学和开发同学讲产品课，分享产品思维，讲产品设计。设计同学给产品经理和开发同学讲交互、讲UI。开发或测试同学就给产品经理和设计同学讲技术。彼此互相教授方法，互相学习，以此提高部门间的沟通效率，进而提升工作效率。
+
+举个例子，很多产品经理可能并不了解什么是状态机，这时，他与开发人员沟通时就会存在障碍，如果开发人员能培训他，让他了解这个概念，之后的沟通中再遇到此类技术术语时就不会出现问题了。
+
+再举个例子，在沟通产品的设计时，我们经常看产品经理对设计师说，“这个图标再放大一点，这里的字号再大一点，整体感觉要高大上”。其实，这些都是非常个人的观点，并不专业。所以设计师需要培训产品经理，让他们从专业一些的角度来评判一个设计作品，比如从颜色这个维度，设计师要让产品经理了解什么是对比色、什么是临近色等，并给出设计规范。这个规范就像品控手册一样，能够得到团队成员的赞同，并且不断完善。
+
+另一种互相提升的方式是阅读分享。我会要求团队成员，每个人每年至少读完三本书。读完之后还要将读后感制作成PPT，在晨会结束时进行分享。按照团队成员为60人来计算，团队每年的阅读书目就至少有180本，能够产生180次读书分享。如果在读书分享结束后，团队其他成员对这本书感兴趣，他们可以自己继续深入阅读。
+
+可以说，团队中的内部学习与分享对于员工提升自我是非常便捷、有效的，对于提升团队能力也是非常行之有效的办法。
+
+除了内部学习、外部学习外，项目的复盘也特别的关键。我讲一个曾经的案例，最开始，我们公司当时的产品经理做了一个注册登录流程的流程图，结果开发拿到手之后，觉得画的并不好，其中存在诸多问题，甚至有些地方并不符合流程图的规范。
+
+所以，开发人员联合产品经理，对流程图进行了一系列的更改、试验，再进行沉淀、复盘，最终产出规范的登录注册流程图。
+
+后来，这张登录注册流程图还成为了我们公司面试产品经理的参考标准，我会让面试的产品经理动手画一张流程图，从起始框开始，一直到判断框、结束框，以及流程线路等。毕竟对于产品经理来讲，掌握登录注册流程是最基本的能力。
+
+我也遇到过很多产品经理表示自己是野路子，不了解规范的的流程。但是，这并不能成为一个很好的规避理由，因为很多人都是野路子，没有系统学习过，大学里也没有产品经理专业。很多产品经理都是计算机专业出身，经验与知识都是从实践中不断获取，并逐渐积累而来的。
+
+一个人只有不断提升自我才能越来越优秀，同样，一名员工只有不断进步与成长才能不被淘汰。在此，我分享一段《权力的游戏》中经典台词：“混乱不是深渊，混乱是阶梯。很多人想往上爬，却失败了，且永无机会再试。他们坠落而亡，有人本有机会攀爬，但他们拒绝了。他们守着王国不放，守着诸神，守着爱情，尽皆幻想。唯有阶梯真实存在，攀爬才是生活的全部。”
+
+且不论翻译效果如何，我想表达的是，在现实生活中，“攀爬”一词可能过于功利，我认为成长才是全部。所以，我们需要不断成长，并帮助团队中的伙伴一起成长，当自身能力提升之后，做事情的效率自然会提升。
+
+小结
+
+本文分享了改善团队沟通问题，提高团队成员能力的一些解决方案。在沟通问题上，最关键的就是公开透明和信息共享，这样能让团队成员了解彼此的进度，共享彼此的经验，同时也能有效减少沟通时的隔阂。
+
+另外，我们可以从不同团队间的互相培训和学习分享出发，再加上阅读、复盘等一系列手段来不断提升团队成员的能力，以此提升整个团队的能力，并提高部门间的沟通效率。
+
+如果你对团队能力提升培训有自己的见解，欢迎在留言区分享。
+
+作者简介
+
+兰军（BLUES）：梅沙科技创始人，致力于教育+互联网行业产品打造，原迅雷产品总监，腾讯、YY语音高级产品经理，公众号ID：bluemidou，已经写了600多篇原创文章，欢迎交流。
+
+（本文整理自兰军在ArchSummit全球架构师峰会上的分享，有删减。）
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/095兰军：提升产品团队研发效率的实践（下）.md

@@ -0,0 +1,95 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            095 兰军：提升产品团队研发效率的实践（下）
+                            你好，我是梅沙科技创始人兰军（Blues），前两期的文章中，我们分析了研发效率未达预期这一问题背后的诸多原因，将这些原因归纳总结后，可以分为组织与制度问题、能力问题、沟通问题、招聘与解聘问题这四大类。
+
+其中，优化组织与制度问题、提升能力与沟通问题等方面，我在之前的文章中已经分享了梅沙科技的实践。今天，我想分享的是如何通过招聘与解聘来提升团队的研发效率。
+
+招聘
+
+我招聘团队人才时有三个原则，一是招聘标准，二是跨岗位面试，三是如果犹豫，就不录用。
+
+1.招聘标准
+
+首先我会制定一个招聘标准和招聘流程，招聘流程共有五步，分别是专业初试、专业复试、跨岗位复试、合伙人面试以及HR谈薪酬的终试。招聘标准的话，我一般会从专业知识、专业技能、激情、开放、用户意识、好学、正直、实干、愿意适配这九个方面来评估候选人。
+
+首先是候选人的专业知识与专业技能，这是硬性条件，没什么好说的。
+
+其次，考虑面试者是否有激情，是否开放。我认为拥有开放心态特别重要，举个例子，即使招进来新员工的能力不是很强，但如果他的心态相对开放的话，他可以接纳别人给他的建议和意见，能够通过学习快速提升自己。如果新员工没有开放心态，就算他能力还OK，但是他无法听取、接纳别人提出的建议，就很难成长，很难融入一个团队。所以，我对开放特别看重。
+
+再者，我也非常重视新员工的用户意识与好学、正直、实干、愿意适配等几种素养。我会在面试过程中抛出几个问题，让面试者给出答案或解决方案，通过面试者的表现来考察他各方面的素养。
+
+比如在面试产品经理时，我通常会问他最常用、最熟悉的APP或产品是什么？能否讲一讲该产品特性、功能或者一些设计方面的亮点。通常面试者都能说出一到两款产品，如果他连这个都答不上来，那就基本不用再聊下去了。
+
+如果他回答了，那么接下来给他几分钟时间，画出他所讲产品的草图。比方说他喜欢音乐，最常用的一款产品是网易云音乐，那么，让他画出网易云音乐的草图，包括顶部设计、中间菜单、列表、底菜单等等。
+
+这并不是什么难事，如果网易云音乐的界面过于复杂，那么至少微信是我们最常用的一款产品，可以给面试者两分钟时间，让他回忆微信的某个页面，并将这个页面画成草图。
+
+事实证明，有些产品经理确实不记得微信页面下方四个底菜单的名称和外观。所以，这就考验了产品经理是否会对常用的产品有所关注，如果他连最常用的一款产品的功能都张口结舌，那面试结果必然是否定的。
+
+2.跨岗位面试
+
+在面试中，我认为跨岗位面试也非常重要。在我们公司，招聘产品经理时，会有开发人员去面试，特别在初期团队人少时，进来一个产品经理，前端、后端的技术人员都要去面试他，如果面试结果大家都满意，就录用。
+
+结果，入职了很多女性产品经理。事实证明，女性产品经理确实与开发人员的沟通比较顺畅，项目推动的结果也非常理想。当然，也有优秀的男性产品经理，只是各自擅长的方面不同。
+
+同样，我们招聘开发经理时，也需要产品经理去面试。后面如果产品经理对这个开发人员有意见了，我就能开个玩笑怼回去说，这是你面的、你招进来的，现在怎么对他有意见了。
+
+这样双方跨岗位面试，有利于提升团队成员之间的沟通效率，从而提升团队整体的工作效率。
+
+另外，在面试过程中，一旦我对这个面试者产生犹豫，我就就立刻说NO，直接否定，要相信自己的直觉。
+
+3.新员工三个月规划
+
+新员工入职后，我们会为他制定一个为期三个月的培训计划，让他能够快速融入团队，快速适应新工作。
+
+每个新员工都有一名指定导师，导师的期限也是三个月。导师会先为新人制定一个目标，然后在三个月之内帮助新人快速成长，努力达成目标。导师还会带领新员工熟练SMART原则，帮助他提升达成目标的效率以及质量。
+
+新人进来，我们会要求他每天都发日报，这样我们能清楚地了解他每天的工作与进步，另外，导师需要实时关注，告诉他每天该做的事情，这样，他也能对自己在做的事情心中有数。
+
+如果是产品经理入职，我们会要求他在三个月之内上线一个产品功能，或者是某个页面改版，并提交一份具体的数据分析。不管多小的功能，一定要上线，这样才能走通内部整个流程。
+
+在三个月期限到达后，我们会根据目标的完成度来评估新员工是否适合团队。
+
+在三个月期限中，除了考察新员工的专业技能素养，还需要观察新员工的自身素养。比如，是否有责任心，遇到难题会不会主动承担；是否有嫉妒心理；是否自我感觉良好；是否情绪起伏过大；是否拒绝改变；是否总会迟到等等。如果发现新员工与团队不太适合，我会果断解除试用，这样的结果更加有利于双方的成长。
+
+解聘
+
+在我看来，解聘要果断，这对于团队的战斗力有益无害。通常，团队中某个岗位的员工不达标，但由于缺人或短时间内招不到合适的人才，很多管理者不会解聘该员工，会留着他继续干活。但我的做法恰恰相反，我会果断解聘该员工，留下的工作会临时交付给它的上级，或者直接由我承担。
+
+因为留着一个不合适的员工，既影响团队氛围，又影响团队战斗力，对于该员工也是一种不负责任。
+
+如图中所示，在团队中，假设每个人的能力均等，那么，平均战斗力就是1，如果有人能力提升，团队战斗力也会随之快速提升，一旦有人能力不足，团队战斗力也会相应降低。
+
+
+
+从图中团队D和团队E的战斗力数据来看，其他7位成员的战斗力数据都一样，只有一位成员的数据从1变成了0.6，结果，E团队的战斗力直接降低了近一半，由此可见能力不达标员工的负面影响之大。
+
+所以，遇到不合适的成员，要果断解聘。这也是有些团队设置末位淘汰制度的原因，这样留下的成员战斗力会更强。
+
+另外，解聘也是对员工的一种培养，有助于他更好地成长。如果他有问题，你可以给他一次机会来提升自己，一次机会足矣，做不到，就果断解聘。千万不要给两次机会，因为一次机会改不了，给两次机会也是白搭。
+
+被解聘之后，他反而可能会获得更好的成长。尤其是对现在的年轻人而言，可能他们的生活压力比较小，自我独立意识比较强，比较崇尚自由，用负面一点的词的话就是比较自由散漫，不太注重团队意识。所以，经历一些挫折与痛苦，能够让他获得更多的成长与经验积累。在我看来，痛苦加反思，才能够进步。
+
+值得注意的是，我所分享的内容都只是一种方法，而非标准答案，具体方法还需要根据你团队的实际情况来分析调整。
+
+小结
+
+本文主要分享了如何从招聘与解聘两个方面出发，来提升团队的研发效率。在招聘层面，我分享了三个原则，一是制定符合团队情况的招聘标准，二是不同部门跨岗位面试，三是如果犹豫，就不录用。而在解聘层面，一旦发现员工不合格或不合适，就要果断解聘，这样即有利于团队战斗力的提升，也有利与对方的成长。
+
+最后，我特别推荐一本书，书名为《非暴力沟通》，我在公司内部也做过这本书的分享，书中所讲的沟通方法对于提升整个团队的效率与战斗力非常有用。
+
+如果你读过这本书，或是对招聘与解聘有自己的实践，欢迎留言分享。
+
+作者简介
+
+兰军（BLUES）：梅沙科技创始人，致力于教育+互联网行业产品打造，原迅雷产品总监，腾讯、YY语音高级产品经理，公众号ID：bluemidou，已经写了600多篇原创文章，欢迎交流。
+
+（本文整理自兰军在ArchSummit全球架构师峰会上的分享，有删减。）
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/096阿禅：工程师转型产品经理可能踩到的坑.md

@@ -0,0 +1,129 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            096 阿禅：工程师转型产品经理可能踩到的坑
+                            你好，我是轻芒合伙人阿禅，“可能吧”创始人，也是一名连续创业者，之前做过科技媒体、做过智能音箱，做过很多事，踩过许多坑。今天想跟你分享的话题是“工程师转型产品经理可能会遇到的几个坑”。
+
+之所以称之为“坑”，而不是“问题”，是因为我自己并没有真正做过工程师，而是接触过很多工程师，也有很多工程师转型产品经理的朋友，我将所有的问题与经验总结起来，并分享给你，希望对你有用。
+
+工程思维与产品思维
+
+首先以手机摄像头为例，来说说工程思维与产品思维的差异。假设我们要做一款手机摄像头，从工程思维的角度，我们可能会考虑，如何提高摄像头的分辨率；如何提高弱光下的快门速度；如何进行ISO调整；如何优化人像识别功能；如何使闪光灯更智能等等。
+
+从产品思维的角度，我们可能会更多的考虑拍照场景、美颜效果等等，比如如何拍出来就显五官立体、肤色嫩白；如何做到自动美颜并可以立即分享朋友圈；如何从众多照片中自动选取最美的一张等等。
+
+我与很多工程师朋友的理解是，工程思维更关注效率、如何实现，也就是“How”；而产品思维更关注“场景”，以及用户的内心需求，也就是“Why”。
+
+在具体的产品开发中，产品思维和工程思维都很重要，需要将两者结合起来。产品思维需要工程的配合与支撑，将“场景”落实到产品开发。比如，产品经理想做一款夜间拍摄效果更好的手机摄像头，那么就要做到既保证人像清晰，又保证背景明亮，这时就需要工程师们在技术上做相应的提升、优化，比如前景快门锁定、快门拉长等。
+
+工程师转型产品经理可能遇到哪些坑
+
+在这次分享前，我跟几位从工程师转型做产品经理的朋友聊了聊，从中摘取了四条较为典型的吐槽。
+
+
+视角变了，原先追求完美和逻辑性，现在是怎么快速实现目标怎么来。
+很多时候，用户视角的简单性与工程思维的完美性有冲突。
+转型这一年，踩过的坑无数，包括产品战略层面、沟通层面、团队管理层面、执行层面，满眼都是坑。
+以前不用做这些，现在要做很多公司内部的东西，比如对上沟通，然而老板永远不懂我；对下沟通，光打鸡血远远不够；还有跟兄弟团队和部门之间因为资源不足产生的博弈等。
+
+
+对此，我稍稍总结了一下，总结出了工程师转型产品经理时，可能会踩进去的7个坑。
+
+1.认为用户傻
+
+
+我明明设计了一个很聪明的按钮，用户就是不用，非要用那个复杂的方法来使用我的产品。
+
+
+举个例子，假设产品经理设计了一个开关，用户只需向上一推就可以把灯打开，比原来向下按的方式更为省时省力。结果发现用户并不买账，可能99%的用户还是用向下按的方式去开灯。尽管这样会稍微费力一点，但用户已经习惯了这样的行为方式。
+
+对于这类情况，很多产品经理容易陷入一个误区：既然有更加方便的产品使用方式，用户就该放弃原有的方式，去使用新方式。但是，他们忽略了用户习惯较难改变的事实。
+
+2.觉得同事傻
+
+
+那帮运营和市场老给我提不靠谱的需求，一点都不懂技术和产品，瞎指挥。
+
+
+这是我曾经陷入的误区之一，以前我在一家公司做客户端，很多时候，市场和销售的人在与客户聊天之后，就会找我提需求，比如在某个位置加个广告位。在当时的我看来，这完全是他们在瞎指挥。
+
+后来，我反思当时的做法，认为应该从两方面思考这件事。第一个方面，当同事提需求时，这个需求可能已经变质，不再是客户的原始需求了。作为产品经理，应该去了解客户最原始的需求。
+
+第二个方面，应该考虑同事提出这个需求想达成的目的，比如他的目的可能并不是为了加一个广告位，而是为了借此达成盈利目标，那我们其实可以通过其他方式帮助他实现目标。
+
+因此，当同事提需求时，我们应该把他和普通用户放在同一层面，尽管提的是一些所谓的“傻”需求，我们也要花费时间与精力去认真分析这些“傻”需求背后的动因，以及如何才能帮助他们解决问题、实现需求。
+
+3.觉得同事还是傻
+
+
+明明那么简单的道理和逻辑，这帮同事怎么就不理解呢?
+
+
+这个问题其实出在沟通层面，然而，产品经理很重要的职责是沟通,很多时候,沟通是做成一件事的关键。
+
+之前有个产品经理跟我分享，他做工程师时不擅长沟通，也不想沟通。在他看来，这些事情都很简单，为什么还要花时间给别人解释。这是他后来转型做产品经理时很难跨过的一道鸿沟。
+
+在公司中，不同职位与不同资历的人，彼此的认知都不同，而作为产品经理，需要团结团队里的每一个人，让大家朝着同一个目标努力。那么，你就必须跟所有人解释，某件事的重要性，某个功能为什么存在，某件事为什么要那么做等等。而且，因为认知的差别，你与每个人的沟通方式也要有差别，找到合适的沟通方式才能获得对方支持。
+
+可以说，提升沟通能力是工程师转型产品经理的必经之路。
+
+4.容易在前端呈现过多技术
+
+
+我给用户做了一个特别炫酷的功能，用户可以自定义各种参数，但似乎他们并不怎么用。
+
+
+其实，许多做产品的书籍、课程都会写到，不给用户选择，反而是最好的选择。举个例子，前段时间小程序黑咔相机特别火，日活量最高时可达千万。它的功能特别简单，就是给照片中天空提供各种动态效果，比如用户选择梵高星空，它就能将图片中的天空变幻为动态的梵高星空效果，然后一键保存、分享，操作非常简单，过程中没有任何需要技术的地方存在。
+
+这个产品的用户平均年龄大概50岁，最早在某个摄影群中爆发，由于操作简单，效果有趣，迅速被群成员分享，一天时间内由日活30多万，迅速上涨至几百万，第二天再增长至一千万，是一个特别经典的例子。
+
+5.过于追求完美，害怕返工
+
+
+用这个方法来实现产品方案太笨了，对服务器的开销太大，我们应该重写代码，用另一种方案。
+为了应对未来可能存在的需求改动，我要把能在后端定制的功能都写了API，并且把功能拆成各种层级。
+
+
+许多创业公司在开发产品前会将计划思考周到，以防未来可能出现的需求改动，比如将各种API补全、把框架都搭好等等。但在实际开发过程中，我们还需考虑阶段性问题，如产品当前处在什么阶段，是否应该在当前寻求最完美的实现方案；如果处在MVP阶段，是否应该允许回炉重做等等。
+
+我们应该允许一些不影响主功能的Bug存在，先让功能运行，再补全不完美的地方。有许多工程师害怕返工，觉得按照产品经理的需求去做时，会不断出现新的需求，就需要不断地返工进行完善。然而对产品经理来讲，他需要根据每个阶段的数据变动，去观察市场反馈，从而迅速做出调整。所以，我们应该放下害怕返工的心态，接受随时推翻重做的可能性。
+
+6.认为功能大于场景
+
+
+我们有A功能、有B功能、有C功能……我们有非常多的功能，都是我们自己的技术实现的。
+
+
+产品经理经常犯一个错，就是总觉得应该再多开发一些功能给用户使用，让他们的体验更丰富。然而，我研究了许多小程序的方法论，发现小程序之所以火爆，除了自身裂变属性较强外，非常重要的一点是，它只满足用户一个功能的需求。你可以看到，很多拥有多合一功能的小程序，很难火起来，因为功能增多之后，会模糊用户对这个小程序的认知。
+
+7.忽视运营
+
+
+酒香不怕巷子深，好的产品，用户自然回来，首先要做好的是产品，运营和营销并不重要。
+
+
+其实不然，产品与运营始终不可分割，产品经理一定要与运营人员密切沟通，甚至做到产品经理即运营本身。
+
+最近几年，很多成功的产品，其成功的原因中运营占得比重甚至大过了产品本身。以小程序为例，很多小程序的功能比较容易实现，技术门槛并不高，别人也可以快速复制，关键点反而在于如何做用户增长。
+
+对此，我们的做法是采用AB测试，反复测试，总结结果，在这个过程中，产品经理需要跟运营不断沟通，共同摸索出最优结果。
+
+并且很多时候，产品经理还需要身兼多重角色，我有一位朋友是做电商产品经理，他每天除了做AB测试，测试各种按纽，优化各种流程之外，还会涉及对文案细节的改动，某次他改动了一句广告语，结果下单率提高了9%。
+
+可以看出，产品经理做测试、运营、文案等细节工作，看似与技术没有太大关系，却是产品获得成功必不可少的一部分。
+
+小结
+
+本文总结出工程师转型产品经理时可能会踩到的7个坑，包括认为用户傻、觉得同事傻、在前端呈现过多技术、过于追求完美、害怕返工、认为功能大于场景、忽视运营等，值得大家借鉴。你曾经踩过其中的哪个坑呢？欢迎在留言区分享你的踩坑经历！
+
+作者简介
+
+阿禅，连续创业者，资深微信产品与运营研究者。创办中文原创博客可能吧，轻单创始人、有可能学院CEO、极客公园前CEO、出门问问产品总监，目前担任轻芒合伙人。
+
+（本文整理自阿禅在ArchSummit全球架构师峰会上的分享，有删减。）
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/097阿禅：工程师转型产品经理的必备思维.md

@@ -0,0 +1,97 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            097 阿禅：工程师转型产品经理的必备思维
+                            你好，我是轻芒合伙人阿禅，在上期《工程师转型产品经理可能会遇到的“坑”》一文中，我根据自己与朋友转型做产品经理的经历，总结出七个最容易踩的坑。今天，想继续跟大家分享工程师转型产品经理必须要掌握的八个思维与能力。
+
+实际上，即使不是工程师转型，这些思维也需要学习。还记得我第一次学做产品经理的时候，因为是野路子出身，没有经验，不知道文档怎么写，就找了一个网易的朋友请教，他给我发了一个300页的文档参考。当时我震惊了，产品经理要做这么多东西么？后来，我自己去做产品时才发现，写文档并不是一个产品经理最核心的技能，他需要具备的能力有以下几点。
+
+1.好奇心
+
+关注一切你喜欢和不喜欢的产品，思考场景与为什么。在招聘产品经理的时候，我经常问对方一个问题：在不看手机的情况下，分别说出微信做的好与不好的三个功能，说明理由，并反推此功能为什么要这样设计。
+
+我并不关心面试者的观点是对是错，我的关注点是他有没有细心观察这个他每天使用最频繁的产品；有没有去思考其中的功能为什么要这么做，为什么不按照他所认为的更好的方案去做。
+
+产品经理需要有好奇心，要经常花时间与精力去研究常用产品或对手产品，只要一款产品出现在眼前，不管喜欢还是不喜欢，都应该用职业敏锐性去研究、分析它，凡事多问问为什么。
+
+比如看抖音，并不是看完一个点赞量上百万的小视频，认为不错，感到开心，就接着刷下一条。这不是一名合格的产品经理该有的生活状态，而是要研究上百万的点赞量背后的原因，去看看主播是谁，他以往的视频点击量是高是低，视频属于哪一种类型，再试试总结哪个类型的抖音视频比较火等等。
+
+2.同理心
+
+将自己当成核心用户，并从的他们需求角度思考产品需要解决的问题。当你认为用户“傻”的时候，不要急着否定他们，而是要以同理心去思考他们的需求。
+
+我之前做过一个的练习，当时，我特别不理解拼多多，为什么一个二十几块钱的伟哥能卖四百多万份，成了当时拼多多销量最好的单品，这让我非常震惊。然后我去分析拼多多的用户群体，也混进了很多中老年群。结果发现，中老年人真的很闲，每天都会在群里聊天，而且群是他们很有安全感的一个舒适区，他们乐意在舒适区中表达观点，也非常乐意将自己认为优惠的产品分享到这样熟悉的圈子中。而且他们不止是分享产品，而是会把产品链接直接发到群里，还会直接@几个人，让他们帮忙拼团，氛围特别热闹。
+
+当时我还观察了一个叫“点开就看”的小程序，它里面包含养生类、新闻类、花草山水类等内容，字号特别大，是中老年人喜欢的风格。我做了个测试，托朋友将这个小程序分享给他们的长辈，结果，长辈们都表示非常喜欢，已经收藏。这在当时非常颠覆我认知，因为不论是UI设计还是内容都不能达到我的审美标准，这样的产品竟然能在一个群体中如此火爆，这个群体还非常愿意传播。
+
+后来我开始去尝试了解这个中老年群体，混了好多群，聊了很多人，也慢慢理解了这个群体的内心需求。其实，中老年人，是今年下半年小程序应该着重去打的用户群体。
+
+3.逻辑力
+
+能够将不同部门、内外声音等所有碎片梳理成树状关联的关系。产品经理需要开很多会，所以信息的整理能力非常重要。同时，逻辑能力还包括对优先级的判断，以及高优先级条目与其它条目的关联性。有逻辑的观点会具有更强的说服力。
+
+4.化繁为简
+
+找到用户最真实的场景，用用户最容易使用的路径去实现。在这方面，我们需要做到这4步：
+
+
+研究用户在不同场景下的不同需求，并梳理成流程图和故事；
+抽象出用户的需求，并列出实现方案A、B、C；
+像用户一样思考，寻找最简单的实现路径；
+谨防炫技。
+
+
+其实，在做用户调研的时候，用户往往很难将内心真正的需求表达清楚。比如，你问用户哪类内容会引发他的阅读兴趣，他可能回答是比较狗血的社会新闻，但如果你因此去做标题党，你的文章并不一定火爆。因为用户真正喜欢的可能并不是狗血的社会新闻，而是其中刺激到他内心的某个点，狗血的社会新闻只是一个外在表象。所以，我们要挖掘用户的核心需求，制定最简单最直观到达用户内心的产品。
+
+5.不完美思维
+
+因为没有完美的解决方案，只有当下最合理的解决方案。我们要知道哪些是最重要的，哪些是暂时不重要的，要允许不完美，懂得舍弃，懂得屏蔽各种声音带来的非核心需求，毕竟优先解决当前用户的核心需求永远是最重要的。
+
+举个例子，我第一次创业的时候，公司只有7人，资金只有一百多万元，产品做了五个月后，遇到了很多技术瓶颈，是我们无法解决的。当时，资金所剩不多，也招不到技术大牛来解决问题。所以，在一次例会中，我们决定砍掉一些不重要的功能，先想办法让公司存活下去。
+
+虽然，公司最后还是没能存活，但是回头去看，对于那个阶段来讲，我们的做法并没有错。当时我们有两个产品，如果不做取舍，可能连一个产品都做不出来。所以很多时候，我们要允许存在不完美，先实现再改进，这会更适合当下中国互联网的竞争态势。
+
+6.战略思维
+
+像CEO那样去思考战略，像OKR拆解那样去执行战略。之前看到过一个观点：谁未来最有可能成为CEO，是产品经理，因为他必须关注面，而非点，要把很多点连成面，这就要求他们充分了解竞争格局，不仅仅是功能，还包括团队优势、融资状况等。
+
+我们做产品的时候，并不是设计完成某个功能就好的，而是需要知道我们做的每一个产品、每一次版本的迭代，对整个公司的好处，对未来盈利的好处。产品经理应该把自己的思维拔到一个相对比较高的角度，思考产品对于公司的价值。
+
+另外，战略思维也包括不完美思维，意味着要放弃一部分不重要的的东西。
+
+7.运营思维
+
+好的产品是技术、运营、营销配合出来的，在产品中注入运营思维，产品会活的更持久。运营思维主要需要注意4点：
+
+
+产品不光要实现，还要考虑如何吸引用户，如何留住用户；
+洞悉用户心理，寻找用户在使用产品中的心理需求；
+懂得如何让用户自发传播，如何节省营销成本；
+产品中的运营功能应该是方案化并可重复使用的。
+
+
+8.利他心理
+
+通俗讲，知道应该找谁推动什么事，并知道应该给他什么，让他来帮助你。举个例子，我有个朋友之前在百度负责广告部门，他想在搜索界面的某个地方再加一些广告位。做的过程中遇到很大的阻力，因为他需要跟好几个部门沟通协调。
+
+第一，技术部门得去沟通，因为需要他们实现广告位的技术开发。第二，广告销售部门得去沟通，因为广告位增加之后，需要他们卖出去。还有其他诸如网站、广告平台等所有相关部门。
+
+然而沟通的结果是，除了广告销售部门，并没有部门答应做这件事，因为对他们其实没有明显的好处。
+
+最后，他决定找广告销售部的负责人一起合作来推动这项计划的实施，因为这项计划能给销售部带来利益。结果是，所有阻力都被顺利攻克，成功增加了新的广告位。
+
+可以看出，产品经理是一个需要调动所有资源、推动产品开发的角色。那么，要调动资源，就需要平衡人与人、人与资源之间的关系，需要具备利他心理，找到关键人，了解这些关键人最关心的是什么，并满足他们的需求，以此减小阻力，让他们帮助你推动这件事。
+
+最后总结一下，本文分享了工程师转型产品经理必须要掌握的八个思维与能力，包括好奇心、同理心、逻辑力、化繁为简、不完美思维、战略思维、运营思维和利他心理。即使不是工程师转型，所有做产品的人都应该具备这些素质。希望我的分享能为你带来思考与价值，感谢你的收听。
+
+作者简介
+
+阿禅，连续创业者，资深微信产品与运营研究者。创办中文原创博客可能吧，轻单创始人、有可能学院CEO、极客公园前CEO、出门问问产品总监，目前担任轻芒合伙人。
+
+（本文整理自阿禅在ArchSummit全球架构师峰会上的分享，有删减。）
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/098徐裕键：业务高速增长过程中的团队迭代.md

@@ -0,0 +1,77 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            098 徐裕键：业务高速增长过程中的团队迭代
+                            你好，我是贝贝网合伙人兼研发副总裁徐裕键，今天跟你分享的话题是，业务高速增长过程中面临的挑战，以及该如何应对。
+
+先简单介绍一下贝贝网，贝贝网在2014年上线，不到一年时间，就拿到C轮一亿美金的融资，成为估值10亿美金的独角兽公司，用两年时间开始实现规模化盈利。我们公司也从最初的3个人，成长为上千人规模的大团队。
+
+业务高速增长过程中面临的挑战
+
+一个高速增长的公司会面临各种各样的挑战，这些挑战来自方方面面，但大部分可以归结于业务和团队两大方面。
+
+公司的高速增长必然伴随着业务的指数级增长，而且随着业务的增长，团队会越来越壮大，团队中的角色也会越来越多，此时就会出现两个问题。
+
+第一个问题是流程混乱。从最初运营提出需求到产品设计，再到开发上线，这个产品可能就与最初预想的效果完全不一样了。可能我们最初的产品需求是卖家秀的效果，产品上线后就变成了买家秀。
+
+第二个问题是团队内部的挑战。创业初期，公司影响力比较小，要招到合适的人非常困难。所以当时我们的团队成员基本都是一二线电商公司、互联网公司筛选过的员工，或者是实习生和校招生。而随着业务快速增长，需要不停增加人员来满足业务增长的需求。这时你会发现，即使团队的管理层很牛、很专业，但是管理想法就是落实不下去，因为中层是缺失的。
+
+另外，管理者自身也存在一些问题，因为我们不少管理者都是从技术转型而来的，他们看到团队成员事情做的不好，比如说代码写的慢、规范写不好、架构设计不好等，就恨不得自己上手去做，自己去写代码。
+
+但这样做终归是解决不了问题的。那具体该如何解决呢？我分享两个个我们的做法，即规范流程制度、完善团队人才梯队，希望能给你提供一些参考。
+
+规范流程制度
+
+首先要规范流程制度，将它变得标准化、工具化、可度量，让团队成员有流程可依。
+
+从业务角度来讲，公司业绩增长会带来业务复杂度的提升，比如，业务不停增长，系统就会不停地堆代码，那么系统就会越来越复杂，当它复杂到一定程度时，我们就很难继续快速的跟进与执行了。
+
+同时，业绩增长常会稀释人才密度，当业务复杂度往上快速增长时，公司高绩效人才的占比是下降的，两者会出现一个交叉点。当交叉点出现时，你会发现以前的那套流程已经不适用了，混乱和错误开始出现，产品迭代速度会受到严重制约。在这个人才密度上，业务已经变得太过复杂，而系统不可能再以往常的形态运行。
+
+此时，最简单有效的解决方案就是梳理一套流程制度规范，因为当下你很难招到合适的、能即插即用的专业人才，当然，这并不是说现有团队成员的能力不行，只是他们需要一定的时间去成长，而你提供给他们一整套的流程，授予他们合用的工具与方法，能够帮助他们快速成长起来。
+
+其实，业界有不少成型的流程制度规范，我们可以去借鉴参考，但不能照搬照用，如何将其优化的适合自己公司的情况，真正落地执行，是其中的关键的。
+
+我们的一个尝试是增加了项目经理的角色，在我看来，一个项目要完整执行下来，会有三个关键角色，分别是产品经理、技术经理和项目经理，他们组成金三角，一起去推动这个项目。
+
+项目推进过程中，需要信息快速传递，并且要避免信息失真、不对称的问题，所以我们会建立专门的站会制度，定期沟通、同步进展。另外，项目上线后并不代表结束，我们还需要重视结果，不论这个项目成功还是失败，我们都会组织相关同学进行复盘，并对该项目的流程进行持续的迭代优化。
+
+另外，项目的流程规范也要跟技术的演进紧密相连，比如当我们能做到APP组件化的时候，项目方式就得作出相应的变革，否则，就不能与生产力的增长相匹配。
+
+以我们公司为例，规范项目流程能够确保上百号研发、数十条业务线做到并行迭代，同时能够做到快速发布，新版本的迭代速度从一个月一个版本缩短到了三周一个版本。 总而言之，要持续优化改进流程制度规范，以此终止混乱，提升效率和质量。
+
+完善人才梯队
+
+其次是完善人才梯队，刚才也讲到，随着业务复杂度提升，团队高绩效人才的密度会下降，所以，我们需要完善团队人才梯队，使人才密度的提升超过业务复杂度增长。同时，我们也要通过工具化、产品化、智能AI等技术手段，将业务增长带来的系统复杂度增长降低到最小。
+
+另外，砍掉一些次要的边缘性业务，或是让人分散精力的鸡肋业务，关注最核心、最具价值的事情，也能降低系统复杂性。
+
+在搭建团队人才梯队时，我们探讨过一个话题，即管理者到底要不要背招聘KPI？我们的结论是要背。因为招聘不仅是HR的事情，也是管理者的事情。一名优秀的管理者也应该是一名优秀的HR，反之，如果不具备HR的能力，他也做不好管理者的角色。所以，在创业早期，我几乎每年年底都会亲自飞去北京，跟各个领域的专家、资深架构师面对面沟通，将他们吸引到自己的团队中。
+
+我们也探讨过另一个话题，即我们是否应该通过高薪引入一些专业人才，他会不会打破团队中的薪酬平衡？因为之前创业初期，招进团队的成员薪资比较低，如果招聘一位技术专家进来，他的薪资可能会比别人多出一倍，甚至好几倍。
+
+最终，我们的答案是，团队需要这样的技术专家，而且，当公司还处在快速发展阶段时，最初跟随团队的那些员工也需要继续成长。那么，通过引进专业人才，可以倒逼大家去不断突破自己的天花板，使团队整体的能力再上一个台阶。结果告诉我们，这确实非常有效。
+
+在完善团队梯队时，你必须选择符合团队发展的组织架构。一般来说，团队组织架构分为两种，一种是职能驱动型，另一种是业务驱动型，而这两种组织架构我们都经历过。
+
+职能矩阵型团队是特点是团队小，业务简单且产品单一，能够更好地进行资源统筹及人员备份，此时，团队应该专注于深耕所在领域，以寻求更大的突破。
+
+而当公司发展，团队变大，业务也越来越多、越来越复杂之后，为了保证产品及业务能够并行快速迭代，这时就需要将团队重组为业务矩阵型团队，以业务线为主，进行团队分工，将全职能目标打通，建立利益共同体。
+
+我们公司即使发展到两三百人的规模，也依然保持扁平化的管理方式，团队中的管理者只有20人左右，总占比不到10%。这样做是希望我们的研发同学能够在专业技能方面发挥更大的价值，我们希望以业务为导向，激发团队自驱动性，将团队价值发挥到最大。
+
+组织架构的能力非常关键，从过去几年的创业过程中，我发现一个公司能否持续成功，有两个决定因素，一个是战略能力、决策能力，一个组织能力。在公司发展过程中，每个阶段都有非常多的机会，至于能否选择对机会，就取决于战略能力和决策能力。即使选对机会，但这个机会最终不一定会属于你，这时就看你的团队组织能力与团队执行力。在如今竞争残酷的市场中，半年就可以决定一个创业公司成或者败，一年时间就可以决定一个公司的存亡。
+
+希望今天的分享能对你有所帮助，感谢你的收听，我们下期再见！
+
+作者简介
+
+徐裕键，贝贝网合伙人兼研发副总裁。负责贝贝技术团队管理，从0到1搭建贝贝移动电商产品和技术架构，推动集团各个技术领域快速演进，完善技术团队的梯队搭建和文化建设。
+
+（本文整理自徐裕键在ArchSummit全球架构师峰会上的分享，有删减。）
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/099徐裕键：业务高速增长过程中的技术演进.md

@@ -0,0 +1,63 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            099 徐裕键：业务高速增长过程中的技术演进
+                            你好，我是贝贝网合伙人兼研发副总裁徐裕键。上一期文章中，我跟你分享了业务高速增长带来的业务和团队两方面的挑战，以及如何通过规范流程制度、搭建人才梯队、完善组织架构等方法来应对这些挑战。
+
+然而，在业务高速增长的过程中，来自技术的挑战也不可忽视。贝贝网从一个电商新秀到行业独角兽，只用了短短两三年的时间，看似顺利，但其中的酸甜苦辣只有我们自己知道。所以今天就想扒扒皮，和你分享一下我们业务扩张过程中在技术上踩过的那些坑，以及我们是如何应对的。
+
+业务规模和复杂度快速增长带来的挑战
+
+其实，创业最初，我们曾怀疑过贝贝网这个平台的可能性，因为在早期的电商淡季时期，我们连三个九的业绩都达不到。后来，在双十一流量压力的作用下，我们把业绩做到了四个九以上，才打消了我们的疑虑。
+
+另外，最开始我们是移动电商，APP版本的迭代速度非常慢，早期可能一个月更新一个版本都非常困难。后来，经过技术的不断演进、团队的不断迭代，我们能够做到每周更新一个版本，而且新版本的缺陷率从原先的50%降低到5%以上。50%意味着，在早期，我们上线的100个需求里面，有50个需求是有缺陷的，需要返工的。
+
+版本更新速度的提升与相应错误率的下降，这背后起支撑的是一个团队的持续迭代。一个人可以走得很快，但唯有一个团队，才能走得更远。
+
+再来看来自于技术的挑战。公司在快速发展过程中，相应的业务量也是快速增长的，最初可能只有一个单一的产品、一个简单的业务，到后面，随着业务、产品的成熟，逐渐将它铺开后，可能会出现多个产品，甚至数十条业务线，都需要并行迭代的情况。此时便会衍生出更多的问题，具体可以分为三点：
+
+第一个问题是，原先我们习惯于在一个工程或一个系统应用上进行开发，长期以往，代码会越堆越多，导致这个系统越来越腐化，架构越来越不稳定，出现越来越多的耦合。
+
+这时就会发现，团队的新成员进来后不敢写代码，团队中的老人也不敢对这个存在复杂耦合性的系统轻举妄动。因为，极有可能你动了某个地方，就会导致整个系统出现更大的问题。一旦这种可能性发生，那之前的什么代码冲突，相较而言就是非常小意思的事情了。
+
+第二个问题是，当大家都在一个工程、一个应用上进行开发，并且有多条业务线并行迭代的时候，你会发现，每个团队直接的步伐并不一致，互相之间可能会有诸多争论。这样就会导致版本更新的效率大大降低，也加大了需求上线的难度，比如大家可能需要花费半天的时间才能够完成上线验证，效率极其低下。
+
+第三个问题是，由于系统太过耦合，可能某个新功能上线后对于全站业绩增长的影响非常有限，但因为系统扛不住新功能带来的流量，结果导致核心链路交易服务都不可用了。
+
+业务系统解耦合及平台化推进
+
+说了这么多问题，我们当时是如何应对这些技术难题的呢？
+
+首先，我们要明确一个观点：保证生存是首要目的，永远没有非常完美的产品方案，我们必须要不停地进行开发和迭代。所以，我们必须具备一种快速试错、低成本试错的能力，使产品和业务完成快速迭代。并且，当这个模式成熟后，能够帮助产品和业务快速进行规模化，再通过这种规模化的能力，实现公司商业价值最大化。
+
+回到具体的技术挑战，公司规模上来后，我们在每个技术领域都有非常大的技术演进，是基于全栈的技术演进，从APP端组件化动态化，到业务层组件化，到服务化，一直到底层数据库拆分、运维自动化、持续集成能力的提升等，我们都做了很多布局，而且很多都被证明是非常有效的。同时，整个系统的基础架构设施也在不断完善和配套。最有力的表现就是，后台研发同学的交付能力，直接是翻倍的提升。
+
+其实，归纳起来就是通过服务框架对应用进行拆分解耦、采用异步消息来对系统进行解耦、使用分布式数据访问实现数据层的无限扩容。
+
+在APM应用性能管理方面，我们自研了一套从客户端到后端的全链路应用市场监控，便于我们对性能进行优化。其监控管理对象也从最初的单应用演进为多应用。
+
+在应用拆分、服务化之后，我们还自研了一套私有云系统，改进了系统的部署方式，从原来的集中式部署，到分布式部署，再演进到单元化部署。这样一来，原本交付一个资源至少需要一天以上，现在只需要几分钟就能进行扩容，效果立竿见影。
+
+在监控告警方面，我们从原来的单机房部署，一路演进到异地多机房部署，基于这样的监控告警体系，当我们的业务指标发生变化时，能够做到一分钟之内告警，特别是核心业务指标发生变化时，我们可以及时进行处理。
+
+在持续集成方面，我们也从最初的单系统优化做到后面的结构型优化，能够提供非常灵活的灰度发布机制、非常快捷的回滚机制，确保即使出现问题，它的影响也能控制到最小。
+
+在大数据方面，我们很早就开始布局，并组建大数据团队，目前已经演进到机器学习阶段。比方说在客服上，机器客服能够帮助节省一半的客服人员，减少人力资源消耗。另外，对运营也有非常大的帮助，比如通过自动化排期，基本能做到减少1/3运营人员的投入。
+
+当然，在技术之外，流程是保证保证快速迭代的关键，对此，我们定了两点原则：一是每个阶段都实行准入制度，明确需求；二是每个环节都检查输出，包括质量和时间两个维度。在具体执行中，我们推行短项目迭代制，正如之前提到的，没有完美的产品方案，我们要先求有，再求优，小步快跑、快速迭代，而所有的技术与系统都要能支撑我们能够迅速验证产品。
+
+总结一下，技术上的挑战，来自于业务高速增长形成规模化之后，带来的系统复杂度的上涨，而解决的重点在于，通过服务框架对应用进行拆分解耦、采用异步消息来对系统进行解耦、使用分布式数据访问实现数据层的无限扩容。
+
+然而需要注意的是，对创业团队来说，如果想要把握住机会，就必须做到快，因此，在技术演进的时候，也要学会克制自己的技术洁癖，不要追求完美，适合的才是最好的。
+
+作者简介
+
+徐裕键，贝贝网合伙人兼研发副总裁。负责贝贝技术团队管理，从0到1搭建贝贝移动电商产品和技术架构，推动集团各个技术领域快速演进，完善技术团队的梯队搭建和文化建设。
+
+（本文整理自徐裕键在ArchSummit全球架构师峰会上的分享，有删减。）
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/100徐裕键：团队文化建设，保持创业公司的战斗力.md

@@ -0,0 +1,75 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            100 徐裕键：团队文化建设，保持创业公司的战斗力
+                            你好，我是贝贝网合伙人徐裕键，之前的文章中，我分享了业务高速增长中的团队迭代和技术演进，而保证团队持续迭代和技术持续演进的一个关键是团队文化。
+
+团队文化可以成为每个员工的行为准则，影响个人意识，当个人意识与团队文化达成一致时，团队就会逐渐走向成熟，并具备极强的战斗力。所以，今天我想跟你分享我们在团队文化建设上的一些实践。
+
+创业公司发展路径
+
+从文化的角度讲，一个企业基业常青，它的发展路线必然会经历一个S型的增长曲线。
+
+以阿里巴巴为例，它最初专注于国内批发贸易市场，做ToB业务。当ToB业务做到一定的规模后，它预感到了业内天花板的存在，此时，又发现ToC领域有非常大的市场，于是创立了淘宝网，直接触达普通用户。然后又发现用户和商家在交易时存在非常大的痛点，于是推出了第三方支付工具“支付宝”，以担保交易的方式使消费者对网上交易产生信任。随后又推出阿里旺旺，方便用户与商家沟通，这样一来，即时通讯工具与网络购物就有了联系。之后又发现了商品品质与用户购物体验的问题，于是推出了天猫商城。而当线上交易的渗透率达到一定深度后，业务的天花板也是显而易见的，于是又从业务转向技术，开始做阿里云。
+
+从阿里巴巴大概的成长历程可见，每一个创业公司都必须经历这样的过程，即不断地寻求新的业务增长点，预见问题、解决问题，并保持持续迭代，不断追求新的制高点。
+
+我们公司也是一样的，我们是一个持续创业公司，最初，我们做的是返利模式，后来发现返利的天花板非常明显，之后转到导购，又发现导购需要依赖于淘宝、天猫等电商平台，受制于人，天花板也非常明显。
+
+之后，我们发现了母婴市场，并迅速切入进去。当时母婴市场还是一片蓝海，其实蓝海和红海是相对的，很多人们以为是蓝海的领域，进去之后发现已经变成了红海。好的商业模式会让蓝海很快变成红海，所以创业者一定要有在红海中竞争的姿态。
+
+所以，在母婴市场，我们也需要不停地进行迭代，在成长过程中，不停地寻求新的业务增长点，寻求新的突破。
+
+另外，每个S形迭代的过程中，都有很多不确定因素，这对于团队成员的考验非常大。因为在每个S阶段中，都有高速增长期和顶峰停滞期。在高速增长期，业务发展快，大家都会比较亢奋，很多问题都会被掩盖掉，不会被发现。然而，当业务达到顶峰停滞期时，之前被掩盖的问题都会暴露出来，这时就需要团队去做调整，去寻找新的破局点，对于团队成员的考验也就随之加大，会需要他们具备强烈的文化认同感与执行力。
+
+文化价值认同感
+
+我们推崇的文化主要有三点，第一是自我驱动，第二是头狼精神，第三是价值认同。
+
+自我驱动
+
+我们会在团队内部强调创业文化，强调自我驱动。因为我们希望，在确定目标、明确方向之后，大家能够基于问题出发，以结果为导向，带着敢担当的精神做事情。同时也希望每个人都能带队伍冲锋、打胜仗。
+
+因为，创业过程确实存在很多不确定性因素，会遇到各种问题与挑战。无论是来自于公司的流程制度，还是应用系统等工具支撑，都存在许多不完善之处，而这些不完善，都需要员工自己开拓解决方案。那么，员工能否将这些问题当做一次次机会，发挥自身价值，就需要看他们是否具备创业精神与自我驱动的意识。
+
+另外，团队中的Leader，必须具备识别小白兔与老白兔的能力。所谓的“小白兔”即勤勤恳恳干活，认认真真做事，但不生产业绩的成员。而“老白兔”则是加入团队的时间比较早，以过往的功劳自居，也是勤勤恳恳做事但不产生业绩的人。对于这两类团队成员，管理者应该及时处理，该淘汰就淘汰，否则也会影响到其他团队成员的积极性与成长速度，对公司的发展非常不利。
+
+头狼精神
+
+所谓的头狼精神即开拓、进攻、猎杀，对创业公司来讲，开拓与进攻非常重要。因为无论你做到何种规模，想守住第一都很难，迟早会被别人超越，所以，只有每时每刻具备危机感，保持敏锐，去发现新的机会，转守为攻，才能确保你的核心竞争力。
+
+在创业公司，很多情况并不是考验员工的整体能力，而是考验员工的执行力，包括能否接受各种考验，能否主动突破问题、获取知识，能否做到快速执行，以及执行后能否做到持续迭代优化。创业公司能否保持快速迭代，可以说与团队员工的执行力紧密相关。
+
+如果团队中的每一位成员都能够具备创业精神和头狼精神，遇到问题积极挑战，而不是吐槽抱怨，那么，团队将会快速稳定的走向成熟。
+
+对贝贝网来讲，我们的目标是成为全球领先的母婴公司，那么就必须要保持头狼精神，保持领先的思维方式，积极进取，勇于开拓，构建核心竞争力，以免被他人超越。
+
+价值认同
+
+我们在确定公司的使命、愿景及价值观这条文化建设道路上，花了好几年的时间，我们会去研究、借鉴很多优秀公司的文化价值观。经过几年的积极探索，我们逐渐形成了属于自己的开发者文化。
+
+想知道自己到底有没有文化，其实很简单，就问自己接下来团队要举办的活动中，大家对哪些活动寄予期望，另外，是否有什么东西成为他们工作的准则。
+
+我也会经常在技术团队提及公司文化的slogan，使大家增强认同感、归属感与使命感。
+
+比如，我们要求团队成员有责任感，持续迭代对用户负责。不论是公司的商业模式、产品，还是技术都需要进行持续迭代。尤其作为研发者，给用户交付产品功能，并不是将功能上线就完成了，而是要持续迭代，交付给用户真正有价值的东西。
+
+而如何将这些喊口号的内容做实、落地、体系化，并转型为生产力，就需要我们作为技术领导者在日常工作中不断的积累和沉淀。
+
+以贝贝网为例，我们把“悟空”设为我们文化的关键词，因为我们的发布系统叫“悟空”，并由此衍生出很多含有“悟空”因素的活动，比如新员工培训叫“大闹天宫”，高精尖的老员工进阶叫“悟空训练营”，一年一度的技术嘉年华叫“悟空说”，等等。
+
+我们第一次举办技术嘉年华的时候，针对五个领域、五大专题进行分享，时间定在每天晚上的七点到九点，每个专题每个晚上都会分享两到三个话题。当时，虽然我们公司的技术人员不多，只有两三百人，但是每天晚上会场都坐满，甚至站满，并且吸引了很多产品组、运营组同学一起分享交流。
+
+最后，我们也对这次技术嘉年华进行了满意度调研，结果发现，满意度、认可度、赞赏度都非常高，并在团队中形成了一种技术文化氛围。而最重要的是，团队成员可以互相借鉴彼此的经验，提升自己，获得成长。
+
+总的来说，团队文化建设不是一蹴而就的事情，需要统一团队成员的文化价值观，使大家目标保持一致。对于企业的使命、愿景有强烈的实现愿望，并将想法有效执行，而在团队文化建设中，也需要做好文化传承，将企业的精神、态度、价值等有效传承下去。
+
+作者简介
+
+徐裕键，贝贝网合伙人兼研发副总裁。负责贝贝技术团队管理，从0到1搭建贝贝移动电商产品和技术架构，推动集团各个技术领域快速演进，完善技术团队的梯队搭建和文化建设。
+
+                        
+                        
+                            

专栏/技术领导力实战笔记/101刘俊强：领导力提升指南之培养积极的态度.md

@@ -0,0 +1,82 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            101 刘俊强：领导力提升指南之培养积极的态度
+                            你好，我是腾讯云资深架构师、TGO鲲鹏会会员刘俊强，有着8年以上的技术管理经验，今天想跟你分享技术管理者如何做好情绪管理、培养积极的态度。
+
+作为技术管理者需要负责的事情繁多，需要培养并带领团队完成工作目标，会面临诸多不如人意或突发的情况，稍加不注意就会让自己陷入到负面情绪中。我们必须及时处理工作中的负面情绪，不论是团队成员的或是自己的，毕竟负面情绪是可以传播的，我们当然不想给团队增加消极性，从而影响士气和团队表现。
+
+一般来讲，我们在工作中常见的负面情绪及典型场景有以下这些：
+
+
+挫败：当我们感到卡住或陷入困境时，通常会有挫败感。有可能是团队没有按照你的期望完成好项目，抑或是上司或老板未按时出席你主持的会议。
+愤怒：失控的愤怒可能是人们在工作场所中经历的最具破坏性的情绪。同时这也是我们大多数人处理得不好的情绪，作为管理者更要学会控制愤怒的情绪。
+忧虑：是对尚未到来事情的担忧和焦虑，例如公司业务发展受阻，需要对技术团队进行人员优化，抑或是工作挑战大担心完成不了等。忧虑的情绪不加以控制的话，很容易扩散影响自己的身心健康和工作效率，同时也容易让你在工作中不太愿意承担风险。
+失望：当事情未达到我们期望时，一般会产生失望的情绪，例如团队成员认为未取得应得的晋升时。失望的情绪也会让我们趋向避免承担风险，影响到我们的工作效率。
+
+
+不得不承认的是，工作场所中不出现负面情绪是不可能的，不论是因为管理者糟糕的决策引起的，亦或是由团队成员的个人问题引起的，作为技术管理者，我们不能对负面情绪视而不见，不去处理，任由它们在团队中蔓延，影响团队效率和士气。作为合格的管理者，我们应该学会在团队中培养积极的态度，学习洞察和处理负面情绪。
+
+接下来，我们就聊聊如何来应对负面情绪、培养积极的态度，希望对你实际工作或生活产生些帮助。
+
+应对挫败感
+
+无论是基于什么原因，快速处理挫败感很重要，因为它很容易导致更多的负面情绪，比如愤怒。对于处理挫败感我这里有些建议：
+
+
+首先是停下来评估，当你感到挫败时，能够做的最好的事情之一就是先停下来，当然这里说的停下来是指精神和思维上，回顾下遇到的情况，问问自己为什么感到沮丧，记录下来并具体来看这些事情，想想所遇到情况的积极方面，例如你的上司开会迟到了，你就会有更多的时间准备会议，或者，利用这段时间放松一下也不错。
+如上所说，寻找情况的积极面，考虑你所遇到情况的积极方面会帮助你以不同的方式看待事物，角度微小的改变能够对我们的心情进行改善，因为造成你挫败感的人，他们可能并不是刻意让你沮丧或困扰的。因此让你挫败事情的产生，并不是某个个人的，不要在意，继续前进做你该做的事情。
+消除脑里的负面词语，一般产生挫败感时，我们的脑子里会不自主产生些负面词汇或语句，让我们陷入这种负面情绪的影响之中，例如 “糟糕，又被坑了” “怎么总是做不好呢”，我们可以使用语气不那么重的词汇及语句来替换，例如 “事情进展有些不顺利” “完成情况低于预期”等，状况或事情总要解决的，因此不要沉迷于挫败感，如上面所说的继续前进带领团队解决问题。
+
+
+控制愤怒
+
+没有人会喜欢自己发怒的样子，作为管理者更不应该对团队成员发怒，因为这样会很容易将之前建立的团队信任摧毁掉。愤怒可能是工作中最普遍的负面情绪，从过往经历而言，愤怒在团队管理中还是蛮常见的，甚至于有些管理者会习惯性使用愤怒来达到自己的目的，但是与愤怒的人一起工作是让人辛苦、精疲力尽的。当人愤怒或回应愤怒时，大脑会让我们难以沟通或清晰地思考，那么我们该怎么避免在工作中发怒呢？
+
+
+注意愤怒的早期迹象，只有你知道愤怒发生时的危险信号，所以我们要学会在它们开始时识别它们。尽早制止你的愤怒是关键，请记住，你的第一反应是生气，但并不意味着这是正确的反应。如果你开始生气，停下正在做的事情，闭上眼睛，进行深呼吸，将注意力集中在呼吸这件事情上，这样反复深呼吸后，能够帮助自己将注意力拉回到事情本身，而不是陷在愤怒的负面情绪中。
+当生气时想象自己生气的样子和表现，例如，如果你要对团队大喊大叫，想象一下你自己的样子，是不是面红耳赤、手舞足蹈，你自己是否愿意和这样的人一起工作？我相信答案一定是否定的。
+学会聆听，团队管理中经常会遇到的愤怒场景，便是团队成员对未完成好的事情进行解释或辩解，这很容易让管理者情绪达到临界点，进而爆发，因此我们要学会聆听，保持冷静沉着的风度，继续听下去，找出问题所在并引导团队进行纠正，以讨论问题的方式进行处理，如果进行到激烈时候，可以暂停5分钟，彼此冷静下再讨论问题。
+
+
+解除忧虑
+
+我们可能会对工作中发生的一些情况产生忧虑的情绪，例如糟糕的季度工作业绩、上司对于团队的不信任或公司发展受阻需要裁员等。忧虑通常伴随着恐惧，人类的生理本能会让人战斗、逃离或站着不动，而作为管理者，我们面对这些状况时，还需要带领团队继续前进，例如在不尽人意的业绩情况下，继续改进给予完成目标的希望。那么我们该怎么面对和处理？
+
+
+正面处理员工的恐惧，坦诚地与团队成员沟通现状，并探讨接下来该怎么改善处理，唯有行动才能打破忧虑与恐惧，也就是人类本能里要么跑、要么战斗，站着不动可能被野兽吃掉，而因为我们是管理者，所以我们必须正面面对恐惧与忧虑，例如业绩不好，我们需要坦诚合理地探讨分拆实现的可能性，以及因为业绩不好带来的负面影响。
+帮助员工避免夸大风险，当事情失去控制时，人们难免会产生恐惧并可能会放大忧虑。作为管理者，我们应该通过自己的经验和分析，帮助员工正视现状及问题，鼓励他们专注于如何改善现状，例如害怕被解雇，坐在那担心并不能帮助他保住工作，我们需要引导他们如何展示自己对于公司的价值。
+记下你的担忧，如果你发现有些事情总是烦恼着自己，那么请将它们记录下来，然后安排时间处理它们，在此之前，你可以忘记这些担忧，因为你知道自己会去处理他们。在时间安排上，我们可以对这些担忧进行适当的风险分析，并看看可以采取哪些措施来减少风险。
+
+
+宽容失望
+
+我们可能会在工作中失望或悲伤，不论哪种情绪都对干好工作没有帮助，我们可以采取一些主动措施来应对失望和不快乐：
+
+
+调整自己的心态，花一点时间让自己意识到事情并不总是一帆风顺的，说句鸡汤的话，正是完成事情过程的起起伏伏才让得生活变得如此有趣。
+适当调整目标，如果你对团队未达到目标感到失望，并不意味着目标不可到达，可能是需要再多点的时间，那么是否可以调整下截止日期呢？如果团队总是无法在截止日期前达成目标，那么要思考的是目标拆分、进度管理是否合理呢？
+帮助员工调整，前面我们有举例，员工可能会因为未取得自己期望的晋升而感到沮丧和迷失方向，他们会觉得自己经历了损失，因此作为管理者，我们在沟通时要有同理心，不要要求他们怎么怎么做，而是引导他们如果要达到自己的期望，应该要解决哪些问题，并认可他们出色的地方以帮助他们建立自信，达成目标。
+
+
+总结
+
+我们在上面谈到了一些常见的负面情绪，以及如何应对它们。我认为作为管理者应该明白的一点是，不论你自己或团队产生了负面情绪、士气低落，这些都是你要承担责任的，因为你是管理者，需要你来带领大家走出困境解决问题。
+
+做个阳光积极的管理者并不容易，需要我们保持对团队负面情绪的洞察，并采取适当的方法进行处理，而这需要管理者不断训练精进。最后，当然是希望收听的各位都能够成为应对负面情绪的熟手，带领团队元气满满的工作。
+
+思考题
+
+你最近一次发现团队负面情绪是什么呢？你又是如何应对的，欢迎在留言区分享。
+
+感谢你的收听，我们下期再见！
+
+作者介绍
+
+刘俊强（微信公众号：程序员精进）现任腾讯云资深架构师，曾任迅雷技术总监、某互联网公司技术副总裁，10+年以上互联网开发经验，8年以上技术管理经验。
+
+                        
+                        
+