软件的软性一面

  Download PDF version of this article PDF

软件的软性一面

自主性与认可的悖论

关于软件团队文化中信任和价值的思考


Kate Matsudaira

谁不想要因其辛勤工作和贡献而获得认可呢?

在我的职业生涯早期,我曾经天真地认为,只要你努力工作,创造价值,你就会得到回报。我曾相信那种乌托邦式的理想,即努力工作、严于律己和贡献是推动你攀登企业阶梯的燃料。哎,我错了。

你看,我的职业生涯是从一个害羞、缺乏安全感,但聪明的程序员开始的。我努力工作(几乎每个周末都工作),在不忙于工作项目时也编写代码(实际上现在仍然如此),我对公司忠诚且敬业。

我的项目本应以价值来评判

有一次,我花了六个月的时间与另外四个人一起做一个项目——我感觉自己在功能和工作时长方面的贡献都位居团队之首。所以你可以想象我在发布会上有多惊讶,当时团队的总经理站起来,表扬了“Josh和其他团队成员的辛勤工作”。我站在那里,惊呆了,心想,搞什么鬼?!总经理怎么会如此脱离团队?我们的经理难道没有看代码提交记录和解决的问题吗?为什么对项目贡献可能最少的人 Josh,最终成为团队中唯一被点名表扬的人?不是我,也不是项目中资历最老的人,而是那个似乎花了很多时间与我的老板和项目中的其他人交谈的家伙。

我们很多人都有过类似的经历。我们不知疲倦地工作,尽最大努力按时完成任务,但不知何故,我们却被忽略了——而另一个人,你真的相信他没有你贡献得多,却受到了青睐。精英主义和因你的工作而获得认可都到哪里去了?

自主性使精英主义成为不可能

快进到今天。我与一个由 18 位杰出技术专家组成的团队一起工作,我的工作是评判他们的绩效。直到最近我才意识到,在很多方面,这几乎是不可能做到的。

在规模化的情况下,没有客观、可量化的方法可以做到这一点,除非诉诸于微观管理——这甚至不是你想在一个才华横溢的团队中考虑的事情。如果这让你感到困惑,那么让我描述一下人们提出的用于评判绩效的各种指标(请注意,其中一些是可衡量的,但另一些则更主观)

• 工作时长。 哎。我讨厌盯着工作时长的人。至少对我来说,编写代码就像艺术,当我没有心情时,我无法强迫自己完成工作。将花费的时间作为生产力衡量标准,并不能公平地体现开发人员所需的创造力和思考。除此之外,在高虚拟化环境中跟踪工作时长实际上并不可行。我喜欢我的团队成员可以在家工作——或者在任何他们感觉工作效率最高的环境中工作(这就是我们设立“无会议日”的原因)——但如果他们不在办公室,我怎么可能跟踪他们的工作时长呢?就像数豆子一样,数工作时长很糟糕。不要这样做。

• 代码行数。 这个衡量标准有很多缺陷——从“最好的代码是你不写的代码”这句格言,到我曾经花了三天时间写一行代码,而另一天我写了超过 10,000 行代码(虽然,诚然,其中一部分计数包括一些大量的复制粘贴)。而且,当然,删除代码也可能非常有成效。

• 缺陷计数。 质量显然很重要,但在原本编写出色代码的开发人员的产品中发现缺陷并不少见。这个指标存在严重的缺陷——它没有考虑到你最好的开发人员通常会产生一定数量的严重缺陷,因为他们被委托设计和实施应用程序/系统中最复杂和关键的部分。因为具有高影响力的缺陷而惩罚你最好的员工,无异于奖励平庸。

• 功能。 功能是关键,因为就贡献而言,构建或添加到产品中的功能应直接与客户价值相关联。当然,当多个人为一个功能做出贡献时,根据功能进行评判可能会变得复杂。此外,实现的细节可能会极大地影响所涉及的工作量和时长。例如,考虑最近一个为现有站点添加登录功能的项目:使用插页式页面实现该功能可能只需要几个小时;但是,该设计涉及使用灯箱,这增加了安全方面的复杂性,并使项目增加了几天的时间来适应。如果你不深入研究实现的的技术细节及其权衡,即使将功能和特性作为绩效指标也可能具有误导性。

• 可维护性。 衡量和跟踪像编写可靠、可维护的代码这样主观的东西是很困难的——但是任何不得不与遗留的意大利面条式代码作斗争的人都会告诉你,对于将在生产环境中长期使用的代码而言,可维护性值得额外花费时间。那些花费额外时间编写高度健壮、可维护代码的程序员,往往会因此而受到惩罚,仅仅是因为他们的真正贡献要到几年后才能实现。

• 技能和知识的积累。 如何衡量投入时间学习一项新技术以充分有效地使用它;或研究和选择合适的工具以优化你的生产力;或做出谨慎和深思熟虑的战略选择,最终使项目可行和成功所带来的好处?显然,这些都是至关重要的步骤,但外部人士可能会指出,在花费在发展技能和获取知识上的相同时间内,本可以完成更多的工作。

