リード開発者として成功するにはどうすればよいですか？[保留]

私は特定のプロジェクトの主任開発者になりましたが、全体像に焦点を当てて、プロジェクトのすべての部分をカバーするのに苦労しています。

このプロジェクトを管理するとき、私は何に留意すべきですか？すべてが必要な方法で処理されるようにするにはどうすればよいですか？

私は、他の開発者がシニアまたはリードに移行するときに、この旅行を見ました。ここに私が他の人にしたいくつかの提案があります。

• プロジェクトの目標を理解します。

多くの場合、プロジェクトにプッシュされたすべての機能についてではありません。それは、ビジネスニーズに対応している主要な機能セットです。それがあなたの主な目標であるので、常にこれを覚えておいてください。

• タスクに実行する必要があるものを分類します。それらの間の依存関係を理解し​​ます。

プロジェクトを分割するのは非常に簡単です。プロジェクトのできるだけ早い段階で分解してください。部品に光沢を付ける必要がある場合は、何をする必要があるかを理解するまで、部品がリスクをもたらすことを理解してください。

• プロジェクトの未解決の質問またはあいまいさを理解します。

最初にすべてのあいまいさを解決することはできません（ただし、試してみてください）。マネージャーとプロジェクトの関係者は、彼らが何であり、彼らがプロジェクトに与えるリスクを理解していることを確認してください。

• ビジネスは驚きを嫌います。

誰もがプロジェクトのステータスを（理想的には毎日ですが、毎週機能する）知っていることを確認してください。そして、ステータスとは、何をしたか、何をすべきか、未解決の質問、問題などを意味します。プロジェクトの完了に影響を与える可能性のあるものはすべて報告する必要があります。

• 毎日、全体像を見てください。

毎日1時間、全体像を確認する必要があります。質問を自問してください。何が完了しましたか？あと何をすべきか？未解決の質問は何ですか？目標は何ですか？誰かが尋ねるたびに誰かにプロジェクトの詳細なステータスを与えることができるはずです。

最初のアドバイスは、独自のプログラミングタスクを行うよりもチームの管理が重要であることを受け入れることです。つまり、助けを必要とする3人の後輩がいるとき、それがどのようにあなたが発展からあなたを引き離すかについて泣き言を言わないようにするのはあなたの仕事です。リードとして、最初に自分の開発タスクに集中しすぎると、多くの場合、進歩の障害になります。

さらに、委任することを学ぶ必要があります。1時間で簡単にできるのに、1日にひらひらすることがわかっている人にタスクを与えることは困難です。ただし、タスクを取得しなければチームは進行しません。チームがゲームをプレイしている間、残業します。

さらに、他人のコードを修正することは絶対にしないでください。何が間違っているのか（およびその理由）を伝え、修正させます。または、改善されていないため、すべてを修正する必要があるサイクルになります。修正できない場合は、チームにとどまるかどうかを検討します。あなたが彼らがするすべてを修正しているので、弱いチームメンバーがとどまることを許可しないでください。

リードとして、あなたは悪者になり、彼らに不快なニュースを伝えます（チェーンの上下両方）。それは仕事にも当てはまります。つまり、パフォーマンスの評価が不十分でなければなりません。締め切りが引き上げられたか、要件が変更されたことを伝えなければなりません。進歩を遂げていない怠け者をプッシュする必要があります。締め切りに間に合わない場合、上司にその理由と何をしているのかを伝える必要があります。リードとは、好かれることではなく、効果的であることです。あなたの仕事は、友達を作るのではなく、ソフトウェアを外に出すことです。コミュニケーションが重要であり、悪いニュースを避けることは状況を悪化させることになります。クライアントは、ローンチ日が過ぎてからさらに3週間必要だと伝えるよりも、ローンチの前に月の3週間先になると言われることに対処する可能性がはるかに高くなります。

これが私の非公式のチェックリストです。非常に非公式です...私は毎日すべてをするわけではありませんが、毎週これらのすべてをヒットしていない場合は少し心配になり、毎月ヒットしていない場合はパニックに陥ります。また、マイレージは、企業/チームの文化、個人的なスタイル、プロジェクトの種類によって完全に異なります。

• チームと個別に話し合う -あなたのチームの全員が-役に立つ仕事をしていますか？製品と現在のリリースの全体的な目標は何ですか？彼らはあなたがどのようにお金を稼ぐか、そしてあなたのビジネスの主要な推進力が何であるかを知っていますか？彼らは現在の仕事がそれらすべてにどのように適合するか知っていますか？

• 集合的にチームに話しかける -主要なニュースでそれらをすべて集め、グループを集めて、あなたとのコミュニケーションの有無を確認します。小さなチームとして、これはおそらくグループ戦略セッションです。チームが大きくなるにつれて、主要なポイントをガイドする必要があり、必然的に彼らが話をするシナリオになります。それは間違いではありません- 誰もが誰にでも公開情報を言っているのを誰もが聞くのは非常に重要です。だから誰もがあなたが普遍的に情報を提供していることを知っています。しかし、「みんな-みんな-」会議は、あなたがよりガイドであるグループ戦略会議とは非常に異なっています。

• チームの作業をサンプリングします-全員の作業について少し調査してみてください。コードを読み、関数を実行し、テストケースを試します。全員の仕事の100％を目指すのではなく、全員から少しサンプリングしてみてください。フィードバックを与えるだけでなく、チーム全体の長所と短所を整理します。

