「未熟なパフォーマー」のコンセプトを策定するための推進力は、Slava Pankratovによる「マネージャーのブラックブック」、または第5章「People」の一部でした。
人が何かをしていない場合、4つの理由があります
- わからない
- できません
- できない
- したくない
これらの原因を考慮する必要があるのは、この順序です。 しかし、それらのどれが失敗につながったかをどのように理解するのでしょうか？ 降りて観察方法を使用しますか？ 「正直に」話すだけですか？ しかし、結果として正しい理解が得られるという事実ではありません。
活動理論の方法論で解決策を見つけました。その要素は、たとえばエレナ・ムンドリーエフスカヤの記事に記載されています（著者へのリンクは、出版物の最後にあります）。 記事の著者は、アクティビティの特定の公理（または述語）を示します。これに従うと、出力の結果は入力のタスクに対応します。 この手法を使用したエラーと障害の分析は、障害の原因を正しく判断するのに役立つように思えました。
少しの理論（アクティビティ述語）
出版物のこのセクションは、Elena Mundrievskayaによる記事からの引用です。
アクティビティがある場合：
- 活動家でなければなりません（D）。
- Dには通常のアクティビティが必要です。
- Dは標準を理解する必要があります。
- Dは標準を受け入れなければなりません。
- Dはこの基準を満たす必要があります。
- 活動の産物には規範があるべきです
- 活動の成果物を入手するには、ソース資料に規範がなければなりません。
- ソース素材を製品に変換するプロセスには規範が必要です。
- 原材料を変換プロセスで使用される製品に変換する手段には規範が必要です。
- 変換ツールの使用方法に関する規範が必要です。
- すべてのルールの実装が必要です。
- 上記のすべてがある場合にのみ、アクティビティが実行されます。
この述部を注意深く見てください。 これがアクティビティであることに同意しますか？ そうでない場合は、さらに読むことはできません。 アクティビティの定義を入力してください。アクティビティの改善方法を確認します。 あなたは正しいかもしれません。 しかし、アクティビティの定義が正しいことに同意する場合は、次に進みます。」
熟練者と未熟練者
「未熟練」の定義は否定的な意味合いを持たず、特定の実行者がタスクを完了することが不可能であることのみを意味します。 述語ロジックを使用して、「スキルのない」アクティビティの原因を分析し、マネージャー（顧客）の観点から理解することで、「有資格者」に切り替えられるようにします。
分析のために仮想的な状況を考えてみましょう。 プロジェクトマネージャー（=アクティビティの顧客）には、アナリストと開発者のチームがあります。 開発者は常に期限を守っており、機能の機能はTORに対応していません。各リリースのエラーなど。 マネージャーはその理由を理解する必要があります。 状況の分析が、提案された方法論の枠組みにどのように適合するかを以下に示します。
1.活動家が必要です
この瞬間はすべてシンプルです。 マネージャーチームに開発者、つまりDがいる場合
2.労働者は活動の規範を持たなければならない
活動の基準は、会社の文化、規制文書、およびチームメンバー間の暗黙の合意（たとえば、標準のソースはPMBOOK、一連のベストプラクティス、SLA、責任範囲の割り当てに関する内部合意など）に定められています。 この項目が実装されているかどうかを理解するには、マネージャはこれらの標準の包括的なリストを決定する必要があります。
ルールが（少なくとも部分的に）定義されていない場合、開発者-リーダーはルールについて知らず、「誤解」によって「スキル不足」になるリスクがあります。
したがって、最新かつ完全な規制リストを維持することは、請負業者の資格を確保するための管理者の必須機能です。
3.俳優は規範を理解しなければなりません
規範が決定されるとすぐに、チームメンバーがこれらの規範を正しく統一して理解することが非常に重要です。 このアクティビティは、マネージャーの2番目の重要な機能です。 この機能の不可欠な部分はフィードバックです。これにより、パフォーマーは彼に送信された規範を「理解」し、さらにその価値は「正しく理解」されたことを理解できます。
規範が請負業者に渡されず、（または）正しく理解/理解されない場合、リーダー-開発者は同じ理由で「未熟」です-彼に期待されることを理解していません。
したがって、アクターによる規範（値、目標など）の正しい理解を確保することは、「資格のある」エグゼキューターを取得する途中のマネージャーの2番目の必須機能です。
4.俳優は規範を受け入れなければならない
この点は私にとって最も興味深いことの1つです。 受け入れるとは、価値と目標を共有し、基本的な点について合意することです。 養子縁組は生産的な議論を排除するものではありませんが、空と空の紛争を断ち切ります。 この段落を実装する理想的な結果は、志を同じくする人々のチームです。 実際の状況では、マネージャーは組み立てることができたチームと協力する必要がありますが、開発者が適切な方法で作業を行うには、少なくともチームの基本的な価値を維持する必要があります。
活動家が規範を受け入れない場合、彼は間違いなくこの活動に参加したくない。 彼が他のすべての点でどれほど優れていようとも、マネージャーはプロジェクトでそのような「反対」を持つ必要性を考えるべきです。
5.俳優はこの基準を満たすことができなければなりません。
ここではすべてが簡単です。 この問題は、請負業者の能力にのみ関連しています。 成功した活動に関連する9つの要因の1つだけが請負業者の能力によって決定されるという読者の注意を引く。 これはまさにその通りで、Slava Pankratovが「できない」と言っています。 この場合、マネージャー（顧客）は通常、何をすべきかを知っています-能力の開発または請負業者の変更。
ただし、請負業者の相対的なスキルレベルを理解することが重要です。 つまり 最初に、ノルムが決定され、それを実行するパフォーマーの能力が決定されます。 資格要件が第一です。 したがって、スペシャリスト（HRが認証の実践、または開発者向けの開発計画を導入することを決定する）の評価を開始する場合、規模と評価基準の初期決定。
6.活動の産物には規範があるべきである
製品基準は、顧客にとって重要な望ましい結果の特性の定式化です。 機能性、コスト特性、特定のテクノロジーへのコンプライアンス、スケーラビリティなど、理想的な結果を得るために組み合わせる必要のある要件が含まれます。 実際、これらは受け入れ基準です。
受け入れ基準の不確実性は、顧客への製品またはプロジェクトの配送が失敗する主な理由の1つです。 これを理解している資格のあるパフォーマーは、そのような仕事を引き受けるべきではありません。
したがって、管理者が製品標準を定義しない場合、請負業者は彼に何が必要かを理解せず、その結果、「資格がない」、つまり ジョブを正しく実行できません。
7.活動の成果物を入手するために、原資料に規範がなければならない
本質的に、これらは以前の再配布の製品（半製品）の下請業者の要件です。 たとえば、開発者にとって、そのような規範はTKのコンテンツの要件、または開発の要件が視覚化されるテストケースなどである場合があります。
これらの要件の形成が開発者自身に依存することはまずありません。機能間の相互作用の要件は主にマネージャーによって策定されていると思います。 このような基準を備えた開発者は、アナリストが受け取ったTKに十分な情報が含まれており、明確化する必要がないことを理解しています。
したがって、マネージャーは、チーム内の情報フローの質の高さに戸惑うはずです。 このパラダイムのフレームワーク内では、タスクがトラッカーに正式に表示されるだけでは十分ではありません。このタスクには、実行者が作業するのに必要な情報を正確に含めることが重要です。
このルールが守られない場合、「誤解」により「資格のない実行者」が再び得られます。「フロントエンドを作成するときに、スペシャリスト自身がデータベースのデータを取得するバックエンドスペシャリストに同意すると信じていた」などのすべての問題 私の意見では、これはまだマネージャーの仕事です-プロセスに入るための要件を決定する。
8.原材料を製品に変換するプロセスには規範が必要です。
ワークプロセスの構築方法のみを決定する別のルール。 パフォーマー自身が最初に自分自身のプロセスを考え出し、それから行動しなければならない場合、それは悪い習慣です。 各チームが、プロジェクトを実施するための方法論、スプリントの期間、タスクを完了するための条件などを各自で独自に決定するとします。 この状況でのシミュレーターの役割は、観察者の位置に制限され（チーム内の「自己組織化」に関する言葉の後ろに隠れていても）、プロジェクトはどこかで制御不能に動き始めます。 請負業者は、自分がどのように働くべきかを正確に誤解している状況にいることに気付き、再び-彼は「未熟練」のラベルを受け取ります。
9.および10.原材料を変換プロセスで使用される製品に変換する手段、および変換方法について規範が必要です。
ここでも、私には、すべてが単純なようです。 マネージャーとチームは、使用するテクノロジースタック、最適なアーキテクチャなどを決定する必要があります。
11.および12.すべてのルールの実現が必要です。 上記のすべてがある場合にのみ、アクティビティが実行されます
読者は確かに注目を集めました。請負業者が「資格がない」と認められる10の理由のうち、請負業者の訓練レベルに直接関係するのは1つだけです。 その他の場合、資格のレベルは、主にマネージャーまたは顧客が製品要件を正しく策定する能力によって決定されます。 つまり 製品の生産における管理者/顧客の資格が第一です。
活動基準が定義されていない状況では、最も経験豊富なパフォーマーでさえ、「推測しない」リスクを負い、「得たいものがまったく得られない」リスクを常に負っています。 実際には、請負業者が規範を受け入れない、または規範を履行できない場合にのみ、請負業者を「資格がない」と認識することができます。 他のすべての状況では、それは認識されるべきです-請負業者は「理解しなかった」、そして管理のギャップを探します。 マネージャー（顧客）は規範の担い手です。 これらの規範を策定し伝達することができないことは、いわゆるいわゆる 「未熟な顧客。」
結論：
私の意見では、ほとんどの場合、資格のない請負業者は資格のない顧客と一緒にしか現れません。
例外は、請負業者が会社の価値を受け入れない場合（Pankratovの定義で「望まない」）、または単に十分なレベルの知識またはスキルを持っていない場合（「どのようにわからない」）です。
失敗のその他の原因はすべて、顧客（またはマネージャー）のレベルで検索するか、この点から検索を開始する必要があります。
もちろん、管理は不正確な科学であり、芸術の形式でさえありますが、私の意見では、活動理論の要素を使用することで、チームが真実を突き止めたいという欲求がある場合、エラーの検索と特定のプロセスを合理化できます。
また、この記事でこのマネージャーに来て、最初にすべての規則を確立して処方することを要求することは、請負業者側の悪い習慣になることに注意する必要があります。 実生活では、これらの規範は常にそこにあり、多くの場合は書面ではなく、チームが発展するにつれて自然に状況に応じて形成されます。 述語に従うことにより、これらの規範を特定し、それらを棚に置き、改善が必要な場所を理解することができます。
思考マネージャーにとって、チームが現在どのような標準を導き、管理方法によってこれらの標準を調整するかを理解することは、可能なすべてを文書化し、すべてをVisioで視覚化しようとするよりも重要です。 規範自体は急速な変革の対象となり、ドキュメントは常に「昨日」のプロセスを説明します。
また、ドキュメントを完全に放棄することを勧めません。 重要な合意を忘れないためにメモが必要です。 チームがコンセンサスに達すると、本当に重要な規範は修正されるべきです。 例：製品の受け入れ基準。 製品のモジュールインターフェイス。 チームの労働契約などの条件
おわりに
活動の理論、特に製品の配給計画を掘り下げて、製品管理方法論の形成に至りました。これは、可能であれば、以下の出版物で開発されます。 また、マネージャーの動機の問題についても-マネージャーができる限り効率的に生産協力を組織することを奨励するような活動を刺激するシステムを探すこと。
参照資料
- Pankratovの栄光"The Manager of the Manager" -ダウンロードできます。
- エレナ・ムンドリーエフスカヤ「戦略のテスト」「経済戦略」、No。08-2006、pp。172-175、記事はここでも読むことができます 。