技术管理案例课_23_22_技术决策1技术管理者做什么团队效率才最高
你好，我是徐建。
在前面两个模块里呢，我给你分析了作为一名一线经理常见的坑，从关注事情到同时关注事情和人的转变，在招人培养人才人方面的注意点，还有跟领导和跟高级别员工的沟通心得。
接着啊在二线经理的部分，我们要用具体的例子，从变革、管理、冲突、管理组织和文化危机管理等多个方面介绍了一名二线经理。
相对于一线经理所面临的进一步挑战。
那么从今天开始啊，我们进入课程的最后一个模块，技术决策这个模块呢是我特意放在最后的。
而且我认为正是因为有了这个技术决策模块，才能体现技术管理和一般管理的区别。
这个模块我设计了三讲，今天就先来带你讨论启动一个项目时，技术管理者都应该做什么，才能让团队的效率最高。
为什么要讨论这个话题呢？我先给你举个很简单的例子，有这么一个部门。
当前最大的痛点是开发效率不高，而开发效率不高的原因是测试困难。
测试困难最大的问题是因为缺少高质量的测试数据。
如果你是部门领导，你会怎么做呢？如果你做出的决策，没有从高质量的测试数据这个关键事项入手，很有可能就走偏了。
比如，我们把大量的研发力量都投入到构建新一代的基于容器的持续交付CD pipeline.就算构建的这个流水线很先进了，如果无法提高测试数据质量，那么也就无法提高开发效率。
而且呢因为我们要做新的CD pipeline,就投入了大量的人手。
这些人手本来可以去做更有意义的事情，这么一算啊，因为这个决策团队效益还可能是负的。
你看一个部门具体做什么，本质上是由这个部门的一把手决定了我们课程前面讲的所有管理技巧。
如果没有这里说的做正确的事情，那就都是浮云。
好了，说到这里，做一个正确决策的意义和价值，我想就不用再强调了。
那接下来我们最关键的问题就是到底怎么才能做到呢？接下来我就带你一步一步来找到答案。
这第一步就是定义好问题。
第一句话叫做优秀的人眼中都是活这句话说的很有道理。
不过放到我们现在说的战略决策场景下，这样是不够的。
在实际工作中啊，不会像文章里我一开始给你举的例子那样，痛点和难点都那么清晰的，你通常会看到很多的点。
但是作为经理，你不能眼里全是点，你需要更进一步尽快找到那个打蛇打七寸的点。
因为你要带着团队在这个点上长时间做投入的这是关于你的整个团队。
接下来几年发展的点，我们还是结合具体的例子。
来吧，站在我们部门的pass团队，解决团队遇到很多挑战。
比如说下面这些挑战，第一个挑战呢就是我们整个技术战正在往coubtities转，目前是当前系统和新系系统双线作战。
我是不是应该把把所有的系统彻底来吧。
第二，挑挑战这样样的。
我虽虽然迁移到新技术战，但是是然完问题长期无法得删除战点，如IIP分配冲突，比如实现自动且无风险的删除操作，还有淘汰不再使用的线上应用等。
第三个挑战是公司正在往流量、管理、设备、软件化、分布式化演进。
Pass团队的成员要不要加入这个方向呢？比如iste或者invoy公司，因为做支付，对基础架构安全性要求越来越高。
Pass团队要不要去做技础架构安全方向呢？刚才说的这些是几个比较典型的挑战事项，其实我还可以列很多。
那么问题来了，我们现在不是选择太少，而是选择太多，那我们应该按照什么样的原则来做决定呢？ Pass的经理啊，曾经让我在下面三个因素中做排序。
第一个因素是为业务产生价值。
注意啊，有些人产生业务价值的事情并不需要很强的技术支撑，比如系统集成和客户服务质量。
第一个因素呢是技术实施有深度员工做的这个项目自自身市场竞争提提高太少。
还有一个因素就是解决问题的范围可控，对外依赖少。
我最后的排序啊是业务价值优先于范围可控，范围可控，又优先于技术实施。
深度pass的经理说它也是这个方向。
那接下来我就按照这个顺序，从业务价值范围可控到技术深度带你逐一剖析。
不过啊这里我需要强调一点，如果你没有办法把现在手头的日常工作的效率提高，从而空出人手。
那么先别去想新东西了，也就是前面pass团队的三个挑战。
在淘汰老系统和解决固有问题完成之前，做新东西，这个决策根本实施不了。
我们先来看业务价值。
可以说凡是启动新的项目，大家都会说自己是为了业务。
我想说的是，有没有业务价值不是你说了算，而是你的客户说了算。
可是又有人说不可以用户说了算，也就是很多时候都不知道他们要什么。
你看乔布斯就这么说，可是我们毕竟不是乔布斯，如果一个人想要就业务价值发表问题，我通常会先思考下面两个问题，说这句话的人到底花多少经历跟客户在一起，说这句话的人之前是否有过让客户经验的经历？如果两个问题的答案都是否那还不如踏踏实实的先去解决一些问题，也就是解决几个我们明确知道的客户痛点，再来发表高论吧。
回到前面pass团队的问题，我们来对比一下，对于业务价值不同的表题，我把不同表述用表格列出来。
可是你文稿里看了下，如果你不方便看文字，也没有关系吧。
给你简单知述说表里的内容。
对于测试环境稳定性问题，表述，一是这样的我们目标标百分之一百，把测试环境从open stack迁移到coubonalius.而比如说二是这样的，我们的目标是通过迁移，使测试环境可靠性提高到百分之九十九点九五对安全合规要求表述。
一是我们的目标是干掉现有系统而表述。
二呢是这样的，我们的目标是用新系统实现云原生，才有可能实现monthly patching的安全目标。
在总人数不能增加的前提下，我必须先干掉现有系统，才能把现有系统的维护人员鲁网新系统研发，还有IP分配顽固问题表述，一是我们的目标干掉rus并迁移到ipad而表述二则是我们要彻底解决IP分配冲突导致业务受损的隐患。
通过对比，你有没有发现这两种表述的不同呢？表述一更多的是在说技术实现或者陈述一个任务而表述。
二呢才是真正的从价值层面来阐述为什么要做一个投资。
而举一个很现实的例子做解释测试环境稳定性问题。
如果按照业务表述，一大家的关注点就是那百分之一百的迁移指标。
但是业务表述二强调的才是真正的测试环境、可靠性问题。
事实上也是这样的这件事啊，我们就是因为没有强调真正的业务指标，后来导致一大堆互无抱怨，甚至投诉到了CTO那里。
而IP分配的顽固问题，是我现在向团队反复强调的点，不要在我面前再反复说，我们要用新的ipad系统替换rus,请明确我们的问题，解决方案迁移只是方法，彻底杜绝IP冲突问题才是目的。
定义好了，我们的目标，也就是确定了业务价值。
我们再来讨论问题范围。
你是在公司做事需要按阶段交付业务指标，你的交付时间拖得越长，别人对你期待越高，失败风险越大。
以pass团队IP网段的问题来说，最初分配其实就是网络部门管理，而网络部门并不隶属于云计算部门。
如果我要pass团队解决这个问题，必须评估网络部门的配合程度，最好网络部门有专人负责并绑定他的年度业绩。
我给你总结一下问题范围可控的注意点演示图给你放到文稿中了。
你可以去看一下图里描述的内容是这样的问题，范围可控制点需要你把解决问题的依赖全部列出来，然后对每一个依赖评估重要程度和你对这个依赖的控制力有多强，对关乎你成败的重要依赖。
如果你的控制力不够，要么你能够得到领导的足够支持，搞定这个依赖。
要么你能够重新审视你的技术决策，看看能不能去除这个依赖。
如果都搞不定，请问问自己这个问题是不是应该由你来解决？最后我们来说说技术实施深度的问题。
虽然在定义问题的考虑因素时，我把它排在了最后一位，但这却是我在技术决策中最棘手的一个问题。
为什么这么说呢？因为事情啊都是人做的。
团队成员除了交付业务价值外，还会关心自己的市场竞争力。
如果实施的技术深度不够啊，也就是说不足以让成员感受到他自身的实力会因此提升，那他的积极性是不高的。
还有一个很现实的问题摆在眼前，如果不是奔着市场上很火的技术方向，走你很难招到高质量的人才。
相信我，我也曾给自己打技术，真正优秀的人才呢才不看技术战的哪种技术，只要做到极致，都是高手。
但现实让我不得不重新审视这个问题。
比如，虽然我很想给pass团队补充优秀人才，但无论从数量还是质量上来说，我在cobnative方向收到的简历都优于pass.具体到pass团队问题三，也就是如果做基础架构安全方向如何更加快速的满足安全合规要求呢？我的思路是这样的，第一呢就是业务价值优技术术啊，必须务务业务。
这也是我们在定目标的时候，为什么先强调业务价值，而不是技术手段？特知道需要我们好好学习一下。
Pcidss和GDPR规范，也就是支付行业数据安全标准，却通用数据表护条例规范安全合规要求设及用户隐私信息的交互不能泄露，不能篡改。
第二，首选公司内长期不能得到解决的棘手问题，特别是那些历经几代技术变迁却长期无法解决的问题，尤其值得我们关注。
比如，不影响业务前提下，我希望我们具备给大规模模术架架构安全强化的能力。
具体来说，就是如果安全需要，我们就可以迅速给任意应用之间通讯升级TLS版本。
要知道啊，我们公司上一次只是给PCI环境应用升级，TIS到一点二，就动用了业务开发、流量价值运维网站监控多部门一起在worroom会战了数个月才完成。
另外啊我还想发展一项能力，就是能给安全需要的任何应用添加力度，更细的权限管理。
第三，我不想跟趋势斗了，看看有没有什么新的技术趋势可以陈述效应解决问题。
比如去看看业界做安全的公司，现在在解决什么问题？安全方面有什么重要的会议和期展。
这个时候零信任beyond corp SSO oss APT,这些名词就会进入我们的视野。
从趋势来说呢，我会倾向决策模块往beyond cop,多维度决策引擎方向发展，执行模块往invoy side car这样贴近应用的非侵入方式发展。
所以我们的关注点应该放在智能IM和involy上。
第四，试图以最短路径交付效果绝对，要克制贪念，控制作战范围。
小步迭代。
比如啊我一定要使用SQ加involy这个方法来实现更细粒度的应用间隔离吗？还是就使用involy和公司内部已经有的IMIDM系统集成呢？我倾向于第一阶段先跟公司现有系统集成，逐步过渡到e stl的方式。
而智能IM的事情，也应该先选取一个核心系统部署智能IM,而不是一上来就要做一个又大又全的新方案。
其实关于技术深度这个问题，我是层层深入和筛选关键点的。
首先框住为业务服务这个大框架。
然后第二层着眼解决现在的难点，这是第三层是选择符合趋势的人才。
最后，第四层是选择实现的路径。
目前这个分析方法做成一张漏斗图，给你放到文稿里了，你可以去看一下。
好了，到这里定义好问题的三个核心要素我们就讲完了，也就是业务价值范围可控，技术深度公司都是很珍惜能够解决问题的人才的。
但是其实能够发现好的问题的人才更可贵，这需要你首先有这个心，然后出这个力还要长期坚持。
因为定义问题是一个从模糊逐渐清晰的过程。
目前我们部门副总已经明确了安全方向，但是具体哪个部门做什么，还没有很清晰的界定。
在pass团队这个问题上，我就特别缺少帮助我定义问题的人才。
那接下来呢我们就来看看定义好问题后怎么找到关键的人。
易贝啊，其实很早就开始做云计算了，在我加入云计算部门之前，已经做了两代产品，但是都失败了。
失败的原因啊，我的分析是这样的，云计算部门是由一群软件工程师组成的，而解决基础架构自动化程度不够的问题，却一直是由基础架构运维部门在负责。
后来，第一代受到认可的云计算自研系统之所以能成功，原因之一就是大领导做了组织重组的决定，把运维团队里最懂易备基础架构。
日常问题的最重要骨干，挪到了云计算部门。
我们公司现在正在做自己的支付系统，于是整个公司对安全越发重视。
副总更是直接说，我们基础架构工程部接下来最重要的事情就是平台安全。
他作为经理，我就想到了两个问题，我们公司做支付已经做了两年了，为什么我没有想到应该提前布局安全而要副总？现在说了，我才开始考虑呢。
亡羊补牢，未未晚矣。
我们可以做什么产品能帮助到公司的平台安全。
我找到了总经理，希望他帮忙找安全部门的副总牵线搭桥。
然后我主动申请了做公司安全部门所，上海的总联系人。
通过这个途径啊，我开始慢慢的熟悉安全部门的各级领导。
你还准备做一件事情，就是找到易贝和paypal部门拆分时分到区的老同同向他们学习payppaypal.在处理支付安全时，技术架构部门所经历的变迁，最好啊能够帮忙引荐其核心人才取经。
我的专栏写到这里，我突然觉得我甚至可以直接给payer的CTO写邮件，看看他会不会回复我。
这里有一点不知道，你注意到了没有？我们这里啊往往至需要找到那个人。
领领域内专家，而不是通采。
而作为技术经理，除了找有兴趣有潜力的部门内人才做培养计划，也应该不遗余力的去寻找外部的高级咨询，甚至直接做高手加入。
即使你能够引进了一个很好的问题，你也找到了关键的领域专家，那就真能够顺利的启动这个新的项目吗？答案是不一定的。
要知道如果你推出的是一个颠覆性预案，你就是动了被颠覆的那个产品，团队的利益很容易遭到反对的。
而很多时候呢，新的产品刚出来的时候啊，都还是原型并不成熟，被人找到理由拍死也是有可能的那这个时候你该怎么办呢？我想提醒你的是，不要老想着颠覆别人，其实这又回到了决策透明和信任的问题上来了。
这就需要我们把相关的人给理顺。
这不是一件简单的事儿，需要我们平时花功夫去和项目相关的核心人员沟通交流，尤其是那些持反对态度的关键人员。
我们部门的架构是老梯说过一句话很经典，你要把有可能提反对意见的意见领袖，变成你的盟友，帮着你去说服其他人。
具体方法就是把问题抛给他，让他参与进来，帮你一起想办法。
这样他就会觉得最终的解决方案也有他相当大的贡献。
而很多人因为自己内心要独占功劳或者占大风功劳的原因，不去主动拉意见领袖入伙，结果后续立项反而遇到更大的阻力。
讲到这里啊，我们基本上就可以做出一个正确的技术决策并启动项目了。
不过呢还有一个点，我要特别交代一下，这也是我自己这几年特别有感触的一点，那就是把握趋势。
易被中国研发中心作为离岸研发中心，这几年的发展很快，现在几乎所有的重点投资项目我们都有参与，而且重要性很高。
但是我时常来问自己一个问题，每一年总部确定的新启动的重点投资项目中有哪些是我们部门首先提出来的，结论是很少有我们先提出来的那为什么呢？我的结论是，除了总部信息量比我们大之外，另一个主要原因是我对技术趋势的研究跟进不够。
我在这里做一个回顾，看看技术趋势相关的内容都是在何时出现的。
谷歌在二零一四年开源cubnetis在二零一五年发布了bog的论文，而我在那段时间内却从未关注过谷歌的频繁动作。
那基于cubnatis的最新一代云计算平台，自然不可能由我发起。
最近开始火起来的click house系统在被总经理教育眼光不够。
之前呢，我从未意识到这个系统对o lap分析的潜在巨大影响。
而click house开源的时间早在二零一六年，谷歌的spanner系统和相关论文发表于二零一二年，在我们公司启动分布式数据库项目之前，我从未听说过spanner,就说我们公司的图片存储系统。
多年前启动时也是总部的高级别技术专家，看了facebook的histack相关论文。
我查了一下facebook的这篇论文发表于二零一零年，我自己复盘的收获是这样的，当你看到一个比较火的开源系统，已经是比较晚了。
往前推是业界前沿的技术公司发表的文章，哪怕不是开源的也要看。
再往前推呢，就是对应领域顶级会议上的论文。
你看这其实就是了解技术趋势的时间线。
你越内顶级会议论文、业界前沿技术、公司文章、开源项目，你越早能把握这个趋势啊，你就有越多的时间来准备你要发起的项目。
最后我们来总结一下这节课的内容。
技术决策的正确与否，质量高低决定执行效率。
方向错了，什么都是空的，不但影响业务，还影响团队成员的成长。
今天我们一起梳理了技术决策的准备过程是怎么做的。
首先啊你要学会怎么定义一个问题，从业务价值高低、解决问题的范围可控和技术深度三个层面来考量，权重依次降低技术决策。
很依赖领域内专家作为经理，我们要去找到这样的人，让他给你提供信息。
有时候啊我觉得我们找专家的镜头要跟做销售差不多，要动用一切的人脉去找。
接下来呢秉承我一直坚持的新和事并进的思路，人一定要理顺，特别是公司里那些意见领吗吗？不把他们拉进你的队伍，他们就有可能成为阻力，而且让他们参与进来，还能给你一些技术决策参考，何乐而不为呢？最后啊，作为一名技术经理，把握技术趋势，会极大帮助你做出前瞻性的决策，这也是我们的一门必修课。
在本节课的最后，我给你留一道思考题，你能分享一个自己经历的新项目启动的例子吗？你能同时复盘一下从这个项目启动之前的准备工作，中学到的思路吗？欢迎在留言区晒除你的经历和疑问。
如果你觉得有所收获，也欢迎把这篇文章分享给你的朋友。