吸血鬼。 プログラマーの分類

リーダーは誰ですか、なぜ彼らが必要なのですか？ 人生でのそれらの使用は何ですか？ 彼らは何をしますか？ 彼らは何をすべきですか？



一方では、リーダーは伝統的に管理者として理解されています-計画を立て、指示を与え、タイミングを制御し、最も大声で叫び、決定を下し、それらに責任を負います。



一方、運用責任者は運用管理に関与することなく、委託されたユニットの開発のみに対処すべきだという意見があります。



第三に、自治組織とターコイズ組織がありますが、実際には、リーダーとしてのそのようなエンティティはまったく必要ないことが証明されています-それは、異なる人々の間で簡単に広がる責任、役割、および管理点のセットです。



それで、このリーダー、彼は誰で、なぜ彼が必要なのでしょうか？ マネージャーは会社を必要としているのか、会社は収入源としてリーダーを必要としているのか？ 結果は価値があるので、おそらく彼は自分の存在を正当化します-マネージャーの収入は通常、通常の従業員の収入よりも比較にならないほど高いです。



私はマネージャーを評価するために特別なモデルを使用しています。

モデル

このモデルは簡単に不名誉になりますが、原則としてプログラマーだけが理解できます。 しかし、あなたはプログラマであり、すべてがあなたに明確になります。



したがって、特定の情報システムで会計を自動化した企業を想像してください。 そしてこのシステムの隣にはプログラマーがいます。 彼とIT部門の長、コーダー、アーキテクト-すべてが1つになっています。 この状況は、小規模企業、時には大企業で非常に一般的です-私自身は、しばらくの間、企業で唯一のプログラマでした。



そこで、プログラマーが部門の長であり、実際には、情報システムが人員、機器、プロセスなどを含む彼の部門であると想像してください。 そして、部門、サービス、部門、および企業全体-これはシステムです。 そして情報-それもシステムです。



プログラマーは、システムをさまざまな方法で自由に扱うことができます-開発、保守、削除、破壊、生産性の低下または増加、別のシステムへの交換、文書の作成または削除、バランスの制御など。



頭は、彼のシステム（部門）でほぼ同じことを自由に行うことができます。開発、同行、執行者としての仕事、干渉、支援、分散、人事の交代などです。



モデルは明確です。マネージャー/部門の関係はプログラマー/情報システムと同じです。



では、このモデルのプリズムを通してリーダーを見てみましょう。

スニーカー

最も原始的なタイプのプログラマは、何もしませんが、どうにかして仕事から飛び出さないようにしています。 私は個人的にこれを見ました-彼は統合された1C 7.7から1C 8ソフトスターターに切り替えられ、足も最初も2回も使用しませんでしたが、彼はインターネットに時間をかけてセットアップし、 ICQとトレントからの音楽のダウンロード。



別の例は、自分で何かをする方法を知らなかったが、プログラマーの間で広範な連絡先のネットワークを持っていて、可愛くて魅力的であると言われた女の子です。 さらに、彼らは他の会社で働いていました。



あなたは、そのようなプログラマーがいるシステムはそれ自身の人生を生き、事実上それに依存せず、オフィスを出る前に目に見える変化がないことを理解しています。



これらの人々のリーダーの間でも満員です-彼らはそうである、彼らはそうではないこと。 彼らは結婚式の将軍と呼ばれることもありますが、これは頭が少なくとも代表的な機能を果たすことができる場合です。たとえば、クライアントとの会議にうまく座る場合などです。



このようなリーダーは、あらゆる種類のイベント、会議、特に多くの人がいて、口を開く必要がないイベントを愛しています。 時々彼らは非常に悲惨で、彼らがまだリーダーシップから任務を得るならば、誰かが同情して助けない限り、システムがそれらを完全に無視するので、彼らはそれを正常に委任することさえできません。



