截止日期无一例外地出现在所有项目中，并且几乎发生在所有产品开发过程中。 在项目管理中，截止日期很容易直接与收入相关，但是对于产品而言，情况要复杂一些。 截止日期在产品开发中扮演什么角色？ 没有他们，有可能吗？
基于John Cutler的文章 。 经许可发布以讨论和分享经验。最简单的截止日期类型是
商业截止日期。 如果“打孔”它，显然会损失很多钱。 这样的截止日期很少：通常是与竞争对手赛跑，或者与日历事件（节假日，展览等）相关联。 碰巧是宣布了商业截止日期，但是在“突破”之后，事实证明钱并没有丢失。 确实发生
了损失大量金钱的
可能性 。 这更难以验证，但也有可能（从统计角度来看）-经常会发现直接损失要么被高估，要么根本没有被高估。
这是滥用
人为期限的结果。 食物生态系统中的大多数截止日期（与设计截止日期相反）是人为的。
为什么需要它们：
- 限制成本 。 在一个特征/假设上花费超过X个资源是没有意义的
- 营造健康的紧迫气氛 。 保持团队精神并保持良好状态的团队会更有效率
- 刺激切割范围 。 抛光功能可快速减少边际效用
- 防止团队抱怨 。 没有商业地标的免费游泳效率低下
- 鼓励设定目标和集中精力 。 提高每个团队成员的效率
- 坐标依赖项 。 我们同意X小组可以在xx.xx.xxxx之后开始工作。 重新安排和保留资源效率低下
- 协调商业活动 。 预定于xx.xx.xxxx开始销售。 到此时，可以分配预算或计划营销活动
- 建立可衡量的责任 。 如果明确由谁负责，则明确宣传方法/何时进行-反馈的透明度
- 在业务合作伙伴之间营造一种可预测性和宁静感 。 对业务部门的信任使您可以简化沟通并建立更有效的流程
有时会适当使用人为的截止日期，有时则不会。 无论如何，在特定时刻了解并诚实地宣传其真实目的很有用。
人工截止日期的次优使用示例：
- 没有可用结果的冲刺 。 如果事先知道由于sprint没有什么可看的，并且没有新内容集成到服务中，那么中断工作（sprint的结束/开始）的开销可能不会得到回报。
- 季度/年度杂货计划 。 由于存在大量不确定因素，因此在计划和产品假设中出现重大错误的可能性都接近100％，这证明了此类延迟的截止日期
- 截止日期基于评分 。 它解决了许多问题，并且很受欢迎，但是它包含一些缺陷：
- 刺激“过早收敛”-选择局部最优解，尽管全局最优可能非常接近
- 可能不取决于团队，因为评估不包括外部因素
- 将团队集中于“按时”工作，而不是“按结果”工作，这增加了错误决定的数量
可能的改进建议：
- “正确的”时间框 。 一般指南/倡议持续数周。 在此期间内，具有可验证实施假设的短距离冲刺。 截止日期是固定的，范围是任意的，并且需要反复审核
- 流量控制 。 我们将工作模拟为流（例如： Reinertsen ， ToC ， kanban ），并对其进行优化。 同时，我们正在寻找进行频繁集成的方法（对于超过X天的活动， CI / CD ，SAFe IP / PI等，进行自动回溯）
- 如果您使用截止日期，请明确指出他们要解决的问题
主要思想 ：想更高一级。 试图找到解决特定业务问题（动机，协调性等）的解决方案，而不是在任何无法理解的情况下以截止日期的形式拐杖。
讨论 ：截止日期还有哪些其他案例研究？ 可以使用哪些替代方法代替截止日期？