61、人机交互中的组织问题解析-优快云博客

本文链接：https://blog.youkuaiyun.com/stem5/article/details/150548383

人机交互中的组织问题解析

在当今数字化时代，人机交互无处不在。通常，我们想到人机交互时，脑海中浮现的是一个人坐在显示器前，使用键盘和鼠标的场景，这可视为当下人机交互的“基本单元”。然而，实际上大多数计算机的使用场景会极大地影响这种交互。

组织对人机交互的影响

组织背景对计算机系统的实施，也就是系统引入和使用，有着显著影响。以在家使用个人电脑的用户为例，他们依赖他人来指导硬件和软件的选择，受到制造商和经销商提供的支持水平的影响，同时供应商关于互操作性的决策也会对他们产生作用。

对于设计师和开发者而言，理解组织使用背景至关重要。了解系统引入和使用的相关知识，能在制定需求、寻找典型用户以及确定重要界面组成部分时提供关键见解。这里的界面广泛包括文档、培训和支持等。而了解开发背景，则有助于开发者预见挑战、选择合适的技术，避免在遇到障碍时将责任归咎于个人，而非组织的结构和流程。

组织自身在更广泛的背景下运作。随着全球对计算机访问和使用问题的关注增加，人机交互受到国家政策、立法、诉讼以及政府间谈判等因素的影响。组织可能首先对这些影响做出反应，但最终使用计算机的个人会感受到这些影响。

组织问题案例分析

曾经有一家名为“CompuSys”的大型计算机公司，聘请了顶尖的界面设计师，对销售团队内部使用的应用程序界面进行重新设计。该应用程序是一种专家系统，旨在帮助销售代表为客户配置复杂的系统，减少错误。然而，尽管构建了能够准确配置产品的专家系统，但只有一小部分订单使用了该系统，其他订单仍然受到代价高昂的错误困扰。

销售团队抱怨系统的可用性，于是公司对界面进行了重大重新设计，采用了包括用户反馈的迭代设计等多种技术，并对来自五个试点站点的用户进行了新系统培训，投入了数百万美元后，推出了改进后的界面。但新系统的使用情况并没有比旧系统好多少。

原因在于，设计基于的销售流程模型与实际情况不符。设计模型是客户确定系统需求，销售代表制定满足需求的系统配置，然后计算系统价格。但实际上，大多数客户有大致的需求和固定的技术预算，他们告知可花费的金额，销售代表需要根据此确定合适的系统。该应用程序不支持从价格到配置的“逆向”推理，只支持从配置到价格的单向推理，因此无法帮助销售团队，虽然界面可用但不实用。

开发者起初不理解为何可用的系统被忽视，最终通过组织（实际上是跨组织）分析，发现了这种“违反直觉”的工作流程。为避免此类错误，开发者可以检查工作环境，并在尽可能接近实际工作的条件下测试原型，同时可以学习组织理论和实践的相关文献。

组织的定义与理解

组织常被定义为具有共同目标或任务的人群集合，但这一定义同样适用于团体。团体不仅仅是成员的简单集合，成员之间的关系，即“团体动态”，是区分团体与随机个体集合的重要因素。类似地，组织可以被看作是“团体的团体”，其正式结构和定义团体间关系的动态过程，是区分组织与随机团体集合的重要因素。

要理解一个组织，可依据一般系统理论，先了解该组织在其参与的组织网络中所扮演的角色，再研究其组成部分，即具有结构化关系和动态交互的团体和个人。

组织的背景与组成

组织并非孤立存在，它们在更大的社会背景或环境中运作，可将其视为一个组织网络。以汽车制造公司AutoCorp为例，它与多种类型的其他组织进行交互，包括原材料供应商、人员招聘机构、各类银行和金融机构、营销服务公司（如广告机构）、分销渠道公司（如汽车经销商）、大客户（如汽车租赁机构）、竞争对手、个人客户以及广大公众。在这个交互的组织网络中，每个组织都扮演着不同的角色，有着独特的目标或“利益”，这些目标有时与其他组织兼容，有时则相互冲突。

