要质量，还是要进度？
编者按：在周日夜间问各位周一午安。超忙的一周过去了，年会也已结束。刚刚在衡山路的国际礼拜堂做晚礼拜，坐下听着诗班安静地吟唱着，才真真切切感到身体上的疲惫。
本周第一发，来自合作作者 Echo 的译文。我很喜欢 Echo 的文风，并因为她译了 Julie Zhuo 的新随笔而惊喜。Echo，曾经的景观设计师，半年 UX 设计经历，如今是一名日常需要“左右逢猿”的产品经理；所谓“左右逢猿”，即指需求评审时左右都是程序猿，需舌战群猿，以一敌多。- 编者人格的 C7210
要质量，还是要进度？
如果说，有一个围绕着产品设计开发所展开的争论，会像“星球大战 vs. 星际迷航”一样没完没了，那一定是“质量与时间之争”，也就是所谓的“The Tradeoff Between Quality and Time”，简称“TTBQT”。
争论通常是这样发生的：
Alice：“我们现在实现 X 功能的方式不大对头。我有一个更棒的方案。”
Bob：“但我们距离开发完成只有两周了。为了优化 X 而推后发布时间，这值得吗?”
Alice：“但是我们应该关心质量。”
Bob：“我们也应该关心能否准时交付。”
Alice 和 Bob 严肃地看着对方，双手似乎紧抓着闪亮的光剑，随时准备拔剑决斗….等等，我们走错片场了。
最后的情况可能是其中一方说服了另一方，也可能是争论升级。最终，团队要么接受延期发布的事实，要么同意交付一个质量比较差的产品。这两种情况都不值得庆祝。
你可能会想，这就是产品设计开发过程中时常遇到的问题嘛，TTBQT 无非是“必要之恶”。
注：“必要之恶”是指为了实现好的结果而必须发生的恶事。 它是“两害相权取其轻”中较轻的一方。
真的是这样吗？
诚然，不时地在这两者之间进行权衡是有益的，这能确保我们不会因为打磨产品而减少收益，或是被时间表主导产品开发进程。
不过，我想提出的是第三种选项。
当你们进入了 TTBQT 状态，真正要问的问题是：“如果我们事先已经知道开发高质量的 X 功能需要很长时间，那么我们在一开始还会不会选择去做这个功能呢？”
这个问题非常有效，能迫使团队去检查问题存在于何处，譬如：
- 团队的优先级排序原则是否足够坚定？
- 团队对于执行力的预估是否足够准确？
- 团队的实际执行力是否足够优秀？
而且这个问题有助于我们从 TTBQT 当中获取真正有益的决策。
“不会”
如果答案是“不会，花费大量时间去打造高质量的 X 是不值得的”，那么就完全去掉 X，停止对它的开发投入。
你可能会说，“等等，那太可怕了，X 已经开发了90％。如果不发布，之前所有的工作就都浪费掉了。”
确实，时间和精力被浪费掉是令人痛苦的，因为我们甚至会从情感上与自己所做的产品项目产生关联。但这也正是“沉没成本误区”的所指。如果你认为某个功能根本不值得花费时间去做到最好，那么仅仅因为不愿浪费掉已经投入的时间成本而决定发布一个糟糕的版本，这是不理性的决策。
“会”
如果答案是“会，我们知道需要花很长时间才能让这个功能变完美，但仍会决定开发这个功能”，这就表明 X 非常重要，并且值得投入努力让它变得更好。
每当你遇到 TTBQT 困境时，不妨试着通过这种方式进行评估。长此以往，你的决策将更加理性和聚焦；您将能更好地为重要事项进行优先级排序，你的预估将变得更加精准，执行力也会得到提升。
将产品成功与否与每次发布功能的数量混为一谈，这是错误的。取而代之，我们应该：
- 列出团队正在进行的工作清单。
- 衡量每件事的优先级，并理性排序。
- 该删则删。你无法像你自己想象的那样能完成那么多的事（比如我以为写这篇文章用一天就足够了，而现在已经是第五天了）。
- 确保有力执行。每周设置里程碑，带着紧迫感工作。如果功能1的进程开始失控，考虑删除功能5、4、3...直到能够确保优先级位于前列的功能1、2得到良好完成。
- 最终，将高质量的产品发布上线（然后获取成功，或是虽败却有所收获），你的用户值得体验它。
记得，让更少的事成为更重要的事，并把它们做得更好。
- 英文原文：https://medium.com/@joulee/how-to-make-things-high-quality-f466f875227d
- 原文作者：Julie Zhuo
- 译者：Echo（Beforweb 合作作者）
- 编者：C7210
译文代表原作者观点。欢迎发表评论，或到译者微博进一步交流探讨。