菡萏如佳人这一小节主要讲一讲技术管理者的大局观。
弱水三千，只取一瓢
这是一个最好的时代，我们学习技术有着太多的资料和渠道；这也是一个最坏的时代，技术多的让人眼花缭乱，不知从何学起，又走向何方。
我们瞧一瞧：开发语言很多，设计方法很多，开发方式很多，开源架构也很多。作为一个技术负责人，我们应该如何去选择？
我的心得是：最快最多最合适，优先级从高到底。
最快：在新技术和旧技术之间要能权衡，根据团队的技术能力分布，选择合适的技术选型，哪怕明知道不是最合适的，但是再初期是最快速的，能保证产品的快速开发和稳定开发才是首要任务。
最多：最快是受制于最多因素的，有时候A语言的开发效率是最快，但是团队里掌握A语言的人却不多，那么你应该选择团队里掌握的最普遍的哪门开发语言进行开发。
最合适：满足了最快和最多，再考虑最合适。最合适是指该项选型技术是最合适某个领域模型的。最好的当然是满足三个最，但往往就像CAP原则一样，我们很多时候只能满足其中二项。
当然技术架构在后续的迭代中会随着新员工的加入和老员工的成长，团队的技术能力分布会有一定的变化，CTO也要学会巧妙引导团队的技术成长方向和培养梯队人才，逐步向更好的技术选型迁移，不要一蹴而就，始终要以保证产品和业务目标为首要位置
知己知彼
技术到底还是为商业世界服务的，商业价值一般是通过产品服务为媒介来实现的。每一家公司都存在着现存的竞争对手和潜在的竞争对手。那么如何做到知己知彼，如何平衡好技术在行业中的水平与投入呢？
- 技术上至少高于平均水平
一个公司的技术部门作用在一开始往往被高估，而长期又会被低估
- 寻找弯道超车的机会
充分做好竞品公司产品技术了解与发展动向，不能让公司技术能力低于行业平均水平，但也没有必要花费巨大的代价来持续维持技术上先进水平，找到关键弯道超车即可，要知道如果不是黑科技公司，不是有特别先进专利技术公司，技术领先时间非常之短（除非像国外的从科研到研发需要大量资金和6-10年时间产品，否则一般技术领先期只有3-6个月）
- 留意与产品密切相关的技术
要充分了解公司产品在市场上的反应，在开发阶段预留一定的可扩展性或提前为产品优化，新功能的开发做好解决方案技术调研，新技术培养学习
- 降维攻击与OTT策略
不仅仅在产品和商业模式上需要思考降维攻击和OTT策略，技术上也是一样。行业中的典型代表就有：移动通讯与微信，谷歌的免费邮箱GMail。随着目前的发展大数据+AI+区块链都有可能形成OTT或降维攻击
谁是1谁是0
我们接下来再谈谈技术和产品，背后是程序猿与产品狗这对宿敌。到底是产品重要还是技术重要？短期上可能不分伯仲，但我们今天把视野拉长来看看。
技术：技术是高价值、高风险却不易独占的一种资源很重要，但不能隔山打牛。
产品：是高价值、低风险、高收益性的起引导作用。
这样去分析，高下立判了。注意这里并不是说产品狗比程序猿重要。在硅谷的很多企业，都没有产品经理这个职位，为什么？因为很多的程序猿他们也具备很好的产品思维，说实话比大多数的产品经理更懂产品。
那么结合我们的标题，产品和技术谁是0谁是1，就像身体与财富一样，身体是1.财富是0。产品是1，技术是0，技术可替代性太强
天下第一的技术水平假设是1的话，那天下第二的技术水平可能就是0.98，天下第三是0.97，天下第四是0.96，天下第五是0.95。差距不大。比如Java不行我上.Net，再不行上PHP，还不行？后面还有很多语言在排队呢~
那搞业务的，第一和第二的差别就大了。第二和第三的差别也大。
贝尔实验室，Borland，再是Sun，一个一个的消失了，这就是把技术重于业务的一个后果。IBM也差一点消失。
Google初期赖以成功的Page Rank算什么技术啊，恰逢其盛而已。微软其实也不算，Windows之所以能成功是因为Windows够烂而不是够好，因为够烂，所以能快速推出，等那些追求技术完美的公司搞出来了，地盘已经被微软抢走了!
及时还债
江湖上有句话：出来混，迟早是要还的。
做技术的其实也一样，欠下的债也是迟早要还的，不要等着债主上门来讨债，要自己及时去还才是。
产生技术债无外乎两个方面：能力与技术
能力原因：
- 有缺陷的设计和代码
- 技术能力薄弱
- 纯人工测试甚至没有测试
- 技术选型未跟上发展潮流，坑多填不动
...
时间原因：
- 一开始因为时间紧，临时方案凑合着使用，没人再关注优化
- 不会做优化改进，只会做美其名曰的MVP（最小可实现产品）
- 开发流程缺乏必要的基本文档与规范
- 写代码如贴膏药，无注释
...
那我们怎么去及时还债呢？我这边提供了三个解决方法：
- 前人挖坑后人填
前人挖坑，后人填坑，碰上了别说倒霉，很多人也是在解决前人留下的债务危机中迅速成长起来的。要保持填坑的平常心。
- 快刀斩乱麻
一般来说，就事论事解决就好，如果积累太多，千头万绪一团乱麻，那就快刀一斩，推倒重来，重构。重构看起来像是东山再起，没有在原系统上修修补补，但确实是偿还了债务的，不过还可能引入新的债务!但随着重构技能的熟练，整体上还是向好的。
- 未雨绸缪
适时调配资源，持续性解决债务危机，避免债务危机失控。一个合格的技术管理者，要保持对技术债务的敏感度，更要适时的调配资源，解决部分技术债务，避免失控。但也不需要过于敏感，处处小心，防微杜渐，或者优柔寡断，有的时候不做决策一样是一种决策行为，会导致债务。
这里扩展讲下未雨绸缪法的几个做法：
1 不断完善开发流程规范
2 对项目和故障进行复盘及时发现问题
3 不同领域知识建立专家组来进行管理
4 建立完善监控系统，确定系统基线，关注系统运行趋势和异常
虽然说我们要避免技术债，及时还债，但是如果我们的业务发展的很好，随着系统扩展，技术债难免被不断引入，所以完全规避技术债肯定是不可能的。所以我们要学会和技术债共生。就像目前众病之王癌症一样，我们没有能治愈癌症的特效药或方案，但是我们可以用药物辅助，学会和癌症共生来延长个体生命。
这样来看，每个技术宅都会遇上技术债。总会有自己接手的第一笔债，还的第一笔债，欠下的第一笔债。于是开始与技术债相爱相杀的职业生涯，接下来面对更多的债。但不要陷入俗话说得好，虱子多了不痒，债多了不愁，债多不压身这样的心态。这样的心态不免过于良好，甚至有些不负责任了。
越大的系统，其中包含的技术债务越多，越高的技术管理者越要重视债务，规避“系统性风险”。
什么是系统性风险？08年的次贷危机，很多赫赫有名金融机构就翻了船，越大的系统，出现问题的代价越高，风险越需要重视。
存在即合理，技术债也有两面性，就如同房贷、车贷，给我们在某些方面的收益。
因此正视技术债，有意识的管理、使用好技术债，是技术管理者必备的技能，必经的修炼。
箴言小结
最后用一个扎西拉姆式诗歌体来结束本章节：
你见，或者不见
债就在那里
今生，今世
不弃，不离!
