1

時間の経過とともに、私たちの情報戦略はいたるところに行き渡り、より明確なポリシーと、すべての人が情報共有について同期するためのより明確な方法を模索しています。注意すべき点は、組織は300人以上であり、世界中の複数の国に存在するということです。また、Sharepointに慣れている人、合流点に慣れている人などがいるので、ここには間違いなく「変化」の要素があります。

これが私たちの現在の問題と私たちがそれらについて何をしようと考えているかです。フィードバックや提案などを聞きたいです。

今日のコンテンツ:

  1. 技術設計情報/アーキテクチャドキュメント
  2. 議事録、アクションアイテムなど
  3. プロジェクト計画とロードマップ
  4. 組織のビジネス管理情報-旅行、予算情報、人員情報など
  5. 事業分析、要件などを含むプロジェクトページ

主な問題のいくつかを次に示します。

データの行き先-ConfluenceWIKIとSharepointとイントラネットサイト-#1、#2、#3、#5にはConfluence WIKIを使用しますが、#1、#3、#4、#5にもSharepointを使用します。私たちは、物事を一貫させるために、特定の場所に各番号を義務付ける必要があるかどうかを判断しようとしています。私たちはSharepointをより多くのドキュメントのディレクトリ構造に使用しており、よりアドホックに変更可能なコンテンツにはConfluenceを使用しています。

古いデータ-これはおそらく組織にとって文化的なことですが、ある時点でデータが古くなり、関連性がなくなります。古いデータが多くのノイズを発生させないようにし、最新の正しいデータが最新であることを確認するための最良の方法は何ですか。組織内にこれに責任のある人がいるのか、それとも暗黙の「全員の仕事」であるのか。これは、人々が去ったり、参加したりするときなど、より大きな問題です。。

より積極的な使用法-人々を電子メールから解放し、「これは他の人にとって役立つでしょうか..電子メールチェーンではなく一元化された場所に配置させてください」と考えて停止するための最良の方法は何ですか。。

また、組織のコミュニケーションと情報管理を改善するための良い方法に関する他の話

4

4 に答える 4

2

情報の混乱の根本的な原因は、「所有権がない」ことです。

プロジェクトには人員が割り当てられます。プロジェクトは終了 (またはキャンセル) され、人々は移動し、文書は置き去りにされて「ほこり」が集まり、情報が混乱します。

これを防ぐのは難しいです。wiki 対 sharepoint は混乱に対処していません。混乱を蓄積するために使用されている技術基盤をシフトするだけです。

混み具合を見てみよう

  1. 技術設計情報 / アーキテクチャ ドキュメント。古いものは関係ありません。現在と無関係があります。ウィキ。

    昨年の廃止された設計情報は -- まあ -- 廃止されました。

  2. 会議の議事録、アクション アイテムなど。アクション アイテムは、開発スプリントで誰かのバックログの一部になるか、おそらく決して完了しないでしょう。バックログは wiki アイテムです。他のすべては歴史であり、興味深いかもしれませんが、通常はそうではありません。スプリントのバックログ項目を作成したり、アーキテクチャを更新したり、開発の問題を解決したりしなかった場合、会議はおそらく時間の無駄でした。

  3. プロジェクト計画とロードマップ。スプリント バックログは重要です。これが「計画とロードマップ」が目指しているものです。計画をロードマップで補足する必要がある場合は、おそらく計画をあきらめて、スクラムを使用し、バックログを最新の状態に保つ必要があります。

    当初の計画は、プロジェクト開始時の誰かの推測であり、現在のプロジェクト チームにとってあまり興味深いものではありません。

  4. 組織のビジネス管理情報 - 旅行、予算情報、人数情報など。高度に構造化されたもの (予算、組織) と構造化されていないもの (「旅行」?) が奇妙に混ざり合っています。

    どのくらいの歴史が必要ですか?なし?せいぜいウィキ。財務または人事システムは、それが属する場所です。しかし、大規模な組織では、会計システムを使用するのが困難で煩雑になる可能性があるため、実際の予算の数値は Oracle Financials 内に埋もれているため、古い予算の数値を含む SharePoint ページのような二次的な情報源を作成します。

  5. ビジネス分析、要件などを含むプロジェクト ページ。これはバックログです。プロジェクトのロードマップ、要件、および分析は、1 つのドキュメントである必要があります。ウィキで。

    歴史が重要になることはめったにありません。要件が何であるかというプロジェクト開始時の誰かのコンセプトは、もはやあまり重要ではありません。最終的な形で要件がどのように発展したかは、歴史よりもはるかに重要です。ウィキ素材です。

「古すぎる」とは何歳ですか? 私は、30 年前のソフトウェアを使用している顧客と仕事をしてきました。ソフトウェアは (明らかに) 本番環境にあるため関連性があります。

ただし、ドキュメントはすべてがらくたです。ソフトウェアはメンテナンス済みです。変更管理記録がいっぱいです。「元の」仕様は、変更管理を組み込むたびに細心の注意を払って書き直す必要があります。変更管理ドキュメントは非常に広範囲に及ぶ可能性があるため、変更が適用された場所を確認する唯一の方法は、ソースを読み、そこから-現在の状態の仕様をリバース エンジニアリングします。

