24

更新重新审视这个问题的有趣时间。现在 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 等）之上的框架，并且因此，可以开发做大多数事情（给定时间和资源）。

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

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

4

13 回答 13

26

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

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

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

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

于 2009-01-29T21:53:50.727 回答
11

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

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

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

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

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

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

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

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

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

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

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

这些都不是幽默的意思。。

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

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

我认为，经过多年的内部对产品的抨击，现在人们对 SharePoint 是什么以及它的使用情况有了一些最基本的了解。问题是人们使用它的方式是微软所承诺的，但不是上层的管理：

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

但是当权者应该明白，这永远不会是有自己的腿的东西，可以免于 IT 护理和培育。

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

（输入 InfoPath 表单......）

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

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

输入流行词嘉豪：MOSS 做 CMS...

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

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

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

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

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

收到的答案：“这太技术性了..” <<<< 他们真的希望通过点击网站选项的开箱即用功能来执行完整的品牌推广..

他们最初计划将品牌开发外包并从那时起将其发展..否则，尝试向他们解释绝对没有意义..

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

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

于 2009-01-30T01:37:17.203 回答
8

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

于 2009-01-29T21:10:36.617 回答
7

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

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

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

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

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

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

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

于 2009-02-10T08:44:10.680 回答
6

我遇到了很多正在进行“银/金/魔弹”销售的人和组织。

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

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

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

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

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

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

于 2009-01-29T21:55:53.173 回答
5

tl;dr：Sharepoint 并没有给人一种专注于帮助我完成工作的印象。

不是很好。

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

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

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

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

于 2009-01-29T21:06:56.750 回答
5

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

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

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

于 2009-01-29T21:18:25.277 回答
5

只要您或公司中的某个人精通技术，您的公司就会从免费版的 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 可以工作！

于 2009-02-04T17:30:46.213 回答
5

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

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

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

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

于 2009-05-13T11:38:12.393 回答
3

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

于 2009-02-05T01:19:15.193 回答
3

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

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

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

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

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

于 2009-10-01T11:23:10.247 回答
2

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

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

我最近听到一位 MS 分析师将 SharePoint 称为建模粘土，这为我总结了！

于 2009-01-30T09:19:06.473 回答
1

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

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

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

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

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

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

如果 1. 部署中包含培训，那将是更好的部署。2. 上线期间实施了扎实的变更管理。

于 2011-06-10T19:30:49.190 回答