24

更新この質問を再検討する興味深い時期です。SharePoint 2010 が定着し始めた今でも、認識は同じですか? 確かに、2010 年の実装には独自の課題がないわけではありませんが、ビジネスの認識もその 1 つですか?

更新:私たちの実装は現在、いくつかの注目を集めるプロジェクトが今後数週間で開始されることで、ハイギアになっているため、環境が変化したかどうかを確認することに非常に興味があります.

元の質問

私たちの作業環境には、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 アプリケーションよりも) ばかげた純損失になります。ほとんどのイントラネット サイトは、比較的簡単に無料バージョン (WSS) を使用できます。ただし、彼らは通常、多くのカスタマイズを行っておらず、ドキュメント リポジトリとしてのみ使用しています。

なんらかの理由で、ビジネス スタッフは製品に対して完全に歪んだ意見を持っています。彼らは、SharePoint が最終的にお金を節約できると信じています。私がこれまでに見た SharePoint を使用したすべてのプロジェクトは、カスタム ASP.NET アプリケーションに対する私の見積もりを (長期的にも短期的にも)はるかに上回っているため、これは歪んだ意見です。ある特定のケースでは、カスタム ASP.NET アプリケーションの場合、文字通り最長で 1 か月 (開発時間、QA などを含む) かかるプロジェクトに関与しました。ただし、SharePoint の同じアプリケーションは、ほぼ 1 年間開発されています。肝心なのは、プロジェクトが SharePoint に属していなかったということですが、ビジネス スタッフは選択の余地がなくなるまでこれを受け入れることを拒否しました。

組織で SharePoint を検討している場合は、まず下調べを行うことを強くお勧めします。非常に大きな学習曲線と多くのフラストレーションが予想されます。技術スタッフのほとんどは、製品の欠陥をすぐに認識し、極度の不満を持って指摘します。これは、SharePoint 開発環境では正常です。最終的に、これらの犠牲を払っても得るものはほとんどまたはまったくない場合、SharePoint は適切なソリューションです。

于 2009-01-29T21:53:50.727 に答える
11

私の現在の会社は、イントラネット ユーザーに SharePoint を提供することで権限を与えるべきだと考えています。このようにして、ユーザー、サイト、ページを自由に管理/追加/削除できます。そして、IT 部門は、笑っている猫のグーグルのように時間をより生産的に使用できます。

私たちは、SharePoint を十分かつ広範囲に使用しています..あちこちにたくさんの SharePoint リストがあります..

起こらないのは、実際に製品を社内で販売するセルフサービスのアイデアです..そして、「自分でやっている..または単にそれを使用している..」べき部門の99%は、それに触れたことさえありません!!

--ここでほとんどの人が知っている唯一のソフトウェアは Excel です

ここの人たちは、トラブルシューティングのためにスクリーンショット画像を送ってくれたり、Excel ファイル内に画像を貼り付けるだけでマニュアルを作成したりしています。

(以前は Open Office を使わずに古い Solaris マシンで作業していたので、今は XP を使用していますが..これが起こるのを見るのはまだ痛いです)

彼らにとってのインターネットはYahooのホームページとメールです。

彼ら (悪) は、これらの人々が SharePoint を使用してビジネス ニーズを解決することを望んでいます。

現実のチェック: セルフサービスであろうとなかろうと、それは起こりません..彼らは SharePoint を使用して自分で問題を解決することはありませんが、とにかく誰も気づきません.

..うそです、人々はそれに気づきますが、経営陣がSharePoint をどのように使用していると考えているか、現実との相違について言及することは、会社で赤毛の義理の子供になる確実な方法です。

この「通常のユーザー」への権限付与はゴースト機能です。IT 部門では常に、スーパー ツールの SharePoint を使用することで解決されるはずだったすべての作業を行うことになります。サイトやリストを作成することになります。 、ワークフロー、そして通常、それらを使用するのは私たちだけです。

これはどれもユーモアを意図したものではありません..

(IT 部門以外で SharePoint を使用して使用される唯一のワークフローは、IT 部門が作成した SharePoint リストに新しいリスト アイテムを追加した後に、GA または HR から自動メールで送信される月例の社内ランチ アナウンスです)

SharePoint は、前述の小さなタスクから IT を解放することで IT の生産性を向上させるための黄金の弾丸と見なされていますが、これらの小さなタスクは残ります。加え て、他の部門に自分でやらせようとする追加コストがかかります。

何年にもわたって内部で製品を人々の喉に叩きつけてきた後、SharePoint とは何かについての最低限の理解があり、かなり使用されていると思います。管理:

SharePoint リスト ベースのドキュメント ストレージとワークフロー -- すばらしい!

しかし、これは決して IT 看護や育成から解放された独自の脚を持つものではないことを理解する必要があります。

それは、「彼らに自分でやらせる思考プロセス」全体について私が嫌いなポイントをもたらします.IT以外のユーザーに自分で開発させることは、あらゆる点で非生産的です.

(InfoPath フォームを入力してください....)

私たちは IT 部門で、ソフトウェアの作成方法とソフトウェアの保守方法を学ぶことに一生を費やしています (そして、それでも間違っています)。今では、マーケティング [または何でも] を行いたいだけの人が、自分のデータと内部作業プロセスの UI + ロジックを管理しています! !

これは (誰にとっても) 不必要な学習曲線であり、私たち全員が別の場所で仕事を探すようになり、IT 部門に非常識で扱いにくい中途半端なビジネス オブジェクトをデバッグするという不可能なタスクを任せることになります。

流行語をたくさん入力してください: MOSS は CMS を行います...

結果: 私たちは現在、CMS としての Interwoven から MOSS に移行しています。

私は SharePoint と現在の MOSS で 1 年以上の経験がありますが、上層部からの全体的なアイデアは次のとおりです。

「MOSS は SharePoint++ で、自分で管理できるので、マーケティング部門に任せてください」

MOSS は非常に優れたツールだと思いますが、最近の会議での私のコメントは次のとおりです。

「そうですね、マーケティング部門は SharePoint Designer をざっと見て、今後の予定を把握する必要があると思います」

受け取った回答:「それは技術的すぎる..

彼らは最初にブランディングの開発を外注し、それからそれを翼にすることを計画している.

私は?.. このプロジェクトについてミーティングをするときはいつでも就職活動のことを考えます。神々に感謝します。私はこのプロジェクトのプロジェクト マネージャーではありません。

結論: SharePoint ツールを非難するつもりはありませんが、人々がどこのオフィスでも間違った考え方でこのツールを使用していることは理解できます。何年も続く力による理由。

于 2009-01-30T01:37:17.203 に答える
8

それをどうするかは決してわかりませんでした。私たちをぼんやりと混乱させただけで、結局他のことに移りました。

于 2009-01-29T21:10:36.617 に答える
7

以前の会社である南アフリカのFMCGグループでのSharePointの経験は、多くの点で前向きでした(MOSSも実装しましたが、主にWSSです)。

カスタマイズしすぎないようにし、ボックス化された機能をできるだけ多く使用して、本当に必要な場合にのみカスタマイズすることにしました。

ビジネスユーザーのいくつかのグループは、プロジェクトや部門の問題に関するコラボレーションと知識管理の目的で、場合によっては特定の顧客パートナーシップ専用のエクストラネットサイトでそれを非常にうまく採用しました。最も効果的なサイトは、さまざまなビジネスユニットのCIOが直接関与したサイトでした。-彼らは技術を理解し、ビジネスの人々が光を見るのを助けるためにうまく配置されているようです。重要な要素は、CIOの1人が、実際に製品を導入する前の何年にもわたって、情報戦略の一環として、包括的な視点ベースのポータルの一般的なビジョンを推進していたという事実でもあったと思います。私は、SharePointを、重いトップダウンドライブではなく、価値の高いいくつかのポイントから有機的に広めることを強く信じています。しかし、SharePointが実装されると、ITに組み込まれているが、ビジネスにしっかりと定着している変更管理機能によって、スプレッドが十分にサポートされました。

あるビジネスでは、一般的なエクストラネットコラボレーションサイトをセットアップし、SharePointで人をトレーニングしました。ビジネスユーザーにとって、ビジネスパートナーとのコラボレーションのためのサブサイトを数分で作成できることは大きなメリットでした(ITがまだ行っていたアカウントの作成は別として)。これらのタイプのニーズは、以前はWebサイトのデザイン担当者や開発者によって何ヶ月も苦労していました。

私のチーム(開発チーム)では、コラボレーションやKMなどにWSSを幅広く使用しましたが、ソリューションの提供にも大きな影響を与えました。一つには、部門が切実に望んでいたが、率直に言って、必要以上にコストがかかり、時間がかかりすぎる小さなニッチなアプリの開発に何度も縛られていました。WSS製品に精通していることで、WSSだけを使用して、わずかな時間で適切なソリューションをセットアップできるようになることがますますわかりました。。いくつかはそれらがそれらのレベルで実行するのに十分単純でしたが(いくつかの進歩的な秘書タイプはかつてOutlookを採用したようにSharePointサイトを採用しています)、他は継続的な支援を必要としました-しかし保守性はカスタム作成されたC#/ASPよりもはるかに軽量でした.NETアプリ。結論-価値をより早く提供し、実際に違いが生じた場合にのみコードを使用して、TCOを削減することができました。