在大多数有一定规模的组织内部，情况同样复杂和动态。组织由以各种形式组织的工作团体组成，这些团体又进一步形成更大的结构安排。例如，AutoCorp可能按产品部门（如汽车，包括跑车和豪华车等子类别；运动/多功能车和小型货车；卡车和工业车辆）、地理位置（如北美、欧洲、亚洲、非洲和南美）或所制造的技术或车辆组件（如发动机、动力传动系统、底盘、车身等）进行内部组织。计算机制造公司也可以按产品（如大型机、小型机、工作站、个人电脑）、功能（如硬件、系统软件、应用软件、支持）或其他基础进行组织。

不同的组织团体、部门、部门和其他类型的单位，即使组织整体有明确的目标和利益，内部的个人、团体和子单位可能并不完全共享这些目标和利益。例如，计算机公司ComputerCorp的系统软件部门成员和硬件部门成员在先前的教育和工作经验方面可能存在很大差异。此外，这些部门的负责人可能面临截然不同的目标、绩效衡量标准和奖励。软件部门可能根据开发进度和预算进行评估，而硬件部门可能主要根据制造成本进行评估。这种差异可能导致各单位难以合作以实现组织的总体目标。

组织内部的工作团体和更大的组织单位可能形成独特的“文化”（假设、信仰和语言系统），这使得成员之间难以清晰有效地沟通。例如，在一些公司中，“销售”这一术语在不同部门有不同的定义。销售部门认为客户口头同意订单即为“销售”，而法律部门要等到合同签订，制造部门要等到采购订单录入制造控制系统，会计部门则要等到发票准备好才承认“销售”。公司内部语言差异导致在关键组织决策上存在广泛不同的观点。

组织差异的总结

一般来说，在组织内部和组织之间同时存在至少三个层面的现实。第一个层面可称为理性、技术或经济现实，该层面以既定目标为前提，关注实现目标的最有效和高效手段。第二个层面是社会情感任务现实，人们有社会需求，组织是他们满足这些需求的工具。此外，由于人们是组织团体和子单位的成员，他们在组织中习惯了特定的思维和行为方式，这些方式有时与外部观察者认为的理性、技术经济最优方式有很大差异。第三个层面是结构/政治层面，涉及由单位和任务链（通常称为业务流程）或组织间网络中的资源和职位所产生的目标和利益。牢记这三个现实有助于理解组织行为的复杂动态。

组织之间以及其组成的工作团体和子单位之间存在一些重大差异类别，这些差异会显著影响信息技术的使用：
1. 成员数量规模 ：成员数量的多少会影响组织的沟通效率、决策速度等。
2. 财务资源规模 ：特别是来自过去财务成功或强大支持者的“闲置”（未承诺的资源）资源。
3. 地理和空间因素 ：包括业务范围和建筑物内的空间布局等。
4. 组织年龄、成员人口统计学和员工平均任期 ：反映组织的经验和稳定性。
5. 明确或隐含的目标或战略 ：如低成本生产者与产品创新者的区别，这决定了“关键业务流程”。
6. 组织结构基础 ：如产品、地理、功能、技术、时间等。
7. 组织文化 ：包括信仰、假设、语言系统和特征行为模式等。
8. 管理系统 ：如绩效衡量、奖励、晋升模式等。
9. 信息技术基础设施 ：包括对特定技术方向的先前投资历史和承诺，以及信息技术治理模式。

差异类别	影响说明
成员数量规模	影响沟通效率、决策速度等
财务资源规模	影响资源调配和发展潜力
地理和空间因素	影响业务覆盖和内部协作
组织年龄等	反映组织稳定性和经验
目标或战略	决定业务流程和发展方向
组织结构基础	影响组织运作和协调方式
组织文化	影响成员沟通和协作氛围
管理系统	影响员工激励和绩效
信息技术基础设施	影响信息技术应用和发展

