插图的

专家-多面手平衡

几年前我遇到了一个危机点。在我的公司,不同学科之间存在着明显的差异;我被贴上了“后端开发人员”的标签,这开始让我觉得受到了限制。这个标签没有错:我的大部分工作时间都花在编写服务器端代码上了。我很喜欢,也很擅长——但事实并非如此全部的我能做到。

继续下面的条

我一直认为自己拥有相当多面手的技能,给自己贴上标签意味着我只能从事属于后端开发人员职权范围内的工作。我觉得定型。不幸的是,这种分歧不仅仅存在于这家公司;它在整个行业无处不在。

那么问题是什么呢?#第2节

考虑下面的项目场景:市场营销人员有一个想法。他们与设计师讨论,设计师在Photoshop中模拟了它。设计师将其交给前端开发人员,前端开发人员抱怨设计师没有考虑在没有重大JavaScript攻击的情况下实现X有多困难。她完成了自己的工作,并将其交给了后端开发人员,而后端开发人员对此大发雷霆,因为前端开发人员根本没有考虑Y将如何与公司的CMS合作。

听起来熟悉吗?

建立一个狭窄的专家小组会使团队分裂,并限制我们合作的方式。在他的文章中”开发设计弗罗斯特(Brad Frost)将这种分歧描述为一道篱笆,专家们把各自的东西扔过去,让其他专家接住并跟着跑。由“专家”组成的独立团队彼此分开坐着的情况并不少见。公司规模越大,就会增加更多的专业站点,每个站点都有自己的任务要完成,而且大多数都是在孤立的环境中工作,这种孤立助长了不健康的环境,限制了协作,并造成竖井。

关键是在团队中找到专家和多面手之间的正确平衡,以利用他们的优势并培养健康、高效的环境。最终,问题是:专家如何更好地合作?

平衡你的团队#第三节

多面手的魅力#第四节

在我的性格形成时期,我在一家小型软件公司做开发人员。完全的自由——绝对的信任,没有繁文缛节。如果其中一个活动站点有错误,我可以自由地跳到活动服务器上,仔细查看日志,或者检查配置文件中的错误。我不仅被允许,而且经常被允许要求做任何事,任何事。这是一个很小的公司,根本没有专家。

就这样,我学到了一些基本的设计技巧;我学会了在服务器和数据库之间导航;我对客户端的开发变得相当有信心。

这种类型的多面手开发网站的方法显然有优势:多面手学习每个组件如何与其他组件一起工作。他们发展了对整个过程的理解和欣赏。他们也擅长把事情做好;不需要等待专家为您做数据库工作。

多面手可以用他们的手去做大多数事情,但他们永远不会精通一切.有时候,有一个人粗略地知道他们如何应对某些事情是不够的。

如果你的摇滚乐队成员可以用各种乐器演奏《水上烟》,但没有人可以演奏Slash独奏,或者像约翰·博纳姆(John Bonham)那样打鼓,那么你的演出永远不会爆满。

充分利用专家#第五节

专家是他们所在领域的专家。他们用自己的职业生涯来磨练自己在某一特定学科上的技能,因此他们在这方面会比没有经验的人做得更好,这是理所当然的。

但误用它们会导致团队协作的障碍。例如,有一次,在一家大型软件公司,我的任务是调查为什么我们团队的构建失败。我发现问题在于构建定义中缺少依赖项引用。那么,很容易修复,对吗?只要调出构建定义并修复依赖项,直到我意识到我没有访问权限。我无法直接编辑构建定义,并且被告知我需要一名“配置专家”来实施修复。

本应快速编辑的内容却花了我好几个小时,而我却在等待另一个团队的专家来解决我知道如何解决的问题。不幸的是,这是一种常见的情况:孤立的专家小组被赋予特定任务的独家所有权,而不是与公司其他成员合作。

专家最适合担任他们工作的角色沿着其他团队成员,而不是单独。作为Spotify的Henrik Kniberg说“这就像一个爵士乐队——尽管每个音乐家都是独立的,演奏自己的乐器,但他们会倾听彼此。”

拆墙#第6节

消除高绩效文化的障碍是在整个组织中实现创新的方式。

Adrian Crockroft Netflix

合作是组建团队的最终目标,因为它允许想法自由流动,鼓励创新。创建完全拥有所有权的专家小组,很少或没有跨团队交流,将为协作设置不必要的障碍。那么,我们如何识别并消除这些障碍呢?

打开瓶颈#第7节

我曾经在一家公司工作,那里的多面手开发团队的人数比专家多15:1。当开发人员要求对自动化构建进行修改时,他们必须提交一张通知单,让专家来处理。在某一点上,开发人员提交票据的速度快于专家获取票据的速度,这导致了工作流瓶颈。

如果开发人员能够自己管理自动化构建,那么就可以避免瓶颈。配置团队中掌握的知识可以在开发人员之间共享,从而创建一种更通用的方法,并消除竖井。

