mod

极客时间专栏/技术管理案例课/技术决策者：开始定战略了/22 | 技术决策（1）：技术管理者做什么，团队效率才最高？.md

@@ -0,0 +1,173 @@
+<audio id="audio" title="22 | 技术决策（1）：技术管理者做什么，团队效率才最高？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/78/6b/78de26ddde83d324c542e640d740916b.mp3"></audio>
+
+你好，我是许健。
+
+前面两个模块，我给你分析了作为一名一线经理常见的坑，从关注事情到同时关注事情和人的转变，在招人，培养人，裁人方面的注意点，以及跟领导和跟高级别员工的沟通心得。接着在二线经理的部分，我们又用具体的例子从变革管理，冲突管理，组织和文化，危机管理等多个方面介绍了一名二线经理相对于一线经理所面临的进一步的挑战。
+
+从今天开始，我们进入课程的最后一个模块：技术决策，这个模块是我特意放在最后的，而且我认为正是因为有了这个技术决策模块，才能体现技术管理和一般管理的区别。这个模块，我设计了3讲，今天就先来带你讨论：启动一个项目时，技术管理者都应该做什么，才能让团队的效率最高？
+
+为什么要讨论这个话题？我先给你举个很简单的例子。
+
+有这么一个部门，当前最大的痛点是开发效率不高，而开发效率不高的原因是测试困难，测试困难最大的问题是因为缺少高质量的测试数据。如果你是部门领导，你会怎么做呢？
+
+如果你做出的决策没有从“高质量的测试数据”这个关键事项入手，很可能就走偏了。比如我们把大量的研发力量投入构建新一代的基于容器的持续交付CD pipeline（持续交付流水线）  ，你就算构建的这条流水线很先进了，但无法提高测试数据质量，也就无法提高开发效率。
+
+而且因为要做新的CD pipeline， 要投入了大量的人手，这些人手本来可以去做更有意义的事情，这么一算，因为这个决策，团队效益还可能是负的。
+
+你看，一个部门具体做什么本质上是由这个部门的一把手决定的。我们课程前面讲的所有管理技巧，如果没有这里说的做正确的事情，那就都是浮云。
+
+好了，说到这里，做一个正确决策的意义和价值，我想就不用再强调了。那接下来我们最关心的问题就是，到底怎么才能做到呢？接下来，我就带你一步一步来找到答案，这第一步就是定义好问题。
+
+## 定义好问题
+
+有一句话叫做“优秀的人眼中都是活”，这句话说得有道理，不过，放到我们现在说的战略决策场景下，这样是不够的。
+
+在实际工作中，不会像文章里我一开始给你举的例子那样，痛点和难点都那么清晰。你通常会看到很多的点，但是作为经理，你不能眼里全是点，你需要更进一步，尽快找到那个“打蛇打七寸的点”。因为你要带着团队在这个点上长时间投入，这是关于你整个团队接下来几年发展的点。
+
+我们还是结合具体的例子来看。以我们部门的PaaS团队来说，团队遇到很多挑战：
+
+1.我们整个技术栈正在往Kubernetes转，目前是当前系统和新系统双线作战，我们是不是应该把现有系统彻底淘汰？
+
+2.我们虽然迁移到新技术栈，但有一些顽固问题长期无法得到解决，比如IP分配冲突，实现自动且无风险的删除操作（删除一直是高危操作，因为删除造成业务影响被开除的员工在我记忆中有好几位了），以及淘汰不再使用的线上应用。
+
+3.公司正在往流量管理设备软件化、分布式化演进，PaaS的团队成员要不要加入这个方向呢？比如Istio或者Envoy。公司因为做支付对基础架构安全性要求越来越高，PaaS团队要不要去做基础架构安全方向？
+
+这是几个比较典型的挑战事项，其实我还可以列出很多。那问题来了，我们现在不是选择太少，而是选择太多，那我们应该按照什么样的原则来做决定呢？PaaS的经理曾经让我在以下**三个因素**中做排序：
+
+1.能不能产生业务价值，注意有些能产生业务价值的事情并不需要很强的技术支撑，比如系统集成和客户服务质量。
+
+2.技术实施有深度，员工做了这个项目自身市场竞争力提高显著。
+
+3.解决问题的范围可控，对外依赖少。
+
+我最后的排序是1 &gt; 3 &gt; 2，PaaS的经理说他也是这个排序。那接下来我就按照这个顺序，从业务价值、范围可控到技术深度，带你逐一剖析。
+
+不过这里我需要强调一点，**如果你没有办法把现在手头的日常工作的效率提高从而空出人手，那就先别去想新东西了。**也就是上面PaaS团队的3个挑战，在淘汰老系统和解决固有问题完成之前，做新东西这个决策根本实施不了。
+
+### 业务价值
+
+我们先来看有没有业务价值。可以说，凡是启动新的项目，大家都会说自己是为了业务。我想说的是：**有没有业务价值不是你说了算，而是你的客户说了算。**可是又有人说，不可以用户说了算，“用户很多时候不知道他们要什么”，你看乔布斯都这么说。
+
+可是我们毕竟不是乔布斯，如果一个人想要就业务价值发表看法，我通常会先思考下面这两个问题：
+
+- 说这句话的人到底花了多少精力跟客户在一起？
+- 说这句话的人之前是否有过让客户惊艳的经历？
+
+如果两个问题的答案都是否，那还不如踏踏实实地先去解决几个我们明确知道的客户痛点，再发表高论。
+
+回到前面PaaS团队的问题，我们来对比一下下面对于业务价值不同的表述：
+
+<img src="https://static001.geekbang.org/resource/image/d1/b5/d1fa4651e54aeda1be654cec072cbab5.jpeg" alt="">
+
+通过对比，你有没有发现两种表述的不同呢？
+
+表述1更多的是在说技术实现或者陈述一个任务，而表述2才是真正的从价值层面来阐述为什么我们要做一个投资。
+
+我举个很现实的例子做解释，测试环境稳定性的问题，如果按照业务表述1大家的关注点就是那100%的迁移指标，但是业务表述2强调的才是真正的测试环境可靠性问题。
+
+事实上也是这样的，这件事我们就是因为没有强调真正的业务指标，后来导致一大堆客户抱怨，甚至投诉到了CTO那里。而IP分配的顽固问题是我现在向团队反复强调的点，不要在我面前再反复说我们要用新的IPAM替换RAS，请明确我们的问题解决方案，迁移只是方法，彻底杜绝IP冲突问题才是目的。
+
+### 范围可控
+
+定义好了我们的目标，也就是确定了业务价值，我们来讨论问题范围。你是在公司做事，**需要按阶段交付业务价值。**你的交付时间拖得越长，别人对你期待越高，失败风险越大。
+
+以PaaS团队IP网段的问题来说，最初分配其实是网络部门管理，而网络部门并不隶属云计算部门，如果我要PaaS团队解决这个问题，必须评估网络部门的配合程度，最好网络部门有专人负责并绑定他的年度业绩。
+
+我给你总结一下“问题范围可控”的注意点：你把解决问题的依赖全部列出来，然后对每一个依赖评估重要程度和你对这个依赖的控制力有多强。对于关乎你成败的重要依赖，如果你的控制力不够，要么你能够得到领导的足够支持搞定这个依赖，要么你能够重新审视你的技术决策，看看能不能去除这个依赖。如果都搞不定，请问问自己，这个问题是不是应该你来解决?
+
+<img src="https://static001.geekbang.org/resource/image/e0/ae/e077f2b16418d7cfd58fa7d4e25b43ae.jpeg" alt="">
+
+### 技术深度
+
+最后来说技术实施深度的问题。虽然在定义问题的考虑因素时我把它排最后一位，但这却是我在技术决策中最棘手的一个问题。
+
+为什么这么说呢?因为事情都是人做的，团队成员除了交付业务价值外，还会关心自己的市场竞争力。如果实施的技术深度不够，也就是说不足以让成员感受到他自身的实力会因此提升，那他的积极性是不高的。
+
+还有一个很现实的问题摆在眼前，如果不是奔着市面上很火的技术方向走，你很难招到高质量的人才。相信我，我也曾给自己打气说“真正优秀的人才，才不看技术栈，哪种技术只要做到极致都是高手。”但现实让我不得不重新审视这个问题。比如虽然我很想给PaaS团队补充优秀人才，但无论从数量还是质量上说，我在Kubernetes方向收到的简历都优于PaaS。
+
+具体到PaaS团队的问题3，也就是如果做基础架构安全方向，如何更加快速地满足安全合规要求呢？我的思路是这样的：
+
+**第一，业务价值优先，技术必须服务于业务。**这也是我们在定目标的时候，为什么先强调业务价值而不是技术手段。这里需要我们好好学习一下PCI的DSS（支付行业数据安全标准）和GDPR（通用数据保护条例）规范。安全合规要求涉及用户隐私信息的交互不能泄漏，不能篡改。
+
+**第二，首选公司内长期不能得到解决的棘手问题。**特别是那些历经几代技术变迁却长期无法解决的问题，尤其值得我们关注。比如不影响业务前提下，我希望我们具备给大规模基础架构做安全强化的能力。
+
+具体来说就是如果安全需要，我们就可以迅速给任意应用之间通信升级TLS版本。要知道我们公司上一次只是给PCI环境应用升级TLS到1.2就动用了业务开发，流量管理运维，网站监控多部门一起在War Room会战了数个月才完成。
+
+另外我还想发展一项能力，就是能给安全需要的任何应用添加粒度更细的权限管理。
+
+**第三，我不想跟趋势斗了，看看有没有什么新的技术趋势可以用****乘数效应解决问题。**如果去看看业界做安全的公司现在在解决什么问题，安全方面有什么重要的会议和期刊，这个时候零信任，Beyondcorp，Istio，OAuth，APT 这些名词就会进入我们的视野。从趋势来说，我会倾向决策模块往Beyondcorp多维度决策引擎方向发展，执行模块往Envoy Sidecar这样贴近应用的非侵入方式发展。所以我们的专注点应该放在智能IAM和Envoy上。
+
+**第四，试图以最短路径交付效果，绝对要克制贪念，控制作战范围，小步迭代。**比如我一定要使用Istio加Envoy来实现更细粒度的应用间隔离，还是就使用Envoy和公司内部已经有的IAM/IDM系统集成呢？我倾向于第一阶段先跟公司现有系统集成，逐步过渡到Istio的方式。而智能IAM的事情，也应该先选取一个核心系统部署智能IAM，而不是一上来就要做一个又大又全的新方案。
+
+其实关于技术深度这个问题，我是层层深入和筛选关键点的。首先框住为业务服务这个大框架，然后第二层着眼解决现在的难点，接着第三层是选择符合趋势的技术，最后第四层是选择实现的路径。
+
+<img src="https://static001.geekbang.org/resource/image/50/21/50a374e1f692843b1696308512be9021.jpeg" alt="">
+
+好了，到这里，定义好问题的三个核心要素我们就讲完了，也就是业务价值、范围可控、技术深度。
+
+公司都是很珍惜能够解决问题的人才的，**但是其实能够发现好的问题的人才更可贵。**这需要你首先有这个心，然后出这个力，还要长期坚持，因为定义问题是一个从模糊逐渐清晰的过程。
+
+目前我们部门副总已经明确了安全方向，但是具体哪个部门做什么还没有很清晰的界定，在PaaS 团队的这个问题上，我就特别缺少帮助我定义问题的人才。
+
+那接下来，我们就来看看定义好问题后，怎么找到关键的人。
+
+## 找到关键的人
+
+eBay其实很早就开始做云计算了，在我加入云计算部门之前已经做了两代产品，但是都失败了。
+
+失败的原因我的分析是这样的，云计算部门是由一群软件工程师组成的，而解决基础架构自动化程度不够的问题，却一直是由基础架构运维部门在负责。后来第一代受到认可的云计算自研系统之所以能成功，原因之一就是大领导做了组织重组的决定，把运维团队里最懂eBay基础架构日常问题的最重要的骨干挪到了云计算部门。
+
+我们公司现在正在做自己的支付系统，于是整个公司对安全越发重视。副总更是直接说，我们基础架构工程部接下来最重要的事情就是平台安全。那作为经理我就想到了两个问题：
+
+第一，我们公司做支付已经做了两年了，为什么我没有想到应该提前布局安全，而要副总现在说了我才开始思考。
+
+第二，亡羊补牢未为晚也。我们可以做什么产品能帮助到公司的平台安全。
+
+我找到了总经理，希望她帮忙找安全部门的副总牵线搭桥，然后我主动申请做了公司安全部门在上海的总联系人。通过这个途径，我开始慢慢地熟悉安全部门的各级领导。
+
+我还准备做一件事，就是找到eBay的PayPal部门拆分时分到PayPal去的老同事，向他们学习PayPal在处理支付安全时基础架构部门所经历的变迁，最好能够帮忙引荐其核心人才取经。我的专栏写到这里，我突然觉得甚至可以直接给PayPal的CTO写邮件，看看他会不会回复我。
+
+这里有一点不知道你注意到没有，**我们这里往往需要找到的那个人是领域内专家，而不是通才。**而作为技术经理，除了找有兴趣有潜力的部门内人才做培养计划，也应该不遗余力地的去寻找外部的高手咨询，甚至直接劝高手加入。
+
+## 人理顺了吗
+
+即使你能够定义了一个很好的问题，你也找到了关键的领域专家，你就真的能顺利地启动新的项目吗？答案是不一定的。要知道，如果你推出的是一个颠覆性预案，你就是动了被颠覆的那个产品团队的利益，很容易遭到反对。而很多时候，新的产品刚出来的时候都还是原型，并不成熟，被人找到理由拍死也是有可能的，那这时候怎么办呢？
+
+我想提醒你的是，不要老想着颠覆别人，其实这又回到了决策透明和信任的问题上来了。这就需要我们把相关的人给理顺，这不是一件简单的事儿，需要我们平时花功夫去和项目相关的核心人员沟通交流，尤其是那些持反对态度的关键人员。
+
+我们部门的架构师老T说过一句话很经典：**你要把有可能提反对意见的意见领袖变成你的盟友，帮着你去说服其他人。具体方法就是把问题抛给他，让他参与进来帮你一起想办法，这样他会觉得最终的解决方案有他相当大的贡献。**而很多人因为自己内心要独占功劳或者占大部分功劳的原因，不去主动拉意见领袖入伙，结果后续立项反而遇到更大的阻力。
+
+讲到这里，我们基本上就可以作出一个正确的技术决策并启动项目了。不过，还有一个点我要特别交代下，这也是我自己这几年特别有感触的一点，那就是把握趋势。
+
+## 把握趋势
+
+eBay中国研发中心作为离岸研发中心，这几年的发展很快，现在几乎所有的重点投资项目我们都有参与，而且重要性很高。但是我时常问自己一个问题，每一年总部确定的新启动的重点投资项目中，有哪些是我们部门首先提出来的？结论是很少的，为什么呢？
+
+我的结论是除了总部信息量比我们大之外，另一个主要原因是我对技术趋势的研究跟进不够。我在这里做个回顾，看看技术趋势相关的内容都是在何时出现的：
+
+- 谷歌在2014年开源Kubernetes，在2015年发布了BORG的论文，而我在那段时间却从未关注过谷歌的频繁动作，那基于Kubernetes的最新一代云计算平台自然不可能由我发起。
+- 最近开始火起来的Clickhouse系统，在被总经理教育眼光不够之前，我从未意识到该系统对OLAP分析的潜在巨大影响。而ClickHouse开源的时间早在2016年。
+- 谷歌的Spanner系统和相关论文发表于2012年，在我们公司启动分布式数据库项目之前，我从未听说过谷歌的Spanner系统和相关论文。
+- 据说我们公司的图片存储系统多年前启动时，也是总部的高级别技术专家看了Facebook的Heystack 相关论文。我查了一下，Facebook的这篇论文发表于2010年。
+
+我自己复盘的收获是：当你看到一个比较火的开源系统已经是比较晚了，往前推是业界前沿的技术公司发表的文章（哪怕不是开源的），再往前推是对应领域顶级会议上的论文。
+
+你看，这其实就是**了解技术趋势的时间线：领域内顶级会议论文-业界前沿技术公司文章-开源项目。**你越早能把握这个趋势，你就有越多的时间来准备你要发起的项目。
+
+## 总结
+
+最后，我们来总结下这节课的内容。技术决策的正确与否、质量高低决定执行效率，方向错了什么都是空的，不单影响业务，还会影响团队成员的成长。
+
+今天我们一起梳理了技术决策的准备过程怎么做，首先你要学会怎么定义一个问题，从业务价值高低，解决问题的范围可控和技术深度三个层面来考量，权重依次降低。
+
+技术决策很依赖领域内专家，作为经理我们要去找到这样的人，让他给你提供信息。有时候我觉得我们找专家的劲头，要跟做销售差不多，要动用一切的人脉去找。
+
+接下来，秉承我一直坚持的人和事并行的思路，人一定要理顺，特别是公司里那些意见领袖，你不把他们拉进你的队伍，他们就有可能成为阻力。而且让他们参与进来，还能给你一些技术决策参考，何乐而不为呢？
+
+最后，作为一个技术经理，把握技术趋势会极大帮助你做出有前瞻性的决策，这也是我们的一门必修课。
+
+## 思考题
+
+你能分享一个自己经历的新项目启动的例子吗？你能同时复盘一下，从这个项目启动之前的准备工作中学到的思路吗？
+
+欢迎在留言区晒出你的经历和疑问。如果觉得有所收获，也欢迎把这篇文章分享给你的朋友。