由于存在这些差异，组织、子单位和团体对“相同”技术的反应可能截然不同。

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px
    A(理性、技术或经济现实):::process --> B(实现目标的手段):::process
    C(社会情感任务现实):::process --> D(满足社会需求):::process
    E(结构/政治层面):::process --> F(资源和职位产生的目标利益):::process

以上内容深入探讨了组织对人机交互的影响，通过实际案例分析了组织问题在系统设计中的体现，同时对组织的定义、背景、组成以及组织差异进行了详细阐述。这些知识对于从事人机交互相关工作的人员，如设计师、开发者、采购者、用户和研究人员等，在规划系统采购、开发更可用和有用的软件、定位研究方向以及管理职业生涯等方面都具有重要的指导意义。

人机交互中的组织问题解析

交互式系统使用中的组织问题

从组织采用系统供内部使用的角度来看，交互式系统使用过程中存在多个阶段的组织问题，这些问题会对系统的最终效果产生重大影响。

启动阶段

在启动阶段，组织需要做出采用新的基于计算机的技术或进行需要信息技术支持的组织变革的决策。这个决策过程往往十分复杂，创新的推动力可能来自组织外部，比如管理顾问建议客户公司采用Lotus Notes来“管理智力资本”和“支持知识工作”，或者供应商说服公司的首席信息官（CIO）某款群件产品可作为电子通信、文档管理和团队合作的基础设施。推动力也可能来自组织内部，例如首席执行官（CEO）参观供应商后，对其采用Lotus Notes所取得的效益印象深刻，或者信息系统（IS）部门内的技术扫描或投资组合规划小组将群件确定为高优先级的投资技术。

技术投资想法的来源会对后续事件产生重要影响，它会影响所购买、构建或使用的技术或软件包的功能，影响组织内各方对创新的使用方式以及创新的影响。最初提出创新的个人或团体可能没有正式的组织权力或资源控制权来进行收购或开发，他们需要寻求授权决策者的批准。不同组织的审批流程差异很大，有些可能只需向控制足够预算的“一线”高管进行个人诉求，而有些则有专门指定的审批委员会和正式的技术支出审查和批准流程。

组织政策可能要求发起者准备正式提案，以证明投资的合理性，通过展示创新符合预先设定的投资标准（如投资回报率或与现有战略信息技术计划的契合度）来说服决策者。然而，一些投资标准可能并不适用于创新项目，技术倡导者在应用这些标准时可能需要对技术使用、风险和收益的描述进行一些调整。

在论证过程中，组织内的各方可能会对技术的用途形成共同理解，这有助于后续的实施和接受。但这种共同理解可能与技术的客观能力以及为实现组织最大利益所需的使用方式不完全一致。例如，Lotus Notes可能被视为解决桌面计算架构老化或维护成本高的自制电子邮件系统问题的低成本解决方案，但用户可能从未充分利用其讨论数据库功能。

当技术收购的推动力来自强大的组织决策者时，创新可能不会经过严格的论证、审查和批准。决策者可以直接提供获取和开发技术所需的资源，但这并不能保证技术能满足组织的实际需求、符合组织的工作方式并被实际使用。例如，信息系统部门可能已经致力于另一种技术解决方案，不会全力支持CEO的项目；潜在用户可能看不到技术对个人的好处，从而拒绝使用。

在启动阶段，通常会确定项目的时间表、资金水平以及资金在不同项目活动中的分配。这些决策虽然有时可以在项目出现进度延迟或预算超支时重新审视，但它们往往会对后续产生持久且并非完全积极的影响。例如，限制Lotus Notes仅供特定工作单元使用，可能会给跨工作单元的活动带来困难；决策者可能为获取或开发技术分配了足够的资源，但却严重低估了用户培训和支持的资金，导致技术投入使用后出现可预见的负面后果。

采购阶段

一旦技术投资提案获得正式批准和资金支持，通常会任命项目负责人来监督项目的下一阶段。此阶段的主要活动是获取创新所需的能力并使其投入运行，但可能会出现一些困难。

