成功したチームを作成および管理する方法

皆様、またご挨拶！ 約束通り、私はITの管理について書き続けています。 前の記事で 、チームの新しいプレーヤーを見つけて採用することについて話しました。 しかし、彼らがどれほどクールで才能のある人々であっても、彼らはまだチームではありません。 サッカーとの類似点を描くことができます。スーパープレーヤーを購入してフィールドで放すことはできますが、彼らは戦術や戦略がないため、チームではなく、おそらく試合に負けます。



スマートスペシャリストのチームを雇ったときにビジネス上の問題を解決する方法は？

目標、目的、戦術

新しい従業員を雇用する前に、目標を明確に定義する必要があります。 新しいサービスを作成するには特定の技術が必要であり、それらには専門家の能力が必要です。 つまり、採用されたエンジニアの能力は課題に対処する必要があります。 潜在能力がタスクと大きく重複しているスペシャリストのスタッフを維持することは意味がありません。誰かが単にアイドル状態を保つことができます。



したがって、分析から始めて、すべての機能、コンピテンシー、および責任範囲を説明する作業計画を作成します。 これを行うために時間をかけて、いくつかのアイデアを得て行動してください。 私を信じて、今回は将来的に報われる以上のものです。

チームとそれらが効果的でない理由

チームとは何ですか？ 次の定義を定式化できます。共通の目標を達成するために、動機と関心によって結ばれた人々のグループ。 素晴らしく聞こえますが、実際には問題があります。

• 互いに理解し、同じ言語を話す能力。 私たちはすべて異なっており、すべてを異なって認識しています。これに耐えることしかできません。それがその人の働きです。 それぞれに独自の世界観があります。 Excelでテーブルからアンロードするなど、いくつかの機能をギャグするように要求しますが、出力は完全に間違っています。 そして、それは簡単な作業のように思えますが、途中で何かのナンセンスがあります。 誰もがさまざまな経験や考え方を持っていますが、他の人があなたと同じことを意味するという事実からはほど遠いです。 このトピックには面白いテストがあります。同僚に試してみてください。
• 話す能力。 通常の状況：難しいタスクが発生した場合、最適なソリューションを見つける必要があります。 同僚を集めて、解決策について話し合うことを提案します。 まあ、誰かが声を出しても、人々が提供するものが何もないことが起こります。 指示されたとおり、彼らは特定のタスクを待つだけです。 彼らは単に彼らがどのように助けることができるか理解していないか、見ていません。
• 動機と関心。 それらがTLおよびチームと一致することを確信していますか？ 機能を機能させ、期限内に完了するモチベーションがあります。 そして、チームメンバーは、新しい言語を導入するか、ここで機能が必要になるすべての場面でクールなアーキテクチャソリューションを作成したいと考えています。
• 聞いて聞いてください。 多くの場合、会議のエンジニアは、彼らが引き抜かれた理由を完全に理解しておらず、耳を傾けさえしません。
• プロセスへの関与。 プログラマは単に特定の問題を解決するだけですが、プロジェクト全体の最終的な意味を理解していません。 たとえば、ボタンを追加する必要がありますが、彼らは理由を理解せず、盲目的にコードを書いてチケットを閉じます。

結局のところ、これは彼らが何をして何をしているのか理解していない人々のグループであることがわかります。 どこかに移動するのが好きなので、降りてきます。 誰もが自分の動機と目標を持っています。 これはチームと呼ばれますが、実際にはそうではありません。



チームを作成し、その中にプロセスを確立する場合、最初に上記の問題に対処する必要があります。 もちろん、他の困難があなたを待っていますが、これらは最初に敗北しなければなりません。

人を団結させる方法

チームリーダーからCTOまでのリーダーの主なタスクは、すべての否定的で気を散らす要因の影響を最小限に抑え、チームの生産性を最大限に高めることです。



良いチームの重要なプロセスはコミュニケーションだと思います。 以下に、コミュニケーションを確立するための基本原則とヒントを示します。

