著書に『知識人のマネジメント方法。 私、オタク、オタク」

プロジェクト マネージャー (および上司になることを夢見ている人) に捧げます。

大量のコードを書くのは大変ですが、人を管理するのはさらに大変です。 したがって、両方の方法を学ぶにはこの本だけが必要です。

面白い話と真剣なレッスンを組み合わせることができますか? マイケル・ロップ (狭い範囲ではランズとしても知られる) が成功しました。 信じられないほどやりがいのある (架空ではありますが) 経験を持つ架空の人々についての架空の物語が見つかります。 ランズ氏は、Apple、Pinterest、Palantir、Netscape、Symantec などの大手 IT 企業で長年働いてきた中で得た、さまざまで、時には奇妙な経験をこのように共有しています。

あなたはプロジェクトマネージャーですか? それとも、上司が一日中何をしているのか知りたいですか? ランドは、インフレした七面鳥の有毒な世界で生き残り、機能不全に陥った派手な人々の一般的な狂気の中で繁栄する方法を教えます。 狂った頭脳派のこの奇妙なコミュニティには、さらに奇妙な生き物がいます。神秘的な組織儀式を通じて、多くの人々の計画、思考、銀行口座を支配する権力を手に入れた管理者です。

この本は、マネジメントやリーダーシップの原稿とは異なります。 マイケル・ロップは何も隠さず、ありのままを語ります（おそらくすべての話を公開すべきではないでしょう：P）。 しかし、この方法でのみ、そのような上司の下で生き残る方法、オタクやオタクを管理する方法、そして「あの忌まわしいプロジェクト」をハッピーエンドに導く方法を理解することができます。

抜粋。 エンジニアリングの考え方

考察: コードを書き続けるべきか?

管理者のためのルールに関するランズの本には、現代の管理者の「やるべきこと」の非常に短いリストが含まれています。 このリストの簡潔さは、「しなければならない」という概念がある種の絶対的なものであり、人間に関しては絶対的な概念がほとんどないという事実に由来しています。 ある従業員にとっては成功した管理方法でも、別の従業員にとっては大惨事となるでしょう。 この考えは、マネージャーの「やるべきこと」リストの最初の項目です。

柔軟性を保ちましょう！

もうすべてを知っていると考えるのは非常に悪い考えです。 世界が常に変化しているという唯一の変わらない事実がある状況では、柔軟性が唯一の正しい立場になります。

逆説的ですが、リストの XNUMX 番目の項目は驚くほど柔軟性がありません。 しかし、この点は経営成長の基盤を作るのに役立つと考えているので、個人的に気に入っています。 この段落には次のように書かれています。

コードを書くのはやめてください!

理論的には、マネージャーになりたい場合は、自分のために働いている人たちを信頼し、コーディングをすべて彼らに任せることを学ばなければなりません。 このアドバイスは通常、特に新しく就任したマネージャーにとっては理解しにくいものです。 おそらく、彼らがマネージャーになった理由の XNUMX つは、開発の生産性のためであり、物事がうまくいかなかった場合、彼らの最初の反応は、完全に自信を持っているスキル、つまりコードを書く能力に頼ることです。

新しく任命されたマネージャーがコードの作成に「夢中」になっているのを見ると、私は彼に次のように言います。 問題は、あなたがリーダーシップを発揮できるかどうかです。 あなたはもはや自分自身に対してだけ責任を負うのではなく、チーム全体に対して責任を負います。 そして、自分でコードを書かなくても、チームが自分たちで問題を解決できるようにしたいと考えています。 あなたの仕事は、自分自身をスケールする方法を見つけることです。 私はあなたに一人であってほしいのではなく、あなたのような人がたくさんいてほしいのです。」

良いアドバイスですよね？ 規模。 管理。 責任。 そんなよくある流行語。 アドバイスが間違っているのは残念です。

正しくない？

