您的公司如何看待 SharePoint？ [关闭]

Question

更新 重新审视这个问题的有趣时刻。现在 SharePoint 2010 开始流行，人们的看法是否仍然相同？当然，实施 2010 年并非没有挑战，但商业认知是其中之一吗？

更新：我们的实施正在加速，一些备受瞩目的项目将在未来几周内投入使用，所以我很想看看那里的环境是否发生了变化。

原始问题

我们的工作环境中存在一个问题，即对 SharePoint 的看法是：

a) 金子弹，解决我们所有问题的答案。

b) 可以解决或不解决特定问题的应用程序。

c) 一个令人沮丧的工具，无法满足他们的严格要求。

现在，在我看来，SharePoint（或更具体地说，在我们的例子中是 Microsoft Office SharePoint Server 2007）是一个基于各种较低级别 Microsoft 技术（IIS、ASP.Net、WSS 3.0、.Net Framework、Windows Workflow Foundation 等）之上的框架其他人），因此可以开发为做大多数事情（给定时间和资源）。

在我的组织（以及我确信的其他人）中形成的态度是 Microsoft 营销机器和组织希望在尽可能多的人面前获得“金子弹”而不说“做什么的？'或“为什么？”或者在某些情况下甚至是“如何？”

这是其他 SharePoint 开发人员所共有的态度和看法吗？

Answer 1

我知道这个问题是针对开发人员的（而且有点老了），但我想从业务用户的角度分享一个观点。我们公司（全球 75,000 多名员工）部署了 MOSS 2007 的“Team Site”模板，停用了我们现有的文档 e-Rooms，并通过零培训、零信息让我们松了一口气。

整个公司的用户都将他们的团队网站用作文档存储库。有少数用户对 MOSS 2007 的协作功能有了更多了解，并开始设置和使用 MOSS 2007 的协作功能。

我还应该提一下 - 我们公司仍在使用 IE6 和 MS Office 2003。（遗憾的是，仅凭这一事实，我们无法使用 SharePoint 做所有事情。）

我们公司不会奖励想方设法利用所提供的工具来创建更好的协作的最终用户，我们的 IS/IT 部门拒绝协助提供学习材料、机会或以任何方式协助最终用户。在目前的狗咬狗心态下——下岗后下岗，现在有 1 个人在做过去 5 个人或更多人所做的工作，如果这不是核心关注的一部分，人们就是没有时间他们的工作。

我已经为几个小组学习并实现了一些协作功能——尽管我是在自己的时间学习的——这让我感到害怕，这是否意味着我会被认为没有足够的工作来完成让我忙，因此 - 消耗品？

就我对 SharePoint 的感觉而言：我喜欢 sharepoint。它确实为最终用户提供了相当多的功能……这可能需要我花点时间来做啊哈，但最终，我明白了。有时我在构建页面时会感到有些沮丧——我希望它是 CSS 和 HMTL——但是，当然，我们无法使用共享点设计器。

如果部署会更好 1. 培训包含在推广中。 2. 在推出期间实施了可靠的变更管理。

Answer 2

tl;dr：Sharepoint 不会给人以专注于帮助我完成工作的印象。

不太好。

在我们的工作中，我们发现 Fogbugz 提供了我们真正想要（并且确实）使用的功能，而且明显更直观、更快捷，因此也更有用。当然，您可以为其中许多事情创建 Sharepoint 工作流，但我们为什么要这样做呢？我们直接从一个似乎更专注于帮助我们完成工作的系统获得合理的工作流程和功能。

• 开发工作流程：我们非常喜欢以案例为中心的结构。
• 非正式讨论：Fogbugz 讨论与旧时的 Usenet 小组平行，非常适合在我们将问题转化为需要处理的案例之前进行讨论。
• 持续的讨论/文档：wiki 是我们构建所需材料的好地方，尤其是文档。
• SVN 集成：这对我们来说变得越来越重要。
• 项目报告/基于证据的调度：这对我们的计划和报告流程来说正迅速变得至关重要。

最后一个该死的事实：我们已经在这里使用 Sharepoint 很长一段时间了，但开发人员并没有真正感兴趣。我们推出了 Fogbugz，开发团队几乎立即接受了它，并将其作为日常工作的一部分。

