やあ！ チームリーダーの役割に移行したすべての開発者は、最初はチームと一緒にコーディングとタスクの解決に戻るよう努めていると思います。その後、ビジネス関連の課題、部門間またはクライアント間のコミュニケーション、およびアーキテクチャにまで踏み込み、より多くのビジネス タスクと問題を網羅し始めます。 この時点から、私たちにはもう何か他のことをする時間も意欲もありません。典型的なチーム リーダーのカレンダーは次のようになります。 開発に戻ってコーディングを再開するにはどうすればよいですか?どこから始めればよいでしょうか? 自分がどれだけ忙しいのか、そして通常の勤務日がどのようなものかを評価することも重要です。あなたは仕事後に自己啓発に取り組んでいますか?これらはすべて重要な要素です。 私の経験に基づいて、「仕事の前後に時間がなく、意欲も機会もありません」から「常にコンピューターに向かっています。これが私の情熱です」への道に沿ってステップを踏むことをお勧めします。 時間をブロックしてください！ 効果的な開始点は、開発専用の時間をスケジュールすることです。カレンダーの「コーディング時間」を 1 時間以上ブロックするだけです。可能であれば、技術的なタスクに取り組むために毎週半日または丸 1 日を確保することを検討してください。 はい、会議を移動したり、不要な会議を削除したり、一部の会議に出席する必要性について話し合ったりすることが必要になる場合があります。ただし、特定のグルーミング セッションがまだ自分にとって意味があるかどうかを再評価することを検討してください。 おそらく、それほど影響を受けずにそこで1時間を過ごしているでしょうか？その時間をコーディングに振り向けましょう。 チームと一緒にコードをレビューしましょう! 周囲の特定のプロセスを最適化するための 2 番目で最も重要な側面は、プロジェクトの価値観やアプローチを同僚に伝えることです。すべての開発者が問題解決に対して同じアプローチを考えているわけではないため、コーディング スタイル、テスト カバレッジ、プラットフォームやサービスの基本的な方法と仕組みを個別に事前定義することが重要です。 常にコードレビューを実施し、質問が長引いていると感じた場合は、チームを集めてプルリクエスト (PR) の問題に迅速に対処します。実践が示すように、このアプローチにより問題解決時間が短縮され、その結果、機能の市場投入までの時間が短縮されます。 時間が経つにつれて、チームは注意をあまり必要としない開発アプローチを完全に理解し、適用できるようになります。目の前のタスクとそのロジックを解決することだけに集中できるため、最初は数分、長期的には数時間の開発時間を節約できる可能性があります。 あなたには何の責任がありますか? 最も明白な仕事のようには思えないかもしれませんが、自分に何が責任があるのかを自問してください。あなたは何する必要があるの？これらすべてのポイントを紙に書き出して、不必要なものを引き受けていないか確認してください。 おそらく、それが習慣になっているというだけの理由で、他の人の仕事をしているのかもしれません。もしかしたら、あなたは隣のチームのプロセスを手伝い、今も関わっているかもしれません。 自分の立場と、プロジェクトや会社に対して何を貢献しているかを明確に定義します。大規模なチームを率いる場合は、タスクや問題のキューを作成できるメモを使用します。常にレビューを実施し、たとえば DevOps リーダーの場合、モバイル アプリ開発者向けのタスクを誤って処理していないことを確認してください。 タスクや依存関係で過負荷になっていることに気付いた場合は、立ち止まって上司に相談し、なぜ自分の部門でこれが起こっているのかを理解する価値があります。たとえば、あなたがデータ エンジニアを担当する DevOps チームで、彼らに独自のリーダーがいる場合、自分の部門ではなくそのリーダーに責任を委任することが理にかなっているかもしれません。 仕様書と必要な文書を作成して、合意事項やセットアップやメンテナンスに関する隠れた詳細を正式にまとめ、従業員をそれぞれのチームに戻します。 これは単なる例であり、誰もが独自のチームと編成の原則を持っていることに注意することが重要です。 優先順位付けと委任 優先順位が変わり続けるため、物事が完了しない可能性があります。会社全体が 2 週間のスプリントで運営されていますが、この設定はもうあなたには合わず、あなたはそれに価値を見いだしていません。優先順位が弱いため、機能はスプリント内で完了できません。 これはサービス指向のチームに当てはまります。 カンバンまたはウォーターフローのアプローチを検討してください。私たちのチームは独立した島のようなもので、プロセスをより良い方向に変えることを試みる権利があります。新しいアプローチへの移行を 1 か月間テストして、指標を観察します。私の経験では、スクラムが当社に適していないことに気づくには数週間で十分で、カンバンに切り替えました。 優先順位が週に 2 回変更されるようになり、より迅速に問題に対処できるようになったことで、市場投入までの時間が大幅に短縮されました。 次に、チームをドメイン ゾーンに分割してみますが、あまり細分化しないでください。 70/30 ルールに従って各チーム メンバーを集中させます。 70% がメインスタック、プロジェクト、または製品に専念 その他の場合は 30% チームに 5 人以上のメンバーがいる場合は、すべてのサービスと機能をカバーできるため、個人がより迅速に対象領域に取り組むことができます。 これで何が得られるのでしょうか? 開発者がすでに十分な理解と没入感を持っていると判断した場合、自分ですべてを行うのではなく、一部のタスクをチームに委任することができます。アルゴリズム全体と統合を説明する必要はありません。彼らはすでにすべてを知っています！ 時間管理と生産性 チームは作業時間をどのように計画していますか? 簡単なことから始めましょう。チームとしてどのように活動していますか?見積もりとタスクの評価方法を確認してください。すべて順調ですか？おそらく改善の余地、あるいは作業負荷係数の導入の余地があるでしょうか? 作業負荷係数は、サポートの妨げになる可能性を考慮して、スプリントまたは週の間に各チーム メンバーにどのような負荷がかかっているかを理解するのに役立ちます。たとえば、あなたが独自の製品を保守するサービス チームの場合、他のチームがあなたの支援を求めたり機能拡張を要求したりする可能性があり、スプリント内のコミュニケーションに時間が費やされることになります。 バグへの対処についても同様です。実稼働環境での緊急の問題に対処するために脇道に逸れてしまうことがよくあります。 ただし、それは別のトピックです。この領域を段階的に改善する方法については、以前の記事を参照することをお勧めします。 https://hackernoon.com/just-go-ahead-and-test-your-project-part-1?embedable=true さて、係数の話に戻ります。問題を解決するために、少なくとも 5 日のうち 1 日はチャットや会議に各自が呼ばれていることを認識している場合は、計画の際にそれを考慮に入れてください。こうすることで、チームに真の利益をもたらすタスクを現実的に達成できるようになり、コードを書く時間を節約できる可能性があります。 ポモドーロテクニックを試してみましょう。 何も画期的なことはありません。携帯電話のアプリを使用するだけで、45 分などの設定された時間間隔でタスクに集中できます。特別なことは何もないと思います。 トラッカーを活用しましょう。 8 労働時間を何に費やしたかを調査します。週または月の活動を時間ごとに記録します。気を散らす要因を発見したり、昼食後に 15 分間散歩すると仕事の効率が上がることに気づくかもしれません。それが成功の鍵なのではないでしょうか?あるいは、3 回連続で会議があった場合、その後 1 時間何もせずに仕様書を読むだけになってしまうことはありませんか?たぶんそれはあなたにとって挑戦的ですか？ 重要なのは、自分のやっていることを精査することであり、そうすれば改善すべき領域が特定されると思います。 技術的に難しいプロジェクトへの参加 システム設計またはアーキテクチャ ソリューション専用の会議に参加できない場合は、フォローアップまたはドキュメントをお読みください。何がどのように問題を解決するのかを理解するように努めてください。このような会議を欠席せず、可能な限り技術的な側面に没頭するよう努めることが望ましいです。 コードを深く掘り下げる必要があるプロジェクトまたはプロジェクトの側面を選択します。これは、新しいテクノロジーや開発手法を常に把握するのに役立ちます。 あなたのためのRnD プロジェクト内で問題がある領域や機能を改善できる領域に気付いた場合は、自由にプロトタイプを作成してください。これにより、提案された変更を視覚化できるだけでなく、チームに議論や意思決定のための具体的な資料を提供することもできます。 主な目標は、アイデアを紹介するだけではなく、それらが本当に重要または有益であることが判明した場合にプロジェクトに実装することです。たとえば、古いサービスを Java 1.8 からバージョン 21 に移行することを常に夢見ていたのであれば、試してみてはいかがでしょうか。プロトタイプを作成し、チームに見せ、ソリューションを開発し、将来の参考のためにプロセス全体を徹底的に文書化します。 このアプローチは、技術的な改善を実装するだけでなく、潜在的な変更についてチーム内で共通の理解を生み出すのにも役立ちます。したがって、プロジェクトに建設的に貢献し、効果的な開発を確保し、イノベーションを促進することができます。 レビューポイント！ 、コードを作成し、解決策を提案するのに数時間かかります。その後、一息つきます。もちろん、リーダーの立場では両方を行うことはできません。まだ開発に焦点を当てているのであれば、復帰を検討する価値があるかもしれません。 この段階では それは何も悪いことではありません。たとえ管理が得意だったとしても、自分にとって管理が退屈になってきていると認識するのは問題ありません。ただ、現時点では、あなたにとってそれが魅力を失っているだけです。 まだ時間があれば 学習と自己啓発 技術文献を読んだり、教育コースを調べたり、技術カンファレンスに参加したりして、継続的に知識を深めてください。これは、ソフトウェア開発における最新のトレンドとベスト プラクティスを常に把握するのに役立ちます。 技術文献を読むことは、新しいテクノロジー、方法論、ベスト プラクティスを深く掘り下げるまたとない機会となります。これには、ソフトウェア開発のさまざまな側面をカバーする書籍、記事、ブログ、その他の資料が含まれます。 教育コースを受講することは、新しいトピックやテクノロジーに関する知識を習得するための体系的かつ体系的な方法です。オンライン コース プラットフォームでは、さまざまなプログラミング言語、フレームワーク、概念に関する幅広いコースが提供されています。 技術カンファレンスに参加すると、最新のトレンドやイノベーションについて学ぶだけでなく、業界の専門家と交流する機会も生まれます。カンファレンスは、経験を共有し、困難な問題について話し合い、技術コミュニティ内でつながりを構築するためのプラットフォームを提供します。 要約すると、読書、コースの受講、カンファレンスへの参加を通じて継続的に学習することで、ソフトウェア開発者は最新のトレンドを把握できるだけでなく、新しい知識やスキルを日々の業務に積極的に組み込むことができます。 例: leetcode、Udemy、または Youtube (本当に優れた無料コンテンツが見つかる場合もあります!)。 個人プロジェクトに取り組む 可能であれば、自由時間に個人的なプロジェクトに取り組んでください。これはプログラミング スキルを向上させるだけでなく、本業の新しいアイデアの源としても役立ちます。 さらに、このアクティビティと記事の RnD ポイントを組み合わせることで、創造性とイノベーションに対するさらなるインセンティブとなる可能性があります。 個人的なプロジェクトに取り組むことで、実践的なシナリオでスキルを適用し、新しいテクノロジーを実験し、現実世界の問題を解決することができます。これらのプロジェクトには、独自の Web アプリケーションの開発、オープンソース プロジェクトの作成、または興味深いサイド プロジェクトへの参加が含まれる場合があります。 この活動を前述の研究開発 (RnD) 作業と統合すると、プロトタイプを作成して職場で展示できるようになります。オープンソース開発に参加するなど、プロジェクトを一般に公開することは、スキルを向上させるだけでなく、貴重な専門的なつながりを構築し、創造性を評価してもらうことにも役立ちます。 ただし、本業の機密保持ポリシー (NDA) を遵守することが優先事項であることを覚えておくことが重要です。個人的なプロジェクトに着手する前に、創造的なプロセスが確立されたルールに違反していないことを確認し、機密データの機密性を維持しながら創造的なエネルギーの自由な発展を促進するために、法律の専門家や経営者に相談することをお勧めします。 結論 チームリーダーとしてコーディングの時間を確保するには、意識的な努力と効果的な優先順位管理が必要です。あなたの役割には、チームを直接率いるだけでなく、技術スキルを満足のいくレベルに維持することも含まれることを忘れないでください。 大変なことになると思いますが、幸運を祈ります! 私はずっと前にその問題を見ました。専門的な本を読みたい場合は、 と 書籍を読むことをお勧めします。 リンク リンクの
