做出真正糟糕的技术决定的12种方法

时间如此之短，技术决策出错的方式却如此之多。如果你想做出明智的技术选择，就不要让这些决策反模式阻碍你。

InfoWorld特约编辑

Kaspars Grinvalds / Shutterstock

当你看到新技术的时候，你是否像一个在糖果店里的孩子一样，兴奋地想尝试每一个最新的创新？也许你组织中的某个领导是个技术赌徒，在没有充分分析和尽职调查的情况下就准备选择供应商？或者，采购经理、项目管理办公室或业务利益相关者对技术选择进行了如此详尽的研究，以至于你的组织在创新之后被遗留在传统平台的泥潭中？

技术聚焦：

IT领导力

这些技术购买者的角色在许多组织中都可以找到，他们会破坏技术领导者做出明智和及时的技术选择的能力。杂乱无章的技术选择会导致浪费精力和技术债务，而过于有条不紊的方法会减缓创新的步伐，阻碍实验、聪明的冒险和敏捷的文化。

[也在InfoWorld：没有人愿意管理Kubernetes了]

这些角色会以各种方式破坏你的技术决策过程，从使你的组织的技术评估过程陷入困境，到损害关于何时投资于技术以及考虑哪些产品或服务的决策。这里有12种需要注意的反模式。如果你想做出明智的技术决策，那么就不要做以下事情。

接受高管的意见作为最终决定

当首席执行官或其他有影响力的高管要求技术团队购买和实施一个特定的技术解决方案时，关键是要向后退几步，了解其理由。这位领导想解决什么问题，该解决方案在多大程度上满足了人们的期望？很多时候，我听到技术领导人把高管的声音当作命令来接受，而不采取步骤使方法合理化或提出替代方案。

一个解决方案是建立起草和提交一页的愿景声明的纪律，重点是问题、机会或价值主张。精心起草的愿景声明定义了目标，但对解决方案或实施没有规定性。即使技术团队代表高管填写，也常常导致对多种解决方案的讨论和辩论。

未能征求或考虑客户的意见

作为技术专家，我们有时会犯和高管们一样的错误，在跳入实施过程中。我们看到了问题，我们知道了解决方案，一种紧迫感驱使我们去实施修复。不幸的是，由于在决策过程中不包括客户的声音，或者不了解客户的利益（或者不了解），我们很容易就会提供一些不符合要求的能力。通常情况下，企业甚至不能正式定义某些技术项目的客户是谁。

当你在开发终端用户应用时，通过定义角色和人物来定义客户比较容易。但在考虑后端能力时，包括基础设施、安全能力、中间件、库或网络服务，寻找客户角色可能更具挑战性。但技术专家也是企业的一部分。在实施后端技术时，建筑师、业务分析师或技术负责人可以作为客户角色的代理人。要求他们提供需求，确定验收标准，做出权衡的决定，并对实施的解决方案进行满意度评价。

忽视现有的标准和技术

从历史上看，技术部门在创建和维护文档以及沟通和管理标准方面一直很努力。因此，当一个紧急请求或最高要求出现时，我们更有可能寻求新的解决方案，而不是调查和重新使用现有的能力。

这种方法往往导致多余的能力、半开发的解决方案和如雨后春笋般的技术债务。在调查新的解决方案之前或作为其一部分增加一个 "研究内部解决方案 "的步骤是一个简单的纪律，可以增加重用。当人们推荐新技术时，建立一个程序来估计对遗留平台的升级或整合具有类似功能的技术。

培养一种单一供应商、单一方法的技术文化

有没有听过有人强调说："我们是一个_X_商店"，以此来减少对其他供应商或技术的研究、审查和考虑？有标准和首选供应商是一回事。对第三方的能力一无所知并阻碍对替代方案的讨论则是另一回事。

让少数强大的平台倡导者的声音淹没任何探索和实验，会导致代价高昂的错误。技术领导者应该公开处理这种文化上的反模式，特别是如果它压制了人们提出问题或挑战现状的思维。

假设构建或购买是唯一的选择

在用自定义代码构建解决方案和购买SaaS或其他提供开箱即用功能的技术之间，存在着一个广阔的灰色地带。在这两者之间有高度可配置的低代码和无代码平台、商业合作关系以及利用开源技术的机会。

因此，构建与购买是一个过于简单的说法。一组更好的问题是，所需的能力是否有助于企业的差异化，以及从长远来看，什么类型的解决方案能提供更多的创新和灵活性。