• 各従業員と座ってチャットし、スキルと経験について尋ねます。 同僚の長所と短所を見つけてください。 あなたは、人々が仕事で彼らの強みを使用して、お互いを補完することをさらに確実にする必要があります。 これが最終的に最大の効率を達成する唯一の方法です。
• チームに仕事の目標をもたらします。 何らかの機能が実装されている場合、誰もが元の意味を理解する必要があります。 たとえば、品揃えを拡大して売上を増やし、ひいては会社の利益を上げるには、パートナーとの統合が必要です。 機能の究極の本質をチームに伝えて、人々が本当の目標を理解し、より喜んでタスクを完了するようにします。
• 誰もが理解できるように、すべてを簡単な言葉で説明してください。 アインシュタインが言ったように：「あなたがそれを簡単に説明できないなら、あなた自身は最後までそれを理解しません。」
• 議論に参加してもらう。 たとえば、営業部門に何らかの問題がある場合、チームにこれについてどう思うか尋ねることができます。 最初は誰も発言できませんが、最初の一歩を踏み出して会話を始めることを誰も気にしません。 チームを徐々に話し合います。 そして、すべてのエンジニアが自分の意見を聞いていることを理解することが重要です。 どういうわけか、社内システムを他の物流サービスと統合しました。 そして、彼らは快適だと思った。 しかし、顧客のためにロジスティクスを手配するために座ったとき、使用、データの送信、ステータスの表示などが不便であることに気づきました。 だから私たちは問題を特定しました、彼らは非常に夢中になって、あたかも彼らの痛みであるかのように問題を解決し始めました。
• 「間違い」という言葉を忘れてください。 エラーまたは失敗が新しいソリューションの検索であることを示します。 すべてのチームメンバーは、これが通常のワークフローであることを理解する必要があります。 何もしない人は間違っていません。 誰もが自転車に乗ることを学びました、誰かが倒れることなく乗ることができたとは思いません。
• ケースでのみ批判することを学ぶ。 すべてが悪いと言うことはできませんし、あなたの決定は良くありません。 特定の解決策がうまくいかない理由を否定せずに合理的に説明し、代替案を提案します。
• 同じ言語を話します。 タスクについて話し合い、概要を尋ねます。 優れた方法の1つは、問題の解決策とすべてをどのように理解したかについてエンジニアに尋ねることです。 あなたには多くの発見があるかもしれません：時々彼らが理解したことはあなたが言ったこととは非常に異なっています。 計画と完全に矛盾する完了したタスクの結果を発見するには、後で議論するよりも、時間をかけて議論するほうがよいでしょう。
• これを先取りして同僚に教える方法を知ってください。 これはエラーを指します。 スプリントの終わりではなく、人々自身が立ち上がってプロセスの困難や失敗について話し合うことが必要です。 特定のタスクを閉じるだけでなく、最適なソリューションを見つけることが重要であることを報告します。 将来的には、これはおそらく何かに影響を与えるでしょう。アーキテクチャの観点から重要です。 したがって、もっと時間がかかる場合でも、すぐに実行することをお勧めします。 各チームメンバーは、期限が切れているため、松葉杖を固執するのではなく、いくつかのステップを先読みする習慣を持つ必要があります。
• プライベートで仲間の幹部とではなく、チームとタスクについて話し合う。 第一に、それがプロセスに関与し、第二に、彼らはあなた自身が推測していない本当に良い解決策を提供することができます。 また、優れたプログラマーは、ロジックをコードに変換するものではなく、問題を完全に解決するものであることを忘れないでください。 プログラミングは部分的に創造性があるため、チームにそれを行う自由を与えます。 このようなアプローチは、何度も何度も真にエレガントで有能なソリューションを提供します。
• ヘルプルームを作成します。 従業員と話をして、仕事でどのような問題があり、何がうまくいき、何がうまくいかないのかを知ることができる場所が必要です。 その人の話を聞くことが重要であり、彼はこれを理解しています。 したがって、その作業の有効性の欠如の理由を特定することが可能です。 たとえば、彼のタスクが正しく設定されていない場合や、椅子が単純にバラバラになっている場合があります。 同僚と体系的にコミュニケーションを取り、チームの人生の脈動を把握してください。 そのため、競合状態を防ぎ、ワークフローをスムーズにできます。 誰もが静かにコーディングして、だれとも通信しない場合、チームには問題があります-通信はありません。
• ありがとうと言ってください。 人々が何かをうまくやっているなら、彼らに感謝するようにしてください。 このささいなことは非常に重要であり、あなたが感謝されれば誰もが喜んでいます。 しかし、虐待しないでください。さもなければ感謝はすぐに価値を失います。
• 会社の業績について話してください。 チームまたは特定の人々は、共通の原因に対する貢献を認識している必要があります。 プログラマーが他の部門から成功についてのフィードバックを得るのは素晴らしいことです。 たとえば、マーケティング担当者は、サイトが改良された後の売り上げの増加について話したり、マネージャーがその作業を加速したサービスの最適化について話したりできます。 これにより、チームの士気が高まります。 ときどきCTOまたはCEOでさえも、ランク付けされた従業員を集め、業績について報告するのは良い習慣です。