そのようなプログラマーとシステムのリーダーの役割とその開発について話すことは意味がありません。 役割も開発もありません。 これは最も悲惨なケースです。

親relative

これは別の種類のこっそりであり、親relativeはその場にとどまるために多くのことをする必要がないという違いがあります。 彼らは毛むくじゃらの足でそこに連れて来られ、座っています。 誰が一日中、誰が夕食の前に、誰が夕食の後に、誰が家にいます。



近親者はすでにシステムに影響を与えています。 彼らは恐れています-あなたはどんな種類の手綱が尻尾の下に落ちるのか決してわかりません、あなたはあなたの仕事を失う可能性があります。



しかし実際、彼らは通常この影響を使用しません。 システムの要素、つまり 彼らはその中で機能を実行したくありません。 責任と義務が表示されます、少なくともあなたは仕事に来なければなりません。 彼らはシステムを開発できません これには、少なくともいくつかの能力と何が起こっているかを理解することが必要です。



もちろん、親relativeが親relativeのように振る舞わない場合は例外がありますが、その場合はこのカテゴリから厳lyに除外します。 家族の絆が助けになることもあり、例えば家族経営などで、人の責任と効果を高めます。 親relativeは解雇を恐れないため、効率が向上します。



しかし、一般的に、そのようなプログラマーはほとんどの場合、システムの生活の中で役割を果たしておらず、部門の生活の中で頭を占めています。

ねじ

プログラマーがオペレーターに変わることがあります。 頻繁ではありませんが、起こります。



ファイルの交換、アップロード、ダウンロード、バックアップ、ドキュメントの入力、レポートの生成、何らかのデータ分析などを実行するだけです。 実際、ユーザーの仕事をするだけです。 私の人生では、ゆっくりと、少しずつ、プログラマーが会計士になったときに、これを見ました。



回された場合、すなわち 別の部門と別のポジションに移動しました-そして、彼と地獄、そのような通常の変換。 しかし、たまたまオペレーターとして機能し、プログラマーと呼ばれています。 私たちのモデルでは、彼は誰ですか？ 彼が管理することになっていたシステムの要素。 その後、誰がシステムを管理および開発しますか？ 誰も、別のものが来て、ここで何かが間違っていることに気付くまで、誰もいません。



これは、特にチームリーダー、サイトマネージャー、チーフシステム管理者などの最下位レベルのマネージャーで常に発生します。 彼らの立場は形式的なものであり、何も管理も開発もせず、他の人と同じように働き、RAMにアクセスしてタイムシートを提供するなど、もう少し責任があります。



どちらのリーダーも、彼らのシステムに影響を与えません。 管理しない、開発しない、応答しない。 システムはそれらに依存しません。

タコ

しかし、これはまったく別のケースです。 このようなプログラマーは、プログラミングに関与していませんが、重要なシステムのユニークな要素です。 たとえば、彼だけがコストを計算し、課税戦略に従って調整する方法を知っています。



実際、これは同じ演算子であり、より高度なものであり、その価値を実現し、成功裏に販売しています。 そのようなプログラマーは、「何も飛ばさないように」登録項目を調整する方法を知っているのは自分だけだと主張しています。 サブコントが分散しないように、彼だけが背面のマイナスを修正できます。 リストを自分で続けることができます。



このようなプログラマは、システムの不可欠な部分であり、そのボトルネックであり、切断できない付属物です。 それがなければ、危機があり、彼自身を含む誰もがこれを理解します-すべてはそれにかかっています。 彼は、複雑な操作の実行、レポートのダウンロード時のエラーなどの複雑な問題の解決について決定を下します。



このタイプのマネージャーはプログラマーよりもさらに多くいます。 彼らは人工的に意図的にシステムを1日間も存在させない状態を作り出します（これは休暇中にはっきりと見ることができます）。 彼らはすべてを調整し、すべて、特に「2階」で提供されているものをチェックし、プロセスの各インスタンス（たとえば、顧客の注文）で決定を下し、すべての会議に参加します。



