原创不易，转载请联系作者，感谢！
0. 小引
第一次听到“远程办公”的概念，大概是09年刚上大学的时候。当时听说克雷数学研究所（Clay Mathematics Institute）的研究生可以选择世界上的任何地方从事其研究工作，于是“远程工作”带着满满的浪漫主义色彩进入到了我的职业规划，然而从校园走出来之后，才渐渐意识到现实的骨感。
直到加入到我目前的公司，才重燃了我对远程办公的热情。然而在真正实施“远程办公”的方法之后，也逐渐发现了各种各样的问题，以及产生了各种各样的应对办法。不过这个布满荆棘的过程也是我个人成长的过程，我从最初的科研走到传统工业，再直至踏入互联网行业，让我始终坚持的一个理念就是
任何好的解决方案，都是在解决最棘手的问题时诞生的。
所以在不断尝试和实施“远程办公”的同时，也不断的在与其他公司的管理者/技术团队进行观察和交流，从而及时的深入了解远程办公的理念，同时也去规避一些不必要的风险。于是，对远程办公产生了一些感想，遂整理记录如下。
1. 个人远程办公的状态
先简单介绍一下个人目前的远程工作状态吧。实际上在之前的工作中，当前公司执行的是一种on-site与telecommuting之间的一个过度状态，即我们的客户都是海外公司，一切会议，讨论乃至产品交付都需要通过远程办公形式完成，但是我们的工程师每天必须要到当前城市的办公室签到并完成工作，不忙的情况下也会参加一些其他项目组的续修分析和技术方案会议，当然后者也是当前公司的一种价值和企业文化取向，目的时从每个人的技术方案中总结出一套最优化方案，以此表示对客户的负责，同时也能让每一个工程师体现参与的价值。之所以会形成这种on-site与telecommuting的中间态，主要是因为在倡导远程办公社区的同时，又要考虑到国内市场的现装(国内市场对于远程办公虽然提倡了若干年，但程度依旧不高，其原因也会在下文中分析)。
直至去年十二月份，由于疫情在国内蔓延（当然是当时了，如今国内的疫情让人喜大普奔有没有，感谢英勇的医务工作者，也感谢一起募捐的小伙伴们），出于对员工的安全的考虑，我们才从之前的过度状态转入到了真正意义上的远程办公(telecommuting)，正如上文说过的理念“任何好的解决方案，都是在解决最棘手的问题的时候诞生的”，所以这次“疫情”无疑是为国内的“远程办公”普及提供了一次有利契机，一定程度上讲，也算是因祸得福了，虽然这代价是如此沉重。
虽然是首次意义上的“远程办公”，但是毕竟有前期过渡状态时期的工作铺排，所以个人觉得这个转变并没有给形目组和个人带来许多负担。回想起来主要有三个原因，
- 首先来说是项目自身就是on-site与telecommuting的一个过度状态，而且内容铺排上来说更为倾向于telecommuting形式(上文已经提及)。
- 其次，个人目前处于的项目体量很小，只有一个PM和我在内的两名工程师，工作内容铺排非常容易把控。而且这个项目虽然体量很小，但是会涉及许多高并发，缓存IO，机器学习和模糊匹配等等多种开放性的技术问题，所以让我们与客户有了长达一年多的磨合过程，与客户的默契程度是相当不错的。
- 再者，19年下半年，为了公司内部累积技术框架和一些半成品项目（这个想法真的是偶然为之，没想到为后文埋了伏笔），个人在公司内网部署了一台服务器，可提供项目管理，代码管理，Maven/NPM/Gradle等私有镜像仓库，以及持续集成和自动化部署等服务，所以在执行远程办公之后，利用网络隧穿技术和公有云构建了一套混合云，为接下来的远程办公生产的技术问题奠定了基础。
说了这么多其实还没说到目前远程办公的真实状态，由于目前公司原本执行的就是弹性工作制，所以一般在不是很繁忙的状态下，我是按照下表来规划我日常生活的
不得不说，远程办公不仅仅解决了交通一大恼人的问题，同时为生活添色不少，对于一名大龄单身狗来说，虽然爱情不顺心，但至少可以用一些快乐时光填补寂寞也是极好的。当然，在得到的同时，也会失去一些，比如说，个人非常喜欢利用碎片时间（等地铁，等公交，坐公交，上厕所）去学习一点东西，比如一个公式，一个算法，推演一些新颖的模式或架构在项目中的应用等等（这也是一种学习方法，虽然我不是学霸，但毕竟是个理科生，所以很多时候能够以点及面的去学习），而把大把整块的时间用于Game和Happy上。但是远程办公会让人腾出许多整块的时间，那么如何利用这些时间并持续做下去就成了一个困扰。庆幸的是可以利用时间去蹭大学时恩师的网课，填补自己在数学和算法方面的知识空白。同时利用其余时间可以做一些有意义的事儿，比如疫情期间义务给初高中学生补课。
在远程办公的初期，利用一张表格来规范自己的生活是比较有必要的，让人更容易接受远程办公的方式而不至于惰怠。而这种惰怠恰恰是阻碍远程办公普及的一个重要原因，后文会展开去说。
2. 远程办公的价值驱动
个人觉得在任何一个复杂的运行系统中，任何一个个例都有着一定的普适性，同时也有着一定的特殊性，所以在当前公司尝试远程办公的同时，也会向其他公司的朋友求教，比如一些技术团队负责人，工程师，甚至是人力资源和财务等等行业。来比较和总结远程办公的优势和缺点，通过总结普世性和特殊性，以达到发展和规避风险的目的。那么这里就总结一下个人所想到的远程办公其背后的价值驱动。
2.1 产品原因
首先就是产品原因，毕竟产品的第一动力就是客户需求。远程办公一定意义上是为市场提供了一种人力资源的便利。而且这种便利性的付出恰恰又可以让生产公司/团队拥抱更大的市场。所以远程办公的意义在于对于市场和生产之间提供了一种加速的正反馈机制，也同时让生产团队伸长了手臂拥抱更大的市场。
比如对于我们目前来说，公司接近八成的业务来源于海外市场，而这八成业务就需要采用远程办公来实现。毕竟on-site的成本如此之高。当然，随着各种远程接活和私活平台的完善，产品驱动带来的一个直观不利因素就在于竞价模式，而选择的方式则是因团队而异，因人而异。比如很常见的一种情况就是印度团队的报价及其凶残，可能对于并不十分熟悉远程办公的客户来说，最直观的方法就是看价格，所以在产品驱动的过程中，作为生产方，我们也要有一个价值观，就是在产品、价格和质量之间做一个取舍。真正好的客户都是培养出来的，而非来即所得。
2.2 主观/客观原因
从客户需求和产品的角度来说，产品引导的远程办公自然是第一驱动力。但是对于从业者的角度来讲，第一驱动力是从业者的自身，比如家庭，交通，城市环境，收支情况等等因素。远程办公一定程度上解决了一个生存环境和收入高低这个矛盾，让从业者有机会也同时具备能力享受生活。给从业者一个宽松的生活氛围，同时也一定程度上较低公司的管理成本。
个人当前所在公司，一直比较推崇远程办公的模式，也成功过许多案例。比如一些同时因为婚姻的现实问题，不得不离开北京，回到南方的一个二线城市，然而该员工离职也会对公司造成一定的客户损失。因此当时最佳的一个选择就是远程办公，在解决问题的同时也开启了全新的办公模式的探索。
个人对于办公环境并没有过多的体会，但是个人对于早晚乘坐公共交通却甚是反感。当时在北京上下班的日子至今想起来都甚是折磨。那时候就在想如果能够远程办公该是多么美好的事情。
所以，对于公司来说，引导并尝试远程办公模式的办法不应该完全站在产品研发的角度，而应该更多的结合开发者自身的需求，也只有这样才能把远程办公推行下去，
2.3 节省不必要的成本
传统的办公模式除了日常开支之外，最令人诟病的就是用时间开不必要的会议。然而这个诟病却不容易说清楚的，比如说客户需要开一个会议，无论内容有意义与否，其实客户都是需要产生付费的，那么这个会对于公司来说就是有意义的。然而多数情况我们经常出现的是团队的“内耗”，比如需求分析，和技术方案研讨，市场出现这种情况。
而远程办公则可以降低这种“内耗”。其主要原因就是交流沟通成本的提高，所以在远程的交流沟通之前，大多数人都会准备充分，从而能够让在有限的沟通资源产出更大的价值。不过本质上，这并不是远程办公的直接效用，而是办公中一种效率懈怠造成的，所以这种所谓的”内耗“成本并不是远程办公模式节省的，而远程办公主要效用仍旧是借用一些硬件上的成本而已。
3. 远程办公的基础设施——云
在远程办公的各种准备当中，基础设施是第一步要做的事情。正如上文说到的，我在公私假设的私有云为接下来的远程办公奠定了一定的基础工作。这里对远程办公的一些工具做一个简要的梳理。但首先要说明个人为什么建议使用混合云而不是共有的开源第三方仓库，主要的原因还是安全，以及维护的便携性。就在个人撰写这篇文章的时候，一个大公众号Info Q给出了一条微软封禁github开发者账号的新闻，不得不说这是一个信号。另外就是作为公司的基础设施维护人员，对于网络和数据安全的知识多多少少还是要了解一些的，常见的如注入式攻击，DDOS攻击等等攻击手段和防御方法还是需要掌握一些的。
代码仓库Gitlab-CE
之前也都是使用Github等公共代码仓库，但是一个重要的问题，就是私有协同仓库需要收费，虽然架构也不是很高，但是如果企业不能够持续维护一些中间件产品，那么就是一笔浪费了。另外就是随着贸易对抗的加剧其管理体制，个人对其稳定性目前还不能完全信任，但是对于国外客户的代码管理仍旧是首选产品。
但是在这种情况下，个人建议不妨采用gitlab做一个备份产品。Gitlab-CE版本是开源社区提供的免费版本。当然在一些功能上相对于收费版本肯定是有所限制。个人喜欢采用gitlab-ce作为内部服务器的代码仓库，用以累积公司业务框架和中间件产品代码。同时利用gitlab天然的镜像仓库，将仓库实时同步到github等私有的仓库(Github允许个人免费使用三个私有仓库，而且其中一个可以支持最多四人协同开发)。做到产品代码管理的万无一失。持续集成Gitlab Runner
采用gitlab-ce版本作为代码仓库的另一个原因就是gitlab的CI/CD功能做的非常好，天然的支持K8s进行持续化集成和自动化部署，对其他类似工具也十分友好。
而在实现这些功能中，当然是需要Gitlab Runner来支持的。容器/私有云——Docker
容器这个话题不必多说，想必这个时代的开发者没有几个是不熟悉容器特别是docker容器和K8s工具的了。另外只简单说说私有云的问题，想必有些人并不了解。其实OpenStack给出了一个私有云搭建和部署的解决方案，但是个人更为推崇利用Docker构建私有云方案(搭建过程网上有很多)，主要原因也是方便管理和维护，而且与上述工具同属于一个生态。
另外值得一提的是，为什么要构建私有云，除了上述的生态需要之外，另外一个重要原因就是在FaaS，SaaS和分布式微服务的技术前提下，私有云一定程度上会节省客户的开发成本，因为自己维护的云虽然技术上不如一些大公司的公有云产品，但是开发阶段却是更为节省的方案。当然最终交付产品时，肯定要做迁移，毕竟私有云往往难以承受生产环境的稳定性。镜像仓库
个人另外一个推崇就是在Docker容器中部署多个本地镜像仓库，例如Maven，NPM，Docker Hub等等，并不需要对所有框架和所有框架版本进行镜像，而只是对团队内部常用的技术生态进行镜像同步即可。其目的也是为了远程办公的网络问题提供一种保障。这看似是一个弱智的问题，然而有些时候确实很要人命。前一段在老家的家里办公时就遇到了这种情况，运行配置文件同步时，经常卡断，以至于一套框架配置做了两三天，严重影响后续的工作效率。API文档工具——Swagger
个人主要从事Java开发，经常使用的Web框架就是Spring Boot等等，那么API文档撰写和协同工作也同样是一个重要的问题。早些时候，我并不喜欢Swagger工具，因为Springboot本身就有API文档插件，对代码编辑非常友好。而Swagger对Spring Boot代码侵入性很强，要做好多的注解，而且要对其控制器和安全规则做单独配置。最终部署的时候你可能还需要花些心思去移除或者屏蔽它。
但是后来再做一个dotnet项目时，忽然发现Swagger也还算好用。所以当团队内部出现这种多语言开发的局面时，Swagger也不失为一种统一的解决方案，毕竟可以降低团队开发人员的学习成本。白板工具——Microsoft Whiteboard
个人尤为喜好使用白板，曾经跟同事说过，会议室小一些，没有桌子，没有椅子都可以容忍，但是没有白板那是万万不行的。事实上很多人也是有同样想法的。因为在需求分析、技术方案和晨会当中，快速地展示，理解和吸收一个人的观点十分重要，而要达成这一效果，个人觉得符号语言和图像语言是最为方便的。也因此白板成了会议的必备工具。
在年后的远程办公中，为了客户沟通和团队会议，我找到了微软的这款产品，即可携同的白板工具，可支持客户端和Web两种形式，非常便捷。在线团队文档协同工具——腾讯文档/Google文档
在线协同工具不必过多介绍，想必很多人都已经十分熟悉。相比来说Google文档得功能更为强大，对于文档协议得支持也更为全面，而腾讯文档相比功能上较为逊色。但考虑网络原因，很多情况也就只能选择腾讯文档了。团队会议工具——Teams等
视频会议工具很多，这里不再赘述，感觉微软得产品能够购成一个完整得体系，所以个人倾向于微软得产品。团队协作的一站式工具——飞书
值得一提得是，上面得工具都是分开得，使用得时候比较难受。所以无意中发现了飞书这个产品，它集成了管理，项目管理，功能模块，协作文档和在线会议等多个功能，确实比较好用。号称是字节跳动员工离职最怀念得产品。平板电脑类的书写工具——MyScript Nebo
很多人在这两年选用苹果平板得一个主要原因，我想就是它自带得电容笔配合其自带得只能笔记本功能。确实很好用，深受很多教师，设计和开发者青睐。个人体验也是流畅度和识别能力都非常好。但是个人却不太喜欢苹果系统得封闭性。因为可能有一些开发者会跟我一样喜欢自己做点小工具然后希望随时放到自己得平板或者手机上。但是对于苹果系统要做到这点就显得麻烦了一些。
那么并不是没有这款只能笔记本得替代方案，因为这款只能笔记本背后推动得技术是由MyScript最早提出的。MyScript得产品已经可以适用于Web，Windows S和Android系统，但是都是付费得。不过总体体验却不完全输于苹果得智能笔记本，这类电子手账主要是记录便捷。个人尝尝用其来组织解决方案或者文章纲要，对于数学得符号系统支持得足够好。*弹性可伸缩的云数据库
小团队一个很常见得问题就是，经常要求每个开发者在本地Fork并建立数据库，这一点经常造成开发者得困扰，比如当开发者得电脑性能不是足够好时，开发会卡顿；当数据库做一些设置不能完全同步到开发者本地时就又会造成数据库io错误等等一系列得问题；而小团队并没有专门得DBA人员去维护数据库，所以最终让数据库的原子性，冗余问题越来越严重。
个人在执行小团对开发时，一般会利用上述得私有云构建统一得数据仓库，大家修改仓库要及时声明，或者将数据库在私有云上进行分布式部署，这样大大减轻开发者对于数据库维护得压力，也同时降低错误率。那么私有云上部署数据库现在也随着数据库得发展而进行，从传统的SQL关系型数据库，到后来的NoSQL数据库再到现在的NewSQL数据库，从早期的OLTP引擎架构，到后来的OLAP引擎架构，以至于现在HTAP数据引擎架构，强迫团队使用新技术，就意味着技术团队对技术生态的更新和适应，与此同时，你不需要专门的时间去分享和讲解这些新的技术，因为团队开发者随时可以查看你在如何使用新技术，自然而然他们也会很快的跟上。
4. 远程办公的团队管理——“联邦式”
总体来说，远程办公最值得谈论的话题就是团队建设问题。其实“远程办公”这一概念天生就存在一个潜在的矛盾，即松散团队人员个体，同时又要加强个体之间的沟通联系。但毕竟远程办公不是一个全新的概念了，所以其实已经由许多小的团队进行过了探路人，并取得了一定的成功。
但是相应的大团队使用远程办公的先例却不多见，对应的团队建设和管理经验都源自一些探路者的分享，分析和推测。其中看到一种有趣的方法是一个类比模型——分布式。这种从技术架构角度类比处理问题还是很有可取之处的，因为模型的角度讲，更为有利于问题的分析和全局的推演。那么我们不妨沿着这个思路，敞开脑洞，用抽象的模型语言来处理这个问题。其实，所谓的“分布式”的团队管理更像是一个MapReduce模型，从客户需求把问题拆解开去，然后讲原子性的需求转变为对应的子任务，并交由对应的开发者去完成对应的研发/开发工作，示意图如下
值得注意的是，在任务拆分之后，我们应该格外注意那些“没有什么价值”的任务，因为这类任务本身对项目没什么贡献，但是在这种远程状态里，这类任务反会影响开发者的执行效率。
然而这个类比不够恰当的是同步对于状态的同步更强，也就是说对于每一个开发者都强烈的知道项目的进展情况，虽然这种状态有利于项目开发，但是在现实中大团队的远程办公实操起来却着实困难。对于大体量的项目开发，虽然敏捷的管理要求每个人对于项目的需求都能够完全把握，但实际上实现是很困难的，更不要说即使现场办公也很难保证每个人完全把握项目需求，而在远程办公的沟通模式中，由于交流成本的提高，这样的代价无疑是十分昂贵的。
那么更为松散的一种类比，是我之前介绍Google物联网设备机器学习的一种算法模式，即“联邦式”。这种模式没有强烈的状态同步需要，但是需要一个对应只能的工作去对任务分发，同步和整合这些工作有所把握，也即是一种Center的存在。Center会有一个固定的任务时钟，等间隔的归纳评估任务开发状态，并及时做出相应的调整，从而降低开发者与开发者之间的沟通成本，所以从推演上来说，这种联邦式的团队管理，不失为一种有效的远程办公团队建设和管理手段。至于当中只能极为重要的Center可由下文中我所介绍的远程社区来充当。
无论如何，对于远程办公模式下，大体量项目研发和开发团队的建设和管理仍旧是一个开放性的问题，很难在一时间解决，只有不断地探索和尝试，或可取得一定的成功。
5. 远程办公的自我修养——自律
这一部分还是蛮重要的，是在构思这篇文章时补充上的。但是真正写道这里却不知道如何去表达，因为写不好就是一片心灵毒鸡汤。但是仍要提及的是，其实自律最好的动力源自于爱好，个人还是蛮喜欢利用代码去构建一些功能的感觉，所以自然也就喜欢在有事儿没事儿的时候谢谢代码。但是在远程办公在家的初期，仍然也会有一些懈怠的过程，毕竟家庭的氛围确实很难让人沉浸到工作当中去。所以在这段时间里，如我上诉的一张作息时间表就显得有勇气来。也许一张表格不能够完全约束你，但至少让你在突然进入到远程办公模式时更为从容一些，也能让人更快的适应远程办公的节奏。
其实除了这一张表格之外，个人实际上还利用业余时间做了一个自己的生活管理系统，把这个管理应用作为操作系统的一个Service，至少可以让自己能在正确的时间做该做的事儿。
6. 远程办公的若干问题
当然，远程办公理念的推行并不一番丰顺，在国内市场尤为不被认可，在横向对比其他技术团队，合作伙伴和其他行业之后，个人总结主要有以下几个原因。
6.1 数据安全/数据脱敏
其实数据安全并不是一个完全无解的问题，毕竟现在越来越多的数据挖掘算法和数据脱敏工具越来越成熟了，但是在涉及这个话题时，其情况是比较错综复杂的。数据的保存和传输安全是任何时候都值得考虑的问题，但是数据脱敏这一个话题有些时候可能被过分解读了，甚至有些数据是可以通过书面协议来约束的。当然大数据脱敏有时候又是一个很大的成本。特别是随着一些统计算法或者智能算法的普及和应用，脱敏已经不能是简单的同数据类型造假了，甚至我们有可能需要对数据进行归纳分析，应用一些非常先进的数学算法手段来找出数据的模式，从而进行模拟脱敏。
在个人的经历当中，遇到两次数据安全要求比较高的情况。一个是很早之前遇到的项目，需要在内网分发数据到客户端进行拟合模拟等算法操作。但问题是有些算法需要依赖模型本身，也就是说如果我们要实现远程办公，那么我们要对模型数据进行造假，但又不能太假。其牵扯的算法复杂度很高，所以由于问题过于棘手而最终放弃了。
另外一个案例，是今年二月份接触了一家做电子货币的金融科技公司，他们前期工作需要加一名高级系统测试工程师。当时我向他们介绍了远程办公的方式，然而他们却始终坚持on-site. 我当时也很不理解，后来发现他们的账号数据，金融数据都十分敏感。如果远程办公就必须做脱敏，棘手的是，他们项目中有人需要做一些量化模型，如果对数据进行脱敏，那么这些模型的处理工作就可能无法配合。另外一个因素就是当前如果选择on-site的话，派人出差需要隔离，这也是一笔很高的人员成本，所以最终无果。
所以总体来说，在远程办公模式中，数据安全也许不是技术上不可逾越的障碍，但是现实中因为各种各样的因素左右，也会让远程办公这种模式失去效用。
6.2 企业文化与信任危机
远程办公另外一个重要限制其实是源自人本身，就是在远程办公的情境中，客户总是可能在揣测开发者是否在认真的完成任务。这种信任危机尤其能够阻碍远程办公的阻碍。其实个人本身对这个问题并没过分关注，但是现实中却总是出现类似的场景，造成项目最终以失败高中。
所谓信任危机是双方的，首先客户会惧怕开发者不能认真的工作，反过来，开发者也会担心客户是否能够按约付费。在经历的项目中以及交流过的开发者中，抵赖付费的不在少数，甚至不乏一些国内知名企业。
就在为撰写这篇文章而收集素材的时候，找到了一段关于远程办公的语音采访。令人震惊的是信任危机往往能给项目带来摧毁性的打击，严重威胁着研发/开发工作的进展。但是归根揭底这是一个人文问题，如何能够培养客户的信任，如果能够培养开发者按时并保证质量的进行工作，谈到底就是一个企业文化建设的问题。
6.3 协同效率
另一个关于远程办公的话题可能就是团队协同效率，因为各种原因，远程办公注定要将团队拆解成散碎的每个人。无论线上工具再如何完备，但可能效果仍旧无法与现场工作相媲美。但是效率与成本综合起来看，也并不一定会拉低利润。
不过，总归是要解决团队协同效率的问题。个人觉得除了云上的基础设施，以及“联邦式”的团队管理理念之外，另一点也十分重要的就是能够让远程办公人员即使在无任务情况下也能相互保持交流，从而磨合默契程度。之前公司内部提出一个线上茶水间的概念，个人觉得尤为新颖。但总体来说其内容还是太过单薄，所以终归需要一种完善的机制拉拢开发者。仅仅凭借几个巧妙的招数，几个颇具新意的电子还是不够的。而是有一个能够聚合开发者主动投诚的平台和交流生态，即我后文要讲到的远程社区。
社区不是一个简简单单的市场信息聚合平台，而是开发者的生活点滴，喜怒哀乐。就想你小区的超市一样，有事儿没事儿都能拉动开发者们来转转看看。
6.4 信息化程度不够
当然，如果横向比较多个行业，那么可能阻碍远程办公的另一个因素就是信息化程度不够。这里没必要对一些传统工业进行讨论，因为这类行业的信息化不是几个人的问题，而是整个行业共同面对的问题。这里我说一个软件相关研发行业的案例。
之前，受到一个朋友邀请去帮助他们解决物联网设备驱动程序的问题。在现场的时候，我发现他们的业务有点类似于物联网行业，他们需要开发用于分布设备进行数据读取，检测等功能的系统。但是这种系统需要链接设备测试，而其中几个重要的测试就是热插拔或冷重启等。那么问题就来了，他们虽然是高度信息化的行业，但是并不能因此就具备远程办公的能力。因为如果要实现全自动化设备测试，就需要自己组件一套测试系统和测试设备。如果这么去做就相当于项目成本翻倍，原则上，这也是一种信息化程度不够的行业。但归纳来说，一个行业信息化程度的受限往往来自于成本的考量。
但转过来看，现在由于疫情原因，导致他们迟迟不能复工，所以产品的如期交付也就成了天方夜谭。公司也会因此造成亏损。所以有些时候，也不得不对成本和信息化程度之间做一个抉择。个人觉得有时候你可以不必立即采用远程办公的模式，但是在未来，也应该在为可远程办公做一些铺排工作。
7*. 一个高龄开发者的延续之路——远程社区
由于大部分互联网公司，尤其是国内的互联网公司的生命周期短的特点，造成了软件开发这个行业一直处于一种人员流动频繁，流量较大的状态。当互联网处在一个恶性或者说是持续性不够的市场机制中，对于年龄的青年化要求则尤为突出。因此，“高龄开发者”一直是一个受到广为关注的话题。从横向去看各个行业去看，主要依靠体力的行业往往对从业人员的年龄青年化较为看重，而对于需要经验积累的技术性行业或者客户资源积累的销售行业，则丰富的工作经验才更为受到重视。但是，在互联网却出现了一个反向命题，即一个需要丰富技能的技术行业缺一直依赖于年龄年轻化的体力劳动，个人觉得其根本原因在于企业所处市场的竞争机制，以及公司从事业务的创新性，虽然国内不少小型互联网公司初创没几年，本应该是茁壮成长的年纪，却总是看上去已经垂垂老矣。没有管理模式，产品模式和市场模式的创新，只能根据以前的行业模式维持并挣扎，这也就导致了其对低成本的体力型员工更为看重。总结来说，无论是因循守旧且恶性竞争的市场机制，还是传统的以客户需求为导向的产品研发机制都会造成这种局面。在这种情况下，个人一个揣测高龄开发者的延续之路很有可能是未来的远程社区。
眼下，个人所在的公司也正在筹备在国内市场试行以及推广远程社区这一想法。然而目前似乎并没有形成一套统一的范式(至少我个人还没有看到一个推广，运营以及研发的统一范式)，所以，这里个人结合上述对于远程社区的论述，基于远程办公团队管理的“联邦式”模型做一个假设。
远程社区，是默认由一些具备高效远程办公素质的开发者，产品经理和需求分析工程师组成的集合体。然而又不能单单是一种松散的集合体，否则与当下运行的第三方“私活”平台无甚区别。个人觉得，最高效最具质量的解决方案一定是让团队中的每个人都在做着自己擅长并喜欢做的事儿。这恰恰也是远程办公一个最原始的初衷。就如同我们所居住的社区一样，每一个生活在这个社区里的人平时都是独立行动的个体，每个家庭有每个家庭的生活，而每个家庭不必依附于某一个第三方的机构才能生存。然而当这个社区面对一些共同的问题时，就会把若干家庭中擅长解决问题的人集中在一起去做事情，比如物业，居民委员会等等(当然，这里没必要抬杠说现实的社区怎么怎么样)组织去应对和解决问题，而且尽可能保证问题的解决方案和问题的最终结果是最优化的。
远程社区并不是在传统私活平台的传统市场基础之上建立的，而是逐步引导客户认知并了解远程社区的解决方案。具体来说，并不为适配客户提出需求之后开发者解决需求这种情况，因为这种情况很难形成大型的产品项目，远程社区应是主要适配客户提出需求，社区对其需求进行分析，深入挖掘，意见反馈，从而给出优化解决方案的情况。简而言之，远程社区的目的并不是顶替现有的私活平台模式，而是对远程办公的价值最优化。
更为细致的描述，可以运用一定的模型语言来描述，私活平台的模型可以概括为如下
在这个模型中，第三方平台除对双方交易安全和信用进行评定管理外，基本并不深入参与项目本身，并且还要在产品研发过程中压榨高昂的管理费用，并且各个开发者或者开发者团队之间给出的解决方案都相互独立，具有天然的不完备性，因此最终很难保证产品的交付质量，也很难承载大体量项目的研发/开发工作。特别是，当开发人员与客户之间达到一定默契程度之后，就会从该平台脱离开去，因为平台本身并不能给双方带来更多的利益，也就没有真正的持续驱动力。
而对于远程社区来说，就是要尽可能规避这种传统模式。首先对于客户来说，社区并不接受低质客户的委托。而对于开发者来说，也不必为了生存而去选择“全能也全不能”的技术栈。社区由公共认可的“委员会”管理，并接受社区内所有人员监督。任务分配机制根据社区一致性认可决定，继而其可以描述为如下的模型语言
社区本身要参与到各个项目的解决方案优化，任务分配，产品优化等各个环节，目的以高质高效的为客户输出服务，而非完全裁决于项目成本。当然在项目开发模式和合同模式上，目前来说最好的方案必然是敏捷+ODC的形式。在这样一个模型中，可以看出一个远程社区的基本轮廓。它能够给出一个产品研发/开发的统一范式。当然，各种的细节还需要优化。
在远程社区的模型中，有一个基本问题就是在多层级的社区作用下，如何优化协同开发效率。个人认为除了采用上文阐述的“联邦式”团队管理之外，其社区本身也将有益于效率优化，因为社区本身并不是一个呆板的第三方平台，而是需要参与者活跃于其中，社区本身能够增进成员之间的沟通机会（如平台开放演讲，直播等等相关运营活动），也能够及时为社区成员增添技术生态。所以本支上，社区建设与协同效率成为一个彼此正反馈机制，演变必然是层层递进的。
8. 总结
眼下，随着世界疫情的进一步恶化，在人们为命运共同体努力的同时，也为远程办公开创了一个进一步规范范式和取得市场发展的契机。也希望众多中小型（大型企业一般是有能力做的更好的）企业，无论是否是互联网行业与否，都可以在远程办公方面进行尝试，并共同打造一个完整的远程办公社区，贡献于当前的市场情况，乃至未来风云变幻的市场。