要发现并打开自己的瓶颈,问问自己:

  • 过程中哪一部分最慢,为什么?
  • 你是否依赖于一个人来完成所有的前端开发?为什么?
  • 团队中还有其他人有类似的技能,或者有学习这些技能的天赋吗?
  • 限制性的职位头衔会妨碍人们从彼此的技能和专业知识中获益吗?

鼓励沟通#第8节

我见过一些公司,软件测试人员和开发人员是完全独立的团队。测试人员通常只在开发过程的末尾参与,当他们收到一个基于原始需求的测试模块时。但是需求在开发过程中可能也确实会发生变化——当团队完全独立运作时,这可能会导致许多误解并降低生产力。

将测试人员包括在整个开发过程中会改善沟通和性能。相反,由于团队的分离,项目发布受到了影响。

有许多方法可以限制此类部门并促进团队间的沟通:

  • 尝试安排工作空间,让项目团队可以坐在一起。如果他们不能坐在一起,那就确保他们坐在一起至少每天一次关于这个项目的对话。
  • 远程工作是一种特权,但只有在您愿意参与讨论的情况下才有可能。在办公室工作的一个巨大好处是能够走近同事的办公桌,问他们一些问题;远程工作会让人觉得遥不可及。如果您必须远程工作,那么请确保您的同事能够轻松地与您联系。
  • 并列争球是一个很好的鼓励交流的工具,特别是在日常的站立式交流中,每个团队成员描述他们正在做什么以及他们需要帮助的任何问题。

填补技能空白#第9节

你的团队是否缺乏完成项目或高效交付所需的技能?团队是否不熟悉特定的方法或技术?他们是否缺乏成功克服问题所需的信心?利用专家来培训你的员工:

  • 从公司其他部门引进一名专家,或者,如果公司内部没有这种技能,雇佣一名顾问。
  • 不要让专家孤立地解决问题。让你的团队成员有机会与他们密切合作,从他们的经验中学习,并开始培养他们所缺乏的技能。
  • 鼓励您的专家举办研讨会。研讨会也是在专家和通才之间建立互动关系的好方法;他们开放交流,营造知识共享环境。

促进知识共享#第10节

我曾经在一个团队中工作,他们非常重视识别“竖井”。我们被鼓励在整个系统上工作,没有一个开发人员拥有一个特定的领域,尽管人们有他们的偏好——我更倾向于客户端,而一个同事更喜欢web服务。

当我承认我不熟悉公司内部web服务的运作方式时,因为我已经很久没有使用它们了,我的同事和我决定在下一个sprint中交替使用客户端和web服务,从而分享我们的知识。

有很多方法可以促进这种知识共享,这是创新和协作文化的基础。

棕色袋子#第11节

在我现在的公司,我们定期举办自带午餐——每个人自带午餐,同时一位同事就他们感兴趣的话题进行非正式的谈话。自习袋经常会在参与者之间引发有趣的讨论:我记得有几次,一个技术特性或程序在热烈的自习袋之后进入了我们的正式流程。

微软的斯科特·汉斯曼建议这些公司“每月至少举办两次技术大班,并鼓励每个人至少每年参加一次。”这是一个很好的机会,鼓励同事之间进行健康的辩论,你不一定要定期与他们合作。

行会#第12节

在他的文章中在Spotify通过部落、小队、分会和公会实现敏捷扩展(PDF), Henrik Kniberg将协会定义为“一群想要分享知识、工具、代码和实践的人”。Spotify利用工会来弥合组织内部团队之间的差距。例如,一个开发人员可能会遇到组织中另一个开发人员已经解决的问题。重复工作有什么意义?

组建公会可以交流共同的解决方案。这是一个在团队之间分享经验的机会。

在我目前的公司,每个团队至少有一名测试人员;测试人员还属于一个单独的QA协会,该协会允许他们汇集知识。这是一个巨大的成功:测试程序已经在各个团队中标准化,像Selenium这样的技术已经被引入到测试堆栈中。

内部开源模型#第13节

通过引入内部开源模型来限制所有权观念。通过用类似GitHub pull requests的模型替换基于票券的系统,让每个人都可以为你的源代码或设计做出贡献。如果您能够胜任并乐于更改位于另一个团队“区域”内的代码库,那么您为什么不能这样做呢?另一个团队可以通过审查任何代码提交和反馈来作为项目的管理者——但是猜猜是什么?现在你合作!

黑客的日子#第14节

你正在进行的项目是否感到有点乏味?试着作为一个公司参加一个竞赛,或者利用一个创意日让创意再次发挥作用:

  • 安排一个公司Ludum敢在这里,在黑客日结束时表现最好的游戏获胜。
  • 你甚至不需要把它限制在一天之内。Spotify定期举办黑客周. 你甚至可能最终得到一些你可以向企业或客户展示的东西。
  • 国家卫生局每年举办黑客日在英国,鼓励本地数字专业人士参加。他们努力解决由NHS医生和工作人员提出的问题,无论他们手头有什么技术。这是令人难以置信的授权,也是一个绝好的机会来回馈如此重要的组织。

