クライアントチームと協力してチームを構築することは、同じことではないとすぐに言います。 長所と短所がありますが、アジャイルコーチと技術起業家の両方に役立つ一般的な慣行もあります。
チームのだれが誰であるかをすばやく理解し、チーム構築プロセスの時間を節約するのに役立つツールをいくつか共有したいと思います。
したがって、プロジェクトに一緒に取り組む人々（5〜7人）のグループがあるとします。 アセンブリの開始場所 知人から始めましょう...
販売/購入
なんで？
- 同僚の強みや興味について知り、学びます
- 自分自身とチームのリソース状態を誇りに思う
どれくらい時間がかかりますか？
- 30〜40分
何が必要ですか？
- インデックスカードまたはステッカー
- フェルトペン
- フリップチャート
- マーカー
ステップ1.準備
チームメンバーにインデックスカードを提示し、それを2つの部分に分割します。左の部分は売り、右の部分は買いです。 フリップチャートで、2つの質問を書き留めて、参加者に2〜3分答えて、インデックスカードに記入してもらいます。
- 販売：どのようなスキルと資質が豊富に開発されていますか、それらを簡単に「販売」できますか？
- 購入：どのようなスキルと資質を「購入」したいと思いますか。 自分でさらに成長するには？
ステップ2.プレゼンテーション
チームの各メンバー（サークル内）が自己紹介し、まだ知らない場合は、自分の長所と専門的成長への関心を表明してください。 これには、1人あたり、一般にチームごとに1〜3分かかります-最大30分。
ステップ3.デバフ
各チームのエクササイズは、報告で強化するのに役立ちます。 ここで、「あなたは何に気付きましたか？」という質問をすることができます。 私の経験では、観察は次のとおりでした。
- 部屋にはたくさんの賢明な人がいて、一緒に仕事をするのが面白いでしょう
- 学びたい人と知識を共有したい人がいます
- クールな製品を作るためのほぼすべてのものがあります
*私の意見では、「あなたは何に気付きましたか？」という質問は、あなたがどんなチーム活動をしていても、デバフする最も簡単で迅速な方法です。 それは、内省（意識）を高め、明白な結論と暗黙的な結論の両方を表面に引き出します。 彼、または彼の修正をもっと頻繁に尋ねることを強くお勧めします。
次のチーム活動では、スキルのマトリックスを形成することをお勧めします。 彼の目標はスキルと知識の研究でもありますが、一般的な知人のためではなく、チームの構成とクロス機能性のレベルの分析のためです。 機能横断性に関する小さな余談。
チームのクロス機能
多くの場合、開発者のフロントエンドを使用してデータベースアーキテクチャを設計し、設計者を使用してテストケースを作成することが提案されているかのように誤解されています。
実際、私たちは個人ではなくチームのクロス機能性について話している。 つまり、機能を横断することで、プロジェクトの実装に必要なすべての機能を実行するチーム全体の能力を理解しています。
私の昔ながらのチームのコーチは、チームのスキルと知識を文字通り1つの部屋で最大限に集中することを常に勧めています。 分散プロジェクトの世界では、これはほとんど不可能ですが、私が今チームを構築している場合、一緒に働く人々が共通のタイムゾーン、国、文化、物理的に発達できる高い生産性を支持して、オフィスと給与のコストの節約を無視しますスペース。
個別のクロス機能
高い生産性のもう1つの重要な側面は、チームのT社員の存在、さらには大部分です。 ここで私たちは個々のクロス機能性について話しています、そしてそれが私がそれが意味することです。
T型の専門家は、1つの専門分野/ドメインを深く（文字Tのベースとして）理解しており、他の関連分野の幅広い（文字Tのキャップのような）関心を持っているため、そのような名前を取得しました。
このような人は、プロジェクトに3種類の利点をもたらします。
- その主な目的を定性的に実現できる
- リソースのサポートが必要な分野で交換またはペアで作業できます
- 耳を傾け、理解し、意見を共有し、多くの設計上の問題について新鮮なアイデアを生み出すことができます
最後のポイントの重要性は、特に開発者がドメインと機能分野の幅広い知識を開発し、単なる高品質コードの行よりもはるかに高い価値を生み出す動的な技術プロジェクトで過小評価されるべきではありません。
星のチームではなく 、 星のチームが必要です。そのため、Tピープルを成長させ、チームと個人のクロス機能のバランスを維持することが役立ちます。
この方向への最初のステップは、スキルのマトリックスを作成するワークショップです。
スキルマトリックス
なんで？
- 製品の販売に必要なスキルをマップする
- プロジェクトで利用可能なすべての人々について学びます（できれば、パートタイムおよび契約の参加者でさえ、全員の存在が望ましい）
- チームの十分な知識とスキルを分析する
- ボトルネックと潜在的なリソースリスクを理解する
- チーム内での知識の移転と職域を超えた開発のための行動を計画する
どれくらい時間がかかりますか？
- 60〜180分
何が必要ですか？
- フリップチャート
- マーカー
- ステッカー
- フェルトペン
- 製品のバックログ（スクリプトによる）、仕様、または要件（何と呼んでも）
誰を招待しますか？
- チーム全体
- 製品の所有者（ところで）、顧客、または私たちが開発するものについて最も明確な考えを持っている人（あなたがそれを呼ぶものは何でも）
ステップ1.ビジョン
製品のアイデアの簡単な概要については、製品所有者（これがあなたかもしれません）に問い合わせてください。
- 彼はどんな問題を解決しますか
- 主要ユーザーは誰ですか
- 彼はどのようにお金を稼ぐつもりですか
- 競合他社は市場に存在しますか
- どうやって違うようになりたいの
- どのテクノロジーを使用する予定ですか
- 制限は何ですか
もちろん、2つの企業EPRシステムの統合インターフェースを作成する場合、ピッチの内容は異なりますが、その目的は変わりません：作成する内容、必要なスキル、選択できるテクノロジー、および事前定義済みの制限をすばやく理解するため。
ステップ2.スキル
ピッチと仕様に基づいて、チームが持つべきスキルとテクノロジーを書き留めます。 技術の議論や選択の自由度に応じて、最初にステッカーに書いたり、すぐにフリップチャートに書いたりできます。
マトリックスでフリップチャートシートを描画します。その列には技術とスキルがあり、行には人の名前があります。
列の例：
- html5
- css3
- Php
- Js
- DB
- Ux
ステップ3.人々
古い学校のプロジェクト管理からの同僚、私はすぐに人々のリソースを呼び出すことを停止することを提案します。 人は人です。 行には、チーム自体が望む名前、姓、またはニックネームがあります。
私の実務でデザイナーがよくそうだったように、「クローゼット内」の誰もが忘れないようにしてください。プロジェクトの立ち上げに伴うトレーニングとコーチングの1週間後、マトリックスを埋める段階で、経営陣はUXを招待するのを忘れたことを「覚えていました」。
そのため、行にはチームメンバーのリストがあります。 マトリックステンプレートの準備ができたら、入力を開始します。 行と列の交点で、マトリックス全体に丸い空白を描くとよいでしょう。 以下は何が起こるかの例です。
ステップ4.サンズ
各チームメンバーは、4種類の「太陽」のいずれかでマトリックスを埋めます。 太陽は、4つのセグメントに分割された円を指します。
充填ルール：
- 空：このタスクを完了できない、または完了したくない
- 最初の上部四半期は塗りつぶされています：タスクの要素に精通しています
- 垂直の半分は塗りつぶされています：私は誰かの助けを借りてそれを行うことができます
- 4分の3塗りつぶし：自分でタスクを完了することができます
- すべてが塗りつぶされている：私は自分でそれをして別のことを教えることができます
チームメンバーが基本的にタスクを実行したくない場合、たとえその方法を知っていても、サークルに記入するように依頼することはありません 。 ここでは、やる気に取り組み、チームワークとサポートの重要性を理解する必要がありますが、人々に喜びをもたらさないことを強制しないでください。 ほとんどの場合、このプロジェクトは利点をもたらしません。
ステップ5：分析
では、これが私たちにとって何を意味するのか見てみましょう。
パターン：空の列 -最初に注目できること。 これは、チームにまだ人員が配置されていないことを意味します。スタートアップの場合、空席を空けるか、「家族、愚か者、友人」から誰かを探す必要があります。
スキルがまれで、めったに使用されない場合、パートタイムで誰かを見つけるか、契約サービスを使用する誘惑があります。 チームの外部の人々への依存は、期待、「私たち」と「彼ら」への分離、誰かの側のボールにつながる可能性があります。
リソースが本当に限られている場合、またはチームの常任メンバーを見つけることができない場合は、少なくともルールを順守してください 。 外部の専門家が単独で作業することはできません 。 少なくとも「半日」レベルでこの分野を習得したいチームのTパーソンを見つけて、関係する専門家と協力して仕事をするように彼に申し出てください。
ペア作業の2倍のコストに異議を申し立てる準備はできていますが、プロジェクトのリスクについては後述しますので、少し後で説明します。
パターン：半分以上で満たされた孤独な「太陽」 。 彼らは、私たちのチームに本当の「スター」があるという欺de的な自信を生み出します。 したがって、そのような人々を「バス要因」についてテストすることは有用です。
バスファクターは、プロジェクト内の何人の人がバスに乗ることができ、プロジェクトがまだ生きているかを示す楽しいプロジェクトの「メトリック」です。
孤独な太陽の星（および私が上で書いた外部の専門家と同様）は、バス要因の潜在的な「クライアント」です。 すべての資格にもかかわらず、プロジェクトが危険にさらされるには、熟練したヘッドハンティング、休暇、または出産で十分です。
どうする プロジェクトのこのスキルまたはスコープを習得したい人を決定し、いくつかのジョブを提供したり、タスクを切り替えたり、Tピープルを上げたりします。
パターン：半分の日陰の横にある単一の日陰ではありません。 結論は明らかです。私たちには、おそらく学びたいという願望を持つ二次的な専門家がいますが、内部メンターが不足しています。 何に悩まされていますか？ 疑わしい品質または不十分な速度。 解決策：内部トレーニング、外部トレーニングまたは企業トレーニング、クールな「太陽」の採用-から選択。
他にどのようにスキルマトリックスを使用できますか。
- 業務の途中で新しいチームメンバーを入力するとき
- プロジェクトの成長に伴い：チームを分割し、各サブコマンドに新しい人員を追加することが理にかなっている場合があります
- （ピボット）アイデアを転換し、新しいテクノロジーを接続するとき
たぶん、あなたはアプリケーションのための他のアイデアを持っていますか？
紙のアーティファクトがチームルームの壁にしばらく掛かっていると便利です。演習中の議論と一緒に、 グループのソーシャルメモリを作成します 。これは、チームの構築プロセスで非常に重要です。
後者については、次回の出版のためにアイデアとツールを収集する予定です。 もちろん、これは自然と企業関係者との共同の遠出についてのものではありません。 ピクニックやパーティーで作成されたチームビルディングは、残念ながらそこで終わると強く信じています。
ご清聴ありがとうございました。以下の質問やコメントにお答えします。