技术大停滞 费米悖论_技术领先悖论：技术需求与业务需求

技术大停滞 费米悖论

敏捷宣言的签约人吉姆·海史密斯（Jim Highsmith）在适应性领导方法中谈到了骑乘悖论 。

领导者会发现自己在两种解决方案或两种相互竞争的情况之间进行选择。 领导者采用“与”思维模式而不是“或”思维模式时，成功地“克服了悖论”。 他们没有选择一种解决方案而不是另一种解决方案，而是找到了一种满足两种情况的方法，即使它们彼此矛盾。

常见的技术领先者悖论是技术需求与业务需求之间的矛盾。

技术需求案例

在Internet上提供云服务之前，大多数公司会投资硬件来运行其服务。 非技术利益相关者由于其物理方面的原因而更容易设置和配置机器。 如今，软件需要更多的软件和非物理服务，需要进行配置，测试和发布。 它更多是虚拟的。

尽管诸如持续交付之类的实践提供了无价的业务能力，但它也不会带来一些开销。 所有这些“面向内部的”技术要求都需要软件交付团队提供时间。

业务需求案例

许多软件是为企业编写的，其总体目标是赚钱。 不发展业务的企业将输给竞争对手或不断变化的消费者市场。 这意味着企业希望始终尝试其现有服务，或提供新服务以保持其现有客户群或吸引新客户。

修改或引入新服务的压力要求软件支持或要开发的新软件。

冲突

企业将始终对开发团队施加压力，以使其尽可能多地生产软件。 同时，如果不解决某些级别的技术需求（例如技术债务 ， 部署管道或自动化测试套件），就无法有效交付软件。

预期花在技术需求上的时间会提高开发人员的效率，但这通常很难衡量并向外部利益相关者证明。 总是可以花费无休止的时间来调整，优化和改进技术基础架构和工具。 从“仅一个下午”开始的时间变成了一周或一个月，因此业务功能被搁置。 如果发生的时间过长，企业可能会错过某些功能的约定外部截止日期，从而失去客户或金钱。

技术负责人做什么？

技术需求的冠军时间

作为优先排序流程的一部分，技术负责人倡导有时间花在技术需求上。 他们确保交付足够的工作，或找到业务问题的解决方案以最大程度地减少需要编写的软件数量。 他们确保团队不会因提供新功能和变更而超负荷工作，并会发现少量内容来满足技术需求，这将带来很好的收益。

解释每个技术需求的商业利益

团队可以花大量时间研究，配置和支持其技术基础架构。 如果技术领导知道他们带来的好处，他们将获得非技术利益相关者的支持。 成功的技术领导能解释不只是这个团队工作，但也是为什么还有谁的利益。

一些典型的业务收益包括：减少重复工作量，提高质量（通过最大程度地减少人为失误的机会）或证明业务机会。

技术负责人通过强调满足技术需求的利益，并说明他们是否达到了这些利益，建立了与非技术人员的信任。

首先处理高影响力的物品

技术需求列表通常是无穷无尽的，因此技术负责人将对列表进行优先排序，剔除不再有意义的项目，或者将可能立即产生重大影响的工作项目拉到前面。

保持平衡

技术负责人谨记，团队不能仅根据技术需求开展工作，并且会注意确保达到良好的平衡。

最大限度地利用“安静”时期

有时，开发团队会超越企业优先考虑的能力，“下一步是什么？” 您可能会认识到产品负责人实现了所有目标的时期，或者他们正在努力澄清下一组时期。 技术负责人利用这些“安静的时间”作为他们的开发团队处理基础设施或总是被低优先级处理的任务的机会。

对于团队来说，这通常是一个良好的时期，以进行“ 黑客日 ”活动，或者是团队根据自己的想法提供有益的小想法。

翻译自: https://www.javacodegeeks.com/2014/12/a-tech-lead-paradox-technical-needs-vs-business-needs.html

技术大停滞 费米悖论