|
|
# 22 | 技术决策（1）：技术管理者做什么，团队效率才最高？
|
|
|
|
|
|
你好，我是许健。
|
|
|
|
|
|
前面两个模块，我给你分析了作为一名一线经理常见的坑，从关注事情到同时关注事情和人的转变，在招人，培养人，裁人方面的注意点，以及跟领导和跟高级别员工的沟通心得。接着在二线经理的部分，我们又用具体的例子从变革管理，冲突管理，组织和文化，危机管理等多个方面介绍了一名二线经理相对于一线经理所面临的进一步的挑战。
|
|
|
|
|
|
从今天开始，我们进入课程的最后一个模块：技术决策，这个模块是我特意放在最后的，而且我认为正是因为有了这个技术决策模块，才能体现技术管理和一般管理的区别。这个模块，我设计了3讲，今天就先来带你讨论：启动一个项目时，技术管理者都应该做什么，才能让团队的效率最高？
|
|
|
|
|
|
为什么要讨论这个话题？我先给你举个很简单的例子。
|
|
|
|
|
|
有这么一个部门，当前最大的痛点是开发效率不高，而开发效率不高的原因是测试困难，测试困难最大的问题是因为缺少高质量的测试数据。如果你是部门领导，你会怎么做呢？
|
|
|
|
|
|
如果你做出的决策没有从“高质量的测试数据”这个关键事项入手，很可能就走偏了。比如我们把大量的研发力量投入构建新一代的基于容器的持续交付CD pipeline（持续交付流水线） ，你就算构建的这条流水线很先进了，但无法提高测试数据质量，也就无法提高开发效率。
|
|
|
|
|
|
而且因为要做新的CD pipeline， 要投入了大量的人手，这些人手本来可以去做更有意义的事情，这么一算，因为这个决策，团队效益还可能是负的。
|
|
|
|
|
|
你看，一个部门具体做什么本质上是由这个部门的一把手决定的。我们课程前面讲的所有管理技巧，如果没有这里说的做正确的事情，那就都是浮云。
|
|
|
|
|
|
好了，说到这里，做一个正确决策的意义和价值，我想就不用再强调了。那接下来我们最关心的问题就是，到底怎么才能做到呢？接下来，我就带你一步一步来找到答案，这第一步就是定义好问题。
|
|
|
|
|
|
## 定义好问题
|
|
|
|
|
|
有一句话叫做“优秀的人眼中都是活”，这句话说得有道理，不过，放到我们现在说的战略决策场景下，这样是不够的。
|
|
|
|
|
|
在实际工作中，不会像文章里我一开始给你举的例子那样，痛点和难点都那么清晰。你通常会看到很多的点，但是作为经理，你不能眼里全是点，你需要更进一步，尽快找到那个“打蛇打七寸的点”。因为你要带着团队在这个点上长时间投入，这是关于你整个团队接下来几年发展的点。
|
|
|
|
|
|
我们还是结合具体的例子来看。以我们部门的PaaS团队来说，团队遇到很多挑战：
|
|
|
|
|
|
1.我们整个技术栈正在往Kubernetes转，目前是当前系统和新系统双线作战，我们是不是应该把现有系统彻底淘汰？
|
|
|
|
|
|
2.我们虽然迁移到新技术栈，但有一些顽固问题长期无法得到解决，比如IP分配冲突，实现自动且无风险的删除操作（删除一直是高危操作，因为删除造成业务影响被开除的员工在我记忆中有好几位了），以及淘汰不再使用的线上应用。
|
|
|
|
|
|
3.公司正在往流量管理设备软件化、分布式化演进，PaaS的团队成员要不要加入这个方向呢？比如Istio或者Envoy。公司因为做支付对基础架构安全性要求越来越高，PaaS团队要不要去做基础架构安全方向？
|
|
|
|
|
|
这是几个比较典型的挑战事项，其实我还可以列出很多。那问题来了，我们现在不是选择太少，而是选择太多，那我们应该按照什么样的原则来做决定呢？PaaS的经理曾经让我在以下**三个因素**中做排序：
|
|
|
|
|
|
1.能不能产生业务价值，注意有些能产生业务价值的事情并不需要很强的技术支撑，比如系统集成和客户服务质量。
|
|
|
|
|
|
2.技术实施有深度，员工做了这个项目自身市场竞争力提高显著。
|
|
|
|
|
|
3.解决问题的范围可控，对外依赖少。
|
|
|
|
|
|
我最后的排序是1 > 3 > 2，PaaS的经理说他也是这个排序。那接下来我就按照这个顺序，从业务价值、范围可控到技术深度，带你逐一剖析。
|
|
|
|
|
|
不过这里我需要强调一点，**如果你没有办法把现在手头的日常工作的效率提高从而空出人手，那就先别去想新东西了。**也就是上面PaaS团队的3个挑战，在淘汰老系统和解决固有问题完成之前，做新东西这个决策根本实施不了。
|
|
|
|
|
|
### 业务价值
|
|
|
|
|
|
我们先来看有没有业务价值。可以说，凡是启动新的项目，大家都会说自己是为了业务。我想说的是：**有没有业务价值不是你说了算，而是你的客户说了算。**可是又有人说，不可以用户说了算，“用户很多时候不知道他们要什么”，你看乔布斯都这么说。
|
|
|
|
|
|
可是我们毕竟不是乔布斯，如果一个人想要就业务价值发表看法，我通常会先思考下面这两个问题：
|
|
|
|
|
|
* 说这句话的人到底花了多少精力跟客户在一起？
|
|
|
* 说这句话的人之前是否有过让客户惊艳的经历？
|
|
|
|
|
|
如果两个问题的答案都是否，那还不如踏踏实实地先去解决几个我们明确知道的客户痛点，再发表高论。
|
|
|
|
|
|
回到前面PaaS团队的问题，我们来对比一下下面对于业务价值不同的表述：
|
|
|
|
|
|
|
|
|
|
|
|
通过对比，你有没有发现两种表述的不同呢？
|
|
|
|
|
|
表述1更多的是在说技术实现或者陈述一个任务，而表述2才是真正的从价值层面来阐述为什么我们要做一个投资。
|
|
|
|
|
|
我举个很现实的例子做解释，测试环境稳定性的问题，如果按照业务表述1大家的关注点就是那100%的迁移指标，但是业务表述2强调的才是真正的测试环境可靠性问题。
|
|
|
|
|
|
事实上也是这样的，这件事我们就是因为没有强调真正的业务指标，后来导致一大堆客户抱怨，甚至投诉到了CTO那里。而IP分配的顽固问题是我现在向团队反复强调的点，不要在我面前再反复说我们要用新的IPAM替换RAS，请明确我们的问题解决方案，迁移只是方法，彻底杜绝IP冲突问题才是目的。
|
|
|
|
|
|
### 范围可控
|
|
|
|
|
|
定义好了我们的目标，也就是确定了业务价值，我们来讨论问题范围。你是在公司做事，**需要按阶段交付业务价值。**你的交付时间拖得越长，别人对你期待越高，失败风险越大。
|
|
|
|
|
|
以PaaS团队IP网段的问题来说，最初分配其实是网络部门管理，而网络部门并不隶属云计算部门，如果我要PaaS团队解决这个问题，必须评估网络部门的配合程度，最好网络部门有专人负责并绑定他的年度业绩。
|
|
|
|
|
|
我给你总结一下“问题范围可控”的注意点：你把解决问题的依赖全部列出来，然后对每一个依赖评估重要程度和你对这个依赖的控制力有多强。对于关乎你成败的重要依赖，如果你的控制力不够，要么你能够得到领导的足够支持搞定这个依赖，要么你能够重新审视你的技术决策，看看能不能去除这个依赖。如果都搞不定，请问问自己，这个问题是不是应该你来解决?
|
|
|
|
|
|
|
|
|
|
|
|
### 技术深度
|
|
|
|
|
|
最后来说技术实施深度的问题。虽然在定义问题的考虑因素时我把它排最后一位，但这却是我在技术决策中最棘手的一个问题。
|
|
|
|
|
|
为什么这么说呢?因为事情都是人做的，团队成员除了交付业务价值外，还会关心自己的市场竞争力。如果实施的技术深度不够，也就是说不足以让成员感受到他自身的实力会因此提升，那他的积极性是不高的。
|
|
|
|
|
|
还有一个很现实的问题摆在眼前，如果不是奔着市面上很火的技术方向走，你很难招到高质量的人才。相信我，我也曾给自己打气说“真正优秀的人才，才不看技术栈，哪种技术只要做到极致都是高手。”但现实让我不得不重新审视这个问题。比如虽然我很想给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，而不是一上来就要做一个又大又全的新方案。
|
|
|
|
|
|
其实关于技术深度这个问题，我是层层深入和筛选关键点的。首先框住为业务服务这个大框架，然后第二层着眼解决现在的难点，接着第三层是选择符合趋势的技术，最后第四层是选择实现的路径。
|
|
|
|
|
|
|
|
|
|
|
|
好了，到这里，定义好问题的三个核心要素我们就讲完了，也就是业务价值、范围可控、技术深度。
|
|
|
|
|
|
公司都是很珍惜能够解决问题的人才的，**但是其实能够发现好的问题的人才更可贵。**这需要你首先有这个心，然后出这个力，还要长期坚持，因为定义问题是一个从模糊逐渐清晰的过程。
|
|
|
|
|
|
目前我们部门副总已经明确了安全方向，但是具体哪个部门做什么还没有很清晰的界定，在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年。
|
|
|
|
|
|
我自己复盘的收获是：当你看到一个比较火的开源系统已经是比较晚了，往前推是业界前沿的技术公司发表的文章（哪怕不是开源的），再往前推是对应领域顶级会议上的论文。
|
|
|
|
|
|
你看，这其实就是**了解技术趋势的时间线：领域内顶级会议论文-业界前沿技术公司文章-开源项目。**你越早能把握这个趋势，你就有越多的时间来准备你要发起的项目。
|
|
|
|
|
|
## 总结
|
|
|
|
|
|
最后，我们来总结下这节课的内容。技术决策的正确与否、质量高低决定执行效率，方向错了什么都是空的，不单影响业务，还会影响团队成员的成长。
|
|
|
|
|
|
今天我们一起梳理了技术决策的准备过程怎么做，首先你要学会怎么定义一个问题，从业务价值高低，解决问题的范围可控和技术深度三个层面来考量，权重依次降低。
|
|
|
|
|
|
技术决策很依赖领域内专家，作为经理我们要去找到这样的人，让他给你提供信息。有时候我觉得我们找专家的劲头，要跟做销售差不多，要动用一切的人脉去找。
|
|
|
|
|
|
接下来，秉承我一直坚持的人和事并行的思路，人一定要理顺，特别是公司里那些意见领袖，你不把他们拉进你的队伍，他们就有可能成为阻力。而且让他们参与进来，还能给你一些技术决策参考，何乐而不为呢？
|
|
|
|
|
|
最后，作为一个技术经理，把握技术趋势会极大帮助你做出有前瞻性的决策，这也是我们的一门必修课。
|
|
|
|
|
|
## 思考题
|
|
|
|
|
|
你能分享一个自己经历的新项目启动的例子吗？你能同时复盘一下，从这个项目启动之前的准备工作中学到的思路吗？
|
|
|
|
|
|
欢迎在留言区晒出你的经历和疑问。如果觉得有所收获，也欢迎把这篇文章分享给你的朋友。
|
|
|
|