在过去的几个月，事实上有好几年里，企业机构对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时什么可以良好的运行。如果你有什么想要添加的，或者不同意其中的任何一项，请在评论中告知。