Googleエンジニアのヒント

みなさんこんにちは！



私の名前はラリサです。 私はこの記事を最初に公開したlarrr.comの Googleとブログで働いています。



今日は、元々Googleによる内部使用専用に書かれた記事に注目します。 私はそれが本当に好きだったので、著者に連絡し、彼女の許可を得て少し編集し、Google Pressから公開の許可を得ました。 私の翻訳。



念のため、これは公式のGoogleドキュメントではなく、Googleはそのコンテンツについて責任を負いません。 それは主観的であり、従業員のために従業員によって書かれています。



エンジニア向けのヒント



2013年4月15日

2014年5月21日編集

2015年8月31日翻訳

Gretta Bartels、Googleのソフトウェアエンジニアリングマネージャー



親愛なる読者、



このドキュメントでは、チームでの作業に依存する原則のいくつかを説明しました。 それらには根本的に新しいものや革命的なものは何もありません;これらの原則はすべて私たち一人一人に長い間知られています。 しかし、知ることと行うことは2つの異なるものです。 したがって、このドキュメントは、自分のマネージャーの仕事はこれらの原則を自分で守り、他の人に思い出させることであるということを私自身に思い出させるものでもあります。



私の経験豊富な同僚の一人は、マネージャーが非常に予測可能であることが非常に重要であることを教えてくれました。 マネージャーには、部下全員が知っており、マネージャーが近くにいない場合でも従うことができるいくつかの簡単なルールが必要です。 したがって、私の目標は、私のチームのプログラマーが「マネージャーはこれに対して何を言うでしょうか？」という質問を自問し、自分の質問に正しく答えることです。 その後、チームは私の指導なしでほぼ​​独立して作業できるようになります。 そして、私は家に座ってケーキを食べます:)。



これが私の基本的なルールのリストです。



1.本当に重要な仕事をする



1a）「なぜ私たちはこれをしているのですか？」



あなたが何をするにしても、誰もが常に2つのことを明確に知っている必要があります-1）なぜあなたはこれをしているのですか？ 2）目的の結果を達成したことをどのように理解しますか？ 「なぜ？」という質問に対して自分で答えられるように思えたとしても、最初の適切な答えで止まらないで、もっと深く見てください。 答えが単純で明白であると同時に、非常に野心的なものになるまで、この質問を何度も自問してください。



これは、技術者が「なぜ？」という質問を何度も自問し、問題の原因を見つけるために答えをさらに深く掘り下げる「 5なぜ 」という方法に似ています。 しかし、私たちのケースでは、問題の原因を見つけるだけでなく、あらゆる方法でこの方法を使用することを提案します。



そして、ここに人生の例があります。 私のチームの1人は現在、Googleマップのデータの品質の改善に取り組んでいます（つまり、データの内部的な矛盾を見つけて解決します）。 この場合、「理由」チェーンは次のようになります。



データの不整合を排除します

->既存のデータと新しいデータをより簡単かつ迅速に統合できるようにするため

->データをより速く更新できるように

-> Googleマップをできる限り正確にする

-> Googleマップの品質が非常に高い基準とユーザーの要件を満たしていることを確認する

->人々がGoogleマップ（およびGoogle製品全般）を積極的に使用および信頼できるようにするため



とてもシンプルに見えますよね？ しかし、私の経験に基づいて、すべてのエンジニアがこれらの質問を自問するわけではなく、彼らが取り組んでいる特定の孤立したタスクを超えて見ることができます。



実際、「なぜ」を理解することはあなたの仕事にとって非常に重要です。 叫ぶことは重要だと思います。

• この理解がなければ、仕事の結果を評価することははるかに困難です。 そして、絶えず変化するプロジェクト要件に適応することははるかに困難です。その結果、あなたがしていることが本当に重要であることを経営者に証明する必要があるかもしれません。
  
  
• さらに、この方法では、同じ基本的な目標を追求する他の人々やチームを見つけることができます。 サポートと同盟国を見つけることができますが、その重要性を過大評価することは非常に困難です。
  
  
• さらに、既存のプロジェクトに優先順位を付けることができます。

ところで、あなたの「なぜ？」に対するいくつかの答えがあるかもしれません。 これは良い兆候です。おそらくあなたのプロジェクトは本当に重要です。



もう1つの重要なことは、特にマネージャーにとって：「なぜ」チェーンを使用すると、何かをする理由とその方法をよりよく理解できるだけでなく、プロジェクトのその他の戦略的開発領域を確認することもできます。 チェーンのもう一方の端から行って、「どのように？」という質問を自問してください。

