项目总结 项目团队加班加点_项目团队与产品团队

项目总结 项目团队加班加点

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

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

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

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

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

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

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

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

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

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

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

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

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

翻译自: https://www.javacodegeeks.com/2017/01/project-vs-product-teams.html

项目总结 项目团队加班加点