黑客时代不一定与IT有关;通过遵循NHS模式,鼓励开发团队以外的人员参与。黑客日允许人们与他们通常不会共事的同事一起工作,在这种情况下,鼓励新想法,鼓励创新。

合作#第15节

强大的协作对于建立一个成功的团队至关重要,而协作是通过打破障碍来促进的。通过将专家与多面手结合起来,并将他们定位于指导、教学和向团队灌输激情,充分利用他们。

关于作者

加林埃文斯

加林·埃文斯(Garin Evans)是英国威尔士加的夫(Cardiff)的一名开发商。他花太多的时间在电脑前,而没有足够的时间在阳光下。当他在阳光下度过的时候,他喜欢骑自行车和绕着美丽的布雷肯灯塔徒步旅行。他用这个名字发推mrgarinevans

10读者评论

  1. 这是一篇很棒的帖子,你有很多很好的建议来打破学科之间的隔阂。我认为“行会”是破坏这座墙的罪魁祸首专家们的噩梦我曾经在这里工作,我们称之为“社区”,而设计社区通过合作,帮助将设计标准和知识从可用性工程师传播到交互设计师。

    我很想知道你的设计社区/公会和开发者社区/公会之间是否有很多交叉点——这是我个人经历中最难打破的一堵墙。

  2. 嗨,安妮。谢谢你的反馈!我们在跨越开发人员与设计人员之间的鸿沟方面取得了一些成功。

    在我目前的公司里,有想学习开发的设计师,也有想学习设计技能的开发人员,包括我自己。因此,我们自行设立了研讨会,旨在在不同学科之间分享技能;有一天我将举办一个关于JavaScript的研讨会,另一个会议将讨论颜色理论,等等。我发现这些技能交换课程可以很好地弥合这一差距。

    我们也有偶尔的集体黑客,不是黑客日,只是我们一群人聚在一起讨论和构建一些我们在非固定时间内共同感兴趣的东西。最近的一次集体黑客攻击是制作一款益智游戏,我们仍在开发中。这是让设计师和开发人员(当然还有其他部门)一起工作和交流的好方法。如果你发现很难安排一个涉及整个公司的正式黑客日,那么一个较小的团体黑客是理想的,你可以轮换成员以获得更多的曝光。

  3. 事实上,每家公司都需要多面手和专家,就像在医院一样。我,对于我自己,我喜欢认为自己是一个通才。

    另外,一个只由专家组成的公司是很难成立的,你需要一个非常好的管理才能和这样的团队一起前进。

  4. 加林:有一件事需要考虑——关于你的例子,你没有权限更改配置文件——你显然是一个熟练的开发人员,但是想象一下,如果所有开发人员(不管他们的技能水平如何)都有权更改配置。您可能会看到bug的大量增加,并且浪费时间讨论什么是做某些事情的最佳方式,这些人通常不一定知道全部细节。
    我已经在一个类似的船给你,但我很欣赏筒仓,当他们正确实现,没有什么比保护设计或建筑决定别人不懂的全貌,但认为他们应该完全访问改变一切,它可以浪费时间如果不是天。

  5. 嗨JSGuy。谢谢你的评论!在那个特定的例子中,我们最终允许开发人员访问。这涉及到技能提升,这是一件好事;开发人员接受了构建的细微差别的培训,而配置团队作为专家,在培训中扮演了重要的角色。最终,配置团队仍然是构建的管理者;他们定期审查变更,并在变更中断时帮助修复构建,即使是由于开发人员做出的变更;但这种情况很少发生,所以从来都不是问题。总有一些专家比其他人更了解自己的专业领域,但他们没有理由坚持要成为唯一对该领域做出贡献的人。在同事和团队成员之间分享知识将减轻负担,并有助于建立一个更协作的环境。

  6. 嘿,加林,很棒的文章。

    我发现自己在一个类似的情况下,通才技能集,并同意它有它的起起落落。

    繁文缛节会让开发变得更加依赖专家。我认为你提出了一个非常重要的话题,关于开发集成,在当今时代。

    谢谢你有趣的阅读

  7. 很多值得思考的东西。我大部分时间都在一家大型企业工作,身边有很多专家,我既是专家,又是多面手,我曾经有过类似的想法。
    最后,它归结为对言论自由的控制。两者都有其优缺点,取决于相关人员!通常情况下,大型组织会遭受专家造成的瓶颈,而小型组织则会因缺乏多面手主导的专家而面临无政府状态和混乱的风险?这还表现为一方(小型组织)缺乏流程,另一方(大型组织)有太多不切实际的规则。一种平衡的方法似乎是合适的,这取决于组织的规模。。让辩论继续下去,时间来评判!

有什么要说的吗?

我们已经关闭了评论功能,但是你可以看到在我们关闭评论功能之前人们都说了些什么。

更多来自阿拉巴马州

Webwaste

在这篇《世界垃圾》的摘录中,Gerry McGovern研究了臃肿的网站和不必要的资产对环境的影响。
工业

连接这些点

在这篇摘自《创意文化》的文章中,Justin Dauer向我们展示了一个组织的文化和它所做的设计工作相互作用的许多方式。
事业