本书开门见，第一个主题，谈的就是沟通。
为什么开头，我就选择这个主题作为开场。
原因是这样的，在写这本书之前，我在线上举办了一个很小的讲座，帮大家解决问题。当时，我请参加的人填了一份问卷。询问它们在 Working Remotely 时，遇到什么痛点。
接近 90% 的人。不约而同都选了「沟通」问题。
的确，对于一般普通的工作者来说，转换到「Working Remotely」型态之后，遇到的最大难题，就是沟通。
因为一瞬间，在办公室集中工作的好处，全部都消失了。原先你要一个答案，只要走到同事旁边，瞬间就能够得到回答。
现在，在家工作，即便有聊天软件。可能等上老半天，还等不到回音。而且，就算对方回应了，双方沟通效率也很低。一方面是打字效率比起说话很低。一方面是面对面沟通，能够传达的信息与辅助媒介，实在远比文字丰富的太多。
但是，你又不能紧迫盯人的一有问题，打电话给你的协作者，这样反而更耽误双方的工作效率。
所以，这个问题实在是大家心中的痛。
在远程协作里。我推荐大家使用一个原则：「一天限制自己最多只能与同事通话两次」。
围绕著这个原则为核心，去设计与同事的沟通策略。
（更精确的说，就是上午一次、下午一次。）
一般工作者，对于 Remote 环境工作感到焦虑的最大主因。在于工作模式彻底改变了。比如说，从头转头一下就能得到解答的答案，非得「等一下」才能得到答案。更甚而，而绝大多数的人甚至是「没有拿到」这个答案，不能往前推进下一步。
一环扣一环之下，效率与效果都会得到打击。
这也是绝大多数人，认为「沟通」应该是「远程协作」时，最需要先被解决的问题之一。
这个问题，也许很多人在职场上没有思考过这个问题。那便是：
「你真的需要马上得到答案吗？」
特别是因为这种时空背景下。你「想」，但是「得不到」。却是铁一般的现实。
那么我们要如何对应这样的情况。
有三个方向可以思考。如果你想要问同事问题，可以先思考以下这三个问题：
- 自己想要得到什麼答案？
- 這件事需要馬上得到答案嗎？
- 公司 Wiki 上找得到答案嗎？
我一直认为。在工作上。如果需要频繁与对方沟通，才能办成事，才能得到想要的效果，工作上一定有什么地方出了错。
比如说，在职场上。这种状况应该不陌生。诸如：
- 「在吗？」
- 「你有没有什么方向？」
- 「你觉得黄色好吗？」
- 「你觉得老板想要什么？」
这类有点令人讨厌的问题。
这类问题的共通特点。就是有点令人讨厌。但又说不上来的觉得没必要大惊小怪。
但是。如果你试著将这些问句，放到远程里。你会突然发现，超讨厌人家问这种问题，浪费时间。
为什么会有这样的效应呢？
这些问题都有个共通特点。每当这些问题出现前，你总需要再多问好几句，才能最终搞明白对方要什么？
办公室里很常出现，但大家不太在意，主要原因是以前这类问题，多问几句的成本只要几秒钟。但现在这些问具的成本就是几十分钟。让人不由自主的无名火起。
这些问句的成因有可能是问问题时，没想清楚。还有一种情况时，问这些问题的人，平常就有不好的工作习惯，习惯将「思考作业」扔给对方。平常没感觉，一切到远程工作模式，就觉得跟这人常让人无名火起，与他工作十分费劲。
无论如何。这些问题的产生，有可能无意，有可能有意。但是最重要的是，我们要如何改变「结果」？
这个问题的解法是
- 思考问对方问题时，你想要得到什么答案？
- 尽量将选项集中到你想要的结果
- 将一个「开放问题」，改造成有限的多选题
比如说我上面举的些无脑例子，可以改造成这样：
- 「在吗？」=> 「在吗？我想跟你沟通 A 项目的事。我在 15 分钟里面都在线。如果你在的话尽快回我。如果等下要找我，我可能整点时候才在，到时候可以打我电话 XXXXXX。」
- 「你有没有什么方向？」=> 「关于目前这个问题，我目前有 A 方向、B 方向、C 方向，我个人比较偏好 A 方向。你有没有其他思路？」
- 「你觉得黄色好吗？」=> 「关于这张海报，我做了红橙黄绿色，我个人觉得黄色在这个场景比较适合，理由是 XXXX。你比较偏好哪一款。选个两组给我。」
- 「你觉得老板想要什么？」=> 「我认为老板因为 AA,BB,CC 因素。他可能比较偏好 CC 选项。你有什么的看法？可以给我你的方案与理由吗？」
我们可以再进一步，观察这些「问题的重构」具备什么样的特征：
- 都很长
- 一次性的表达了自己相对完整的看法
- 如果对方没有什么想法，让他选择容易
- 缩小双方讨论的开放性与时长
- 更容易得到结果。时间可控，结果可控
我们平常在办公室沟通协作时，因为讲话成本很低。于是你很难察觉到跟某些人沟通，就是特别的费劲。或者是某些会，开来就是特别的烧脑与无效率。
其实就是这种「思考作业」落在哪一方的问题。
在远程协作上。
为什么开篇第一个原则，就是「限制自己一天最多只能跟同事语音沟通两次」。
其实是因为如果说话机会这么珍贵。就能促使自己更深入的思考，自己要问什么样的问题，又期待得到什么样的结果。
现代人都很急躁。眼前遇到问题，就马上想得到答案。但是，其实所有事情，都得马上需要答案吗？
或者是，非得要得到答案，你才能接下去做目前手头的事吗？
这是在远程沟通发问时，我认为工作者需要去思考的第二个问题。「這件事需要馬上得到答案嗎？」
你会发现，在绝大多数的情形，其实并不需要。
很有可能，你只是期限内需要得到答案。可能今天下班之前、或者是两天之内。
- 1) 这种状况。你只需要透过聊天软件，或者是专案管理软件。通知协作者在 by 某某时限前，必须缴交结果。
- 2) 如果怕对方忘记。你可以过一阵时间提醒他。或者是在缴交期限提醒他。
- 3) 如果对方真不交。那么有可能是他做不出来。甚至可以事先声明，答不出来有问题，可以个别沟通协助。
那么，你更可以顺利的在你想要的时间之内得到答案。没必要「中断对方」硬是要得到答案。
(P.S. 如果真的很紧急。大家都能接受利用手机硬是找人。只是尺度真的必须拿捏)
有时后。我们觉得无法继续完成工作。其实只是不懂得工作拆分而已。也许卡住的坑洞只是件小事。只是以我们的顺向思维。觉得不顺手追下去可能会档到自己。但是其实换个工作顺序，这件事就不再是个档路石。
解法一：先造暂时性答案
我举个公司内设计海报的例子。在设计海报时，有些设计师，他的惯例是非得 PM 先决定主色，才能开展设计。当然，选定主颜色，在做出主视觉，是非常重要的一步。否则后续改变设计，有可能造成大量返工（修改、大量重做）。
所以设计师倾向追著 PM 在初期就定稿。等到答案再开展设计。
但是，在远程工作里。返工与沟通的成本，有可能是反过来的。
在远程工作中，最大的成本，就是沟通中的「等待」。有时候等待的时间，反而都够你把原先的事情全部都做完了。
因此与众人常识可能截然相反的，在远程工作里面，甚至可比较好的技巧是，自己先做出多种可能方案。把原本「中间缺的那一块需要得到的回答」自己先暂时补起来，顺利把原先流程跑完，再重新修改「暂时区」。
以海报来说。与其等人家决定颜色。在远程工作中，比较好的方式，可以是可以先著手设计一个万用版型，而这个版型至少可以搭几个颜色。这样设计师就不需要等 PM 决定你用什么颜色，才能进行设计。
同时在发稿修改时，一次出大量版本提供选择（我要 1 与 6 merge 起来，同时右上角的设计删掉）。这样双方就可以更快的达到一致的结果。
我认为远程工作与在办公室工作，提升效率最大的原则技巧，分歧点在于：在远程工作时，提高效率的重点 在于「自己反而多花一点时间，猜测一些可能选项，甚至先帮对方做一些的工作」。这种看似比较耗成本的事，反而才能提升双方效率。
因为在远程工作时，「等待」是最大的浪费。如果你想要最快得到答案。最快的方式，是自己先造答案。
解法二：非同步作业，指定对方在时间截止之内给你答案
有的时候，我们还是需要对方明确给我们建议。但是这一类不需要马上，或不可能马上得到的回覆。
你可以使用「截止时间」这个概念，留言让对方在你希望的指定时间之前回覆。这样，双方的注意力都不会被占用。
他不需要马上处理，可以等一下处理。你也不需要时时刻刻在现上等著他回覆。
一般来说。远程工作者大概都是 30-60 分钟之内。会固定的回公司聊天频道看有没有人找自己。所以，你也不会太晚拿到你需要的结果。如果好解决，基本上都能在 1-2 小时内得到答案。
除非这个答案没拿到，真的会让你火烧屁股，或者是这个请求需要你额外说明。那么这样的 case 我才建议你直接打过去沟通，而且是得马上打过去沟通。
绝大多数中小型公司。可能因为各种因素（如技术能力、创始人经验），公司没有建置内部知识库。
但是，如果在远程工作中，我认为建置一个内部知识库（如 wiki），是绝对必要的。甚至不是远程工作的团队。我都认为强烈需要导入。
为什么呢？
有几个重要原因：
- 许多工作中，很多同事日常要问的问题，多数都属于「共同问题」。比如说如何请假、公司编号、网路如何配置。这一类问题其实可以自助，不需要占住大家宝贵的交流时间。
- 有一些工作流程内容，属于某些工作组的日常流程。这些不成文工作流程与默契，是新来的同事不易 get 到的，甚至一对一贴身工作都要学很久。但是如果放在公共知识库，就可以大幅度降低新员工的学习曲线。
- 减轻关键员工工作 Loading。有些知识，是特定员工才会的。这些知识说说不重要也重要，说重要也不重要。关件是该员工如果请假，会搞的大家很头疼。因为只能问他才能解决。逼得在办公室的人与请假的人都很头大。
- 留存公司知识。同时，最大的宝藏就是员工工作时共同的经验与知识沉淀。要是这些工作经验知识没有在员工在职留下来时，每一个员工离职，公司都要花上钜额的金额与时间才能填补。但反之，一个团队若有知识库，那么公司的无形资产与实力壁垒会越来越厚，甚至产生后劲非常强的效率正循环。
我们在平时，因为转头就能够拿到这些资讯。所以并不会觉得写起来多重要。只会在同事请假、或者是离职时，才会觉得大量不便。
所以当在办公室时，往往下意识觉得没有必要写文件。甚至不会感受到有知识库的好处。
但是在远程时，因为一天之内，沟通的管道与次数严重被限缩，「常识库」的重要就会被突显出来。甚至你会发现，一天当中产生的 50% 问题，其实都是这些「不成文」常识。
所以你该这么做，开始请团队将以下资讯开始建置成知识库：
- 流程文件
- 人员手册
- 一周里面大家会互相问三次以上的各种问题
- 某些人请假就会严重被中断的流程
上面我们解决了「问问题」的问题。有时候我们去找同事沟通。并不是想问题，而是想要委托他帮我们办一件事。
在远程协作里。一个更关键的技巧是：避免使用命令语句。可以的话，尽量加上「原始场景」以及「决策上下文」。
举个例来说。如果我跟同事身处在办公室。这句话当时可能没问题：「我要做个活动，你可不可以帮我合个微信用的海报？」
但是在远程工作里，可能是很不好的句式。
我们在办公室时，因为场域使然，因为大家都聚在一起。原本这一句没什么问题，是因为因为办公室信息量庞大，设计师可能当下就心领神会这张海报是抽奖需要的海报。需要在视觉上凸显「奖」这个元素。
但是当在远程工作时，「空气」就消失了。设计师难以意识到这张海报的原始用意是什么。所以只能按照他的直观与直觉作。等到你拿到结果，才跟他说方向作错了，我们要凸显「抽奖」的元素。
这时候要退回去做，可能还需要一天的时间。
所以换到远程工作时，正确委托他人的姿势，是要不厌其烦的在「命令句」下，加上「原始场景」「你的决策理由」。比如这样说：
「我们因为在 event 里面提高活动参与率，我的想法是在活动时也提供抽奖。所以是否可以帮我做张海报，里面强调参加能抽奖，以提高活动参加率」。
在请求句式前面加上原始动机以及决策场景的好处，是对方能够更理解你的意图，能够更做出贴近你需要的决策产品。
这样沟通的好处是，对方搞不好理解意图后，能顺势贡献出更省时的另一个建议或者是结果。
比如说在这个例子之下，他可能就会反口说「是不是跟我们过去作的那一档 XXX event 一样，如果是的话，我一小时就能改给你」。
如此一来，原本你预计要 4 小时才能拿到第一版结果。这下，可能 1 小时就拿到可以上战场的成果。
我们谈完基本的「send request」技巧。接下来我们要谈「respond」技巧。
respond 技巧有两个方向
这是我长年养成的工作习惯。每交出自己的工作，必另附上使用说明以及 FAQ。
你会觉得，这也太麻烦了吧。真的要事事都这样干吗？
是的。真是要这样干。其实不只我，这一条工作习惯甚至是我们公司的「工作内规」，甚至写进流程里面。
这一张截图是我们公司内部提交 Github Pull Request 图。Pull Request 是技术人员提交代码的一种方式。我们内部有订制的模版。
我来为大家解说一下。
- 第一段 Redmine Issue Link。Redmine 是我们公司的项目管理系统，所以这一段的意思是他是根据这一张 Ticket（专案管理系统上的管理事项最小单位），去实做这个功能的。
- 第二段 Changes。是这段代码，改变了什么值得注意的原有的截构。
- 第三段 Screenshots。如果这段代码，牵扯到画面大幅改动，或者是新引入了设计，那么我们应该会看到什么。
- 第四段 Notes。注意事项。如果这张票，程序员内心若有任何不妥，内心想要提醒其他人的部分。应该写在这里。通常，我会将 Pull Request 的，如何使用的操作指南也写在这里。因为，我们在写代码时，有时候背后设计逻辑，或者是操作步骤，只有我们自己知道而已。而别人需要负责审批我的代码。因此负责任的程序员不应该让同事产生困惑，直接掉坑。需要主动介绍说明自己代码背后的意图，以及如何操作、如何重现使用步骤。
- 第四段 Risks。这段代码，会有什么隐藏的风险吗？
- 因为当程序员提交代码后，这一段代码基本上在公司流程里面，大概两小时就会被他的上级或同事审批，甚至过审部署。有时候我们只是先做了一半，拉了 Pull Request，只是为了要跟隔壁的更好协作。不希望马上进审。这时候我们就会在 Pull Request 标题标上 WIP。Risks 上面写上半成品。让路过同事连点都不要点。
- 有些代码因为涉及到架构大变更，在正式上线时需要独立大量测试，并非只是单纯需要别人给评语。这一类的票会强制需要在 Risks 上注解这件事，以利最后负责部署的 Release Manager 安排人手测试。
- 而有些代码涉及到数据库结构改变（新增栏位、或者删除栏位），或者改写大量数据，这也可能为系统引入风险，必需要在 Risks 特别提出，以利 Release Manager 手动操作（甚至部署前打数据库备份）。
- 总之在这个栏位里面，如果你认为这会有重大影响，必需要在此栏位写明。
这一段工序在开发团队里面，属于强制性流程。
亦即，如果你提交代码的内容不足够让 Reviewer 满意的话，其他人有权拒绝审批你的代码。而如果你平日习惯不好让同事频繁掉坑（比如说大量浪费代码阅读时间、引入重大结构改变却不事先说明，不知道如何操作。。。。）等，是会被举报直接上协作黑名单，甚至被安排离开团队。
而我本人更是有一个好的习惯。亦即我会在 Hand over 我的工作时，会额外制作 FAQ 提交给下一手开发人员。更甚者，如果这段架构制作复杂，我甚至会在当天结束之时或者该周结束之后，主动写一篇开发教程，提交到公司 Wiki。
为什么呢？因为如果其他人有这样的需求，就可以「不需要再来问我」。
一个人来问我花10分钟。感觉没什么。但是如果是 5 个人呢？那就是 50 分钟。何况，有时候光口说，有时候更难讲清楚。所以，我总会主动自己先写 FAQ 或者是文件。节省大家发问的次数。
过去读者可能会疑惑，我哪来那么强大的文件写作能力。似乎万物我都能写教程。其实就是这种长年工作习惯培养出来的。我从不嫌麻烦，因为这原本就是我工作的一部份。
接下来，读者可能会疑惑。既然要写 FAQ。那 FAQ 到底要写什么？写到多细。这里我提供各位一个参考模版。是我在 Growth Hack 这门学问里面提炼的模版，叫做 Onboarding。
Onboarding 一词原是指 HR 领域，新人入职的一个流程。后来在 Growth Hack 界被用来指称用户第一次使用者产品的激活流程。
Onboarding 在这两个领域之所以重要。是因为如果在这两段流程里面，没有做好对于候选人与客户的服务，本来好不容易争取它们入职以及购买意愿，可能一个卡壳卡坑，。它们瞬间就会转头离开
但问题来了。我们怎么知道它们会遇到什么问题，以及知道要怎么解决它们的问题办法。我们又不是神仙，不懂「通灵」。
事实上，还真有这种通灵框架。我发明的 Onboarding Checklist 总共有 8 个问题：
- 在开始前，用户会问你什么问题？
- 在第一次使用前，用户会忘记做什么会让使用者体验搞砸（最常客诉的点）
- 用户最常做了什么「正确的事」达到很好的体验？
- 用户最常做了什么「错误的事」结果收到很糟的体验？
- 东西售出后，你如何检验它们做了「正确的事」或者是「错误的事」？
- 顾客如何联络你修正问题？
- 你怎么做事后补偿的方案？
- 你希望它们如何事后帮你行销？（或分享使用感受）
当你填完这八个问题。一份妥妥的 FAQ 与注意事项也完成了。
当然，我们不是八个问题都会用到。只是填写这八个问题，很大程度上不需要到实际交付阶段，就能协助你跨越到未来，感知到接收者可能会遇到的问题。
至此。让我卖个小小广告。我建议读者在阅读这本书时，也可以连带购买我撰写的另外一本书「闪电式开发」。在「闪电式开发」这本书里面。某一些主题的步骤、拆解更加详细细致。
当在实际远程工作后，除了返工问题。还会遇到一些小小的「交流」气氛问题。
因为远程，大家又紧密的换手工作。有时候，当你收到需要大量返工，或者是完全错误的结果。那真会让人气馁。
很多时候，「这做错了」「这不是我想要的」「你害我延迟」这些字眼，可能就会不经意在对话里面冒出来。
这些「用词」在面对面沟通时，可能不是个事儿。你可能只是小埋怨，或者只是使用开玩笑的口气责备。
在远程的聊天软件里面。这种缺乏上下文以及表情的表达，可能就会变成很重很种的责备。让你与同事的关系严重恶化。
程序员在开发时，有一道过程，叫做「Code Review」。Code Review 就是当程序员写好代码之后，必须将代码提交出去，让他的上级，或者是同级同事做代码审核。确定没有低级错误，或者是粗劣设计，才能实际进入线上正式环境。
然而，人无圣人。一段代码提交出去，不太可能是完美无瑕的。所以代码提交出去，可能瞬间就会收到很多评语。
这些评语都是「字」。所以有时候程序员不小心评语写的太狠，可能就会引发战争。比如说它们可能会这样写：
- 这里写错了
- 你怎么会这样设计
- 这是明显的 bug，你送出之前不检查吗？
- 我拉下来后不会动
一看就知道这些评语，要是提交者与评审者平常感情不好。看到这样的评语后写可能瞬间就会打起来。
但你要知道，但凡程序员评审别人的代码，脾气都不会太好。小错误还只会稍微更正一下。要是遇到那种让评审者「觉得」会花上他很多时间去改去修的代码。那么它们的口气就会「很直接」。
网上。如果你搜寻「Code Review Best Practices」「Better Code Review」，你会发现关于这类议题简直是一大堆。。。。。
有一个关于如何写 Code Review 的建议。我觉得挺值得借荐在远程沟通技巧上。
比如说把这些词，换成更好的语气版本。
- 这里写错了 => 這樣寫更完美 :)
- 你怎么会这样设计 => 可能我之前说清楚
- 这是明显的 bug，你送出之前不检查吗？=> 帶給我小小的困擾
- 我拉下来后不会动 => 是不是我操作上有错误
记得一定要多加表情符号「:)」。因为远程，有时候你的一句没有恶意的评语。可能对方今天刚好吃了炸药，语气一错可能瞬间就吵架了。在自己给 feedback 时，多加一个表情有好处没有坏处。
你会疑问。程序员平常写代码都这么表里不一，写评语还要包装一遍吗？
并不是。
相反的，程序员极度直接。代码评审里面，最常出现的是前面那个版本。甚至，它们平日跟 PM 讲话，也是那种版本。因为在程序员的世界里面，只有正确、错误与速度。
这也是正常人与程序员相处，比较受不了的地方。常常会觉得程序员讲话过于直接，伤害它们感情。但这是一个职业上的后遗症，要是我们写个意见要花这么多时间包装，反而会占住程序员的思考资源。
然而，说话好听一些总会有些好处。况且，远程工作的时候，大部分你见不到同事的脸，如果你与对方先前没有搭档过，或彼此实在不熟。过于直接的反馈，带来的不是效率，可能是浓浓的敌意。
一些好的沟通小技巧，总能带上多一点的效率而不是阻力。
很多公司。之所以内部没有建置知识库（Wiki），卡在内部几个原因：
- 员工懒得写
- 老板 / Manager 觉得没有必要
- 员工担心 Job Security
- 老板担心公司关键技术流失，或者泄密
只有少数一些公司与主管与意识到建置知识库的好处。
这里我可以针对一些读者常见的一律去做回答。
能。绝对能。
一些朋友。往往羡慕我过去所待的团队技术实力。总觉得怎么只能这么少人，就能干这么大的事。
其实背后的大功臣，就是 WIKI。
我带的每一个团队。几乎背后都有一个庞大的 WIKI。
说个技术圈段子，但这还不是瞎扯。我过去曾经服务某出版集团的技术部门，其 wiki 之丰富程度，甚至到了很多程序员耳闻该 wiki 的传说，视为自学宝典。踊跃报名入职该公司。
团队 WIKI 的好处有几个：
我们公司许多岗位，都是有工作手册与七天上手训练指南的。不管是程序员，或者是客服。
原因是这些工作都有高度共同作业流程。这些作业流程说简单不简单，说不简单也简单。但就是带入门需要老手的时间与整个团队的迁就。
因为我们有了相对丰富的知识库。其实许多基础问题，新手其实自己一查就找得到，能够很快解决基础问题。大大节约了团队的时间。
程式开发团队里面，会有非常多的「豆知识」。这些知识说重要不重要，说不重要也不重要。说小也不小。
但是就算是自己曾经解过类似的问题，有时候也忘记过去曾经找到的答案。更不用说可能这些答案，是同事解出来的。
开发程式往往是高度专注的工作，程序员非常厌恶被人打断。所以一个高效能够自助上手的知识库，能够巨大的帮助程序员的开发效率。
有些团队内部可能担心 Job Security 的问题。怕写了文件以后，自己就是个可有可无的队员了。
这样的情形其实根本不存在。
一般员工对于写文件有个经典迷思。就是写文件就是让自己有被可取代性。所以不想写文件。
但真实的情形是，我也当过员工，我发现身为员工，要有高可「被取代性」，才有机会升职。
因为职场上。我们每天遇到的是大量的重复性工作，如果你将知识埋藏在自己这里。后面会变成的情形就是，，某些大量的工作只有自己能够做。刚开始可能会蛮开心的，觉得自己在公司相当有重要性。但久了以后就会很不对劲。因为你的工作就是每天反覆做这些你已经做到烂的工作。每天这些工作大量的占用你固定的时间。
你觉得厌倦。但是公司也很无奈。因为其他人无法接手。只能你做。你想接新任务，老板却不准。因为你的工作没人接。。。。。所以只能卡在原有位置上。你很难请假，因为只有你会。结果假日你都在接电话。
最后你觉得这工作烂透了。要辞职。结果你损失了，公司也损失了。
我在年纪很轻时，就发现了这件事。
如果要让自己升职进步工作轻松，最快的方式就是写文件、教别人。
为什么呢？
- 因为自己教会别人，还写了一份文件以后。以后有同样的新人就不用再浪费我的时间。甚至可以直接把工作交接出去。自己去挑战新技能。
- 解过的问题写成文件，别人要问我的话，直接扔给他一份连结就好。连话都不必跟他多说。
- 请假时，因为一些关键流程都在 WIKI 里了。只有非常非常重要交不出去的东西，才需要找到我。其馀状况，职代都能看 WIKI 解决。
- 以前踩过的坑，不需要重新研究一遍。
- 因为愿意教别人，有大量时间可以玩新东西。所以，老板很赏识我。
我有时候还会假日时，把一些程序员界共用的知识流程，发表整理在我的博客里面。后来也变成我职场资产的一部份。
当我开始写文件时，同事也会开始写文件。无形之中，整个 Team 开始有时间去探索新的方向。而不是原地踏步一直在干同样的事情，问同样的问题。
同时，我们也知道，鸡毛蒜皮的事。真没有必要去打断其他人或者广播其他人。有事直接上 WIKI 查或者写到 WIKI 就好。
很多时候，我们去打断他人，真的只是为了求教于同事一件小小小小的事而已。
所以。如果你想要提高团队的沟通效率。而团队里面没有 wiki 的话。我建议尽快架设一个。
你会发现，架设 wiki 之后，团队的生产力会得到很大的喷发。
当然，不是所有流程与问题都能上 WIKI。有些团队会害怕流程能够让团队存取，将来有人叛变。会造成商业上的损失。这里我觉得可以切成几个问题去思考：
- 将共用流程整理上 WIKI 带来的好处，是否远大于不写 WIKI 的好处。
- 机密流程又占整个公司的知识库的多少百分比。
- 你的机密流程一到竞争对手或让公司同事自起炉灶，就能造成你商业上严重的打击？
- 公司同事入职，你是否让它们签订过保密协定以及泄密惩罚条款。
当你思考过这几个问题。也许你就知道如何构筑防火墙，以及拿捏流程进知识库的尺度在哪里。（我们会在资安篇深入继续这个话题。）
我们团队有一套标准做事流程：
- 平日在工作系统里面，详细纪录自己工作时遇到的状况，方便同事换手
- 在当周结束时，将一周之内最常遇到的重复工作流程，整理成一篇文章 + FAQ 上 WIKI。
而详细纪录自己工作时遇到的状况。这件事是「强制性」的。
有两个好处：
- 别人换手时可以知道发生什么事。
- 因为这个动做是顺手的。有写有记忆。这样写 WIKI 时回忆就不会太痛苦。
一旦人只要觉得麻烦，就不会动手想做。同事之所以不想写文件，是因为太费力。
所以一定要将这个习惯动作，整合到日常的小工作流程里面，大家动手的意愿才会高。