左耳听风 - 远程办公「读书打卡 day 22」

你好！我是 Java 工程师蔡姬，此蔡姬非彼菜鸡！很高兴和大家一起共读陈皓老师的《左耳听风》一书，并在这里分享自己的感悟。

转眼来到了书籍最终章。时间过得真快，很开心过去一个月左右的时间和大家一起共读这本书。收获还是不小的，其中有些观点我也是非常认同，可以说，作者用准确的语言把我内心的话说了出来。开卷有益，共勉之。

言归正传，正如之前一直做的那样，我的读书打卡依然会分为两部分——笔记 + 打卡。

• 笔记部分，我会整理在读书过程中感悟比较深的内容，和你一起分享。

• 打卡部分，我会就一个点阐述个人的思考。

话不多说，让我们开始吧！

笔记

宏观管理

• 努力找到合适的人

• 能独当一面

• 沟通能力强

• 能自我管理和自我驱动

• 设定共同的目标和使命

• 需要确保所有人形成默契，对要做的事情有统一的标准和认识：要做什么，不要什么；如何取舍和权衡。

• 倾向使用小团队

• 由于沟通成本较高，远程工作更适合小规模的团队。

• 《人月神话》一书指出，只有小团队才能驾驭复杂的系统。

微观管理

• 文档驱动

• 编写文档除了可以提供讨论的问题，还可以给后续开发者提供可追溯的信息。

• 编写文档本身就是一个深思熟虑的过程。讨论发起人把想法写下来会让自己的思考更加深入。

• 自动化和简化

• 自动化工具直接决定了远程团队的整体效率。

• 主人翁文化

• 每件事情都要有一个负责人。他有权对事情做出定义，当然也要承担对应的责任，而其他人则有义务配合他的工作安排。

• 议案文化

• 方案需要文档化才能促成有效沟通。

• 在发起讨论或评审前，发起人要把背景、目标、可选方案、参考资料、数据及优缺点分析清晰地写入文档。

• 目标承诺

• 每个人承诺自己可完成的工作目标，这个目标完全由每个人自己制定。

• 自我管理

• 我们的团队是没有审批制度的，无论是休假、报销还是出差，完全由个人自由安排，公司仅在一些需要整个团队全力以赴的关键时期不建议员工休长假，前提是个人需要将自己的安排告知团队。

• 一旦公司发现有人撒谎和作弊，会直接将其开除，因为这条规则的初衷知识为了让好人更加自由。

• 闲聊和自行见面

• 见面交流对促进感情非常重要。因此，我们鼓励远程团队的成员私下见面互相分享经历，甚至漫无目的地闲聊。

• 知识分享会

• 我们每周都会举办知识分享会，但要求每次只用半个小时讲一个小知识点。

• 团队中还会有人主动使用云表单来收集分享会的反馈信息。

• 就地奖励文化

• 团队默认不设置年终奖，而是用就地奖励代替。

• 如果公司没有盈利，但员工表现良好，我们仍会给予他们年终奖。

• 不挣钱的主要责任在公司负责人，而挣钱的主要功劳则理应归团队所有人。

• 外包支持性的工作

• 一些支持性的工作，如人力资源管理、行政保障、薪资发放、财务支持、员工持股落实、测试、定制化开发等，我们尽可能地使用外包。这样可以让团队更小、更高效，也更易于远程协作。

• 异步编程

• 由一个人组织好代码框架和结构之后，其他人再加入项目，这种异步编程的模式效率会更高。

远程工作协议

• 原则

• 主人翁精神和领导力：每个人都是公司的主人和领导者。

• 自发性：每个人都必须是主动的，需要自己提出或认领要做的事情。

• 目标导向：每个人都是产品经理，也是项目经理，必须将自己的工作与公司的大目标联系起来，知道什么是重点。

• 坚持高标准：我们要坚持用高标准来要求自己，对于高标准的目标不妥协，但在实施路径和策略上可以做出妥协。

• 实践

• 保持在线：工作时必须保持在线。若需要离线请提前预告离线时长。

• 文档驱动：文档能将重要信息结构化，而且编写文档会让员工审视自己的想法。

• 设计评审：对于重要的问题或工作，需要先把自己的想法分享出来，让大家共同评审，而不是直接去实现。

• 简化和自动化：简化和自动化是软件工程所追求的两大目标。实现自动化可以让远程团队更高效地协作，是公司规模化的前提。

• 反思与重构：无论是代码还是工作，都需要经历反思和重构的过程。反思是进步的源泉。

• 里程碑计划：对于一个项目，每个人都需要有自己的里程碑计划，并承诺将其完成。计划要在两周内完成，一周内完成更好。

• 证据驱动：任何讨论和分析都应该基于权威的证据、数据或引用。如果争论不休就先停下来，大家分头去调查和收集证据。

• 演示日：开发人员拿着自己的成果，向团队做一次实时演示。这样有助于开发人员从产品角度思考自己的工作。

• 有效会议：会议的主要目的是提出议案、发现问题、达成共识。

• “1-2-3” 问题升级原则：遇到问题时，若自己处理 1 小时后仍没有思路，请与他人进行小范围讨论。如果与他人讨论 2 小时内没有取得结果，请将问题升级到团队层面。如果团队内讨论 3 小时仍没有解决问题，则需要借助外部力量。

• 3Ps 式更新：每个人在更新进度时，不要只是简单地签入，而要说明工作内容。在工作告一段落时，请简单地总结 3Ps——计划 (Plan)、优先级 (Priority)、问题 (Problem)。

• 不同意与承诺：团队成员都有自己的开发风格，因此团队可能对某个问题产生争议。对此，我们鼓励争议，但是要求团队在做出决定之前将其解决。一旦团队做出决定，成员就必须支持这个决定，并为目标做出贡献。

打卡：站在员工和领导两个角度，分别如何看待远程办公？

以下看法仅针对程序员这个工作岗位。

其实，目前支持远程办公的在线工具，包括线上会议，在线文档，直播分享等等，已经非常成熟了。

因此，远程办公的效率高低主要取决于人而不是工具，包括是否能保证线上沟通的响应速度和沟通效率，以及是否能投入与现场办公时相当的精力来完成工作。如果团队成员这两点都能做得比较好，我想员工和领导都会支持远程办公。

以上便是今日份的笔记和打卡内容。欢迎你在评论区留言，我们一起探讨，共同进步。

我是 Java 工程师蔡姬，期待和伙伴们有更多交流和思维碰撞，明天见！