ソースのリバース エンジニアリングによって 30 年前のアプリしか理解できない場合は、30 年前の紙の山を破棄します。無駄だ。

整備が終わった時点で「本来の」仕様は切り下げられています。

それをきれいにする方法は? Wiki ページまたは SharePoint サイトを作成すると、そのサイトは永久に所有されます。あなたが去ると、あなたの後任者がそれを永久に所有します。

各マネージャーは、スタッフが作成するすべての情報に対して 100% の責任を負います。彼らは物事を削除する必要があります。弱い解決策は、「アーカイブ」することです。これは、「D-word」なしで「delete」と言う丁寧な言い方です。

クリーンアップは、すべてのマネージャーの継続的な責任でなければなりません。それが何であるか、または所有している理由を思い出せない場合は、削除するように要求 (または「奨励」) する必要があります。過去 2 年間にアクセスされていないものはすべて、問題なくアーカイブする必要があります。10年前のすべては、無関係な歴史です。

それは苦痛であり、価値を生み出す仕事とは思えません。結局のところ、私たちはITで働いています。私たちの仕事はソフトウェアを「書く」ことであり、削除することではありません。発砲の脅威にさらされない限り、誰もそれをしません。

ストレージのコストは比較的低いです。クリーンアップのコストが高くなります。

メールの連鎖を止めるには?
参加をお断りします。電子メール チェーンを wiki の更新 (または共有ポイントの更新) に置き換えることに重点を置いた「Break the Chain」キャンペーンを作成します。

ウィキがリンクを提供し、電子メールよりも編集が速いことを確認してください。

本当に便利な解決策 (電子メール) を放棄するよう強制することはできません。wiki をより価値のあるものにし、電子メールと同じくらい便利なものにする必要があります。

ウィキで価値を上げてください。メール チェーンを非推奨にします。電子メール チェーンへの応答を拒否します。「やるべきこと」のアクションアイテムを電子メールで受け取ることを拒否します。

于 2010-02-04T15:53:05.363 に答える
0

ウィキにファイルを保持させない理由はありますか?

また、内部メールへの添付ファイルを許可しないようにメール サーバーを制限するのは、おそらく厳しすぎるかもしれませんが、複数回メールで送信する必要があるものをすべて wiki に入れるように人々に依頼することは、非常に便利です。

于 2010-02-04T15:56:19.813 に答える
0

効率的な情報管理は、実に難しい問題です。「シンプルであるほど良い」という原則が奇跡を起こして問題を解決できることがわかりました。

データはどこに行くべきか- 私たちはウィキのアプローチを強く信じています。実際、非常に大きなバイナリ ファイルを除いて、おそらくあらゆる種類の情報を共有するために Confluence を使用しています。そのために、Dropbox を使用しています。そのシンプルさは絶対にキラー機能です。(ヒント: Dropbox in Confluenceプラグインと統合できます。)

古いデータの検索- 私たちの定義では、古いデータとは、特定の期間更新または表示されていないものです。Confluenceのアーカイブ プラグインは、これらをすばやく自動的に検出し、作成者と管理者に報告します。作成者と管理者は、更新 (または削除、次の項目を参照) する可能性があります。もちろん、有効期限が切れない情報もありますが、対応するページをマークした後、プラグインはそれらをスキップできます.

古いデータの削除- これにはかなり積極的です。データの関連性が (あまり) なくなった場合は、今すぐクリーンアップしてください。実際にデータを削除することはないため、この方法を安全​​に実行できます。アーカイブ プラグインを使用して、古いデータを非表示のアーカイブ スペースに移動するだけです。後で気が変わった場合でも、アーカイブで見つけたり、表示したり、復元したりするのは非常に簡単です。

より積極的な使用- 私たちのルール: 情報を永続的に保持する必要がある場合は、電子メールで送信しないでください。代わりに wiki ページに置きます。一部の人々にとって難しいことは、情報に最適な場所 (どのスペース? ページ階層のどこ?) を見つけることです。残念ながら、あいまいなスコープを持つ不適切に組織化されたスペースは、効率を妨げるもう 1 つの大きな要因です。大企業は、これを解決するためにwiki ガーデナーを導入することを検討するかもしれません。

于 2013-07-02T05:42:34.237 に答える
0

Confluence Wiki を使用してドキュメントを添付ファイルとして保存し、Wiki のパスを SharePoint のファイル パスとして機能させることができます。

Re: 古いデータ: データ (個人とチームの両方) の所有権を持ち、所有者の成果物にすべてのデータのメンテナンスが含まれていることを確認します。

「オフメール」に関しては、すべてのメールを積極的に監視する以外に人々にこれを強制することはできないため、これを行うのは困難です... しかし、Wiki に追加されたコンテンツに関するメトリクスを使用して、いくつかの成果物を試すことができます。そうすれば、人々は新しいものを作成する代わりに、電子メールで既に行われた作業を再利用して Wiki に貼り付けて「クォータ」を満たすことを望む可能性が高くなります。

私たちの会社および/またはチームは、これら3つのアプローチすべてを使用して、過去にある程度の成功を収めました

于 2010-02-04T15:20:34.580 に答える