SharePointは、コードではなく作成するソリューションのクラスに私たちを助けてくれていると思いますすべて。たとえば、ある会社では、人間にExcelスプレッドシートで注文を送信してもらいたいと考えていました。私たちの純粋主義者は抵抗し、より水密なものを求めていますが、私たちは口述する立場になく、それらの制約の範囲内で敏捷性をもって提供する必要がありました。そこで、WSSサイトを作成し(以前に設定したルートエクストラネットコラボサイトからサブサイトを作成するだけで)、スプレッドシートをリストに添付してもらいました。BizTalkを設定して、それらを取得し、データを抽出し、注文をERPシステムにプッシュして、戻ってきてWSSリストアイテムにステータスのフラグを付けます。そのため、コードを作成しましたが、ユーザーエンドエクスペリエンス全体にWSSのすぐに使用できる機能を使用しました。

私は、SharePointが一般的なWebアプリケーション開発プラットフォームとしても期待しています(つまり、ここにたくさんの配管があり、必要に応じて活用および拡張できます)。学習の障壁があり、維持するのが難しい/厄介な場所にたくさんのコードが滑りやすい坂道があるため、まだ深く掘り下げていません。私はそれが本当かどうかを探求し続けるつもりですが、それまでの間、ソリューション構成の考え方で箱から出して活用する価値はたくさんあると思います。

于 2009-02-10T08:44:10.680 に答える
6

「銀/金/魔法の弾丸」の販売が行われている多くの人や組織に会います。

ビジネスに保存されている情報を統合したいと考えている人々を目にします。通常は、大規模な共有ドライブや文書がいたるところに散らばっており、Web ベースのさまざまなアプリケーションがあります。

組織は、従業員がすべてを簡単に利用できるようにし (検索可能性)、すべてが 1 つの巨大なアプリケーションの一部であるかのように見せることを望んでいます。これにより、組織全体のユーザーは、必要なすべてのことを実行できる一貫した場所を確保できます。

SharePoint を使用してすべてのビットをまとめて組織内のコンテキストを提供するのではなく、SharePoint の「中で」実行する必要があると人々が考えているという混乱が生じています (たとえば、大規模な「花を見つける」アプリケーションは、サイトのガーデニングセクションセクション)。

問題は、優れた情報アーキテクチャを実現するには、非常に多くの作業と、どこに行くべきかについての計画が必要だということです。多くの場合、SharePoint は新しい共有ドライブのように使用され、データはどこにでも放り出されます。

開発者にとって、これは日々の仕事では重要ではありませんが、午後やマネージャーにとっては重要です。開発は多くのドキュメントを生成する可能性があり、適切に作成された開発サイトは、「私たちが実行することはなかったが、昨日必要なプロジェクトの設計ドキュメント」を簡単に見つけることができます。

SharePoint は、実際には開発者のコ​​ア作業ではありません (つまり、開発環境やソース管理ではありません)。

于 2009-01-29T21:55:53.173 に答える
5

ここにSPがあります(非MOSSはバニラです)。

ほとんどの人はそれをどうするかわからない。それはその可能性に慣れていませんが、誰も(私を含めて)そのような時間を投資したいとは思っていません。

ここで使用されている方法は、リモート共有と事前定義されたフォルダ/ディレクトリ構造に簡単に置き換えることができます。

于 2009-01-29T21:18:25.277 に答える
5

私がさまざまな組織やサードパーティのコメントで観察してきたことから、「期待」という言葉に行き着きます。SharePoint がすべての問題に対する万能薬であると期待する人もいます。この考え方は、それがすべての世界で最高であるというものです。前述の機能を拡張するためにコーディングすることもできる幅広いコラボレーション ツールのセットを提供する、すぐに使用できるリッチな製品です。また、SharePoint は .NET 製品であるため、平均的な Microsoft 開発者でもすぐに RAD の優れた機能を利用し始めることができます。

この期待から出発して、a) Microsoft が実際に意図したことはなく、b) 知識豊富な SharePoint 開発者と適切な環境なしでは達成できないレベルに基準を設定しています。それよりも少し複雑であることに気付くのにそれほど時間はかかりません。はい、SharePoint に対してコーディングすることはできますが、それが .NET アプリの構築に似ていると期待することはできません。開発環境の要件からリリース プロセス、継続的なメンテナンスまで、すべてが単に ASP.NET アプリを構築するよりも複雑です。これはまた、多くの組織で SharePoint が一元化された共有環境であり、多くの場合、自由にソリューションを展開することを許可しないレベルのガバナンスをもたらすという事実に照らし合わせる必要があります。

