对于一个基于网络的在线软件应用程序，我们在决定产品开发的方法上面临着困难。

我们正在致力于在线Web应用程序的系统设计，该应用程序有可能作为SaaS服务提供。我们在决定下面的系统设计和实现相关的决策时遇到了困难，也有很多成本考虑。

方法A：

我们设计和开发的每一件事情都考虑到了非常基本的需求，这些需求只是满足了基本的需求，并解决了手头的给定问题，然后启动它。一个足够好的系统可以支持几百个用户，而不必过分关注微观优化。

我们通过添加新模块在客户机请求时添加新功能。

因此，简单的设计，单一的开发，必要时可以通过升级基础设施或在需要时进行优化来进行扩展，并且将来可能会根据需要用全新的系统来取代系统。

我们保留相同的服务器，但客户端帐户的数据库不同。同样，为每个访问独立数据库的客户机托管不同的应用程序等。当需要时，我们可以添加新的服务器。虽然管理/维护和升级几乎不困难。

方法B：

我们研究了可能增加附加值的完整需求和可能的功能(尽管我们仍然不确定这些附加功能会增加多少价值？)并从一开始就设计出支持大量用户(具有大量硬件)的系统。

我们推出功能齐全的应用程序，从一开始就进行了很好的优化。

我们设计它来支持单个数据库和应用程序托管中的多个客户机帐户，并在云服务器/负载平衡服务器上实现它，其架构类似于成熟的SaaS应用程序。尽管这使得代码和维护变得非常困难。而且执行起来肯定需要更多的时间。

请注意，

我们准备了功能列表、用户界面和可能使用的技术设置。我想知道解决这种情况的最佳方法是什么。

如前所述，对于另一个产品开发项目，有了一组所有的特性，完成它花费了太长的时间，甚至它也有一些根本没有被使用的特性。这种项目的成本考虑非常高，我更愿意采用方法A，因为这是快速、简单和可预测的。此外，与第二种方法相比，我很快就会得到用户反馈，这可能有助于我决定关注哪些特性以及为什么。此外，当需要时，我们可以重写整个应用程序，重点关注与方法B类似的系统。

我想了解其他公司如何管理这种情况，以及什么是实施此类项目的最佳方法？

这是经典的大设计前沿(bduf)辩论的新版本：我们的设计是在实施之前完成并完善，还是应该渐进设计？

我已经看到了支持BDUF和反对BDUF的很好的论据。就我个人而言，我更喜欢一个中间点：有必要做一些前期设计——否则你的设计会在迭代过程中发生根本性的变化——但是这个阶段不应该花费太长的时间，否则你只有一个架构文档和几个月的工作后无聊的程序员。

所以，我将用方法B来做一些方法A。

这要看情况而定。

经验法则：

• "没什么"比"坏"好。
• 80%的溶液总比没有好。
• 前80%将消耗80%的资源。
• 接下来的20%将消耗您80%的资源。
• 如果你不以80%的价格发货，别人会的。
• 在达到80%之前，你不知道剩下的20%。
• 环境和需求的变化比你想象的要大。即使在应用了这个规则之后。

不要让你的顾客等得太久，运送一个破损的或无法修复的产品，以此吓跑他们。不要把钱浪费在你不需要的基础设施上。

接近A听起来很明智…如果您也可以采用敏捷的Scrum，这意味着您可以在Sprints中迭代地与客户机一起工作，您可以在每次Sprint之后开发和交付产品版本和特性。客户机可以看到交付的软件单元越来越小……客户机常常会改变主意，决定他们想要什么新功能。

因此，您总是有机会响应客户需求，并且只构建客户需要的内容。