开发商的框架

互联网给软件开发带来了许多变化。啊！这家互联网公司的崛起推动了人们对持续关注市场和倾听客户意见的需求。软件开发不能再孤立地进行，而且需要很长时间。市场已经向前发展了，竞争对手不是每十年一次，而是每月一次。其中大多数都是资金充足的，而不是车库商店的运营。总体的驱动力是更多地关注具有更快更改和更多中级指导的开发人员，而不是绘制长途旅行图。

反映这一点的第一种方法是90年代末的极限编程(XP)。XP为许多开发人员带来了敏捷、迭代的开发，并引入了“现场客户”的概念。我们的想法是让开发团队有一个可用的客户，最好让客户在现场并且可以面对面。然后，开发人员的任务是询问客户有关细节和需要开发的内容。这让开发人员处于主导地位，客户确保以正确的方式构建正确的东西。XP失败。它的失败可能有各种原因，但其中之一是互联网为拥有数百万客户的公司带来了，而XP诞生于内部软件开发的环境中。要让客户到场是一件很有挑战性的事情。另一个原因可能是开发人员不能“仅仅开发”代码，而是将成功产品的责任放在他们身上。他们应该坐在驾驶座上，与客户互动。

然后Scrum来了。Scrum与极限编程有很大的不同。它没有告诉开发人员该怎么做。XP说开发人员应该出于各种原因进行结对编程，而Scrum并不在意。XP告诉开发人员进行单元测试，而Scrum不在乎。XP告诉开发人员要对正在构建的内容负责，而Scrum告诉开发人员要对吞吐量和最后期限负责。Scrum着眼于要构建的东西的管理以及人们应该如何交互。它为会议带来了严格的指南，以及在会议中应该做些什么。但是Scrum并不关心工程学。Scrum带来的最大变化是产品所有者。团队不再拥有产品，但产品所有者拥有。他决定了开发人员应该做什么。开发商不再处于主导地位。这不是开发人员问客户产品应该是什么样子的，而是产品所有者告诉他们他想要什么功能。大多数人可能对这一变化感到高兴-也是因为工资开始迅速上涨。

一位新的主角上台了--产品经理。成功的公司都在使用它们，所以每个人都在效仿。敏捷和产品经理的崛起是齐头并进的。从自上而下的指挥层次结构到自组织的团队带来了与该团队互动并赋予其工作的需求。在此之前，产品将在董事会上与CTO讨论，然后下传，涌入项目并交给开发人员。随着敏捷和自组织团队的兴起，这种工作流不再起作用，我们需要一个新的设置。随着数据分析在产品开发中的出现，优化KPI(如转换)的需求发生了变化，需要有人来做所有这些工作，而开发人员并不愿意。他们不会对公司的业务感兴趣。为了完成它的功能，企业界会和谁交谈呢？商界认为很难与开发人员交谈。因此，产品经理填补了这一空白。幸运的是，随着Scrum的兴起，我们也有了一个很容易让产品经理适应的组织结构。产品所有者！从那时起，Scrum中的产品负责人角色几乎总是充满了产品经理的工作描述。今天，这两个词经常被混为一谈，用作同义词。大多数人不再意识到产品负责人和产品管理是两码事。

开发人员在短期内很高兴，他们不需要与客户交谈，并且有明确的人负责构建什么。产品负责人可以做所有杂乱无章的事情，比如与市场营销和销售人员交谈，以及管理需求。但开发商不再控制局面。感觉在掌控中是快乐的主要驱动力之一。虽然每个人都在奉承开发商，但他们的需求很高，工资也在不断上涨，但他们对建造他们不理解、没有影响或没有意义的东西感到越来越不高兴。

在一篇题为“对技术极度失望”的文章中。“请帮帮我”，一位不知名的工程师写道，然后我为一家科技巨头工作，然后为一家高增长的独角兽公司工作。令我震惊的是，他们两个人都是如此的庸俗。到处都是戴着金手铐的政客和疲惫不堪的工程师，他们迫不及待地想要走出家门，发表毫无意义的商业言论，还打量着那些一直假装对一切都很兴奋的员工。“‍。

别想大象了！这就是标题o

在讨论和环境中有意和无意地使用框架。框架塑造了讨论，让一些事情变得可以想象，而另一些事情则变得不可想象。相框中有与它们同行的朋友。

我们在发展中有一个占主导地位的框架。作为“积压”的软件开发。特性由产品经理(产品所有者)和不同部门积压。根据剑桥词典，积压是“大量你以前应该做而现在必须做的事情”。积压这个词会让你觉得自己总是落后于完成任务。框架上写着：完成意味着成功。如果我们从积压的工作做起，我们就会成功。如果我们完成了我作为一个产品所有者在我的愿景中的所有事情，我们就会成功。

这幅画一直潜伏在那里。随着Scrum中产品所有者和Backlog工具的兴起，这个框架变得清晰起来，并且已经显现和固化了自己。产品经理填补了开发人员和业务人员之间、技术人员和CEO之间的空白。积压作为一种工具有助于管理这些关系。作为Backlog的所有者，产品经理在与技术、业务、创始人和CEO的对话中使用此框架。

在待办事项框架中，成功取决于实现待办事项。为了取得成功，有必要实施这些项目。如果产品在此模型中不成功，则没有实现来自待办事项的足够项目。因此，尽可能快速高效地工作是至关重要的，因为这是成功的动力。首席执行官们经常问我，为什么他们的开发人员不像市场营销那样工作。他们认为，他们创业的成功与开发人员工作到深夜息息相关。积压的功能越多，我们的成功就越多。这带来了CTO的买入。我们的开发人员越多，我们可以实现的功能就越多，我们就会获得更多的成功。在这种世界观中，开发人员被视为一种资源。它们越多越好，资源利用越有效率就越好。

在Backlog框架中，技术的理念是执行和交付。通常，CTO都为交付而感到自豪。如果CEO们认为“技术没有交付”，而问题出现是因为“信息技术太慢”，那么问题就出现了。与开发人员认为产品经理需要告诉他们要做什么相反，他们并不对成功负责。如果产品失败了，产品没有告诉他们去做正确的事情。有趣的是，只有开发人员这样想，其他所有人都“技术没有交付”。