更好的乔尔测试：开发者文化测试
我已经和几十个软件开发人员谈过他们对工作场所、团队和公司的专业喜恶之处。我开始看到一种有趣的趋势，那就是让人们快乐并茁壮成长的环境--让他们停留的时间更长--而不是那些让人感到痛苦的环境，即使他们在那里也是如此。4-5年来，我一直特别关注同一家公司的员工，他们对探索其他选择不感兴趣。是什么让他们打招呼并想要留下来呢？而那些不顾一切想要搬家的人，是什么把他们推开了呢？
令我惊讶的是，2020年在量化这些观察结果方面没有做太多工作。我们有Joel测试，它仍然附加在Stack Overflow工作列表上，大多数招聘广告声称在这12分中有11分或12分。但是，2000年编写的“乔尔测试”(Joel Test)让人感觉太过时了，没有涉及到本世纪20年代对高效开发人员来说很重要的事情，比如自治、代码审查或持续的专业成长。因此，我退了一步，重新想象了像乔尔测试这样的测试在本世纪20年代会是什么样子：预示着一个拥有伟大开发人员文化的工作场所。
有了这个，我给你一个开发者文化测试：3个领域，每个领域有5个问题，是一个健康的组织，开发人员在那里茁壮成长。根据我的经验，任何一家你可以称之为体面公司的科技公司都应该明确这3个基本点，并且至少涵盖每个领域5个要点中的4个。
这些都是所有像样的公司都有的。如果你的公司连这些都没有，那么你很可能已经在找新工作了，而且你肯定已经放下了防护罩。
心理安全和无可指责的文化。即使人们可能与他人意见相左，但他们是否觉得做自己、说出自己的观点是安全的呢？关注微侵略性和无意识的偏见并采取行动是文化的一部分吗？当出现问题时，您是否运行了一个无懈可击的流程，将重点放在系统性根本原因上，而不是是谁造成的？这可能是因为停机、技术问题或决策失败。
公平的补偿。贵公司支付的工资是否合理，与当地市场多少持平？
工作时间的常识性灵活性。工程师能否以灵活的方式工作，为他们的团队工作，也为他们工作？这可能是合理的WFH指导方针，对短期时间表变化和个人情况保持灵活性，专注于人们在工作日开始和结束的时间内完成的工作。
我不会在前两个问题上浪费太多时间。关于最后一个问题，即常识灵活性，有些人可能会想，我为什么要把它加在这里。这是因为软件工程师的灵活工作安排无处不在。远程角色呈爆炸式增长，WFH是主流，因为冠状病毒(CoronaVirus)和任何坚持朝九晚五或类似工作的公司都会发现自己是少数。这些地方的人们会(也应该)问，为什么他们不去其他有这种灵活性的地方换工作呢？
做对了这一点的公司将会有创新和自主的员工蓬勃发展。那些不这样做的人会随着时间的推移看到这些人离开。
了解原因。您是否有适当的流程来与工程师分享需要完成的工作的业务原因？这可以是路线图、OKR、公司和组织范围的目标等。
积压工作/路线图和参与工作的工程师。团队是否有清晰的积压/路线图，便于回答我们下一步要做什么？为什么？自上而下的计划是否也符合自下而上的计划？那么，工程师是否可以将最终出现在团队路线图上的建议拿到谈判桌上--要么作为支持为什么，要么作为工程工作预算的一部分？合理的科技债务偿还建议会这样优先吗？
在解决问题时直接沟通。是否鼓励开发人员通过找其他团队的开发人员直接解决问题？而不是必须通过他们的经理，后者与另一位经理交谈，后者与团队的经理交谈，后者与…。
跨职能协作。开发人员是否直接与用户、设计师、产品经理、数据科学家和其他利益相关者合作，而不必依赖代理(例如他们的经理)？
庆祝人们积极主动。人们是否在采取主动，让事情更好地得到庆祝或奖励，因为这被视为不必要的分心？
区分功能齐全和可投入生产的产品。您是否区分代码的原型/MVP/功能完成阶段和生产就绪状态？你们有没有一份清单，上面写着什么是可以投入生产的额外质量标准？
代码审查和测试。代码评审和自动化测试(单元、集成等)是日常开发过程的一部分吗？对于非常容易理解的情况，没有代码评审和自动化测试是极少数的例外吗？
CI和CD或部署到生产中的开发人员。您是否有在提交代码之前运行的CI进程设置？提交代码后，您是否有CD流程可以将其直接推送到生产环境中-如果没有，开发人员是否可以将他们拥有的代码推送到此环境中？
健康的OnCall。对于开发人员使用OnCall的团队，您是否衡量OnCall运行状况及其对开发人员的影响？修复不健康的OnCall是否优先于任何产品工作？
内部开源。您是否遵循内部开源模式，在这种模式下，任何开发人员都可以阅读任何其他代码库并为其贡献内容-只要有适当的代码所有权？
以上所有这些都是大多数技术公司的基线实践，在这些公司中，开发人员可以快速行动，具有稳定性实践和预期。反过来看：如果你错过了这其中的大部分，祝你好运，从科技公司招聘员工，而不是他们在第一个月就辞职--或者他们开始改变类似的文化。
被驱使的人希望在整个职业生涯中保持成长。贵公司是否有针对高级开发人员跳槽进入管理层之外的成长轨迹，以及是否通过各种方式支持专业成长？
建立信任的技术经理。大多数工程经理是否都有过在其职业生涯中的某个阶段从事过软件开发的背景(技术上的意思是说)？经理们是否以建立信任的方式定期进行1：1(例如倾听、提供反馈、讨论职业目标)？
职业阶梯。你是否有职业阶梯，确定了每个级别的级别和期望，以及关于如何进入下一个级别的明确晋升过程？
并行IC&A；管理器跟踪。您是否拥有比入门级工程经理角色高几级的平行IC&；管理职业道路？
一种反馈文化。你是否至少有以下三项中的两项：360绩效评估(主管也会向经理提供反馈)，同事之间相互反馈的文化，以及公司通过全公司或全组织范围的调查收集、分享并采取行动的定期反馈。
投资于职业成长。你是否至少有以下三项中的两项：与开发人员同时指导其他开发人员的积极指导计划，书籍/培训的专业发展津贴，公司内部人员相互学习的定期技术讲座-或者向外部专家学习。
经理人的技术性是我和人们谈得很多的一个问题。虽然我理解非技术经理也可以是富有同情心和伟大的经理：但他们会错过挑战团队的能力，以及保护团队不受无理要求影响的能力。他们将缺乏有效倡导可持续工程的能力-既不能保护团队不受不合理要求的影响，也不能为了团队的健康而将实践放在适当的位置。如果没有实践经验来解释为什么某些实践是重要的，那么倡导任何一种做法都是非常困难的。他们还将努力指导团队中的软件工程人员-这对职业生涯早期的人来说尤其重要。
并行管理和IC跟踪-或缺乏-是工程文化的另一个预测因素。如果最优秀的工程师唯一能够在专业和影响力方面成长的地方就是管理，那么对于那些不想做或者不太擅长做这件事的开发人员来说，这将是一个严峻的前景。它还创造了一种管理者掌管局面的文化，而不是充当仆人领导者，他们是开发者的合作伙伴，特别是与高级IC合作。
你可能会问：Gergely，这是一个很好的列表，但上面的所有这些都有多适用呢？根据我的专业经验，以及我与来自不同地区和行业的数十名软件开发人员的交谈，这是非常适用的。它还反映了一些最具创新精神、发展最快的科技公司的运作方式，从微软(Microsoft)、谷歌(Google)、Facebook和优步(Uber)，一直到规模较小但成功的初创公司，如Monzo、N26和其他许多公司。
虽然我是独立撰写的，但“技术优先文化测试”似乎也呼应了“加速：构建和扩展高绩效技术组织的科学”一书中的一些发现。关于个人和团队自治、可持续工程的思想也是本书中提到的观点。
喜欢这篇文章吗？订阅我的时事通讯，并在您的收件箱中获取未来的帖子。这是一本相当不错的书，拥有超过3500名订阅者。
订阅我的时事通讯，了解实用的软件开发和工程职业发展的最新情况。