首要问题是项目团队可能仅从技术角度定义交互式系统所需的能力，专注于软件功能、访问硬件和网络要求，而忽略了用户培训和支持，以及组织方面的必要变化，如工作描述、绩效评估和奖励等。这种做法几乎总是会导致下游出现问题，如用户接受度有限、使用水平低和使用质量差。

即使项目团队将“实施规划”纳入其职责范围，问题仍然可能出现。如果技术设计或选择不当，无论是否进行培训、支持或让用户参与设计或选择，接受和使用问题通常都会发生。因此，详细审查设计/选择过程非常重要。

在采购阶段，项目团队在做出决策时会受到内部和外部各方的影响。例如，一些团队成员可能强烈希望在内部构建技术，即使外部供应商有完全合适的软件包；有些成员可能希望根据组织的独特需求定制软件包，而不是改变组织的工作方式；团队成员对技术供应商、软件包或基础设施平台或架构可能有不同的个人偏好；或者他们可能要求解决方案包含某些功能；为了满足时间表和预算，原始提案中的某些项目方面可能会被推迟或完全放弃。

采购阶段的谈判结果取决于多种因素，包括项目团队的组成（是否包括用户）、适用于项目的组织政策和实践（如规定的系统开发方法或购买软件而非内部构建的公司政策）以及独特的项目团队动态。例如，在前面提到的CompuSys案例中，项目团队中的技术专家成员没有听取或拒绝听取用户成员关于将CONFIG与他们的自动报价系统完全立即集成的反复请求。

采购阶段的最终结果是，创新变得更加具体且更难改变。在编写详细规格、获取潜在用户的意见、与供应商签订合同以及与设施专家、安装人员、运营和支持人员、培训人员和用户经理进行安排的过程中，会发生各种组织变化。首先，创新的技术特征至少在一段时间内会“固定”下来；其次，会制定并执行（或不制定和不执行）计划，以提高组织及其人力资源有效使用技术的能力；第三，对技术用途和使用方式的看法通常会稳定下来，并延续到使用阶段。这些变化可能朝着积极或消极的方向发展，既可能将考虑不周的高管决策转化为可行的计划，也可能将合理的高管目标转化为昂贵的基础设施项目，而缺乏实现可衡量商业价值所需的应用程序和熟练用户。

此外，采购阶段还会建立各种组织内部和外部团体之间的社会关系，这些关系将在技术的“使用”阶段发挥作用。这些社会关系对项目生命周期的后续阶段可能产生深远影响。例如，用户解决“日常计算机使用中的反复出现的难题”的能力可能严重依赖于各种维护和支持人员；由于一次性培训计划没有解决高级培训或新员工初始培训的需求，用户技能可能停滞或下降。简而言之，采购阶段所确定的内容是否能满足组织未来的需求是不确定的。

实施和使用阶段

虽然采购阶段的决策会对后续结果产生重要影响，但实施和使用阶段的活动仍可能极大地改变之前获得的能力，并影响技术使用生命周期的下游阶段。

有些项目团队在采购阶段没有充分考虑让用户参与设计、提升用户技术技能或改变组织结构和政策，只是将技术产品“扔给”用户和他们的经理。这种做法通常会导致技术无法被使用或无法充分发挥作用以实现组织预期的效益，但有时一线经理和用户会看到这些技术的潜力，并将其视为自己的工具。不过，这可能需要一线经理在培训、促进、支持以及政策、程序和结构的改变方面进行大量投资，而这些投资通常在最初的项目提案中并未预算。

