私たちのチームは30人以上を雇用しています。 スケーラブルなWebソリューションを開発しています。 私たちは、トムスク、サンクトペテルブルク、モスクワに住んでいます。 タスクのコラボレーションを整理するために、タスクトラッカーを使用しました。 プロジェクト中に、貴重な開発が作成され、知識を持って作業を整理する必要がありました。 さまざまなwikiシステムを試しました。 私たちの知識のほとんどは、現在の問題を解決することで生み出されることが判明しました。 問題に遭遇しました：

• タスクトラッカーですべてのタスクを入力および管理するのは不便なので、従業員は常にインスタントメッセンジャーを介してコミュニケーションに切り替えます。
• 多くの知識が電子メールとインスタントメッセンジャーに蓄積されています。 通信からタスクトラッカーおよびwikiへの知識の転送には、多くの時間とエネルギーが必要です。
• プロジェクトを計画する際に、プロジェクトのコンセプト全体がウィキに記録されている場合、ウィキ内の情報と実際の状況との間には日々差があり、知識ベースの維持は不合理に時間がかかります。

これらの問題を解決するために、独自の方法論とコラボレーション環境を開発しました。 それで、新しいプロジェクトが生まれました。 この記事では、彼についてお話したいと思います。 最初に、チームワークがチームでどのように編成されているかを見てみましょう。

在庫切れの知識

情報フローモデルは、簡素化されたビジネスプロセスで最もよく見られます。 小さな家電店を考えてみましょう。 店は11人を雇用し、パビリオンと倉庫があります。
注文処理のビジネスプロセスについて説明します。これには、注文、パッケージング、クライアントへの配送の手順が含まれます。 3人がプロセスに参加し、プロセスアクションが専門の情報システムに記録され、定期的に発生します。

簡素化されたビジネスプロセス

別の8人は組織内の他のタスクに従事しており、口頭、電子メール、インスタントメッセンジャー、およびその他の専門的な情報システムでコミュニケーションを取ります。
家電店での通信方式

環境：競合他社、サプライヤー、政府機関、天気など 常に変化しています。 店長はこれらの変更を特定し、迅速な決定を下す必要があります。 このような決定は、電子メールやメッセンジャーで議論され、口頭で行われます。 これらのソリューションは、店舗が生き残り、長期的に収益性を維持し、本質的にビジネス価値を生み出すことを可能にします。 貴重な知識のほとんどは、頭の中にあります。 これは、会社の知識に対するニーズが小さく、従業員が会社に残っている限り、大したことではありません。
どのような知識が価値がありますか？ この例では、倉庫の地下から悪臭が出るという問題を解決した後、電話をかける場所、尋ねる場所などに関する情報を書き留めることができます。

航空税

別の状況を考えてみましょう。分散ITチームが会計ソフトウェアを開発および実装します。 「空中税」に関する新しい法律が公開されました。 したがって、ソフトウェアを変更する必要があります。 決定は次の順序で行われます。
1.プロジェクトマネージャーはプログラマーに状況を説明する手紙を書きます。
2.プログラマーはタスクトラッカーでタスクを開始し、アーキテクトに次のように書き込みます。「アプリケーションは異常です。詳細を明確にする必要があります。」
3.アーキテクトは、明確にする必要がある質問のリストをマネージャーに書き込みます。
4.マネージャーは、必要なものの詳細な説明を含む手紙を送ります。
5.アーキテクトがタスクトラッカーにレターを追加します。
6.プログラマーは、タスクの結果をタスクトラッカーに書き込みます。
7.プログラマーは、企業wikiのアーキテクチャを変更します。
コミュニケーションを示します。
ITチームの問題を解決するときに情報が流れる
この例では、すべての情報が損失や歪みなしに送信され、その結果がプロジェクトマネージャーによって直ちに受け入れられた理想的なケースが考慮されました。
実際には、明確化が必要になる場合が多く、3つすべてがメッセンジャーのタスクについてコミュニケーションを取ります。 これらの改良には知識が含まれます。 その結果、それらのほとんどは会社にとって失われ、従業員の個人アーカイブに残ります。
コンテキストコミュニケーションに基づいて、コラボレーションと問題解決へのアプローチを提供します。 この場合、企業内の主要なやり取りは、議論が行われている新しい環境で行われます。ここでタスクが設定されます。 このモデルは、電子メール、タスク、Wikiシステムを組み合わせたものです。
Volnaは知識ベース、メール、タスクシステムを置き換えます

タスクを完了すると、通信の一部が削除され、重要なものだけが残ります。 セクションには見出しが付けられ、この方法でドキュメントセクションが作成されます。
そのようなシステムで作業しているチームは以下を受け取ります：

• より少ない説明を作成する必要があるため、タスクをより速く設定する機能。
• 問題を解決する過程で得られた知識は失われませんが、文書化されます。

心理的な側面にも注意する価値があります。 タスクまたは目標への各レプリカの厳密なバインドはありません。 メッセンジャーに似た環境で、人々がコミュニケーションをとり、質問をするのは簡単です。

目標を設定する方法

現在、ナレッジシステム、メッセージ、問題ステートメントを共有していません。 タスクを設定するには、コンテキスト内の括弧内に単語「タスク」を書くだけで、システムは式を処理し、エグゼキュータに通知します。
この記事の歴史の例を紹介します。 「航空税」の状況のイラストをスケッチしましたが、
紙の上の将来のイラストに関する考え

短いテキストの説明を作成し、デザイナーにタスクを設定しました：「sketch（task sasha）」。 その後、彼らは働き続けました。
コンテキスト内のタスク設定インターフェース

サーシャ：「仕事に取りかかったとき、彼らはすでに他の写真を決めていたので、彼らの一般的なデザインについて考え始めました。 イラストを描いて記事に貼り付けました。 この時点で同僚は書き続け、その後、改訂のタスクを設定しました。 今回は2回のイテレーションを管理しました:) "。
TaskGadgetでタスクを処理します。

コンテキストタスク用のTaskGadget

リストの各タスクには、コンテキストへの遷移へのリンクが含まれています。
現在、ソリューションはGoogle Wave（GW）プラットフォームに基づいており、拡張機能とロボットを作成しました。 将来的には、すべてのツールを、ApacheコンソーシアムとGWの後継者によって開発されたプラットフォームであるWiaBに移行する予定です。
更新：多くの人が、GWの運命と終了日について質問します。 Googleの代表者は、私たちは死んだ馬に乗せたと言います。 しかし、それにもかかわらず、 代替プラットフォームがユーザーを受け入れる準備ができているように見えるまでGWは機能すると約束しています。

ディスカッションとドキュメントの操作

パッケージングの作業の過程で、まだそのようなドキュメントがあります 、
将来的には、見出しから読み直し、徐々に希望するコンテキストに浸ることができます。
ズームリーディングと呼びます。

ズーム読書

Google Chromeの拡張機能に基づいてこの概念を実装しようとしました。 そして、将来的には他のプラットフォームで開発する予定です。

この記事が主に私たちのプロジェクトを信じて助けてくれた人々のおかげで登場したことを追加する必要があります：

記事編集者のリスト

方法論を試すことを提案します 。