プログラマーと管理

プログラミングフォーラムにアクセスすると、仕事をしている企業の問題の組織について人々が話し合うという事実に常に遭遇します。 そして、しばしば非常に不快なトーンで。



さらに、私自身、偶然にも、有能な開発者から、チームのやる気と明るい未来への信念を損なうリーダーシップによる深刻な管理ミスについて、突然手紙を受け取りました。 手紙は通常、一連の状況の分析を提供し、その後、著者は疲れていて、会社で働く機会が自分自身にないと報告した。 私は素朴ではなく、おそらく、開発者は別の場所のどこか、たとえば、より魅力的な財務見通しを見たことを理解しています。 ただし、単純化しないでください-まったく同じ給料で別の会社に転勤することもありますが、損失が発生しても（私たちと私たちから）起こりました。



チームは貴重な従業員を失うため、開発者の退任は常に非常に動揺するだけではありません。 当社はすでにこの従業員の義務を引き受けており、これらの義務を履行しないと、多くの罪のない仲間に時間通りに給料を支払うことができないまで、さまざまなトラブルで会社を脅かすため、出発が重要になる可能性があります。



開発者は会社の「グローバル」なビジネスプロセスの仕組みについてかなりあいまいな考えを持っていることが多いことを発見したので、作業を整理しようとしている人々が直面している問題を開発者に説明し、それを「平和な軌道」に向けることに決めました。



構造を管理する場合、管理者は構造自体と構造内で発生するプロセスの両方を変更するさまざまな決定を行う必要があります。 これはプログラミングに非常に似ています。 プログラムを高速化する必要があると仮定します-これはクライアントによって必要とされます、さもなければ彼はそれを買いません。 あなたはこれをどのように達成できるか考え始めます。 それらをテストするためのアイデアがあり、コードを変更する必要があります。これを行うときは、管理上の決定を下します。 マネージャーはまったく同じことを行います。管理対象システムの一部、つまり従業員の対話アルゴリズムにコードを変更します。 確かに、システムはプログラムよりもはるかに複雑です。なぜなら、心理学、感情、正義感などの要素がまだ残っているからです。



すべてのソリューションが成功するわけではありません。 まさにプログラマーのようです。 特定のケースでのコードのいくつかの変更は、プログラムの劣化につながり、時にはクラッシュすることもあります。 確かに、マネージャーとは異なり、プログラマーは自分のプログラムを何度も実行して、何が起こるか、どのように機能するかを見ることができます。 しかし、これらの場合でも、私たちの実践が示すように、コードには多くの重要な、さらには重大なエラーが含まれることがあります。 次に何が起こるか。 コードはテスター、他のスペシャリスト（実装者、プロジェクトマネージャーなど）によって徹底的にテストされ、発見された欠陥を通知するため、修正する機会が与えられます。



ただし、この後でも、クライアントから新しいエラーが発生する場合があります。 彼はそれらを報告します。 テスターはそれらをローカライズします-そして、次の情報がプログラマーに届きます：プログラムのそのような場所では、そのような、そしてそのような不快な結果につながるそのようなそのようなエラーがあります。



ここで、コードで検出されたエラーについて誰もが黙っていて、何も言わないことを想像してください。 しかし、一方で、彼らは次のように推論して、ますます多くのエラーに腹を立てています：

「まあ、それは何ですか？ この男はますますミスを犯しています！ これらのバグを含むソフトウェアを提供するにはどうすればよいですか？ 間違いの連続です！ はい、彼は私たちをまったく尊敬していません！ 彼と一緒に仕事をする私たちのモチベーションはどんどん下がります...」

最後に、決定が下されます。「これはもう許容できません！ 彼とはもう働きたくない！」

プログラマーでこれを行うのは正しいと思いますか？ エラーや改善の必要性についてのフィードバックなしに、良いコードを入手できますか？ このアプローチで良い結果を達成する見込みはありますか？ 答えは明らかだと思います。



しかし、マネージャーはそのような状況にあります。 彼はプログラマーのようにさまざまなミスを犯しますが、管理コードの消費者である彼の部下は、ほとんどの場合、頑固に無言でresり、resり、無言です。 そして、彼らは解雇を発表します。



