无服务器架构从根本上影响限制产品开发的限制因素。组织中的产品经理扮演着各种角色。 有时它们被称为“客户声音”，有时它们起到
“公司猫危害”的作用 。 他们是个皮肤黝黑的弟兄，尽管有任何道德或借口，但他们无情地带领您交付产品。 一个好的产品经理很少会成为某人的偶像，但是由于有了这些人的工作，您所使用的大多数技术解决方案才得以体现。
PM一直在寻找质量最高的工具来解决问题。 我们知道竞争对手不断踩脚，客户厌倦了等待，因此我们必须不断采取更明智，更快和更高效的行动。 随着无服务器技术的出现，目前尚不清楚它们如何适合产品管理的愿望清单。 但是，在使用这些技术一年后，我发现它们解决了一些软件开发问题，这些问题在我们看来是永远的。
悖论：团队规模和绩效
产品管理的第一条规则说：要执行的工作量在不断增长。 积压量持续增加，仅在一种情况下（当产品被淘汰时）积压至零。 最困难的事情是将待办事项中最重要的元素变成可以交付的产品。 在所有其他条件都相同的情况下，应该遵循以下关系：
如果一个挖掘机每天可以回收1吨土壤-假定10个挖掘机可以回收10吨土壤。 通常，公司中的资源管理基于以下原则：如果要增加销售额，请雇用更多的销售人员。 在开发软件时，随着积压的增加，诱惑就是简单地增加团队。 但是，在产品和服务复杂的情况下，随着时间的流逝，通常会大致遵循以下时间表：
很少见到一支庞大的团队如何以Stakhanov的速度运作； 但是经常发生的情况是，一个令人羡慕的稳定团队不断进步。
许多创业公司都犯了这样的错误：产品成功后，就会有更多新的开发人员和管理人员加入员工队伍。 很快，突然发现速度开始下降。 怎么了 最初的开发人员更有才华，公司中的官僚机构在增长，架构是如何计划的？
我认为所有这些只是症状，而不是问题的根源。 问题本身归结为三个关键因素的相互作用，其中只有两个可以直接控制：
- 脆弱性是新变化的结果。 如果新功能仅影响机器的一部分，则易于测试和实施。 如果它影响了机器的所有元素，那么测试将变得更加困难，同时也变得更加重要，并且实现需要更多的时间量级。
- 工作量是团队可以执行的最小的工作，并且在输出端具有生产功能。 例如，结果是“用Alexa付款”，而不是“聚在一起讨论如何用Alexa付款”。
- 复杂性-实现功能需要多少知识。 是一个知道如何编写能够在组织内完成相同功能的功能的开发人员吗？ 为了使进度逐渐变慢，还必须进行哪些其他更改，并且产品停止增长，并且具有从客户角度来看很有价值的功能？
我特别感兴趣的是，为什么在存在之初，所有这些因素都达到了最佳平衡：没有任何脆弱的东西，工作量不是特别大（您通常可以与客户达成一致），并且几乎没有复杂性。 因此，如果团队需要创建符合GDPR的网站，那么他们将有时间研究此问题，将迅速做出决定，并且团队将确保该网站完全按计划工作。
在大型公司中，这些因素综合在一起，导致团队规模不断扩大，并且减少了工作量。 要在这样的公司中创建与GDPR兼容的网站，您将需要律师的签名，营销人员的批准，董事会一级项目的批准，对破坏性最小的实施进行A / B测试，与管理团队协调开发中断，与其他团队采用的部署计划协调-清单继续。 即使有这么多的控制权和许多流程，由于整个系统的脆弱性以及生态系统中的许多未知因素，团队仍不太会成功。
将这个示例扩展到一个实际项目的大小（其中可能有数十个功能和数百个更改），很容易理解，由于这些因素的影响，“团队规模/工作量”比率的图如何从第一个变为第二个。 随着团队的成长，无论您如何试图超越组织的巨loss，您注定要在单位时间内减少工作量。 或似乎只是这样-但是该怎么办？
如何破解这三个因素
这个问题困扰了我很多年，促使我开始研究其可能的原因。 创业公司有可能取得快速进步吗？ 有一阵子，我只是这么想，面对大型组织中产品管理的困难。 但是，然后我更仔细地研究了所有三个因素。
脆弱性始终有害于您-在任何规模的任何项目中，它都会招致越来越多的技术债务。 这种情况让人想起“相反的半衰期”：程序的任何元素都会随着时间的推移而增长，并且由于这个原因（在开发过程中），它变得更加脆弱，所有这些都与新的代码行混合在一起。
工作量与产品的特定功能（“用Alexa付费”）无关，如果我们比较“之前”和“之后”的状态，则与基础架构轮廓上的差异无关。 “之后”变得越困难，执行的工作量就越减少。 这就是为什么在许多公司中，在计划工作时，重点从客户的需求（“用Alexa付钱”）转移到组织的需求（“见面并讨论谁应该参与功能“用Alexa付钱”的实现）。
复杂性是社会，组织和技术因素的组合，这些因素直接影响寻找合适的开发人员的时间，将程序员视为可以承担任何工作的多任务人员的能力。 而且，它是复杂性-可能仍保持不可见，未记录和被误解的方面。 开发人员可以在家编写一个React应用程序并自己发布它，但是在组织中，他将不得不采取许多额外的步骤，而这将花费他的时间，并且用户所感兴趣的功能将完全不会改变。 程序员将大部分时间花在它们上面。
这三个因素共同构成一个恶性循环，因此执行的工作量减少，脆弱性增加，开发人员设法完成越来越少的功能，并且您的产品因看不见的泥土而过分繁杂。 因此，团队的成长无济于事，只有通过数字和指标的狡猾才能有意识地提高速度。 一个典型的症状：“会议举行”位置出现在冲刺报告中。
在大型公司中，我不得不观察几种旨在打破这一循环的有缺陷的方法。 第一个是“大型敏捷”，它导致了巨大的会议，所有参加特定功能开发的人员都参加了会议，并试图协调工作。 因此，尝试协调工作并了解复杂性。 这种方法对于提供迷人午餐的食品分销公司来说是不错的选择，但在我们看来，这种方法是行不通的。 事实是，随着优先项目组的规模增加，它变得越来越多，并且它们本身也在减少。 因此，不可能从根本上解决脆弱性和复杂性的问题。 随着时间的流逝，大型敏捷给出了类似于购物清单的战术任务清单，并且越来越像从一个周到的功能到另一个周到的整体路径。
其次，企业内部的“创新团体”经常尝试推动外围变革，希望这项工作扎根于脆弱的机器中，并且整个结构会变得更好。 这种方法产生了一个怪异的副作用：人们坚信只有这种“创新者团体”才有权对流程进行更改。 因此，类似的方法也不能解决组织复杂性的问题。
经历了多年的各种失败之后，我得出的结论是，有必要破解所有三个因素，以防止它们对完成的工作产生综合影响并应对惯性：
- 在将来的版本中或随着产品的老化，脆性不应增加。
- 从用户的角度来看，这项工作不应少于创建重要功能所需的工作。
- 复杂性不应影响单个开发人员的工作。
如果您成功采用了这些想法，那么您将免受岩石的袭击，岩石将追逐人类历史上的所有软件产品。 听起来不错，但是如何实现呢？
如果您成功采用了这些想法，那么您将免受岩石的袭击，岩石将追逐人类历史上的所有软件产品。 听起来不错，但是如何实现呢？
无服务器技术突破限制
由于云技术的出现，为新的“被入侵”状态铺平了重要的道路。 通常，随着云的出现，交付软件产品的过程变得更加紧凑，因为提供商开始为您做很多例行工作。 在出现云之前，如果需要实施新的用户功能，则必须订购服务器，在机架上安装设备，同意在数据中心内铺设网络，然后维护该设备，但随着时间的流逝，它会逐渐磨损。 在云中，所有这些都可以租用，从而摆脱了数十个组织项目，节省了整个月的时间。
此外，由于无需升级数据中心的设备并按需提供对硬件的访问权限，因此我们减少了脆弱性和复杂性。 与过去相比，使用程序要容易得多。 但是，随着时间的流逝，管理广泛的虚拟基础架构的负担已大大增加，许多过时的交付方法保持不变。 使用云，可以在工作开始变慢之前显着增加团队-但是，它开始以某种方式变慢。
无服务器技术从根本上改变了这种动态。 无服务器应用程序由团队编写的一小段代码（所谓的“胶水”）和由云提供商管理的功能性“黑匣子”组成。 黑框仅接受配置并对更改做出反应。 在具有高质量体系结构的应用程序中，与应用程序的操作相关的操作工作的标准部分落在标准黑匣子上。 应用程序本身不再是单一功能，而是功能和黑匣子的联邦结构。
实际上，这极大地影响了我上面提到的三个因素：
- 由于基础架构管理成本为零且绑定较弱，因此降低了脆弱性。 在我们自己的项目中，据观察，由于这些更改而导致的代码库有时可以减少十倍。
- “工作量”的大小通常与创建新功能的成本相当，因为创建功能的新版本或以前不需要的全新功能变得微不足道。
- 复杂性不会影响开发人员-如果他可以编写处理信用卡付款的功能，那么除了无服务器应用程序中的此代码外，几乎没有任何事情要做，无需组织包装程序，也无需考虑生态系统，因为这会降低工作速度。
在管理非常大的无服务器应用程序时，产品经理很容易仔细查看受更改影响的极少数元素。 另外，通过放置功能标记很容易以竞争方式启动两个版本。 而且，通常甚至不需要拆除旧版本的代码。
在无服务器应用程序中，基础结构总是建立在外围设备上，并且您只编写必要的最少代码，这些代码结合了完全托管的服务。 您无需从操作角度考虑它们。 我们并不是要控制整体，清理旧代码，也不是从鸟瞰的角度来看整个系统。
为什么它如此重要
随着变更步伐的加快，预测您的程序将来的外观或用户从您的需求中变得越来越困难。 因此，尝试“数百年”地编写代码，以至于不管将来如何变化，它都必须在将来工作，这种尝试变得越来越徒劳。 我们已经看到了大多数公司中糟糕的代码重用率，以及对过时平台的遵守如何减慢了进度。
现在，一切都已安排好，以便尽可能长时间地开发和维护旧系统，直到几乎所有时间它的支持都开始脱离程序员为止。 此后，该公司从新系统重新开始，郑重承诺不要重复旧系统中的错误。 当三个因素迟早会扼杀新系统时，就会发生技术性的“森林大火”，此后您必须重新从头开始。
我们正在与复杂性的症状作斗争，这就是为什么这么多范式来来往往的原因，而在产品管理的历史中却没有留下明显的痕迹。 反过来，无服务器开发使团队可以最大程度地减少复杂性的增加，并继续以相当均匀的速度交付有价值的产品，而不会陷入数十年来一直是任何软件开发的祸害的经典陷阱。
无服务器模式刚刚开始发展，但似乎已经非常有希望。 在客户要求您拥有前所未有的新功能时，产品经理可以最终获得一个平台，该平台使您可以根据新功能的准备情况进行精确思考。 该过程不受组织复杂性增加的阻碍，也不会因过度脆弱而停止。