彼らが委任される必要があると言われたとき、彼らは雇用について言及します-ただ座って考え、指示を書き、物事を引き渡す時間はありません。 一般的に、これは彼らのお気に入りの言い訳です-彼らが人為的に作成した雇用。 さらにマルチタスク。



状況は時々コミカルに見えます。特に、上層部のマネージャーが変わって、私たちの重要な要素を尋ね始めたとき-あなたは何をしていますか？ そして最も重要なのはなぜですか？ 答えは通常-「とても受け入れられた」、または、もし彼が企業の標準で不可欠なものを修正できたなら、「そうあるべきです」。 誰が受け入れ、いつ受け入れられたのか、なぜ受け入れられたのか-回答がないか、発音できない 「この意味のないがらくたを考えた」というのはまあまあです。



プログラマーとマネージャーの両方が徐々に彼らの排他性を信じ始めます。 時々、彼らは自分自身を気の毒に思い始め、他の人に同情を要求したり、収入を増やすためにより高い人からこの同情を誘発することさえします。



このような重要なプログラマーまたはマネージャーがシステムに変更を加えることがあります。 彼女に有利に働きます。 しかし、彼はほとんどの場合、システムをなくすことに集中していません。 たとえば、プログラマーは文書の束を形成するためのクールな処理を記述できます。これにより、ルーチン作業から人々を救いますが、この処理を使用するのはプログラマーだけです。 彼が誰か他の人に教えるように頼まれるなら、彼は「もっと長く説明するためにそこにいる、もっとうまくやらせて」などの言い訳をたくさん見つけるでしょう。



リーダーも同じことを行い、システムを自分自身で強化します。 たとえば、条件を打ち破ったセールスディレクターがいました。部門全体の売上の割合を教えてください。 あなたは、販売員にとって、それがそのようなリーダーのために働く主な動機になることを理解しています-「もっと売る」のではなく、「もっと好き」。 このアルゴリズムは存在しないため、マネージャーは分散アルゴリズムを説明できません。



その結果、プログラマーにとって、マネージャーにとって、結果は1つです。システムは存在せず、システムなしでシステムを開発することもできません。

グローブ

手袋のようなシステムを変更するプログラマーがいます。 彼らは、プログラミングの方法を知らず、実装を思い浮かべ、ユーザーの大小の問題を解決し、企業に利益をもたらします。



どんな危機的状況においても、システムからの利益よりも害がある場合、彼らは発言します。それは別のシステムに切り替える時です。



幸いなことに、特に1Cの製品ラインでニッチが混在していても、これで問題はありません。 UT 10.3からUPPに切り替え、次にKA 1に、次にKP 3.0に、次にKA 2に、次にERPに切り替え、すべてに唾を吐き、UNFを実装してから、USHP（業界で許可されている場合）のような歪み、驚いたことに、SCPに戻ります。 各移行期間は最低1年です。 そのような戦略にどれだけ耐えられるかを考えてみてください。 そのようなプログラマーに会ったことがありますか？ 会った。



同様のリーダーはどのように見えますか？ 彼は、管理の基本的なアプローチである方法論を際限なく変えています。 今日、彼は1か月の計画を立て、明日は1年の計画を立て、その後アジャイル、TOS、リーン、4-4-5、予算編成、予算なしのモデルの順に進みます。 頭がこれらのすべてのテクニックを知っていれば、これは悪くありません。少なくとも彼らのアプリケーションを練習することは可能です。



しかし、通常、すべてがより平凡です-そのようなリーダーは、リストラによってすべての問題を解決します。 彼は1つの部門から2つ、次に10、それから1つを作成し、新しい人々から新しい部門を採用し、古い部門に取り消して配置し、新しい投稿を作成して指示、プロセス、標準を作成するか、非常に幼稚な方法で部門を変更します部門、部門の部門、チームの部門、地区のチームなど。



