在我们与Suhail Patel、Hannah Paine、Crystal Hirschorn、Charles Humble和Jamie Dobson的专家小组讨论中，看看DevEx为什么以及如何在资源配置、招聘、保留和创新中至关重要。
》
，作者是Douglas W. Hubbard
《人类工作的多样性
作者是Steven Shorrock博士
小组成员
Suhail Patel - Monzo
Suhail
是云原生银行Monzo的高级员工工程师，
主要负责
建设核心平台。他的职责是建立和维护Monzo的基础设施，它跨越了两千多个微服务，并利用关键的基础设施组件，如Kubernetes，Cassandra，Etcd等。他特别专注于调查偏差行为，并确保服务在面对不断变化的云环境时能够继续可靠地工作。
Hannah Paine - Container Solutions
Hannah Paine是Container Solutions的工程经理。在过去的8年中，她找到了自己的槽点，在咨询业建立了快乐和成功的工程团队。她积极倡导将个人和团队的幸福感作为成功交付客户的首要关键，并在零售业和政府部门的大规模数字转型中取得了成功，展示了以人为本的领导力。
Crystal Hirschorn - Snyk
Crystal是一位经验丰富的软件工程副总裁/总监，在技术行业工作了20年。她的大部分职业生涯都是在媒体、技术和出版部门度过的。15年的软件工程实践经验；在完全转向管理和领导之前，已经达到了首席工程师的水平。
Crystal是一位富有同情心和雄心的领导者，努力为团队的成功创造最佳条件，让他们为胜利立下汗马功劳，并提供一个缓冲区，让他们完成伟大的工作。
他热衷于科技领域的多样性和包容性，在建立多元化团队方面有丰富的经验。
主持人
杰米-多布森 - 容器解决方案
杰米-多布森是容器解决方案的联合创始人和首席执行官，这是一家专门从事云原生转型的专业服务公司。他是一位资深的软件工程师，擅长领导力和组织战略，经常在会议上发表演讲。
杰米还是《 云原生转型
》一书的合著者 。
Charles Humble - Container Solutions
Charles Humble是Container Solutions的主编，也是 InfoQ.com编辑部
的前负责人 。作为一名前软件工程师、架构师和CTO，他曾担任过技术和最近的内容小组的高级领导和执行官，范围从小型初创公司到中型和大型公司，与离岸、在岸和远程团队合作。
文字实录 目录
介绍
WTF is DevEx?
你能给我们介绍一下你的DevEx团队所负责的工具的情况吗？
当创建一个高水平的抽象时，你如何处理像数据工程师这样的更有底层意识的群体的需求？
你如何衡量你所做的工作的有效性？
你们中是否有人有这样的经历：开发人员的看法和实际情况有很大的不同？
你是如何让高管买下DevEx功能的？
你对更广泛的组织问题有什么看法吗？
为开发者体验设立一个专门的职能部门与将DevEx人员嵌入到流向一致的开发团队中的利弊是什么？
你如何看待开发者体验职能随着时间的推移而发展？
完整的文字记录
保管和公告
Jamie:
好的。所有在等候室的人现在都在网络研讨会上。你好。欢迎以前参加过WTFs的人回来，也欢迎今天来的新手。在人们排队等候的时候，因为人们通常需要一到两分钟的时间才能真正来到这里，所以我有几件事情要宣布。也许应该先做一些介绍。我的名字是杰米-多布森。我是集装箱解决方案的创始人，你能相信吗，集装箱解决方案的联合创始人。我们曾经是一家小公司，现在我们已经不那么小了。今天加入我的是我的同事查尔斯。打个招呼吧，查尔斯。
查尔斯：
你好。
杰米：
哦，非常简短。查尔斯将主持今天的小组讨论，这是关于什么是或F是开发人员的经验。我们今天有多少人来自美国，卡拉？
卡拉：
嗯，实际上几乎有一半的注册者。所以是的。
Jamie:
你看，当我们有来自美国的人时，这决定了我们可以说多少脏话。
Carla:
不！
Jamie:
因为如果我们说正常的脏话...总之，所以我就说一次。这他妈的是什么？什么他妈的是开发人员的经验？我现在已经做了。我已经做了，把它说出来了。当然，我们今天还有我们精彩的小组成员，苏海尔、水晶和汉娜。
好，
汉娜：
你好。
水晶：
你好。
杰米：
欢迎、欢迎、欢迎。我想这是你对WTF的第一次体验。祈祷吧，并做个十字架的手势，希望这不是你的最后一次，希望你喜欢这个，我们会再见面。好的。同时，在我们准备的时候，我们有一些内务工作，一些公告，然后我们有一些八卦。卡拉，今天谁来给我们讲讲八卦。
卡拉：
好。我们有罗德里戈和朱利安。
杰米：
来自集装箱解决方案的罗德里戈和朱利安将为我们带来八卦。我希望它是好的。我想知道它是否与英镑价格下跌和我们本周在英国发现的政治灾难有关系。宅男。我们有一个行为准则。Carla现在会把它发布到Slack频道。因此，总的来说，我们的行为准则是，我们需要尊重和注意彼此以及我们所有的不同意见。我们确实在执行该行为准则。因此，任何违反行为准则的行为将被迅速和明确地处理。如果你正在举办活动，你想为你自己的活动制定一个行为准则，请随时盗用我们的。你可以使用它，你可以编辑它，或者你可以与我或卡拉离线交谈，我们将看看我们是否可以为你指出正确的方向。
杰米：
如果我们要维持，创造和维持安全的空间和我们都有责任建立的技术社区的环境，我们必须认真对待这个东西。而你们知道，我们确实是这样做的。还有什么内务吗？是的，问题请到聊天室。查尔斯稍后将在我们进入小组讨论时主持。但任何问题或澄清，请直接提出来。我们会在聊天中回复你，或者如果它是更广泛的辩论的一部分，我们会在那里与你交流。当我们通过八卦和公告时，我们将在聊天框中分享所有链接。请自由使用它们，在推特上发布，等等。卡拉，我错过了什么大的内务吗？
卡拉：
两件事。
杰米：
两件！
一个漫长的夏天。
Carla:
嗯，第一件事是，显然，正如你所看到的，这次会议被记录下来，视频将被上传到我们的YouTube频道，链接在聊天中。
Jamie:
是的。是的。所以，如果你有什么问题，现在就告诉我们。如果你不想被看到，你可以关闭你的摄像头。如果你忘记这样做，让我们知道，我们可以为你提供像素。如果你对被记录有真正的问题，那么你可能应该离开网络研讨会，然后在回放中观看。
Carla:
第二个问题是，我们有现场转录，所以你也可以跟随字幕直播。
Jamie:
现在，现场转录是人工智能，不是吗，Carla，它帮助那些有听力障碍或失聪的人。
Carla:
没错
Jamie:
问题是，它可以处理我的约克郡口音吗？因为Siri非常吃力。所以这对我们今天使用的转录服务是一个很好的测试。好的。谢谢你的帮助。对。接下来是公告。所以，WTF是一份通讯，是一堆网络研讨会，是一堆会议。我们不是一个垃圾邮件公司。因此，你可以订阅通讯，你可以消费所有的内容，而不会收到销售会议的要求，也不会被问及你是否想要这份工作或类似的东西。如果你对这些东西感兴趣，只需点击方框。我们对不向加入我们数据库的人发送垃圾邮件感到非常自豪。因此，你可以自由地这样做，而且我们让你以后退订非常容易。
杰米：
但如果你错过了所有最好的内容，不要哭。曾经发生在我身上最好的事情是有人非常生气，因为他们无法获得内容，但他们不想订阅通讯。我就说，好吧，这就是为什么我们有这个订阅服务。而我们所有的东西都是免费的。我们所有的东西都是免费的。没有付费墙或类似的东西。而且很多都是由社区推动的。因此，一些贡献来自于我们，但很多是由我们的行业朋友带来的，有时是独立作家，等等，等等。说到WTF，我们将在明年举办我们的SRE会议。
Jamie:
如果你们有人记得在大流行病的黑暗深处，我们实际上与Nathan Harvey举行了一次网络研讨会，它被称为 "什么他妈的是SRE?我们得到了大约700个网络研讨会的报名者。这给了我们一个想法，如果某些东西是有效的，就不要改变它。这给了我们一个想法，让我们在12周后做一个会议，我们做到了。因此，很偶然地，我们发明了一个会议，被称为 "什么是SRE"？对我来说，这里面有太多的字母了。SRE是什么？我们将在2023年再次举办这个会议。如果你不介意按照那个二维码或聊天框中的链接，并让我们知道你对什么感兴趣。我们将定制内容和议程，以确保每个人都得到他们需要的东西。因此，如果你填写这个问卷，我们将能够为你举办一个更好的会议。
杰米：
集装箱解决方案是一个了不起的公司。它真的很了不起。我们的管理团队由40%的女性高管组成，60%的男性。这是一个数字，介于60/40之间，我们正试图在整个组织中实现这一目标。它是多样化的。
我们很擅长我们的工作。每个人都喜欢我们。我认为每个人都喜欢我们。我认为这是一个公平的声明，我可以坚持。哦，你好？一个异议者？队伍中的异议者。有人说我不爱你。我只是去看免费的内容。总之，这是一个可爱的公司，如果你想来和我们一起工作，我们有各种东西在做，特别是阿姆斯特丹的工程经理，尽管我们实际上是一个完全远程的公司，云原生工程师。但我们也在寻找两名国家经理。这将在未来几天在互联网上发布。一个是帮助领导我们在加拿大的业务，另一个是领导德国的事情。如果你对这些职位感兴趣，可以和我说，也可以和卡拉说，或者在职业网页上找找看。在这个快乐的音符上...哦，八卦幻灯片在哪里？我们错过了八卦幻灯片。
卡拉：
它应该在那里。
什么是八卦？
杰米：哦。哦，不。流言蜚语的幻灯片有...哦，它在那里。现在，什么是八卦？这是我们在12个月前、14个月前曾经试验过的一个功能，我们不确定它是否会成为一个赢家。而它是一个赢家。因此，每次我们举行网络研讨会时，我们现在都有一个八卦部分。而问题是，谁在做第一篇八卦？是朱利安还是罗德里戈？
卡拉：
罗德里戈。
杰米：
罗德里戈。你好，罗德里戈。欢迎，
罗德里戈。
我就是那个人。我希望它足够好。那么--
杰米：
你有什么八卦消息给我们？
罗德里戈。
是的。那么，令人震惊的是。所以Heroku正在取消免费访问层。对于那些不知道的人来说，Heroku是Salesforce的子公司，平台即服务帮助许多人进行DevOps，云工程师部署服务，允许人们建立和运行应用程序。而且你可以想象到像Go、Java、PHP、Scala这样的一切。因此，在提供了10年的免费服务之后，Heroku把用户推向了付费计划，这该怪谁呢？好吧，经常有人滥用免费的计算层来进行欺诈活动，如挖掘加密货币和建立网络钓鱼网站。你猜怎么着？这就是案例，不幸的是，欺诈和滥用。甚至还有公司的员工因为在工作中挖比特币等事情而面临一些后果。这很糟糕，对吗？因此，该公司在他们的博客中正式声明，引用如下："我们的团队正在花费巨大的努力来管理Heroku免费产品计划的欺诈和滥用。为了将我们的资源集中在为客户提供关键任务的能力上，我们将从2022年11月28日开始逐步淘汰我们的免费计划，并删除不活跃的账户。"这真的很糟糕。
杰米:
公地的悲剧。我们有一些东西可以分享，可以供大家使用，而那些挖比特币的人却把别人的东西给毁了。好吧，那么他们已经做了10年了，免费服务。在Salesforce收购他们之后，这些服务有多少年是免费的？Salesforce的收购和这个有什么关系吗？
Rodrigo:
我认为这有关系，因为现在他们在这个领域有一堆竞争对手。但是，滥用计算机的事情，真的是......哇。我提醒当他在以前的工作中有一个客户，电脑被劫持了，他们正是因为密码不严密而在他们的服务器中做这种挖比特币的事情。所以
杰米:
如果我们当时知道今天的情况就好了，对吗？在这个快乐的话题上，朱利安...谢谢你，罗德里戈。朱利安，第二件八卦。顺便说一下，我喜欢Heroku的八卦。我认为那是一个很好的消息。
朱利安：
当然，嘿
所以，对不起，这不是一个八卦，像上次一样，但我还是要谈谈我认为人们应该知道的东西，以防他们感兴趣。因此，今天的网络研讨会是关于DevEx的。关于DevEx，我们通常不考虑的东西是它的个人方面。所以我在这里想的是你工作的地方的人体工程学，以及你如何直接在计算机上工作。因此，关于人体工程学，我们通常考虑的是椅子，所以可调节的，有可调节部件的椅子或站立式办公桌。但我们通常不考虑的是键盘。键盘实际上是一个非常重要的设备，在几年前，很难买到真正的符合人体工程学的键盘，而且价格也不便宜。但是现在，你可以用非常公平的价格拥有这种东西。我将给你一个这样的例子。你真的可以去看看。
Julian:
Keyboardio Atreus，它有一个分体式键盘的形状，但它是一个一体式的，所以你的两只手之间有一种角度。这里的想法是真正让你的手尽可能的直。特别是作为开发人员，我们在复制和粘贴时使用了很多控制键和其他移位键，而小指，我们一直在使用我们的小指。我不知道是否有人在使用过程中或在另一侧有过这种痛苦。但是这个键盘，比如说，在大拇指周围有更多的键。所以像这样，你避免了所有这些奇怪的动作，你使用你的实际手指，是在右边的力量。所以这是它的一部分。和这个一起去...由于这一点，你也可以有一个真正的定制体验，因为你真的可以自己编程，你的键盘，无论是用GUI还是用QMK，也就是写自己的...那个痛苦。我同时还在看聊天记录。所以痛苦是针对每个人的。
朱利安:
所以另一部分...这里的想法是，你可以根据你自己的需要定制它，因为我们都是个人，我们没有所有相同的需求。我想提到的另一部分是，你实际上可以为你的开发环境拥有相同的ID。这是一个被创造出来的术语，即个性化的开发环境。它是什么呢？这是同样的想法，即我们都是个人，我们实际上可以有一个为我们自己的需求量身定做的开发经验。因此，对于这一点，我只想提一下，现在有一种叫做Neovim的东西，这是一种非常好的技术，是完全开源的。如果你觉得它太多了，你不想花太多时间在上面，有一个它的分叉叫LunarVim，它是Neovim的一个有意见的、可扩展的、快速的ID层。因此，所有这些都是说，你也可以真正地个性化你的体验，以获得你想要的最佳时间，并在一天结束时不那么累。
杰米：
绝对是真棒。是的，你的开发者体验确实延伸到你的物理环境。但是，现在所有的年轻人都在使用的那些咔哒咔哒的键盘呢？
杰米：
它毁了我的工作经验
朱利安：
这是我正在谈论的键盘定制的一部分。
杰米：
对。
朱利安：
你可以选择键盘的形状，但你也可以选择按键的形状，你也可以选择当你按下它们时按键的反应方式。所以你可以有一些...取决于你的手指。因为我们都有不同的手指，有不同的重量，我们实际上可以为你选择合适的弹簧。
杰米：
非常好。好的，那是非常非常有趣的。我不知道这一点。所以在聊天框里有其他开发环境的链接。现在，感谢朱利安，感谢罗德里戈。就在这时，我将移交给查尔斯。掌声送给查尔斯和小组。我们将开始讨论什么... ...哦，哦，哦。喂？开发者体验的下一步是什么他妈的？欢迎来到WTF。
小组讨论
介绍
Charles：
，很好。非常感谢你，杰米。所以我确实喜欢让这些会议具有互动性。我们已经提前提交了很多问题，所以我会尽可能多地回答这些问题。但请继续在聊天中提出问题，我们也可以把这些问题提交给小组。也许你可以先告诉我们你对DevEx感兴趣的是什么，也许你的背景是什么，因为这真的有助于我们构建对话。当你这样做的时候，我将请三位小组成员介绍自己。苏海尔，也许你可以开始我们的讨论。
苏海尔。
是的，当然。非常感谢你的邀请，也感谢所有加入的人。嗨，我的名字是苏海尔。我在一家叫Monzo的银行从事开发者体验工作。我们是一家位于英国的银行，有超过600万的客户。对我们来说，开发人员的经验是非常非常重要的，因为如果你考虑到传统的银行架构和诸如此类的事情，你必须非常可靠、安全和可靠地部署系统，而通常这需要非常缓慢和非常繁重的部署过程。
苏海尔。
许多在银行工作的人都非常熟悉六个月的准备时间，以便将任何变化发布到任何类型的生产环境中。变更审批委员会是很多的，有很多的人工审查和类似的事情。从本质上讲，我们的目标是消除所有这些，尽可能地将其自动化。我们现在的情况是，我们每天要部署数百次。当我与其他公司的同行交谈时，他们想知道有什么系统性的方法来达到这个目的。我不敢说没有银弹，但我想这将是小组讨论中的一个话题。是的，这就是我。
查尔斯：
很好。非常感谢你。汉娜，你可以做一下介绍吗？
汉娜：
嗨。早上好，下午好，也许对某些人来说是晚上好。我的名字叫汉娜。我是集装箱解决方案公司的工程经理。在此之前，我是以发布经理的身份生活的，我是交付负责人，所有的事情都在这两者之间，但我不是工程师，也没有当过工程师，这对一个工程经理来说是一个很不寻常的位置。我认为这无疑给我和我的团队带来了不同方面的开发者体验的意义，所以我真的很高兴今天能多谈谈这个问题。
Charles:
太棒了。谢谢你。Crystal.
Crystal:
你好。谢谢你今天邀请我。另外，我只想说，如果有任何欢呼声，销售部门的人就在这里了。现在是本季度的最后一周，所以他们有点疯狂。我可以听到他们的欢呼声，这是件好事。所以我是Snyk的工程总监。我负责Snyk的基础设施组，今天由三个团队组成，即云平台、网站可靠性工程和开发人员体验。我实际上得到了我的工程经理弗拉德，今天在电话里，我已经看到了。所以打声招呼吧。他是DevEx的工程经理。
Crystal:
我为什么在这里？我一直是一个长期的工程师，所以我已经做了20多年了。在所有类型的工程中都工作过，但最近对运营、平台工程、基础设施和开发人员经验更感兴趣。我想这是...我以前也做过一些关于开发者体验的这类事情。我认为这是一个广泛的话题，而且它可以...这是个模糊的东西，对吗？开发者经验，它可以是任何东西，任何事情。因此，如何将这样的团队带入一个组织并使其成功，对我来说，是我真正想要成功的事情。并很高兴与这个团队分享我们在Snyk所做的事情。
什么是DevEx？
查尔斯：
那真是太好了。谢谢你。正如你所说，这是一个非常广泛的术语，我想也许我可以请你们每个人给我们定义一下你们所认为的DevEx，也许还包括一些我们使用的相关术语，如工程生产力、开发人员能力等等。实际上，在注册表中也有一个问题，那就是开发者体验和DevOps之间的区别。所以，也许我们也可以谈一谈这个问题。水晶，你想继续这个问题吗？
水晶：
抱歉。因为所有的欢呼声，我把自己调到了静音状态。所以，当我去建立这个团队时，这是我的小组中的第三个团队，所以它是最后一个形成的。他们已经进行了大约，我不知道，大概有六个月左右的时间。但是，我总是从章程开始，对吗？这真的很重要，要确定下来。很多人可能会说，把DevEx放在一个infra小组里是一个奇怪的地方，我认为，正如我对那个团队所说，这有点随意。这只是或多或少我有这样的团队的背景，但这也是我希望我们为公司建立的东西。说实话，在我看来，随着时间的推移，它可能会成为自己的部门，自己的小组。
Crystal:
而这往往发生在那些在这方面比较成熟的组织，比如GitHub，你在那里谈论诸如工程生产力的事情。他们有整个部门围绕这个问题，由几个团队组成。但这不是我们的情况。我们是一家初创公司。我们现在有7年的历史，这是我们第一次涉足这个领域。我认为对我来说，对公司来说，这真的很重要，我们今天在Snyk有300名工程师，也许现在比这更多一点。而这是试图像量化和限定他们什么是开发者经验。因为，就像我说的，这就是一切，对吗？开发者体验无处不在，它存在于堆栈的每个部分。之前有人谈到了人机工程学，比如说这有多远？然后我们也有像运营这样的事情。
更多的事情，比如产品运营，以及如何将其融入事物的整体图景中。
Crystal:
所以对我来说，我不认为
所以我随便说了几个词，我想到了像你说的使能、生产力等东西。但我认为它有所有这些东西的元素，我觉得称它为生产力或赋能可能不是我想去的角度。我希望它被称为开发者体验，因为它就像我们如何带来那种快乐，以及那种日复一日的，我们如何为工程师带来生活质量的改善，并为他们不断地向前推进？
因此，这取决于那是什么，以及如何解决这个问题。
Crystal:
因此，这需要一个整体的系统思维方法。因为有时我们可能会关注CI管道和它的速度。这就是我们在Snyk所做的事情...我可以围绕DORA指标和我们跟踪的方式做更多的介绍，但我们在这个过程中发现的一件事是，实际上公关生命周期是导致紧张的事情。它是让人们把目光放在PR上并完成审查。这实际上是需要时间的事情。因此，这也是试图发现非明显的摩擦领域，并随着时间的推移减少这种摩擦。我就说到这里吧。
查尔斯：
苏海尔，你想加入吗？
苏海尔。
是的，当然。我非常同意Crystal的定义，这也是我们在Monzo采取的方法。对我们来说，开发人员的经验是一切，从作为一个工程师的人体工程学，你使用的工具，编辑器和类似的东西。对我们来说，为了安全、审计和合规等目的，实现标准化是非常重要的，但我们给工程师足够的自由，让他们出去实验。如果你问很多传统公司和我工作过的公司的工程师，甚至在过去的创业公司，每个工程师都有他们的快捷方式文件夹，脚本文件夹或其他东西，以使他们的生活更容易。这些东西通常通过口口相传或隐藏在GitHub gist或Slack附件或类似的东西中。我们怎样才能把这些东西变成整个组织可以采用的成熟工具呢？
苏海尔。
开发者经验甚至可以超越工程师。例如，有一些问题是工程师经理想要回答的，工程领导想要回答的，诸如此类的事情。我们怎样才能让他们也能参与进来，而不需要花一大堆时间来设置他们的整个环境，并在本质上做所有的努力来成为一名工程师。对我们来说，我认为这也是一个相当早期的功能，尽管我们已经走过了与Snyk非常相似的时间。这是一个相当早期的功能。我们已经加快了围绕部署和优化CI管道以及诸如此类的事情的标准化进程。
Suhail。
但我认为它也超出了这个范围。因此，例如，你如何在你的IDE中工作？如果我们已经围绕特定的语言和诸如此类的东西进行了标准化，那么我们如何才能使编程变得更加快乐？所以，例如，我不知道大家是否玩过GitHub Copilot，它就像一个自动建议的编辑器体验。很多人安装了它，我们就像，这很神奇。它可以根据我在编辑器中输入的内容自动完成我的代码。我们怎样才能在我们的规模上，在与我们相关的规模上，给工程师带来这种快乐？我们想把这种火花带回给工程师。
苏海尔。
我确实想谈谈你之前提出的关于DevOps和开发者体验之间的区别的一个观点。DevOps本质上是将这种快乐带入运营。所以，如果我回顾一下过去，如果你想以运营的方式做事，如果你真的很久之前，人们都在用Bash脚本黑客攻击，并试图编写他们自己的定制自动化和类似的东西。SSH进入服务器和诸如此类的事情。而DevOps运动已经使其明显更加自动化，明显更加迭代，你可以分享的东西，你可以依赖的东西。围绕着整个基础设施空间已经有了一大堆的工具。因此，它几乎是把开发者经验的乐趣带入了运营的世界。所以我基本上把它看作是运营世界的一个子集。
Charles:
这很好。谢谢你。汉娜。
汉娜：
是的。很高兴我们都达成了一致。这使它成为一个相当好的环境。我认为，正如Crystal所说，全面的方面是关于改善生活质量，而不仅仅是你的技术系统、工具和流程。对我来说，DevEx是我们如何让我们正在做的事情变得更容易，让工程师有更愉快的体验。什么是什么并不重要。它可以是一个产品，可以是一个项目，它是任何重点。它为所有下游的工程师减轻了认知、情感和能力方面的压力。我认为这就是目标。而且，这不仅仅是使能的问题。它也是关于享受，正如我们都提到的。这是关于享受你正在做的事情，正如朱利安提到的，就像你的物理设置一样。你的键盘发出的声音是否给你带来快乐？还是给你带来愤怒？在这种情况下，需要解决。我认为从DevOps和DevEx的比较来看，对我来说，DevOps是一种功能和一套流程，侧重于改善工程工作的端到端交付。DevEx对我来说更上一层楼，更广泛地看待DevOps的人的因素。
你能给我们一个感觉，你的DevEx团队负责的工具景观吗？
Charles:
是的。我认为这很好，实际上。谢谢你。在聊天中，有很多关于将快乐引入工程工作的想法的评论，所以这似乎真的得到了人们的共鸣。你能给我们介绍一下你的DevEx团队所负责的工具的情况吗？苏海尔，也许你可以谈一谈这个问题。
苏海尔。
是的，当然。对我们来说，这种团队中常见的是围绕持续改进和持续交付、测试管道、围绕部署的东西，以及类似的东西。但实际上，我认为现在的情况是，更倾向于围绕你的系统和服务的可观察性。所以，不是在谈论指标和日志，不是在你的系统运行时的可观察性，而是可观察性，比如你的系统是如何运行的？文档在哪里？你如何做服务发现？你如何确定一个端点的存在，以及它是内部还是外部？你应该如何调用它，你应该如何对它进行授权，以及诸如此类的事情，这些事情通常是松散的文档，使其更加结构化。你在Backstage这样的系统中看到了很多，比如说，它就像一个服务发现式的工具。我看到它越来越多地渗透到其他空间，如机器学习和类似的东西。存在什么样的模型？它们是在什么基础上训练的？以及类似的事情。
苏海尔。
我已经提到了文档，带来了结构化的文档，包括从API规范中生成的文档，但也带来了围绕文档工具的某种一致性，以鼓励更好的文档和更多地执行某种结构，特别是随着组织复杂性的增加。是的，它就像一个所有这些不同功能的集合体。我讨厌把它描述为像其他团队一样。它不只是一个抓包的东西。所有这些都是围绕着使一个大型组织内的工程师的组织复杂性降低。因此，我认为一个自然的问题是，你在什么规模上开始发展这样一个功能？一旦你开始确定所有这些不同的领域都在试图解决同样的问题，那么开始启动这种功能并对一些工具进行标准化，以便你可以从组织的角度受益于所有这些优化，这确实是有意义的。
查尔斯：
水晶，也许，你想加入吗？
水晶：
是的，当然。我只是想扩展一下你说的最后一点，苏海尔，关于......。我认为很多公司在达到一定的规模和成熟度之前都不会这样做。因此，我确实认为50岁以下的工程师，我不认为我们真的需要一个专门的DevEx功能。当你达到100人左右的时候，这时流程和技术以及与之相关的原则，在保持这些东西被编入你的工具和平台的方式方面提高了标准，我认为这时就开始出现了很大的问题。我认为汉娜也提出了一个观点，这不仅仅是关于工程。它在很多方面也是关于产品的。如果你有程序和项目管理，这些功能如何在更大的点和规模上跨职能合作，当你作为一个组织经历这些拐点时。
Crystal:
所以这就是为什么，对我们来说，这是一个正确的时间来做。我希望它能早一点完成，但这是我们开始看到破绽的地方。就DevEx团队目前所做的事情而言，这是很相似的。任何与CI/CD管道有关的事情都在他们的职权范围内。因此，我们使用Circle CI或GoCD的事情是一种关键的事情。因此，你可以从这一点推断出，我们在Snyk主要使用Kubernetes和很多Helm。事实上，在即将到来的这个季度，DevEx的其中一件事是我们在云供应商之上为工程师建立了一个内部运行平台，我们正试图为工程师创建一个更高级别的API。因为现在Helm图表和设置在repos中的YAML文件，就像，好吧，现在我需要知道所有这些关于基础设施的东西。
Crystal:
而这就像，不，不，不，不，不。有300名工程师，他们不应该真的对任何事情都了解那么多，对吗？如果我们到了最好的地方，也就是Heroku的事情，这就像我只是想旋转一个服务。我真的不关心这个。我只想要好的默认值。我想让你告诉我什么是最佳做法。只是为我做这件事。这就像90%的情况，甚至是95%的情况。因此，这就是我们的目标，就是创建更高级别的API，然后从它的后面获得服务模板。然后，这就是你可以谈论像Backstage这样的东西，它是我们在Snyk试图推动的技术平台的关键部分。为什么Spotify的这个项目如此有趣，也如此重要，因为我们可以从中推动这样的事情。
Crystal:
这就像好吧，我们有一个好的API。让我们把服务搞起来。如果你有一个特定的需求，那里也有可扩展性点，所以你可以说，好吧，我需要一个特定的数据库资源，我需要它被配置成这样。因此，工程师们仍然有能力对他们正在做的事情进行一些控制，在他们感到舒适的地方。我认为这也是关键的一点，在那里他们感到舒适。这就像组织必须经历的一整套成熟的步骤。这只是一件事，对吗？因此，这就是我们现在正在经历的事情。而且，是的，我想...我还能说什么？
水晶：
，我在想他们还拥有什么。有很多东西，但 "后台 "是我们在未来这个季度关注的关键之一。而这更多的是将供应商的技术。所以它不像 "不是在这里发明的"。我们试图非常谨慎地对待这个问题。因此，这就像让我们使用已经在工作的东西，并使其成功。甚至把这些东西带入，像记分卡或技术洞察力，因为它们被称为。因此，我们如何能够在组织中推动某种程度的问责制，并将数据交给每一个团队来处理。因此，记分卡是很了不起的。所以，如果你对这个不太了解，我会说看看后台，看看记分卡。这是我们在Snyk未来几个季度的主要重点。我就说到这里。可能还有其他我完全错过的他们拥有的东西，但这就够了。
当创建一个高水平的抽象时，你如何处理像数据工程师这样的更有信息意识的群体的需求？
Charles:
不，那很好。谢谢你。
一个相关的问题，来自Pavel Brodskym，如果我读错了你的名字，请原谅，那就是当创建一个高水平的抽象时，你如何处理像数据工程师等更多有内在思想的群体的需求，他们需要有90-95%的快乐路径之外的控制？
Crystal:
是的，当然。我的意思是我可以快速回答这个问题。因此，当我们建立这个平台时，我们从一个观点来看待它，就像它有很多层。所以我们想出了五个层次，当然，零层是指你如何获得一个账户，以及围绕账户的基本情况和云供应商本身的组织结构。
Charles:
Mm-hmm.
Crystal:
我们最终会在这个过程中加入像GuardDuty和类似的东西。然后你有像网络一样的东西，一直到应用程序，对吗？所以在这些层的每一个点，都有扩展点。因此，我说的一件事是...我们最近有一位工程师需要MongoDB资源，但云平台还没有为我们的平台创建这种资源。但是这个人是有信息背景的，所以我们就说，你想写一些Terraform吗？我们就说这是我们的游戏手册，然后他们就走了，在两天内就完成了，然后他们在一个演示中告诉研发部的其他人。就像这是我们做的事情。好啊。如果你觉得这样做很舒服，那就超级简单，超级快。但是，我们当然不会期望工程师们这样做。
Crystal:
所以我认为我们还没有触及的一件事是能力。你可以建造很多东西，但对于DevEx团队来说，就它应该如何看待自己的能力而言，有很多东西需要教育、配对、咨询、文档编写。因此，我们试图确保为这样的活动留出一定数量的能力。事实上，我的整个小组都是如此。但这是我们管理的一种方式，就是如果你不舒服，这是我们可以帮助你的方式，让你在我们的平台上走上铺平的道路。
查尔斯：
，这很好。谢谢你。汉娜，你有什么要补充的吗？
汉娜：
我真的很喜欢这个层级的想法，因为我所看到的最大的挑战之一是，无论是在一个大规模的公司还是在一个正在经历规模扩张的公司工作，都会认为什么是对自主权的侵犯，而什么是促进者和减轻认知负担？文化对这一点也有很大的影响，所以你的独立文化是什么。我认为从DevEx的角度和基础设施的角度来看，它只是没有被视为足够性感。我不明白为什么，因为我认为它很好。但根据我的经验，性感的工作往往被认为是应用开发。因此，当我们谈论限制和自主权时，把负担从不得不考虑我们如何获得甚至部署一个应用程序的问题中解脱出来，一般来说效果还不错。标准化，教他们如何...这是我认为DevOps很好的地方。教导软件和应用程序级别的开发人员如何使自己达到适当的程度，使你能够将标准化与授权和自主权结合起来。
Charles:
谢谢。苏
海尔
？
是的，我完全同意Crystal和Hannah提到的一切。它不需要是限制性的，但我认为有一个小小的例外，那就是很多时候，这些团队专注于5%的边缘情况，而不是为95%的情况进行优化。而你最终会出现这种情况，没有人能够获胜。我认为为95%的情况进行优化很重要，正如我在聊天中提到的，许多工程师并不关心运行基础设施。他们想呆在铺好的道路上。因此，如果你让铺好的路尽可能的迅速，并允许在必要时在铺好的路上增加延伸点...一个开发者体验团队并不是在泡沫中工作的。就像汉娜提到的文化一样，这就是文化真正发挥作用的地方，人们觉得他们有自主权为开发者体验做出贡献，因为他们每天都在实地使用它。
苏海尔。
他们就是那些人...我看到的一件事是，从事开发者体验的团队，他们可以做尽可能多的用户研究，对吧，但他们没有真正感受到其他工程师在现场的感受，他们在现场感受到的挫折，特别是当他们在开发和部署应用时。因此，获得良好的理解，并允许其他工程师做出贡献，给他们提供指导和咨询，正如Crystal所提到的，以便在必要时增加他们自己的扩展点，并在铺好的道路上延伸，这是一个全球性的努力。我认为DevEx团队主要是维护这一全球努力。因此，对他们来说，这都是为了确保他们添加的东西能够继续支持，以及类似的事情。有一个集中的团队，但他们不是万能的，也不是万能的。他们不应该是看门人。
应该是推动者。
Hannah:
是的。补充一点，看门人而不是助推器是绝对的，正是如此。我认为还有一个因素是，你如何使DevEx团队获得成功？我看到它工作得非常好的地方是，它几乎被视为有最终用户的产品，你必须有一个产品经理，他走出去，收集需求，了解如何确定优先次序，与你的技术领导合作，以了解我们在哪里得到了快赢与实际上这是一个更大的部分的平衡，然后沟通。
汉娜。
所有的责任就像你去johnlewis.com买一个产品，作为结账的产品负责人，你的责任是了解，我的人结账需要多长时间，我怎样才能改善？我们在幕后需要做什么？我们可以在前面做什么？我们如何沟通这些变化？我们如何试用它们？我们用什么来衡量成功？这就为你的DevEx团队的成功奠定了基础，因为他们也是工程师，所以也要兼顾。当你的DevEx团队的首要任务是为下游的人们提供良好的体验时，你如何为他们制定一个好的DevEx。
你如何衡量你所做的工作的有效性？
Charles：
我认为这真的很有趣。我们有很多关于DevEx团队如何验证他们所做的工作的问题。因此，你如何衡量，你衡量什么，你如何衡量你正在做的工作的有效性。我不知道。汉娜，也许你可以从这个问题开始？
汉娜：
，我认为从咨询公司的角度来看，这也是一个非常具有挑战性的问题。我认为[听不清 00:41:38]也问了一个非常好的问题，与此相关的是平衡我们如何让我们的工程师有一个美好的体验，但我们的用户需要什么，就像在下线？我们的客户想要什么和需要什么？我们在什么范围内工作？这就是我发现在DevEx中关注非工具性优先事项的重要性。
Hannah:
因为我不一定能控制我的客户使用什么。我不能控制他们的流水线是怎样的。但是，我们可以影响的是开发人员体验中的其他方面，这可以成为一个积极的环境。这是我们作为一个咨询公司的内部流程。这是你提供的心理上的安全。这是你在家里的物理设置。但是，是的，我的意思是我们正在谈论很多关于快乐的事情。作为实用主义者，它并不总是带来快乐。因此，你如何能在你控制的范围内减轻负担？在咨询业，这是一个非常、非常具有挑战性的领域，你只需要希望你在客户内部也有一些积极的文化影响。但并不总是如此。
查尔斯：
好吧，水晶，你之前提到了DORA指标，在谈话中提到了很多。那是你开始考虑衡量的地方吗？
水晶：
那实际上是团队作为一个团队在一起时做的第一个项目。他们最初是从云平台中分离出来的，所以这就是它孵化的地方，然后有足够的人在DORA中创建这个团队。所以我认为这是一个有趣的项目，谈论的是有趣的事情，做的是更多的实验。以正确的方式启动团队，以及他们应该长期承担的那种心态。我们看了一些平台，我不打算给它们抹太多的黑。但我们看了像Velocity、Code Climate Velocity这样的东西，我发现Velocity的问题是我想试一试，在以前的组织中也看过，但我只是发现它真的令人难以承受。我在Snyk的不同小组中走来走去，试图解释它可能带来的东西，而大量的问题，它只是..
水晶：
，有时一些小组会问我一百多个关于他们正在看的问题，我想这不可能是好事。但它也...另一件事是，当你在谈论测量时，你必须...让我对这个平台有点失望的事情之一是，它似乎暗示工程经理可以用它来衡量业绩，比如说业绩评级。这个人每天做多少次提交？或者有多少PR？我觉得不，不，不，不。所以你必须非常小心，这不是你要带入组织的文化，因为那会立即扼杀它。所以对我们来说，这不是个人的事，而且无论如何，衡量的单位是团队。它不是个人。所以这应该永远是这样的。但我们想把它看得更高。回到苏海尔之前说的，对我来说，这也是为了让工程领导和产品领导在季度计划中做出更好的决定和权衡。
水晶：
人们谈论技术债务，这是非常模糊的，而且不是非常可量化的。这就好比说，这里有一些关键绩效指标，这里有一些措施，可以告诉我们今天的事情在哪些方面出现了严重的问题。发现的一件事是...这就像我们对事情也有一种直觉，我们的CI管道...要解释的是，Snyk有一个单体架构，我们正在将其分解，就像公司可能做的那样，并转向面向服务的架构。但我们已经有这样的感觉，我们的管道只是......它只是围绕着那个单片机。这很糟糕。但把一些实际的数字与之对照是很有趣的。此外，量化什么是失败案例和成功案例也很有趣。所以我们说，好吧，如果从我们对失败的定义来看，它在第一次构建时有80%的时间是失败的。然后我们在图表中分解了原因。
Crystal:
所以任何人都可以去看，但我们也可以说，好吧，这个单片机与它之外的任何其他服务相比，这看起来像什么，并做很多侧面的比较。这真的很有用，因为它说，好吧，在整个研发过程中花费投资来打破单体是有很大价值的，这就是我们将看到的投资回报。所以这就是问题所在。作为工程师，我们如何用商业语言说话，基本上？我们如何能够量化并倡导我们想要做的工作？因此，能够将一些措施与之相对应是非常重要的。我们一直在关注这个问题。
Crystal:
我认为让我有点吃惊的是，当你读到《加速》一书中关于DORA的内容时，他们研究了如此广泛的行业，我在说，哦，我们应该把四分位数放在那里，看看我们与行业的比较情况。因为我在想，哦，我们没有跟踪得那么好。但是，如果你每天向生产推送代码超过一次，你就已经在最前面了。我当时想，好吧，也许我们需要把它移到我们认为应该的地方，因为我们是一家年轻的云原生公司，我们每天向生产推送60到70次。这个数字应该是多少，而书中告诉我们应该怎么做？这是一个有趣的收获，但只是在我们做了大部分的项目之后才发生的。
Charles:
是的。苏海尔，在衡量你所做的事情的影响方面，你在Monzo是怎么做的？
苏海尔。
我认为已经有...听到Hannah和Crystal的观点很新鲜，因为我们曾多次尝试非常客观地衡量开发者体验的影响，但恐怕我们总是失败得很惨。你会得出一个很自然的结论，即这是一个相当主观的衡量标准。例如，如果你和很多工程师交谈，尤其是在谷歌工作过的人，他们会对谷歌的内部工具赞不绝口，对Facebook等公司也是如此。但是，当你要求他们指出任何一件特定的事情时，他们就会说是一切。一切。他们谈论的是幕后的一切。因此，对我们来说，这在很大程度上是基于直觉，正如水晶提到的。直觉和我们想要授权的事情，对吗？
苏海尔。
所以，我认为看待这个问题的错误方式是我们如何让我们的工程师写更多的代码？我认为这是个错误的答案。我认为最好是说，好吧，我们的工程师究竟在哪里发现写代码有困难？比如说，为什么我的工程师不能在星期五进行部署？或者为什么我的工程师不能在下午5点进行部署？或者类似这样的问题。这种心理障碍从何而来？他们是否担心他们会破坏环境，或者让环境处于不能留下的状态，或者给值班人员造成问题，或者类似的事情？这些都是心理上的障碍。而关注和放大这些...而这些都是基于直觉的感觉。就像这需要研究，需要时间。我认为我们，特别是作为工程师，我们想走快速和优化的道路，并说好吧，我们要把这个数字加上去，最糟糕的事情，我们要专注于这个。
苏海尔。
已经有很多勇敢的尝试，其中很多都以悲惨的失败而告终。现在，直觉也可能以失败告终，我可以给你很多例子，对我们来说就是这样。但我认为，我们已经尝试并深入研究这个问题，并与许多工程师交谈，花时间做用户研究，把它当作我们发布到野外的产品，这是件好事。你需要做这种用户研究。你不能只看一个分数。产品存在用户研究功能是有原因的，我认为有效的开发者体验工具和团队也需要这样做。
你们中有人有这样的经历吗，即开发者的看法和实际情况有很大的不同
？
Charles:
你们中有人有这样的经历吗，即开发者的看法和实际情况有很大的不同？
Suhail:
我也许可以去。
查尔斯：
哦，好。很好，
苏海尔。
我也许可以先说说这个问题。当然可以。我认为速度，事情发生的速度通常是最大的不满之一。很多时候，事情很慢，对吧，而慢是一个非常相对的措施。与什么相比慢？与以前的经验相比慢，还是与你觉得应该发生的速度相比慢，还是与你期望的某件事情的运行速度相比慢，这使你的工作效率大大降低？有一个经典的XKCD备忘录，就是我的代码正在编译，对吗？而代码，如果你使用的是编译语言，你的代码就需要进行编译。然后还有相对的慢的措施。因此，举例来说，如果你正在做一个项目，而这个项目是一个非常复杂的项目，但你在很短的时间内就开始工作，你很可能会优化缓慢的编译时间，以避免重新发明地球。
苏海尔。
但是如果你每天都在做一个产品，而且每天都要发布很多很多次，你就会想要优化，比如说编译的经验或部署的经验，以及诸如此类的东西，使其尽可能快。要么在问题上投入资金，要么在问题上投入工程力量。很多工程师不明白，对于开发人员的经验，这是一个非常难证明的团队，因为他们没有在客观上为公司的目标提供任何东西，对吗？他们是一步之遥。
苏海尔。
我们很多人都在谈论，比如说，无差别的重体力劳动和类似的事情。如果你看一下像亚马逊或AWS这样的公司，或任何这些提供SaaS的不同供应商，他们的产品和他们的目标是他们产品的一部分。他们正在建造这个产品，他们正在把它卖给你。对于他们来说，使其快速发展并增加新的功能是产品供应的一部分，对吗？而当你是一个团队，当你是一个内部团队，当你自己构建它时，你就会被排除在外。而且总是有机会成本，因为这些工程师可以在一个产品上工作，而且很难证明人数的合理性，因为你需要证明这对我的工程师来说有多大的作用。这是一个非常、非常难回答的问题。
汉娜。
我可以从咨询的角度补充一下吗？当你试图说服客户花更多的钱在一个无形的东西上，你知道这将改善，显然改善你的工程经验，但它将改善开发速度，它将改善参与和无形的东西，你是对的，它变得越来越难，因为你变得越来越远离直接的指标，这将翻转这个数量的钱和增加这个数量的价值给我们正在做的事情。
杰米：
，我认为在你可以实时衡量的指标之间是有区别的，比如签到的数量，每天的签到，然后是硬性指标，比如失败的时间，恢复的时间。但DORA的东西也是围绕着你能在多大程度上迅速扭转实验，而这本身就导致了一种心理安全文化。这些只能用追踪指标来衡量，保留你的员工，员工参与服务，现金流，盈利能力。所以有一个问题。所以，苏海尔，你提到你已经试图客观地测量这个。最难的事情是很难衡量的，往往只能在回顾中进行。而且我认为，作为工程师，我们不应该欺骗自己...我们都是工程师，对吧，所以都是为了做多少次检查？但你需要退一步说，好吧，DevEx对更广泛的安全、实验以及对你工作的满意程度有什么贡献。我们经常忘记这一点，因为我们每天都在忙着做我们正在做的事情。
Charles:
是的，我认为这很有道理，Jamie。谢谢你。水晶，我看到你点了点头，提到了启动这一部分的感知和现实之间的差异问题。你想谈谈这个问题吗？
水晶：
是的。我的意思是，我认为这在很多情况下都是事实。我还没有听说过的一件事是破窗效应，即我们对那些缓慢或破损的东西随着时间的推移变得适应了，并且对它们几乎不敏感了。而新来的工程师进来后就会觉得，这到底是怎么回事？但我们会认为这是常态，这是我们所期望的。就像我说的那个东西，单片机。
Crystal:
这让我很困扰，因为当我加入Snyk的时候，我们有一个特定的，怎么说来着，工作小组，我把一个人也扔进去，说，好吧，让我们把这个构建时间控制在20分钟以内。他们说，好的，我们可以做到。我们得到了它，我们做到了，我们把它减少到20分钟以下。这就像18分钟。现在我在这里，两年后，我们说建造时间，我们想把它弄到一个小时以下。我想，哦。所以这就是成长中的事情，对吗？这些事情变得正常，但它们也会变得更严重，我认为有点。
Crystal:
但我认为这就是为什么DORA指标项目对我如此重要，因为我可以向他们展示。当我们做那个项目时，我们实际上有点担心，因为我们想，好吧，从我们的角度来看，这些东西是失败的案例。所有这些事情，不稳定的测试，失败，都是失败。我们会说这一切都失败了。如果工件没有建立起来，没有准备好被推送到某个环境中，它就失败了。因此，这就是我们的...好吧，75%到80%的时间都是失败的。我们担心向工程师展示这一点，因为他们可能会有一个非常糟糕的反应，并可能开始推倒重来。但这就是为什么我们试图非常小心地标明事情的方式，并说这就是故障。这不仅仅是一些红色/绿色的百分比，但这里是它的细分。这也有助于管理层识别需要更多投资的特定领域。
Crystal:
最后我想提到的是，建立共鸣真的很重要。因此，本季度我们在Snyk的开发者体验团队要做的事情之一是确保该团队的每个工程师至少在一个不是他们团队的团队中度过一个冲刺期，以尝试和看到......因为有一种东西叫做 "想象中的工作 "与 "完成的工作"。查一查。
东西叫 "人类工作的多样性
"，这就是这篇文章在互联网上的名称。
Crystal:
而且，再次改变了我对这个问题的整个思考方式。但就像我们需要知道，从应用工程师的角度来看，在尖锐的一端和开发这些东西是什么。他们需要什么？让我们停止假设他们需要什么，弄清楚他们真正需要什么，以及最高的摩擦点在哪里。因为这就是我所说的像生活质量一样的意思。什么会使人感动？我们不能只是假设。
需要和他们一起生活，一起想办法。
，你是如何让高管买下DevEx功能的？
Charles:
是的。Hannah，你开始谈了一点关于买下投资于开发者体验的业务，用一种笼统的说法。我很好奇，你或其他人是否愿意谈一谈，如何让行政级别的人特别买账，以建立一个开发体验职能部门，并在其中投入时间和精力和投资。
Hannah:
我可以谈一谈它在哪些方面遇到了困难。
Charles:
是。我也可以这么做，但请继续。
Hannah:
我想，...我想说的是，产品主导型企业和咨询公司之间的区别往往在于此。我的职业生涯中一直在咨询公司工作，当事情开始出错时，我们总是会得到客户的支持，我们说这将真正有助于解决已经出错的事情，而不是这将改善并使事情变得更好，你不能直接看到。我不认为我有一个解决方案，我们如何在咨询公司内部克服这个问题，除了开始也更多地看，嗯，看，更广泛的行业和成功的产品企业确实投资于此。当我们把它带到我们的客户那里时，已经有了证据，我们也在谈论改善他们围绕工程和交付的文化。不幸的是，从咨询的角度来看，这是一个追赶的游戏。也许我是一个愤世嫉俗的人，但作为一个咨询公司，很难在这种无形的改进投资中成为领导者。
汉娜。
我们经常关注那些已经做得很成功的产品公司，并对我们的客户说，看，如果这是你想成为的人，这是你想去的方向，看看它已经做得多好。请允许我们也为你做这件事。所以，是的。我想这就是为什么我喜欢...我还重申了围绕文化是这样一个巨大的、巨大的问题。作为一家咨询公司，我们绝对投资于开发人员的经验。我们了解它的影响，而不需要通过说服掌握钱袋子的高级利益相关者的过程，这就是正确的事情。我认为，如果你能从一开始就在公司内部建立起一种文化，你就已经走上了正确的道路，然后就变成了在你的财务中打勾，说......并使用这些指标来帮助推动说，看，这是成功的事情，因为我们可以看到它是成功的，而不必先经历它非常糟糕的痛苦。
Charles:
对。是的。水晶，苏海尔，在执行人员买入方面有什么要补充的吗？
苏海尔。
我认为有一个关键指标相当重要，不幸的是，它是在工程师离开时出现的。当工程师离开的时候，你会看到这种神奇的浪潮，他们会敞开心扉，谈论他们的许多挫折。其中一个经常出现的事情，特别是当你没有在这个特定领域投资的时候，就是对工具的糟糕使用。围绕着让东西出货的挫折是工程师选择离开他们特定领域的一个非常普遍的原因。因此，如果你看一下许多已经成功的公司，他们的成功与他们在工程工具方面的投资有关，以便使他们能够更快地发货，减少失败的时间。所有这些都是开发者经验的一部分，对吧，给...再一次，消除发货的心理障碍。
苏海尔。
正如Crystal所提到的，所有的事情......比如一个不稳定的测试，一个悄悄进入代码的错误，一个被破坏的部署，对，所有这些都是失败，对吗？这些都是工程师会经历的纸上谈兵。而当工程师们习惯于这些破损的窗口时，他们的生产力就会因此而降低。因为会有一类工程师会非常淡定，只是把东西扔到栅栏上，而会有一类非常不同的工程师会想非常非常小心。这将最终减缓他们的速度。正如杰米提到的，这些都是跟踪指标。而且不幸的是，你发现得有点晚。但我不认为这是不可挽回的，即使在每一种规模的组织。
苏海尔。
你不会到了一个大型组织，说，好吧，所有的地狱已经崩溃了，我们对此无能为力。我们只是要生存。你可以开始做一些事情，我认为即使是在一个较大的组织，你有可能有一些可用的人数，这个案例也比较容易。你可以说这是一个有很多工程师正在经历裁员的领域。这里有一些数据。对吗？这需要一点点的直觉来识别。这里有一些数据可以证明这是一个问题，我想有了这些数据，我们就可以把这个图画下来。然后说好的，对，用两个工程师的时间价值的努力，我们可以做出100个工程师的生产力。这是一个相当容易推销的等式。
汉娜：
，我认为衡量标准和信任。
苏海尔。
信任，是的，
汉娜。
归结为
相信实验是值得的，并且相信如果实验不值得，你会继续从中吸取教训。
Charles:
是的，我想我也要补充一下，如果你能有与高管们关心的事情有某种联系的指标。因此，你的普通管理人员不会关心，我不知道，你的应用程序崩溃的次数，或有多少次中断或类似的事情。但是，如果你能把它与过程中的损失联系起来，或者与执行团队真正关心的事情联系起来，那么我想，就会变得更容易支持销售。对不起，Crystal，你正准备说些什么。
Crystal:
是的。我认为这实际上是
对于你的观点，查尔斯，所以有几个...我的意思是，我们有买进，所以我很幸运，我应该说，因为我曾经在组织中肯定不是这样的情况。所以从我的角度来看，这很新鲜，因为有信任。我的高级副总裁说，这听起来像是一个好的团队，我需要...他说，当我去参加执行会议时，他说这可能有点令人沮丧，因为他们会有报告，很多人都会有报告和数据可以分享，但他说我作为工程领导往往没有很多东西作为基础。所以我们谈论像客户SLA和正常运行时间这样的事情，他说，但是我们都知道这些措施就是不那么好。他说，所以我也希望有更多的数据，关于工程的心跳是怎样的，我们怎样才能使其更有成效？
水晶：
，所以就买进而言，这是好事。但是，我们做的一件事是......。所以我在书中贴了一个链接，是《如何衡量一切：寻找商业中的无形资产》。我想说，去读那本书。这本书很了不起。它有时会有点枯燥。它确实谈到了很多统计学术语，但不是太深，所以任何没有统计学背景的人都可以很好地掌握它。但这是一种，再次，另一件完全改变了我的思维方式的事情。因此，我们在Snyk想出了一个延迟成本模型，这就像，好吧，这里是一个电子表格......我们并不完全固定在建造时间上，但这恰好是我们开始的地方。但我们已经说过，好吧，建造时间是多长？我们有多少名工程师？我们付给他们多少钱？如果我们将其减少X%，这将为企业节省多少钱？
Crystal:
所以我认为这很重要，因为我曾经是工程部的副总裁，我认为以前曾坐在我老板的椅子上，就像我记得那是什么样子，如何谈论商业语言，比如我们如何证明自己？我认为工程师们经常发现这一点很棘手，在谈论投资回报率和需要发生的商业语言方面。这就是购买力的来源，是能够量化的东西，并以那种商业语言的方式说话。因此，我们能够说，嗯，是的，如果我们进行这项投资，我们可以很容易地每年节省50万。这听起来不是很多，但在我们当时的规模，即不到100名工程师，这是相当重要的。
Crystal:
现在，它更多，它可能是每年几百万。你想想看，这只是在构建时间上减少了10或15分钟。因此，这肯定证明了团队本身的合理性。这就像你几乎不需要做其他事情一样。但我们带来的价值还有很多，对吗？因此，其中一个...我们说好吧，这是一个好地方。很多人都明白这一点。我们怎样才能采取同样的模式并将其应用于SRE？那么，一个事件的成本是多少呢？再说一遍，当然，这将是粗略的，随着时间的推移，这将变得越来越可量化，但让我们从某种模型开始，给我们一个范围，然后我们可以与企业讨论。比如我们为什么要投资于从事件中学习？这是因为我们期望从中获得这种投资回报率。我认为这是我想说的，是一件值得思考的事情，可以在任何组织中得到买进。
你们对更广泛的组织问题有什么看法吗？
Charles:
我很好奇，你们中是否有人对更广泛的组织问题有什么想法？从我自己的经验来看，我们倾向于把注意力集中在让我们的CI/CD管道变得非常灵活，或者能够超级频繁地把它部署到生产中。但也许这不是我们最大的问题。也许我们最大的问题是我们得到的需求不是很好，或者不是很清楚，或者也许在产品管理过程中出现了问题或类似的问题。因此，这并不属于DevEx的直接管辖范围，但正如我们一直所说的，DevEx是一种更广泛的事情。我不知道是否有人对此有什么想法。
Suhail。
我非常关注的一件事是组织的复杂性，例如，当涉及到......开发效率时，我非常关心。例如，非常具体地说，在许多团队中，如果你想改变你的团队并不直接拥有的系统，通常你会去把它添加到其他团队的路线图中，并乞求他们的EM或领导来优先考虑你的事情，以便你可以发货的功能。我相信这将是一个非常普遍的......当你依赖别人的时候，这将会在这个特定的小组中引起非常广泛的共鸣。随着像monorepos和诸如此类的东西的出现，这种东西已经变得非常容易，在那里你可以进入并帮助对业务的其他领域做出改变。而且，事情并没有被隐藏起来，复杂性也没有在一个特定的领域中被自我封闭。
苏海尔。
但其中一些仍然可以成为进入的障碍。例如，如果一个不同的团队使用不同的编程范式或使用不同的编程语言，诸如此类的事情，你仍然会有组织上的障碍，你没有所有的背景。因此，举例来说，我们之前谈到了铺设的道路，而铺设的道路也可以包括像你使用的编程语言或你如何构建你的应用程序，你的代码住在哪里，你如何定义你的HTTP处理程序，你如何在服务和类似的事情之间沟通。任何能使跨公司合作变得更容易的东西都能大大减少交付的时间。
苏海尔。
因为你不是把一个特定的领域集中在一个特定的团队里，而是有一大片的工程师愿意并能够在不同的团队计划中做出贡献。现在，这也带来了关于所有权的潜在问题，每个工程师都想把太阳下的所有功能都封装在系统和服务中。这也是你需要管理的一个方面，以确保它不会成为拥有团队的沉重负担。但它可以成为一种重要的授权，以减少组织的复杂性，建立对系统构建方式的共鸣，传播知识和专业技术以及文档，并允许每个人做出贡献，而不仅仅是一小部分人在把关。
Hannah:
我认为你必须相当小心
我们显然已经谈到了DevEx是非常广泛和全面的，包含了很多方面。你也必须小心，不要试图把每个人都抓起来，解决所有问题。应该对强大的产品管理技能和功能进行问责。它不可能解决所有问题。它是更广泛的公司或项目的一部分，检查和平衡以及问责制也是一件好事。
Hannah:
我知道肯定有，我猜
当然，在咨询行业，我认为...我一直想回到咨询行业。这是我的参考框架。有一种趋势是，我已经看到了一个问题，我要去解决它。在 "我已经看到了一个问题，我要去解决它 "和 "我已经看到了一个问题，我要把它叫出来，让正确的人负责，因为那是他们的责任 "之间必须要有一个平衡，每个人都在为同一个最终目标而努力，但在这个过程中做他们自己的功能和他们自己的事情。我认为这是一个真正难以驾驭的平衡，但确实必须有责任的界限，就像DevEx可能是广泛和全面的。
Charles:
是的。Crystal?
Crystal:
当我们谈论产品运营时，这又回到了之前在组织中经常发生的事情。还有其他一些存在于组织中的姐妹功能，我认为与它们配对是好的。我们开始在我们的组织中创建这种类型的东西。因此，查尔斯，当你谈到像我们可以专注于一些他们觉得更舒服的事情，他们是在我们作为工程师的控制范围内，而有些事情更难。它更难调试，因为你在调试组织和流程，以及跨边界功能的那种故障和类似的东西。但这就是为什么我认为，当你考虑到产品运营和DevEx时，他们可以成为做这种组织性调试的快乐伙伴。因此，这是一个我们已经开始与之紧密配对的团体。
Crystal:
我们的另一个有趣的配对是Snyk是一家SaaS/PaaS公司，我们也有DevRel，所以我们正试图弄清楚DevRel是如何运作的，以及我们如何将DevRel引入DevEx？因为DevEx在很多方面都有点像DevRel的功能，所以我们如何将这些可以帮助我们的东西嫁接到一个团队中？但是，也不是说一个团队就能解决所有问题，因为它是一个小团队。如果DevEx变得太大，你可能做错了。它更多的是关于我们如何与组织的其他部分配对进行调试，这种系统思考的方法贯穿整个组织。老实说，我们还没有做到这一点。但这是我热衷于研究的一个领域，因为这是我以前被问到的问题，就是如果问题实际上是像你说的那样，收集需求怎么办？如果不是很清楚我们要建立什么或为什么要这样做呢？
Charles:
对。是的。
Crystal:
那么我们就在建造错误的东西。这是很浪费的，对吗？因此，要回到精益思维，并试图将其灌输到组织中去。是的。所以我没有答案。不过我很感兴趣，如果你一年后再问我，我会对我们是如何做到这一点有更好的答案。
有一个专门的职能部门负责开发者体验，与将DevEx人员嵌入到流线型的开发团队中，有什么利弊？
Charles:
关于这个问题，有几个有趣的变化。这里有一个来自Tudor的问题，还有一些人私下里给我发了一些信息，我将尝试把这些信息合并在一起。因此，基本上可以归结为，有一个专门的开发人员经验的职能部门与将DevEx人员嵌入到流向一致的开发团队中的利弊是什么？这可能是最简单的总结方式。
Crystal:
我可以开始。所以我对这样的事情非常感兴趣。我对团队拓扑结构这样的事情非常重视。因为这就像，你如何建立你的组织是根本，运营模式。因此，我认为可能有优点和缺点。从我自己的经验来看，我已经为不同的事情尝试了不同的模式。我想说的一点是，这不是一个放之四海而皆准的模式。我所看到的效果很好的是，当你有更多这样的核心团队时，比如有六、七个工程师和一个产品经理围绕着这个团队。这并不意味着他们会做所有的事情。这就是实践社区和行会真正帮助组织运作的地方。
Crystal:
我们在Snyk有这种情况。所以，虽然我可能在管理一个信息部门，但有很多信息部门的工程师分布在整个组织中，还有来自SRE背景的人。因此，通过引入类似公会的方式，你仍然可以给他们一种更强的声音来影响这些实践或平台或任何可能的方向，这将是一个快速的过程，甚至可能加入一种快速通道。好吧，这将是一个有点颠簸的旅程，但你是我们的设计伙伴，因为你在另一边，但你也了解我们的背景，因为你以前做过这种类型的角色。所以我认为这可以成为一个很好的桥梁。但是，是的。但也许另外两个人在这方面有更多的
发言权
。
我可以接着说。我不认为这两者有冲突，我认为你可以有一个更全面的开发者体验功能，我想我们称之为生产工程师，他们坐在各自的团队中，帮助反馈给一般的开发者体验功能，但也为他们的本地小组进行优化。我认为，最后一点是关键。因为如果你只有，我想我们称之为生产工程师的人，这些人在他们特定的小组中被过度优化，如果你看一下团队拓扑结构和类似的东西，他们被认为是拥有团队的人数。因此，他们的优先权首先是他们自己的团队。因此，举例来说，如果你有一个大型的跨领域的变化，或者一些可以让很多很多团队受益的东西，典型的反应是降低优先级，以获得快速和肮脏的变化，使你的团队更快。
苏海尔。
所以没有人真正关注整体的情况。而开发者体验团队的优势在于，他们的职责是关注整体情况。但这两者并不需要争论。有一个问题也很类似，那就是这个开发者体验团队，你如何建立这种共鸣？与团队坐在一起，了解他们的工作方式，是成为一个高效的开发者体验团队的核心功能，了解工程师是如何构建和编写软件的。你可能最终会处于这样一种情况：你只影响到一个特定的团队，这完全没有问题。但你可能会发现，因为你有更广泛的职权范围，你会授权给更大的工程师群体，而不仅仅是你的局部团队。
查尔斯：
汉娜，你想加入这个行列吗？
汉娜：
我完全同意。我认为有时我们把团队的方向看成是线性的，但实际上，特别是当你考虑你的生活服务团队，你的生产团队，然后是你的DevEx团队，你可能在传统上把端到端的规模中的任何一端。其实不然。它是循环的，实际上，让他们接近使所有其他的循环变得更好。
你如何看待开发者体验功能随着时间的推移而发展？
Charles:
那么，你如何看待开发者体验功能随着时间的推移而发展？
Hannah:
我想我们在聊天中已经就这个问题进行了很多讨论，即在融入团队和保护自己的时间方面，它看起来像什么，以确保他们能够做到，而不是被吸入日常工作中。我认为这必须归结于环境。它在哪里工作？公司是如何设置的以获得成功？你是否有全面能力的团队，这是常态，他们拥有产品的部分？你是否有产品团队，他们拥有非常简洁的部分，需要非常简洁的技能？你必须能够灵活运用。我认为它的未来是，我们更好地阐明它的重要性，使它成为一个不可谈判的问题，但我们能够根据公司、项目和文化的需要，灵活地实施它。
苏海尔。
是的，我同意。我认为整个运动，整个开发者体验运动正在经历一个爆炸性的发展，有很多东西正在进入开发者体验的世界。因此，我特别热衷的东西是我们能够从安全角度卸载到一般的日常工作中的大量事情。我和Crystal根本没有聊过这个问题，但是像Snyk这样的东西，我们能够将其作为公关流程的一部分，例如，将整个安全意识传播到有脆弱的依赖关系和引入不符合许可要求的依赖关系。对于每年做一次审计的人来说，这些事情通常是一种负担，比如说，这里有10个你不小心违反GPL的行为。这些工具正变得越来越普遍，很多公司现在都在真正谈论开发者的体验。
苏海尔。
这就像一个有趣和性感的领域，对吗？很多团队都在谈论他们的生活经验。我们正在进行这样的对话。我认为这是一个很好的证明，我们能够分享其中的一些经验和我们的一些经验，在我们不同的行业中运作良好的事情，没有运作良好的事情。即使是在传统上非常、非常保守的领域，比如我和很多投资银行之类的公司谈过，现在加入这些公司的工程师，他们都希望有这种水平的开发者经验工具。
苏海尔。
一个加入高盛的工程师不会再容忍Java 5.0成为他们的标准开发环境。所以，这些事情是很重要的。很多工程师都非常关注行业的发展，他们不希望落后于人。他们希望能够与像谷歌和Facebook这样的大型开发力量并肩作战。事实上，我们正在进行这些对话，工程师们非常非常热衷于保持最新，现在比以往任何时候都更热衷于保持最新，而开发者体验是其中非常非常大的一部分。是的，我们能够分享我们的经验。
Charles:
Crystal，你想进来吗？
Crystal:
是的，只是补充一下。所以，当我回想起我开始的时候，对，我不认为这是玫瑰色的眼镜，说那些日子更容易，那些时间更容易。这就像用FTP把东西放到服务器上，希望东西不会出错。如果它出了问题，你就在它上面做FTP，而且没有源码控制。或者说，我肯定没有使用它。那时候可能已经有了，但这并不常见。所以，现在要保持对事物的关注是非常困难的。就像我上周刚在办公室里做了一些事情，围绕着一大堆人的加速训练营课程，就像加入这个行业是什么样子？对他们来说，这很艰难。他们被期望知道所有这些东西，这比我作为一个计算机科学毕业生被期望知道的要多得多。
Crystal:
所以我认为这是关于铺好的路。这就是苏海尔所说的。工程师们只是对他们的环境和日常工作有更高的期望标准。他们不会像以前那样忍受狗屎。就像他们有1000种选择，可以去别的地方工作。因此，从一个品牌和吸引员工的角度来看，我们需要在这方面进行投资。这也是可以让我们从我们的竞争对手中脱颖而出的东西。它的发展方向是什么？我认为，我们将看到更多这样的事情，这是事实。老实说，我不知道它在未来会是什么样子。就像我说的，从我自己的角度来看，我们现在有一个团队在Snyk做这个。我认为最终会变成多个团队，这是事实，有更多的专业性。但也要与组织的其他部分和其他职能领域合作，尝试和看看我们如何更全面地做这件事。
查尔斯：
，我认为这实际上是一个非常、非常好的总结点。所以非常非常感谢我的三位小组成员，汉娜、水晶和苏海尔。非常感谢你们在今天下午抽出时间来参加我们的会议。对于每个人来说，他们都...我们在聊天中同时进行了一些很好的对话，这非常棒。因此，非常感谢你们的到来。正如我们在顶部所说的，这次会议被记录下来了，所以很快就会有一个视频发布。所以你可以留意一下。如果有任何你想错过的东西，对不起，任何你想回去看的东西。那么这显然会在音频中出现，你可以在周围分享。卡拉，在我们结束之前，还有其他最后的通知吗？
卡拉：
不，每个注册的人都会收到一封带有视频和一些额外内容的电子邮件，你可以查看。而且，是的，如果你想得到更多的内容，我在聊天中放了一个提醒，你可以订阅我们的通讯，或者明年亲自来参加我们的会议，效果更好。我也想感谢你，查尔斯，感谢你主持这个小组，还有我们的小组成员。我想这是一次很好的对话，有很多的见解。我们将尝试回答一些通过电子邮件注册的问题。有很多的问题。我们会尽力而为。但是，是的，感谢大家今天加入我们。
Charles:
非常感谢。
CS
博客
的相关内容
开发者体验门户 "后台 "如何解决Spotify的复杂性问题
3210
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
