.. Kenneth Lee 版权所有 2020
:Authors: Kenneth Lee :Version: 1.0
后软件时代和技术沙盘陷阱
进度管理者喜欢技术沙盘，技术管理者不然，本文剖析一下技术沙盘会带来的战略陷阱。
首先我们理解一下什么是技术沙盘。比如你要做一个Web Server，这里涉及到多少技术？ 我们不严谨地简单列一下：
TCP/IP协议栈
http/https协议栈
ssl协议栈
XML库
文件管理
维护接口
Servlet
先这样，有些名字都已经旧了，但我们只是用来举例，暂时认为就是这些技术。只要搞定 这些技术，我们就初步掌握了Web Server的供应能力了，然后我们就可以在市场上占据一 席之地了。
把这些技术画成一个个框框，组织成一个软件栈的样子，掌握的技术就标成一种颜色，部 分掌握的标成一种颜色，已经掌握的又标成一种颜色，就叫一个“技术沙盘”了，比如这样 ：
.. figure:: _static/技术沙盘.jpg
一个技术沙盘的例子（当然，这个例子简单了，显得不够牛逼，其实本质上是一样的东 西）
管理者喜欢这个工具，这是一种天然的行为：我也不知道细节，但天下所有的事情，都是 一步一步这样做起来的，那么我们把这些事情分成很多个方面，然后分不同的人去把他们 搞定，这不是合情合理的吗？
而且这很能给人满足感，这有点像电影里的领袖人物：背着手站在地图面前，看着自己的 部队逐步占领一个个城池，然后整个地图从绿变红，然后就拥有整个江山了……
从做战略来说，凡是能让你爽的模型，往往就是有陷阱的。今天如果你这样做Web Server 的竞争，基本上你只会拖你技术团队的后腿。
因为现在是后软件时代，大部分软件部件已经存在了，不再是什么软件都要自己开发的时 代了。上面列的东西，基本上都是已经存在的。无论是通过开源存在，还是通过某些老公 司历史积累存在。反正你的竞争者都是站在大部分部件已经存在的位置上和你竞争的，大 家都是比怎么提升这些已有组件的性能或者水平、垂直整合部分部件来获得竞争优势的。 你还看着这幅图，想着把哪个部分染红染绿的——你的决策模型根本就是错的啊。如果你再 强势一点，通过这样的沙盘在那里指手画脚，那你对团队就只有副作用了。
这背后的本质，是软件的进步不在于如何增加代码，而在于怎么用好，和优化好这些代码 了。国内很多公司或者国家决策机构，还在简单想着“人有我也有”，然后用技术沙盘这些 简单的方法处理尖端的竞争问题，这才造就了那么多“用开源软件制造的国有软件或者核心 竞争力”，这些都是技术沙盘思维带来的陷阱。
抵抗这种陷阱的方法一般是以最终特性进行进度管理：我也不管你要做多少个模块，我要 的就是某个特性呈现给我，比如我要支持WebServer，要支持100万个用户同时访问，要支 持JS和Servlet通讯，要支持NoMySQL访问，要支持https接口等等。这样一步步向前走，就 能慢慢维持在阶段竞争的思路上了。
但很多管理者是很难接受这种管理方式的，因为首先这个东西很难算投资规模：你说做一 个支持100万用户的WebServer要多少人力和钱？要花多少时间？而且这种方法还不保证已 经达成的结果别人不会找别的手段反超，还要屡屡回头。他们会说：你看以前多好，我们 按有多少模块，多少Kloc来分配资源，这种问题根本就不存在——但这是典型的蠢人思维—— 我不在乎问题能否解决，我只在乎我是不是容易操作。所以丢了东西不应该去丢东西的地 方找，而应该去明亮的地方找。
另一方面，这种方法操作起来，其实还是很容易掉入前面的陷阱中的。比如，管理者系统 判断整体规模，然后事无巨细地把特性安排在一个5年计划中，然后他们就觉得松了一个口 气了：战略决策做完了，现在只要埋头干个五年，我们就成功了。
但很明显，你认为战略可以做得这么容易，你就已经失败了。战略是个要天天抬着头的事 情，根本不允许你简单看两眼，就觉得安全了的。
不但管理者容易陷入这种陷阱，就算你懂技术但对管理行为不熟悉一样会陷入这种陷阱。 比如你领导或者项目经理找你，说需要一个技术沙盘，或者一个详细的5年特性实现计划。 你知道这种方法不是你一般的做成一个产品的方法，但领导给你说了：“我只是参考一下， 我也不要求你准确，大概大家有个参考而已。”甚至他说的时候，他也是真心实意的，确实 是先对事情有个了解而已。
然后呢，也不能只信一个人是吧？这很合理，他去找另一个技术专家B，问“这个沙盘这样 定义行不行？”，那个专家呢，可能也隐隐觉得项目不是这样做的，但这时为了沟通的方便 ，这位领导就会他说，这个沙盘也不是我一个人的意见，这个沙盘是专家A（就是你）提供 的。B一想，A还是挺靠谱的，连A都这样说，可能是我偏颇了吧，好，然后这个沙盘就成了 你们的共识了。而且这种东西本身就特让人安心的——不看方向只埋头赶路这种事情从来都 挺让人安心的，反正大家都觉得自己有疑虑的东西别人已经考虑过了。就算最后失败了， 都挺让人安心的——反正也不能回头了，赶紧散伙找工作就好了。
你看，如果你不想动脑，很简单的陷阱就能让你找不着北，跳下去都跳得心甘情愿。
还有一个更容易掉进去的变体：比如有个管理者觉得他认可你前面说的观点了，但团队总 要分工对不对？那么我们总是要把工作分开，每人负责一份吧。我们先做一个分工总是对 的吧？
错！
因为在构架设计阶段，如何分工才是整个工作量的核心。你认为分工是第一位的，是因为“ 你看不上分工这个工作”，但如何分工，恰恰是架构设计本身。你可能说，做一个Web Server，总要支持反向代理，虚拟主机吧。好，你现在分工了，有人负责反向代理，但你 一分析，发现这个反向代理其实不重要（在没有分析前你根本不知道，因为项目初期你不 可能什么都知道），你现在让负责反向代理的团队停下来？你算不算他们的战功？
那你说，那我们建立一个很长的架构分析阶段，先把这些东西都分析清楚了再开始分工。 但这恰恰掉进了后软件时代的陷阱：这为了定义一个合理的计划，把项目本身的时间给浪 费了。
没有开发经验的人这样理解一下吧：你要穿过一个山区，你没有去过，但你心里是有底知 道山里是有条路的。照理说，你只要进去走，保证方向，最多折回一两次你就可以走过去 的。但你为了“管理方便”，“程序正义”，结果你派出大量的先头部队，让他们把这座山方 方面面都调查一遍，然后给出一个“过山路径”，你以为你是皇帝出巡吗？这个成本可能被 穿过这座山的成本还高几十倍。
所以，非要这种程序正义的人，最终的结果其实是两头都搞不好，要不强行浪费时间，要 不强行定义不存在的限制，最终都是失败。
而现代开发都是怎么做的呢？比如你要让LLVM支持一款新的处理器，LLVM的代码量是5百万 行左右，每个独立模块都是某个领域长期研究投入才能搞定的，你不可能都懂，你最多就 是先搞一个后端，适配你的处理器，然后你看到你的向量处理unrolling无论怎么适配都没 法让你的处理器发挥优势，你才决定要优化一下中端的IR的生成，在里面加上一个语义信 息，弄完这个，然后你还发现你的内存管理在不同情况要做不同处理，这样需要在定义变 量的时候增加几个保留字，你又修改一下前端……在整个开发前，其实你根本不会知道你一 定会改什么，你都是严肃做完一步，看看情况，然后跳下一步，你延伸出去，也不是你搞 定了中端，前端的全部原理，只是搞懂和你相关的部分的算法而已。你非要提前知道这个 计划，你就不可能走过去。
隋炀帝三征高丽怎么失败的还记得吧？一大教训就是部队必须坚决执行皇帝的既定计划啊 。