注意：这读起来像 Fogbugz 广告，但还有其他工具似乎希望对 Sharepoint 提供更多帮助。

Answer 3

关于“如果那里的环境发生变化”的更新......根据我的经验，情况变得更糟了。这主要是因为用户界面。

作为开发人员，我经常听到“它看起来像 SharePoint”的评论，表明该产品越来越过时了。 （自从发布以来，我一直对它的外观感到失望。）这意味着大量的 CSS 和图形工作很痛苦，因为使用的表格太多了，而且 HTML 完全是废话。

除了外观，很多人发现界面不直观且令人沮丧。特别是对于知识较少的用户来说，仅仅上传一个文档就需要多次点击和不同的页面。

另外，由于 UI 不足，我被要求做很多 Web-2.0/AJAX/jQuery 的东西来美化界面并向用户提供更好的反馈。该产品不是为此而设计的。当 jQuery 需要在 2007 版本中非常令人失望的 Web 服务时，这是非常耗时的。 （好在终于有人开jQuery Library for SharePoint Web Services了。）

当产品的下一个版本即将推出时，通常会发生这种情况，我非常希望 SharePoint 2010 是坚如磐石的，因此当我们达到 2010 年的 RTM 时，几乎没有理由在 2007 平台上启动新项目。

Answer 4

根据我对一系列组织和第三方评论的观察，可以归结为一个词：期望。有些人期望 SharePoint 是解决所有问题的灵丹妙药。这种思想流派认为它是世界上最好的。丰富的开箱即用产品，提供广泛的协作工具集，您还可以对其进行编码以扩展上述功能。由于 SharePoint 是一种 .NET 产品，因此您可以吸引普通的 Microsoft 开发人员并立即开始获得所有 RAD 优点。

从这一期望开始，将标准设置在 a) Microsoft 从未真正打算过的水平，b) 如果没有知识渊博的 SharePoint 开发人员和合适的环境，就不太可能实现。很快就会意识到它比这更复杂一些。是的，您可以针对 SharePoint 进行编码，但不能期望它类似于构建 .NET 应用程序。从开发环境要求到发布过程再到持续维护，一切都比简单地构建 ASP.NET 应用程序更复杂。这也需要考虑到这样一个事实，即在许多组织中，SharePoint 是一个集中的共享环境，它通常会带来一定程度的治理，不允许您随意部署解决方案。

回到预期；当您继续假设这是一个用于协作活动、门户或文档管理的好工具时，它是一个了不起的产品。甚至继续在​​平台上进行开发，期望它需要一些专业技能，并且部署和管理过程将不同于传统的 .NET 堆栈，但这样做时要睁大眼睛了解其含义。

因此，总而言之，它是一款出色的产品，只要设定得当，就可以在组织内获得非常积极的评价。但是，如果您在没有完全了解其含义的情况下陷入炒作，那么您很可能会设定一个无法实现的期望。

Answer 5

在我以前的公司（南非的一家快速消费品集团），我们对 SharePoint 的体验在很多方面都是积极的（主要是 WSS，尽管我们也实施了 MOSS）。

我们抑制过多的自定义，并决定尽可能多地使用盒装功能，仅在真正需要时进行自定义。

几组业务用户很好地采用了它，用于围绕项目或部门问题进行协作和知识管理，在某些情况下，还有专门针对特定客户合作伙伴关系的外联网站点。到目前为止，最有效的网站是那些各个业务部门的 CIO 直接参与的网站 - 他们似乎处于很好的位置，既可以了解技术，又可以帮助业务人员看到光明。我认为一个重要的因素是，在我们实际推出任何产品之前，其中一位 CIO 多年来一直在推动将基于视角的全方位门户的总体愿景作为信息战略的一部分。我坚信从几个高价值点而不是沉重的自上而下驱动器有机地传播 SharePoint。但随着 SharePoint 的实施，传播得到了我们的变更管理功能的良好支持，该功能位于 I.T.但在业务中根深蒂固。