クライアントが何も報告せずに最初にソフトウェアで長い間ミスをしてから、最終的には送信してください。このようなエラーはもう許容できないためです。



普通じゃないと思う。 正しい状況は、クライアントとの協力であり、クライアントはバグを指摘し、状況を改善する方法を提案します。そして、一緒になって、私たちは現在、世界のトップ企業を買収しているまともな製品を得ます。



管理にもまったく同じことが当てはまります。 クライアントのニーズに応じて、改善を追求するために、会社を変更し、さまざまな経営判断を下し、コードを変更する必要があります。 時には間違いを犯します。 プログラマーは、あなたが正しいコードを数千行書くことができ、プログラム全体を動作不能にするさらに数行を書くことができることを知っています。 この避けられない迷惑に対処するためのレシピは簡単です。エラーを検出し、エラーについて通知し、ローカライズ、修正します。



管理にもまったく同じことが当てはまります。 プログラマーのようなマネージャーは、常に間違いを犯します。 しかし、フィードバックのおかげで、彼らはそれらを修正することができます。 そして、部下とともにシステムをより効率的にすることで、より良い仕事とより多くの収入を得ることができます。



常に存在するショックと非常に誠実な悔しさにもかかわらず、私は、私が説明した誤解にほとんど慣れていました

手紙の始まり（何十回も起こったから）。 しかし、複雑なシステムを作成した経験のあるプログラマーの素朴な信念には常に驚かされます。すべてが管理上正しくなければならず、マネージャーは間違いを犯すべきではないということです。 そして、会社の現実がそうでない場合、彼らは気分を害します（まあ、または彼らのモチベーションが下がります-あなたが呼びたいものは何でも）。



つまり、クライアントは「みんな、ここに間違いがあります。訂正してください」とは言いませんが、彼は沈黙しており、自分のニーズや願望に対する態度が間違っているためにますます気分を害しています。 彼は、エラーのあるコードを彼に与えるのは不公平だと考え、実際に何千人もの人々が苦しんでいます。 しかし、彼はそれを公平だと考えています-それを私たちの詐欺と呼ぶこと。

私たちのクライアントが正しいものであると想像してください、私たちは、共同の努力を通じて、特定の困難を乗り越え、最終的には、ますます彼のニーズを満たす、本当に素晴らしいシステムを作成することができます。快適。



そして、黙って気分を害した場合、クライアントが必要なもの、快適なものを受け取ることは絶対に信じられません。 はい、私たちはすべてへそをかわしますが、結果は良くありません。なぜなら、無知と誤解によりますます多くの間違いを犯し、状況はますます悪化するからです。



これは、私たち自身が幸福の鍛冶屋であるという事実に書いています。 私たちは効果的に正しい方向に進むことができ、フィードバックがあれば開発の全員が満足して幸せになるようにし、システム-会社を改善するために協力します。



クライアントからは、製品に対する満足度と引き換えにサービスの料金を支払う必要があります。



開発者からは、当社での彼の仕事に対する満足と引き換えに効果的な仕事が必要です。



クライアントは、理想的には、月に20,000ルーブルで働き、必要なものを、できれば1年ではなく、数週間ですぐに配り、すべてがすぐに、エラーなく、愚かな質問もなく動作するようにしたい、彼はどのように良くなっていますか-どうにかして（「あなたは本当に私が欲しいものを知らないのですか？あなたは自分を専門家と呼びます！」）？



これは不可能であることを理解しています。 月に2万ルーブルは働きません。 天才でさえ、数週間で多くのことをしません。3人のチームが幸運で未知の困難が現れなければ、この仕事をするのに6か月を必要とするからです。 ただし、プログラムは数回の反復後にのみ必要に応じて機能し、多くのエラーを修正し、クライアントによって提案された多くの追加の改善を導入します。 しかし、私たちは請負業者と顧客の両方の良い最終結果に責任があること、この結果は共同の努力と妥協の結果としてのみ可能であり、最終的には正しいクライアントが彼が必要とするもの、彼を提供するものを受け取ることを認識していますライバルに対する競争上の優位性。



