需要幫助來決定產品開發的軟件設計/體系結構？

Question

關於基於在線Web的軟件應用，我們在確定產品開發方法時面臨困難。

我們正在使用的系統設計必須被提供作爲SaaS服務的潛在的在線Web應用程序。在決定遵循系統設計和實施相關決策時，我們在這裏面臨困難，也有很多成本考慮。

解決方法A：

我們設計和開發的一切考慮，這只是履行手頭給出問題的基本要求，解決了很基本的要求，並啓動它。一個足夠好的系統可以支持幾百個用戶，而不用過多地關注微觀優化的一切。

我們通過添加新模塊添加新功能，當客戶端請求時。

所以，簡單的設計，單一的開發，規模在必要時由要麼升級基礎設施或需要時，還不如在未來的需要，總的新系統替換系統優化。

我們保持相同的服務器，但客戶端帳戶有不同的分貝。同樣，爲每個訪問單獨數據庫的客戶端託管不同的應用程序，等等。需要時，我們可能會添加新的服務器雖然很難管理/維護和升級。

方法B：

我們研究所有要求，可能的功能補充，可能會增加額外的價值（儘管我們仍不能確定上述附加功能添加多少價值？），並設計系統支持從一開始就有大量的用戶（擁有大量硬件）。

我們推出全功能應用程序，從一開始就非常優化。

我們設計，它支持在單個數據庫和應用託管多個客戶帳戶，並與像一個成熟的SaaS應用程序的架構實現它的雲服務器/負載平衡服務器上。雖然這使得編碼和維護非常困難。絕對需要更多時間來實施。

需要注意的是，

我們正在與功能列表，用戶界面和可能的技術設置，我們可能會使用準備。我想了解什麼是解決這種情況的最佳方法。

正如前面我已經看到了一個其他產品開發項目，與集合的所有功能，它花了太長時間來完成，甚至它有這樣的功能，是不是在所有使用之中。對於這樣的項目，成本考慮非常高，我寧願採用方法A，因爲這是快速，簡單和可預測的。此外，與第二種方法相比，我很快就會收到用戶反饋，這可能會幫助我確定要重點關注哪些功能以及爲什麼。此外，當需要出現時，我們可能會重新編寫完整的應用程序，重點是類似於方法B的系統。

我想了解其他公司如何管理這種情況，以及可能是最佳方式實施這樣的項目？

Answer 1

這取決於。

規則拇指：

• 「沒有什麼」 比 「破」 更好。
• 80％的解決方案總比沒有好。
• 第一個80％將消耗您資源的80％。
• 以下20％將消耗您的資源的另外80％。
• 如果您沒有以80％運送，其他人會運送。
• 在達到80％之前，您不知道剩下的20％。
• 環境和要求變化超過您的想象。即使在應用這個規則之後。

不要嚇跑你的客戶，讓他們等待很長時間，運送破損或不可維護的產品。不要在基礎設施上收錢你不需要（還）。

Answer 2

這是典型的Big Design Up Front (BDUF)辯論的一個新版本：難道我們的設計完成和完善實施前完成，否則我們將逐步的設計？

我見過相當不錯的參數pro-BDUF和against-BDUF。就個人而言，我更喜歡一箇中間點：有必要做一些前期設計 - 否則你的設計會通過迭代發生根本性的變化 - 但這個階段不應該花太長時間，否則你只會有一個架構文檔和無聊的程序員經過數月的工作。

所以，我會做一些解決方法A與B.方法一點點

Answer 3

解決方法A聽起來似乎在理......如果你能採用敏捷SCRUM爲好，這將意味着你可以反覆地與客戶合作在Sprint中，您將在每次衝刺之後開發並提供產品版本和功能。客戶可以看到正在交付的軟件的更小單位......並且更多時候，客戶會改變他們想要的新功能的想法。

因此，您將始終有機會迴應客戶需求，並只建立客戶需要的東西。