ご覧のとおり、ほとんどのヒントは何らかの形でコミュニケーションに関連しています。 最初からチーム内で適切に構築されていない場合、問題が発生します。 主にエンジニアの有効性を決定するのは彼女です。 私の経験を信じて、すぐにこれを行うのに時間と労力をかけないで、問題を解きほぐしたほうがいいです。

コントロールの微妙さ

どういうわけか、私は最適なチームサイズについての面白い理論を読みました。 ジョージミラーは記憶の研究に携わっており、実験の結果、5から9のインコヒーレントな要素が通常、短期的な人間の記憶に収まると結論付けることができました。 つまり、人は覚えやすくするために、いくつかの原則と特性に従ってそれらをグループ化する必要はありません。 トヨタの成功を繰り返したスクラムの父であるジェフ・サズランドは、チームの人数は7人以下である必要があると考えており、その結果、「1つのプロジェクトに7人」というルールが生まれました。 彼の意見では、そのようなチームだけが高生産性の効果を達成し、8倍の効果が得られます！



びっくりしましたが、これらの理論はうまくいきました。 12〜13人のチームが1つあり、それを2つに分割しました。見れば、生産性が著しく向上しました。 プログラマーのスタッフが増えたため、6人で構成される3番目のチームを作成しました。



以下では、チームの管理に関するアドバイスをします。それらは新しいものではありませんが、当時私を大いに助けてくれました。そして、私自身が実際に彼らの有用性を確信しました。

• チームを結合して、成長する場所を確保します。 私の初期の間違いの1つは、同僚をレベルごとに2つのチームに分割することでした。1つは強力なプログラマーを集め、もう1つは経験の浅いチームです。 シャッフルした後、生産性が向上しました。 そして、誰もがより集中的に開発を始めました。新参者は技術的な経験を積み、強力なエンジニアはメンターとして自分自身を試しました。
• タスクを正しく配布する方法を学びます。 プログラマーは会社にとって大切な従業員です。 彼の前には常に挑戦がなければなりません。 彼がすぐに解決できるよりも少し複雑になりましょう。 これは彼の成長に役立ちます。 経験豊富なシニアは、初心者のスペシャリストよりも速く作業を行ったとしても、簡単なタスクの上に座ってはいけません。 顕微鏡で釘を打ちつけないでください！ もちろん、必要な難易度のタスクを選択するのは難しいので、バランスを保ち、通常のタスクと組み合わせてください。
• 従業員の動機付けを正しく行います。 ここでは個別のアプローチが必要です。一方はお金で、もう一方はキャリアの成長です。3番目はスーパープロフェッショナルになりたいので、誰もがアドバイスを求めて彼に来ます。 つまり、本当に必要なものを提供します。 これは、当局から上から発行される何らかの種類の命令よりも長く効率的に機能します。 さらに、会社と従業員が必要とするものの間のバランスを維持するのが簡単です。
• 快適な勤務スケジュール。 私は長い間、柔軟なスケジュールのために当局と苦労していましたが、最終的には数字で彼の優位性を証明しました。 プレゼンスの時間についてはチームと合意しましたが、必要に応じて誰もが都合の良い時間にビジネスに行くことができます。
• すべてのステップを制御しようとしないでください。 人々は自分の責任を意識しなければなりません。 これを理解している人は、はるかに効率的で自立しています。
• トレーニングを節約しないでください。 会議、ワークショップ、その他のイベントに同僚を送ります。 高い？ お茶とピザを用意したカジュアルな雰囲気の中で自分でアレンジしてください。 人々が経験を共有したり、新しいアプローチについて話し合ったり、いくつかの難しい問題を一緒に解決したりできます。
• 運転せずに運転。 私の意見では、これは曲技飛行です。 直接指示を出すのは簡単ですが、チームのすべてのステップを制御するチームリードはどれくらいの間続きますか？ 優れたチームでは、ヘッドは他の部門と同じ部門の従業員です。 特定のタスクについてではなく、会社の発展について考えているのは彼だけです。 時々、彼は問題や仕事の新しい方向性を報告し、残りはそれを急襲して決定します。 私の意見では、これは最も効果的な管理アプローチであり、これのためだけに、優れたチームが既に構築され、その中のすべてのプロセスがデバッグされるべきです。