对于其中一个企业，我们建立了一个通用的外联网协作网站，并在 SharePoint 中培训了一个人。 业务用户能够在几分钟内创建子站点以与他们的任何业务合作伙伴协作（除了帐户创建，IT 仍然这样做），这是一个巨大的胜利。这些类型的需求以前由网站设计人员和开发人员花费数月的时间来解决。

对于我的团队（开发团队），我们将 WSS 广泛用于协作、KM 等，但它也对我们的解决方案交付产生了重大影响。一方面，我们曾多次忙于开发部门迫切需要的小型利基应用程序，但坦率地说，这些应用程序的成本超出了他们应有的水平，而且花费的时间也太长了。通过非常熟悉 WSS 产品，我们越来越发现我们可以帮助他们在很短的时间内仅使用 WSS 建立一个适当的解决方案。虽然有些很简单，可以让他们使用它们自己运行（一些进步的秘书类型正在采用 SharePoint 网站，就像他们曾经采用 Outlook 一样）其他需要我们持续的帮助 - 但可维护性比自定义编写的 C#/ASP 轻得多.NET 应用程序。底线 - 我们可以更快地交付价值，并且只在真正产生影响的地方使用代码，从而降低 TCO。

我认为 SharePoint 正在帮助我们进入一类解决方案，我们可以在其中撰写而不是编写代码。例如，在一个案例中，一家公司希望通过人工发送 Excel 电子表格来下订单。我们内心的纯粹主义者抗拒并想要寻求更无懈可击的东西——但我们无法发号施令，需要在这些限制范围内灵活地交付。所以我们创建了一个 WSS 站点（通过简单地从我们之前设置的根外联网协作站点创建一个子站点）并让人们将他们的电子表格附加到一个列表中。我们设置 BizTalk 来提取这些、提取数据、将订单推送到 ERP 系统，然后返回并标记 WSS 列表项的状态。所以我们仍然编写代码，但使用 WSS 开箱即用的功能来提供整个用户端体验。

我仍然对 SharePoint 作为一个通用的Web 应用程序开发平台 寄予厚望（即，这里有很多管道，现在可以根据需要加以利用和扩展）。我们还没有深入到那里，因为在一个可能难以/混乱维护的地方存在学习障碍以及大量代码的滑坡。我确实计划继续探索这是否属实，但同时我认为在解决方案组合思维模式中开箱即用的价值很多。

Answer 6

我想说sharepoint还不错！它管理信息的方式很棒！然而，困扰我的一件事是它对最终用户来说有点太复杂了，我们的组织花了两个月的时间来教育他们，但结果远远超出了我们的预期。有时看起来我们在上世纪50年代得到了一架超音速飞机——我们不能充分利用它！

Answer 7

只要您或公司中的某个人精通技术，您的公司就会从免费版的 Sharepoint 中受益。确保您购买了 Sharepoint Designer 2007。

我的公司并不真正了解 sharepoint 是什么以及做什么。它实际上是我们简单的生产调度和零件跟踪系统的“后端”。用户可以看到在 sharepoint 设计器中创建的基本 aspx 页面。

Sharepoint 允许我快速创建用于管理信息的列表。我将 sharepoint 视为 Excel 对 Web 环境的扩展。大多数人使用 Excel 创建信息列表。 Sharepoint 为该列表信息启用 Web 功能。

我使用免费版的 Sharepoint，并使用 Sharepoint Designer 对其进行了广泛的定制。我是一名具有一定编程技能的工程师。我知道我已经能够创建简单但有用的数据收集网页。

我首先使用 WSS 2.0 创建软件错误跟踪器。当时（2003 年）我刚刚发现了 Fogbugz，我们实际上使用了 Fogbugz 的试用版。每个人都喜欢 Fogbugz，主要是因为您可以分配问题并且自动发送电子邮件。标准的 Sharepoint 问题跟踪列表也可以实现这一点。 Fogbugz 显然有更多功能，但管理层决定我们将使用 sharepoint .....

最终，sharepoint 被广泛用于管理项目信息和与客户沟通。这是在很少定制的情况下完成的。刚刚创建了一些网站模板，每次创建新项目时都会创建一个带有适当文档库、问题跟踪列表、日历等的新网站。

我是分享点粉丝！！！ 哦，是的，它有很多限制，它的顶级项目违反了数据库最佳实践，但 Sharepoint 可以工作！