プログラマーは、理想的には15万ルーブルの支払いを希望しますが、処理は一切行われず、会社が必要とするものではなく、興味のあるものを実行できます。 また、コードの重大なエラーに対して会社が支払う必要のある罰金は、彼にまったく関係ないことが望ましい。 在庫の結果、新しい機器や家具などを購入するために30万ルーブルになった会社は、プロジェクトチームに簡単に説明する必要があります。プロジェクトチームはRFPをプログラマよりも少なく受け取りますが、プロジェクトの収入からボーナスを受け取ります。合計で10万ルーブル未満になります。 しかし、クライアントにまったくテストされていないコードを与えたプログラマーは、数百、つまり会社の損失の割合でさえ罰金を科せられません。プログラマーはいずれの場合も耐えませんでした（彼らが言うように、「開発者の罰金はやる気をなくします」）。



これは不可能であることを理解しています。 私たちは企業として価値があるので、このために何も犠牲にすることなく、より良くなることなく、卓越性への困難な道を通過せずに、クライアントが本当に多くを支払うことに本当に同意する状態まで、より大きな報酬を受け取ることは不可能です。 これを行うには、徐々に獲得するのが難しく、数回のフライトで簡単に失うという評判が必要です。



ミスに対する責任を常に回避することは不可能です。 会社の多くの人々が本当に道徳的に苦しんでいる場合（彼らが常にコミュニケーションを取り、仕事の成功に依存しているクライアントは、彼が一日中そこにいて、200人のエージェントと数十人のスーパーバイザーのそれぞれが働いていなかったため、彼を失礼だと見なします）今月、彼の給料の5％、および彼の利益の10％の所有者-そして誰もがそれらに怒っています）、そして重要な用語で：プロジェクトの収入は顕著に少なくなりました-そして彼らの報酬は顕著に少なくなりました。 プロジェクトチーム（これは多くの人々）に説明することは不可能であり、正直に働いており、気分を害したクライアントが道徳的および物質的な責任を負いました。誰がそれを許可しました。 コードがバギーではないという事実については話していないことに注意してください-それはまったくテストせずにクライアントに到達したという事実についてです。



この状況では、マネージャーは意思決定すらできません。 数十人の被害者が正義を求めていますが、彼らの問題の本当の犯人が少なくとも本当の、すなわち金銭的責任を共有しない場合、会社はひどく取り返しのつかないほど怒ります。



しかし、プログラマの場合、クライアントのように奇跡を待たなければ、一部の叔父のマネージャーが、彼が重要な責任を負いたくない同じ仕事のためにすべてを整理することを望んでいません。 、何らかの理由で、時間が経つにつれてますます多くの情報を受け取るようになりますが、逆にマネージャーに間違いを知らせ、問題のローカライズを支援し、ソリューションのビジョンを提案します。その後、反復的なソフトウェア作成の場合のように、組織を繰り返し改善します、私たちの責任と私たちの動機 ション。 このような困難を抱えながら、今日獲得したリーダーシップを強化します。 そして、顧客は私たちにもっと喜んで支払います。 また、ZPプログラマーは、その効果が高まるため、本当に成長します。 個々のスキルの成長だけでなく、作業のより正確で合理的な組織化のためでもあります。 結局のところ、賃金の成長のための最善の戦略は、効率と品質を高めることです。



リーダーの位置を示すこのようなよく知られた例があります。 ゴルフチャンピオンシップでは、勝者の賞金プールは100万40万ドル、2位の勝者には6万、3位には1万2千だけです。 さらに、最初の結果は2番目の結果よりもわずか0.5パーセント、3番目の結果よりも1.5パーセント優れています。 ビジネスでもまったく同じルールが適用されます。 リーダーは、2番目のリーダーよりも数パーセント優れていますが、何倍もの報酬を受け取ります。 最初に努力する必要があります-そして報酬は長くかかりません。 私たちは、誰もがお互いに非常に依存している非常に複雑なビジネスを行っています。 たぶん40人が一生懸命に努力し、一生懸命、正直に働き、1人の間違った行動が多くの人の仕事を台無しにします。 軟膏のハエに関することわざを覚えていますか？ 私たちは21世紀に住んでおり、タールが何であるかを本当に理解していません。 より明確に提案します。 樽全体に、小さじ1杯のたわごとが見られました。 それを知っているあなたがそれを食べたいと思うことはまずない。 特定のプログラマーの仕事の結果は、開発者、実装者、マネージャーのチーム全体の仕事の結果に劇的に影響を与える可能性があります。 多くの人がこの個々の責任に依存している場合があるため、開発者の個々の責任を高める方法を一緒に見つけられたら素晴らしいと思います。 エンジンを組み立てるためのセクションの1つにある車のコンベヤーに、技術に違反してシリンダーブッシングが取り付けられていると想像してください。 他のすべての人の勤勉な仕事に関係なく、結果は結婚であるため、この妨害は、プロセスの他のすべての参加者の正直な仕事を過小評価します。