プログラマーとマネージャーの両方のアプローチの本質は同じです。大規模な変更が進行中の間、誰も結果の底に到達しません。 そして、あなたが底に着くならば、あなたはいつでもotmazatsyaすることができます：我々は全面的な変化にあります、今あなたの質問に答えるか、1ヵ月後に戻ってくるか、あなた自身で答えを探すことは単に不可能です。



システムへの影響は規模では恐ろしいものですが、その結果と効果には意味がありません。 これらは、変更のための単なる変更であり、巨大な規模にすぎません。



特に悪いのは、他の人がそのような振る舞いに慣れ、これらの変更に始まりがあり、終わりがなければならないことを徐々に忘れてしまうことです。 彼らは、一連の変更、どのシステムまたは方法論が変更されたか、そしてその理由を忘れています。 その結果、しばらくすると、変更の範囲全体を再び繰り返すことができ、誰も気付かないでしょう。 実際には、私はそのような写真を観察し、サイクルの頻度-4年を計算しました。



もちろん、そのようなプログラマーやマネージャーから企業に利益をもたらすことについて話す必要はありません。

プリーシキン

PlyushkinはGogolの「Dead Souls」のキャラクターです。貪欲な小さなmerc兵で、見つけたものをすべて引きずり出して保持しました。



このようなPlyushkinプログラマーは、gitなどのあらゆる種類のソリューションとコードリポジトリを愛していますが、他の目的にも使用されています。 そこで問題の解決策を探す代わりに、十分なディスク容量またはお金（有料ソリューションの場合）であるすべてのものを愚かにダウンロードします。 それらはきちんとしたフォルダに格納され、ソートされます。時々、システムに組み込み、ユーザーまたはディレクターに見せて自分のふりをして、その存在を正当化しようとします。



彼ら自身は特に何もすることができないため、他の誰かの小さなものを彼らのために使うことが、この職業で生き残るための唯一の方法です。 深刻な変化については、彼らには強さ、能力、勇気が欠けています。



そのようなPlyushkinsは、そのシステムのインターフェイスを見ることで認識できます。これは、さまざまなアドオンのアイコンでいっぱいになり、その意味は誰にもわかりません。 あらゆる種類の機能パネル、メタデータツリーの複製、テーブルのユニバーサルソート、エクスチェンジを使用しないデータベースでのエクスチェンジの管理、他のシステムでさえも多数のレポートなど



Plyushkinaの幹部も同様に行動します。 彼らはソーシャルネットワーク内のブログ、記事、あらゆる種類のグループを読んで、少しの努力で便利な変更を加える方法を学びます。 方法の選択における非体系的な性質、部門の問題および実装自体の理解のために、彼らは通常ナンセンスになります。



たとえば、Plyushkinは、新しい若い知事が立ったまま会議を開いていることをテレビで見ます。これにより、効率が向上します。 以前は、仏塔に座って水を押していましたが、今は立っています。 または、すべての従業員が手作業で日報を書くべきである別のベストプラクティスを読んでください。これは、コンピューターのコピーペーストではなく、心からの本当の言葉です。



このようなプログラマーとマネージャーは、システムに小さな、そしてほとんど有害な影響を与えます。 とりとめのないゴミやノイズでいっぱいにします。

エスコート恋人

多かれ少なかれ複雑なタスクの解決のために、ほぼ常にアウトソーサーと呼ばれるプログラマーがいます。 システムの導入、新しいサブシステムの立ち上げ、サイトとの統合、新しいドキュメントの開発、小道具の追加のプロジェクト-外部プログラマーがすべてのために呼び出されます。



同じリーダーがいます、私は個人的に見ました。 モチベーションシステムが必要ですか？ ビジネスプロセスの最適化？ 戦略開発？ 管理システムの分析？ 答えは1つだけです。外部の専門家を探しています。