当用户和他们的经理采用技术时，不能保证他们会按照发起者或项目团队的最初设想使用技术。技术专家通常认为信息技术的适当使用等同于其功能，并且可以在随意浏览过程中轻松推断出技术的功能和适当使用方式。但这种假设是基于对用户和典型用户学习新技术过程的严重错误理解。研究表明，即使是像数字电话系统这样中等复杂程度的信息技术，普通用户也只使用其功能的一小部分。典型用户（与技术专家通常所说的“高级用户”不同）不喜欢学习新技术的过程，甚至可能会有中度到重度的恐惧反应。他们通常只学习完成手头任务所需的技术知识，并且经常通过向同事（可能比他们熟练程度高不了多少）寻求帮助来学习，而不是查阅手册、在线教程、专家或帮助台。一旦他们达到一定的熟练程度，除非新版本发布、进行转换或工作压力发生重大变化，否则他们通常不会再学习新功能。用户经常会采用耗时且低效的“变通方法”，而不是投入时间、精力和承受痛苦去学习更高效的程序。

这种学习动态意味着用户对技术创新用途的理解可能与技术供应商、发起者、开发者或实施者的理解大不相同。例如，有些组织中的人们既不使用Lotus Notes的电子邮件功能也不使用其分发列表，而是将其视为文档存储库和“新闻源”。相反，用户有时也会过度使用简单的信息技术，从这些技术中获得超出设计者预期的价值。例如，有两个组织将非常简单的电子邮件系统有效地用作全功能的群件系统，人们通过该技术支持多对多的面向团体的通信，而该技术原本更适合支持一对一的私人通信和一对多的广播通信。

在技术被“过度使用”的情况下，人们首先会在已经以其他方式进行的活动和流程中使用新技术。这些初始使用可能并不经济，即新技术相对于旧技术在这些使用场景中可能没有真正的相对优势。但一些用户会从早期试验中更多地了解技术，并最终尝试有价值的新用途。其中一些新用途涉及将新技术与旧技术互补使用，而不是替代旧技术。例如，一家公司的经理将电子邮件与电话结合使用，下属先在电子邮件中详细记录问题或决策情况，然后再打电话给经理，这样比单独使用电话或电子邮件能更快速地进行讨论和获得批准。这些在技术首次获取时未被预料到的新用途，往往会导致所谓的组织“变革”，如业务流程的重大改进、世界首创的新产品和服务等。

用户对技术进行重新定义并以与开发者、发起者和实施者预期不同的方式使用技术的过程，被称为“再发明”。再发明很重要，因为它意味着技术的使用及其影响在采购阶段无法完全确定。即使项目团队让用户参与设计并制定了精心的技术实施计划，用户和开发者可能直到技术在组织中实际安装并运行后，才会看到技术的真正组织影响。例如，在CONFIG系统的案例中，开发者在事后才发现设计缺陷，但在当时，开发者和用户可能都没有认为这是一个致命缺陷。同样，在Orlikowski广泛引用的Alpha Corp使用Lotus Notes的案例研究中，事后看来，顾问由于工作压力大、时间使用目标严格以及担心他人会窃取自己的想法而不愿意将数据输入Lotus Notes数据库是显而易见的，但批准Alpha Corp在Notes上进行巨额财务投资的高级合伙人肯定是被技术专家说服，认为“只要建好了，他们就会来”。

在生命周期的使用阶段发生的再发明意味着，在一定程度上，使用模式（以及随后的组织影响）是自然出现的。良好的设计实践（如让用户参与）和整体设计（即除了技术和经济方面，还考虑工作的社会和政治方面的设计）当然很重要，但我们必须认识到，用户使用技术时会发生什么是无法完全预测或控制的，我们将这种现象称为“涌现”。有时使用过程中出现的结果比供应商、发起者和实施者所希望的要少得多，有时则要多得多。

影响和绩效阶段

信息技术的使用是一个持续的过程，即使技术相对稳定，随着人们在组织问题的背景下尝试技术功能并发明新的用途，使用也会随着时间的推移而演变。但技术本身或其使用环境很少能保持稳定。

