これらの考慮事項は、主にADV / Webエンジニアリングでの長年の経験に基づいています。 長年の作業と会社の発展のさまざまな段階で、「三角形」の組織化のスキームのほとんどすべてを試みました。
「三角形」の役割の説明、責任範囲
ここで役割について話していることに注意してください。 「三角形」の特定の組織スキームは、1人のマネージャーの複数の役割の組み合わせを意味する場合があります。
売上高 セールスマネージャー。 彼は、次の要求に関するプロジェクトの販売を担当しています。最初の連絡、提案と見積りの準備と提示、契約の締結。 また、「コールド」コンタクトの開発にも関与している場合があります。つまり、単独で（または大規模なRA、システムインテグレーターなどのチャネルを介して）顧客を検索します。
PM プロジェクトマネージャー。 彼はプロジェクトの制作を担当し、タイミング価格の品質を管理しています。 彼は、プロジェクトの制作の一環としてプロジェクトチームを指揮し、顧客の代表者との制作の問題を解決します。
アカウント アカウントマネージャー 顧客サービスを提供し、クライアントとの戦略的関係を構築し、苦情に対応し、クライアントの存在の全段階で彼を快適かつ簡単にするよう努めます。 原則として、既存の顧客にプロジェクトとサービスを販売する意欲があります。 多くの点で、アカウントロールはPMとSalesの中間にあります。
やる気
問題を理解するには、彼の仕事の各役割の代表者を動かす動機を理解する必要があります。
販売は 、特定のプロジェクトの販売に焦点を当てています。 彼にとって、生産段階で何が起こるかはそれほど重要ではなく、彼が販売することは重要です。 そのため、販売は多くの場合、推定コストを引き下げ（販売しやすい）、顧客に金の山を約束する傾向があります。 多くの場合、PMに非常に不満があります。
PMは 、プロジェクトの質の高い生産に動機付けられています。 彼はプロジェクトの品質と人件費を担当しているため、常に推定コストを引き上げて（リスクが少なくなるように）、クライアントに最低額を約束します（約束を担当するため）。 彼はプロジェクトの完了後に何が起こるかはあまり重要ではなく、彼の仕事はプロジェクトを論理的な結論に導くことです。
アカウントは 、クライアントのために社内で最も快適なスペースを整理することを目的としています。 実際、アカウントはスタジオ側の顧客の代表者であり、彼の利益のために行動する必要があります。 アカウントは、顧客との忠誠心と良好な関係を、会社のプロジェクトとサービスの繰り返し注文に変える必要があります-これが究極の目標です。 アカウントは、推定コストを削減するように動機付けられ（販売が容易であり、クライアントは満足しています）、黄金の山を約束するように動機付けられません（それでも悪化しますが、クライアントと連携します）。
アクティビティ
動機付けに加えて、すべての役割は活動の形式とリズムが大きく異なるため、これも考慮する必要があります。
営業活動は可能な限り不安定であり、クライアントとのやり取りは最短です。 販売サイクルは最短の段階です。 販売-販売されていません。 また、販売には最もリスクがあります-プロセスでは最前線にあり、生産する製品のほとんどは需要がありません（単に販売されているプロジェクトよりも販売されているプロジェクトの方がはるかに少ないためです）。 すべての人がこのような破れたモードで作業できるわけではないため、これにはある程度の傾向が必要です。
PMアクティビティは、プロジェクトサイクルによって測定されます。 マネージャーは、1つまたは複数の生産プロジェクトを抱えており、個々のプロジェクトの効果的な実施を目指しています。 PMは、プロジェクトとその段階のコンテキストで時間間隔を考慮します。 したがって、PMは中距離を「実行」します-彼の視野ではプロジェクトです（期間は販売段階よりも長くなりますが、会社のクライアントのライフサイクル全体よりも短くなります）。
アカウントは最長実行フェーズで動作します。 彼は、会社での彼の存在のサイクル全体で一緒にいるクライアントを持っています。 彼の仕事はより戦略的です（関係の発展、クライアントの快適な滞在の組織化）。 アカウントのアクティビティは、体系的でよく整理されている必要があります。 しかし、彼は最終的に、顧客へのプロジェクトまたはサービスの繰り返しの販売に焦点を当てています。これを忘れないでください。
「三角形」を整理するためのオプション
役割は3つしかないため、それらを組み合わせるためのすべてのオプションを検討し、各アプローチの長所と短所を評価できます。
1.セールス＆PM＆アカウント 「オールインワン」
小さな会社の開発の最初の段階のための古典的なオプション。 複数の専門家を雇うにはリソースが足りないため、会社にはすべての取引のマネージャーが1人います。 原則として、彼は会社のCEOであり、能力の中心でもあります。
利点：
マネージャーがなんとかプロジェクトを売却できた場合、クライアントはそれを気に入りました。 彼は引き続きリードし、クライアントとやり取りします。これにより、販売後に連絡先を変更する問題がなくなります。
短所：
動機と目標が異なることによる、強い内部対立「Sales-PM」。 マネージャーはクライアントの単一のエントリポイントであるため、生産段階で必然的に発生する小さなショールは、クライアントによって戦略的な関係に投影されます。 プロダクションマネージャーでの着信リクエストとプロジェクトの増加に伴い、すべてに対して十分ではありません。
2.セールス+ PM＆アカウント
原則として、このモデルは会社の発展における次のモデルです。 PMとSalesの最も対立する役割が分かれているため、内部対立を解決できます。 売上高は純売上高に従事しており、そのタスクは新規顧客を会社に引き付けることです。
PM＆Accountの主なタスクは、プロジェクトの制作です。 クライアントとの関係を発展させる機能は、負担になる可能性が高くなります。
利点：
仕事に責任を持つ有能なPMおよびアカウントスペシャリストにより、このスキームにより、長期間効率的に作業することができ、大きな安全マージンがあります。
PM＆Accountは、クライアントとプロジェクトの両方に関する知識のキャリアです。彼は常に何が起こっているかを知っています。
短所：
Salesは別のマネージャーであるという事実のため、プロジェクトを転送する問題が発生するため、PMとAccountはプレセールの初期段階に関与する必要があります。 セールスの観点から見ると、マイナスは彼らの行動に対する責任の欠如であり、「3つの箱でクライアントを約束する」誘惑があります。
常連客の数が増えると（たとえば、1人に15人が割り当てられ、彼は3つのプロジェクトを生産中で、彼はプロジェクトに注力します）、彼らは見えなくなり、関係のさらなる発展なしで停滞し始め、それは会社のビジネスに悪影響を及ぼします。
前のスキームのように、プロジェクトの制作中に小さなショールが発生し、顧客との不満が戦略的な関係に投影されます（同じマネージャーがそれらに対処するため）。
* ADV / Webエンジニアリングという会社は、8年以上にわたって「トライアングル」の組織のこのようなパラダイムに存在してきたと言えます。 しかし、これはPMとアカウントの投稿における従業員の非常に高い能力と責任のおかげでのみ可能になりました。
3.アカウント+セールス＆PM 「臨床」
これは非常に奇妙なオプションであり、完全を期すためにのみ検討しています。 PMとSalesの動機は正反対です。そのため、1人で別のアカウントと組み合わせることは無意味です。 実際には、幸いなことに、私はそのようなオプションに遭遇したことがありません。
4.セールス＆アカウント+ PM
このスキームでは、アカウントは販売と統合され、PMは専用の役割になります。 これにより、1人で顧客との販売のやり取りをローカライズし、別の人で生産を直接ローカライズできます。 そのようなスキームは、十分な数の常連客と生産中の大量のプロジェクトがあるかなり大規模な企業にとって典型的です。
利点：
プロジェクト（クライアント）とその知識を移すのに問題はありません。 最初のプロジェクトをクライアントに販売したマネージャーは、引き続き彼と協力します。 Sales＆Accountは、会社のすべてのサービスのクライアントのエントリポイントです。
セールスとアカウントの両方の最終目標はセールスです。これにより、このタスクを1人でローカライズできます。 同じスキームを使用すると、通常の顧客からの注文の量が常に予測されているため、販売の「個別の性質」を安定させることができます。
短所：
セールスとアカウントの活動のリズムは異なりますが、内部矛盾が発生します。 セールスには多くの受信トレイがあり、すぐに「ハングアップ」、短い対話サイクルで終わります。アカウントには、関係を慎重に構築する必要のある通常の顧客がいます。
*この資料の執筆時点で、ADVはそのようなスキームを仕事に使用しています。
5.アカウント+セールス+ PM 「スワン、ガン、パイク」
最大の「分業」を備えたスキームは、可能な限り効率的であり、大企業に理想的に適しているように思われます。 ただし、すべてがそれほど単純ではありません。
このようなスキームの利点は、管理者が「純粋な」役割を実行することです。これにより、すべての人間の内部紛争が解消されます。
他にも欠点があります：
重要な問題の1つはプロジェクトの転送です。クライアントは、仕事の開始時に好きなセールスが2人の連絡先に置き換えられ、ビューから消えるとショックを受けることがよくあります。 これには、PMとSalesをプレセールの初期段階に含める必要があります。
各プロジェクトに3人がいると、やり取りに混乱が生じ、多くの場合、クライアントの周りで「タンバリンとのダンス」に変わります。何が起こっているのか誰も理解していないと、能力の中心が失われます。 明らかに、そのようなスキームのフレームワーク内での管理は整理するのがより困難です。
さらに、同じ役割を果たすことができる「狭い専門家」が市場にかなりいることが実践により示されています（これはPMにはそれほどではありませんが、販売およびアカウントにはさらに当てはまります）。
*私たちはそのようなスキームのフレームワーク内に1年未満存在し、それを「アカウント＆セールス+ PM」スキームに変更しました。
おわりに
このトピックは非常に広範であり、最初に気づいたように、検討中のモデルではいくつかの単純化が行われています。 たとえば、ほとんどの大企業には「サポートマネージャー」という追加の役割があり、これにも独自の微妙さがあり、この役割を他の（またはそうでない）と組み合わせて、「三角形」を「正方形」に変えることができます。 さらに、会社が多様な製品のラインを形成している場合、スキームに「製品マネージャー」の役割を含めることについて話し合うことができます。
また、各スキームがスペシャリストを雇用するための独自のアプローチを必要とすることも注目に値します。ロールのレイアウトの1つで自分をよく示している人は、他のロールを組み合わせるのにほとんど効果がないからです。
ご清聴ありがとうございました。この資料が有用な考えに貢献したことを願っています;）
テレホフアンドレイ