期待に戻ります。これがコラボレーション活動、ポータル、またはドキュメント管理のための優れたツールであると仮定すると、それは素晴らしい製品です. ある程度の専門的なスキルが必要であり、展開と管理のプロセスが従来の .NET スタックとは異なることを期待して、プラットフォームでの開発を進めますが、その影響については目を大きく開いてください。

要約すると、期待が適切に設定されている限り、これは優れた製品であり、組織内で非常に肯定的に認識される可能性があります. ただし、その意味を完全に理解せずに誇大宣伝に巻き込まれると、期待を裏切らない可能性が高くなります。

于 2009-05-13T11:38:12.393 に答える
5

あなたまたは会社の誰かが技術に精通している限り、あなたの会社はSharepointの無料版から恩恵を受けるでしょう. Sharepoint Designer 2007 を購入してください。

私の会社は、シェアポイントとは何か、何をしているのかを本当に認識していません。これは実際には、単純な生産スケジューリングおよび部品追跡システムの「バックエンド」です。ユーザーには、sharepoint デザイナーで作成された基本的な aspx ページが表示されます。

Sharepoint を使用すると、情報を管理するためのリストをすばやく作成できます。SharePoint は、Excel を Web 環境に拡張したものと考えています。ほとんどの人は、Excel を使用して情報のリストを作成します。Sharepoint は、そのリスト情報に対する Web 機能を有効にします。

私は無料版の SharePoint を使用しており、Sharepoint Designer を使用して大幅にカスタマイズしています。私はプログラミングスキルのあるエンジニアです。シンプルだが有用なデータ収集 Web ページを作成できたことは十分に承知しています。

私は最初に WSS 2.0 を使用して、ソフトウェア バグ トラッカーを作成しました。当時(2003年)にFogbugzを発見したばかりで、実際にFogbugzの試用版を使っていました。問題を割り当てることができ、電子メールが自動的に送信されたことが主な理由で、誰もが Fogbugz を愛していました。標準の SharePoint の問題追跡リストもこれを実現します。Fogbugz には他にも多くの機能があったことは明らかですが、経営陣は SharePoint を使用することにしました.....

結局、SharePoint はプロジェクト情報の管理と顧客とのコミュニケーションに広く使用されました。これはほとんどカスタマイズされていません。いくつかのサイト テンプレートを作成しただけで、新しいプロジェクトが作成されるたびに、適切なドキュメント ライブラリ、問題追跡リスト、カレンダーなどを使用して新しいサイトが作成されました。

私はシェアポイントのファンです!!! そうそう、多くの制限があり、最上位の項目はデータベースのベスト プラクティスに違反していますが、Sharepoint は機能します。

于 2009-02-04T17:30:46.213 に答える
5

tl;dr : Sharepoint は、仕事を成し遂げるのを助けることに集中しているという印象を与えません。

あまりよくありません。

私たちの作業では、Fogbugz が、私たちが実際に使用したい (そして実際に使用している) 機能を、明らかにより直感的で、より速く、したがってより便利な方法で提供していることがわかります。確かに、これらの多くについて SharePoint ワークフローを作成できますが、なぜ作成するのでしょうか? 私たちは、私たちの仕事を支援することにはるかに重点を置いているように見えるシステムから、賢明なワークフローと機能を直接取得します。

  • 開発ワークフロー: ケース重視の構造がとても気に入っています。
  • 非公式の議論: Fogbugz の議論は、昔の Usenet グループと類似しており、取り組む必要があるケースに変わる前に、問題について話し合うのに最適です。
  • 永続的な議論/ドキュメント: ウィキは、必要な資料、特にドキュメントを構築するのに最適な場所です。
  • SVN 統合: これは私たちにとってますます重要になっています。
  • プロジェクトの報告/証拠に基づいたスケジューリング: これは、私たちの計画と報告のプロセスにとって急速に重要になってきています。

最後の忌まわしい事実: 私たちはかなり長い間ここで Sharepoint を使用してきましたが、開発者はまったく関心を持っていませんでした。Fogbugz を導入すると、すぐに開発チームがそれを採用し、日常業務の一部にしました。

注: これは Fogbugz の広告のように見えますが、Sharepoint をさらに支援するツールは他にもあります。

于 2009-01-29T21:06:56.750 に答える
3

「環境が変わった場合」の更新について...私の経験では、状況は少し悪化しています。これは主にユーザー インターフェイスが原因です。

