我听过这句话：“好，便宜，快：选两个。”
对于编程项目，通常会有“最好的两个？”
答案 0 :(得分：11)
这完全取决于您的客户。
如果他们愿意付钱，那么好的和快的总是优先考虑......
答案 1 :(得分：8)
这只是一个更简单的预算与时间和范围的陈述。两个是固定的，一个是可变的。
问题是，他们几乎总是想要所有3 ...
答案 2 :(得分：6)
我更喜欢好又快......业务总是选择廉价和快速
答案 3 :(得分：5)
我的经验是，其中只有一个是可能的
答案 4 :(得分：3)
大多数工程师会告诉你他们想做好工作。这很自然。几乎没有人喜欢回顾他们生活中的工作，看到他们制造了大量便宜的垃圾。你希望能够为你的生活所做的事情感到自豪。
这不仅限于软件。如果你发现自己是一名优秀的机械师，喜欢这项工作的人，他们总会试图让你解决正确的问题。例如，他们将推动一辆旧二手车的600美元发动机工作来修复一堆缓慢的油泄漏，这将不会花费你在其生命周期内接近600美元的油。我曾经认为他们都希望能够帮助我，但事实并非如此。他们只想做正确的。
了解我们的客户和非工程师老板看待我们的方式与我们看待汽车修理工的方式相同，这是智慧的开始。
答案 5 :(得分：2)
我总是努力追求良好和快速。遗憾的是，经常提供的是廉价和快速。
我认为人们经常犯的错误是“廉价”而不考虑项目生命周期的总成本，包括支持和维护。如果最初的出价包括这些额外的项目（我建议“低价”项目比非便宜的项目成本高得多），便宜的选项往往看起来不那么吸引人（从长远来看往往是最昂贵的）。
从我的经历中得到一些想法......
答案 6 :(得分：1)
另一种看待这种情况的方法是，基本上有四个变量可以控制到或多或少。
在这四个中，通常您希望将质量提高，尽管有例外。资源最好事先添加，因此除非您的时间表很长，否则也会合理地修复。因此，权衡通常在范围（什么）和时间（多长时间）之间。我倾向于减少范围并满足最后期限，如果我能提供的仍然有价值。通常这是在特定迭代的上下文中，稍后将添加删除的功能，可能会增加项目的总体时间。
在你的万神殿中，我认为这等同于善与快。
答案 7 :(得分：1)
根据经验，我会说大多数项目都倾向于廉价和快速。我在生活中看到的好软件的比例很小......
答案 8 :(得分：1)
这实际上取决于项目。对于有资金约束的初创公司，廉价和快速通常是最好的方法。如果你有无限的资金，显然选择快速和好的是最好的方法。它因情况而异。
答案 9 :(得分：0)
这取决于项目和客户拥有的可用资源。没有一个答案。
答案 10 :(得分：0)
好主观是廉价而快速的。至少那种方式如果它不好（这与其他人的好处相同）你可以用最小的麻烦扔掉它。
答案 11 :(得分：0)
好又快！
答案 12 :(得分：0)
如果你不想花钱好又便宜就好了
答案 13 :(得分：0)
最好的2 - 好＆amp;快
现实 - 快速＆amp;廉价
答案 14 :(得分：0)
就个人而言，我认为这通常取决于项目的性质，很可能取决于客户。廉价和优惠通常适用于预算较低的人。对于预算较高且可能导致更多项目的客户而言，良好而快速。
答案 15 :(得分：0)
开源=＆gt;好＆amp;廉价
答案 16 :(得分：0)
和其他人一样，我更喜欢好又快。
但我觉得这太简单了。从长远来看，采摘廉价最终会削弱这种利益。有时，快速选择也可以，因为创新应该涉及更高程度的原型设计和测试。
当然，每个项目都有不同的条件（以及复杂程度，创新水平和规模经济），但一般来说，我认为真正好的意味着你不能太便宜或太快。
答案 17 :(得分：0)
一个未被封闭的主观，非编程问题。谁会想到这是可能的......
编辑 - 当，看起来我太快进入了我的帖子......
答案 18 :(得分：0)
质量足够好，速度足够快，而且价格足够便宜。如果你不能得到这三个，那就不够了，你应该停下来重新思考你的项目。
答案 19 :(得分：0)
客户昨天不需要任何费用就会想要一切。
它在每个请求中找到了一个平衡，有助于确定这是我争取的东西（好的和快的）还是节省了一些钱，因为它不是那么重要，或者他们可能不会根据需要使用它（好又便宜）
第三个选项，Fast and Cheap，并不意味着它对我来说不会好。更重要的是，我们正在减少实施以满足您的预算和时间表，并确保我们能够很好地实施它。
什么时候没有选择？
在尝试选择Good，Fast或Cheap中的2时，我使用了一个简单的测试：
1）有多重要？ 2）有多复杂？ 3）在您认为可以更快地完成之前需要多长时间？
基于这些答案，我试图争取以下内容：
- 这很简单吗？真的吗？快速和便宜可能足够好。如果我们从简单的事情开始并根据您的需要构建它，如果您需要它，那么从它的方法开始将更快，更便宜。否则我们将完成所有这些工作并且无论如何都必须改变它，无论如何都会耗费时间。这在某些方面可能是敏捷开发。
- 这很复杂吗？真的吗？如果它如此重要和必要，你确定你没有过度工程吗？
- 我可以立即以一口大小递送吗？他们现在怎么做？即使是一个简单的解决方案，它可以做一些核心和关键的事情，对于现在如何完成它们会有很大的不同？然后，做得更少可能会更好，但做得好又便宜。 我的经验法则是始终以小胜利开始，这些胜利比他们的努力具有更大的影响，让他们滚雪球并获得进入大系统的动力。没有人喜欢比他们想要的更快的系统。所以，你给它们一个或三个特征。只需确保您的测试和签收过程就在那里。
只是一些想法，希望这是一些值得思考的东西。