软件开发团队的所有权和责任
理查德·加特利摄
这是一个由三部分组成的系列文章的第1部分，该系列文章是关于我在孵化器中与高效能，真正敏捷的软件开发团队一起学习到的东西的。如果要在最有才华的软件开发人员中排名前20位，曾经与之合作过，清单上的大多数人都是我最近从事的同一项目的工程师。该项目是一家由大型企业支持的创业公司，如今通常与这个“孵化器”一词共享，并且多年来在数字市场中实现方式有很多变化。在该国相对较小的人才库中，该公司设法招募了一些最好，最智能人才（以及在国际范围内招聘的更大的人才库，但这只是针对我在当地工作过的人才）。工程师平均流失率仅一年多。大约12到14个月后，他们再次离开公司。在我参与该项目大约2年之后，他们一无所有。为什么？定义孵化器从大型，成熟的公司设立创新部门得到以下假设的支持：大型，复杂和传统管理的公司不能很好地处理创新。决策是由员工自上而下进行的，与产品和客户的联系最少，员工具有固定的角色并定义了职业道路，并且通过一系列旨在避免问责制的决策来命令和控制新项目。这个星座不断稀释和抑制旨在市场破坏或挑战现状的任何和所有创新尝试。尽管有共鸣，但这个想法实际上并不是那么新。关于它的文章很多，请参见本文。 《 Adhocism》一书于1972年首次发行，包含了如今孵化器使用的许多概念和想法，大人们会从这里借鉴它。在我任职期间，我观察到应用管理方面的重大变化，这是影响管理的决定性因素。员工的敬业度和奉献精神。在孵化器成立之初，管理层言语与行动之间的一致性是1：1。随着孵化器产生的项目和文化开始成熟，传统管理者自上而下的决定被他们称为“毕业生”，使孵化器项目成为公司的一等公民。剧透警报：那是辞职率开始上涨的时候，即使我没有与任何人谈论他们的决定，他们的行动通常也胜于雄辩。任何负责任的人力资源或管理人员在尝试倾听旧工作与新工作之间的沉默差异方面都表现出色。一些同事甚至根本没有找到新工作就离开了。如果我知道的话，那真的应该是一个警钟，但是我确实打了个电话。所有辞职都（至少）有一个共同的痛苦，那就是寻求新机会的原因：他们以前拥有所有权，现在却承担了责任。在前面提到的人才流失中，五名工程师成为了其他孵化器的CTO，就像他们刚离开的那个一样，另外四到五名被新当选的CTO挖走了，三名加入了其他孵化器初创公司作为高级开发人员最后两个人决定成为独立承包商。当被问及他们在新职位上获得了什么时，答案是一样的：所有权。“我喜欢自己做决定”，其中一个告诉我，当我问他为什么被前任猎杀后辞职的时候。 -同事转为CTO，“时速120英里/小时”。他的意思是说，他希望被信任负责，同时又能将产品推向市场的时间最短。他拥有开发，部署过程和质量保证。但是，如果您只是一名简单的软件工程师，您将如何负责？ CTO或技术管理人员肯定是负责人吗？对？错误在这些消息之后，让我尝试解释原因：在此“毕业”过程中，孵化器的整个原始管理已被完全替换。我将在本系列文章中将所观察到的新管理风格简称为Career Manager™。这是众所周知的古典经理类型，他们对产品增长不感兴趣，但对职业发展不感兴趣。我确定你们至少知道一个。也许你自己一个人？在那种情况下，我真的希望您继续阅读。授权意味着所有权，而不是责任最新的软件团队管理指南始终强调相同的概念：授权。但这到底是什么意思呢？这是一个定义：
授权是使团队参与决策的一种手段，可以赋予他们参与性的角色，可以利用他们的专业知识和判断力，并增强他们对个人价值和对组织的承诺的意识。
另一方面，Career Managers™解释为这意味着要赋予员工责任感：“恭喜，我们已经决定让您带领团队。这是很多责任”但这并不是，实际上。赋予员工权力意味着所有权。那么有什么区别呢？责任承担“授予的责任”实际上是矛盾的。就像团队中的其他每个人以及管理团队和所有穿着西装并穿着C级电话卡的人的顶层公寓一样，您没有获得任何应有的选择灰白色调色板。我们看到的充分利用工程技术人才的职业是那些没有将责任和领导视为职务的人，而是将他们的行为和行为视为同行的人。如果您正在开发软件解决方案，那同样是您的责任该代码实际上在生产中运行，就像团队中其他所有人一样。长期以来，我们已经跨越了高性能开发团队中“不是我的代码，不是我的问题问题”的孤岛思想。关于此事的研究和文章已经发表了无数，所以我不会再让您感到厌烦了。我曾在许多高绩效团队工作，这些团队利用消防员来处理生产错误，以避免不断引起环境变化。团队中其他开发人员的想法。显然，如果这是您喜欢的方式，考虑到这个星座的本质，就不可能垄断责任，这就是应该的方式。对于职业经理人而言，有效地通过责任来赋权，无非是指责和责备。问责制，以使自己不承担责任。我的意思是说，对吧？如果我可以将责任转嫁给其他人，那一定意味着我自己不负责任，对吗？例如，听起来熟悉吗？
生产中存在一个错误：在发行过程中，谁负责质量检查？开发团队中的谁介绍了该错误？谁来负责，所以我们将来可以取消该团队的责任？
…我们必须建立一个新的，专门的部署团队来负责将来部署到生产中。这不能被开发团队信任，因为他们无法内部进行协调。这一事件无可争议地证明了这一点。
在任何现代开发组织中，赋予责任和承担责任都是零收益或意义，这是被误解的发布管理的副产品，我将在本系列的下一部分中进行介绍。就目前而言，请相信我.OwnershipOwnership意味着以团队为己任的方式最好地主动解决任务。最适合产品的最终用户，以及其他团队成员的代码质量和可维护性。这可能是一件令人不安的事情，因为如果做错了，它可能导致产品的灾难性灾难。如果您的工作环境完全是指责和推卸责备，那么就不太可能采取主动行动或主动挑战现有的工作方式。实际上，就像我亲眼所见，它引导人们积极应对这种行为，以避免自己受到高层管理人员的不必要审查，这就是为什么责任和主人翁是团队努力的原因。使团队拥有所有权意味着团队在内部对产品和代码负有共同的责任。这样，该团队将能够在潜在灾难发生之前进行缓解，并且无论如何不可避免地发生了某些灾难，由于他们自己拥有部署管道的所有权，因此将能够迅速减轻生产错误。顺便说一句，这就是DevOps的本意，在此之前，就像Fake Agile一样被稀释了。示例与其他曾经阅读过手册页的人一样，示例是您首先要跳过的内容。因此，我将以两种显示差异的现实世界场景结束本文。场景1：完全负责，零所有权
想象一下，您正在一个5-6人的软件开发团队中工作，并且您要承担一些任务，以创建需要扩展的分布式后端。团队决定遵循云提供商所提供的所有奇迹，使他们专注于代码而不是基础架构。他们利用一些云提供商MQ来进行异步消息传递，使用一些自动缩放的负载Balancer以实现最佳响应时间和故障转移，使用分片的对象存储作为后端，并使用分布式日志记录机制进行轻松调试，最后使用一些度量标准警报来快速警告生产错误。对于编程语言，整个团队已经有一段时间关注最近出现的Rust规范了，并认为这将是一个在学习新技术以提高平台安全性的同时集体提升能力的好机会-他们知道管理层的热爱在距离很远之前，Career Manager™打断了他们，并要求创建关于他们的决策的详尽报告，并仔细指出做出了哪些（技术）决策，以及原因。在团队可以继续之前，职业经理人™需要得到批准。公司周围流传着谣言，表明该团队将使用未经批准的软件，技术和编程语言来执行Wild West任务。如果团队在其报告中包含图纸和图形，那将是一个加号。当然是Microsoft PowerPoint。团队中的任何一个都不使用OSX或Linux。在团队花了两天时间在内部编写和验证报告，并等待了另外一周的答复之后，团队被召集参加会议，并告知管理层有一些顾虑。他们仍然有权按照自己的方式去做。但是，正如良好的管理人员所指示的那样，它们必须在一定的范围内运行，以免它们失去控制。管理层也必须考虑公司的其他部门。
- 云是危险且不安全的。他们可以使用IT部门在内部自行研发的本地解决方案。
- 该数据库只能是Microsoft SQL Server（无分片，单一来源），因为这是他们唯一外部支持的企业解决方案，以防万一出了问题（请记住，归咎于责任是最重要的）。
- 他们不了解或不支持MQ的现成解决方案，因此团队将不得不提出一种没有此功能的实现。
- 在内部部署中至少不支持自动负载平衡和回退解决方案，这在每个云解决方案中至少已有6年成为事实上的标准，因此该解决方案将始终保持固定数量的服务器。如果运维部门发现任何性能问题，他们将提供更多服务器。团队只需要告诉操作人员他们想要多少服务器，没什么大不了的。
- 由于具有紧密安全团队的复杂组织中的防火墙问题，因此无法提供自动度量标准和错误警报。只能从具有特殊凭据的特殊Windows计算机上查看生产日志（团队使用他们喜欢的任何操作系统，主要是Linux和OSX，因此他们将需要一些新计算机）。生产错误将在部署之日由专门的质量检查小组检测，或者由最终用户投诉以发现生产错误。
- 不生锈。该语言对于IT管理层来说是未知的，因此，由于公司的风险太大，所有对其使用的争论都无关紧要：考虑一下可能，整个6人团队突然决定一次退出。没有人需要维护代码库，因为学习一种新的编程语言并不是高级软件开发人员会突然想到的事情。公司的官方政策是仅支持C＃，因为那是Microsoft支持的，如果出现问题，您总是可以聘请外部Microsoft顾问来扑灭。 （同时将责任归咎于“我告诉你”）。
这是代表团队承担全部责任的一个示例，而对团队以他们认为合适的最佳方式来解决任务的努力则置零信任。对于Career Manager™而言，这是最佳的解决方案，因为这完全可以提升他的职业发展道路，同时对于可能发生的任何和所有灾难保持绝对的责任。对于开发团队来说，情况完全令人沮丧，因为如果实施受到影响，他们将受到全部责备，如果实施失败，他们将获得零信用，因为职业经理人™通过保留这些牛仔使项目从灾难中拯救了出来情况2：共同承担责任，共同拥有
想象一下完全相同的情况，只是这一次，谣言并没有引起管理层的恐慌，但是兴趣突飞猛进。管理层知道他们雇用了才华横溢的开发人员，因此他们也认识到自己不足以比自己的软件开发更好地了解团队。经理的责任是表明团队的信任，并清除从构思到实施的障碍。由于管理人员对软件实现的细节不感兴趣，也不了解，因此，仅由开发团队自己负责。由于该公司没有可以与云提供商的灵活性进行远程比较的内部部署解决方案，因此，团队拥有整个开发流程的所有权，并被管理层要求花大量的时间进行前期记录这个过程，因此下一个团队可以以共享的方式从知识中受益。
- 由于公司目前没有使用云提供商，因此要求团队审查并确定最有效的云提供商，无论是从成本还是与现有系统的集成方面。由于安全性，GDPR和公司品牌价值很重要，因此管理层要求团队确保所有此类规定均由提供商实施。如果团队中具有关键知识的人员突然决定辞职，就应该记录移交程序，就像在其他任何辞职情况中一样。
- 可以根据团队的需要选择数据库技术。管理层要求云提供者确保合理的快照和备份过程，以防被触发满意的初级开发人员意外删除，攻击等。
- MQ技术可以是团队认为合适的任何东西。但是由于企业解决方案可能会很昂贵，因此管理层要求团队尝试将MQ解决方案与云提供商的MQ捆绑在一起（如果有的话），或者找到团队可以为其提供担保的开源软件。
- 自动负载平衡解决方案可以是团队认为合适的任何解决方案。管理层很久以来一直在寻找一种解决方案，以在发生部署错误时自动回退和重新部署，并要求他们在此调查这种可能性。
- 日志和错误度量标准可以是团队认为合适的任何东西，但是管理层要求团队要么自行开发钩子，要么找到一种解决方案，以将生产警报集成到整个公司使用的现有错误跟踪工具中。
- 编程语言可以是团队内部一致认可的任何语言。管理层相信，团队不会选择不适合当前任务或将来无法维护的晦涩编程语言。
所有权意味着对团队自身理性行动能力的信任，这使团队承担的责任似乎更像是批准而不是问责制。责任数量并没有减少，相反，团队现在要承担更多责任。这就是大多数Career Managers™无法理解该概念的原因。考虑分配了与数据库相关的bug的工程师的内心想法。在场景1中，无论出于什么意图和目的，他都没有决定采用该技术，甚至可能决定反对该技术，但是对于毫无意义的政治解释无耻地否决了该技术。该员工对修复该错误实际上有多大责任感或动力？在方案2中，由他自己决定采用该数据库技术，管理层相信他会这样做，因此给了他更多的动力来实际解决它，并且对他有更高的宣泄意识。任务失败。结论被指责为失败是每个人的痛苦经历，而大多数人自然希望避免这种事情。我个人造成了一个生产错误，这导致了未被发现的错误引起的滚雪球效应，进而导致我们服务的重大中断。如果我一直在零所有权和总责任制的氛围下工作，我的自然反应可能是精心梳理“ git blame”，直到检测到所有有罪的提交，然后再大胆地坚持更孤立的发布流程和对团队的严格控制自由，因为我现在遭受了其他人对自己的自由缺乏控制的痛苦，相反，团队感到共有的主人翁意识和责任感，这使我们对事件进行了集体验尸，确定了如何避免事件的发生。未来，然后像往常一样继续。我们再也没有发生过类似的事件。放弃控制是一件令人恐惧的事情，特别是对于Career Manager™。但是，如果这类指挥与控制型公司没有意识到通过所有权而不是作为责任来赋予权力的重要性，他们将继续看到其工程人才库迅速减少，而是被那些致力于避免责备。下一步，这给我们提出了最后一个亟待解决的问题：这些公司系统的本质是否与这种授权概念完全不兼容？拥有这些孵化器结合的星座甚至有意义吗？我要说的是，确实有道理，但它需要职业经理人及其与软件开发人员一起工作的同行提出一种革命性的新思维方式（这很讽刺）：接受生产错误并提高决策的透明度。这将在第2部分和第3部分中讨论。图像中使用的AttributionsIcons来自Vectors Market（在FlatIcon上，由Creative Commons BY 3.0许可）。