You think you use SharePoint but you really don't 你認爲你使用了SharePoint，可是實際上不是

You think you use SharePoint but you really don't 

你認爲你使用了SharePoint，可是實際上不是

        Thousands of organizations have implemented SharePoint but fail to exploit the most obvious of SharePoint's many benefits. Here are some suggestions for a SharePoint roadmap that can succeed. 

        無數公司部署了SharePoint，可是沒有利用到SharePoint的不少好處。這裏有關於一個能夠走向成功的SharePoint路徑地圖的一些建議。

        You see it all around you, good SharePoint gone bad. The number of SharePoint deployments in the world today has six digits in it, and four-fifths of them suck. That's a subjective observation, of course; many who deploy SharePoint (especially the license-free version) don't have very high ambitions. The irony is, they could aim much higher, and get a lot more out of their deployment without upgrading to the more expensive version.

        你能夠隨處可見，好的SharePoint變壞了。今天世界上部署SharePoint的數量有6位數了，他們中的五分之四很糟糕。固然這只是一個主觀推測。不少部署SharePoint的人（特別是免費版本的）並無很是高的雄心。然而諷刺的是，他們能達到更高的目標而且從他們免費的部署中獲得不少。

        Since "sucks" is a less-than-technical term, let's give it a focused definition: there are many organizations out there that have implemented SharePoint - with good intentions, surely - but have improved neither their processes nor their culture thereby. But the implementation that really sucks is the one that actually takes the big messes that existed in the legacy environment and simply recreates them in SharePoint.

        由於「sucks」是一個非技術詞彙，咱們來給它一個集中定義：有許多公司懷着良好的初衷實施了SharePoint，可是既沒改善他們的流程也沒改善他們的文化。可是真正糟糕的實施其實是把以前遺留的大麻煩在SharePoint上簡單地再現了。

        The typical pattern is something like this: 1) the organization has the epiphany that file shares are out of control, and content management is sorely needed; 2) SharePoint is deployed throughout the organization; 3) files are moved out of file shares and into SharePoint; 4) they rapidly spiral out of control。

        典型的模式是這樣的：1）公司的文件共享失控了，亟需內容管理；2）SharePoint部署到了整個公司；3）文件從文件共享中轉移到了SharePoint上；4）這些文件迅速失控。

        Adding insult to injury, the failure of SharePoint to solve the content management issue diverts the organization from exploiting SharePoint's other game-changing features. SharePoint persists - no one in their right mind would actually roll back those awful file shares - but nothing new gets done.

        乘人之危地說，SharePoint解決內容管理問題的失敗把公司從利用SharePoint的其餘遊戲轉移到了改變功能上。堅持着用SharePoint（實際上沒有一個頭腦清醒的人會回滾這些可怕的文件共享）卻沒有任何創新改善。

        Let's start with the two biggest problems ... which are also the two that are easiest (and cheapest!) to fix.

        讓咱們從兩個最大的問題，同時也是兩個最容易（也是最便宜的）解決的。

Share and share alike 共享

        After years of consulting on content management issues, I'm prone to stating that most organizations birth file shares in places where John Conner would feel right at home - dystopian wastelands fraught with unforeseen peril and sudden eradication. Any organization that doesn't have at least one such file share lurking about ought to be immortalized on The History Channel.

        從事多年的內容管理問題諮詢以後，我傾向於證實大部分公司的文件共享產生於約翰康納會感受駕輕就熟——充滿了不可知的危險和忽然根除隱患的反烏托邦的荒地。任何連一個這種文件共享都沒有潛在的公司應當是歷史頻道上的不朽。

        What tends to happen is this: the file shares get chopped up at the subdirectory level (depending on who owns what, content-wise) and shoved into SharePoint by means of the Windows Explorer View interface (which is fake, but convincing), preserving the trickle-down hierarchical file structure of whatever chunk of the tree the content owner is moving. This doesn't simply transplant the data - it also transplants the problem.

        會發生的是：文件共享在子目錄級別（取決於誰擁有什麼）被分割而後藉助資源管理器視圖（假的，但可亂真）隨意堆放到SharePoint上，保留文件擁有者轉移上去的向下分級的文件結構。這不只僅遷移了文件，也遷移了問題。

        What should you do, instead? Eliminate folders altogether. I know, it's like giving up reruns of Andy Griffith (or Cosby, or Friends, depending on how old you are), but file folder hierarchies are the single biggest cognitive shortcoming we possess, as a result of our years in IT. SharePoint exists, in part, to liberate us

        那麼應該怎麼作呢？徹底消除文件夾。我知道，這像是放棄重播的安迪格里菲斯（電影名）（或者是科斯比、老友記等，取決於你的年齡），可是根據咱們多年來的IT經驗，文件夾層級結構是咱們具備的最大的認知不足。SharePoint的存在在必定程度上解放了咱們。

        Move all that file-share content over into SharePoint libraries, yes - but make the libraries themselves the top-level folders. Once you parsed at that high level, don't parse the child folders as folders! Instead, drop everything into the appropriate SharePoint library, and then establish columns (metadata) that define the organizing sub-levels that the resulting files require, and create views for each library that display files according to those columns

        是的，把全部的共享文件內容轉移到SharePoint的庫，把庫本身做爲頂級文件夾。轉移頂級文件夾以後，不要把子文件夾做爲文件夾轉移！取而代之的是，把全部東西扔到合適的SharePoint庫，而後創建字段（元數據）來定義文件須要的子級組織，根據這些字段爲每一個庫建立視圖來顯示文件。

        What is the end result? Each library you create is a superfolder of sorts, able to be all folders to all users, depending on their view. A single folder can represent dozens or even hundreds of subfolders - and instead of hosting content defines in single dimensions (a necessary restriction of the traditional folder hierarchy), you're now hosting all those files in as many dimensions as you need - and asking fewer mouse-clicks of your users to get to it, in the process

        最終的結果是什麼？每一個你建立的庫是一個歸類的超級文件夾，可以面向全部用戶做爲全部文件夾，取決於他們的視圖。一個單個文件夾能夠表述幾十個甚至是數百個子文件夾。而且，取代了單一維度的託管內容定義（傳統的文件夾層級結構必要的限制），如今你能夠根據須要從多維度來託管全部的文件，同時在流程上你的用戶獲取到文件須要更少的鼠標點擊。