• 早めに頻繁に管理者に確認してください -これは茶色の鼻ではなく、ループ内にあります。経営陣が何を必要としているか、経営陣が何を考えているのかわからない場合、チームはどのようにして期待に応えることができますか？あなたは上司と本当に良いレポを持っている必要があり、彼のチームにいる必要があります。些細なことで上司と効果的にコミュニケーションをとることができれば、危機に直面したときに助けを得て明確な理解を得ることができるという自信が生まれます。また、大きな絵の目隠しがどこにあるのかを確認するのにも適しています。

• 定期的にチームのリソースを確認します -以前に利用できたリソースが利用できなくなったとき、人々は悲鳴を上げますが、未知の痛みのポイントを確認します。チョークポイントはどこですか？便利な新しいツールはありますか？ほとんどのチームには、常に最新かつ最高のガジェットの最新情報を入手できるツールハンターと考える男がいます。Tool HunterとGuyWhoHatesEverythingNew間の会話のバランスを取り、進化の次のポイントを見つけます。ツールには、SW、HW、物理空間、学習リソースなど、すべてが含まれます。

• サポートチームと連絡を取り合います。 すべての会社は異なりますが、品質管理、文書作成、法律、施設、財務、およびあなたのビジネスに固有のその他の支援グループの担当者を知っています。彼らはあなたとは全く異なる世界を見ているので、私が考えることができる最高の全体像の引き金です。

• 競合他社を知る -製品を使用していない場合に、製品が解決する問題を誰かが解決する方法を週に少なくともいくつかの時間を費やしてください。それは単一の会社ではないかもしれませんが、他のソリューションはあなたに提供しないものを何を提供しますか？

• コストとスケジュールを確認する-あなたのチームが現在の締め切りを意味する可能性はどのくらいありますか？次の締め切りはどうですか？費用の燃焼率はいくらですか？今後の大きな購入はまだ支払っていませんか？予算の残りは何ですか？詳細は財務追跡の方法によって異なりますが、非常に非公式の会社であっても、残された予算の日数/週数/月数、および現在の製品の期限は何かを知っている必要があります。どこかで、どういうわけか誰かが「この仕事をするのに何人の人が必要なのか」を計画した方がいいでしょう。「来月/四半期/年に支払いをする余裕はありますか？」これらの番号を知って、次のステップで入力する必要があります。来週には明確な計画が必要です。誰かが歩いて来て、尋ねたらすぐに説明できます。来月にはかなり良い計画が必要です。それは現実がヒットしたときのみ2-3箇所で変化します。四半期の大まかな計画と、その年の頭の要点から外れた大将が必要です。それを過ぎて、巨大なプロジェクトであっても、数字は単なる数字です。それらに耳を傾けますが、誰も血で署名していないことに気づきます。

それは私の頭のリストの一番上です。私は通常、「驚き」に頭をひっくり返されたときに追加します（見逃した領域に敏感だと言ってから、チェックリストに折りたたむことができます。 ）。

また-Dread Context Switchの準備をします。経営陣を始めたばかりの場合は、小さなチームがあり、経営陣の誰かが、チームの管理に時間を費やし、個々の貢献者の仕事に時間を費やすことは問題ないと考えている可能性があります。これは実行できますが、2つのコンテキストの切り替えは大まかなものです。それを計画します。（昼食の前後など）切り替える時間をブロックし、あまり練習されていないスキルセットを把握し、最初の数回は自分自身をそこにドラッグする必要があることを認識します。実際にどこかに行くには少なくとも2時間必要です。

コンテキストスイッチは双方向で機能します-実践的な管理とその逆です。しかし、あなたが自分の力と練習のポイントから不快で練習の少ない場所に行くとき、あなたはより多くの痛みを感じ、退却への推進力は強いです。そこを知り、戦い、全体像を把握することで、すべてをうまく取り入れることができることに気づきます。スラッシングする時間をとってください。

この本を読む：Herding Cats：プログラマーをリードするプログラマーのための入門書

しばらく前に、私はこの本を上司に贈りましたが、彼はそれを気に入りました。私がそれを読んでいたとき、彼は彼が話していることを知っているように見えました。そして、これはそうです。著者は彼自身の経験について語っています。マネージャーの「単純な真実」のコレクションではありません-これらは元プログラマーの言葉です。そして、それはHISの経験であったことを理解する必要がありますが、あなたの経験は異なるかもしれません。だから、いくつかの事柄については批判的に見るべきです。「マネージャーはもはやプログラマーになれません-それは重要です」。

私が開発していない製品で最近小さな会社の技術的リーダーシップを引き継いだとき、物事を管理するのに非常に役立ったのは、製品の働きをキュウリで文書化した機能と内部について文書化することでしたオブジェクトモデルの説明と、さまざまなコントローラーのフローを作成しました。私が見つけたのは、A）製品が少し面倒だったということです:) B）アプリの仕組みをもっと早く学んだので、そこにどんな問題があり、リファクタリングが必要かについて、インテリジェントな会話ができました。または特定の機能を実装するために必要なもの。

写真も役立ちます。Visioのような製品をいじるのではなく、クレヨンと白紙を使うだけです（実際、私は自宅で仕事をしていますが、2歳の子供と一緒に仕事をすることがよくあります）。