これを行うには多くのオプションがあります。 私のケースで機能したアプローチの1つについてお話ししたいと思います。 その結果、ジャムと相互対立の数、リーダーと部下はずっと少なくなりました。
パート1.背景「チェスのプレイ方法とチェッカーのプレイ方法」
別のITプロジェクトに加えて、定期的な作業（標準的なマトリックス管理構造）がありました。
プロジェクト自体、使用されているテクノロジーに多くの不確実性があり、最終的にプロジェクトの最終結果も数回変化しました。 顧客側の巨大な官僚機構は楽観的な見方をしませんでした。 サプライヤーからの特別な喜びを提供します。 さて、Her下-政治はプロジェクトの問題の階層を冠しました。ここには奇妙な解決策と、「ボーイッシュな」アレンジメントのさまざまなスキームなどがあります。 一般的に、このような普通のプロジェクト。
しかし、これは最も不快ではありませんでした。 スタッフに何か問題がありました。 この作曲では、仕事中に何らかの方法でそれらの1つに出会ったが、私たちが初めて働いたことに注意する必要があります。 チームはすべて選択です。頭が良くて有能な人です。 しかし、イニシアチブを取り、責任を負い、決断を下す必要があったとしても、それが最も小さなものであったとしても、これはある種の壮大なフェイロフにつながりました。
私の最初の反応は次のとおりです。 間違いはより寛容である必要があり、これは実際に-経験と成熟度の蓄積です。」 私はバランスの取れたアプローチを誇りに思っていました-本当のベテランのマネージャーです。
私はそれぞれの従業員とそれぞれの柱の事実について話し、彼に尋ねました：「あなたは今何を学びましたか？」 そして、会話の後、彼は肩を軽くたたきました。 間違ったことを理解することが重要です。 次回、これは起こりません。」
ミスやミスの数が減ったと思いますか？ まったくありません。 彼らは私が想像することができなかったそれらの場所でさえ起こりました。 私は当時、経営理論に生きる自己陶酔的な愚か者でした。
プロジェクトの途中までに、私はすでにプロジェクト管理の分野で非常に理論的に精通した人でした（私はいくつかのコースを経てPMPを取得しました）。 科学的なアプローチが必要です！ これは何かをするための私の2回目の試みでした。
作業スケジュールを守り、ネットワーク図を作成し、チームとリスクについて話し合い、それらを念頭に置いて作業を計画しました。 私は期待を管理し、利害関係者（利害関係者）と連絡を取り、チーム内でプロジェクトの合同会議と議論を開催しました。 しかし、地獄、私のチームは私に対して働きました。
私の次の反応は罰金制度の導入でした。 数回の罰金とcouple責の後、スタッフのモチベーションは急激に低下しましたが、基本的に問題は消えませんでした。 罰則は、明確に定義されたルールの場合に適用されます。これを行う必要があります。そうしないと、傷つきます。
「ハードウェアを使い果たしました。どこで入手できますか？」、「ここでエラーが発生しましたが、さらに作業することは重要ではありません。 開発者に電話する必要がありますか？」 誰も同意なしに単一の追加ステップを取りたくありませんでした。
次に、試行番号3がありました。 私は仕事の説明を確認し、主要なビジネスプロセスを説明し、すべてのニュアンスを詳細に考慮することにしました。 結果は論理的です-詳細にdrれました。
私はついにエルバートハバードの物語「ガルシア将軍へのメッセージ」で終わりました。 短い話は文字通り数ページです。 その後、ネタバレがあります...ストーリーを自分で読むことを強くお勧めします。
一言で言えば、コンテンツ
戦争があります。 反政府勢力のリーダーにメッセージを伝える必要があります。 彼がどこにいる-誰も知らない。 彼を見つける方法も不明です。 彼らはナナカマドという名前の単純な男に電話をかけ、彼に手紙を渡しました。これは最終的な宛先であるガルシア将軍だけを示しています。 ナナカマドは手紙を受け取り、胸のポーチに封印し、ジャングルの中に姿を消した。 3週間後、彼はガルシア将軍に手紙を届けた。 彼がどのようにそれをし、ガルシアに手紙を届けたのかは謎です。 しかし、彼はあまり多くの質問をすることなく、余分なリソースを求めることなく、何も不満を言うことなく、これを行いました-彼は単にそれを取ってそれをしました。
私は頭の中ですべてのスタッフを調べました...誰も手紙を届けることができませんでした。 最終結果だけを言うことができる人はいませんでした、そして、彼はそれを達成したでしょう。
いつアイデアを得たのか覚えていません。ゲームのルールを策定する必要があります。 つまり、関係の初期座標、リーダー-従属を設定する必要があります。 不十分な情報に直面して決定を下したり、タスクを完了したりする必要がある場合に信頼できるもの。
対立の本質は、当事者のさまざまな期待です。 私にとって正常だったことは、従業員にとっては完全に異常でした。 一般的なルール、共通の基盤が必要でした。
私の意見では、すべての従業員が従うべきいくつかの重要な原則を策定しました。 これらは私の側の暗黙の期待です。 私はすべての従業員にドラフトを送りました。 私たちはそれらを数回共同で書きました。 そのため、この文書では、従業員の相互関係と私に対する暗黙の期待のように見えました。
コラボレーションの最終バージョンは、2つのドキュメントでした。
- 「管理の原則」
- ブランド標準
最初のドキュメントでは、会社の仕事の基本原則、つまり誰が、どのように、いつ、何をすべきかについて説明しています。 これらはすべての会社の従業員の一般原則です。
2番目の文書は、情報が不十分な場合のふるまいと意思決定の一般的な基準-不確実性の解決策について説明しています。 このドキュメントの注釈には、次のテキストが記載されています。
「作業中に、指示に記載されていない決定を行う必要がある場合、困難な状況に遭遇する可能性があります。 会社は、あなたがそのような状況で行動し、以下に示す企業基準に従うことを期待しています。 「これらは当社のあらゆるものに追随し、当社の企業文化の基盤を形成しているため、企業標準と呼ばれています。」
ここでは、「管理の原則」のみを示します。 記事の量はすでに大きくなっています。 興味があれば、次の記事で会社の標準について説明します。
パート2.管理原則
リトリート：
- 私は正直に以下の原則のいくつかをコピーしました、いくつかは私のスタッフによって書かれました、いくつかは私によって書かれました。 どこから来たのか覚えていません。 あなたの考えを見つけたら、私は下のリンクを置くことを教えてください。
- 当時、私たちはプロジェクトとタスクの管理に専用のITシステムを使用していました。その名前をXXXに置き換えました
原則1：透明性。
- 誰もが彼に結果が期待されるときに彼がしなければならないことを知っている必要があります。
- 誰が何に責任を持ち、誰がプロセスを遅くしているのかを知る必要があります。
- 誰でも、どんなタスク、誰、何、いつ完了したかに関する作業の進捗状況を見ることができます。
この透明性は、特殊なシステムXXXの使用により達成されます
原則2：すべてを1か所で
作業に関するすべての連絡は、 XXXのみを経由する必要があります。 会議、電話での会話、Lyncのコミュニケーション、およびICQ担当者の結果は、 XXXで達成されたすべての合意を作成する必要があります。
そのような責任者は誰ですか？ それが明らかに話すことができない場合、指示を与える人。
結論1：タスクがXXXに設定されていない場合は、省略できます。 これには何の影響もありません。 （緊急事態や事故を除く）
結論2：タスクがXXXで完了としてマークされていない場合、完了していないと見なされます。
原則3.仕事を始める前に、受け取ったタスクを分析する必要があります。
タスクを受け取ったら、請負業者はそれを分析する必要があります。 分析の目的は、自身のリソースの十分性を評価することです。すなわち、
- 理解とは、目標と実行方法の両方の観点から、タスク自体の明確さを評価することです。 さらに、他のパラメーター、用語、品質要件、優先度を考慮する必要があります。
- 資格-必要なパラメーターを考慮してタスクを完了するために必要な自分の知識とスキルの評価
- 情報-必要なパラメーターを考慮した、タスクの完全性の評価
- 時間-必要な時間内にタスクを完了する可能性の評価。以前に受け取ったタスクの残りの義務、日常業務を考慮します。
- 権限-割り当てに対する権限の妥当性の評価（既存の権限と割り当てとともに与えられる権限の比較）
原則4.受け取ったタスクは100％完了している必要があります。
作業は2つの部分に分かれています。割り当てのすべての義務と条件を考慮して完了し、完了していません。 言い換えれば、結果があるかどうかのどちらかです。
原則5。タスクの100％完了の障害は、リーダーとすべての関係者に直ちに報告する必要があります。
本当の干渉、自己疑念、新しい情報の受信、およびあなたの意見では何らかの方法でタスクを変更するすべての形で障害が発生した場合、すぐに頭に通知する必要があります。
原則6.問題を解決するための提案は、その発生に関する情報よりも望ましい。
理想的なオプションは、問題に対する保証されたソリューションを提供することです。 そのようなものがない場合、可能な解決策の提案は受け入れられます。
原則7.割り当ての拡張解釈は許可されていません。
受け取ったばかりのタスクを分析するときは、タスクを完了するための用語、要件、条件を検討する必要があります。 課題を完了する過程で、彼らに有利に生じた状況を解釈することは許可されません。
例：職場にマネージャーが不在でも、現時点でスケジュールされたレポートの提出はキャンセルされません。
原則8。タスクのパラメーターまたは実行ルールとの不一致は、それらを無視する理由にはなりません。
受信したタスクのパラメーターに同意しない場合は、それらについて議論できます
- 受信したタスクを分析するとき
- 仕事を100％終わらせることができないときに状況が発生した場合
原則9.意見よりも望ましい事実と議論
従業員の意見は非常に重要ですが、感情に加えて事実に裏付けられている方が良いです。
原則10.あなたの使命はあなたの使命にすぎません。
請負業者は、受け取ったタスクを完了する責任があります。 タスクを完了する過程で、彼が助け、情報、他の人との相互作用を必要とする場合-これは、彼が時間通りに完了したタスクに対する責任を軽減しません。
原則11. XXXシステムのプロジェクトに関する体系的な作業
各プロジェクトには以下が必要です。
- タイトル-プロジェクトの本質または結果
- プロジェクトの本質。 プロジェクトの目的は何ですか？ 短い説明：プロジェクトの目的、結果はどうあるべきか。
- カウンターパーティ プロジェクトが実装される組織。 そのような取引相手がいない場合は、追加する必要があります
- プロジェクトの作成者である彼は、プロジェクトの結果の責任者でもあります。
- プロジェクトのステータス。 このプロジェクトで完了する必要があるアクティブなタスクがある場合、プロジェクトはアクティブであると見なされます。 （タスクは、期限があるどこかでアクティブであると見なされるか、現在の月の最終日までに完了する必要があります）
- プロジェクト終了日
- プロジェクト監査員-プロジェクトの結果の責任者の責任者。
- プロジェクトのエグゼキューター。 後でタスクを割り当てるときに追加できます。
原則12.適切なプロジェクト計画
必須ルール：各プロジェクトにはタスクが必要です。 タスクの総数は、完了後にプロジェクトの結果が達成されるようなものでなければなりません。 プロジェクトにタスクがないか、今月実行されていない場合、またはその実装の責任者が機能しない場合。
プロジェクト全体はタスクに分割されます。 タスクとは、1人の人間または
1営業日以内に。
タスクの名前は必ず動詞で始まります：「作成、送信、受信、計画、実行など」
各タスクには次のものがあります。
- タスクマネージャー。
- タスクのエグゼキューターは、いくつかある場合があります。
- 何をする必要があるかについての簡単な説明。
- タスク完了日
さらに、以下を使用できます。
- ファイル
- チェックシート
- 通知/繰り返しタスク
- 分析
- メモ/その他の情報源
原則13.緊急のタスクと割り当ての声明
緊急事態、緊急の注文の場合、携帯電話または固定電話でタスクを設定できます。 この場合、タスクが当日以内に完了した場合、請負業者は電話またはSMSで注文の実行について通知します。 通知が来なかった場合、タスクは完了していないと見なされます。
タスクにさらに時間がかかる場合は、 XXXシステムで修正する必要があります。 これが明示的に記載されていない場合、タスクを設定した人がシステムへの登録を担当します。
次の記事では、私たちの「企業標準」とそれが何につながったかについてお話します。
ここに続く
UPD：ストーリー「ガルシア将軍へのメッセージ」の著者を修正しました。 サイエントロジストは私の脳を曇らせています。 実際、この物語の著者はエルバートハバードです。 vfrolovにご注意いただきありがとうございます