以CONFIG系统为例，开发者对其初始使用水平低感到失望，为了解决这个问题，他们为系统开发了全新的界面并进行了“重新实施”，在技术平台和用户培训及支持方面投入了大量资源。虽然这一努力对CompuSys来说没有取得成效，但在许多其他组织中是有效的。“如果一开始不成功，就再试一次”的原则在创新领域尤为适用，“坚持下去”和“再次尝试”是众所周知的成功因素。一些专家估计，创新所带来的大部分好处来自后续的修改和增强，而不是初始的改变本身。例如，Frito - Lay直到开发了分析工具以改进产品促销决策并改变促销决策的组织层级后，才从其手持计算机项目中获得全部优势，这距离最初的技术投资决策已经过去了大约10年。同样，一个组织可能需要几年时间才能开发出使其对Lotus Notes的投资获得回报的“杀手级应用”文档数据库。

重要的是，必须仔细跟踪和管理对创新的后续改进。在人类活动的许多领域，对基本创新的后续增强可能只是表面的“花架子”，虽然能取悦用户或开发者，但不一定能提高工作流程、组织沟通和决策或客户服务的效率。事实上，信息技术投资未能提高组织绩效的一个主要原因是组织倾向于对其信息技术环境进行无增值的改进。

当技术的使用达到一定阈值时，就会开始产生可观察到的影响。信息技术带来的积极组织影响通常可分为四类：由信息技术支持的新产品和服务、改进的业务流程、由于数据库和分析工具而改善的组织决策以及由于通信、协作和协调技术而提高的组织灵活性。然而，需要注意两个问题。

首先，技术投资带来的积极组织影响并不总是能转化为以各种组织利益相关者认为重要的指标衡量的组织绩效提升。例如，像CompuSys这样的计算机制造公司可能实现了业务流程的改进（减少了客户发货错误），但可能无法提高整体盈利能力、市场份额或客户保留率。如果创新很快被竞争对手复制，或者改进只是使公司绩效达到现有客户的期望，那么即使有积极影响，绩效也可能不会提升。同样，一所大学通过远程学习项目吸引了新学生，但可能会发现其传统地理市场被其他有类似项目的远程大学“抢占”，最终并没有比创新前更好。最终，将影响转化为组织绩效的能力取决于许多因素，并非所有因素都在创新组织的控制范围内，如竞争对手的行为。

其次，积极的组织影响几乎总是伴随着组织生活某些方面的负面影响。例如，电子邮件等电子通信技术带来的组织效率和灵活性的提高可能伴随着人际关系的淡化、压力、信息过载和问责政治等问题。组织可能会找到减少负面影响的方法，或者认为负面影响是为获得积极利益而付出的小代价，但即使组织希望消除负面影响，也往往无法完全做到。为了采用新的工作方式，组织通常必须放弃与以前工作方式相关的社会互动模式，尽管组织中的人们可能重视组织功能的改善，但他们仍然可能会为传统工作方式的消逝而感到惋惜，因为这些传统方式赋予了他们工作生活意义和质量。此外，负面影响可能无法消除，因为它们支撑或促成了积极影响。例如，一家公司的经理为了保留电子邮件作为战略讨论的有用工具，禁止将电话用于工作相关目的，但这导致人们感到疏远和人际关系淡化。为了应对这一问题，公司又广泛使用电话来保持与他人的个人联系，但不用于业务目的，以免破坏通过电子邮件进行业务的纪律。同样，电子邮件能够记录项目进展和比较承诺与实际情况的优势，也可能导致一种明显的负面使用模式，即人们会跟踪他人的承诺和履行情况，当承诺未兑现且组织结果受到影响时，他们会通过向自己和违规者的上级转发电子邮件副本，使自己显得无责而让他人承担责任，这种做法会迅速破坏组织氛围。

总之，影响会随着时间的推移而变化，它们对组织绩效的贡献可能增加或减少，可能会因为缺乏集中管理而被浪费。此外，积极影响可能无法对组织绩效的重要指标产生持久影响，因为它们可能会被竞争对手的行动和市场中客户的反应“抵消”。最后，无论出现何种积极影响，都可能不可避免地伴随着负面影响，这些负面影响通常会影响工作场所的社会关系。

