如何为项目和产品提供资源——优化工作时间、激励团队和预算

在上一篇文章中，我探讨了资源重要性和价值转移的含义。考虑到产品生命周期的时间越来越短，我认为时间是一种越来越被低估的资源。放大到亚微级别，我认为我们也在考虑高科技公司内部资源分配的模式转变。

无论技术背景如何，所有利益相关者通常都按计划进行谈判。从问责制的角度来看，时间是最不常见的标准。

在传统的项目方法中，团队会先弄清楚并同意范围。一旦将这些需求转换为成本和时间估算，这些需求将是固定的。日期也将事先约定。在这种情况下，需要进行很多分析和争先恐后地尝试在了解所有内容之前先学习和决定所有内容。实际上，这种前期探索需要时间。不管产品交付团队是否实际在处理产品，“模糊”前端上的经过时间都会添加到最终交付日期中。定义和估计交付范围所需的所有工作需要大量时间。在实践中，此积压工作只会帮助我们确定项目或产品何时“完成”，而这本身对客户或销售人员没有任何意义。这项工作通常可以避免在交货时不“计算”时间。

标准方法：瀑布式包装中的敏捷

而且由于范围是固定的，并且实际上需要一个泄压阀，因此通常左侧的底部三个三角形之一会受到影响：时间，质量和成本。然后。花费数月的时间来跟踪项目进度并且与客户互动受限（因为尚未完成），这是又一次浪费时间。

通过尽早吸引客户并在高度规范的结构中最大程度地学习，有一种方法可以大大减少这种浪费。在敏捷方法中，采取了完全相反的方法。我们不会尝试预先确定范围；我们预先确定了参与规则，以使业务和技术团队成员都能优先考虑范围。

相反，我们在未完全同意范围的前提下，严格为项目预先定义了业务和技术标准。因此，我们同意我们将花费不超过$185k，通过自动化测试确保质量，并且我们有3个月的时间交付可出售的产品。我们可能只提供一项功能，但是如果这是一项有价值的功能，那么客户会为此付费。如果所有这些都是明确的，则产品团队本身可以根据从客户那里学到的知识在操作上确定范围的优先级。对于所有类型的产品，最终客户和市场都将决定购买正在建造的产品。

尽早开始工作，交付更多，并尽早收集客户反馈

这里有什么根本上的不同？范围由产品团队的一系列操作或战术决策定义，而不是在产品外部定义的战略决策。高级业务利益相关者不需要遵循并了解产品中所包含内容以及项目“完成”部分的技术细节。它涉及的细节太多了，并向他们精心招募和培训的高薪技术专家团队传达了对判断的不信任。这也破坏了团队对结果的归属感。因为他们工作的一切都是外来的定义，都是偶然发生在他们身上的。

在敏捷团队中拥有瀑布式包装的总成本是多少？

显然，需要在整个组织范围内协调工作。尝试使用详细的瀑布式前期计划将花费您的时间，并可能浪费您已确定的市场机会。最好共享对积压的访问权限和敏捷的驱动力，以便以较短的节奏提供潜在的可移植软件。因为您知道您可以使用其他团队所做的任何事情。您可以根据团队之间的公开讨论进行估算或确定优先级。