うん。 そのアドバイスは間違っています！ 完全に間違っているわけではありませんが、元同僚に電話して謝罪しなければならないほど間違っていました。「コードを書くのをやめるべきだという私のお気に入りの言葉を覚えていますか?」 それは間違っています！ はい...プログラミングをやり直してください。 まずはPythonとRubyから始めましょう。 そうです。私は本気です！ あなたのキャリアはそれにかかっています！」

私がボーランドでソフトウェア開発者としてキャリアをスタートしたとき、私は大規模なチームだった Paradox Windows チームで働きました。 アプリケーション開発者だけでも 13 名いました。 コア データベース エンジンやコア アプリケーション サービスなど、このプロジェクトの主要なテクノロジに常に取り組んでいた他のチームのメンバーを追加すると、50 人のエンジニアがこの製品の開発に直接関与することになります。

私がこれまで働いた中で、この規模に近いチームは他にありません。 実際、年を追うごとに、私が所属するチームの人数は徐々に減っていきます。 どうしたの？ 私たち開発者は集合的にますます賢くなっているでしょうか? いいえ、私たちは負荷を共有しているだけです。

過去 20 年間、開発者は何をしてきたのでしょうか? この間、私たちは大量のコードを書きました。 コードの海！ 非常に多くのコードを作成したため、すべてを簡素化してオープンソースにするのが得策であると判断しました。

幸いなことに、インターネットのおかげで、このプロセスは可能な限り簡単になりました。 ソフトウェア開発者の方は、今すぐチェックしてみてください。 Google や Github で自分の名前を検索すると、長い間忘れていたものの、誰でも見つけられるコードが表示されます。 怖いですよね？ コードは永久に存続することをご存知でしたか? はい、彼は永遠に生きます。

コードは永久に存続します。 そして、優れたコードは永遠に存続するだけでなく、それを評価する人々が常に最新の状態を保つようにするため、成長していきます。 この高品質でよく管理されたコードの山は、新しいコードを書くのではなく既存のコードに集中でき、より少ない人数でより短い時間枠で仕事を完了できるため、エンジニアリング チームの平均規模を縮小するのに役立ちます。

この一連の推論は気が滅入るように聞こえますが、その考えは、私たちは皆、ダクトテープを使って既存のもののさまざまな部分を接続し、同じもののわずかに異なるバージョンを作成する統合オートマトンの集団にすぎないということです。 これは、アウトソーシングを好む上級管理職の間の古典的な考え方です。 「Google の使い方を知っていてダクトテープを持っている人なら誰でもこれを行うことができます。 では、なぜ私たちはマシンに多額のお金を払っているのでしょうか?」

私たちは経営者たちに大金を払っていますが、彼らはそんなナンセンスなことを考えています。 もう一度言いますが、私が重要なのは、地球上には優秀で非常に勤勉な開発者がたくさんいるということです。 彼らは認定された大学に一分間も座ったことがないにもかかわらず、本当に優秀で勤勉です。 そうそう、今ではその数がどんどん増えています！

何人かの優秀な同志がその場所を探しているとされるからといって、自分の場所について心配し始めることはお勧めしません。 ソフトウェア開発の進化はおそらくあなたよりも速く進んでいるので、それについて心配し始めることをお勧めします。 あなたは XNUMX 年間働いており、そのうち XNUMX 年間はマネージャーとして働いており、「ソフトウェアがどのように開発されるかはすでに知っている」と考えています。 そうだよ知ってるでしょ。 さよなら…

コードを書くのはやめてください、でも...

私の最初のアドバイスに従ってコードを書くのをやめた場合、作成プロセスへの参加も自発的にやめることになります。 このような理由から、私はアウトソーシングを積極的に利用しません。 オートマトンは創造するのではなく、生産するのです。 適切に設計されたプロセスは多額の費用を節約しますが、私たちの世界に何も新しいものをもたらしません。

少ないお金で多くのことをやっている小さなチームがある場合、コードを書くのをやめるという考えは、私にとってキャリア上の決断としては間違っているように思えます。 際限のない規制、プロセス、ポリシーを持つモンスター企業であっても、ソフトウェアを自分で開発する方法を忘れる権利はありません。 そしてソフトウェア開発は常に変化しています。 それは今変わりつつあります。 足元に！ この瞬間に！

