问责制被认为是个人与其社会系统之间的纽带，它创造了一种将个人与其行为和绩效联系起来的身份关系。在入门系列的第一篇文章《超越工具和流程：成功软件开发团队的策略》中，我们介绍了问责制的概念，并提出了以下定义：

期望对自己的行为负责，并需要在未来向他人提供此类行为的解释和理由。

无论集体的性质如何，从二元组到文明，解决其成员之间利益分歧的协调与合作都是必不可少的。问责制通过在社会系统中建立共同的期望来发挥作用。当制定了标准和期望时，人们必须遵守，否则可能会受到惩罚。社会系统的各个层面都会评估对标准的遵守情况，包括个人、二元组、团体、组织和整个社会。

问责制是所有社会（包括组织）的基本推动因素。如果社会体系缺乏问责制，个人行为将不顾他人造成的后果。因此，组织可能发现有效管理其运营具有挑战性。在软件开发中，问责制早在 80 年代的先驱者工作中就得到了承认。在 Barry W. Boehm 关于“软件工程七项基本原则”的论文中，他提出了一项确保对结果负责的原则，即“对结果保持明确的责任制”。

此外，“问责制”在 Scrum 指南中出现了九次。该指南非常强调问责制作为一种控制机制，例如“让彼此 [开发人员和团队成员] 以专业人士的身份承担责任”。那么，问责制如何控制和改善软件团队的成果呢？

图 1 直观地展示了追究责任的过程。它由一个评估过程组成，在这个过程中，个人要对自己的行为和决定负责，并受到特定社会文化背景下的人际、社会和结构因素的指导。受众会评估个人是否符合预先定义的规则、标准、官方和非官方期望以及共同规范，从而给予奖励或处罚。作为回应，个人会发展出各种应对机制，既有主动的，也有被动的，以维护和维持其社会体系中一致的自我形象。其中一些机制可能包括认知策略，例如将行动与受众偏好保持一致，或事后合理化，即个人用理由和借口为过去的行为辩护。虽然传统的问责理论通常将“受众”视为一个单一的实体，但它可以解构为一个由多个参与方组成的网络，个人需要对这些参与方负责。

在我们最近的研究中，我们研究了软件工程中问责制的构成要素，报告称，软件团队成员需要对多个问题承担个人和集体责任。

图 1：社会体系问责制的动态

项目成果，主要是软件质量、软件安全性和满足项目期限。业务分析师与软件团队中的其他角色共同承担这些成果的责任。

业务分析师 (BA) 共同负责软件质量、安全性和项目期限，因为他们的职责涉及定义直接影响这些结果的需求。通过收集业务需求并将其转化为技术规范，BA 可确保软件符合质量标准并按预期运行，这对于最大限度地减少缺陷和安全漏洞至关重要。此外，他们在生成构建软件的需求工件方面的作用会影响时间表，使团队工作与项目期限保持一致。当 BA 无法提供准确及时的需求工件时，就会对时间表产生影响。因此，让他们与开发人员和其他团队成员一起承担责任。

正式问责

组织有意实施策略来推动软件团队成员的责任感。这些制度化的驱动因素包括财务奖励、职业发展和惩罚。这些正式化的策略影响个人对责任感的看法，从而塑造他们对实现团队预期结果的承诺。虽然奖励旨在强化积极的表现，但惩罚旨在起到威慑作用，通过让工程师意识到潜在的负面后果来阻止他们表现不佳。

财务奖励。在上述研究中，我们发现软件团队成员在一定程度上受到财务奖励前景的激励，以满足既定期望。其中一些奖励包括财务激励，特别是与绩效评估挂钩的年度奖金。财务奖励，无论是奖金、加薪还是晋升，都用于坚持责任感并激励个人满足既定期望。

职业发展。在我们的工作中，职业发展也被认为是一种激励责任感的因素。组织会通过职业发展来奖励达到预期结果的期望。我们的研究结果表明，在软件专业职业中获得晋升的动力与表现出强烈的责任感密切相关。

惩罚。组织采用惩罚策略来激励表现不佳的团队成员达到或超过既定的预期结果。惩罚策略包括纠正措施（如绩效改进计划）和失业。惩罚策略表明，在某些情况下，组织致力于通过对未能达到预期结果实施明确的惩罚来推动软件专业人员的责任感。

控制机制是组织制定或嵌入软件开发实践的各种流程、工具和程序，旨在确保个人能够履行职责并遵守既定期望。在问责制的动态和流程中，控制机制属于图 1 中的“评估”。为了控制制度化的正式问责制，绩效评估作为一项问责制定期进行。这些定期评估推动了问责制，因为它们要求对组织就预定义期望的绩效负责，依靠代码中的缺陷计数和同行的反馈等指标，确保工程师始终如一地努力达到或超过组织既定的期望。

共同责任

共享或非正式的责任感源自同事的期望和软件专业人员的内在驱动力。前者促进了一种集体责任感，个人感到有必要回报同事并向同事展示自己的责任感，而后者则是天生的，具有内在基础。当软件专业人员感到内在驱动力以达到某些结果（例如，代码质量或按时完成任务）时，他们会表现出一种自我驱动的责任感。这种自我要求的责任感源于个人渴望超越或达到自我要求的标准，反映了软件专业人员的内在承诺和动机，即坚持和保持其交付成果的质量与他们的职业和个人价值观保持一致。共享责任感主要通过软件工程和开发实践（即测试和代码审查）以及同事的反馈来强化。

这种基于同行的问责制使用软件开发实践中固有的控制机制，例如测试或非正式同行的反馈，而不是既定组织的流程（如绩效评估）。

非正式或共享责任归因于团队的共同规范。然而，回报并不类似于正式的责任制（即财务奖励和职业发展）。在软件开发环境中，软件专业人员对同事的期望感到有责任，希望得到同事的评价，并为集体努力做出贡献。此外，避免团队层面的制裁。相反，我们的研究表明，软件团队更喜欢一种心理上安全的方式来应对表现不佳。

软件专业人员的责任不仅受到制度化机制（例如绩效评估）的影响，还受到同事的期望和内在动机的影响。虽然绩效等传统责任控制机制在软件团队中具有相关性，但它们与同事驱动和内在动机驱动的责任共存。

我们的工作表明，软件专业人员对同事驱动和内在动机驱动的责任有着天然的倾向。因此，在下一篇文章中，我们将深入探讨这种责任如何发生以及如何有助于满足团队成果的期望。