PMI原创文章 - 隐藏的最后期限所带来的成本

easthomeRT

最后期限看起来作为管理者和产品所有者的运营之道。但是往往，它们经常表现为不可预期的后果。

我们试图在最初的时间就对日期和最后期限引起重视。我的孩子们在收到家庭作业时会看到附上的目标完成日期。我的妻子和我也有我们自己负责工作的最后期限，比如为我们的孩子申请高中入学和申报个税等。在工作中，最后期限无处不在，几乎所有的工作都有一些日期的限制，比如何时完成，审批和交付等情况。

是否你曾经疑惑为何我们需要这么做呢？为何把日期看成一个紧要的因素？为何它们无处不在，最后期限已经不仅仅被命名为重要的日期了吗？

一些最后期限是真实的

事实上，有一些产品交付或发布仅仅在特定的时间窗口内才可以实施，我们通常叫发布窗口或变更窗口。如果延后，他们可能就不再需要或影响到具体的受众或用户。举个例子：

• 每年，税务软件制造商必须及时的升级他们的产品以适应税务法的变更；
• 游戏供应商想在圣诞节来临之前可以提供待玩家选购的产品；
• 组织需要供应商在几周内对其招标进行应答，否则组织会采取他们自己的选择方案。
  
  
  

在一些案例中，时间窗口只有一天。比如选举、马拉松和贸易展览等都符合这一特点。

何时日期不必成为最后期限

我们身陷麻烦，特别是在服务或产品发布环境中遇到，当问题没有具体关键期限约定的时候。相反，我们延迟交付的时间越长，对应的价值会相应的降低。换句话说，产品或服务越早的被使用，可能表现出更有价值。然而当客户、提供商和管理者协商具体工作时，日期不可避免的就会出现。有些时候，一些日期变得重要并成为最后期限，比如响应一个非预期的变更，以满足客户的应急需要。

我们随时都可能经历动态的变化。即使没有外部的事件或有意义的机会窗口，工作者被推动来满足一个臆断的日期。作为结果，他们和他们的客户在执行工作时会有很少的自由度。预示着一个隐藏的后果。

更多的工作参数受限，则更多其他参数需要提供。固定的日期给范围和质量目标带来风险的可能。管理者喜欢通过日期、范围和质量来约束团队。团队成员获得独立的工作指派，往往会降低团队沟通和协作的意愿。当他们遇到更高的日期、范围和质量的期望时，团队陷入一种恶性循环。

敏捷和日期

我们已经习惯于对待日期和最后期限的通常处理方式。是否我们可以考虑应用不同的处理方式，比如是敏捷的方法呢？

敏捷方法非常适合“早会更好”的情景。相互协作和稳定的团队聚集能量在一个小的时间盒子内（我们称为一个迭代周期）来实现限制性的工作。他们的能量最先投入到最有价值的工作，持续的获得反馈和不断学习，勤勉的聚焦于工作的完成，并且一次只计划完成尽量少的工作，也就是只规划在一个迭代周期内（通常是2~4周）需要完成的工作。应用这种方法，他们尽早产出最有意义的结果。他们拥有的时间越多，会涌现出更加有用和可爱的交付内容。他们在短周期内以既定产品的范围为杠杆，实现功能的最大化质量。

如果主要的杠杆是范围，什么时候一个团队应该停止工作呢？既然敏捷是确保不断达成使客户高兴的产品或服务。这个答案就是：“持续工作直到认为没有任何价值值得进一步投入为止”。但是即使依照敏捷计划的方法，一个团队也会在一些日期内停止工作，因为在那天交付一个不成熟的解决方案会面临风险。

如何最后期限向敏捷妥协

如果这个日期是真实和重要的，或者具有一个他们不可能忽略的限制，团队可以缩小变更动作或功能产出。他们也可以扩展他们的计划去更好的管理以来和降低意外（比如一次性计划几个迭代周期的内容）。这些可能会降低产品或服务的适应性，而当一个日期事件要高于适应性的要求时，这个是一个正当的选择。

然而，如果这个日期并不是非常重要，它符合“早会更好”的场景，设定一个最后期限，不需要降低适应性。这种做法可能有害处。如果日期如预算那样可以被很容易的监控和度量，我们可以使用非敏捷的行为或办法。比如独立的贡献者只是在前期投入少量的初始调研，考虑在既有的框架内基于没有被完全证实的假设去执行。经理们也许被诱惑去使用日期作为责任的度量依据。到最后，他们按时的交付也许并不是客户想要的。

基于我的经验，管理者和产品负责人过多的把日期强加到项目和任务中，已经超过了这些项目和任务应该需要的。一些时候，这仅仅是因为习惯。需要记住的是敏捷是持续的使客户愉悦，并且设置了一些敏捷原则来建立一个框架去使做的事情具有最大化的适应性。当下一次你做敏捷工作时，确保你不会向你的敏捷妥协。

更多行业干货、技术文章，请关注公众号：东方瑞通终身学习~