Stamp out email abuse! 杜絕濫用電子郵件

        I've ranted about this before, and I surely will again: There are lots of us out there who should be jailed, or at least made to do community service, for our crimes against Outlook

        之前我由於這個咆哮過，固然我之後也會。咱們中的不少人由於自身對Outlook的犯罪須要被監禁，或者至少去作社會服務。

        Crime #1: Long chains of email become de facto meetings. Those of us who use Facebook - almost everybody - are familiar with the occasional lengthy thread that results when somebody posts some really interesting or important status, and many additional posts are made to the original status, resulting in a substantial (and often controversial) thread. Now - tell me this doesn't happen in your workplace, in email. You may not be an instigator (God bless you if not!), but you've almost certainly been hostage to this scenario, probably more than a few times

         犯罪#1：長鏈的郵件實際上變成了會議。咱們使用臉書的人（幾乎全部人）熟悉偶爾冗長的帖子是由於某人發佈了一些確實有趣或重要的狀態，而一些附加的評論添加到了原始狀態，來充實帖子的內容（一般是爭論性的）。如今，告訴我在你的工做場所，郵件中是不會發生的。你可能不是一個煽動者（上帝保佑你不是），可是你卻幾乎成爲了這種情境的犧牲品，極可能不少次。

        Crime #2 (even more despicable than Crime #1): These long email chains are actually saved as project documentation. And from a content standpoint, it's actually legitimate!

        犯罪#2（甚至比犯罪#1更卑劣）：這些長鏈郵件實際上保存爲項目文檔。從內容的角度來看，它其實是合法的！

The solution to both of these problems? 這些問題的解決方案？

        Set up a List in a SharePoint Team Site. Make all of your project participants Users of the team site. This List will contain all of the tasks (or action items, or objectives, whatever is appropriate) for a particulat project

        1. 在SharePoint工做組網站中建立一個列表。把你項目裏的全部成員加入到工做組網站的用戶。這個列表包含了跟特定項目有關的全部任務（或者是行動項、目標、其餘適合的東西）。

        Assign each Task/Action Item/Objective an "owner," from among the team site Users

        .2. 將每一個任務/行動項/目標（如下稱這些東西）指派一個在網站用戶中的全部者。

        Set up email alerts on this List, so that any participant is notified when one of the Tasks/Action Items/Objectives is modified (notified via Outlook - which limits email to its appropriate role in the process!). These alerts will contain links that will take the participant directly to the Task/Action Item/Objective, opening it for them in SharePoint

         3. 建立這個列表的提醒郵件，使任何一個參與者在這些東西更新時獲得提醒（流程中經過Outlook限制發送的郵件只能到它應該送達的角色）。這些提醒包含了這些東西在SharePoint中打開的連接。

       Have all of your participants pass along their input or contributions or reviews as comments in the List items. For all practical purposes, this input will be exactly the same as email - date/time-stamped, credited to the author, placed sequentially among all such entries - except that it will all exist in one place, a secure and properly administrated place (as opposed to email!).  And you have all of the benefits of those email threads, with none of the shortcomings.

        4. 讓全部的成員在列表項中經過評論/註釋來傳達輸入或貢獻或評論。實際上，這種輸入跟郵件是徹底同樣的——日期時間戳，歸功於做者，按順序放置全部這些條目——除了它們都會存在於一個地方，一個安全的可以妥善管理的地方（與電子郵件截然相反）。而且你擁有了全部那些電子郵件的好處，沒有缺點。       

        With just these two steps, an out-of-the-box SharePoint deployment can go from a turkey to a tiger. But even this is just the surface of what out-of-the-box SharePoint can do. Another step or two down the trail is process automation, collaborative power you've never harnessed before, salvation for project managers and a potential application hosting platform that can consolidate your security and administration efforts into a single global model. And each of these we will visit soon.

        僅僅經過這兩步，一個獨立的SharePoint部署就能從火雞變成老虎。可是這僅僅只是獨立的SharePoint能作的事情的表皮罷了。接下來另一或兩個步驟是流程自動化，協做的力量這些你歷來沒有利用過的，來拯救項目經理和一個潛在的應用程序託管平臺，這個平臺可以鞏固安全和管理能力到一個單一的全局模型。每個咱們都會很快地去了解的。