開発者として、「SharePoint のように見える」というコメントをよく耳にします。これは、製品がますます時代遅れに見えることを示しています。(リリース以来、私はその外観にがっかりしています。) これは、非常に多くのテーブルが使用されており、フラットアウトのがらくた HTML があるため、多くの CSS とグラフィックの作業が苦痛であることを意味します。

見た目は別として、多くの人がインターフェースが直感的ではなく、イライラしていると感じています. 特に、知識の少ないユーザーにとっては、ドキュメントをアップロードするだけで、多くのクリックと別のページが発生します。

また、UI が不十分なため、インターフェイスを整えてユーザーにより良いフィードバックを提供するために、多くの Web-2.0/AJAX/jQuery の作業を行うよう求められています。この製品は、このために設計されたものではありません。jQuery が 2007 リリースで非常に残念な Web サービスを必要とする場合、時間がかかります。(幸いなことに、誰かがついにSharePoint Web サービス用の jQuery ライブラリを開始しました。)

製品の次のバージョンが間近に迫っている場合によくあることですが、2010 年の RTM に到達したときに、2007 プラットフォームで新しいプロジェクトを開始する理由がほとんどないように、SharePoint 2010 が堅固であることを切望しています。

于 2009-10-01T11:23:10.247 に答える
3

シェアポイントは悪くないと思います!情報管理の仕方がスゴイ!しかし、私が気になることの 1 つは、エンド ユーザーにとって少し複雑すぎるということです。私たちの組織は 2 か月かけて彼らを教育しましたが、結果は私たちの期待をはるかに下回っています。前世紀の 50 年代に超音速機を手に入れたように見えることもありますが、それをフルに活用することはできません!

于 2009-02-05T01:19:15.193 に答える
2

そのため、これまでに SharePoint を真にポジティブに体験した人は誰もいなかったにもかかわらず、誰もが SharePoint を購入していることに気付きました。MSがこれをどのように管理したのか混乱しますか?

パイプラインには、SP の注入から大きな恩恵を受ける単純なプロジェクトが数多くあります。しかし、ほとんどの場合、SharePoint を製品とテクノロジの組み合わせに「ブレンド」しようとしていると思います。それがうまくいくことは本当にうまくいきますが、特定のシナリオでは、ほとんどの場合、カスタマイズのいくつかの要素 (CSS、JScript、またはサーバー側のコード) が必要になり、それが常に適切なソリューションであるとは限りません。

最近、ある MS アナリストが SharePoint を粘土のモデリングと呼んでいるのを聞きました。

于 2009-01-30T09:19:06.473 に答える
1

この質問が開発者向け (そして少し古い) であることは承知していますが、ビジネス ユーザーの観点から意見を共有したいと思います。当社 (全世界で 75,000 人以上の従業員) は、MOSS 2007 の「チーム サイト」テンプレートを展開し、既存の Documentum e-Room を廃止し、ゼロ トレーニング、ゼロ情報で解放しました。

会社全体のユーザーは、チーム サイトをドキュメント リポジトリとして使用します。もう少し理解があり、MOSS 2007 のコラボレーション機能をセットアップして使用し始めたユーザーがいくつかいます。

また、私たちの会社はまだ IE6 と MS Office 2003 を使用していることにも言及しておく必要があります (この事実だけで、SharePoint で実行できないすべてのことを残念に思います)。

当社は、提供されたツールを使用してより良いコラボレーションを作成する方法を見つけたエンド ユーザーに報酬を与えることはありません。IS/IT 部門は、学習教材、機会の提供、またはエンド ユーザーへの支援をいかなる方法でも拒否します。現在のドッグイートドッグの考え方では、過去に5人以上が行っていた仕事を1人でこなしながら、次から次へと解雇されています。彼らの仕事の。

私がいくつかの共同作業機能を学び、いくつかのグループのために実装したことは、私をひどく怖がらせます-私は自分の時間でそれを学びましたが-それは、私を忙しくさせるのに十分な仕事がないと認識されることを意味しますか?したがって、消耗品ですか?

SharePoint について私が感じている限りでは、SharePoint が大好きです。それはエンドユーザーの手にかなりの機能をもたらします... ああ、ちょっと時間がかかるかもしれませんが、最終的には理解できます. ページの作成に少しイライラすることもありますが (CSS と HMTL があればいいのにと思います)、もちろん、sharepoint デザイナーを使用することはできません。

1. ロールアウトにトレーニングが含まれていれば、より適切な展開でした。2. ロールアウト中に、堅実な変更管理が実装されました。

于 2011-06-10T19:30:49.190 に答える