zoukankan      html  css  js  c++  java
  • 你以为在用SharePoint但事实上不是

    博客地址 http://blog.csdn.net/foxdave

    原文链接:http://www.techrepublic.com/blog/tech-decision-maker/you-think-you-use-sharepoint-but-you-really-dont/

    是篇老文章了,近期研究问题的时候偶然碰到了这篇文章。尽管里面说的情境不一定发生在中国。可是非常赞同里面的思路。我们大多数做项目的时候,是否真正使用SharePoint达到了效果?

     

    无数公司部署了SharePoint可是没有利用到SharePoint的非常多优点。

    这里有关于一个能够成功的SharePoint路标的一些建议。

    你能够随处可见。好的SharePoint变坏了。今天世界上部署SharePoint的数量有6位数了。他们中的五分之四非常糟糕。当然这不过一个主观猜測。非常多部署SharePoint的人(特别是免费版本号的)并没有非常高的雄心。

    然而讽刺的是,他们能达到更高的目标而且从他们免费的部署中得到非常多。

    由于“suck”是一个非技术词汇,我们来给它一个集中定义:有很多公司怀着良好的初衷实施了SharePoint,可是既没改善他们的流程也没改善他们的文化。

    可是真正糟糕的实施实际上是把之前遗留的大麻烦在SharePoint上简单地再现了。

    典型的模式是这样的:1)公司的文件共享失控了,亟需内容管理;2)SharePoint部署到了整个公司。3)文件从文件共享中转移到了SharePoint上。4)这些文件迅速失控。

    落井下石的说。SharePoint解决内容管理问题的失败把公司从利用SharePoint的其它游戏转移到了改变功能上。坚持着用SharePoint(实际上没有一个头脑清醒的人会回滚这些可怕的文件共享)却没有不论什么创新改善。

    让我们从两个最大的问题,同一时候也是两个最easy(也是最廉价的)解决的。

     

    共享

    从事多年的内容管理问题咨询之后,我倾向于证明大部分公司的文件共享产生于约翰康纳会感认为心应手——充满了不可知的危急和突然根除隐患的反乌托邦的荒地。不论什么连一个这样的文件共享都没有潜在的公司应当是历史频道上的不朽。

    会发生的是:文件共享在子目录级别(取决于谁拥有什么)被切割然后借助资源管理器视图(假的。但可乱真)任意堆放到SharePoint上,保留文件拥有者转移上去的向下分级的文件结构。

    这不只迁移了文件,也迁移了问题。

    那么应该怎么做呢?全然消除目录。我知道。这像是放弃重播的安迪格里菲斯(电影名)(或者是科斯比、老友记等,取决于你的年龄)。可是依据我们多年来的IT经验,目录层级结构是我们具有的最大的认知不足。SharePoint的存在在一定程度上解放了我们。

    是的,把全部的共享文件内容转移到SharePoint的库。把库自己作为顶级目录。转移顶级目录之后,不要把子目录作为目录转移!

    取而代之的是,把全部东西扔到合适的SharePoint库,然后建立字段(元数据)来定义文件须要的子级组织,依据这些字段为每一个库创建视图来显示文件。

    终于的结果是什么?每一个你创建的库是一个归类的超级目录。能够面向全部用户作为全部目录。取决于他们的视图。一个单个目录能够表述几十个甚至是数百个子目录。

    而且。代替了单一维度的托管内容定义(传统的目录层级结构必要的限制),如今你能够依据须要从多维度来托管全部的文件。同一时候在流程上你的用户获取到文件须要更少的鼠标点击。

     

    杜绝滥用电子邮件

    曾经我由于这个咆哮过。当然我以后也会。我们中的非常多人由于自身对Outlook的犯罪须要被监禁。或者至少去做社会服务。

    犯罪#1:长链的邮件实际上变成了会议。我们使用脸书的人(差点儿全部人)熟悉偶尔冗长的帖子是由于某人公布了一些确实有趣或重要的状态,而一些附加的评论加入到了原始状态,来充实帖子的内容(一般是争论性的)。

    如今,告诉我在你的工作场所。邮件中是不会发生的。

    你可能不是一个煽动者(上帝 保佑你不是)。可是你却差点儿成为了这样的情境的牺牲品。非常可能非常多次。

    犯罪#2(甚至比犯罪#1更卑劣):这些长链邮件实际上保存为项目文档。从内容的角度来看,它实际上是合法的!

    这些问题的解决方式?

    1. 在SharePoint工作组站点中创建一个列表。

    把你项目里的全部成员加入到工作组站点的用户。

    这个列表包括了跟特定项目有关的全部任务(或者是行动项、目标、其它适合的东西)。

    2. 将每一个任务/行动项/目标(下面称这些东西)指派一个在站点用户中的全部者。

    3. 创建这个列表的提醒邮件,使不论什么一个參与者在这些东西更新时得到提醒(流程中通过Outlook限制发送的邮件只能到它应该送达的角色)。

    这些提醒包括了这些东西在SharePoint中打开的链接。

    4. 让全部的成员在列表项中通过评论/凝视来传达输入或贡献或评论。实际上,这样的输入跟邮件是全然一样的——日期时间戳,归功于作者。按顺序放置全部这些条目——除了它们都会存在于一个地方。一个安全的能够妥善管理的地方(与电子邮件截然相反)。而且你拥有了全部那些电子邮件的优点。没有缺点。

    只通过这两步。一个独立的SharePoint部署就能从火鸡变成老虎。可是这只不过独立的SharePoint能做的事情的表皮罢了。接下来另外一或两个步骤是流程自己主动化,协作的力量这些你从来没有利用过的,来解救项目经理和一个潜在的应用程序托管平台,这个平台能够巩固安全和管理能力到一个单一的全局模型。每一个我们都会非常快地去了解的。

  • 相关阅读:
    Hard Rock
    Codeforces Round #416 (Div. 2) B. Vladik and Complicated Book
    codeforces 793B. Igor and his way to work
    codeforces 1B Spreadsheets
    HDU 1069 Monkey and Banana
    codeforces 2B The least round way
    【机器学习】 通俗说拟合
    python-八皇后问题
    python-核心知识思维导图
    python-@property 属性
  • 原文地址:https://www.cnblogs.com/bhlsheji/p/5196639.html
Copyright © 2011-2022 走看看