私の観点からの正しい方法は、責任の免除を要求しないことです。 それにもかかわらず、彼女は来て、彼女から解放されることができないので、あなたは彼女を他の人に変えることができるだけです。 「罪のない者への罰、招かれざる者への報い」を覚えていますか？ これは間違った、悲惨な戦略です！ 私たちのすべてが本当に良いので、この責任が発生しないように組織する必要があります。



私たちが存在する条件は客観的です。 そして、システムをより良くし、機能を追加し、パフォーマンスを向上させ、ロジックのコーナーをカットしたいという欲求から、マネージャーはプログラマーと同様に、正当な理由で間違っています。 管理上の誤りを修正することによってのみ、システムを改善し、人生をより面白く、より快適にすることができます。



制御を使用したプログラミングのもう2つの類似点。 多くの場合、決定はプログラムコードと同じ方法で調整する必要があり、これには管理決定の消費者、つまり従業員からのフィードバックが必要であるという事実は、私たちはすでに理解していると思います。



お客様は、修正できない重大なエラー/問題を見つけることがあります。 時々、「システム全体を変更する」という冗談のように、ミス/問題を解決するために、真剣な努力と多くの時間が必要になることがあります。 愚かなクライアントは時々理解しません：「私は3週間前に問題についてあなたに知らせました、しかしそれはまだ修正されていません！ あなたは何もしていません！」 彼は、私たちに一連の開発タスクがあることを理解できないことがあり、すべての問題を一度に解決することはできません。 問題が複雑であり、多くの月と多くの相互依存サブシステムの変更が必要であること。 彼が忍耐力を持っているなら、結局、彼は彼が必要とするものを手に入れるでしょう。 そして、彼のシステムは競争よりも優れているでしょう。 クライアントが次のような立場をとった場合、結果が良好になることはまずありません。「私はクライアントであり、したがって常に正しい。 あなたの問題を私に負担させないでください-私を幸せにしてください。」 クライアントがあまりにも遠い場合（これが当てはまる場合は残念です）、テスターが何も説明せず、エラーを示さず、ただ彼を幸せにするように要求するテスターを想像してください。 さらに、次の水曜日までです。 この状況には通常の建設的な見通しがありますか？



ここで、従業員が黙っていなくても、これはすべての問題を解決するのに十分ではありません。 多くの従業員は改善に真剣に関心を持ち、マネージャーに問題に関するフィードバックを提供します。 彼女は非常に有用であり、マネージャーにこれらの問題を認識させ、解決策を探させます。 しかし、私はしばしば次のことを聞きます-「5月にこの問題について話しましたが、まだそこに起こっています-この会社では何も起こりません」（「したがって、私たちのモチベーションは着実に低下しています」）！



しかし、クライアントのこの問題は2週間では解決できないことをクライアントに伝えないでください。チーム全体の持続的で長い努力が必要です。 そして時には（悪夢です！）私たちは問題を認識していますが、その対処方法をまだ理解していません。 しかし、私たちは間違いなく思いつきます（まだそうではなかったので、最終的には、私たち自身が設定したタスクを解決しませんでした！）。 道を見つける手助けをする必要があり、忍耐する必要があります。 – , .



70 . 250 . , . , , , , , – , . , — , – … . , , . , , . .



, , - , , , , , . , , , - . , , , .



, : « , . ?». – , : «. . ». , , . - , ( ) .



: , , – , . , , – , .