知識共有の目標
多くの場合、次の目標リストに出くわすことがあります。
- 開発者を訓練する
- 開発者の生産性を向上
- 地域の専門家グループを構築する
- 開発リスクを減らす
- イノベーションを促進する
このリストは、知識共有の分野における活動を完全に説明していますが、非常に抽象的なものであり、期待される結果についてはわかりません。 私の意見では、これらのポイントを読むことで、人によってまったく異なることを理解できます。 誰もが新しいことをすべて学ぶ必要があると考えるでしょう。誰かは基礎知識について考えるでしょう。 これらのポイントを一般の人々に近づけようとして、次の目標を達成しました。
- 開発者間で知識を広める
- スキルと用語を調整する
- 最新のIT業界標準に引き上げる
- 内部開発標準を開発する
1.開発者間で知識を広める
知識共有の分野で最も明白なタスクは、開発者間での情報の普及です。 互いに統合し、バージョンの一貫性を維持する必要がある複数のプロジェクトで並行作業が進行している企業では、これが現在最も重要な役割を果たしています。 あるチームが統合されている別のチームのコンポーネントの動作の原則について認識していると、より適切なソリューションが作成され、デバッグの反復回数が減ります。 プロジェクト間の統合を考慮しない場合、このアクティビティは異なるプロジェクトで同じものを再作成する可能性を減らします。
この分野の活動は、最初のリストから2つの目標を一度に達成するのに役立ちます。リスクを減らし、開発者の有効性を高めることです。 誰かが知識を広めることで、開発者が会社に対する独占権を失うことに気付くかもしれません。 これが、開発者が開発分野の1つに関する知識をすぐに共有したくない理由になる場合があると思います。 誰かが言ったように、シッターだけがこれをします。 彼らの排他性を失う恐れは、そのトピックの能力が不十分であるという恐れと関連していると思います。 人がこのトピックについて話そうとする瞬間に、彼の能力の問題は鋭く提起されます。 ここで心理学的理論を提唱することは想定していませんが、トピックを完全に理解していなくても、他の人に伝えることで頭脳を整え、自信を持って必要なレベルの知識を補うことができます。
2.スキルと用語の調整
私の意見では、知識共有のやや目立たないタスクは、開発者とその用語のスキルを調整することです。 私たちが主に話しているスキルについては、経験の少ない人を経験のある人に引き寄せることで、ディスカッションと開発の両方で平等に参加できるようにします。 繰り返しになりますが、これは会社自体にとっても開発者自身にとっても、win-winゲームにとっても有用です。 私はスキルを引き上げることに焦点を当てています 一連のスキルはプロジェクトによって決定されます。 教育にはあまりにも抽象的な定義があります。 この方向に進む前に、プロジェクトに必要なスキルと開発者のレベルに応じてカットを決定するために、チームを少し調査する必要があります。 その結果、どのアクションが追加のアクションを必要とするかが明確になります。
タスクのもう1つの側面は、開発者が使用する用語の統一です。 社内の標準的な用語を使用して異常なことを説明する状況に出会いました。 たとえば、マイルストーンという用語は、世界の他の地域がユーザーストーリーを使用するために使用されました。 さらに、誤って使用されている用語や専門用語などが多くありますが、それ自体はまったく重要ではありません。 チームが変わらなければ、誰も出入りしません。すべてが順調です。 ある程度の流動性が現れるとすぐに、コミュニケーションが不十分になります。 多くのプロジェクトを持つ企業では、同じものの指定にも違いがあるかもしれません。 たとえば、場所とプロパティは2つの異なるプロジェクトで同じことを意味します。特定のレストランです。
この方向での活動の別の有用な結果は、専門家グループの作成です。 私はこれを、自分のしていることが好きで、「トピックへの愛」で他の人に感染する人々のグループとして想像します。 通常、これらは非公式のチームリーダーであり、社内の多くの開発の推進者です。
3. IT業界の最新の標準に引き上げる
このタスクは、開発者のトレーニングに関連しています。 前の2つと同様に、両者にとっても有益ですが、この場合、会社はさらに心配する必要があります。 活動データと開発者に投資することにより、企業は後者を失う可能性があります。 これがおそらく、一部の企業がこの分野に投資しない理由です。 しかし、この理由は、アイデアが表面的にすぎて、他のタスクとは関係なく理解されているためだと思われます。 ここで私は技術的なスキルを意味することを明確にします。
私の意見では、このタスクは専門家グループによって解決されるべきです。 そして重大な場合にのみ、外部からの知識の注入が必要です。 これは重要です。なぜなら、社内の改善と開発者自身の動機により、トレーニングと改善が行われるからです。 そして、会社はそのような「ドライバー」を促進するために投資を指示する必要があります。 これにより、参加者は会社にとどまることに最大限の関心を持ちます。 そして、結果として、別の重要なタスクの方向への動きがあります：イノベーション。
4.内部開発標準を開発する
この方向での活動の結果は、専門家グループと調整された一連の既成のソリューション、アプローチ、およびテンプレートです。 このキットは、IT業界で受け入れられている標準とは異なる場合がありますが、会社自体のために機能しています。 これは、技術的ソリューションだけでなく、設計、開発プロセス、監視方法、および企業と開発者が共通の目標を達成できるようにする他のすべての可能なプラクティスに関するものです。 wiki、cの例、GitHubの知識ベースのように見えます。 この分野の特徴は、技術分野の専門家グループでの明示的な作業であり、そのようなグループの特定もこのタスクの一部です。
オプショナル
コメントでは、あなたの会社での知識の交換と状況について教えてください？ この分野の開発でどのような困難に遭遇しましたか、どのように決めましたか？