摘要：对于企业领导者来说，很多技术决策由于考虑不充分或由于时间太短而出错。他们希望做出明智的选择，并且不会受到一些不利因素的影响。

   对于企业领导者来说，很多技术决策由于考虑不充分或由于时间太短而出错。他们希望做出明智的选择，并且不会受到一些不利因素的影响。
　　
　　当出现新技术时，企业领导者是否会尝试每一项技术创新?企业领导者如何在没有充分分析和尽职调查的情况下选择技术供应商?或者由于采购经理、项目管理者或业务利益相关者通过详尽的研究做出技术决策，以至于企业在采用创新技术之后却陷入了遗留平台的困境?
　　
　　这些决定技术购买的角色存在于许多企业中，这可能会削弱技术领导者做出明智和及时的技术选择的能力。随意的技术选择会导致企业浪费精力并出现技术债务，而过于有条不紊的方法会减缓创新的步伐，并阻碍明智的冒险和敏捷文化。
　　
　　这些角色可能以各种方式影响企业领导者的技术决策过程，其中包括阻碍企业的技术评估过程到影响何时投资技术以及考虑哪些产品或服务的决策。以下是企业领导者可能做出糟糕技术决策的12种情况。如果企业领导想做出明智的技术决策，不要执行以下操作：
　　
　　1.接受行政部门的意见作为最终决定
　　
　　当企业的首席执行官或其他有影响力的高管要求技术团队购买和实施特定的技术解决方案时，了解其基本原理至关重要。企业领导者试图解决什么问题?其解决方案满足预期的程度如何?团队领导者通常会听从企业高管的命令，而不是采取措施使方法合理化或提出替代方案。
　　
　　一种解决方案是制定和呈现愿景陈述的规则，重点关注问题、机会、价值主张。而精心设计的愿景陈述将定义目标，但并未规定采用哪些解决方案或实施方案。即使技术团队代表企业高管填写这些内容，也经常会引发对多种解决方案的讨论。
　　
　　2.未能征求或考虑客户的意见
　　
　　作为技术人员，有时会犯与企业高管相同的错误。他们通常会看到问题，并采用解决方案实施修复。不幸的是，企业领导者在决策过程中并没有考虑客户的意见，或者不了解对客户有什么好处，或者提供不符合要求的功能。
　　
　　当通过定义角色来开发最终用户的应用程序时可能会更容易。但是，在考虑后端功能(包括基础设施、安全功能、中间件、库或Web服务)时，寻找客户角色可能更具挑战性。但技术人员也是业务的一部分。在实施后端技术时，架构师、业务分析师或技术主管可以充当客户角色的代理，可以提供需求，确定验收标准，做出权衡决策，并评价他们对实施的解决方案的满意度。
　　
　　3.忽略现有的标准和技术
　　
　　从历史上看，技术部门一直在努力创建和维护文档以及沟通和管理标准。因此，当出现紧急请求或最高需求时，他们更有可能寻求新的解决方案，而不是调查和重用现有功能。
　　
　　这种方法通常会导致冗余能力、半开发的解决方案和激增的技术债务。在研究新解决方案之前或作为其一部分添加“研究内部解决方案”步骤是一个可以增加重用性的简单原则。当推荐新技术时，创建一个流程来评估对传统平台的升级或整合具有类似功能的技术。
　　
　　4.培育某种供应商和某种方法的技术文化
　　
　　很多企业通常会强调“我们是一家X店”，以此来减少对其他供应商或技术的任何研究、审查和考虑。拥有首选供应商是一回事，而对第三方一无所知并阻碍采用替代方案是另一回事。
　　
　　采用强大平台的少数声音淹没在任何探索和实验中可能会导致代价高昂的错误。技术领导者应该解决这种文化反模式，特别是当它妨碍人们提出问题或挑战现状的时候。
　　
　　5.假设构建或购买是唯一的选择
　　
　　使用自定义代码构建解决方案与购买SaaS或其他提供开箱即用功能的技术之间存在很大的灰色地带。介于两者之间的是高度可配置的低代码和无代码平台、商业合作伙伴关系以及利用开源技术的机会。
　　
　　因此，在构建或购买之间选择是一种简单化的做法。更好的选择是所需的功能是否有助于区分业务，以及从长远来看哪些类型的解决方案可以提供更多的创新和灵活性。
　　
　　6.假设API满足集成需求
　　
　　大多数现代SaaS甚至许多企业系统都提供API和其他集成选项。但是编目集成应该只是调查它们是否满足业务需求的开始。API公开了哪些数据?是否支持所需的视图和事务?企业能否轻松连接数据可视化和机器学习工具?API的性能是否足够，是否存在需要考虑的潜在使用成本?
　　
　　加速集成功能审查的方法包括这三种验证API和利用低代码集成平台的方法。
　　
　　7.未能履行社会尽职调查
　　
　　当人们面临很多解决方案时，可信赖的信息源可以帮助企业缩小竞争范围。而阅读博客、白皮书、评论和研究报告，以及观看网络研讨会、主题演讲和在线教程都是关键的学习步骤。但经常被遗漏的一种方法是利用社交网络向专家咨询。
　　
　　8.跳过概念验证(PoC)
　　
　　企业选择技术的艺术和科学涉及设计和执行概念验证解决方案(PoC)，以验证假设并测试关键战略要求。在验证新兴技术或评估SaaS平台时，概念验证尤其重要，但即使使用敏捷峰值来审查第三方技术组件，也有助于加快制定决策，并避免代价高昂的错误。
　　
　　最大的错误可能是跳过概念验证(PoC)，或者是因为企业只信任供应商，或者面临时间压力。而从概念验证(PoC)中学到的知识可以帮助企业将优先级导向可行的实施方案。
　　
　　9.没有制定详细的决策矩阵
　　
　　当许多人参与审查和评估新工具和技术时，帮助推动数据驱动决策的一种常见方法是创建决策矩阵电子表格。特性和功能按重要性加权，然后由审查委员会进行评级，并采用电子表格计算总分。
　　
　　不幸的是，当涉及太多人员、选择太多功能或分配任意权重时，这些工具很快就会失控。电子表格最终会优先考虑编制者的偏好，而人们通常查看一些无用的东西而忽略了需要战略性评估的内容。
　　
　　企业领导者在开始采用决策矩阵之前，考虑将解决方案的特征提炼为业务问题的本质，而不是要求由太多审核者评估众多的特性。
　　
　　10.忽略长期架构、生命周期和支持方面的考虑事项
　　
　　企业领导者需要通过基于易用性和价值实现时间来评估技术，但这并不意味着长期架构、维护和支持不重要或不需要评估。
　　
　　关键是决定何时对它们进行评估、关键考虑因素是什么、谁将参与审查，以及在评估中投入多长时间。这样做的一个很好的方法是将技术团队在评估开始时应该考虑的控制问题与应作为决策过程输入的长期因素分开。
　　
　　11.忽略SLA、数据保护和安全审查
　　
　　时间压力或盲目信任选择的技术是浏览服务等级协议(SLA)审查和评估供应商安全和数据保护实践的糟糕借口。做好这些审查的关键需要具备必要的专业知识、谈判技巧、工具和有效的评估流程，只有这样，技术人员和业务赞助商才不会将审查视为瓶颈。
　　
　　在内部执行服务等级协议(SLA)、数据保护和安全审查的大型企业必须高效，并集中精力将评估与最高风险保持一致。专业知识不足的是小公司应该寻求在解决方案领域具有专业知识的外部人员的帮助。
　　
　　12.延迟财务和法律审查
　　
　　最后但同样重要的是一个是进行财务和法律审查，很多企业并没有这些领域的专家。
　　
　　考虑到许多SaaS产品、API服务和云原生技术都有基于消费的定价模型，运营成本可能无法满足预算或财务限制的要求。法律审查对于受监管行业的企业或在全球范围运营的企业尤为重要，在这两种情况下审查合规因素可能特别耗时。对于财务和法律审查的延迟，企业可能会付出高昂的代价。
　　
　　不要等到技术审查过程结束才引入财务和法律专业知识人才。在此提出的建议是，在一开始就让他们参与进来，并在企业领导者做出任何技术决策之前权衡需要尽早审查的内容。此外，不要因为一次性进行太多评估，而使财务和法律人员的工作负担过重。
　　
　　对许多企业来说，试图兼顾多项技术评估是不现实的，企业领导者应该优先考虑他们的采购工作。如果这样做的话，开展智能、全面和高效的技术审查是可能的。
　　
　　编辑：Harris