1b）最も重要なことは結果です



マネージャーとして、私は次のパラメーターによって従業員を評価します：知識と経験、難易度、リーダーシップと結果。 それらはすべて専門能力開発とキャリアの成長にとって重要ですが、パラメーターの1つは他のパラメーターよりもはるかに重要です。 これが結果です。



ほとんどの企業は、プログラマー向けのトレーニングおよび開発サイトではありません。 これらは働く企業であり、まさにそのために、私たちは彼らで働くことができます。 ところで、私は個人的にこの組み合わせが本当に好きです-ビジネスとテクノロジー。 私は世界を変えるものに取り組むのが好きです。 そして、このテーマについて私が話をした多くのエンジニアも。



奇妙なことに、結果は残りのパラメーターからは続きません。 あなたは、非常に複雑で興味深いタスクに取り組むチームの、スマートで経験豊富な知識豊富なカリスマ的なマネージャーまたは技術チームになることができます。 戦略的な重要性をまったく持たないタスク。 一方で、知識がなくても、または優れたリーダーでなくても、価値のあるものを作成することはほとんど不可能です。



ところで、複雑さについて。 重要な結果を達成するために、複雑なことをする必要はありません。 これは正常です。 機会があれば、常にシンプルで重要なプロジェクトを常に探してください。



1c）計画は役に立たないが重要



OKRを信じています（目的と主要な結果-目標と主要な結果-プロジェクト管理のための現代の管理で使用される方法。チームと個人の目標を同期し、タスクの実装を効果的に制御できます。Wiki）。 チームのすべてのエンジニアに、四半期ごとに作成して評価するようお願いします。



目標を書くことには多くの利点があります。 しかし、私は最も重要なことはこれだと思います：あなたの時間は限られている、そしてあなたは最も利益をもたらすものでそれを取るべきです。 さらに、計画の質を大幅に改善できます。 戦略的計画がなければ、2つの非常に一般的なtrapに簡単に陥ることがあります。四半期にどれだけ稼げるかを過大評価し、重要な問題ではなく緊急の問題にdrれます。 ただし、計画を立てることでそれらにアクセスすることもできますが、それらを認識してそれらから抜け出すのははるかに簡単です。



重要なことをするのではなく、緊急のことをするという状況は多くの人によく知られています。 この記事では、このトピックについて詳しく説明しています。 興味があれば読んでください。



さらに興味深い問題は、彼らの能力の再評価です。 マネージャーとして、私はエンジニアの評価をより正確に支援する必要があります-私の経験では、多くの人々は一定期間にできる仕事の量を大きく過大評価しています。 人々が多くの目標を設定し、それぞれ30〜50％を達成したが、計画された結果に目標をもたらさない場合がありました。 2つまたは3つの目標を100％にする方がはるかに良いでしょう。



書面による計画と四半期後の結果の評価を使用して、多くの人が目標を設定して達成するスキルを大幅に向上させることができます。 生産性を大きく変えることなく、より現実的な予測を行い、いくつかの本当に重要なことを終わらせます。 それが、私のチームにとってOKRが非常に重要だと思う理由であり、できるだけ多くの人がこのスキルを習得することを願っています。



2.無駄に時間を無駄にしないでください



2a）スピードアップ（別名、いくつかのテストはどうですか？）



大学での研究中に、テスト作業として、美しいインターフェイスを備えたBoggleゲームを作成し、複数のユーザーのリモートゲームをサポートする必要がありました。 当然、変更の最終日まで指を離すことさえしませんでした。 午前3時に、急いで書かれたプログラムに、ゲームの最後にクロールするバグが含まれていることがわかりました。



そのため、残りの夜はゲームをプレイし、バグを繰り返してその原因を見つけようとしました。 もちろん、それは少なくとも愚かだった。 ゲームタイマーを5秒に設定するだけで、事態はさらに速くなります。 私の防御では、午前中だったと言いたいです、私は本当に眠りたかったです、そして私のプログラムのエラーを探しません。 テストを書くことはさらに良いことですが、テストについては聞いていませんでした。



プログラムの一部を何度も繰り返し、間違いを見つけて修正しようとするたびに、これらの繰り返しができるだけ短くなるようにすべてを行います。 ほとんどの場合、これはあなたにとって不必要に思えます。なぜなら、最初にエラーを見つけたことを確信できるからです。 しかし、これはめったに起こりません。 たぶん、これはそうではないことにすぐに気付くでしょう。そして、あなたは再びプロセスを繰り返さなければなりません。 そして再び。



