这本书写到这里。剩下最大的问题，就是如何导入现在的工作环境了。
这也是卡住许多人最大的难关。要是 Remote 这么好导入，承平时期，世界上早就到处都是 Remote Team 了。
不会是因为疫情，大家没得选才会 Remote。
一般团队，之所以不会选择 Remote 作为团队第一选项，就是遇到这样的问题，Remote 造成的基本上是平常的协作模式全改变。身为老板与领导者，很难去估清流程一旦改变所造成的损失与影响。
即便，你可能在市面上听了很多人吹 Remote 是多么牛逼，带来的 150% 生产力爆增及解放。也还是不敢贸然尝试。
主要是真怕以下三点情形的方生：
- 掉生产力下降
- 原先顺畅运行的流程，结构被破坏而且无法 rollback
- 没有人带入门
那么，这本书看到这里。大家也学会了不少技巧，究竟要如何开始呢？
这里还分两种情况。
- 一是你原先目前是 inhouse 团队「想」改 Remote 团队（有得选）。
- 二是你原先目前是 inhouse 团队，「被迫」改 Remote 团队（没得选）。
不过。给的一致答案是。不管你是不是被迫换成 Remote 形式。都要先从原先流程效率最低的部分开始改造。
在组织里面导入新的流程，很像我们程序员以前在写代码的一道工序，「重构」。重构指的是绝大多数网站 App，都是蛮力盖起来的。里面结构七歪八扭，但求能动能收钱就行。但是这样的 App 业务成长到了一个关键节点，就无法再叠床架屋下去。必须要彻底改善内部结构，否则再添任何 feature，都可能使原有架构崩溃。
这时候，程序员团队有两个选择。一个是拆掉里面梁柱，原地改建。一个是另辟一块新地，画新设计图重新建造。
这对一般程序员都是个两难。二显然是最理想的，因为不用管那些恶心的代码，没有技术债。但是新的风险是如果选二，很有可能原App在二还没盖好之前就垮，而且凭空的新设计图，盖不出来，或者是盖出来后又产生许多复杂的新问题。
但是选一呢？又要面对那陀大便般程式码。有时候问题真是大到恨不得把整块代码都敲了重写。但是这样的问题在于敲了可能公司就完了。总不可能公司关著等代码重构完吧。
无论如何，公司老板都不会给你关门大吉，营业损失的重构选项。
这个问题看似难以解决。但那是对一般程序员来说而已。
对于架构师等级的程序员。它们是有一套清楚标准程序能够解决的。
以下我分享架构师级别通常会采用的重构步骤：
- STEP 1: 先测量效能数值，界定瓶颈
- STEP 2: 找出当前效能最大瓶颈区块，计画重构
- STEP 3: 确定该区块的正确输入以及正确输出为何。确保在改写过程中，输出始终不会坏掉
- STEP 4：如果发现还是太大快，就再切成数个小模块，从可以提升效能又改的动的模块开始。
同时这当中，不要害怕多次重写拼装。因为在这个过程，程序员可能要反覆重新调整流程几次。但是始终只要确保一个原则，不要影响到原有结果。
重构应该采取的策略是小步重构而不是扔掉重写。
最不好的重构姿势，是草率把代码直接扔掉重写。看似直接抛弃了技术债，但原先大陀的 workround 里面可能藏了以前许多运行良好的 workround。短期之内效率可能会提升，但是这个修改，却会引出过去老早就被解决的诸多问题，甚至综合起来，产生更多难以想像的灾难。
而这套原则。套到组织流程改成 remote，要如何比照办理？
组织里面可以先行召开一个大型的生产例会议。找出团队还没导入 remote 前，就觉得很慢的流程。
而且是平日就感觉 remote 与否，都会非常慢的流程。
比如说会议、比如说手稿传递修改。将所有耗时的区块都列出来。再排序看哪一个区块是最耗大家时间的。
找出这个技巧之后，设计对策。
看是使用会议技巧提升效率，或者是导入专业 Review 软件，加快协作速度。
「能够节省时间」对所有员工来说，不管改不改流程都是乐意的。只要是利远大于弊，即便可能用点新工具，大家还是能够忍受一些不习惯。
我推荐在流程改造期间，团队每周四开一个 AAR 检讨会。AAR 的全称是 After Action Review。
这个方法起源来自于美国陆军。一般在社会中，团队重复的犯错，不会导致任何死亡事件。但是在军队中，错误重复发生，可能会害死很多人。
所以美国陆军发明了这种 Review 方法然后利用每一场战役、演习后的 After Action Review 所产生的经验与教训，整理成册。编辑成各种教战指南与 SOP。提升部队的战力。防止了致命错误重复上演。
AAR 总共有一组三个问题：
- What was supposed to happen? What actually happened? Why were there differences?
- What worked? What didn't? Why?
- What would you do differently next time?
中文翻译：
- 描述状况： a. 原本预期应该的情况 b. 实际的情况 c. 分析a、b的不同点
- 分析根本原因： a. 在情况中，什么是有效的？ b. 什么是无效的？ c. 为什么有效/无效？
- 行动方针：下次可以怎么做得更好？
根据这个检讨会的结论，去修正组织流程：
当第一个模组模组就再改一个模组。
这里有一个小 Tips。如果你的团队要重构，千万要记得一个原则，一次不要改两个模组。这是重构时罪常犯的错误。有时候因为我们心急，一次就改了两个地方。结果造成了莫名其妙，想都想不到的 bug。找了老半天才发现意外引发了很希有的异常状况。
团队流程重构也是如此。尽量不要一次改太多流程。
而是一次专攻一个项目的效率提升。这样能有效比较重构前、重构后的效率。同事也较能够得到正反馈。
当然，因为 COVID-19 的关系，很多团队是被迫一夕之间，要改变所有流程。那也真的没办法。
但我建议读者可以采取折衷方法：一周全团队只环绕著一个改进方向。如本周围绕改善会议品质。
而不要同时要求文档写作方式，资安文件传递原则。
可以等会议品质要求完了，再转换题目。
一个礼拜只改善一个重点。以这样的进度，一般团队差不多 2-4 个礼拜之内。你的团队就可以开始享受到效率提升的美好战果了。
我将以上重构的循环「翻译」成白话文版，供各位读者进行：
- STEP 1: 开会统整，公司或小组内的生产力瓶颈。确立改善优先级
- STEP 2: 每一周只集中改善一个主题
- STEP 3: 将该周的主题。流程化。使用工具或撰写 SOP。
- STEP 4: 每周开检讨会。检讨当周在引入新工具、新流程后，效率是否有提升。
- STEP 5: 反覆循环此步骤。直到全公司主要的流程文件大致上都被补齐了。并能顺利产生各岗位的上手手册。