• 帮助他人。 许多程序员之所以出色,不是因为他们所做的工作,而是因为他们使其他人变得出色。仅仅团队中有这些人就可以使其他所有人变得更好。指导和无私地帮助他人对于建立和维护一个高效且凝聚力强的团队至关重要,但尽管这种贡献是真实存在的,但量化个人在这些活动中的作用可能非常困难。

可能还有 101 个以上可以用来评判程序员成就的因素——包括他们的自我展示方式(例如,态度良好)、他们的可靠程度,或者他们贡献创新想法和解决方案的频率。这些因素很少有客观、具体的,可以加总并给出等级——而且如果不深入研究细节或微观管理项目,就很难做到这一点。

那么,你如何才能被注意到呢?

如果没有可靠的管理层衡量你的贡献,你如何才能被注意到?实际上,一切都归结为一件事:信任。

信任就像一种货币。当管理者给予团队成员自主权和独立性时,他们是在信任他们能够完成分配的任务,在此过程中做出明智和战略性的决策,同时在问题变成问题之前主动沟通问题。事实上,这些管理者正在将他们的钱投资于团队,当他们看到投资回报时,他们就像任何幸运的投资者一样,非常高兴。

然而,信任需要时间、耐心和一致性。如果你无法与你的经理建立关系,那么所有的工作都毫无意义。要让别人投资你,你必须表明你实际上是一项投资。问问自己这些问题

• 你的老板信任你吗?

• 你的团队和你的同事信任你吗?

• 你是否做得很好以赢得他们的信任?

• 你的同事会如何向其他人描述你?

• 你在你的组织中有多大的影响力?

作为一名经理,我曾经在不同的时期非常喜欢某个特定的员工,但后来注意到这个人的同事不喜欢他或她,或者他们对他的或她的表现持有负面印象。在这些情况下,考虑到我对整个团队的信任程度,集体的意见很容易超过个人偏好。将信任视为一个图,将你与之互动的人之间的每条弧线都视为一个权重——因此,在绩效方面,这些权重真的非常重要。

项目、产品、绩效和公司不仅以其产出进行评判,而且还以它们如何产生产出进行评判。

在我本文开头提到的示例项目中,Josh 做得不同的一件事是,他不仅完成了工作,而且还确保管理层——我的老板和总经理——知道我们的团队在做什么。事后看来,他是我们的项目在拥有如此多人的组织中脱颖而出的原因。当时,我怨恨 Josh;但现在,多年以后,我意识到他对我们团队的贡献不仅仅是他的代码,还有他的沟通技巧和他完成工作的方式。

不过,顺便说一句,某些公司文化可能比其他公司文化更奖励 Josh 的做法。像 Josh 这样的人的问题在于,随着时间的推移,他们可以优化“信任”,并创造出对其贡献的扭曲看法。这就是我所说的“办公室政治”——这也不是好事。

我的一位非常聪明的朋友告诉了我一个故事,关于加入一家大公司,遇到了很多超级聪明、高效且富有成效的人,他们都通过表现得非常显眼来与上级建立信任。

“他们在会议上发言最多,他们打断别人,他们在凌晨 3 点发送极其冗长的电子邮件,详细说明前一天发生的会议的细节,他们在电子邮件中抄送看似无关但级别很高的人,等等。他们的老板喜欢他们,他们得到了最好的评价,等等。在遇到这些人并对他们的花招感到既惊讶又厌恶之后,我们开始清楚地认识到,整个文化都在自我选择这种类型的人。我们很快就明白了为什么发生了这么多“工作”,但完成的工作却如此之少。”

作为一名经理,你能做什么?

作为一名员工,我希望我的贡献得到评判,并成为精英管理团队的一员。我也想要自主权,以及拥有项目重要部分的能力,并且不希望有人在我身后盯着我。

作为一名经理,我希望表扬和赞扬那些值得表扬和赞扬的人,并且我不希望进行微观管理,把我的日子变成老大哥。

这意味着一项隐含的契约

我会给你自主权和独立性,但你有责任与我分享状态和信息。

例如,一位团队成员曾经告诉我,他工作非常努力,并且真的尽了全力;然而,从我的角度来看,他的进度并没有达到他的队友的水平。当他离开公司时,他告诉了我他所做的所有这些事情,我问他,“你为什么不早点与我分享这些?”有了这些信息,我本可以建议他将时间花在对业务更重要的优先事项上。他的回答是:“我以为你会知道。”不要犯同样的错误。

作为一名经理,认识到进步也很重要。这意味着了解一个人的优点和缺点。如果你观察到某人的表现,并看到该人在其发展领域之一取得了实质性进步,那么这绝对值得肯定。例如,如果你有一位出色的工程师,他通常是不善于沟通的人,但后来挺身而出,不仅为项目贡献了出色的编码能力,而且还让其他团队成员随时了解不断变化的风险因素,那么这些成就值得赞扬。

