如果科技是在构建未来，那么我们是否曾停下来思考我们正在构建什么样的未来？我们专注于快速发展，打破常规，持续交付，但我们是否花时间考虑谁会被排除在我们所做的事情之外？
也许我们正在制作的工具不会以我们所期望的方式被使用。或者，它的使用人群远远超过我们的想象--例如，如果它扩展到Facebook的28亿月活跃用户，会发生什么？
负责任地建设技术不仅仅是关于安全、弹性和正常运行时间。它还涉及 环境影响。还有隐私。最重要的是，我们必须考虑我们的社会影响，以及我们要求我们的用户在有意或无意中同意的事情。
随着科技变得越来越个人化--在我们的家里，在我们的工作中，在我们的车里，甚至在我们的身体里--那么我们作为其创造者的责任也必须增加。而随着科技行业继续面临巨大的人才缺口，我们比大多数人拥有更多的工作保障，能够大声说话和提出问题。我们应该利用这一特权。一个组织内的每个人都拥有我们正在建造的东西的后果，甚至我们选择连接的东西。
在这篇文章中，我们解释了一些简单的反思、机制和设计思维，将道德考虑纳入你的冲刺周期。
负责任的技术始于承诺。
当反种族主义的经济学家Kim Crayton在寻找一种组织策略来扩大知识经济中的归属感和心理安全时，她制定了四个 指导原则。
- 技术不是中立的。它也不是非政治性的。
- 没有战略的意图是混乱的。
- 缺乏包容性是一个风险和危机管理问题。
- 优先考虑最弱势的群体。
如果我们作为团队和科技组织将这些公理作为基础，是否会改变我们看待我们在其上建立的东西的方式？我们有多少次在优先考虑那些经历最多风险的人？Crayton说，为了真正创造出不仅可以而且应该扩展的技术，我们必须学会适应不舒服的情况。
当然，我们必须与用户一起工作，或者至少找到最接近用户的队友--我们在销售、客户成功、开发者体验方面的同事，并把他们带到战略桌上。不要简单地依赖你的现有用户，而是要确保你在一个更大的测试基地旁边进行测试和建设，有意为更广泛的人群设计产品，他们最终可能成为你的用户。
当然，遵循这些准则的最简单的方法是拥有一个多样化的、公平的和包容的团队，以减少建立一个没有人会使用的东西的风险--或者会以一种你甚至没有考虑过的方式来使用。从Crayton的原则开始，是记住建造技术所带来的权力和风险的一个好方法。
负责任的技术考虑其后果。
Doteveryone，一个前 英国的负责任的技术智囊团， 创造了一个有用的技术，叫做 后果扫描。这是一种产品团队的敏捷实践，可以不断确保一个组织正在建造的东西与它的文化和价值观相一致。它的目的是在产品的最初构想、路线图规划和功能创建期间进行。
你首先要回答关于你的产品的以下问题。
- 这个产品或功能的预期和非预期后果是什么？
- 我们想关注的积极后果是什么？
- 哪些是我们想要减轻的后果？
我们经常花很多时间来设定目标和维护预期功能的积压。如果我们使用行为驱动开发，我们也会花时间在这些预期的后果和用户体验上，然而非预期的后果却让我们无所适从。Doteveryone发现，技术通常具有这六种意外后果中的一种或多种。
- 缺少对数字的理解。 不明确的商业模式和政策导致人们对自己 "同意 "的内容缺乏了解。人们心甘情愿地将自己的DNA交给免费的祖先工具，以寻找失散多年的亲属，但据透露，警察部门正在使用这些数据调查犯罪。通用数据保护条例》或GDPR指南现在在所有欧洲用户的屏幕上弹出，但我们大多数人很快就从屏幕上清除了这一干扰，没有再了解这些cookies将被如何使用。由于女性和有色人种在IT团队中的代表性不足，缺乏了解的结果是男性建立的健康应用程序不包括月经跟踪器，或虚拟背景将肤色较深的用户的图像斩首。
- 意外的用户和用例。 人们总是会找到一种新的和意想不到的方式来使用你的应用程序。What3words是作为经度和纬度的一个更简单的替代品而建立的，但却被用来在 "黑人的命 "抗议活动中组织社会疏导。而有些人总是会找到新的方式来伤害别人，从骚扰一直到国家支持的选举干预。
- 可靠性、安全性、监控和支持薄弱。你将如何监测一个网站或服务的扩展，以防止意外或计划外的问题，如YouTube成为一个不受控制的极端主义管道。谁在验证政府为COVID-19大流行病创建的追踪应用程序的安全性和稳定性？它们为什么会崩溃？政府会提醒我们以后删除它们吗？
- 行为和规范的变化。这些变化从表情符号成为他们自己的语言，到屏幕成瘾，到我四岁的孩子试图刷电视屏幕来换频道。非接触式移动支付的使用可能使有细菌的货币不在我们手中，但它如何改变我们的消费习惯？
- 流离失所。这包括从技术性失业--自助结账和自动取款机取代收银员，聊天机器人取代客户服务代表--到使人们能够在家里开会、学习和工作。
- 对地球的不利影响。IT行业至少贡献了10-12%的碳排放。我们是否在考虑关闭视频自动播放来帮助减少我们自己产品的贡献？我们甚至在测量我们自己的足迹吗？环境影响的因素是否影响到我们的网站托管地？
我们把后果归结为负面的，但是，正如你在上面看到的，并不是所有的后果。它们只是经常不是预期的结果。重要的是，要集思广益，对可能的后果进行分析，并制定计划来监测、衡量和可能的补救措施。
惠康数据实验室的Aoife Spengeman开发了一个追求道德产品开发的免费研讨会，将其应用于评估实验室自己的算法。这个过程 将意外后果分类为：。
- 使用案例。产品的使用方式是创造者和用户都想使用的。
- 压力案例。产品以其预期的方式被使用，但它对用户产生了意想不到的后果。这就是通常所说的 "边缘案例"。
- 滥用案例。产品被某些人故意使用，而不是按照设计的方式来使用。
- 误用案例。产品被某人无意中用在了它的设计之外的地方。
惠康数据实验室用这个练习来评估一个机器学习工具，该工具是为了帮助内部团队深入了解惠康资助的研究是如何被引用的，旨在衡量研究对公众的影响。
该团队发现了一个主要风险：让用户误解该工具的工作原理，并对其准确性、全面性和产出意义做出假设，这可能会降低一些项目的多样性、包容性和资金。
例如，在全球北方写的论文被引用的比例过高。如果没有惠康公司提供这种背景，这种压力情况可能导致使用该工具的资助者延续这些系统性的不平等，只资助被引用次数最多的项目。此外，该工具对英语和以科学为中心的期刊更准确。用户可能会滥用该工具，认为其他语言或学科的研究影响力较小，而事实上，它只是不太可能被算法选中。
这项工作的结果是努力确保用户对算法的工作方式和它的局限性有更高的理解。
正如斯宾格曼写道："没有人可以防止最坏的情况发生，我们可以尽力想象事情可能出错的地方，并尽我们所能减轻风险。"
负责任的技术寻求将伤害降到最低。
开放源代码有固有的 多样性、公平和包容性问题。 Stack Overflow在2020年的调查中发现，"身为男性的开发者更有可能希望获得特定的新功能，而身为女性的开发者则更有可能希望改变我们网站上的交流规范。"这种要求经常与 "有毒 "和 "粗鲁 "等词语搭配在一起。 2017年的GitHub调查，其中只有3%的受访者是女性，1%的受访者是非二进制的， 发现一半的受访者都 "目睹过不良行为"，这些行为从粗鲁、骂人、刻板印象，一直到跟踪和彻底的骚扰。
此外，开源社区是分布式的，主要是志愿者，或者是维护组织的外部，这使得它本质上更难控制。此外，成功的开源项目可以发展到一个地步，即意外的后果和用例成为常态--因为当你达到Facebook的用户规模时，就没有边缘案例了。
产品设计师 Kat Fukui 在QCon活动中描述了她当时的雇主GitHub是 "开发人员连接和合作的最大平台"。
但这并不是它建立的目的。它开始是为了满足技术需求，而不是人类需求。
"深井说："GitHub的初衷并不是要成为一个社交网络，但我们在这里，它确实是，因为很多对话和人类互动都是围绕着构建代码进行的。
然而，随着GitHub规模的扩大，成为世界上最大的源代码主机，重点转移了，协作功能也被要求了。
深井在GitHub的社区和安全团队中，多年来围绕这些职责不断成长。
- 确保社区是健康的。
- 进行功能审查，确保它们不会引入新的滥用载体。
- 修复技术债务。
- 记录和放大团队自己的工作，以避免意外后果的重复发生。
这个团队的建立是因为，正如Fukai所说，"当GitHub在10年前成立时，我们不一定考虑到代码协作软件可能被用来伤害其他人的方式。"
因此，现在这个跨职能团队的工作是发挥创造力，找出任何功能可以用来伤害别人的方式。
根据Fukai的说法，"将用户安全纳入技术的基础是每个人的责任。无论你是经理、个人贡献者、设计师、研究员、[或]工程师，这都是每个人的合理性......因为每个平台或功能都可能而且会被滥用"。
对于每一个功能审查，我们都要问：这个功能如何被用来伤害别人？
当然，这也不仅仅是创造一个安全空间的人类动力。如果你没有到位的资源，在有人举报滥用时迅速采取行动，你将失去你的用户。
福井的团队应用了 用户故事的敏捷实践。用户故事是从用户的角度对一个功能进行的非常简短的描述--作为用户类型x，我希望y发生 z的理由。
在GitHub社区团队中，用户故事被用来识别压力案例。Sara Wachter-Boettcher在她的《技术上的错误》一书中扩展了创建压力案例的用户故事，特别是帮助建立对用户在可怕情况下的感受的共鸣，比如逃离虐待。
福井说，有意使用 "压力案例 "这一术语使边缘案例人性化。
"她说："即使它很少发生，有压力的边缘案例也会产生较大的负面影响，你会很快失去信任，特别是当它公开发生的时候。
她举了一个例子：当用户要求在GitHub内的私人场所进行聊天时，出现了一个压力案例的用户故事。正如我们所知，直接信息可以增强骚扰性。
在这个用户故事中，深井说明了用户正试图逃避来自虐待关系的骚扰性DMs。因此，团队传统上会问以下问题，并针对这个特定的用例给出答案。
- 他们遇到了什么问题？创建 "袜子傀儡账户 "真的很容易，这些账户的唯一目的是发送垃圾邮件或滥用。
- 他们的感觉如何？无能为力，担心自己的人身安全，甚至担心周围的人。
- 成功是什么样子的？支持部门必须有工具来最大限度地减少大规模滥用的影响，用户必须有权力阻止或关闭DMs。
用户故事不仅仅是创造用户的共鸣，找到功能的差距，以及围绕功能发布来调整组织，他们还带来了不同的观点和专门的知识。
用户故事还可以作为一个验证点。例如，如果你正在开发的其他功能可能会被滥用，那么你可以在未来的决策中参考这个用户故事。
然后，你可以把你的用户故事编织在一起，以安全原则或准则的形式建立一个伟大的技术基础。或者你可以从这些开始，就像这篇博文所做的，然后用这些标准来约束所有的用户商店。
就像敏捷生命周期中的所有事情一样，不断反思、回顾和迭代是非常重要的。