Answer 8

我遇到了很多正在进行“银/金/灵丹妙药”销售的人和组织。

我看到人们希望统一存储在他们的企业中的信息，通常是大型共享驱动器和分散在各处的文档，以及基于 Web 的不同应用程序。

组织希望其员工可以轻松使用所有内容（可查找性），并且他们希望它看起来好像是一个大型应用程序的一部分，以便整个组织的用户有一个一致的地方，他们可以去寻找他们需要的一切做。

造成的困惑是人们认为必须在“在”SharePoint 中完成，而不是使用 SharePoint 将所有部分放在一起并在组织内为其提供上下文（例如，大型“找花”应用程序位于网站的园艺部分）。

问题在于，一个好的信息架构需要大量的工作和计划​​去哪里。很多时候，SharePoint 就像一个新的共享驱动器一样被使用，并且只是将内容转储到任何地方。

对于开发人员来说，这对他们的日常工作并不重要，但对项目经理或经理来说却很重要。 开发可以产生很多文档，而一个良好的开发网站可以很容易地找到“为那个我们从未有时间做的项目设计文档，但我们昨天需要”。

SharePoint 并不是真正用于开发人员的核心工作（即它不是开发环境或源代码控制）。

Answer 9

所以我注意到，迄今为止，没有人真正对 SharePoint 有过真正积极的体验，但每个人都在购买它。这让我很困惑 MS 是如何做到这一点的？

我们的管道中有许多简单的项目将从注入 SP 中受益匪浅。但我想，在大多数情况下，我们将寻求将 SharePoint“融合”到我们的产品和技术组合中。它做得很好，它确实做得很好，但对于特定场景，它几乎总是需要一些自定义元素（例如 CSS、JScript 或服务器端代码），而且它可能并不总是合适的解决方案。

我最近听到一位 MS 分析师将 SharePoint 称为粘土模型，我对此进行了总结！

Answer 10

我目前的公司认为我们应该通过向 Intranet 用户提供 SharePoint 来授权他们。这样，他们可以随意管理/添加/删除用户、网站、页面。而且 IT 可以更高效地利用时间，就像在谷歌上搜索大笑猫一样。

我们确实很好地广泛使用了 SharePoint..到处都有大量的 SharePoint 列表..

没有发生的是实际上在内部销售产品的自助服务理念......而且 99% 的部门应该“自己做......或者只是使用它......”甚至从未接触过它！ ！

-- 这里大多数人知道的唯一软件是 Excel

这里的人们发送屏幕截图图像以进行故障排除，并使用仅在 Excel 文件中粘贴的图像制作手册！

（我以前在一台旧的 Solaris 机器上工作，没有 Open Office，所以即使我现在使用 XP.. 看到这种情况仍然很痛苦）

对他们来说，互联网就是 Yahoo 主页和电子邮件。

他们（邪恶）希望这些人通过使用 SharePoint 来解决他们的业务需求。

现实检查：自助服务与否，这不会发生..他们不使用 SharePoint 自行解决任何问题，但无论如何都没有人注意到...

..这是一个谎言，人们注意到了它，但提到管理认为 SharePoint 的使用方式与现实之间的差异，是成为公司红发继子的可靠方法。

“普通用户”的这种授权是一个幽灵功能，我们在 IT 中总是最终完成工作..任何工作..应该通过使用超级工具 SharePoint 来解决..我们最终创建了网站、列表、工作流，通常只有我们使用它们。

这些都不是幽默的..

（在 IT 部门之外使用 SharePoint 的唯一工作流程是每月公司午餐公告，它来自 GA 或 HR 在将新列表项添加到 IT 制作的共享点列表后通过自动电子邮件发送）

SharePoint 被视为通过将 IT 从上述较小的任务中解放出来来提高 IT 生产力的金子弹，但那些 较小的任务仍然存在，而且我们还有额外的成本 em>试图让其他部门自己做

我认为，经过多年的内部对产品的抨击，人们现在对 SharePoint 是什么以及它使用了相当多的了解很少。问题是人们使用它的方式正如 Microsoft 所承诺的那样，但不是高层管理人员：

基于 SharePoint 列表的文档存储和工作流——太棒了！

