2023年产品开发要进度还是要质量

产品开发，要进度还是要质量？假如团队中消失了围绕产品开发工作绽开的争辩，类似“星球大战与星际迷航”（的粉丝群）之间无休止的吵架，那就是我所说的“质量与时间之间的权衡”（TheTradeoffBetweenQualityandTime，TTBQT）问题。

通常情景是这样的：

艾丽丝：我们构建X功能的方式特别简陋、缓慢、粗糙，我有更好的解决方法。

鲍勃：但是我们距离开发完成只有两周了，为了优化X功能而推迟发布，是否值得？

艾丽丝：但是我们应当关怀质量。

鲍勃：但是我们应当关怀交付。

艾丽丝和鲍勃面面相觑，双手紧握着闪闪发光的光剑，预备决斗……哦，等等，走错片场了。

结果是，或许一方劝说了另一方，或许决策被升级上报；但是最终，团队要么接受延迟发布，要么接受质量更差的交付，这两种状况都不值得庆祝。

你可能会想，事实如此，质量与时间总是无法平衡，必需牺牲一个才能换来另一个。

真的是这样吗？

不要误会，时常提出这种权衡是有益的，可以确保我们不会由于持续打磨产品而导致收益递减，或被动的让时间线主导产品开发，但我想提出第三种选择。

当你进入质量与时间的权衡状态时，真刚要问的问题是：“假如我们知道X功能需要这么长的时间才能做好，我们会在一开头就选择做它吗？”

这是一个很有力的提问，它迫使团队去检查究竟哪里出了问题，通常是：

团队在优先级排序时有多坚决？团队对执行力量的评估有多精确     ？团队在执行力方面有多优秀？我喜爱这个问题的其次个缘由是，它有助于澄清权衡决策应当是什么。

一、“不会”

假如答案是“不，X功能不值得我们花时间让它变得高质量”，那么就把X全部砍掉，别再做了。这可能意味着你预先没有做好足够精确     的评估，或者被其他无关因素影响了工作进度。

“但是等一下，那太糟了，”你会说，“X功能已经开发了90%，假如不发布，之前全部的工作就都铺张了。”

的确，铺张时间和精力是不对的。我们在工作上投入了热忱，谁都不盼望铺张掉，但这就是沉没成本谬论（SunkCostFallacy）。

假如你已经认为一个功能不值得花时间去完善它，但仅仅由于之前投入了时间，就连续发布一个更糟糕的版本，这是不合理的。

二、“会的”

假如答案是“对，我们会连续在X功能上投入，由于它需要很长时间才能变得更好”，那么说明X功能的确很重要，值得我们努力使它完善。

明显，足够优秀的产品必定有足够优秀的功能，假如团队的目标就是达到优秀，就不能只为了按时交付，就拿出一个功能和体验都很糟糕的产品。

当你遇到权衡逆境时，试着让自己首先回答这个问题。久而久之，你会更好地优先处理最重要的事情，你的评估会变得更精确     ，执行力也会提升。

把产品是否胜利与功能交付数量的多少混为一谈是错误的（It’samistaketoconflatesuccesswithshippingalargequantityoffeatures），与之相反，我们应当：

列出你的团队正在进行的工作；根据重要性对每件事进行理性排序；该砍就砍：你无法像你自己想象的那样能完成那么多的事（比如我以为写这篇文章用一天就足够，而现在已经是第五天了）。确保执行：每周设置里程碑，做事保持紧迫感。

假如1号优先级功能开发开头失控，考虑删除功能5、4、3直到确保高优先级功能1、2得到良好完成。我个人宁可听到工程师说“依据目前安排的资源来看，这5个功能我可以完成两个，所以我们评估一下优先级吧”，也不愿接受5个实现得很糟糕的半成品功能。将高质量的产品发布上线（并学习其中的成败阅历）：这是你的用户应得的。始终保持做最重要的少数事情，并把它们做好（Dofewer