リード開発者として成功するにはどうすればよいですか？
私は特定のプロジェクトの主任開発者になりましたが、全体像に集中し、プロジェクトのすべての部分がカバーされていることを確認するのが困難です。
このプロジェクトを管理するとき、何に注意すべきですか？すべてが適切に処理されるようにするにはどうすればよいですか？
他の開発者がシニアまたはリードに移行するときに、これが他の開発者を押し上げるのを見てきました。ここに私が他にしたいくつかの提案があります。
- プロジェクトの目標を理解する。
多くの場合、プロジェクトにプッシュされたすべての機能についてではありません。それは、ビジネスニーズに対処しているコア機能セットについてです。それが第一の目標なので、常にこれを覚えておいてください。
- タスクに実行する必要があるものの内訳。それらの間の依存関係を理解します。
プロジェクトを分解することはかなり簡単です。プロジェクトのできるだけ早い段階で分解してください。部品につやを付ける必要がある場合は、何をすべきかを理解するまで、部品がリスクをもたらすことを理解してください。
- プロジェクトの未解決の質問や曖昧さを理解します。
最初はすべてのあいまいさを解決することはできません（試行する必要があります）。マネージャーとプロジェクトの利害関係者が、彼らが何であり、彼らがプロジェクトにもたらすリスクを確実に理解してください。
- ビジネスは驚きを嫌っています。
誰もがプロジェクトのステータスを把握していることを確認します（理想的には毎日、ただし毎週作業します）。そして、ステータスとは、何が行われたか、何が残されたか、未解決の質問、問題などです。プロジェクトの完了に影響を与える可能性のあるものはすべて報告する必要があります。
- 毎日、全体像を把握します。
毎日1時間は全体像を把握する必要があります。質問してください。何が完了しましたか？あと何をすべきか？未解決の質問は何ですか？目標は何ですか？あなたは誰かが尋ねるときはいつでも誰かにプロジェクトの詳細なステータスを与えることができるはずです。
私があなたに与える最初のアドバイスは、チームを管理することは、自分のプログラミングタスクを行うことよりも重要であることを受け入れることです。つまり、3人のジュニアが助けを必要としているとき、それがどのようにして成長から離れているのかについて考えないようにするのはあなたの役目です。リードとして、最初に自分の開発タスクに集中しすぎていると、多くの場合、進行への障害となります。
さらに、委任を学ぶ必要があります。 1時間で簡単にできるタスクを誰かに与えることは困難であり、1日に失敗することがわかっています。ただし、タスクを取得しない限り進行することはなく、チームがゲームをプレイしている間は残業します。
さらに、他の誰かのコードを修正するだけでは決してなりません。何が悪いのか（そしてなぜなのか）を伝え、修正してもらいます。または、あなたはすべてを修正しなければならないサイクルに入るでしょう。彼らがそれを修正できない場合は、彼らがチームにとどまるべきかどうかを検討します。弱いチームメンバーがすべてを修正しているので、チームメンバーをそのままにしないでください。
リードとして、あなたは悪者になり、彼らに不快な知らせを与えます（チェーンの上下両方）。それは仕事にも当てはまります。つまり、パフォーマンスの評価を低くする必要があります。期限が上に移動されたか、要件が変更されたことを彼らに伝える必要があります。あなたは進歩していない怠惰な男をプッシュする必要があります。そして、締め切りに間に合わないときはいつ、何のために何をしているのかを上司に伝えなければなりません。リードされるということは、好きになることではなく、効果的であることです。あなたの仕事は友達を作るのではなく、ソフトウェアをドアから出すことです。コミュニケーションが鍵であり、悪い知らせを避けることは状況を悪化させることになります。クライアントは、発売日が過ぎてからさらに3週間が必要であると伝えるよりも、発売の1か月前に3週間前になると言われることを処理する可能性がはるかに高くなります。希望的思考で管理すること（徹夜で何とかして、それを成し遂げることができることを確認してください）は、私が知っている失敗への最も確実な道です。
これが私の非公式のチェックリストです。それはとても非公式です...私は毎日すべてを行うわけではありませんが、これらすべてを毎週ヒットしなかった場合は少し心配になり、毎月ヒットしなかった場合はパニックになるはずです。また、走行距離は、会社/チームの文化、個人のスタイル、プロジェクトのタイプに完全に基づいて異なります。
チームと個別に話す-チームの全員が-役立つ作業をしていますか？製品と現在のリリースの全体的な目標は何ですか？彼らはあなたがどのようにお金を稼ぐのか、そしてあなたのビジネスの主な推進力は何かを知っていますか？彼らは現在の仕事がそれらすべてにどのように適合するか知っていますか？
チームと集合的に話し合う-主要なニュースと一緒にそれらすべてをまとめ、グループをまとめて、あなたと一緒に、またはあなたなしでコミュニケーションが確実に行われるようにします。小さなチームとして、これはおそらくグループ戦略セッションです。チームが大きくなると、主要なポイントを案内する必要が出てきて、必然的に彼らのシナリオで話し合うようになります。それは間違いではありません-公開情報をeveryoneと言っているのを皆が聞くのを聞くことが非常に重要な場合があります。したがって、誰もがあなたが普遍的に情報を提供していることを知っています。しかし、「あなた-みんな-みんな」の会議は、あなたがよりガイドになるグループ戦略会議とは大きく異なります。
チームの作業のサンプル-全員の作業について少し調査してみましょう。彼らのコードを読み、機能を実行し、テストケースを試してください。全員の仕事の100％を目指すのではなく、全員から少しサンプルをとってください。彼らにフィードバックを与えるだけでなく、チーム全体の長所と短所をファイルします。
早い段階で頻繁に管理者に確認してください-これは茶色い鼻ではなく、ループの中にあります。経営陣が何を必要としているか、経営陣が何を考えているかがわからない場合、チームはどのようにして期待に応えることができるでしょうか？あなたは上司と本当に良いreporeを持っている必要があり、あなたは彼のチームにいる必要があります。ささいなことで上司と効果的にコミュニケーションできることで、危機が発生したときに助けを得て明確な理解を得ることができるという自信が生まれます。それはまた、あなたの全体像の目隠しがどこにあるかについての良い現実のチェックでもあります。
定期的にチームのリソースを確認する-以前に利用できたリソースが利用できなくなった場合、人々は悲鳴をあげますが、未知の問題点を確認します。あなたのチョークポイントはどこですか？持っていると便利な新しいツールはありますか？ほとんどのチームには、私がツールハンターだと思っている人がいて、常に最新かつ最高のガジェットを使いこなしています。 Tool HunterとGuyWhoHatesEverythingNewの間の会話のバランスを取り、進化の次のポイントを見つけます。ツールにはすべてが含まれます-SW、HW、物理的スペース、学習リソース。
サポートチームと連絡を取り合ってください。会社はそれぞれ異なりますが、品質管理、文書作成、法務、設備、財務、およびビジネスに固有のその他のサポートグループを担当する人を知っています。 。それらは私が考えることができる最高の全体像のトリガーです、なぜなら彼らは世界があなたとはまったく違うのを見るからです。
競争を知る-誰かがあなたの製品を使用していなかった場合に、誰かがあなたの製品が解決する問題をどのように解決するかを理解するために、少なくとも毎週時間を費やす。それは単一の会社ではないかもしれませんが、あなたが提供していない他のソリューションは何を提供していますか？
費用とスケジュールの確認-チームが現在の期限を意味する可能性はどのくらいありますか？次の締め切りはどうですか？あなたの費用の燃焼率はどれくらいですか？まだ購入していない大きな購入予定はありますか？予算の残りは？詳細は財務追跡の方法によって異なりますが、非常に非公式な会社であっても、予算の残りの日数/週数/月数と、現在の製品の期限を把握しておく必要があります。どこかで、誰かが「この仕事をするのに何人の人が必要か」を計画した方がいいでしょう。そして、「私たちは彼らに来月/四半期/年に支払う余裕がありますか？」これらの番号を把握し、次のステップで入力する必要があります。あなたは来週、誰かが入って尋ねてきたら今すぐ説明できる非常に明確な計画が必要です。あなたは来月のためのかなり良い計画が必要です、それは現実が当たったときに2-3箇所で変わるだけです。あなたは、四半期の大まかな計画と、年間の頭の要点の上の将軍が必要です。それを過ぎると、巨大なプロジェクトであっても、数字は単なる数字です。それらに耳を傾けますが、誰も血に署名していないことを認識してください。
それは私の頭のリストのトップです。私は通常、「サプライズ」によって頭の上部をたたくときに追加します（私が見逃した領域に敏感であることがわかると思います）、それをチェックリストに折り込みました。 ）。
また-Dread Context Switchに備えてください。管理を始めたばかりの場合、小さなチームがいて、管理職の誰かが、チームの管理に時間を費やし、個々の貢献者の作業に時間を費やすのは良いことだと考えている可能性があります。これは実行できますが、2つの間のコンテキスト切り替えは大雑把です。それを計画します。昼食前と昼食後のように切り替えて時間をブロックし、あまり慣れていないスキルセットを知って、最初の数回はそこに自分をドラッグする必要があることを理解してください。本当にどこにでも行くには少なくとも2時間は必要です。
コンテキストスイッチは両方向で機能します-管理から実際の作業、およびその逆。しかし、あなたが自分の強さと練習のポイントから不快感と少ない練習の場所に行くとき、あなたは痛みをより強く感じ、後退する衝動が強くなります。そこを知り、それと戦って、全体像の中でスラッシングすると、すべてをうまく取り込めるようになることに気づきます。スラッシュする時間を自分に与えてください。
この本を読む： Herding Cats：A Primer for Programmers Lead Programmers Programmers
少し前に私はこの本を上司にプレゼントしました、そして彼はそれを気に入りました。私がそれを読んでいたとき、彼は彼が何について話しているかを知っているようでした。そして、これはそうです。著者は彼自身の経験について語っています。マネージャーの「単純な真実」の集まりではありません-これらは元プログラマーの言葉です。そして、それは彼の経験であったことを理解されるべきですが、あなたの経験は異なるかもしれません。だから、いくつかのものについては批判的に見る必要があります。 「マネージャーはもはやプログラマーになることはできません-それは重要です」。
私が開発していない製品について最近小さな会社の技術的リーダーシップを引き継いだとき、物事を管理する上で非常に役立つと感じたのは、製品の動作をわかりやすい英語で文書化することでした。オブジェクトモデルの説明とさまざまなコントローラーのフローを書きました。私がそれをしているときに見つけたのは、A）製品が少し混乱していることです:)そしてB）アプリがどのように機能するかをはるかに迅速に学んだので、そこにどんな問題があり、何がリファクタリングが必要かについてインテリジェントな会話をすることができました、または、特定の機能を実装するために必要なもの。
写真も役立ちます。Visioのような製品をいじるのではなく、クレヨンと白紙を使用します（実際、私は家で仕事をしています。2歳の子供と一緒に仕事をしていることが多いのですが）。