内容简介:在2015年文章的《恐怕会在并不遥远的未来,我们不得不迎接工作方式的转变,以及它所必然会带来的,我们却远没有准备好的深远影响。即便是ThoughtWorks这样对于远程工作方式有着充沛经验储备的组织,在面临突如其来的隔离时,也并没有表现出顺滑的过渡。这当然不是容易的事情。从共处一个地点,拥有相同工作时间覆盖,可以表现出亲密无间的团队环境,切换到每人被迫处在孤立环境,受限于场景氛围甚至网络带宽的问题,面临从工作环境的搭建,网络设置,到进入稳定的工作状态,这里有一系列的问题。直到最终寻找回对自己和团队而言都合理
在2015年文章的《 Remote versus Co-located Work 》中,Martin Flower有这样的叙述:在同地协作的团队和远程团队之间,并不存在简单的二分法。但在五年后的今天看来,因为瘟疫的大流行,以及作为行业领先者Google和Facebook对于远程工作所采取的行动,事态也许会往单一的方向发展下去。
恐怕会在并不遥远的未来,我们不得不迎接工作方式的转变,以及它所必然会带来的,我们却远没有准备好的深远影响。
不同以往的沟通窘境
即便是ThoughtWorks这样对于远程工作方式有着充沛经验储备的组织,在面临突如其来的隔离时,也并没有表现出顺滑的过渡。这当然不是容易的事情。从共处一个地点,拥有相同工作时间覆盖,可以表现出亲密无间的团队环境,切换到每人被迫处在孤立环境,受限于场景氛围甚至网络带宽的问题,面临从工作环境的搭建,网络设置,到进入稳定的工作状态,这里有一系列的问题。直到最终寻找回对自己和团队而言都合理的节奏,步履蹒跚。
远程办公
虽然并没有明确的证据表明,但每个人对全部远程带来的大量沟通都会有真切的体会。这对软件构建本身影响巨大。在我看来,沟通是软件开发过程中每时每刻都在做的事情,以致于我们过去一直在尝试不同的实践和方法,尽可能去改善沟通的效率。但在表面上,我们一直在拒绝承认这样的事实。毕竟我们是技术人,有什么不是可以用技术去完美解决的呢?
而现在,每个人都切身感受到了这一点——因为增加沟通所带来的每天疲惫不堪的状态。如果说敏捷尝试用更短的迭代和高效的沟通,去抵抗频发的变化和不确定性。那么现在疾病的大流行,则开始重塑我们对于沟通方式和效率的思考。
首先我们要对短时间内因为不得不适应新状态而显露的低效,持有 理解和认可 。以及抛弃对于只能在同一场所才能享有的同步响应的不切实际的期望。并警惕由此引发的微管理的倾向,这会对有效沟通和建立信任感有毁灭的打击。
我们仍然需要固定时间的站会,需要在集中的地点,以透明的方式可视化团队整体的工作进展。每个人能够尽可能没有阻碍地访问到TA理应可以访问的远程系统。基于 决策文档 来帮助团队建立统一的意见,而不是受困于低效的会议。我们甚至仍然可以保持乐观而 务实的结对 体验,在相约的共同工作时间,依据带宽使用合理的工具。以及我们应该尽可能在视频会议的时候 开着摄像头 。
视频会议
回到沟通本身,除了信息的有效高效传达以外,它所承担的职责恐怕就是对于信任感的守护。物理上的距离显然让信任这件事变得困难异常,而信任感的捡回并不比建立起来更容易。
等待推向极致的工程实践
我能想象,在远程工作逐渐成为日常的时候,重新释放全部的开发效率(如果过去有过)将会是具备足够诱惑力的事情。这也可以被认为是,在新工作条件下,我们在牺牲掉一些曾经无比信赖的像面对面沟通这样的东西之后,仍然对保持交付质量的期待。
试想在远程优先的工作方式下,如果每个人都处于单点工作状态,在沟通成本巨大,而团队个体能力暂时并不齐整的时候,我们对那些可以显著度量交付质量的工程实践,也许会有不同以往的依赖,甚至期待将它们再度推向极致。
沟通
对于持续集成和部署流水线,在其中作为安全伞的自动化测试和覆盖率,我们恐怕要期待更严苛的执行和验收标准。团队可能需要建立更严格的工作流程,来约束因为个人的疏忽对于整体输出的影响,逐渐建立起团队特有的纪律性,来消弭无谓的失误引起的额外的修复成本。
对于业务需求切分的粒度,也会因为多数团队成员独立的工作状态,而有新的诉求,个体可以更容易独立完成。由此可以想见,敏捷诸多实践的整体性本质,会因为远程工作的影响,而产生此消彼长的态势。而显然团队需要根据自己的情况,做出务实的选择。
作为作者之一的Jez Humble在《 Accelerate 》中,提出了四个关键指标,作为衡量高效能组织高质量软件交付的指标:
- 前置时间
- 部署频率
- 平均恢复时间
- 变更失败率
这在我心目中,这恐怕是未来高效交付的寻求方向。它们通过看似极为简单但实则抽象的几个数字,在倒逼组织的文化和结构,团队的工作方法,以及个体的行为方式的改进。优异的表现,必然需要从组织到个体发生有利于结果的转变。激进的组织是否因为远程工作方式的契机,在此方向勇敢推进,也未可知。
重新评估曾经坏味道的实践
徐昊在技术雷达峰会的圆桌讨论中,提到了我们恐怕需要重新思考,那些曾经弃之如敝履的反模式和糟糕实践。它们很可能在远程工作的约束下,具备了不同以往的价值。
比如,特性分支( Feature Branch )的糟糕之处在于开发者面临合并代码不回去后的失控。开发者可以在分支上轻舞飞扬,但轮到合并的时候却一筹莫展。如果团队建立了新的纪律:特性分支在一天内天必须销毁,同时有分支特定的持续集成的支持。那么在这短暂的时间内,则可以换取开发者自由和团队一致性之间的某种平衡。只是这种额外的复杂度,需要团队仔细考量。
而重复代码在新型分布式架构(微服务)中,如果在代码和组件解耦方面,具有一定的价值,以及帮助团队在远程工作下提升效率,那这也是值得付出的成本。
我们发现很多类似的实践方式,是在以远程优先作为工作方式的开源软件世界默认并沿用至今的。可能我们需要重新评估,那些被惯常漠视的实践方式,比如Pull Request,对于满足团队的实际需求,或者解脱困境,都会是务实的选择。
个体迎来未知的处境
尽管还未到来,但远程工作对软件的生态影响显然不会止于开发方法。
初看起来,远程工作的方式对企业和组织是友好的。因为员工对于共同工作场所的需求降低,企业对工作地点和环境的投资,会有立竿见影的降低。而淡化了地域位置的工作方式,让企业可以在更广的区域范围内寻找人才,选择更具竞争力的人才。
但会有一些显著的问题需要解决,比如如何为这种消除了地域特点的工作选择匹配的薪资水平?以及如何在长期并不能在现场的情况下,衡量员工的绩效,只能选择结果导向的评价机制?以及未来保持员工对于企业文化的忠诚度、信任感以及归属感呢?抑或,这不再是一个理所应该需要解决的问题?
企业员工
而员工作为个体,是和企业一道踏入了这突如其来而充满不确定性的远程工作时代。企业和员工之间的互动关系也会发生潜移默化的变化。
我们每个人长久以来的经验,都是依靠在生活和工作间的地点变化,来完成身份和行为的切换。疫情之前的生活和工作状态,虽然在不断加速,但人的孤独感也相对更容易随之消散。虽然远程工作让我们得以更多时间陪伴家人,照顾孩子。但时间一久,发现事情的走向并不是预想的那样简单。
现在相对单一的地点,模糊了场景和身份的变换,习惯和心理上的冲突呼之欲出。有人在工作场所即便暂时离开半小时,也会心安理得,但在家里环境离开屏幕十分钟,都会心存焦虑甚至罪恶感。更重要的是,长此以往因为缺少跟团队和组织的物理性联结,而自然产生疏离的状态,以及开始对于工作甚至生命意义的发问。这才是我们每个个体都不得不去面对的。
但现实以及人的社会属性仍旧存在,一方面是工作场所、场景、方式的变化,一方面个体被不情愿地推动着适应并继续前行。而我担心的是,无论远程带来的工作方式变化,还是以及社会和企业追求高效和逐利的本质,都把人推向被物化的境地。以更加模糊的面孔,机械地完成指标所定义的规定动作,尽管这个过程会有高效的产出,但还会有多大可以容纳个性和创造性的空间呢?
毕竟过去在软件行业,我们曾经以手工艺者和匠人自居,相信创新更多来自于个性和创造性,而这多数来自于企业的特有文化机制拱卫的认同感、归属感和信任感。那新的工作方式是不是会把我们和软件开发一道,推入更加机械的语境呢?
最后
很明显,我们对此都没有明确的答案,但不得不迎来远程工作的不确定性。好在每个人仍然有选择的自由,既可以选择承认这纷繁复杂的现实,也可以选择感激变化所带来的自己认知的精进。
( 感谢我的同事王妮、张婕对于文章内容细节的建议和反馈,这一篇也有她们的贡献。 )
以上所述就是小编给大家介绍的《尚未到来的远程工作》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:- 尚未到来的远程工作
- 一个一直尚未处理的Golang不兼容问题
- ONT 链网架构尚未成型|标准共识评级调整
- WTC测评:核心团队从业经验,核心代码尚未开源
- Linux内核发现两个尚未修复的DoS漏洞
- 谷歌安全团队发现苹果macOS漏洞,至今尚未修复
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。