确保你考虑了一个人在组织中参与的所有因素。采取措施提出好的问题,并征求组织中其他成员的反馈。最后,让每个人都知道你对沟通和进度的期望。

那么,你现在能做什么呢?

我对这一切的结论是:如果你想要自主权,以及拥有和控制你自己的领域和项目的能力,那么你的工作就是推动信息并与你的团队成员建立信任。

换句话说,你需要学习并做到以下几点

• 坚持到底。 说到做到,并始终如一地履行你的承诺。

• 主动沟通。 当一项任务花费的时间比你想象的要长时,解释原因。

• 提高你的沟通技巧。 为了让别人听到你的声音,有时你必须磨练你传递信息的方式

• 主动提供信息。 努力解释模糊或难以理解的想法和概念。分享你的决定和偏差的细节。当你犯错误时,这一点也很重要——在别人自己发现之前让他们知道,将表明你对情况的所有权,并可以防止以后的误解。

• 真诚坦率地表达你的感受。 即使你可能持有相反的意见,也要沟通你的想法(尊重和策略性地)。

• 不要在背后议论他人。 如果有人知道你会说你的老板、公司领导或其他同事的坏话,就很难建立信任。

• 在困难的情况下保持客观和中立。 学习如何在压力下保持冷静,并充当外交官来解决冲突,而不是引起冲突。

• 在你的行为中表现出一致性。 这不仅在坚持到底方面很重要,而且在消除可能存在的任何双重标准方面也很重要。

• 学会信任你的团队成员。 这是最难实现的目标之一,但信任是双向的。给予他人信任并学习如何与他们合作,对于建立牢固的互助工作关系至关重要。

反过来,你可能会幸运地拥有一位好经理,他能够向你提出好的问题,并花时间了解你的贡献。如果你的情况并非如此,那么请确保你与你周围的人分享信息,例如你的同事、你的老板和其他利益相关者。

良好的领导力意味着让每个人都保持一致。如果你想要独立性,那么你有责任确保人们知道你的贡献。

Kate Matsudaira 是一位经验丰富的技术领导者。她曾在微软和亚马逊等大型公司以及三家成功的初创公司(Decide 被 eBay 收购,Moz 和 Delve Networks 被 Limelight 收购)工作,之后创立了自己的公司 Popforms (https://popforms.com/),该公司被 Safari Books 收购。她在职业生涯早期是一名软件工程师,技术非常精湛,并在分布式系统、云计算和移动领域做出了领先的工作。她拥有管理整个产品团队和研究科学家的经验,并建立了自己的盈利业务。她是一位已出版的作家、主题演讲人,并荣获西雅图 40 位 40 岁以下精英等奖项。她是 的董事会成员,并在 katemats.com 上维护个人博客。

版权所有 © 2015 归所有者/作者所有。出版权已授权给 。

acmqueue

最初发表于 Queue 第 13 卷,第 9 期——
数字图书馆 中评论本文





更多相关文章

Catherine Hayes, David Malone - 质疑评估非密码散列函数的标准
虽然密码散列函数和非密码散列函数无处不在,但在它们的设计方式上似乎存在差距。针对各种安全需求,密码散列存在许多标准,但在非密码方面,存在一定程度的民间传说,尽管散列函数历史悠久,但尚未得到充分探索。虽然针对现实世界数据集的均匀分布非常有意义,但当面对具有特定模式的数据集时,这可能是一个挑战。


Nicole Forsgren, Eirini Kalliamvakou, Abi Noda, Michaela Greiler, Brian Houck, Margaret-Anne Storey - DevEx 在行动
随着领导者寻求在财政紧缩和人工智能等变革性技术的背景下优化软件交付,DevEx(开发者体验)在许多软件组织中越来越受到关注。技术领导者直观地接受,良好的开发者体验能够实现更有效的软件交付和开发者幸福感。然而,在许多组织中,旨在改进 DevEx 的拟议举措和投资难以获得支持,因为业务利益相关者质疑改进的价值主张。


João Varajão, António Trigo, Miguel Almeida - 低代码开发生产力
本文旨在通过展示使用基于代码、低代码和极限低代码技术进行的实验室实验结果,以研究生产力差异,从而提供关于该主题的新见解。低代码技术已清楚地显示出更高的生产力水平,为低代码在短期/中期内主导软件开发主流提供了强有力的论据。本文报告了程序和协议、结果、局限性和未来研究的机会。


Ivar Jacobson, Alistair Cockburn - 用例至关重要
虽然软件行业是一个快节奏且令人兴奋的世界,在这个世界中,新的工具、技术和技巧不断被开发出来以服务于商业和社会,但它也很健忘。在其快速前进的过程中,它容易受到时尚潮流的影响,并且可能会忘记或忽略针对其面临的一些永恒问题的成熟解决方案。用例,最初于 1986 年引入,后来普及,就是那些成熟的解决方案之一。





© 保留所有权利。

© . All rights reserved.