我们希望有一个策略，能让我们决定何时停止设计，开始实施编程，同时优化成本函数。
启发式#1：有足够的 "已知的知识"。
你是否有最小的知识来带来价值？
你的项目可能是庞大的；因此，有许多需求，可能有些需求可以在没有其他需求的情况下交付。在 "迭代设计过程 "中，我们希望尽可能快地得到反馈。这就是为什么，如果你有可以低风险发货的东西，就去做吧。
启发式2：不再有 "已知的未知数"。
你解决了所有的 "开放点 "吗？
非常建议在开始任何项目时进行一些风险评估。在评估过程中，团队应该浮出任何开放点。这可能是一个你很久没有接触过的模块，或者是项目需要的新技术。
一个很好的启发式方法是，当你对每个开放点都有一个或多个解决方案时，就可以继续前进了。
启发式3：有太多的 "已知的未知数"。
你无法集中精力，因为你有太多的 "开放点"。
有如此多的开放点，你不知道从哪里开始。这可能是一个很好的迹象，说明你需要更多的信息。一个原型可以使你的努力集中起来。你可能需要再次回到设计桌前，但这一次需要更多的信息（和更少的开放点）。
启发式四：你停止学习新事物
你是否一直在重复讨论同一个开放点？
所以，你确实为你所有的 "开放点 "找到了解决方案，但你无法决定一个特定的点。有多个解决方案，但团队一直在争论哪一个是最好的。你们进行了几次讨论，但没有什么能坚持下去。是时候进行编码了。
如果风险是合理的，你可以考虑从其中一个解决方案开始，并进行密切跟踪。如果风险较高，你可以考虑从多个解决方案开始，并对它们进行反复的评估。
启发式5：掉进兔子洞里
事情开始变得过于复杂和抽象
是的，我们在这里是为了解决复杂的问题，是的，一些解决方案需要一些相当深刻的思考，但试着问自己，我的项目需要这种程度的复杂性吗？
工程师喜欢解决问题。这就是为什么我们经常发明新的问题（想象中的问题是坏软件的根源）。如果你注意到设计开始质疑与你的目标几乎不相关的领域，那么是时候做一个PoC或原型来让你的脚踏实地了。