收集潛在需求的想法不是很困難。幾乎每一個經(jīng)常接觸產(chǎn)品的人——不管他們是企業(yè)內(nèi)部還是外部的人——都至少能說出“這個產(chǎn)品應(yīng)該增加哪些特性”的某個想法。最棘手的部分是排列出哪些功能應(yīng)該包含到你現(xiàn)在的這個網(wǎng)站建設(shè)項目中去。

???

在戰(zhàn)略目標(biāo)和需求之間，你幾乎看不到一對一的簡單關(guān)聯(lián)。有時一個需求可以滿足多個戰(zhàn)略目標(biāo)。同樣，一個戰(zhàn)略目標(biāo)也常常關(guān)系到多個不同的需求。

因為這些范圍在建立是戰(zhàn)略層的基礎(chǔ)上的，因此我們就需要去評估這些需求是否能滿足我們網(wǎng)站建設(shè)的戰(zhàn)略目標(biāo)(無論是網(wǎng)站目標(biāo)還是用戶需求)。除了這兩種情況，我們還要額外確定第三種范圍：實現(xiàn)這些需求的可行性有多大?

??? 有些特性可能會因為技術(shù)上的局限而無法實現(xiàn)——舉個例子來說，現(xiàn)在還完全沒有辦法讓用戶能聞到網(wǎng)頁上產(chǎn)品，無論他們是如何渴望這個功能。另外一些特性(尤其是內(nèi)容方面的)之所以不可行，則是因為它們需要很多資源去做——無論是人力還是力——超出了我們的能力范圍。而有時候，僅僅是因為時間不夠：這個特性需要花費(fèi)三個月來完成，但是企業(yè)的管理層要求在兩個月以后上線。

???

如果是因為時間有限，那你可以把這個特性放到下一個版本或項目里程中。如果是資源有限，則技術(shù)或企業(yè)的改變有時——但

重要的是，并不總是——能減少資源的負(fù)擔(dān)，使某個特性得以實施(無論如何，不可能的事情仍然不可能實現(xiàn)，這很遺憾)。

???

?很少有功能是獨(dú)立存在的。甚至網(wǎng)站上的內(nèi)容特性也要依賴其他特性的支持，并告訴用戶怎樣最好地利用所提供的內(nèi)容。這不可避免地導(dǎo)致了特性之間的沖突。有些特性要和其他的一起權(quán)衡，才能得到一個連貫的、統(tǒng)一的產(chǎn)品。舉例來說，一些用戶也許想要一步提交訂單的過程——但是網(wǎng)站所使用的、混亂的老數(shù)據(jù)庫無法適應(yīng)這個需要。采用多個步驟的流程是更好的辦法，也許你可以重新設(shè)計數(shù)據(jù)庫系統(tǒng)?這完全取決于你的

戰(zhàn)略目標(biāo)是什么。

留意那些看上去有可能需要改變戰(zhàn)略的特性建議，它們在開發(fā)可視文檔期間并不明顯。任何不符合當(dāng)前項目的戰(zhàn)略目標(biāo)的特性建議，都要通過定義將其排除到范圍之外。但是如果有一個特性的建議，盡管它不在項目范圍之內(nèi)，超過任何類型的限制條件，并且聽起來像一個不錯的想法，但你可能需要重新審視某些戰(zhàn)略目標(biāo)了。不管怎么樣，如果你發(fā)現(xiàn)自己正在重新查看戰(zhàn)略目標(biāo)的話，那么你可能是太早地進(jìn)入需求收集階段了。

???

如果你的戰(zhàn)略計劃或可視文檔在戰(zhàn)略目標(biāo)的范圍內(nèi)確定了一個清晰的優(yōu)先級別順序，那么這些優(yōu)先級別應(yīng)該是決定人們所建議的相關(guān)特性的首要因素。有時候，兩個不同戰(zhàn)略目標(biāo)之間的重要程度也會出現(xiàn)不是很清楚的情況。這時候，特性最后是否能納入項目范圍之中，往往取決于企業(yè)的政治局面。

???

當(dāng)管理層談到戰(zhàn)略的時候，他們通常從某種產(chǎn)品特性開始，然后你不得不耐心地把他們引導(dǎo)到后面的戰(zhàn)略因素上去。由于管理層常常分不清特性和戰(zhàn)略，某些特性就會在這個討論需求的過程中占據(jù)了上風(fēng)。因此需求的收集過程就變成了與這些管

理層進(jìn)行談判的過程。