システムへの影響は、どうやらそうですが、ほとんど常に曲がっており、有害です。 コンサルタントはモザイクの一部のみを使用します。



たとえば、不正なプロセスの動機付けシステムを作成します。 または、実装の動機を考慮せずに戦略を作成します。 または、ネイティブ-プロセススナップショットの自動化を行います。これは、プロジェクトの1年前に関連性を失いますが、これは重要ではありませんが、目標と動機も考慮されないためです。



結果として、それは常に曲がっており、ある方向に偏っています。 頭とプログラマの両方。 しかし、主なことは、この開発プロセスにおける彼ら自身の役割がゼロであることです。

許容

これは最も一般的なタイプのプログラマーです-言われたことをすべて行う人。 それに応じて-彼らはシステムに無意味な変更を加え、誰かの不健康な野心を実現するために、それを少しずつ与えます。 これが私たちの大半であり、何と言ってもいいでしょう。



そしてそのようなリーダー-一括で。 これらはすべて、外部のオートメーションエンジニア、ISO 9001の実装者、多数のレポート、紙片を提供し、何百万もの承認を取得し、歌を学び、企業イベントのシーンを準備する必要があるすべてのストライプの内部官僚などを入れた人たちです。 一般に、ホームレスの人々の玄関のように彼のシステムの一部を外部の暴行に開放しましたが、今ではすべてを嗅ぐことがないように、そこから追い出す方法を知りません。



その結果、情報システムと部門または企業管理システムの両方が、フランケンシュタインを禁止するようになり、一歩踏み出すことができなくなります。



そのような人々は害虫です 「そして私はチェ、私は言われた」という名目で彼らのシステムを破壊します。

普通

世界には、システムが何をすべきかを自ら決定し、直面する目標を知っている通常のプログラマーがいます。目標が曲線に設定されている場合、それらは恥ずかしがり屋ではなく、それらを調整し、誰もが同意することに成功します。



システムの効率の改善に絶えず取り組んでいる通常のマネージャーがいて、彼らは思慮深く、一貫して、そして専門的にそれを行います。



非常に緊急の場合を除いて、どちらもシステム内に侵入しません。



どちらもシステムを自分自身に結び付けておらず、いつでも離れることができ、システムは機能し続けますが、開発は停止します。



唯一の問題は、どちらも存在しないことです。

重要な問題

決して同意できないさまざまな人々に散らばった知識、経験、能力があります。動機付けシステムを作成できるものもあれば、戦略、3番目の目標と指標、4番目の自動化、5番目の管理システムもあります。しかし、彼らは同時に一緒に働くことはありません。



開発は常に一貫性があり、企業で時々考えられるプロジェクトからそれを見ることができます。



たとえば、現在のプロセスに基づいた動機付けシステムが導入されています。プロセスが曲がっていることが明らかな場合、プロジェクトの規模と予算を超えないように、これは無視されます。



または、プロセスの最適化が開始されますが、自動化がそれに追いついていないため、両方の新旧バージョンのひどいハイブリッドが発生します。



私はすでに、特に外部のアウトソーサーの努力を通じて、自動化について何度も話しています。彼らは単純に、無意味なプロセス、やる気のない動機、計り知れない目標の自動化されたキャストを行い、一般的な管理システムなしにしています。



無限のレースが得られます-システムの各部分が先を行き、それは人口全体の状態を悪化させるだけです。

解決策

ソリューションは、開発を統合するために、不名誉に簡単です。システムのすべての部分を同時に変更して、それらの間に不均衡がないようにします。



主な問題は不均衡であるため、システムの各部分が互いに不一致です。問題は特定の部分にあるようです。



たとえば、非常に頻繁に自動化を停止します-それはすべてのせいです。



私たちプログラマーは通常、プロセスに責任があり、混乱があると言い、それを自動化することを余儀なくされています。



動機付けシステムの実装者は、プロセス、自動化されていない指標、および目標の欠如について不満を述べています。等



