牛の放牧方法。 開発マネージャー向けのヒント

父と子の永遠の問題に加えて、私の意見では、部下と指導者という別の問題があります。 私の記事でお話ししたいのは、この問題についてです。 より正確には、ソフトウェア、設計、技術文書の開発における部下とマネージャーの関係などの特別なケースについて。 リーダーはしばしば部下を無責任な奴隷だと見なし、リーダーの部下は群れを放牧する必要がある無能な羊飼いであり、開発部隊を指揮しません。 多くの場合、状況は誤解によって悪化します。 頭は開発を理解しておらず、部下は管理上のニュアンスを理解していません。 この記事は、悪いリーダーが良いリーダーになるのを助けるように設計されています。 もちろん、あなたは次のように言います。「ねえ、簡単に考えてください、他の悪いリーダーは何ですか？」 そして、あなたはおそらく正しいでしょう、私は非常に誇張します。 それほど悪くない。 数百人と数千人の普通のリーダー。 しかし、高品質の開発プロセスを構築するには、最高のスペシャリスト、つまりパフォーマーとマネージャーの両方が必要です。 したがって、私はリーダーを善と悪に分けます。 ハーフトーンなし。 ところで、開発者のように、これは最後のヒントで言及されています。 あなたが良いリーダーであるか悪いリーダーであるかを理解する方法は？ 以下のルールをお読みください。 それらのいくつかがあなたにとって無意味に見え、ローファーに夢中になっている場合-記事はあなたのために書かれています。

ルールは次のとおりです。



最初のルールは、開発をうまく管理するために、開発者でなければならないということです。



このルールは揺るぎないです。 開発は複雑なプロセスであり、このプロセスを内部から知っている人だけが有能に管理できます。 他は与えられません。 複雑なシステムを開発したことがない場合、開発の品質を管理できません。 この場合、開発者をリードできます。 しかし、製品を作成するには、仕事を提供する有能な人材を選択する必要があります。 技術的な質問を部下に完全にシフトした多くのリーダーを知っていて、機器の作り方を知っている人々を賞賛し、「いつ準備ができますか？」と「仕事に必要なものは？」 これは素人にとって素晴らしいリーダーシップスタイルです。 唯一の落とし穴があります-人事方針。 人事方針に誤りがあると、プロジェクトが中断し、地位が失われる可能性があります。 スタッフが幸運だったら、彼らの仕事を確実にするだけです。 提供方法について-次のルールをお読みください。



ルール2-各開発者は自分の仕事だけを、より正確には-技術的な決定を下すことによってのみ対処すべきです。



プログラマーである場合、プログラムを作成する必要があります。 これが電子技術者の場合、彼は回路を描く必要があります。 彼はメモを書いたり、購入リストを提出したりしないでください。 彼は自分の能力の分野でのみ技術的な決定を下すべきであり、それを完璧に行うべきです。 同じことがプログラミングと設計にも当てはまります。 他の何かのために専門家を使用する大きな誘惑。 しかし、この場合、あなたは彼の先延ばしを引き起こし、彼の生産性と資格を減らすことが保証されます。 開発者が楽観的で、未完成のタスクから引き裂かれたという事実に落胆しない場合、異なるタスクを切り替えるのに最大2日かかります。 通常の人は、タスクを切り替える前に時間を失います。 そして今週は反対方向に再び負けます。 したがって、不快な驚きを避けるために、問題を処理してタスクを質の高い方法で分散してください。



ルール3-複雑な製品を開発する場合、技術的な決定の階層が必要です。



洗練された製品には、一流の専門家が必要です。 しかし、すべての専門家は異なっています。 そして、良いものはほとんどありません。 そして、それらは高価です。 したがって、開発には階層が必要です。 開発にはほとんど直接関与しないが、実行者に特定のタスクを課すシステムアーキテクトが必要です。 これは高価な高級専門家です。 おそらく、一部の幹部よりも費用がかかります。 そして確かに企業にとっては、多くのマネージャーよりも価値があります。 複数のスーパーエグゼキューター（プロジェクトの複雑さに応じて、1から無限まで）が必要です。 これらは、プロジェクトの構造についてのアイデアを持ち、建築家の機能を実行できる高度な資格を持つ専門家です。 システムの最も重要な部分を開発します。 通常の開発者も必要です。 彼らは建築家と超執行者の指導の下で通常の仕事をします、彼らは簡単に交換でき、彼らの給料は非常に普通です。 彼らはルーチンと呼ばれるものを行います。 テキスト技術文書の設計には、テクニカルライターが必要でした。 サプライ品を購入するには、秘書またはアシスタントマネージャーが必要です。 これらの機能は、マネージャーが技術スペシャリストでなく、製品開発に直接関与していない場合、マネージャーが実行できます。 冗談のように：「犬に餌をあげて、何も触れないでください。」