以下是交互式系统使用各阶段的总结表格：
|生命周期阶段|描述|挑战和影响|
| ---- | ---- | ---- |
|启动阶段|产生想法、项目论证、项目资金决策、确定项目负责人|想法可能不可行或不是对技术的最佳利用；功能可能在分析前就被选定；实施可能资金不足|
|采购阶段|更详细地指定解决方案、用户组织获取或构建系统|设计过程可能促进或限制接受；解决方案可能指定不明确；支持关系网络建立；培训可能不足|
|实施和使用阶段|内部部署、首次使用或拒绝|使用可能不符合计划；用户可能重新发明技术|
|影响和后果阶段|组织体验效果、采取措施增强、减轻或管理影响|系统被修改和增强；培训需求演变；后果显现|

交互式系统开发中的组织问题

组织问题不仅影响系统的用户和客户，也直接影响开发者，同时在开发者和用户组织之间起到中介作用，并对影响设计和开发的经济、文化、政治和社会条件做出贡献。

不同开发背景的出现

开发者清楚组织会通过时间压力、审批流程、正式规格和其他管理实践来限制他们的工作，但不同组织的这些限制差异很大，而且其中一些差异是系统性的，基于历史因素和行业不同细分领域的开发条件。这些差异有助于确定哪些技术和工具将是有用的，组织的结构和实践对开发的人机界面有明显和微妙的影响。

组织影响技术使用的差异也会影响开发，如规模、地理位置、年龄、功能、文化和环境等。例如，小的初创公司中所有员工经常相互见面，而在大的组织中，软件、文档和培训开发者可能在不同的州或国家工作。在社会层面，美国关于“外观和感觉”侵权的法院判决和欧洲的共同决策法律会影响开发的过程和产品。

开发者与技术最终用户的关系是人机界面设计的核心，因此我们关注组织功能和结构对开发者与用户互动可能性有重大影响的开发背景。主要有四种开发背景：竞争性投标合同开发、内部或内部开发、产品或软件包开发以及定制开发。前三种组织背景差异很大，定制开发则兼具其他几种背景的特点。这几种背景并不是全部，而且组织的重要差异（如规模、年龄和文化）会在每种背景内提供更多的变化。

不同开发背景的差异往往被忽视，人们倾向于将“计算机行业”视为一个单一的实体。学术培训通常是通用的，开发者在职业生涯后期才会进行专业化。然而，围绕合同、内部和产品开发的关注点已经出现了不同的研究学科。软件工程的形成是为了解决管理大型项目的问题，通常是竞争性合同授予的结果；信息系统专注于大型用户组织内部的系统开发；人机交互则关注开发商用现货软件时出现的问题。这些不同学科之间的界限正在逐渐消失，合同开发和内部开发的软件不再是独立的，必须与商业产品共存并提供质量相当的人机界面。商业软件开发人员在开发群件应用程序或功能时，必须更加关注用户组织中的社会因素，而这些因素长期以来一直是内部开发人员所面临的挑战。不幸的是，现在不同学科有不同的文献和术语，跨学科交流是一个挑战。

