你根本不需要去追求“完美”的软件！

每一个软件都不是完美的，因为软件是由那些珍惜时间的人或团队编写创造的。




你曾经放弃过一个功能吗？
或者你有没有经历过尝试做一些新的东西，但是后来发现工作量太大，然后放弃转而做了其他的事情呢？
或者说，你是否曾经尝试修复一个 bug，但是发现它只影响少数用户并且难以复现，而忽略它呢？
你怎么可能让你的代码中留下一个已知的错误？为什么要故意发布不完整的代码？
那么，完成这个功能需要花多少时间呢？修复这个 bug 对你的公司来说值多少钱呢？
每一个软件都不是完美的，因为软件是由那些珍惜时间的人或团队编写创造的。
我的一位经理曾经给我讲过一个添加一个手势动作的功能的故事。很多用户不断地要求提供这个功能，最终我们尝试实现它。
我们把它交给了一个初级开发人员，一两天后，他不知道怎么做。然后我们把它交给了另一个开发者，让他们一起干。但是，他们仍然不知道如何去做。
这种情况又发生了三次。我们把它交给了五个开发人员，干了几周最终还是“流产”了——我们在这上面浪费了大量的时间。
假设每个开发人员花了 6 个小时在这上面。5 x 6= 30 小时。假设开发人员的平均时薪是每小时 43 美元，43 x 30 = $1290。那最终，他们花了一千多美元试图实现最终没有成功投入生产的功能。
也许你几乎开发完了所有的 UI 功能，但是设计师想搞点特色。假设你被要求实现一个应用程序内的 web 浏览器。iOS上 Swift 的开箱即用解决方案看起来是这样的：


IOSCreator.com 教程中的一张示例图
注意顶部和底部周围的按钮，这些都是免费的，可以通过 URL 和几行代码就可以创建整个视图。
然而，如果设计师希望调整按钮的位置，或者减少一些按钮，或者可以为按钮设置不同的颜色。突然之间，几行代码就变成了一个为期两周的项目，在这个项目中，你需要创建一个自定义视图，为按钮创建所有你自己的逻辑，并为整个屏幕设计样式——你可以在脑子里计算这笔费用。
我们最近遇到了一个 bug，当一些用户的应用程序在应用程序中执行某个操作时，该 bug 导致程序崩溃。我们的应用程序监控工具显示：只有不到 100 个用户 (我们有数百万用户) 看到了崩溃。堆栈跟踪的级别都非常低，且非常混乱和冗长。我们不确定是什么导致了系统崩溃，我们只知道这和用户设备上的数据库有关，而我们无法复现这个问题，但我们相信卸载和重新安装应用程序很可能会修复这个漏洞。
你害怕了吗？大多数的 bug 在可复现时都很容易修复。当缺陷影响的用户比例较大时，它们的优先级就会快速上升。这个 bug 越不容易复现那么影响的用户比例就越小。修复这个 bug 的成本是无法计算的，但是修复它的价值却最小。
软件的成本效益是一个复杂的方程式。
如果那个定制的网页浏览器对你的产品经理来说是值得的呢？或者这个手势的价值超过了1000美元呢？一个现有的手势功能能够给用户带来的价值是什么？对于用户来说，一个漂亮的、可以自定义的网络设置有什么价值呢？
也许你工作的公司不会让任何用户的应用程序崩溃，你根本不会遇到上述 bug。也许你在飞机上工作或者为医疗设备编写软件，你的软件不会崩溃。那么，修复漏洞的价值就取决于它对整个公司的价值（希望这个漏洞是可以修复的）。
这就是产品经理存在的原因。但开发人员也必须参与其中，我们就是那些做功能评估的人，也是那些有时不得不说“这就是做不到”的人。
我们还必须说，“做这个需求比你想象的时间要长”。设计师和产品工程师在设计功能的时候都会考虑功能的大小。他们要求改变，并且知道成本或者需要多少时间。但他们不是开发人员，软件的变更带来的工作量变化很难估计！
以 web 浏览器为例：设计师可能想要改变按钮的颜色。他以前就被要求改过按钮的颜色，和这次改动非常相似，所以他认为这次改起来也会很快。但你知道事实并非如此。当你接到要更改按钮的任务时，作为开发人员，你的工作就是反馈这个改动将花费更多的时间。
大多数时候，完美的东西是不值得的。
如果你来问我，我永远不会花时间去做一个自定义的 web 功能；我可能会在找第三个开发者开发手势功能的时候就停止；我甚至不会把崩溃归档到待办中。因为这么做投入产出比太低， 但如果你的软件能为你的用户提供价值，就没问题。
所以说，你的软件不一定要完美。