项目团队与产品团队-CSDN博客

对于试图变得敏捷的公司来说，最困难的事情之一就是如何组建团队。回顾过去，团队会围绕一个项目组建。然后六个月后，每个人都会消散并加入新的团队。到团队形成并生效时，它又被撕裂了。您没有主人翁意识，没有连续性。

如今，每个人都知道项目很糟糕，因此需要Scrum团队。因此，将与产品负责人组成一个Scrum团队来确定工作的优先级。但是通常会发生的事情是，积压的工作是轻而易举的事。例如，我看到一个团队没有工作要做 。积压的订单是空的，因为除错误外，所有未完成的项目均未签名。再有一个词。项目。

在幕后，Scrum团队通常会成为交付项目的一种更好的方式。您将获得团队一致性和连续性的好处，以及企业可以根据项目进行工作思考的额外好处。这种方法的缺点是Scrum团队可能缺乏明确的重点：团队没有任何总体目标。从冲刺到冲刺，重点可能会随着不同项目相对重要性的改变而改变。这使得团队很难为一个伟大的构想和更大的目标献身。它最终导致了积压的无休止的游行。

为什么会这样？我认为这归结为金钱。有人在某处看着钱。有人想知道“如果我在这里花x英镑，到什么时候我该赚多少钱？” 该项目的想法很容易适合此模型。团队每天花费£x。该项目预计需要n天。预计将带来£y的利润。由此我们可以计算出预期的投资回报率。麻烦的是，这些数字大部分都是由人为组成的。如果不是根本上不为人知的话。

让我们从一个显而易见的例子开始：该项目要花多长时间？真的，我们仍然在问这个问题吗？我们从敏捷中学到了什么吗？似乎并非如此：许多人仍然按照交货日期和确定性来思考世界。我们什么时候会知道最好的方法总是付出一点，检查结果；然后决定是走同一条路还是提供不同的东西。您无法通过这种方式获得结束日期-这甚至没有意义。继续交付一件事，直到您可以做的更好的事情为止，然后再去做。冲洗，重复。

另一个问题呢：该项目将获得多少利润？好吧，现在让我们假设，按照最初的设想，整个项目将实际交付（好像这实际上是在软件中发生的）。你能说出它赚了多少钱吗？真？独立于组织同时进行的其他任何更改？从软件到运营再到营销？

现在有时您可以对预期收益进行很好的估算，但是通常这只是一个空想。但是，如果您强烈不同意我的看法：我认为您正在认真地跟踪实际成本并将其反馈给未来的项目计划？我看到很少有公司实际这样做。如果您实际上没有衡量项目的收益，您怎么知道您最初的估算是好的？

因此，我们有两个组成的数字，实际上在实践中几乎都无法实现–但是我们用它来决定团队的优先顺序。我曾经看到一个项目被批准并跳到优先顺序的顶部，因为它预测公司的收入将增加10％。对于单个项目而言，这是一个非常大的数目，对于每个参与人员显然都是荒谬的，但是它已被签署并适当实施。由于困难的市场条件，当年晚些时候的收入预测被向下和向下重新估计。还有一些公然的高估。然而，在很多组织中，这种非科学的方法却可以使投资计划获得回报。

有什么选择？我见过的最好的团队都是围绕产品构建的。授予团队对一种或多种产品的完全所有权。对这些产品的所有更改均通过产品团队进行。产品负责人指导产品方向。作为地区专家，他们受托决定哪些是最重要的工作。他们可以与团队讨论长期发展方向，并对产品的发展方向保持一致，一致的愿景。不可避免地，一些变更很大且相互依存，因此成为项目（如果交付了一部分，则必须全部完成）；团队了解解决方案的业务优势，并且可以改进实现以满足基础业务需求，而不是试图满足一些任意的内部项目期限。这为团队提供了检查和调整每次迭代的完全自由。了解了其产品的业务优先级后，他们可以在每次迭代显示更多信息时做出明智的权衡。

那钱呢很难，但说实话：软件交付的项目模型的投资回报率尚不明确，因此请接受并不清楚。困难的是要弄清楚哪些产品能为您赚钱，如果投资更多，哪些产品可以赚更多钱 。麻烦的是，我曾在一些团队工作过，说实话，该产品是如此有利可图，提升范围很小，以至于最有成本效益的事情是解雇开发团队并继续挤牛奶。

那么，我们如何决定将钱花在哪里呢？我认为敏捷的经验模型可以很好地适合这里。让我们假设一分钟，您整个交付团队的钱是固定的–您唯一的选择是放到哪里。在产品A上花了多少钱在产品B上花了多少钱。您能估计每种产品为公司赚多少钱吗？它是如何随着时间变化的？

如果一种产品每个月都能赚取更多利润（如果它是一种正在增长的产品），那么在那儿投入更多的资源以加速增长。如果产品放慢速度，每个月的利润增加幅度较小，甚至利润减少，那么就停止花太多钱。这自然意味着您的钱去了似乎可以带来最大回报的地方。将您的资金放在似乎可以带来成果的地方。

最困难的是，获取反馈需要时间：更改资源分配可能需要几个月才能显示出来。但是至少我们对自己的决定产生的影响是诚实的。与其尝试通过项目进行微观管理，不如管理放置资源的位置，并让产品所有者管理优先顺序。