しかし、本当の問題は開発競争を生み出す不均衡であり、企業はビジネスシステムのあらゆる部分のメリットを決して得られません。



ERPを実装し、残りのプロセスがないため、可能性の10％を利用します。指標の計算は自動化されていないため、評価システムを実装し、使用していません。彼は戦略的な目標を書きますが、プロセスはそれに応じて再配置されないため、目標を達成することはありません。



1つだけのポイントがあります。各部分自体は悪くありませんが、不均衡になっているため、すべて一緒に機能しません。

幹部とプログラマーに戻る

私があなたに言ったモデルは笑うだけではありません。彼女は特定の場所、特定の企業、特定のリーダーの状況を理解するためのものです。



プログラマーとのアナロジーを選んだのは、1つの単純な理由です。私はプログラマーであり、あなたはプログラマーです。確かに、人事の女の子にリーダーの役割と影響を説明する場合、別のモデルを考え出す必要があります。私が伝えたい考えは1つですが、多くのモデルが存在する可能性があるためです-それらは理解を容易にするためだけのものです。



しかし、私には思えるように、リーダーはアタビズムです。ビジネスはそれらを必要としません。彼らはあなたが嫌い​​な悪い習慣のようですが、やめることを恐れています。リーダーは、サポート、安定性、ビジネス管理性の錯覚を作り出します。彼らは、「責任を負う」、「決定する」、「調整する」など、実際には無意味な言葉を好みます。



これらの言葉はすべて、指導者自身によって発明されました。楽しみのために、リーダーが彼が必要でないことを確信させるようにしてください。彼がいなければ、彼の耳が引っ張られるのは悪いことだと、彼はあなたに多くのことを話します。しかし、ビジネスがなぜ彼を必要としているのかを頭で聞くことは、発砲の宣告を受けた人に、なぜ生きるべきなのか尋ねることと同じです。



リーダーとプログラマーを比較するモデルは、リーダーがなぜ必要なのかを忘れないように、こうした会話や同様の会話の中で役立つことを願っています。

どこに置きますか？

人を置く必要はありませんが、一般的に受け入れられているリーダーのモデル-「大きな給料をもらえる大きなボス」。実際、リーダーになりたいと思っている人たちは本当にこれに取り組んでいますか？



Belbinモデルは良い答えを与えます。通常のリーダーは不明確な責任の不明確なコンポートであり、役割を整理して特定の人に適した仕事を選択するだけです。



オンラインの人々の行動を調整できますか？さあ、コーディネーターになりましょう。



インスピレーション、サポート、物事を前進させることはできますか？さて、動機付けになります。



プロジェクトを短時間で完了できますか？OK、フィニッシャーになりましょう。



あなたはビジョンを持っていますか、どこに行くべきかを知っていますか、正しいアイデアを提供できますか？ジェネレーターになりましょう。



多くのシステムパラメータを分析し、念頭に置いて、その脆弱性を理解できますか？ OK、アナリストになりましょう。



これらの役割はすべてリーダーシップではありません。それは単なる役割であり、仕事はそのようなものです。



あなたが何をすべきかを人々に伝える場合、それはあなたが担当しているという意味ではありません。ディスパッチャは、タクシーの運転手にも行き先を伝えます。彼は話しませんでした彼はシステムに置き換えられました。



あなたが人々を鼓舞する方法を知っていれば、これはあなたが担当しているという意味ではありません。誰かがインスピレーションを得るために適切な映画を見る必要があるだけで、あなたが彼を犯したのはあなたの動機をあきらめなかった。そして、家の誰かが家でとても刺激を受けて、彼女は十分に思えないでしょう。



役割と能力の棚にある伝統的な「リーダーシップ」を拡大すると、何も残りません。では、なぜそのようなリーダーが必要なのでしょうか？さらに、レイアウトでは、彼は実際にはどの役割も実行できないことがわかります。



物語が言ったように、王は裸です。