产品开发，要进度还是要质量？

如果团队中出现了围绕产品开发工作展开的争论，类似“星球大战与星际迷航”（的粉丝群）之间无休止的吵架，那就是我所说的“质量与时间之间的权衡”（The Tradeoff Between Quality and Time，TTBQT）问题。

通常情景是这样的：

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

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

艾丽丝：但是我们应该关心质量。

鲍勃：但是我们应该关心交付。

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

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

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

真的是这样吗？

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

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

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

• 团队在优先级排序时有多坚决？
• 团队对执行能力的评估有多准确？
• 团队在执行力方面有多优秀？

我喜欢这个问题的第二个原因是，它有助于澄清权衡决策应该是什么。

一、“不会”

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

“但是等一下，那太糟了，”你会说，“X 功能已经开发了 90%，如果不发布，之前所有的工作就都浪费了。”

确实，浪费时间和精力是不对的。我们在工作上投入了热情，谁都不希望浪费掉，但这就是沉没成本谬论（Sunk Cost Fallacy）。

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

二、“会的”

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

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

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

把产品是否成功与功能交付数量的多少混为一谈是错误的（It’s a mistake to conflate success with shipping a large quantity of features），与之相反，我们应该：

1. 列出你的团队正在进行的工作；
2. 按照重要性对每件事进行理性排序；
3. 该砍就砍：你无法像你自己想象的那样能完成那么多的事（比如我以为写这篇文章用一天就足够，而现在已经是第五天了）。
4. 确保执行：每周设置里程碑，做事保持紧迫感。
   如果 1 号优先级功能开发开始失控，考虑删除功能 5、4、3…直到确保高优先级功能 1、2 得到良好完成。我个人宁可听到工程师说“根据目前分配的资源来看，这 5 个功能我可以完成两个，所以我们评估一下优先级吧”，也不愿接受 5 个实现得很糟糕的半成品功能。
5. 将高质量的产品发布上线（并学习其中的成败经验）：这是你的用户应得的。始终保持做最重要的少数事情，并把它们做好（Do fewer things better, but make them the most important things.）

毕竟，现实世界没有什么事情是完美的。

作者：Julie Zhuo，Facebook 产品设计副总裁

原文：https://medium.com/the-year-of-the-looking-glass/how-to-make-things-high-quality-f466f875227d，文章经过综合编译

本文作者 @鹈小鹕 。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！