技术大停滞 费米悖论_技术领先悖论：交付与学习

技术大停滞 费米悖论

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

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

交付与学习是一种常见的技术领导悖论。

交付案例

在软件开发的商业领域中，始终存在交付满足用户需求的软件的压力。 如果不付钱给客户，公司就不能付钱给员工。 满足用户需求的软件越多，公司赚的钱就越多，公司可以在自身上投资的就越多。

商界人士将总是要求进行更多的软件更改，因为无法知道某些功能是否确实满足用户需求。 商界人士不了解（也不能完全理解）需要哪种技术基础架构才能更快或更有效地交付功能。 因此，他们将始终施加压力以加快软件交付速度。

从纯粹赚钱的角度来看，很容易将交付软件解释为产生更多收入的方式。

学习案例

软件本质上很复杂。 技术不断变化。 随着竞争对手发布新产品和客户需求的变化，并通过不断使用不断发展，问题领域发生了变化。 有一定技能的人离开公司，有不同技能的新人加入。 找到合适的技能平衡以匹配当前的问题是一个持续的挑战。

从技术专家的角度来看，了解不同的技术可以帮助更好地解决问题。 了解完全不同的技术会带来新机会，可能会带来新产品。 但是学习需要时间。

冲突

为了使开发人员最有效地完成工作，他们需要时间来学习新技术并提高自己的技能。 同时，如果他们花太多时间学习，他们将无法提供足够的帮助公司实现目标的公司，并且公司可能无法赚取足够的钱来补偿员工以及开发人员。

以交付为代价的鼓励学习也有可能出于技术的原因而导致技术的发展-开发人员使用技术来交付某些东西。 但是他们交付的产品可能无法解决用户需求，结果使整个公司蒙受损失。

技术负责人做什么？

技术负责人需要在寻找学习时间和有效交付正确的事情之间保持恒定的平衡。 对于技术负责人来说，屈服于过度学习的压力通常会更容易。 以下是有关如何在两者之间保持更好平衡的建议。

冠军有一段时间学习

Google以20％的开发时间闻名于世。 尽管并非在整个组织中始终贯彻实施 ，但该想法已被其他几家公司采用，为开发人员提供了一些创作自由。 20％不是唯一的方法。 黑客时代，例如Atlassian的ShipIt日子（从FedEx日子重命名），也预留了一些明确的，集中的时间来允许开发人员学习和玩耍。

满足用户需求的一流学习

内部运行的Hack Days鼓励开发人员根据用户需求释放自己的想法，使他们能够运用自己的创造力，并在此过程中经常学到一些东西。 他们通常会在平时使用不使用的技术和工具，但是结果通常集中在“用户需求”的基础上，更多的商业投资（例如时间）转向了具有商业意义的解决方案–不仅是技术，而是技术。

汲取经验教训

在大型开发团队中，不同的人在不同的时间可能会汲取相同的教训。 这通常意味着重复的努力本可以花在学习不同或新事物上。 技术负责人可以鼓励团队成员与其他团队成员分享他们学到的知识，以推广课程。

我经历过的一些可能性包括：

• 举办定期的学习“展示与讲述”会议–团队成员围绕最近遇到的问题以及如何解决这些问题进行一系列的闪电演讲或代码演练。
• 更新Wiki上的FAQ页面–允许团队成员共享适用于其自身环境的“如何执行常见任务”。
• 共享书签列表–团队根据遇到的问题创建一个有趣的链接列表。

鼓励共同教学和共同学习

技术负责人可以展示他们对学习环境的支持，但鼓励每个人同时成为学生和老师。 大多数团队成员将具有不同的兴趣和优势，而技术负责人可以鼓励成员分享他们所拥有的东西。 鼓励团队成员举办有关主题的棕色会议，以鼓励他们营造共享氛围。

每周阅读清单

我认识一些技术主管，他们每周发送一封电子邮件，其中包含指向各种技术相关主题的有趣阅读链接。 尽管他们并不希望每个人都能阅读每个链接，但每个人都希望团队中的某人能够阅读其中的一个链接。

翻译自: https://www.javacodegeeks.com/2014/11/a-tech-lead-paradox-delivering-vs-learning.html

技术大停滞 费米悖论