Office構築Sharepoint項目的五個建議

　　在過去的幾個月，事實上有好幾年裡，企業機構對Sharepoint的看法明顯有著分歧。一部分企業認為Sharepoint是微軟出品的另一種產品，他們可以購買並安裝在他們當前的系統中;另一部分認為Sharepoint更是一個可以構築的戰略平台，並且將從中獲得商業利益。

　　Sharepoint - 產品

　　理論上來說Sharepoint是一個產品。由微軟開發，並且必須花錢購買。是的，你可以簡單的購買序列號，往服務器上插入CD，然後驚訝於只需要這點點那點點就可以建立起一個Sharepoint服務器。他甚至可能已經具備非常好的功能了，或許已經足以滿足你的協作甚至文檔(管理)需求了了。在大部分采用這種方案的企業中，往往有兩種現象。一、沒有正確的配置Sharepoint，Sharepoint只是一個被贊美的共享驅動器拓展;二、企業根本看在Sharepoint系統中根本看不到任何利益，而Sharepoint也常常得不到采納。我並不是說所有的客戶都會這樣子，但是根據我的經驗，存在這兩種現象的客戶超出你的想象。

　　Sharepoint - 平台

　　這是在當你對Sharepoint有比較深刻的認識的時候，(你會覺得)縱然Sharepoint像一個產品一樣被出售，但它事實上是一個平台，它需要一些親切的愛和關心，這樣他就會如你所願的運行。當企業花費時間和努力去設計、開發和部署Sharepoint系統，讓他擁有所有的預定義內容類型和良好的分類系統時，Sharepoint被正常的采納了並很快就成為企業的一個關鍵系統。現在我們知道Sharepoint不是總是這樣運行的，但是要如何才能確保Sharepoint像這樣運行呢?

　　在這篇文章中，我不打算談這個問題，因為已經有許多文章討論了這個問題。但是，我想寫的是對於一個傑出的Sharepoint項目構築應該要執行的幾個步驟：

　　讓專家參與

　　在公司內部推廣這個平台

　　讓企業參與

　　設定預期效果

　　測試再測試

　　讓專家參與

　　這是指在你打電話給我並對說，Liam快來幫我的時候!!這只是一個玩笑，但是讓一些人將設計、開發和部署Sharepoint作為全職工作或許是很昂貴的，但這樣可以從內部加快你的部署速度。Sharepoint方面的專家對這方面有經驗，比如獲取T-Shirt等(譯注：got the T-Shirt etc，不知道是不是獲得某種身份的意思)，他們常常知道相對於一種方法另一種方法所潛在的陷阱。我的建議是，讓那些在某些領域可能有幫助的人參與，這不是說要讓他們做所有的事情，只是讓他們來幫助你擴大業務，以確保在初始設計階段不會出什麼錯誤。

　　在公司裡推廣這個平台

　　當微軟開發了一個新的產品時，在網上進行半成品測試是其生命周期的一部分，或許是通過技術采納計劃(TAP)、快速部署計劃(RDP)、Events、Tech-Ed Sessions、Webcasts以及大量的文章。你覺得微軟為什麼這麼做呢?

　　簡單的來講這是為了獲取關於新技術的反饋，以及讓人們對新開發的技術感到興奮。我想起Vista，Office以及Exchange事件，想想激動的微軟是如何推出他時尚的新產品的。這是我們在企業內部部署Sharepoint系統時也應該做的。我的意思不是說我們應該開始像前面所描述的那樣去做，因為這些稍微有些過度，而且需要耗費一部分錢。但是想要讓企業買你的帳，你需要讓企業為你所做的事情感到興奮。如果Sharepoint由IT部門構築而且他們選擇將Sharepoint作為產品來使用，那麼一般大部分的用戶會不喜歡。這種觀念必須改變，是的，Sharepoint可能是一個由IT部門做出的選擇，但是必須讓全公司相信那是他們的選擇，因為他們不能沒有(Sharepoint系統)。

　　讓企業參與

　　隨著(系統的)推廣，讓企業參與進來是成功的關鍵。作為一個Sharepoint顧問，項目的成功真正基於我能夠獲取企業的需求然後提供一些他們想要使用的東西。如果企業從不參與進來，那麼我幾乎是在猜測企業的需求，然後告訴他們你需要照我說的做!這聽起來像是一個獨裁者。J

　　作為我工作的一部分，當基礎設施工作和企業分析工作的比率出現顯著差異的時候，我負責設計和開展會議。在一個普通的解決方案裡，架構和基礎設施設計可以很快被解決，但是為人力資源部門獲取企業需求我們覺得需要兩次那麼長。這裡的關鍵是讓他們參與到系統的可用性和分類目錄(設計)中來，這樣你將取得成功。像一個企業用戶那樣思考。

　　問題：“為了獲取內容，我已經有十個系統需要訪問了，為什麼我以後還再多訪問一個?”

　　答案：“因為這是所有系統的展示層，而且對文檔和內容同樣提供完整生命周期的管理”

　　設定預期效果

　　這與獲取需求一樣的重要。設定預期效果可以成就一個項目，也可以搞垮一個項目。很多時候我看著系統構築完成，演示然後受到了類似這樣的評論，“在系統上你將可以獲得一個你的SAP時間表的只讀視圖”，最後導致項目的失敗，因為企業發現他們沒有企業許可號(譯者注：應該是指MOSS的企業許可號，因為BDC需要MOSS)，也無法使用業務數據目錄集成。我知道這聽起來很可笑，但是這是真實的。

　　現實點，如果說你打算提供一個建立在Sharepoint上的時間表系統，這個系統可以自動填充到工資總支出(譯者注：Payroll)服務器和項目服務器上，那麼竭盡全力去做。如果你想要實現這些，那麼事實上請不要做出任何許諾甚至不要提到它，以免企業用戶將聽到些什麼並奉為真理。通過分解成多個步驟的方式來設定預期效果，然後通過一切手段公開給企業，讓他們了解。在我曾經工作過的一個項目，采用了這種方法(來設定預期效果)，不僅僅根據時間分解成多個步驟，同樣在每個步驟中根據功能來分解成一段一段的。這樣允許項目的管理團隊或者你自己在更小的訪問內進行管理部署。這將使得部署更為成功，而且企業對什麼時候什麼樣的功能將發布有一個明確的路線圖。

　　測試再測試

　　這一步對我來說是最重要的步驟之一。你完成了你的系統，所有的一切都很好的渡過了，而且准備好了在周一早晨部署到企業。周一早餐如期到來，在剛開始的幾個小時內一切都很好，突然出現了意外，事件日志出現了錯誤(記錄)，用戶被拒絕訪問或者系統反應緩慢。那麼你想，如果我們已經在完整范圍內進行了測試，那麼我現在已經發現了這些問題以及如何解決。在許多項目中，我曾經發現隨處存在著測試或者壓力測試沒有考慮到的因素。用戶驗收測試(UT)看起來總是能完成，但是他是面對一小撮選定的用戶，而不是公司內所有的用戶。為了確保你的解決方案可以適用於大范圍，而且你的新系統沒有瓶頸存在，那麼需要正確的進行測試。

　　這些步驟對於構築Sharepoint來說並不是精確的科學;我簡單的寫下這些是為了分享我經歷過的，以及分享當你決定為企業構築Sharepoint時什麼可以良好的運行。如果你有什麼想要添加的，或者不同意其中的任何一項，請在評論中告知。