あなたには異論があります。 理解する。 聞いてみましょう。

「ランズ、監督の椅子に向かっています！」 私がコードを書き続けても、私が成長できるとは誰も信じないでしょう。」

これをお聞きしたいのですが、「私はもうすぐ CEO になります!」という椅子に座って以来、社内でもソフトウェア開発の状況が変化していることに気づきましたか? あなたの答えが「はい」の場合は、別の質問をします。具体的にはどのように変化しているのでしょうか、また、これらの変化に対して何をする予定ですか? 私の最初の質問に「いいえ」と答えた場合は、別の椅子に移動する必要があります。なぜなら、(きっと!) ソフトウェア開発の分野は今この瞬間にも変化しているからです。 ソフトウェアの開発方法をゆっくりと、しかし確実に忘れてしまったら、どうやって成長できるのでしょうか?

私のアドバイスは、次の製品に大量の機能を実装することにコミットしないことです。 チームがソフトウェアをどのように構築しているかを常に把握するための措置を常に講じる必要があります。 これは取締役としても副社長としても行うことができます。 他に何か？

「うわ、ランズ！ しかし、誰かが裁定者にならなければなりません！ 誰かが全体像を見なければなりません。 コードを書くと、視点を失ってしまいます。」

あなたは依然として審判でなければならず、決定をブロードキャストしなければならず、毎週月曜日の朝、エンジニアの一人と一緒に建物の周りを30回歩き回り、彼の毎週の「私たちは皆運命にある」という暴言をXNUMX分間聞かなければなりません。分です。 しかし、それ以上にエンジニアリングの考え方を維持する必要があり、それを行うためにフルタイムのプログラマーである必要はありません。

エンジニアリングの精神を維持するための私のヒント:

1. 開発環境をご利用ください。 これは、コード ビルド システム、バージョン管理、プログラミング言語など、チームのツールに精通している必要があることを意味します。 その結果、チームが製品開発について話すときに使用する言語に習熟できるようになります。 これにより、完璧に機能するお気に入りのテキスト エディターを引き続き使用することもできます。
2. 製品を説明する詳細なアーキテクチャ図を、いつでも任意の表面に描画できなければなりません。 ここで私が言っているのは、XNUMX つのセルと XNUMX つの矢印を備えた簡略化されたバージョンのことではありません。 製品の詳細図を知っておく必要があります。 最も難しいことです。 単なるかわいい図ではなく、説明するのが難しい図です。 製品を完全に理解するのに適したマップである必要があります。 それは常に変化しており、特定の変化がなぜ起こったのかを常に知っておく必要があります。
3. いずれかの関数の実装を引き継ぎます。 このポイントには多くの隠れた危険があるため、これを書いているときは文字通りひるみますが、少なくとも 1 つの機能を実装することを約束せずにポイント #2 とポイント #XNUMX を達成できるかどうかは本当にわかりません。 機能の XNUMX つを自分で実装することで、開発プロセスに積極的に参加できるだけでなく、「すべてを担当するマネージャー」の役割から「機能の実装を担当する人」の役割に定期的に切り替えることができます。機能の説明。」 この謙虚で控えめな姿勢は、小さな決断の大切さを思い出させてくれます。
4. まだ全身が震えています。 すでに誰かが私に「機能の実装を引き受けた管理者が!?」と怒鳴っているようです。 （そして私も彼の意見に同意します！） はい、あなたはまだマネージャーです。つまり、それは小さな役割であるはずです、いいですか？ はい、やるべきことはまだたくさんあります。 関数の実装を引き受けることができない場合は、いくつかのバグを修正するという予備のアドバイスがあります。 この場合、ものづくりの喜びは感じられませんが、製品がどのように作られるのかは理解できるので、仕事から外されることはありません。
5. 単体テストを作成します。 私は今でも、制作サイクルの後半、人々がおかしくなり始めるときにこれを行っています。 これを製品の健康チェックリストと考えてください。 これを頻繁に行ってください。

