全文2677字，阅读约需6分钟。这是某二线城市一家中小型软件公司，公司50人左右，主要业务产品为教培业务系统。我在公司内负责研发团队各类事务。经过一周远程办公考验，我们工作运转正常，花费成本较低。我这里给出办公过程和部分执行细节，供参考，期抛砖引玉。
2020年春节期间，新型冠状肺炎疫情突发。我在焦虑地等待中，收到了公司于2月1日发布的“关于春节后公司延期到岗办公的通知”，要求到岗复工之前，安排员工进行远程办公。对于软件类公司来说，远程办公就是利用各类软件平台进行工作协作、在线办公的过程。
作为一家专业软件公司，我们对工作的质量和流程已然有了标准化；同时，由于业务的特殊性，出差、异地办公是常态。我们使用云服务器，也早已熟悉各类在线协同的办公软件，因此，我对团队进行远程办公是有信心的。
眼下，我和团队经过一周的真实场景考验，工作沟通正常、公司业务正常、客户满意度正常，花费成本较低。现在，我将我们的执行过程记录下来，以期抛砖引玉。
一、建立临时项目组
麻雀虽小，五脏俱全
2020年2月1日，我接到公司通知之后，使用微信多人视频通话功能，连线了团队的各位同事们，确认了彼此位置和网络环境情况，将大家按照网络维度、岗位维度进行了统计：
1. 网络维度：A常在族：网络环境稳定，可正常上班；B掉线族：可使用手机网络上班，不排除经常掉链子的可能；C离线族：无网络，没电脑，不能上班。
2. 岗位维度：项目经理、产品经理、需求管理员、设计师、开发经理、开发组长、开发工程师、测试工程师、运维工程师、硬件工程师、后勤人员……等等。
然后我将A、B族的各岗位同事拉进临时建立的微信群中，对应我们手头各类运维、迭代上线的工作要求，按照岗位进行临时项目分组。分组具体名单使用石墨文档在线协同，进行传阅。
特殊时期，我按照最小化、可工作的项目组配置人力：每组项目/产品负责人1人，开发团队2—3人（含组长1人），其他设计师、测试工程师分别为组，由项目组提出需求后，我们共同评估，统一调配，资源共享。
对于正在整理需求的新项目、准项目，由需求管理员与客户保持联系，使用石墨文档更新需求说明。
二、远程办公约规
没有规矩，不成方圆
远程办公最大的挑战，是建立统一的、处理工作的规范和标准。
不同的工程师对于同一问题，思考和处理的方法不一样，造成的结果产生偏差，尤其对于用户来说，感觉个人体验上随工程师个人喜好变化而变化。不舒服的变化是引起客户投诉的主要原因之一，而客户不满会造成软件公司业务风险。
我们公司以适应客户业务特征为基本准则，在反复磨合和迭代调整中，建立了一系列工作规范和执行标准，将关键内容以“责任清单”形式下发给各岗位员工，有规矩，有清单，有复盘，并与绩效挂钩。
在这次临时项目组工作中，我们通过微信工作群，要求各项目组建立讨论组，我参与其中，同时做出如下约规：
1. 约定各项工作时间
上班、下班时间正常。各项目组视频打卡。由开发组长发起上班/下班视频通话，视频要求含本人和当前工作环境、报告位置、体现时间。下班加班者，由开发组长同意后，单独进行下班视频通话。开发组长保存各类视频通话截图发到工作群并以“#+日期（月/日）+项目/产品名称+上班/下班视频”为标准格式做出备注。同时，对出勤情况，按照上班、下班进行统计后，以标准格式写入石墨文档，传阅给后勤人员。
后勤人员使用在线协同功能，每日9：00AM后对在岗情况进行统计。对于缺勤、请假及其他突发情况离岗的，及时在工作群通知并@关键人，以备应对和选择替代人员。每日下班也如是操作，以此完成考勤记录。
2. 约定对上工作请示、汇报方式
特殊时期，单独建立请示、汇报通道。使用微信企业号的审批功能，单独建立了直达审批模板。按需提交请示、汇报。如遇紧急情况，电话催办关键人。
3. 约定早会、日报的安排
每日8：45AM，以项目组为单位，使用微信多人视频会议开早会。早会以敏捷开发的“每日站会”形式召开，轮流主持。事后主持人以规定形式在工作群内公布：
以“#+日期（月/日）+项目/产品名称+早会”为标题，以123的数字列表方式简要表达项目组早会结果；同时，对前一日项目组完成的工作，以“#+日期（月/日）+项目/产品名称+日报”为标题，以数字列表方式简要表达前一日工作结果。
员工个人日报，以微信企业号的“日报”功能进行提交，项目组长负责对应工作计划、早会内容进行审核，对产生偏差的需及时沟通。遇到风险问题及时在工作群内公布并@关键人。必要时候，项目组成员、我、公司负责人将投票决定调整工作计划。
4. 约定临时突发情况的处理方式
任何人，如遇临时突发情况，可在工作群紧急通知，通知形式以“#+日期（月/日）+紧急通知”为标题，简述内容，并@关键人，可电话催办。
三、坚持敏捷开发
拥抱变化，及时调配
决定远程办公那天，公司管理人员一起开了视频会。最多的问题，是有人担心，简约的团队配置是否够用、好用？远程办公，是否会反应不及时？我的回答是：不会。只要我们约规明确，工程师有工作责任心，坚持在岗，使用敏捷开发的管理方法，坚持计划列表、早会、日报、周例会就没有问题。
在具体的工作任务分配上，有各组项目/产品负责人在Teambition根据自己的需求列表，确定优先级，编制工作计划；由开发团队组长接受并按照迭代要求进行分配，将具体开发项指派到具体工程师名下；工程师完成工作后勾销任务，在当天日报中上报当日完成率结果，并在第二天早会时据实汇报。
项目/产品负责人关注计划与Sprit的内容关联，组长关注Sprit分解和开发人员工作关联。对于任一风险较大的偏差，及时上报。
对于设计、测试的需求，由项目组提出，我根据实际情况统一调配。
四、使用OKR工作法
明确目标，确保达成
转眼，公司探索使用OKR工作法已经一年了。在这个过程中，我们使用OKR工具，有效改善了单个特殊项目的开发质量、进度延期问题。对于远程办公中会遇到的问题，我相信及时使用OKR工具，是行之有效的办法。
总结
在我们当前的经验来看，远程办公，除了基本的网络、计算机、云服务器等办公环境之外，易于接受的管理方法、有标准的执行规则是最重要的。对于这期间突发情况和紧急需求，需要控制在三个节点之内得到解决：坚持范围内主动放权；审批节点1>2，不超过2的规则。
对于没有单独开发远程办公软件平台的，可以考虑较低成本、极大程度利用当前各类协同办公系统，例如本次，我们使用了微信企业号、石墨文档、云服务SVN，Teambition等。
在远程办公的探索和执行上，我们还有很多不足等待改进。我们会以满足客户业务需求为服务目标，不断修正、迭代我们的工作方法、管理方法，力图给客户带来更好的服务体验。
原创文章，如需转载请告知