マネージャーにはないかもしれない3つの重要なスキル 、
プロジェクトは予定どおりに予算内で正常に終了します。
- 方法論
通常、彼らはプロジェクトを可能な限り効率的にするアクションのシーケンスを記述します：時間通りに、顧客が必要とする機能で、そして最小限の身体の動きで。 通常、内部にはアジャイルマニフェストやリーンプラクティスなどのイデオロギー層があります。 方法論は、顧客とのコミュニケーションや計画のルールに影響を与えずにコードを効果的に作成する方法のみを説明する極端なプログラミングなど、プロセスの一部のみを対象とする場合があります。 いずれにせよ、これは非常に長く、理解可能なアルゴリズムではなく、目標を達成する方法です。
私自身も大好きです。
- サービスに関するタスクの処理を計画するためのかんばんボード（ところで、Trelloはこのための魅力的なツールです）。
- 開発プロジェクトのスクラム。
- 顧客との仕事を構造化し、プロジェクトの資金を調達したプリンス2。
すべての方法論はオプションだと思います。 主なことは、あなたに合ったものを選ぶことです。 - フレームワーク
何も忘れずにプロジェクトを可能な限り正確にする方法についてのまったく異なる話。 通常、これは大きなタルムードであり、プロジェクトで考えられるおよび考えられないすべてのプロセスの説明が含まれます。 前の段落と比較すると、これは短いアルゴリズムではなく、プロジェクトを実施するために開始する必要があるすべてのプロセス、成果物、および承認の包括的な説明です。
何についてどのようなフレームワークを簡単に教えてください。
CMMIとPMBokは、開発プロジェクト管理プロセスの概要を示しています。 CMMIには、組織の成熟度レベルの説明が含まれています：プロセスが設定されておらず、結果を再現できない未熟なものから、すべての動きが記録され、すべてのプロジェクトが、説明されたプロセスと前任者が学んだ教訓に基づいて作成される非常に成熟したものまで。
ITSMとCOBITは、サービスの構築に必要なプロセスをカバーします。最初のプロセスはプロセスを実行する人の観点から、2番目は監査人の観点からです。
TOGAF-会社の管理に必要なプロセスについて。
通常、そのような言語で書かれているため、知識豊富な専門家のひどい苦痛と全社規模での深刻なコストなしに、それを読んで実装することは非常に困難です。 - 技術スキル
プロジェクトの評価、アーキテクチャ、コーディング、テスト。 これがどのように行われるか、資格のあるマネージャーが理解する必要があります。 しかし、プロジェクトのアーキテクチャを他の誰よりもコーディング、テスト、発明することは不可能かもしれません。主なことは、有能な技術専門家を選択することです：プロジェクトアーキテクト、プロジェクトテスター、これをうまく行えるアナリスト。
実際、もちろん、有能なITマネージャーが3つのトピックすべてを理解することは良いことです。 しかし、経営に着手し始めたばかりの人々には、彼らから始めないことをお勧めします。
特別な方法論が適用されていないにもかかわらず、成功裏に完了したプロジェクトに参加しましたが、その時点ではフレームワークについて誰も聞いていませんでした。 私は、クールなマネージャーが言語大学の卒業生であり、技術的なバックグラウンドがないチームを知っていました。 一方、私は、SCRUMとPMBoKの素晴らしい使用の例になるはずの、優れた知識と経験を持つ専門家のプロジェクトがどのように失敗するかを見ました。 これは、技術文献はもちろんのこと、方法論やフレームワークでは見られないより深いスキルがあることを意味します。
それらについてさらに説明します。
プロジェクトマネージャーが持つべき3つの非常に重要なスキル 、
そうしないと、デバッグされたプロセスと高度な技術にもかかわらず、プロジェクトですべてが悪くなります
実際、プロジェクトのマネージャーは同じプロセスのチューナーです。
- 仕事を得て、分析し、計画します。
- 人を集めて整理します。
- 時間通りに、適切な品質で作業を確認してください。
- 仕事を引き渡します。
上記で説明したことは、チームリーダーがこれらの4つのポイントが技術的に正しいことを確認するために選択する方法とベストプラクティスについて考えることだけです。
ただし、これらの4つのポイント内のどこかに、非直線性を持つすべての人（顧客、従業員、隣接部門のメンバー）がいるため、ジョブを完全に正しく実行しても、プロジェクトを簡単に台無しにできます。
人と仕事をする場合、より細かい設定が必要になりますが、一見するとそれほど重要ではありません。 これは：
- 信頼関係の構成
- タスクのステートメント。
- やる気を引き出す能力。
それらをさらに詳しく見てみましょう。
- 信頼関係
それらは何に基づいていますか？ 実際、予測可能性と信頼性のみに依存しています。 月曜日にレポートを送信すると約束したとしましょう。 そして、送信しませんでした。 その後、あなたの約束を信頼できますか？ ほとんどない。
または、マネージャーとして、あなたは集会に遅れたすべての人に制裁を課すことを約束しました。 しかし、ヴァシャが集会に遅れるとき、あなたは罰を導入することなく、彼を優しく口説きます。 部下はあなたの言うことを信じますか？ 再び、ありそうもない。
私を信頼するのは、マネージャーがすべての人にとって良いことや、すべての人を信頼することではありません。 彼らは個人的な責任についてのものであり、人々は自分自身に関連して約束されたものを満たすために必要とされる必要があることを：
- 従業員から-給与とボーナスを期限内に支払うため、期限内にリリースし、期限内にレポートを送信します。
- 顧客から-あなたの手紙に応答し、時間通りに決定を下します。
- 自分から-約束を守ります。
プロジェクトでは、このような関係は、明確に定義された作業ルールも意味します。 私は官僚制度について話しているのではありません。 たとえば、 当社のチームがチケットを扱う場合、従業員と顧客がオープンで理解できるチケットを扱うための指示が必要です。 それなしでは働けないからではなく、すべての当事者間の合意が透明でなければならないからです。
そして、その日、動揺しているクライアントが従業員に時間通りにチケットを閉じなかったとscりに来ると、指示を開き、「私たちは言葉に責任があり、チケットは例えば2日間閉じられました。 私たちの指示に従って2日間-これは時間通りです。 あなたは幸せではないようです。 2日間が多い場合の手順について説明しましょう。」 現時点では、不思議なことに、クライアントは幸せになります。彼は、状況を制御できること、契約を作成して修正することで十分だと考えています。
誰と信頼すべきですか？ 例として部下とクライアントを引用しました。 ただし、上司と同僚の両方が、あなたが信頼できる言葉を持つ人としてあなたを知っている必要があります。
これは何のためですか？
- ボスの側であなたの仕事に信頼がある場合 、遅かれ早かれ責任を追加します。 私はキャリアの成長について話している。
- あなたと顧客の間に信頼がある場合 、プロジェクトは成長します。これは、チームと会社のあなたの体重が増加することを意味します。
- チームに信頼がある場合、あなたは彼女と協力し、彼女に代わって約束し、約束をするだけです 。これは再び顧客と経営者の喜びにつながります。
- 近隣のマネージャーからの信頼がある場合は 、会社での取り組みが機能し、要求に応えます。
- タスク設定
目標を設定するための基本的なルールは次のとおりです。
- スマートによって。 長い議論は必要ありません。理論は何年も前のものだと思います。
- あなたの前にいる人に応じて、プロセスまたは結果によって：初心者または実績のあるショット。 初心者がその方法を段階的に説明するプロセス。 その結果、何をすべきかを概説するだけで十分であり、専門家に技術的な詳細を委ねています。 いずれにせよ、コースとの調整ポイントを特定することは、場違いではありません。すべてが計画通りに進んでいることを理解するために、会う日です。
- 対談者の言語で。 各人には、自分の精神的プロセスを非常に明確に反映したお気に入りの単語セットがあります。 プロジェクトについて話している人は、共通の目標に向かってどのように進んだか（プロセス）について色で話し、誰かが達成したこと（結果）を書き留めます。 誰かがクールなチームに集中し、誰かがテクノロジーよりも重要です。 一部の人は常に「ウォッチ！」を繰り返しますが、他の人はしばしば「リッスン！」を使用します。 あなたが彼の言葉を使うと、人があなたを理解するのは本当に簡単です。
- 理解を再確認してください。 残念ながら、あなたが言ったことと人が理解したことは2つの大きな違いです。 重要なタスクまたは大量のタスクのルールは、聞いた内容をもう一度伝えるように依頼するか、タスクを説明する手紙を送ってもらうことです。 その後、彼が何かを誤解した場合は、すぐに修正する機会があります。
- 結果を受け入れます。 それは明らかなことのように思えますが、彼らはあなたのためにタスクを設定し、それから彼らはそれを受け入れることを忘れているようです。 上司がそれを簡単に忘れることができるほど重要ではない何かをすることは、これまで以上に悪化します。 ですから、忘れないことが重要です。
人がタスクを完了したいという欲求を持つためには、このタスクが彼にとって関心のあるものであることを確認する必要があります。 チームの誰が、どこで、どこで成長しているのかを理解して、どのようなタスクが彼に興味を持っているかを知ることが不可欠です。 そしてもちろん、同じアイデアを非常に異なる方法で提出することができます。それは次の点に私たちを連れて行きます。それなしでは、チームで働くとき、どこにも動機がありません。 - やる気を起こさせる能力
動機付けのテーマはファッショナブルで誇張されており、ネットワーク上でStratoplanとGandapasで十分なコースを見つけることができます。 多くの本が動機について書かれています。 私のお気に入りは以下のリストにあります。
私の意見では、モチベーションは販売と非常によく似ていますが、奇妙なことに聞こえます。 ほとんどの人は何かのために努力します。 人が何かのために努力しない場合、それは彼を杖で突く価値があります-突然彼は死にました。 彼が死んでおらず、深く落ち込んでおらず、精神的にも健康でなければ、彼は人生から何かを望んでいます。 セールスの場合のように、あなたの仕事は、人と話をして、彼のニーズと願望を見つけ、あなたの「製品」（プロジェクト、タスク）がこれらのニーズを閉じて最終的に「販売」する方法を理解することです。 つまり、彼に喜びと善をもって行う仕事を与えてください。 または、この「クライアント」の「製品」が現在ないことを理解して、手放します。
優れた販売員のように、優れたマネージャーは、長く流に話すことよりも、聞くことと聞くことを知っている人である可能性が高くなります。 私にとって、動機付けを行うための主要なツールの1つは四半期ごとの会話で、これについては以前に記事を書きました 。
上記のスキルは次から次へと流れていることがわかります。 そしてもちろん、これは彼らの完全な範囲ではありません。 また、リーダーになったり、交渉したり、正しく意思決定したり、競合を解決したりする必要があります。これはすべて、マネージャーが年をとるにつれて起こります。 私の意見では、最も必要な3つを選択しました。
この記事は、方法論やプロセスフレームワークを知る必要性についてのものではありません。 人々を管理したい場合に知っておくべきこと、そして専門のITマネージャーになりたい場合に知っておくべきことについてです。
動機に関する文献 ：
- パンクラトフに栄光を。 ブラックブックマネージャー。
- 猫の放牧方法。 他のプログラマーを監督するプログラマー向けのガイド。
- リー・ヤッコカ。 キャリアマネージャー。
投稿者： Fkleto4ku