更新一个重新回顾这个问题的有趣时刻.当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开发者共享的态度和看法吗？
在我工作的组织中,它完全取决于一个人的技术理解水平.业务人员将其视为一个机会,可以采用预先构建的平台,并相对轻松地对一些微小的变化进行打击.然而,它的实际情况是,对于技术人员来说,与之合作是一场噩梦.权衡通常是从一个极端到另一个极端,这意味着如果我们使用内置功能做一些事情,它相对容易,但最终用户体验远非令人满意.另一方面,我们通常可以提供更好的用户体验,但代价是极端繁重的劳动力.
就个人而言,作为技术方面的个人,我不建议在任何环境中使用SharePoint,因为当您考虑许可成本时,除了开发时间以使任何有价值的东西(根据我的经验,总是需要更多的时间)而不是一个自定义的ASP.NET应用程序)你最终会有一个荒谬的净损失.大多数内部网站点都可以相对轻松地使用免费版本(WSS); 但是,它们通常不会进行大量自定义,只是将其用作文档存储库.
无论出于何种原因,业务人员对产品有完全歪曲的看法.他们认为SharePoint最终为他们节省了资金.我说这是一个扭曲的观点,因为我见过的每一个使用SharePoint的项目都远远超出了我对自定义ASP.NET应用程序(长期和短期)的估计.在一个特定的案例中,我参与了一个项目,该项目在自定义ASP.NET应用程序中最多需要一个月(包括开发时间,QA等).但是,SharePoint中的相同应用程序已经开发了近一年.底线是该项目根本不属于SharePoint,但业务人员拒绝接受这一点,直到他们别无选择.
如果您正在考虑为您的组织使用SharePoint,我强烈建议您先完成作业.期待一个非常大的学习曲线和很多挫折感.大多数技术人员会立即认识到产品的缺陷,并极其沮丧地指出它们.这在SharePoint开发环境中是正常的.最后,如果您愿意在很少或没有任何收获的情况下做出这些牺牲,那么SharePoint对您来说是正确的解决方案.
我当前的公司认为我们应该通过向他们提供SharePoint来授权Intranet用户..这样,他们就可以随意管理/添加/删除用户,网站,页面.并且IT可以像Googling一样更有效地利用它的时间为lol猫.
我们确实使用了SharePoint,并且广泛地使用了大量的SharePoint列表.
没有发生的是实际在内部销售产品的自助服务理念...... 99%的部门应该"自己动手......或者只是简单地使用它......"从来没有碰过它!
- 大多数人都知道的唯一软件是Excel
这里的人们发送截图图像进行故障排除,并使用Excel文件中的粘贴图像制作手册!
(我曾经使用旧的Solaris机器,没有Open Office,所以即使我现在使用XP ..看到这种情况仍然很痛)
他们的互联网是雅虎主页和电子邮件.
他们(邪恶)希望这些人通过SharePoint使用来解决他们的业务需求.
现实检查:自助服务与否,只是没有发生......他们不使用SharePoint自己解决任何问题,但无论如何没有人注意到......
这是谎言,人们注意到它,但提到管理层认为 SharePoint的使用与现实之间的差异,是成为公司中一个红头发儿童的必然方式.
赋予"普通用户"权限是一个鬼功能,我们IT总是最终完成工作......任何工作......应该通过拥有超级工具SharePoint来解决..我们最终创建了网站,列表,工作流程,通常我们是唯一使用它们的人.
这一切都不是为了幽默......
(在IT部门之外使用SharePoint的唯一工作流程是月度公司午餐公告,它是在自动电子邮件中将GA或HR添加到由IT制作的共享点列表后的自动电子邮件中)
通过从所述较小的任务中释放IT,可以将SharePoint视为提高IT效率的核心工具,但是那些较小的任务仍然存在,我们会增加成本, 试图让其他部门自己完成
我认为,经过多年的内部锤击产品的人们的喉咙,现在有一些对SharePoint是什么的最小理解,并且它使用了很多..问题是人们使用它的方式是微软承诺的,但不是上层管理:
基于SharePoint列表的文档存储和工作流程 - 非常棒!
但是,应该理解的是,这将永远不会有自己的腿,可以免于IT护理和培养.
它提出了一个我讨厌整体的观点"让他们自己做自己的思考过程",让非IT用户开发自己的东西在所有方面都适得其反
(输入InfoPath表单....)
我们在IT中花费了我们的生命,学习如何制作软件以及如何维护它(并且仍然做错了),现在有人只是想做营销[或其他]管理他们自己的数据和内部工作流程UI +逻辑! !
这是一个不必要的学习曲线(适合所有人),它将驱使我们所有人去其他地方寻找工作,并让IT部门完成调试疯狂无法管理的半熟业务对象的不可能完成的任务.
输入流行语:MOSS做CMS ...
结果:我们现在正从Interwoven作为CMS(被用作美化的自动化FTP客户端服务器工具)转移到MOSS.
我有超过一年的SharePoint和现在的MOSS经验,但是高层管理人员的整个想法是:
"让营销部门自己做,因为MOSS是SharePoint ++ ..自我管理"
我认为MOSS是一个非常酷的工具,但这是我在最近一次会议上的评论:
"好吧,我认为Marketing应该快速浏览一下SharePoint Designer,这样他们就知道会遇到什么"
收到回答:"那太技术了......"<<<<他们真的希望通过点击网站选项的开箱即用功能来执行完整的品牌推广.
他们计划最初将品牌发展外包,然后从那时开始实施......而且试图向他们解释其他方面绝对没有意义.
我？...每当我们在这个项目上开会时,我都会想到求职,感谢众神,我不是这个项目经理.
一句话:我不会责怪SharePoint这个工具,但是我可以看到人们可能在办公室的任何地方使用错误的框架......至少在我的公司中被滥用和误解,并且仍然会因为错误而受到支持未来几年权力的原因.
永远不知道如何处理它.让我们感到茫然和困惑,我们最终转向其他事情.
我在以前的公司(南非的快速消费品集团)的SharePoint经验在许多方面都是积极的(主要是WSS,尽管我们也实施了MOSS).
我们过于依赖定制,并决定尽可能多地使用盒装功能,仅在真正需要时进行定制.
几组业务用户在项目或部门问题的协作和知识管理方面非常好地采用了它,在某些情况下,还专门用于特定客户合作伙伴关系的外联网站点.到目前为止,最有效的网站是各个业务部门的CIO直接参与的网站 - 它们似乎很好地定位于理解技术并帮助商业人士看到光.我认为一个重要因素还在于,在我们实际拥有任何产品之前,其中一位CIO一直在推动一个全方位的基于视角的门户网站作为信息战略的一部分.我坚信从高价值的几个点而不是一个沉重的自上而下的驱动器中有机地传播SharePoint.但是,随着SharePoint的实施,我们的变更管理功能很好地支持了这种传播,该功能位于IT中,但在业务中根深蒂固.
对于其中一项业务,我们建立了一个通用外联网协作网站,并在SharePoint中培训了一个人.对于商业用户来说,能够在几分钟内创建与他们的任何业务合作伙伴(除了IT创建的帐户之外)进行协作的子网站,这是一个巨大的胜利.这些类型的需求以前曾被网站设计人员和开发人员花费了数月时间.
对于我的团队(开发团队),我们广泛使用WSS进行协作,知识管理等,但它也有意义地影响了我们的解决方案交付.首先,我们在开发那些部门绝望的小型利基应用程序时已被多次捆绑,但坦率地说,这些应用程序的成本超出了应有的程度且耗时太长.通过非常熟悉WSS产品,我们越来越多地发现我们可以在很短的时间内使用WSS帮助他们建立适当的解决方案.虽然有些很简单,然后他们可以运行这些(一些渐进式秘书类型采用SharePoint网站,就像他们曾经采用Outlook一样),其他人需要我们持续的帮助 - 但可维护性比定制编写的C#/ ASP轻得多.NET应用程序 底线 - 我们可以更快地提供价值,并且仅在真正有所作为的地方使用代码,降低TCO.
我想的SharePoint帮助我们进入一个一流的解决方案中,我们撰写,而不是代码一切.例如,在一个案例中,公司希望通过让人们在Excel电子表格中发送订单来下订单.我们中的纯粹主义者抵制并希望采取更加无懈可击的措施 - 但我们无法在这些限制和灵活性范围内提出要求并提出要求.因此,我们创建了一个WSS站点(通过简单地在我们之前设置的根外联网协作站点创建一个子站点)并让民众将他们的电子表格附加到列表中.我们设置BizTalk来挑选它们,提取数据,将订单推送到ERP系统并返回并标记具有状态的WSS列表项.所以我们仍然编写代码,但使用WSS开箱即用功能来实现整个用户端体验.
我仍然对SharePoint作为一般的Web应用程序开发平台抱有很高的期望(即,这里有很多管道,现在可以根据需要进行扩展和扩展).我们还没有深入到那里,因为有一个学习障碍,以及在一个可能难以维护的地方的大量代码的滑坡.我确实计划继续探索这是否属实,但与此同时我认为在解决方案组合思维中开箱即用的价值很高.
我遇到很多人和组织,那里有一些"银/金/魔弹"销售正在进行中.
我看到人们希望统一存储在他们的业务中的信息,通常是分散在各处的大型共享驱动器和文档,一些基于Web的不同应用程序.
组织希望一切都能轻松地提供给员工(可查找性),并且他们希望它看起来好像是一个庞大的应用程序的一部分,因此整个组织的用户可以拥有一致的地方,他们可以为他们需要做的一切.
引起的混淆是人们认为它必须在"SharePoint"中完成,而不是使用SharePoint将所有位置拉到一起并在组织内给出上下文(例如,大型"找到花"应用程序位于园艺部分的网站).
问题是,良好的信息架构需要大量的工作和规划必须去的地方.通常,SharePoint像新的共享驱动器一样被使用,而东西只是倾倒在任何地方.
对于开发人员来说,这对他们的日常工作并不重要,但对于下午或经理来说这很重要.开发可以产生大量文档,一个创建良好的开发站点可以很容易地找到"我们从未做过的那个项目的设计文档,但我们需要昨天".
SharePoint并不是真正适用于开发人员的核心工作(即它不是开发环境或源代码控制).
tl;博士:Sharepoint并没有给人以专注于帮助我完成工作的印象.
不是很好.
在我们的工作中,我们发现Fogbugz提供了我们真正想要(并且确实)使用的能力,这种能力明显更直观,更快速,因此更有用.当然,你可以为很多这些东西创建一个Sharepoint工作流程,但为什么呢？我们直接从一个似乎更专注于帮助我们开展工作的系统中获得合理的工作流程和功能.
开发工作流程:我们非常喜欢以案例为中心的结构.
非正式讨论:Fogbugz讨论与旧时Usenet小组并行,并且在我们将其转化为需要处理的案例之前,非常适合讨论问题.
持续的讨论/文件:维基是我们构建我们需要的材料的好地方,尤其是文档.
SVN集成:这对我们来说变得越来越重要.
项目报告/基于证据的安排:这对我们的规划和报告过程迅速变得至关重要.
最后这个事实:我们已经在这里使用了Sharepoint很长一段时间没有开发人员的真正兴趣.我们介绍了Fogbugz,开发团队几乎立即接受了它并将其作为日常工作的一部分.
注意:这看起来像一个Fogbugz广告,但有其他工具似乎想要帮助更多的Sharepoint.
我们这里有SP(非MOSS只是香草).
大多数人都不确定如何处理它.它没有发挥其潜力,但没有人(包括我自己)想投入那样的时间.
这里使用的方式可以很容易地用远程共享和预定义的文件夹/目录结构替换.
只要您或公司中的某个人精通技术,您的公司将从免费版本的Sharepoint中受益.确保购买Sharepoint Designer 2007.
我的公司并不真正意识到共享点是什么和做什么.它实际上是我们简单的生产计划和零件跟踪系统的"后端".用户可以看到在sharepoint设计器中创建的基本aspx页面.
Sharepoint允许我快速创建用于管理信息的列表.我将sharepoint视为Excel对Web环境的扩展.大多数人使用Excel来创建信息列表.Sharepoint为该列表信息启用Web功能.
我使用免费版的Sharepoint,并使用Sharepoint Designer进行了广泛的定制.我是一名具有一定编程技能的工程师.我知道我已经能够创建简单但有用的数据收集网页.
我首先使用WSS 2.0来创建软件错误跟踪器.当时(2003年)我刚刚发现了Fogbugz,我们实际上使用了Fogbugz的试用版.每个人都喜欢Fogbugz主要是因为你可以自动分配问题和电子邮件.标准的Sharepoint问题跟踪列表也实现了这一点.Fogbugz显然有更多的功能,但管理层决定我们将使用sharepoint .....
最后,sharepoint被广泛用于管理项目信息并与客户沟通.这是通过很少的定制完成的.刚刚创建了一些网站模板,每次创建新项目时,都会创建一个新网站,其中包含相应的文档库,问题跟踪列表,日历等.
我是FAN的共享点!哦,是的,它有很多限制,其顶级项目违反了数据库最佳实践,但Sharepoint工作!
从我在一系列组织和第三方评论中观察到的,它归结为一个词:期望.有些人期望SharePoint是解决所有问题的灵丹妙药.这个思想流派是世界上最好的; 丰富的开箱即用产品,提供广泛的协作工具,您也可以编写代码以扩展上述功能.由于SharePoint是.NET产品,因此您可以抓住普通的Microsoft开发人员并立即开始获得所有RAD优势.
从这个期望出发,将标准设置为a)微软从未真正想要的水平; b)如果没有知识渊博的SharePoint开发人员和合适的环境,就不可能实现这一目标.不需要太长时间才能意识到它比这复杂得多.是的,您可以针对SharePoint进行编码,但是您不能期望它类似于构建.NET应用程序.从开发环境需求到发布流程到持续维护,所有内容都比简单构建ASP.NET应用程序更复杂.这也需要考虑到这样一个事实,即在许多组织中,SharePoint是一个集中的共享环境,通常会带来一定程度的治理,这不会让您随意简单地部署解决方案.
回到期待; 当你继续假设这是一个很好的协作活动,门户或文档管理工具时,它是一个很棒的产品.甚至继续在平台上进行开发,期望它需要一些专业技能,并且部署和管理过程将与传统的.NET堆栈不同,但这样做的目的是睁大眼睛看其含义.
总而言之,只要期望得到恰当的设定,它就是一个伟大的产品,并且在组织内部可以被非常积极地看待.但是,如果你在没有完全理解其含义的情况下陷入炒作,你很可能会设定一个你无法实现的期望.
京公网安备 11010802040832号 | 京ICP备19059560号-6 