我们前面提到。要有效的提高远程团队效率，第一件事就是要引入一个项目管理系统。
问题来了。一般的团队，要引入哪套的项目管理系统。
基本上来说，也要看团队规模以及型态。
一般小型协作项目的开发，我通常会推荐 Trello。（30 个以内待办事项需要管理）
Trello 是看板式管理。适合待办事项状态简单型的项目（如：尚未实做，实做中，已结束）
中小型项目，我推荐 Tower。（100个以内以内待办事项需要管理）
Tower 适合待办项目多类别型的项目。比如我写书就会用 Tower(第一章需要完成什么，第二章需要完成什么)
至于公司内部软件开发，我们用的就是重武器 Redmine。
Redmine 是一套开源软件。非常适合用来管理复杂的项目。比如说像我们软件团队，需要管理复杂的子项目以及里程碑。就会非常倚重这一类的重武器。
其实，根据不同行业流程，也适用不同的管理软件。比如说我印象中很深刻的，就是一套 BrightPod 项目管理软件。
这套软件最大的不同，是用来解决重复型事件的。
一般来说，远程公司都是用一套管理软件管里不同的项目。这些项目的型态很不一样。每一个项目都有独特的进度。也有不同的里程碑与 checkpoint。
但是在 Marketing 领域，很多专案结构都极其相似。可以不夸张的说，每个案子都是相同的 checklist。只是套不同的素材而已。
所以 BrightPod 的这套软件就是以 checklist 为导向去设计的。跟一般的项目管理软件结构有很大的不同。
总之。如果你没有用过任何项目管理软件。不妨在 Google 时，输入这样的关键字，如 "Marketing Project Management"。"领域" + "Project Management"。
相信可以找到很多工作法、软件选择。
在远程工作上，实务上我们会使用一套软件叫 "Slack"。
你也许会觉得好奇。为什么我们明明就有「微信」、「Line」、「Facebook Messenger」这几套软件。为什么我们要单独使用一套工作用软件。
有几个理由：
使用「微信」、「Line」、「Facebook Messenger」沟通事项，有个很大的缺点。在于工作者不能将私人生活与工作分开。
你总不想「完全不能下班」吧。我唯一破例使用「Facebook Messenger」讨论工作的场合，就是与出版社编辑开会的场合。
因为这是「大家都有的沟通工具」。
但如果是要紧密协作的项目或外包项目，我通常都会邀请对方加入 Slack，所有对话集中在 Slack 里面讨论。
私人聊天软件，最大的隐忧是资安问题。很多市面上的资安事件，其实都是因为许多工作者，没有基础的资安意识。直接在私人聊天软件上大谈工作内容，甚至用来转发工作密件。
这背后会有一些问题。首先，很多人的私人社交密码非常薄弱。甚至是与许多常见服务帐号的密码相同。所以一个社交网站被破，几乎所有社交网站就会连环被破。
再者，to C 的社交网站，与 to B 的工作网站，对于资安防御等级是完全不一样的。
所以，在私人聊天软件上面聊公式，传递档案，实在是非常危险的一件事。
技术团队十分喜爱使用 Slack 的原因，还有几点。
a) 可分主题群组。
可以针对不同的工作主题讯息、切分开来
b) 可整合各类系统的讯息，一目了然
这是我们的网站系统的 BUG 讯息
这是整合了我们整个项目管理系统的 Ticket 更新系统。
基本上整个公司的人只要进了频道，就能知道一天之内公司发生了什么
我们也会将客服系统整合到 Slack 上。这样网站上如果客户一提客诉，我们也能迅速处理
所以。要是说项目管理系统，是远程工作第一重要的系统。那么第二重要的系统，就是工作聊天系统。
使用这套流程。基本上公司任一个员工，都可以透过手机（Slack有手机版），迅速 catch 到公司一整天发生了什么，同事正在做什么。重现 inhouse 的「空气流动」。
如果你不知道要挑选哪一套项目管理软件。我建议至少挑选一套可以跟 Slack 整合的。（关键字 slack integration ）
基本上两套系统一定要结合起来，才会发挥到最高效率。
我们团队会采用 Redmine 的原因，是这套软件除一般基本的功能外。还能客制 Ticket 的状态。
一般来说。许多项目管理软件的预设流程是这样的。
我们会扩充到六种不同的状态，以配合真实状态中会发生的状况
我们通常会是这样开票的。
- 回报人或者是执行者，先将票开出来，这时候先不指定到任何一人身上
- 当确定某人要实做时，就会将这张票指派到自己身上。所以当你看到这张票已经有指派者了。那么就表示他正在实做。你不需要去问，到底谁在做哪一件事。
- 等到他把这张票做完以后。他会将这张票设为「已解决」，重新指派给原开票人或者 Code Reviewer，检查是否符合需求，或者直接进入上线前的检查阶段
- 如果实做者做到一半，对于这张票的某些问题，有疑问。那么他就会在票里面写上他有的问题，重新指派回原先开票者，或者是能够解决他问题的人。
- 如果这张票已经确定完成上线，那么最终的部署者，会将这张票设为「完成&结束」。
- 如果这张票随著项目的进度，逐渐被认为没有实做的必要。那这张票也会在周四的指挥官任务之后，被设为「已搁置」强迫关闭。
这也是技术团队能够管理同时这么多 technical issue 的秘密。没有这种系统。事情一多，项目一复杂。那个 PM 再有通天的本领都管不来。
以我们团队的开发与协作速度。一周解决 100 张票，是家常便饭的事。
当然，看到这么多票在天空中，飞来飞去。如果你之前没有用过项目管理系统，一定会感到恐慌。这么多票是怎么管的完。难道进度不会被冲毁吗？
其实不会。Redmine 内建一些比较细致的功能，如子母票与里程碑。
- 里程碑
我们每一周不是都有指挥官会议吗？
我们就是在这个会后，会把要排近下一周下两周进度的票排好。同事只要专心把进度里面的票冲完就可以了。
在 Remote 的时候，我觉得与 Inhouse 很大的一个差异点。在于 Inhouse 协作时，任务相依性与沟通不良的问题不会那么大。
但是在远程工作时，这两件事造成的效率伤害就会被放的无比巨大。
要解决这两件事，我觉得主要有几个原则：
其实，若读者翻回第一章第二章，你会发现这些提问、回答、广播的技巧。都属于「过度沟通」的技巧。在 Inhouse 你会觉得这样做可能太啰唆。但是在 Remote 工作时，真的得做到「过度沟通」才能够「刚好完成任务」
在 Redmine 里面有一个功能，我自己非常喜欢，叫做子母票功能。
子母票功能是用来解决复杂性问题的。有时候，我们面前遇到的工作任务，不是解不出来。而是没有足够细致拆分。
一但将工作仔细拆解。你就可以梳理出，什么是我能先做的。什么是可以等别人回答再做的。什么是可以晚点再做，甚至在这阶段没必要实做的。
这张截图。是很经典的相依性阻塞问题。
例：当我们再开发电商系统时，系统里面势必需要有结帐功能。然而结帐刷卡信用卡，需要整合外部厂商申请信用卡权限。而这个步骤需要一个月去申请。这时候，难道你真的就傻傻的等一个月，才完成这个功能。
当然不是。你可以把先可以实现的功能都写完。甚至把刷卡成功之后的流程也写完。这样你只要等到信用卡权限申请下来，接完这个关键流程。整个大功能就完工了。
而不是因为眼前遇到一块石头。就完全晾在那里。
很多工作中，很多时后一个项目进展速度缓慢。其实就是因为 PM 与程序员不太懂得如何高效拆分工作内容的缘故。
所以在我们公司新人训练的时候，第一轮上岗练的不是写代码，而是练习拆票。
再来第二件事情就是跟著大家一起练站立会议。这样就可以顺手将「无法完成的事」，在站立会议上顺手分拆出去。
在高标准的团队工作。有时候我们难免被自己内心的完美主义纠结住。
然而在 Remote 时，每个人还是只有 24 小时，然而沟通成本变大了，意味著能投入工作时间变少了。
团队之间越强调连结协作，而不是单独作战。
所以提交成品的战略。应该是多次提交，逐渐重构。而不是一口气闷大绝招，一次到位。
写这本书之前。有个朋友问我。远程时代，如何定义管理者的角色与职责。
我觉得这个问题非常的好。
很多人对于管理的印象，就是管理者要负责「管」员工。
但是，在远程团队里面。基本上的协作方式是「自己管自己」，又或者是「制度」管著「所有人」。
因为沟通成本高昂，势必过去一对一沟通与监看这件事，是无法达成的。
我非常喜欢欧美管理学的一个「仆人式领导」的概念。经理反过来是服务大家的。
其实在远程工作里，经理的任务并不是命令大家。他比较像是一个流程引导者与任务分发者。不需要有一个人去催促进度向前。经理比较要做的是
- 管理边界。（不要多做了这个里程碑里面不需要做的事）
- 排除困难（负责排除大家遇到的流程问题或者是生产力问题）
- 主持会议（把控会议的效率与重新聚焦目标）
- 改善设计流程架构 （看书充实自己，提升每个环节的协作效率）
光以上这件事，就可以占满一个人的时间了。
我在 2014 年当 Engineering Lead 时。在后期基本上是没有时间写 code 。我的任务基本上就是负责派票，改流程，做新的自动系统与流程。
光这些事就能占满我的所有时间了。
(真的是所有时间。我虽然不写代码，但是每天光过票就能要快要了我的命)
但是我们当时的输出效率也非常之高。一天至少能完成 15 支以上的 pull request，整个公司一天同时在流动的票至少在两百张以上。
这个议题，在我的管理者朋友里面。相对是比较被重视的。因为世界上绝大多数的公司，都是 Inhouse型态。Remote 管理者绝对是占少数。
Inhouse 团队管理者与 Remote 管理者，在管理方法与风格上绝对会有非常大的差异。
那么一位 Inhouse 团队管理者，应该如何学习 Remote 管理技巧，又应该从哪里开始著手呢？
这里我有五点建议
Inhouse 的团队信息流通成本，绝对是远比 Remote 团队低廉的。甚至有时，你得成了 Remote 团队后，才会发现自己的问题其实内部有很多协作问题。
这是因为「那层空气消失」了。在 Inhouse 团队里，每个成员都可以拿到自己想要的信息。管理者可以比较轻松的掌握每个成员工作进度、状态、贡献。团队成员可以比较轻松的找到同事协助、或求助。资浅成员也容易在前辈身上学习。
进 Remote 团队之后，这些便利消失了。造成的结果就会是每个团队成员都陷入一阵伸手不见的五指浓雾当中。
我觉得在这片浓雾中。第一优先的要务是建立 SOP。
在 Inhouse 公司里面里面，每个团队其实比较像是一个特殊任务小组。这个团队会有比较明显的主线任务，以及一些次要任务。
及早的建立 SOP 是我认为最重要的事。因为 SOP 的存在可以统一大家工作的标准，并且节省大家问询的能力。（避免宝贵的上班时间，结果大家都在问基本的流程问题）
这有点像是大家虽然身陷了浓雾，但却暂时不要紧。身为队长的你发了一份可以同步的地形地图给大家。即便大家还是看不见彼此。但是起码在行走时，不容易进坑。
如果工作太多项的话。我建议可以从最主线的任务开始做。
第二件重要的事，就是导入同步机制以及项目管理系统。
在 Remote 时，让团队成员最不心安的是：不知道自己接下来要做什么任务、不知道自己任务什么时候该交、不知道自己任务达不达到标准、不知道缺东西了要跟谁要。
简单的总结就是没有人知道队友在干嘛。这在打游戏里面情景，就很像蒙著眼睛乱开枪。
所以这样的方向，比较是发给大家可以同步的 GPS 即时显示器。即便有浓雾也不用怕。
第三件重要的事是建立 Work wirh Me 机制。
一个正常的团队里面通常有 5-10 个人的编制。在公司里面，有时候我们是无法一个人独自完成任务的，需要协作。
以前在办公室里面经过朝夕相处，你大概知道什么时后可以拦下同事向他求助，也知道怎么跟这位同事交流更高效。这个同事喜欢什么，不喜欢什么。
硅谷金融新创公司 Stripe COO：Claire Hughes Johnson。发明了一个 Work with me 方法。他在成为 Stripe COO 的非常初期。就发给他了团队成员一份 memo，就叫 Work With Claire。这份文件主要分为几个章节，分别是：
- OPERATING APPROACH
- MANAGER HANDBOOK
- MANAGEMENT STYL
- COMMUNICATION
详述了如何跟他工作。他偏好的协作方法、沟通结构、团队价值观。
让每个人都知道如何容易的合作。这有点像软件团队的 API 文件一样。这样做的好处，是不用大家互相猜来猜去如何跟一个人合作最有效率。自己就先把自己偏好的工作方式同步给大家。省去猜疑与磨合的时间。
任何团队不可避免，一定会遇到扩张、补充新人的问题。
以前在 Inhouse 的时候，补新人不是什么难事。只要让他加入团队，用「空气」磨几个星期就能开始。
但是在 Remote 时，这件事却相对困难。新人一样会不知所措，不知道该干什么，不知道如何干最好，不知道要找谁取得协助。
在 Remote 时，打断别人沟通求助的机会，是珍贵的。但新人得把这些机会全用在问「非常基本」的问题。新人会非常挫折，老人也会非常挫折。
有效解决这个问题的方法，是建立起新手 Onboarding 手册。这本手册有点会像是玩游戏时的前导关卡，让新手加入「这局游戏」时，知道如何进行基本动作的手册。同时也能自助解决非常多问题。
这本手册会有 SOP 手册有相当大的不同。具体 Onboarding 作法，我会在本书里面其他章节另述。
最后一件事，就是建立一本公司的 Remote 工作手册。
Working Remotely 本身就是一套技能。而且是一套需要经过训练的技能。
公司转型成 Remote 公司固然能让你找到更好的人才。但是不是每个人才一进公司，就懂得如何远程协作，甚至融入公司特有的远程协作流程。
这时候一本 Remote 工作手册就会非常重要。
各位读者可以采购这本书送给新员工。或者基于本书的体裁，改编成一本自己供内部使用。
以上五个建议，就是我给 Inhouse 管理者，转型成 Remote 管理者最重要的五件需要先做的事。解决了这五个问题，基本上能够解决掉你团队里面 80% 出现的问题。