极客时间专栏/技术管理案例课/技术决策者：开始定战略了/23 | 技术决策（2）： 拥有辩证思维，才能在纠结中负重前行.md

@@ -0,0 +1,154 @@
+<audio id="audio" title="23 | 技术决策（2）： 拥有辩证思维，才能在纠结中负重前行" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/97/bb/9742cbd44754b313cf76087f5cdbfebb.mp3"></audio>
+
+你好，我是许健。今天我们聊一聊技术决策的辩证思维。
+
+但凡重要的技术决策，决策过程一般都是很艰难的，决策时需要考虑的点又是千头万绪，再加上决策效果通常是影响重大的，这些直接导致决策者处于焦虑纠结的状态。
+
+我自己也时不时陷入这样的状态，为此我很想总结出一些方法论指导我做决策，就像专栏前面的文章中多次提到的那样，我会从自己实际已经经历的事情和正在经历的具体案例中做分析、做反思。
+
+最后我发现自己总结出来的指导思想就是辩证思想，但是思路还是比较零散的。为了把零散的思路整合起来，我就去看了有关辩证法的资料，其中的重点就是毛主席的《矛盾论》，重新整理了思路，我才觉得较之以前系统了很多。
+
+今天我就想跟你分享一下怎么用辩证的眼光来看待和分析技术决策，希望可以帮助你做出更合适的技术决策。
+
+## 让你觉得痛的才是决策关键点
+
+我在专栏中曾多次提到，想要从根本上有提高的事情都不是简单的事情，如果一个重要的问题已经存在很久了，那你也不要有不经过艰苦奋斗就能解决这个问题的幻想。
+
+但是即使有了这种认识，对我们做技术决策又有什么帮助呢？接下来我们先看一个例子：
+
+我们公司之前的配置管理系统ODB已经服务十年了，里面存放了各种系统的模型，一方面由于很少去除过时的模型，这导致很多模型动辄上百个字段，而且里面还有很多无用字段；另一方面，数据量的膨胀使得ODB系统性能越来越无法满足需求。
+
+一开始我们尝试在原有系统上做改进，但改进版本也就是ODB 2.0系统研发失败后，领导最终下定决心做一套新系统，取名CMS。又花了半年多开发完CMS核心，接下来迎面而来的挑战就是原来围绕ODB的周边系统搬迁问题，对于大部分人来说都会将未知的事物默认为有风险的，这时没有人愿意做小白鼠。
+
+所以，我们必须把一套众人皆知的、具有足够代表性的复杂系统从ODB无缝搬迁到CMS，这样才能有底气说服其他系统搬迁，而这个足够有代表性的系统就是第一代云计算系统Stratus。
+
+第一代云计算系统做迁徙的项目由我们云计算部门负责，我让J做了项目实施评估，最后J告诉我预计需要24周，这个时间投入是我自己预计的两倍还多，而且还需要全组每周两次加班。
+
+当时我问J为什么要这么大的投入呢？要知道这个决策一旦定了，基本上就意味着我们全组半年内任何其他的事情都干不了。J给了我一张单子，上面列出了所有需要修改的源代码文件列表，还有所有的测试需要的投入。
+
+另外，J跟我解释了他特别设计了两处细节保证整个迁移步骤顺利：
+
+第一处细节是设计ODB和CMS读写开关，一开始Stratus仍然读ODB，然后保证下游还没有迁移到CMS系统能正确工作必须双写ODB和CMS，逐步过渡到Stratus读CMS双写ODB和CMS，再过渡到只写CMS。
+
+第二处细节是在切换过程中如果一个任务启动的时候是读ODB，那么即使在执行过程中全局切换到读CMS，为了数据一致性该任务还是应该继续读ODB直到任务完成。
+
+我还记得J跟我说：“许健，要么你找别人来负责这个项目，你要是让我来负责，我就是需要这么多时间和这么多人。”我当时有一种孤注一掷，也就是把所有家当都投进去博一把的感觉。
+
+后来实际执行中，我们发现上线前的各种测试比之前预计的更复杂。最后的结果是在J的预估投入之外，又加了一个月的高强度集成，我们才交付Stratus On CMS这个任务。但是我们上线没有导致任何生产事故，总部的云计算负责人K事后专门给我和J写邮件，K说我们做的工作就像是在高速公路上不熄火换引擎，我们做这么大的动作没有出事故非常不容易。
+
+多年后在做AI Ops异常检测平台的项目时，J还让我做过更难的选择：“许健，我们现在有两种做法：一种是我们按照现在的方法做，三个月后我能交付一个效果比现在好的方案，但是这个方案还是没有办法使客户大规模上线；第二种是我们用新办法投入六个月，到时我们有可能取得突破，使得大规模上线客户成为可能，也有可能什么都做不出来。” 我最后选择了第二种方案。
+
+因为J比较资深，所以一般我让他处理的问题都很关键，而每次他在跟我落实具体投入的时候都让我觉得挺痛的。这么多年下来我开始“喜欢”上这种痛的感觉，如果我认定的重要问题在做决策的时候自己不觉得痛，我反而会觉得不对头，一定遗漏了什么关键点，毕竟世上没有天上掉馅饼的事情。
+
+总结下来就是：**如果你不觉得痛，宁愿相信有什么地方不对劲，那么****就应该继续挖，直到挖到那个让你痛的点为止。**这个思路在我做决策的时候屡试不爽。
+
+比如最近我们要在年底前交付基于Kubernetes的流量管理方案，老孟是总负责，我问老孟需要我做什么吗？他说不需要，我当时就跟老孟说我的感觉不对，这么重要的一个项目，我怎么觉得你给我提的要求一点也不痛呢，然后老孟说了两点要求：
+
+- 现在总部领导一直在强调中美团队合作不够好，信任有问题，但是这个项目要说服总部领导把执行全权交给老孟负责的中国团队完成。
+- 有一个关键依赖是全局流量切换模块GTR，该模块负责人身上的高优先级工作很多，能不能让他承诺把我们对GTR的依赖排进优先级。
+
+这两个要求就有点难了，特别第二个点如果我搞不定我只能自己贴人去做GTR ，这意味着我要砍别的项目了，相当于割那边的肉补这边，这对我来说是很痛的。但是这个感觉让我至今难忘，因为这种痛这说明我们在解决核心问题了。
+
+后来我回顾这个项目，发现项目的交付和后来老孟提到的两点紧密相关，可以说是绕不过去的“痛点”。中美合作的要求如果不落实，就会导致决策缓慢、拖慢整体节奏；关键依赖不解决，后续迁移就跟不上，因为一个新系统如果不去接手原来系统的流量，那就不能算作“完整交付业务价值”。
+
+## 矛盾的普遍性和特殊性
+
+前面我们更多的是从决策的艰难程度去谈，但只是靠着这样的感觉去指导我们做决策还不够，所以我们还要考虑到矛盾的特性。
+
+毛主席在矛盾论中说：“我们的教条主义者在这个问题上的错误，就是**不懂得必须研究矛盾的特殊性，认识个别事物的特殊的本质，才有可能充分地认识矛盾的普遍性，充分地认识诸种事物的共同的本质。**”
+
+我现在看到这句话特别有感触，我觉得我们部门之前就是没有懂得这个道理，才导致我们做了很多努力，却没有特别出色的业绩。这个道理就是想要研究矛盾的普遍性，先要研究矛盾的特殊性。我给你举个例子说明：
+
+我之前在[组织管理](https://time.geekbang.org/column/article/291930?utm_source=pinpaizhuanqu&amp;utm_medium=geektime&amp;utm_campaign=guanwang&amp;utm_term=guanwang&amp;utm_content=0511)那一节的思考题里面曾经提到过开发效率的问题，事实上提高业务开发的开发效率是我们的核心任务，我们有一个团队专门负责测试效率这个事情。
+
+这个团队开发了不少工具来提高开发效率，比如CD Pipeline（持续集成流水线）；测试覆盖率和自动化率统计报表，我们内部又叫这个报表耻辱墙，因为他们把这个报表贴在公司的各个人流量大的场合；还有一个叫My Stage的可以给开发人员创建独立的测试环境的系统。
+
+但问题是这么多年了，业务团队始终在不停地抱怨测试效率低下，而负责测试效率的团队除了抱怨测试环境的基础架构不如生产环境稳定之外，也抱怨开发团队没有对这个问题足够重视，没有编写足够的测试用例。
+
+在今年年初的时候我曾经思考过这个问题，我觉得以一个团队去服务上千名业务开发，如果平均用力，很难起到显著作用，还不如集中力量，盯准一个业务团队在一个点上深入挖掘，我建议在上海集中把支付团队的测试效率提上来，我选择这个方向考虑了下面三点：
+
+第一点，支付是我们公司这两年的重中之重，支付团队的测试效率是值得投入的。
+
+第二点，必须深入一线，并且派遣我们组织内的高级别技术人员到支付团队内部去。以保证我们能够在这个点取得突破。
+
+**我认为之前团队最大的失误就是浮在表面而不是深入一线，因为组织内最优秀的人都在做平台而没有去一线了解具体情况，所以最后做出来的平台，总是由于这样那样的原因，让业务开发的测试效率提升无法达到预期**。
+
+第三点，这也是我考虑问题的重要方面，上海有150多人的支付团队，如果我们在上海按照第二点提到的思路来做，是有本地的支持的。
+
+真正做起来以后，其实也碰到了一些问题，进度没有我想象的顺利，但是我们认为找支付部门做攻坚就是正确的策略。
+
+为什么这么说呢？因为我们正是通过给支付团队做服务这个**“特殊用例”**，才陆续发现了持续集成流水线不规范、消息中间件系统在支付测试场景使用不便、集成测试用例不稳定、多测试环境跟外部第三方支付供应商集成遇到的安全限制等一系列问题。
+
+在努力了一个月之后，支付部门有两个Scrum团队已经开始在日常工作中采用集成发布的流水线。这正是因为我们深入到别人的业务中了，才能体会到这个部门需求的特殊性，再然后把众多特殊的个案做归纳汇总，才会慢慢积累经验，总结出共性。
+
+我现在回头看，这其实就是给我们做技术决策提供了一个很好的思路，**不要一上来就说我要做一个平台，更好的方式是你有一个做平台的心，但是从解决一个具体的客户的问题开始，把这个客户服务好，从中了解实际的需求，解决好了以后再去找下一个客户，在特殊性中总结普遍性。**
+
+这个思路到底靠不靠谱，我们还是要用实际操作去验证。最近我们重新启动云原生体验（Cloud Native Experience）的开发，其实去年我们做过一次，但是做出来的效果并不好，每一个试用的客户总有一些需求我们不能很好地满足。
+
+于是这次我们重启项目之前，内部先开了一个会，团队的骨干老T在会上就直接说：“我很不喜欢我们的项目叫**Generic** On Tess （Tess 是eBay 的基于Kubernetes的云解决方案的代号），我觉得如果现在就奔着Generic去，我们很难成功。”这里老T说的“Generic”其实中文就是通用的意思，我认同老T的想法，觉得不能一上来就搞普遍性。
+
+那个会议我们讨论了3个小时，会后我找到项目负责人，我说我们在2020年第四季度和2021年第一季度各选取两个具体的客户吧，我们先特殊，再普遍，具体计划如下：
+
+第一，上海的数据分析部门因为安全合规要求，正在搬迁他们的应用到新的符合安全要求的Security Zone， 我们2020第四季度的目标是让这个部门的所有跟云平台的交互都能在我们新的Cloud Native的平台上无缝完成。
+
+第二，年底前，我们云计算部门应该能够完成 PCI DSS的合规审核，这样我们2021年第一季度就专注支付部门的应用采用云原生的方式部署，对我们自己的要求也应该是支付部门能够在我们的平台上无缝完成日常工作。
+
+这样我们就从两个具体的部门用例中学习他们的特殊性，并总结公共的普遍性。在跟数据分析部门接触的这几个礼拜下来，我们确实发现他们实际碰到的问题跟我们的想象有不少差别，比如他们把一个系统下的不同组件放在同一个应用实例下，而我们原先的模型是一个组件一个应用实例；再比如他们的应用很多是有状态服务，但原先我们认为他们大部分是无状态服务。
+
+根据实际情况，我们及时做了技术解决方案的调整，如果我们不从一招解决所有客户问题的“普遍性”思路，转变成先解决一个具体的客户的“特殊性”思路，那么这个调整就不会发生，我们就很容易重蹈覆辙。
+
+这里我还要额外提一句，如果你去看主席的矛盾论，关于矛盾的普遍性和特殊性我在本节引用的那句话，还有后半句：“**另一方面，不懂得在我们认识了事物的共同的本质以后，还必须继续研究那些尚未深入地研究过的或者新冒出来的具体的事物**。”
+
+这给了我未来做决策的指导，我在这里可以预测一下，当我们明年对数据分析和支付部门的用例学习整理进行平台化推广给更多部门后，我们还会再次碰到下一个阶段的特殊性问题。
+
+比如说，数据分析部门跟数据打交道的特殊性，以及我们公司没有成熟的数据测试平台在测试环境提供高质量测试数据，很有可能我们的云平台需要去适配实际业务需求，也就是在生产环境下部署数据分析部门测试应用，使得这些测试应用可以获取生产环境数据。这就是主席说的“新冒出来的具体的事物”。
+
+## 用发展的眼光看待矛盾
+
+我清楚地记得有一次公司的高管Debasish在到上海考察，那时他说我们整个部门（包括中美）是**“一直活在明天”**的部门，意思就是我们老是说我们要用最新的技术，用下一代的系统来解决基础架构管理的难题，却不踏实解决现在眼前的问题。
+
+我在之前的[文化建设](https://time.geekbang.org/column/article/293315?utm_source=pinpaizhuanqu&amp;utm_medium=geektime&amp;utm_campaign=guanwang&amp;utm_term=guanwang&amp;utm_content=0511)中提到我们部门要变成“说话算数”的部门，这里我认为最大的阻碍就是要求我们做的新东西太多了，所以我一直对做新东西持保守态度，但是最近我对做新的系统这个问题的认识有修正。
+
+我在[组织管理](https://time.geekbang.org/column/article/291930?utm_source=pinpaizhuanqu&amp;utm_medium=geektime&amp;utm_campaign=guanwang&amp;utm_term=guanwang&amp;utm_content=0511)那节课中提到的Account Resoure Quota的例子，我在相当长的时间内是认为该项目不能有效解决Capacity管理的难题，而且该项目并没有得到Capacity团队的充分认可。
+
+但是随着项目的推进，我有了进一步的认识，我开始问自己Capacity团队已经按照现有的方式管理公司资源这么多年了，为什么在控制资源利用率的前提下，加快客户获取资源的速度这个问题一直没有显著进展呢？
+
+如果我们全面地做分析，就应该把事情和人都考虑到：Capacity团队用现有方式来管理资源，而ARQ的发起人对于现有管理方式不满，这个矛盾事实上打破了原有的平衡。**矛盾暴露了，正确地解决了，事物就发展了。事物就是在矛盾的不断产生和解决过程中得到发展的。**
+
+ARQ这个新项目的启动暴露了矛盾，迫使整个组织重新审视Capacity和Quota的管理方式的意义是积极的。很残酷的一点是，不启动新项目搞“革命”，就很难引起Capacity团队的足够重视。
+
+我再用同样的思路看上文中提到的CMS取代ODB的历程，对公司最大的意义不在于CMS的性能更高，而在于ODB到CMS的迁移这件事的效果，它会迫使围绕ODB打造的所有周边系统重新整理。
+
+进一步说，周边系统整理意味着什么呢？这意味着这十年来积累的所有业务模型得到系统梳理，很多臃肿的模型就可以瘦身了，这就跟一个长期不盘点的仓库因为要引入电子账务系统不得不做一次大的盘点一样。
+
+**辩证地看问题，不再只看矛盾的一个方面，也要看到其对立面。**“活在明天”的云计算部门因为既要做新的系统，又要维护现有系统，头尾不能兼顾导致人员辛苦但是客户反馈却不好。这个情况当然要改善，但这个矛盾同时也存在积极的一面，就是一直在暴露公司基础架构管理的问题，在解决矛盾的过程中，不断推动更先进的方式引入进来。
+
+**辩证地看问题不再静止地看问题，而要发展地看问题。**在当前系统的客户满意度不够的时候，主要矛盾是解决当前客户问题，所以应该以提升现有客户体验为主，研发下一代系统解决明天的问题为辅助；而当前客户满意度提升后，要用更少的资源满足更多需求的这个效率上的矛盾，就会成为新的关注点，那时我们就可以考虑以研发下一代系统为主，维护当前系统为辅。
+
+当我用这样的想法再来看待Openstack和Kubernetes，Service Mesh和集中式流量管理，零信任网络和传统防火墙自动化等问题时，顿时觉得清晰了。
+
+其实，**这些新技术的引入就像一条鲶鱼，可以起到暴露矛盾的作用，打破原来的平衡，关键问题就会逐渐浮出水面，这是好事不是坏事。**我们会因此更加清醒，及时地发现问题，从而想方设法解决问题。
+
+所以这里我想给你的建议就是，我们要辩证地看待和分析技术决策，首先看方向和脚踏实地要兼顾；其次要客观看待矛盾，关注到困难的积极意义，通过“变革”解决问题不断前行；最后不要幻想有“一招鲜”的办法，而是要用发展的眼光看问题，根据当前主要矛盾选择合适的决策方案。
+
+## 总结
+
+今天我跟你分享了做技术决策的辩证思维，这些思维方式都是我这些年来在不自觉中总结出来的，也希望可以帮助你更加系统地进行技术决策。
+
+首先，如果你在决策中不觉得“痛”，就是一个很强的信号。因为**所有值得你去努力的方向都没有捷径，所有能根本上提升组织和个人的方法操作起来都不容易。**这个痛的信号提示你可能有什么关键的点没有考虑到，这时候不要自我感觉良好，请一定把那个让你觉得痛的点挖出来，这个方法在我所做的技术决策中被反复证明有效。
+
+接下来，在你准备执行决策，特别是解决一个比较大的平台级别问题时，建议不要一上来就要做又大又全的平台，而是应该脚踏实地找一个细分客户方向入手，在一个一个特殊性的解决过程中总结问题的普遍性。**要带着一颗做平台的心，从具体的案例开始**。这样才接地气。
+
+作为技术经理，我们越到后来需要处理的技术决策就越复杂，当你**看到事物的一个方面，一定要提醒自己去看一下它的对立面。**比如在你看到一个技术的好处时，一定要想一下你需要付出的代价。看到新技术所引入的不确定性等风险的时候，也要考虑到它打破原有平衡的积极意义和潜在的大幅提升效率的可能。
+
+最后提醒自己要用发展的眼光看问题，每一个阶段有该阶段的主要冲突点，你的技术决策需要以该阶段的主要冲突和矛盾为基础。而周边环境的变化很可能导致矛盾重点的变化，这时我们也要及时作出调整。
+
+<img src="https://static001.geekbang.org/resource/image/32/e8/324b1bee1ce1f7395f2fa8509892c7e8.jpeg" alt="">
+
+## 思考题
+
+我们副总最近确立了我们部门以平台安全为第一优先级，并成立了一个单独的团队来负责这件事，副总说平台安全需要做好几年，但是目前我们并没有很清晰的平台安全架构和执行计划，如果你是这个新成立团队的负责人，你准备怎么做？
+
+能否找一个你现实中的项目的技术决策，最好是那种很纠结的技术决策，然后我文中提到的辩证思维来分析这个技术决策案例并分享出来。
+
+欢迎在留言区晒出你的经历和疑问。如果有收获，也欢迎把这篇文章分享给你的朋友。

极客时间专栏/技术管理案例课/技术决策者：开始定战略了/24 | 技术决策（3）：持续跟进进度，执行细节决定成败.md

@@ -0,0 +1,181 @@
+<audio id="audio" title="24 | 技术决策（3）：持续跟进进度，执行细节决定成败" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/cc/e2/cc64dcyy5a3e7def6397de15bd3aaee2.mp3"></audio>
+
+你好，我是许健。今天我们来聊一聊技术决策的执行问题。
+
+我在[人才招聘](https://time.geekbang.org/column/article/282069)中讲了招聘的时候要追问细节，在[进阶心路](https://time.geekbang.org/column/article/286095)里提到二线经理要下沉两个汇报级别到一线了解细节，在[危机管理](https://time.geekbang.org/column/article/293155)中还提到过我自己被架空的一个重要原因是没有深入到日常的团队运营中去，本质上就是没有去了解关键路径的关键细节。
+
+为什么我一直这么强调细节呢？因为我自己经历了好几次教训，追根溯源才发现都是因为忽视了细节，准确地说是对**关键路径的关键细节**不够重视。
+
+今天我想跟你聊的就是技术经理如何把控细节，如何通过技术细节交付好业务，培养好人才。
+
+## 做完决策就可以了吗？
+
+首先，我们做完决策就可以了吗？答案是否定的。
+
+我看过一本叫《执行》的书，里面有这样一段话：“这样做领导当然舒服喽，你只需要站在一旁，进行一些战略性的思考，用你的愿景目标来激励自己的员工，而把那些无聊的具体工作交给手下的经理们。我在这里要提出的是，这种思考问题的方法是错误的，它很可能给你带来难以估量的危害。”
+
+我对这句话深有体会。做决策只是起点，如果止步于此，等于空谈，为什么这么说呢？如果我们觉得决策做完了就万事大吉，那么常常就会有这样的后果：
+
+第一，是经理自己被架空。哪怕我们通过决策把工作优先级聚焦到了核心问题，但决策落地最后还是要靠执行的。如果不能把握关键细节，完整地跟进进度，经理就容易把自己架空。
+
+第二，会导致业务价值无法按时交付。有一次总部领导质问UX小组半年内没有交付业务价值，事后我跟UX小组的经理复盘时，才发现我们当时对于关键依赖的解决不及时，人员不够专注，而且起初的设计也过于复杂。但得出这三条总结已经是事后诸葛亮了。
+
+第三，就是无法解决部下的困难，再远大的目标最后还是要一步一个脚印地推进，技术经理要了解一线的具体困难，采取行动解决，否则会直接影响到自己的领导力。
+
+我这里想说的是，无论是一线技术经理还是二三线技术经理，尤其是二三线技术经理因为会花更多的时间考虑战略文化等事务，所以更要时常提醒自己去了解关键路径的关键细节。
+
+我们不要把自己架起来，因为一个项目一个产品不是静止的，在项目和产品的发展过程中会不断的出现问题，这些问题你不能单方面的等着下属自下而上汇报，也应该由上而下去了解。
+
+只有注重了关键的细节，你才能对你手上的关键产品和项目有比较全面的了解，才能持续地根据实际情况做后续的技术决策，**技术决策不是一次性的买卖，需要为了达成目标做持续修正，项目没有交付前就不能放松警惕。**
+
+## 关键细节如何把握？
+
+我们知道了执行细节很重要，那具体应该怎么把握这些细节呢？
+
+一般在执行过程中我会同时使用下面三种方式来了解执行状况，从而保证执行达到预期效果：
+
+### 方法一：执行负责人要制定可衡量的阶段性目标
+
+我的经验是计划会变这一点我认可，但是我不接受因为这个理由就不去制定计划。
+
+虽然我们可以理解很多事情很难估计时间，强行制定时间表的话最后也许就不能交付。那么很难估计时间的话，目标到底怎么制定呢？
+
+我的方法就是必须定计划这一条没有商量余地，但是可以做拆分，直到拆分的单元可以很好地做衡量。
+
+具体来说，就是如果季度目标不准就定月度，月度目标不准我们就每两周一次的Sprint目标，再不行我们就定每一周的周计划。
+
+### 方法二：定期的项目评审和周报
+
+为什么我要强调定期呢？定期的作用就是给执行负责人传递一个明确的信号，也就是他的上级技术经理正在持续关注他的进度，愿意及时解决他的实际困难。
+
+同时，这么做对执行负责人也是一种压力，每一次到了项目评审和周报的时间点，他都需要给领导和给同仁看到进度。
+
+关于项目评审和周报有下面三点注意事项：
+
+第一点，我不要听流水账，所以负责人要对照项目之前定下的阶段性目标来汇报进度。
+
+第二点，如果项目进行过程中有阶段性目标达成，或者有值得肯定和表扬的点，我会要求负责人单独注明。
+
+第三点，项目中碰到的问题也需要单独标注，这一条非常重要。我一般会建议执行负责人用绿，黄，红三色来对问题分类。绿色是已经解决的问题，黄色表示虽然出现了问题，但是执行负责人已经拿出了具体的措施在解决问题，目前还不需要上级领导介入，而**红色表示要求上级经理介入或者提供帮助。**
+
+在[辩证思维](https://time.geekbang.org/column/article/295028)一节中我讲到自己的一个思维习惯，就是重要的项目在决策过程中要挖掘痛点，如果没有挖掘到，我就会觉得有潜在问题，然后继续深挖。
+
+同样的，在决策执行过程中我想给你分享我的另一个思维习惯，如果我在项目评审和周报里只听到好消息，从来听不到困难和坏消息，我就会给自己提一个醒：这么重要的事情，在执行过程中这么一帆风顺正常吗？这会直接导致我找一线骨干做Deep Dive。
+
+### 方法三：不定时地找团队一线骨干做Deep Dive
+
+在日常工作中，技术经理要下沉两个汇报级别，去找一线骨干了解细节。其实我们在做关键项目的执行时更应该如此。
+
+具体怎么做呢？我是带着希望这个项目成功的心去“挑刺”的，我通常会这样去思考：**如果有三个原因造成我这个项目失败，是哪三个原因？我现在可以作出什么举措降低失败几率。**
+
+通过找团队的一线骨干了解细节，我发现自己对项目的了解更加全面，也能尽快发现实际操作下来经常发生什么样的问题，下面三类问题是最常见的：
+
+第一，对性能压测和失效性分析重视程度不够。我们部门在吃过几次苦头以后，在这一点上已经比较重视了。墨菲定律在我们部门负责的项目上几乎次次灵验。
+
+第二，对关键依赖过于乐观。现在我们部门对于关键依赖我的建议是：没有书面承诺交付时间的，就当这个依赖没有搞定，应该找高级别技术主管介入。
+
+第三，技术实现时夹带必要功能之外的加分项功能。从我们部门目前实际的执行历史看，在核心功能交付前，所有锦上添花的功能都应该全部砍掉。
+
+## 持续跟进的注意事项
+
+前面我们说了关键细节如何把握，但细节更多的还是一些关键节点，在技术决策的执行中，持续跟进还需要一个线性的思维，树立起对决策、对自己角色以及对未来如何做预判的认识。
+
+### 决策不等于落实
+
+请你跟着我回顾一下自己做经理的经历，我们总能轻易举出一系列半途而废的事情，这些事儿都是我们做了决定但是却没有跟进，最后不了了之，没有落实。那么问题到底出在哪里呢？
+
+**第一种情况，就是做了“建议”没有跟进。**这里我专门用了“建议”这个词，而没有使用“决定”这个词，这是因为如果我们都不去跟进确认，就不能算作决定。
+
+我给你举一个具体的例子来说明。我们部门已经多次出现误删操作，因为权限管理太松，发生过不应该有权限的人误操作，结果删除整了个测试数据库的情况。最近一次是因为数据质量问题，系统误删了生产环境流量入口，幸好部署了高可用HA防护才没有出大事。
+
+我做复盘的时候，想起我虽然一次一次建议要引入保底措施，在删除逻辑中加入流量检查保护。但到目前为止，我只是反复在强调不采取措施的风险，这个风险就是一旦出问题影响业务，会导致打乱我们所有的原定计划，然后全员都要去做系统可靠性强化工作。
+
+我的部下不是笨蛋，如果没有落实一定有现实的困难，需要我去了解具体的困难。很有可能落实这项工作是需要以牺牲功能开发为代价的。再联想到我一直强调“说话算数”，也就是我们部门承诺的功能一定要按时按质交付，我觉得问题出在自己只是做了建议，但没有继续跟进。
+
+我们不止一次踩了坑，还是出问题，想要改变一定是艰难的，那这个艰难决定一定是组织一把手来做。
+
+**第二种情况，就是没有落实标准。**在我们部门最常见的就是出了一个生产事故，于是在风头上大家都很重视，制定出一系列举措。问题是我们很少会去重现那个生产事故，通过测试进一步确认我们落实的那些举措的有效性，也就是在下一次发生类似事故时，我们指定的举措是否真正能够起作用。
+
+比如说我们上个月发生的一件事儿，因为一个BUG，PaaS系统的一个超级账号抹掉了整个测试环境监控系统，这个事故我们花了四个小时才恢复服务。
+
+在复盘会议上，团队成员觉得以后我们可以在20分钟内恢复服务，但这个想法没有落实到测试环境中检验，其实很难立住脚。
+
+所以我明确要求监控组一定要复制一套一模一样的线上系统，再做一遍删除系统后恢复的模拟测试。要知道，我们设想中可以20分钟完成的恢复操作，和真的做一遍，验证一下在20分钟内能不能恢复是不一样的。
+
+其实本质上这类问题都反映了技术经理的重视程度，特别是和经理是否能够持续重视密切相关。作为技术主管，你选择要落实自己做过的决策，为了真的落实你就会愿意花时间。
+
+更重要的一点是你愿意延后、甚至取消你想做的其他事情，来给你自己和你的团队腾出精力专注落实这项决策。
+
+### 经理也是执行者
+
+**就算我们已经给关键项目安排了负责人，作为主管经理，我们同样也是执行者。**怎么理解这句话呢？经理不是在项目启动的时候定一下方案，然后安排一下人手，接着定时听听汇报，做做1:1 和Deep Dive就够了，经理得为员工办实事，这就是我说经理也是执行者的意思。
+
+我自己在听定期的工作汇报或跟一线骨干做Deep Dive，经常跟团队成员说的话是这样的：领导的工作不单单是给你分配任务，也包括帮你解决你的困难，领导最不希望看到的就是到了快交付了你跟领导说因为这样那样的原因，项目不能如期交付。
+
+所以，**如果你觉得有风险需要领导介入，就应该第一时间跟领导沟通。你要有这个气场可以给领导安排工作。**
+
+在我们一个冲突比较激烈的项目中，我甚至对技术负责人说过这样的话：“这个项目如果你搞不定技术实施是你失职，如果我搞不定Alignment 是我无能。”
+
+其实这么说，就是因为我认为经理本身也是执行者，关于这个问题，我有三条原则和你分享：
+
+第一，如果部下反映了问题，我能够解决的必须马上解决，不能拖，更不能石沉大海。
+
+第二，如果部下反映的问题我不能马上解决，那我需要告诉部下我大概在什么时候可以解决。
+
+第三，如果我评估下来我也无力解决，我会告诉部下不能解决的原因。
+
+当然，原则还是要结合实际场景才能体现，总结一下就是我们应该把定期的工作汇报会议变成解决问题的现场办公会议，而不是一个给领导单项汇报工作的汇报会。作为领导，要给部下反馈和采取后续动作，做得好的不要吝惜表扬，碰到问题了领导也是执行者需要切实解决困难。
+
+### 早点到真实环境历练
+
+我们都知道，管理“未知”是最难的，有时候我们可以预判后面执行还会有这样那样的问题，但这些问题你是很难事前预料的，这时候应该怎么办呢？我的做法就是早点放到真实环境去历练，争取尽早暴露问题。
+
+我结合具体的业务案例来说一说，我们公司因为要应对购物季的流量高峰，每一年在购物季之前，都需要流量管理团队加班，加班的任务就是把数千对负载均衡器上的流量平均分配好。
+
+今年因为疫情原因，eBay网站流量高峰提前到来，这也导致了问题的加剧。副总给了死命令要在今年三季度结束前完成流量重分配100%自动化。
+
+因为这样的情况，我在跟流量管理团队做定期审核的时候最最关心的问题，就是什么时候可以Dry Run（在线上模拟运行）。我担心自动化没经过试验，存在影响业务稳定进行的风险。事实上，我们在所有功能都开发好以后Dry Run的自动化成功率只有10%，强化一个月后达到70%，再强化一个月后达到80%。
+
+今年年底前我们需要交付的Os Patching也是一样的，公司的安全合规要求越来越高，这对我们全网Patching的挑战就越来越大，十几万台机器的OS Patching从半年一次到一个季度一次，甚至到明年要达到每个月一次，我们觉得引入独立集算法可以增加升级并行度加快速度。
+
+但真正跑起来，应用重启后也许不能自动恢复到正常状态，多应用同时重启压垮下游服务，NOSQL类应用升级时数据重平衡时间过长，这一系列问题让我们举步维艰。最后，我们得出的结论就是早点去战场上历练吧，我们只有提前去线上摸爬滚打，才能把十多年积累的“垃圾”都暴露出来。
+
+## 通过关键细节做人员选育
+
+作为一名技术经理，最后还是要回到人才培养上来。我认为重要的关键项目除了交付业务价值，另一个重要作用就是培养人才。那具体怎么培养呢？
+
+我最近半年最大的收获就是**指出关键细节上的差距。**技术主管只有深入一线了解关键细节，才有可能对执行这些项目中的骨干提出有建设性的高质量意见。这些意见对于项目骨干的成长意义重大。
+
+不知道你是否记得，我在[员工沟通](https://time.geekbang.org/column/article/279026)那一节就提过跟高级别技术骨干不能光谈原则，必须落实到具体的细节。我之所以能够重新审视我们部门的执行文化，并作出改变，正是因为自己的老板指出了我在细节上的差距。
+
+当时我的老板指出我鸡血很足，但是对部门要求并不高，而且她拿着兄弟部门的团队业绩，人才梯队甚至还有对派遣人员的培养计划来做佐证。如果我领导不拿着具体的细节给我看，恐怕不会有这么大的触动效果。
+
+这么做的好处是当你给具体的细节的时候，听的人其实已经从具体的实例中自己得出了你想要的结论，这时候你再说出结论，就更容易被听的人接受。
+
+这个抓细节的思路我也应用到了自己培养部下能力的过程中。比如我跟经理X确定了他今年必须有一个目标，这个目标是培养他的左右手到没有他在也能独当一面的水平；我还找到我们部门的技术骨干E，跟他探讨一下为什么我们部门的关键项目不能由一名骨干带上一批派遣人员来实施，而兄弟部门却可以。
+
+有了细节当作切入点，我们对手下的培养就不是空谈的方向了，而是拿着关键细节作为抓手，引导员工尤其是项目骨干找到矛盾点，在解决矛盾的过程中提升自己的水平。
+
+## 总结
+
+今天我给你分享了技术决策后对执行细节的掌控是项目成败的关键。
+
+首先我提到了作为经理，特别是高级别经理的一个大坑，也就是整天关注战略层面的宏观问题，听听报告而忽略对关键项目的关键细节的把控。
+
+接下来，我给你总结了掌握执行细节的三个方式，分别是设定可衡量的阶段性目标，定期做项目审核和周报，以及不定时跟项目一线的骨干做Deep Dive。我们始终要未雨绸缪，时常问问自己如果我这个项目失败了会因为什么原因，从而及早作出安排。
+
+然后，我们要认识到做技术决策不是一次性的买卖，技术经理必须用发展的眼光做持续跟进。决策不等于落实，技术经理可不能就听听报告，你需要及时了解关键细节使得你能够及时指出调整。
+
+我特别强调了技术经理应该把工作汇报的会议开成现场办公的会议。我们不可能一次性掌握所有情况，很多事还处于未知状态，我们就很难推演怎么降低风险。所以，我建议是尽早到逼近真实战场的环境中去历练，毕竟实践出真知。
+
+最后我们还是回到执行细节对人才培育问题上的意义。我自己对部门的要求还不够高，这一点我觉得是我们部门这两年来人才培养上的两大缺陷之一（另一点是给关键骨干全权负责关键项目的机会）。意识到这一点，我在今后还会继续提高，通过细节入手，让团队成员变得更强。
+
+我的建议是，对我们的骨干要高标准、严要求，而指出他们的问题时，就要拿出具体的细节上的差距。**高标准严要求，甚至是用严厉的语气明确说出来哪个具体的点做得不够好，这对唤醒人的自我觉悟，提升人的能力帮助很大。**
+
+## 思考题
+
+请结合你的实际经历，分享一个你自己注重执行细节的正面案例或者反面案例。
+
+我们大部门有一个小组既要维护现有系统又承诺了新系统的多个子系统的研发，但是该小组经常需要救火，承诺的时间点也出现不能准时交付的情况。总部领导跟我谈起这个状况时，说他会给该小组经理更多的压力，你怎么看待总部领导给更多压力的解决方案呢？
+
+欢迎在留言区晒出你的经历和疑问。如果有所收获，也欢迎你把这篇文章分享给你的朋友，说不定就能给他一些启发。