したがって、プロジェクトで作業するときは、できるだけ簡単にテストできるようにしてください。 モジュール化して、プログラムの任意の部分をできるだけ簡単に分離してテストできるようにします。 私を信じて、あなたがそれをしたことがうれしい時が来るでしょう。 モジュール性と断熱性に問題がある場合、これは、設計が原則としてどれほど優れているかを考える十分な理由です。



同様の原則が、人と製品の取り扱いに適用されます。 不確実な状況にあるとき、少なくともいくつかの予備データを提供する迅速で簡単な実験を行う方法を考えてください。



2b）問題を完全に取り除く（別名Automate）



人々は、コンピューターがはるかに優れていることに時間を費やすべきではありません。 これについても議論されていません。



私たちは皆、プログラミングを行い、生活を楽にし、自動化できるものを自動化します。 エンジニアはこの原則を最大限に適用しようとするようです。 しかし、まったく違います！



多くの場合、同じ繰り返しタスクを自動化するのではなく、手動で繰り返し実行している人々を見てきました。 この状況の主な理由は、「数分で完了し、プロセスの自動化には1日かかります」です。 時々それは真実でさえありますが、見かけほど頻繁ではありません。



タスクの自動化：

• チームで作業を始めたばかりの人や自動プロセスでも、誰でもこのタスクに対処できます。 手作りの議事録は数時間、さらには数日ですぐに集まります。仕事は寝るとき、食べるとき、病気のときに始まります。
  
  小さなタスクを自動化すると、より広範な最適化の扉が開かれます。
• プロセス全体を自動化する前に、考えもしなかった状況を見つけることがあります。
• 後で自動化するためにプロセスを作成することにより、プロセス設計スキルを大幅に向上させることができます。

2c）開発



同じことをあまり長くしないでください。 ある領域をマスターしたら、それを自動化するか（上記を参照）、この作業のために別のエンジニアを訓練して先に進みます。 専門的に成長し、停滞しないでください。



自分の仕事が日常的であるように思われ、この日常を他の人に移したくないため、人々はこれをしないことがあります。 しかし、あなたにとって雑用に見えるかもしれないことは、別の、おそらく経験の浅いエンジニアのために何かを学ぶ絶好の機会になるでしょう。 これがそうでなくても、複数の人が特定のタスクを一度に理解している場合、チームにとってより意味がありそうです。 そうしないと、狭いリンクになる可能性があります。



他の人に説明するのが難しすぎると思われるため、または誰よりもうまく対処できると信じているために、人々は自分のタスクを保持することがあります。 これに該当する場合は、適切なドキュメントの作成を真剣に検討する必要があります。



チームのエンジニアに常に新しいタスクに切り替えて専門的に開発するようアドバイスしています。



3.真空で作業しないでください（別名：他者と通信）



事前に作業するシステムの設計を説明するようにしてください（設計ドキュメントを作成することもできます）。 これらのドキュメントを同僚に送信し、彼らの意見を聞いてください。 これにより、次のことができます。

• 独自の思考プロセスを合理化します。
• 他の誰かが同様のプロジェクトに関与していないことを確認してください。
• 同僚の役立つヒントを使用して、設計を改善します。
• あなたを助けることに同意する同僚を見つけるのははるかに簡単です。
• チームの活動的で責任あるメンバーとして自分自身を見せてください。

あなたの仕事について話します（スライドで可能）。 他の人を招待して、自分の仕事を共有してください。 自分や近隣のチームで他の人が何をしているかに積極的に関心を持ちます。 あなたとあなたのチームはこれの恩恵を受けるでしょう。



多くの人は、準備ができるまで自分の仕事について話したり書いたりしたくない。 または、彼らはただ書くのが好きではありません。 これらはかなり弱い言い訳です。 書きたくない場合、またはチーム全体ですぐにプレゼンテーションを行いたくない場合は、小規模から始めてください。特定の同僚と話をして、ボードにスケッチデザインを描きます。 これは、あなたの考えを整理するのに役立ち、ドキュメントを書いたり、グループ全体と議論したりするのがずっと簡単になります。



記事が気に入ったら、私のブログにアクセスしてください 。 おそらく、あなたはあなた自身のためにさらにもっと面白いものを見つけるでしょう。 私はすでにGoogle、キャリア、自己啓発、生産性に関する記事を300近くも持っています（その一部はかつてHabréについてでした）。 私は書くのが大好きで、私はかなりうまくやっていると思います。 少なくとも時々。

気に入っていただけたら嬉しいです！