但是当权者应该明白，这永远不会是一个可以摆脱 IT 护理和培育的东西。

它提出了一个我讨厌“让他们自己做的思考过程”的观点，让非 IT 用户自己开发东西在所有方面都会适得其反

（输入 InfoPath 表单....）

我们在 IT 部门花费一生的时间来学习如何制作软件以及如何维护它（但仍然做错了），现在有人只想做营销 [或其他] 管理他们自己的数据和内部工作流程 UI +逻辑！！

这是一个不必要的学习曲线（对每个人来说），它会驱使我们所有人去其他地方寻找工作，并让 IT 部门完成调试疯狂、无法管理的半熟业务对象的不可能任务。

输入大量流行语：MOSS 做 CMS...

结果：我们现在正在从作为 CMS（被用作美化的自动化 FTP 客户端服务器工具）的 Interwoven 迁移到 MOSS。

我在 SharePoint 和现在的 MOSS 方面有一年多的经验，但高层管理人员的整个想法是：

“让营销部门自己做，因为 MOSS 是 SharePoint++.. 自我管理”

我认为 MOSS 是一个非常酷的工具，但这是我在最近一次会议上的评论：

“嗯，我认为市场营销部门应该快速了解一下 SharePoint Designer，这样他们就知道会发生什么”

收到的回答：“这太技术性了..” click click 的开箱即用功能来执行完整的品牌推广。.

他们最初计划将品牌推广的开发外包，并从那时起将其发展..尝试向他们解释完全没有意义..

我？..每当我们开会讨论这个项目时，我都会想到找工作，感谢上帝，我不是这个项目的项目经理。

底线：我不责怪 SharePoint 工具，但我可以看到人们在各地办公室中可能以错误的心态使用它。至少在我的公司中它被严重滥用和误解，并且将继续受到支持由于未来几年的权力错误的原因。

Answer 11

在我工作的组织中，这完全取决于一个人的技术理解水平。业务人员将其视为利用预先构建的平台并相对轻松地进行一些小改动的机会。然而，它的现实是，对于技术人员来说，这是一场噩梦。权衡往往是从一个极端到另一个极端，这意味着如果我们使用内置功能做某事，它相对容易，但最终用户体验远不能令人满意。另一方面，我们通常可以提供更好的用户体验，但代价是大量的密集劳动。

就个人而言，作为技术方面的个人，我不建议将 SharePoint 用于任何环境，因为当您考虑许可成本时，除了开发时间以使任何事情都变得有价值（根据我的经验，总是比自定义 ASP.NET 应用程序花费更多时间）你最终会遭受可笑的净损失。大多数 Intranet 站点都能够相对轻松地使用免费版本 (WSS)；但是，他们通常不会进行大量定制，只是将其用作文档存储库。

无论出于何种原因，业务人员对产品的看法完全不同。他们相信 SharePoint 最终会为他们节省资金。我说这是一种扭曲的观点，因为我见过的每个使用 SharePoint 的项目都远远超出了我对自定义 ASP.NET 应用程序（长期和短期）的估计。在一个特定的案例中，我参与了一个项目，该项目在自定义 ASP.NET 应用程序中最多需要一个月的时间（包括开发时间、QA 等）。然而，SharePoint 中的相同应用程序已经开发了将近一年。底线是该项目根本不属于 SharePoint，但业务人员拒绝接受，直到他们别无选择。

如果您正在为您的组织考虑 SharePoint，我强烈建议您先做好功课。期待一个非常大的学习曲线和很多挫折。您的大多数技术人员会立即认识到产品的缺陷并以极度沮丧的方式指出它们。这在 SharePoint 开发环境中很正常。如果最终您愿意做出这些牺牲而几乎没有收获，那么 SharePoint 就是适合您的解决方案。

Answer 12

我们这里有 SP（非 MOSS 只是香草）。

大多数人不知道如何处理它。它不习惯它的潜力，但没有人（包括我自己）愿意投入这种时间。

这里使用的方式可以很容易地替换为远程共享和预定义的文件夹/目录结构。

Answer 13

从来不知道该怎么处理它。只是让我们茫然和困惑，我们最终转向其他事情。