ソフトウェア開発はチームワークです。 それにもかかわらず、専門文献は、技術よりもチーム構築の問題にあまり注意を向けません。
プロジェクトマネージャーは、知識とプロジェクト管理という2種類の方法論を認識しています。 人材管理の方法論はまだ発明されていません。 管理ブックは、従業員を1つのチームにするために何をすべきかよりも、従業員を管理する際に許可されてはならないことを教える傾向があります。 以前、私の同僚はこのトピックに関する記事を書きました。 これにより、この問題に対する私のビジョンを説明することになりました。
プロジェクトマネージャーは、チーム教育に関するアドバイスを求めて心理学の文献を参照することがあります。 しかし、実際には、心理学者は対人関係の一般的な問題に関する本を書いています。 相互扶助の発展とそれらのイニシアチブの発現の数の増加のトピックは、はるかに少ない頻度で触れられています。 私の記憶では、この問題は同僚の記事で検討されました。
おそらく、チームビルディングに関するアドバイスについては、集団活動のより研究された他の領域に目を向けることは理にかなっています。 たとえば、劇場へ。
なぜ彼に？ 少なくとも類似性のため。 劇場はまた、全く異なる活動分野を組み合わせています。 それにもかかわらず、ステージでは、すべてが単一の有機体として機能します。 おそらく、劇場には、さまざまな人々が共通の結果のために働くことを可能にする多くのツールがあるからです。
それらのいくつかを考えてみましょう：
- テーブル期間;
- スーパータスク。
- アクターの役割。
- 「抵抗」の役割。
- ロール描画;
- ステージングエリアの建設。
テーブル期間
残念ながら、これは楽しいごちそうではありません。 テーブル期間では、資料の読み取りが行われる期間を理解するのが慣習です。 ステージでのリハーサルの前に、俳優はテーブルでロールのテキストを発音します。 イントネーションなしで、何も演奏しません。 これはテキストの暗記ではなく、プロットに精通しているわけでもありません。 俳優はテキストの内側のドラマツルギーを明らかにし、スクリプトの余白にメモを作成します。 この段階で、劇の回転イベントが決定されます。
マネージャーにとって、転換イベントはプロジェクトのマイルストーンです。 開発者をプロジェクト計画に関与させます。 最初の段階では、技術のすべてのニュアンスを決定する必要はありません。方向を概説し、潜在的なリスクを特定すれば十分です。 開発者は、プロジェクトの詳細について専門家の意見を考え、表現することを学びます。
スーパータスク
スーパータスクは、作品の主要なアイデアを個別に解釈するものです。 それが書かれた目的。 監督は俳優にスーパータスクを指示します。
マネージャーのスーパータスクは何ですか？ プロジェクトは時間通りに行われますか？ いいえ、プロジェクトの進行を管理することはマネージャーの仕事です。 目標は常に仕事の外にあります。 この質問は、フレデリックブルックスの著書「Mythical Man-Month」で最もよく答えられました。
「プログラムプロジェクトマネージャーの主なタスクは、創造性とイニシアチブを圧倒するのではなく、促進する組織構造とワークフローを作成することです。」
開発者のスーパータスクとは何ですか？ 機能を効率的かつ時間通りに開発するには？ いいえ、これは彼の仕事です。 開発者の目標は次のとおりです。
- 彼のために新しい技術を習得する。
- プロジェクトアーキテクトになりたい。
- 初心者を訓練したいなど。
開発者がスーパータスクを持っていない状況は失敗です。 彼は時間を提供するためだけに働くようになります。
俳優の役割
アクターの役割は、アクターの外部および内部データに対応する特定の種類の役割です。 簡単に言えば、コメディアンの俳優、悲劇的な俳優がいます。
各開発者の荷物を知ることは、チームを募集するプロセスの重要な要素です。 内面の自己を満たす人々のプロジェクトを提供します。 労働条件に関する人々の不満の中には、「私には当てはまらない一連の職務を遂行した」というものがあります。 これは露骨なことです。 水泳のスポーツの達人がバーベルを持ち上げなければならないという事実に相当します。
「抵抗」の役割
「抵抗」の役割は、アクターの役割に明確に対応しない役割です。 もしそうなら、それはそれがそれ自身の「快適ゾーン」を越えて行くことができることを意味します。 それが壊れている場合、それは監督が役割のために誤って俳優を選択し、間違った仕事に彼を置くことを意味します。
開発者が取り組んでいるプロジェクトに対する開発者の関心の重要性を過大評価することは困難です。 そのため、マネージャーは開発者プロジェクトに「成長のため」を提供する必要がある場合があります。 この意味で、設計のすばらしさと開発者の能力を関連付けることができる必要があります。 知識と可能性のバランスを見つけてください。
役割の描画
ロール図とは、俳優が行動する範囲、タスクから退却する範囲、またはタスクを超える範囲です。 リハーサル中、監督は、俳優がテキストを送信する行、テンポ、動作、スクワットまたはリプレイを明確に修正します。
マネージャーは部下に間違いを犯す権利を与えると同時に、期待を超える能力を認めるべきです。 開発者が最悪の形態であってもプロジェクトを圧倒できないような条件をチーム内に作成します。 俳優にとって、そのような条件は虚偽の不寛容を意味します。 この方法で訓練された俳優は、彼が見ている映画やパフォーマンスのリプレイを正確に決定します。 悪いコードに対する開発者の不耐性を開発します。
ステージプロダクション
ステージングシーンの構築は、シーンとそのシーンの俳優を条件付きで分割して、最初の計画、中間の計画、および遠い計画にします。 舞台シーンは瞬間的です。 どのように変化するかによって、パフォーマンスを見ることがどれだけ面白いかが決まります。
各マネージャーは、少なくとも一度は開発者から「プロジェクトを自分で引きました」というフレーズを聞きました。 リーダーは他のチームメンバーのサポートを感じませんでした。 人々は一緒に働きませんでした。 それぞれが独自のジュースで醸造されました。 システムは新しい機能を獲得していません。 マネージャーは次のことを行う必要があります。従業員をいつ最前線から連れ去るべきかを感じます。 どのチームメンバーが友人の肩を代用するかを理解する。 経験豊富な従業員でさえ、プロジェクトだけを引き受けることはありません。 彼は破れます。
it-team
チームキラー
プロジェクトは一種のパフォーマンスです。 一部のプロダクションは、観客の心に何年も住んでいます。 いくつかのヒット後に失敗するものもあります。 一般的な信念に反して、遊びは主なものではありません。 主なことは、チームが結果に対してどのように調和して働くかです。
it-teamの作業にリストされたツールのいずれかが存在しないことは重要ではありません。 すべての不在-プロジェクトを失敗に導くことが保証されています。 チームをやる気にさせる新しい方法を考える前に、チームがこれらのテクニックを使用しているかどうかを確認してください。 使用しない場合、これは単に考えるだけでなく、アラームを鳴らすための機会です。
上記を要約します。
- 開発者をプロジェクト計画に関与させます。
- 明確に目標を設定します。
- チームメンバーの長所と短所を調べて、開発できる場所と開発すべき場所を把握します。
- 悪いコードのボイコットを宣言します。
- リーダーに引き裂く機会を与えないでください、しかし、平均的な専門家に彼自身を証明する機会を与えてください。
もちろん、この記事では舞台裏舞台の秘密の完全なリストを提供していません。 この記事の目的は、他の業界の代表者から学ぶことが可能であり、必要であることを示すことでした。 時々、なじみのない地域を研究することで、驚くべき発見をすることができます。
結論として、私は付け加える：しばしば劇場に行く。 そこで、少なくとも電話をオフにして昼寝をすることができます。