また異議ありますか？

「ランズ、私がコードを書いたらチームを混乱させるでしょう。 彼らは私が誰なのか、マネージャーなのか開発者なのか知りません。」

わかりました。

はい、私は「わかりました！」と言いました。 開発者の池で泳ぐだけでチームを混乱させることができると考えてくれてうれしいです。 それは簡単です。ソフトウェア開発におけるさまざまな役割間の境界は、現在非常に曖昧になっています。 UI 担当者は、広く言えば JavaScript および CSS プログラミングと呼ばれるものを行います。 開発者はユーザー エクスペリエンス デザインについてますます学んでいます。 人々は互いにコミュニケーションをとり、バグや他人のコードの盗難について学び、また、管理者がこの大規模で世界規模の相互受粉情報のバカ会に参加しない正当な理由がないという事実についても学びます。

さらに、簡単に交換可能なコンポーネントで構成されるチームの一員になりたいですか? これにより、チームの機敏性が高まるだけでなく、各チーム メンバーに製品や会社をさまざまな視点から見る機会が与えられます。 ビルドを担当する穏やかな男、Frank のビルド スクリプトのシンプルで優雅さを見た後以上に、どうして彼を尊敬できるようになるでしょうか?

私はあなたのチームが混乱して混乱することを望んでいません。 逆に、私はあなたのチームがより効果的にコミュニケーションできるようにしたいと考えています。 製品の作成や機能の開発に携われば、チームとの距離が近くなると思います。 さらに重要なことは、組織内のソフトウェア開発プロセスの継続的な変化に近づくことです。

開発をやめないでください

ボーランドの同僚はかつて、彼女を「プログラマ」と呼んだことで私を口頭で攻撃しました。

「ランズ、プログラマーは思考力のない機械だ！ 猿！ コーダーは、役に立たないコードの退屈な行を書くこと以外、重要なことは何もしません。 私はプログラマーではありません、ソフトウェア開発者です!」

彼女は正しかった。新任 CEO に対する私の最初のアドバイス「コードを書くのはやめなさい!」は嫌いだっただろう。 それは、私が彼らがプログラマーであることを示唆しているからではなく、彼らが仕事の最も重要な部分の XNUMX つであるソフトウェア開発を無視し始めていることを積極的に示唆しているからです。

そこで、アドバイスを更新しました。 良いリーダーになりたければ、コードを書くのをやめても構いませんが...

柔軟です。 エンジニアであることが何を意味するのかを思い出し、ソフトウェアの開発をやめないでください。

著者について

Michael Lopp は、まだシリコンバレーを離れていないベテランのソフトウェア開発者です。 過去 20 年間にわたり、マイケルは Apple、Netscape、Symantec、Borland、Palantir、Pinterest など、さまざまな革新的な企業で働いてきましたが、ゆっくりと忘れ去られていく新興企業にも参加しました。

マイケルは仕事以外では、ランズというペンネームでテクノロジーと経営に関する人気ブログを運営しており、そこで読者と経営分野のアイデアについて議論し、最新情報を常に把握しておく必要があることについて懸念を表明し、次のように説明しています。製品の作成には寛大な報酬が与えられますが、あなたの成功はチームのおかげでのみ可能です。 ブログはここからご覧いただけます www.randsinrepose.com.

マイケルは家族とともにカリフォルニア州レッドウッドに住んでいます。 忙しいよりも健康であることが重要であるため、彼はいつも時間を見つけてはマウンテンバイクに乗ったり、ホッケーをしたり、赤ワインを飲んだりしています。

» この本の詳細については、こちらをご覧ください。 出版社のウェブサイト
» 目次
» 抜粋

Khabrozhiteley の場合、クーポン使用で 20% 割引 - 管理人

紙版の書籍の支払いが完了すると、電子版の書籍が電子メールで送信されます。

PS: 本の価格の 7% は、新しいコンピューター本の翻訳、印刷所に引き渡された本のリストに充てられます。 ここで.

出所： habr.com