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