驚くべきが真実

ある時点で、押しているカートは自力で移動する必要があります。 優れたチームでは、問題が発生したとき、または新しい機能を設計するときに、人々は座って考えられる解決策について話し合い、独自のオプションを提供する必要があります。 理想的には、彼らはあなたなしで何でもできる。







実際のチームでは、従業員はより責任を持ち、目標と目的、および開発の一般的な方向をよく理解しています。 それはボートのrowぎ手のようなもので、彼らは同期運動を行い、ボートを勝利に押し上げます。 そして、彼ら自身が何かを改善または最適化する方法についての彼らのアイデアであなたに来始めます。 彼らは問題自体を見るようになり、さらに、問題を自分で解決したいと思うようになります。 このような雰囲気の中で、以前は誰も受けたがらなかった日常業務に対する態度が変わり、熱意と品質で解決されます。



休暇に行って、そこから同僚に手紙を書いて仕事について尋ねましたが、彼らはそれを振り切って、休んで仕事について考えないように忠告しました。 私の到着後、最大の発見が待ち受けていました。以前と同様、仕事は本格的で、タスクは時間通りに配信され、発生したすべての問題は参加せずに同僚によって解決されました。 その時、私はこれが本当のチームであることに気づきました。

結論

非常に効果的なチームとは、ミスから学び、成長し、これらのエラーをすばやく修正または予測する方法を知っているチームです。 その中で、誰もがお互いを聞いて聞いて、常に救助に来ます。 チームは、成長している生物のようなものです。 良い解決策はありますが、あまり良い解決策はありませんが、チーム全体がそれらに移行して絶えず何かを改善する場合、それぞれが個別に努力します。



作成する機能の目的を理解している人は、よりやる気があり、他の人には見られない問題の解決策を提供する場合があります。



チームで開発プロセスを構築し、コミュニケーションに最大限の注意を払ってください。 チームリーダーは時間の10〜20％をエンコードするのに十分であり、それ以外はすべてプロセスと人であると信じています。



人々はあなたの最も重要な資源であり、あなたが彼らがあなたに関連するようにしたい方法で彼らを扱ってください。 彼らが成長し成長するための条件を作ります。



私はゼロから構築した会社を辞めました。6か月以上、すべてがそこで動き、発展し、利益が成長しています。 彼は明確な良心を持って去りました。その時、私はすでにすべてが会社で正しく行われ、構築されていることを理解していました。 つまり、少数のエンジニアが、それぞれが専門家として成長した、本格的で独立したチームに成長することができました。 仕事は本格的で、ビジネスは発展していますが、これはアプローチの有効性の最良の証拠ではありませんか？ そして、疑問が生じるかもしれません：「なぜあなたはマネージャーが必要なのですか？」そのような効果的なチームを構築するために。



ご清聴ありがとうございました！ 次の記事では、新しい従業員をチームに導入することのニュアンスについて説明します。



私の他のIT管理記事：

チームリーダーとは

ゼロからのドリームチーム：ITプロフェッショナルの採用

新入社員-デッドオアアライブ

成長、チームリーダー、大小