1.1 定義解決方案設計的多個階段及其意義

設計解決方案與其他工作一樣，都要按步驟進行，而且其中涉及的不僅是技術問題或技術人員。一般來說，會有客戶經理或項目經理與你溝通，更好一些的情況是，CTO會跟你談客戶所提的需求中與技術有關的部分。他們需要尋找一位專家來幫助他們向客戶交付一套解決方案，然而他們所說的那些需求，通常無法把交付該方案的全部信息呈現出來。盡管如此，你還是要從這些需求出發，來摸清該方案的目標。

例如，你收到了項目經理發來的郵件，其中寫道：

我們要做一個至少支持10000次網站點擊的解決方案，在更新或停機的時候，這個方案依然要能夠使用。預算相當少，因此要盡量壓低開銷，而且最好是能免去預付成本（upfront cost）。我們還希望，這個方案能夠讓項目在其生命期內得以持續壯大。

這封郵件只能讓你對所要做的方案有個大概的印象，并沒有給出具體的細節。因此，你只能了解基本的信息，也就是該方案必須支持至少10000次網站點擊。這條信息對設計工作來說，是不夠明確的，你還必須了解相當多的信息，才能知道怎樣解決客戶提出的要求。這正是你需要繼續追問細節的地方，只有把細節問清楚，才能知道客戶的需求到底有哪幾條，而客戶也可以由此形成對該項目的第一印象。這部分工作很關鍵，因為它可以幫助你意識到，自己究竟有沒有理解客戶的想法。

同樣重要的是，你還必須意識到應該提出幾套不同的方案給客戶選擇，客戶會從中選出最符合需求的一個。每個備選方案都有優點與缺點，不過客戶一旦選好，你就得把實現該方案所需的必要工作給處理好，此時通常會遇到許多難題。而且到了方案即將完成的時候，你可能還得做出某些調整或變更，這些情況在早前的POC（Proof of Concept，概念驗證）階段是無法預料到的。

從前面的分析可知，為了交付最終產品，需要經歷4個階段，如圖1-1所示。

圖1-1

除了這4個階段，還可以定義其他一些階段，或是按照其他方法來設計解決方案，但那些都不在本書的講解范圍內。本書主要根據上述4個階段來幫助你了解如何給解決方案做架構。