下面是四种开发背景的详细介绍：
- 竞争性合同开发 ：在20世纪60年代中期集成电路计算机出现之前，系统极其昂贵，大多数大型系统由美国政府通过合同委托开发。政府机构定义需求，地理上分散的组织进行投标，不同的合同可能分别授予设计、开发和维护阶段。开发者和用户处于不同的组织，通常在地理上分离，并且由于法律限制沟通以防止任何投标人获得不公平优势，这为开发者与用户的直接接触设置了重大的组织障碍。在这种环境下，基于规格、先设计的方法，很少考虑反馈或迭代的瀑布模型成为主导的开发方法。当交互式软件变得普遍时，这种方法的局限性被认识到，Boehm等人引入了螺旋模型以明确纳入交互式软件开发的原型设计和迭代设计。然而，开发者与用户的分离仍然是合同开发中界面设计的主要组织障碍。
- 内部或内部开发 ：20世纪60年代中期，随着更可靠、更便宜的大型计算机的出现，企业对计算机的使用增加，用户组织内部开发软件成为系统开发的主要焦点，并且可能仍然占大多数开发。尽管大多数处理仍然是批处理而不是交互式的，但在这种组织背景下，瀑布开发模型很快受到挑战。与合同开发不同，内部开发中用户和开发者在同一雇主下工作，通常距离更近，用户与开发者之间的互动障碍相对较小。然而，组织和文化障碍仍然经常阻碍用户参与。一些信息系统团队受“一次性设计正确”的开发理念影响，未能寻求用户的持续参与，年轻、高薪的信息系统员工可能与其他员工在“文化”上发生冲突，作为拥有权力和权威的变革推动者，他们会遇到阻力。不过，也开发了一些方法来促进用户参与，如社会技术方法和斯堪的纳维亚的参与式设计方法。
- 产品或软件包开发 ：20世纪80年代初个人计算机出现后，商业现货产品开发成为一个主要行业，专注于高度交互式的系统和应用程序。这些应用程序的竞争市场导致更加注重人机界面和更大的时间压力。与合同开发和内部开发相比，产品开发组织对开发者提出了不同的限制。在这种背景下，开发者先确定，而具体用户在开发完成后才明确。瀑布开发方法在这种组织背景下显然不适用，研究人员从一开始就提倡原型设计和迭代设计，并大量让用户参与。尽管这些原则被广泛接受，但由于组织限制，它们并未被广泛实践。开发者在寻求用户参与时可能会遇到困难，包括难以确定合适的用户、难以获得对用户的访问权限以及难以激励在其他组织工作且可能永远不会使用最终产品的用户。即使克服了这些障碍，使用收集到的信息也可能存在障碍，开发时间表通常不提供迭代的时间，界面的变化可能会让管理层以及负责产品文档和培训的人员感到不安。
- 定制开发 ：定制开发结合了前三种背景的特点。定制开发组织与用户组织不同，但合同不一定是竞争性投标的，选择可能部分基于地理位置接近。这种开发允许长期、密切的参与，实际上将内部开发的某些方面融入了过程。如果定制开发组织能够成功找到具有相同需求的客户，他们可能会接近产品开发，甚至将其软件发展成为商业产品。许多小型Lotus Notes应用程序开发者遵循这种模式。随着软件需求变得越来越多样化和专业化，定制开发可能会蓬勃发展。定制开发对于专注于记录上游设计过程以便后续用于重新设计或维护的人机交互工具可能特别有前景，因为在这种背景下，设计、重新设计和维护通常由同一批人完成。

以下是四种开发背景的总结表格：
|开发背景|描述|可用性问题|
| ---- | ---- | ---- |
|竞争性合同|用户和开发者在不同组织，用户先确定，合同通常针对单个开发阶段|持续用户参与存在极端障碍；依赖中介：顾问、标准；需要人机交互意识和过程关注|
|内部或内部|用户和开发者在同一组织，用户和开发者一开始就确定，开发团队负责所有阶段|用户参与机会良好；文化和组织障碍可能阻碍参与；工具可帮助克服资源限制|
|产品或软件包|用户和开发者在不同组织，开发者先确定，特定用户后确定，开发团队可能移交修订|在可用性方面领先，但实用性常被忽视；需要进行工作场所研究但可能困难；面临时间压力、现有用户基础等挑战|
|定制|不同组织但有持续关系，用户和开发者在项目早期确定，开发团队处理多次修订|随着时间推移有良好的用户反馈机会；小众市场意味着界面资源较少；可能是人机交互工作增长最大的领域|

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px
    A(竞争性合同开发):::process --> B(瀑布模型为主,分离开发者与用户):::process
    C(内部或内部开发):::process --> D(挑战瀑布模型,促进用户参与):::process
    E(产品或软件包开发):::process --> F(强调原型和迭代,组织限制实践):::process
    G(定制开发):::process --> H(结合多种特点,有发展潜力):::process