ルール4-1人のスペシャリストに多様なタスクを設定しないでください。



1つのプロジェクトのフレームワーク内で、開発者はプログラマのみ、1つまたは複数のサブシステムの設計者のみ、または電子技術者のみでなければなりません。 彼は一つのことをし、それを完璧にしなければなりません。 さまざまな種類の複雑なシステムの開発を同時に組み合わせることは不可能です。 さらに、プログラミングや電子機器などのタスクに1人の専門家を同時に使用しないでください。 時々、電子技術者は、電気回路を作成するために、プログラムすることができます。 これは標準と見なされるべきではありません-これは逸脱です。 興味がある人は、しばらくの間2つの職業を組み合わせることができますが、遅かれ早かれこれは疲労につながり、労働生産性を大幅に低下させます。 したがって、良い仕事をしたい場合は、「ユニバーサルスペシャリスト」を忘れてください。 これはユートピアです。



ルール5-すべての間違いが大惨事ではない。



プログラムおよびデバイスの開発プロセスでは、常にエラーが発生します。 私たちはただの人間であり、私たちはあまりにも不完全です。 誰もが間違っています。 どんな優秀な技術者もこれを知っています。 このため、プロトタイピング、テスト、プロトタイプなどの開発段階があります。 悪い仕事の指標は、エラーとそのレベルの統計のみです（子供のエラーがありますが、論文を書くことができる現象があります）。 問題は、技術専門家ではないマネージャーがこれを理解していないことです。 彼は、どんな間違いも非専門主義の指標であると信じています。 そして、彼は間違った人々を焼き始め、彼がすべきことのために焼き始めません。



ルール6-開発者は異なります。



有能ですが、普通です。 有能な開発者は、通常の開発者よりも10倍効率的です。 これは冗談ではなく、よく知られた評価であり、かなり古いものです。 多くのマネージャーの間違いは、専門家をバラバラに考えることです。 しかし実際には、10の開発者の価値がある主要な専門家がサブ部門にいます。 そして、彼らの間違いはまれであり、もしそうなら、彼らは非常に明白です。 そして、彼らに対する態度は特別でなければなりません。



ルール7-開発者は、お茶を飲みながら技術的なトピックについて話し合う必要があります。



行くぞ 開発者が会議に座っている場合、彼は働いていません。 彼がお茶を飲みながら同僚と新しい技術について話し合う場合、彼は働いています。 そのような会話はしばしば、彼が勤務時間中、仕事の後、夜間または週末にテストする新しい技術的解決策を促します。 リーダーの仕事は、ユニットの創造性の伝統を維持することです。



ルール8（実行不可能）-市場の原則は専門家の給与だけでなく、管理職の給与にも適用されるべきです。



優秀なプログラマーが平均的なマネージャーよりも見つけにくい場合、下位のマネージャーよりも高い給与を受け取る必要があります。 より便利です。 ボスは主に制御とフィードバックに必要です。 計画を立て、その実装を監視します。 これらのタスクは非常に簡単で、訓練された人なら誰でも実行できます。 しかし、すべてのプログラマーが複雑なプログラムを作成できるわけではありません。 これは、プログラマーがCEOよりも多く稼ぐ必要があるという意味ではありません。 もちろん、彼が開発の天才でなければ。 しかし、優秀なプログラマは、部門の長よりも多くを稼ぐ可能性があります。



規則9（違法）-ロシア連邦の労働法は仕事を妨げています。



これらすべての給与ポスト、これらすべての職務は架空のものです。 専門家は品質が異なります。 一流の専門家がいます、普通の専門家がいます。 そして、彼の立場の矛盾を明らかにする委員会を作ることによって悪い専門家を解雇できるなら、彼がひどい懲戒違反を犯さなければ通常の専門家を解任することは不可能です。 しかし、あなたは彼を解雇する必要があります。 そして、彼の代わりに、より優れた、より有能で資格のある人を探してください。 私の意見では、どのような専門家があなたのために手配されているかを理解するには、3か月の試用期間で十分です。 確かに、ロシア連邦の不便な労働法は、労働者の親切な性質によって完全に補償されています-彼らのほとんどが、「あなたは私たちに合わない」と言うなら、彼ら自身の自由意志の声明を書くことに同意します。



おそらくそれだけです。 コメントに自分の希望を追加することを同僚に提案します。



従業員がお茶を飲んだり、仕事に遅れたり、ミスにscられたり、マネージャー以上の収入を得たりすることを提案していると私に言っているように思える場合、開発者は何も理解していません。 これらのルールには独自の範囲があり、過剰摂取はまさにあなたの考えにつながります。 しかし、創造的な雰囲気とアナーキーを隔てるこの境界線を感じる能力は、開発部門の優れたリーダーの指標です。