假设API满足集成需求

大多数现代SaaS，甚至许多企业系统都提供API和其他集成选项。但是，对集成钩的编目应该只是调查它们是否满足业务需求的开始。API暴露了什么数据？是否支持所需的视图和交易？你能轻松连接数据可视化和机器学习工具吗？API是否有足够的性能，是否有需要考虑的基本使用成本？

加快审查集成能力的方法包括这三种验证API的方法和利用低代码集成平台。

[也在InfoWorld上：如何选择一个低代码开发平台] 。

未能进行社会尽职调查

当我们面对一长串可能的解决方案时，可信的信息来源可以帮助我们缩小竞争范围。阅读博客、白皮书、评论和研究报告，以及观看网络研讨会、主题演讲和在线教程都是关键的学习步骤。但有一个工具经常被忽略，那就是利用社交网络向专家咨询。有两个地方可以开始，包括IDGTechTalk和#CIOChat，在那里许多专家会提供建议并分享替代解决方案。

跳过概念论证

选择技术的艺术、工艺和科学涉及设计和执行概念验证解决方案（PoCs），以验证假设并测试关键的战略要求。在验证新兴技术或评估SaaS平台时，PoCs尤其重要，但即使使用敏捷的峰值来审查第三方技术组件，也有助于加速决策并避免昂贵的错误。

最大的错误可能是跳过PoC，要么是因为你相信你读到的东西，你相信供应商，或者你面临太多的时间压力。即使PoC为一项技术开了绿灯，你从PoC中学到的东西也能帮助你把优先级引导到可行的实施上。

制定详细的决策矩阵

当许多人参与审查和评估新的工具和技术时，一种帮助推动数据驱动的决策的常用方法是创建一个决策矩阵电子表格。特征和能力按重要性加权，然后由审查委员会评分。电子表格会计算出总分。

不幸的是，当有太多的人参与进来，选择了太多的功能，或者任意分配权重时，这些工具就会很快失去控制。电子表格最终会把作者的偏好放在优先位置，而人们会因为审查所有的功能而忽略了需要进行战略评估的内容。

在开始做决策矩阵之前，先退一步。考虑将解决方案的特点提炼为商业问题的本质，而不是要求一长串的功能由太多的评审员来评估。

忽略了长期的架构、生命周期和支持方面的考虑

我非常赞成根据易用性和价值实现时间来评估技术，但这并不意味着长期架构、维护和支持方面的考虑不重要或不需要评估。

关键是要决定何时评估它们，什么是关键的考虑因素，谁将参与审查，以及在评估中投入多长时间。做到这一点的一个好方法是，将技术团队在评估开始时应该考虑的门槛问题与决策过程中应该投入的长期因素分开。

省略SLA、数据保护和安全审查

时间压力或对你所选择的技术的（盲目）信任是忽略服务水平协议（SLA）审查和对供应商安全和数据保护实践评估的糟糕借口。做好这些审查的关键是拥有必要的专业知识、谈判技巧和工具--以及高效的评估流程，这样技术专家和业务赞助者就不会把审查视为瓶颈了。

在内部进行SLA、数据保护和安全审查的大型企业必须具有时间效率，并将其工作重点放在使评估与最高风险相一致上。专业知识不足的小公司应该寻求在解决方案领域有专长的外部人员。

推迟财务和法律审查

我清单上的最后一项，但肯定不是最不重要的，是财务和法律审查。这里的反模式是等待太长时间来引进所需的专家来进行审查。

考虑到许多SaaS产品、API服务和云原生技术都有基于消费的定价模式，而且运营成本可能不符合预算或财务限制。法律审查对于受监管行业的公司或在全球范围内运营的公司尤为重要，在这两种情况下审查合规因素可能特别耗费时间。对于财务和法律审查来说，延误可能会造成很大的损失。

[及时了解软件开发的最新进展。订阅InfoWorld第一视角通讯]

不要等到技术审查过程结束时才引入财务和法律专家。我的建议是在一开始就请他们参与进来，在做出任何技术选择的决定之前，请他们权衡一下哪些方面需要早期审查。此外，不要因为同时进行太多的评估而过度消耗你的财务和法律资源。

对许多公司来说，试图兼顾多项技术评估是不现实的，领导者应该优先考虑他们的采购工作。如果他们这样做了，我向你保证，聪明、全面、高效的技术评估是可能的。

会做出非常糟糕的技术决策的 12 种行为