爆発しないでチームリーダーになる方法

2年前、私は密かにTouch InstinctでiOSリーダーの役割を果たし、iOS部門の安定した仕事を形作り始めました。 6か月後、公式の地位に変わりました。 経験不足のため、椅子の上部にupper熱感を引き起こす膨大な数の問題がありました。 これはいくつかの要因によるものです。

• 管理経験の欠如。
• 自分自身の新しい役割から、プロセスの構造、責任、問題を解決する方法を理解する人に至る道をすでに通過した有能な人が近くにいない。
• 当時の若さによる会社の一般的なプロセスの不安定性。

あなたがリーダーになり、最初の陶酔感が少しburning熱感と落胆に置き換えられた場合、いくつかのヒントは不要ではありません。

リードはどこから来ますか？

歴史的に、企業経営には2つの古典的な構造モデルがあります。

最初は水平制御システムです。 ベースキャンプや37信号など、あまり頻繁に行われません。 重要なのは、自分の活動を独立して調整できる強力な専門家がたくさんいるということです。

2つ目は階層管理システムです。

開発者がいて、彼の後ろにプラットフォームリードがあり、彼の後ろにCTO、そしてCEOがいます。 各参加者は、特定の開発ベクトルを監督します。 階層内の下位に位置する人ほど、より高度に専門化された領域に対する責任が大きくなります。 開発者は、自分が作成したコードについてのみ責任を負います。 リードは、プラットフォームとその開発に対して単独で責任を負います。 テクニカルディレクターは、会社のテクニカルコンポーネントを担当します。 そして、CEOは会社の発展のためのものです。

会社が大きくなるほど、プロセスと参加者が多く表示されるほど、階層が複雑になります。 モバイルリードなどの追加の役割が表示されます。 彼は、モバイルプラットフォームのリードを提出します。 会社の特定のレベルの部下の数に依存します。

1人で制御できる最適な人数は、活動の範囲や管理モデルとは大きく異なります。 古典文学のITでは、この数の範囲は5〜9人です。

少数の人々は、追加の階層的役割が冗長であり、単にプロセスを複雑にするという事実につながります。

制御、トレーニング、その他の機能を実行するのがより難しくなるという事実につながるほどです。 新しい役割を追加する必要があります。

IT企業の典型的なキャリア成長状況を考えてみましょう。 特定のレベルの資格に達すると、特定の個人的資質の存在下で階層の次のレベルに進むか、職業/活動分野/会社を変更して技術的パスでさらに成長することができます。 以下の図は、開発の古典的な短い形式を示しています。 開発者の開発の次の段階は、チームリーダーまたは技術リーダーです。 1つ目は管理への移行、2つ目は深い技術的成長の専門家です。 チームリードは、プラットフォームリードにさらに進みます。 さまざまな口径のハイテクリードアーキテクトから取得します。

会社における鉛の役割

まず、リーダーからのリーダーシップを待つものを決定します。 会社の規模によっては、特定のチームの管理と方向性全体の開発の両方にその役割を減らすことができます。 同時に、開発者が管理タスクを実行するために、開発者があなたと、より高いレベルの管理者に高い技術スキルを要求するという事実に備える必要があります。 ほとんどの場合、チームリーダーはある程度プログラマーであり、ある程度マネージャーです。

技術的役割

彼らは、時間の経過とともにチームリーダーがプログラマーのスキルを徐々に失い始めると言います。 実際には、プログラミングの基本のほとんどは40年以上前に策定されました。 この知識は特定のSDKの知識よりも価値がある場合があります。 しかし、ほとんどの場合、メンタリングは、最も単純なプログラムの質問を支援することに加えて、次のように要約されます。

エコシステムの構築。 現在、その企業が勝つITビジネスでは、製品を提供するだけでなく、エコシステムを構築しようとしています。 これにより、多くのビジネス上の問題を解決でき、会社が提供するさまざまな機能を使用できます。 これはApple、Google、およびFacebookに適用されます。 時間の経過とともに、あらゆるビジネスがプラットフォームに変わり始めます。 開発でも同様の状況が見られます。 可能な限り多くの質問があるように、開発者向けのエコシステム全体を構築する必要があります。 これは、プロセスとアーキテクチャに適用されます。 新しい開発者がすぐにプロセスに参加できるように文書化されたガイドシステムを作成する必要があり、チームメンバーは受け入れられた標準を忘れないでください。

トレーニングシステムの構築。 適切なリードは、すべてのチームメンバーのトレーニングプロセスを適切に構築し、各自の利益を会社のビジネス目標と正しく関連付ける必要があります。 人が複雑なカスタムUIを学習したい場合、リードのタスクは、これをどのように使用するかを考え出すことです。 これは、技術的な知識であれ経営者であれ、他の分野にも当てはまります。 これらのタスクの実装を監視することが重要です。通常、開発者は頭の中でこれらのタスクの優先度を低くします。 知識の少ない分野でも開発を支援してください。 適切な専門家に相談するか、時間をかけて自分で解決してから、他の人に伝えてください。 そのため、人は知識を強化します。 開発者またはあなたがどの分野の知識も持たない状況は正常です。 これを認識して受け入れると、学習が容易になります。

コードに対する態度の原則の教え込み。 開発者に、コード自体には一銭も価値がないという考えを伝えることが非常に重要です。 このコードが実行する機能のみが理にかなっています。 これは、構築する必要のあるエコシステム全体が成長する場所です。 ビジネスはコードを書くためのルールを決定し、その逆はそうではないことを理解することが重要です。 信頼性が非常に高い銀行システムがある場合は、TDDが必要です。 MVPアプリケーションを作成する場合、最初の段階で複雑なシステムとアーキテクチャを構築することは意味がありません。

心理的役割

ほとんどの開発者は内向的であると考えられています。 実際、これは真実に非常に近いものです。 この知識のおかげで、作業に適用できるいくつかの手法が現れます。

開発者との月例会議を開催します。 そのような会議のシナリオは毎月繰り返されます。 最初は、開発者はすべてが大丈夫、すべてが正常で、問題はないと言います。 しかし、心理学者の主な強さは重要です。 会話の中で、先月のプロジェクトの評価システムが改善され、部門間の関係が強化され、元のソリューションも発明されたことが判明しました。 実際、別のプロジェクトで同じ問題が発生し、必要以上に長く解決しました。 会話は素晴らしい考えを持つことができるため、注意する必要があります。 それらは実装可能であり、実装する必要があります。 そのような会話の後、いくつかの問題は平準化されます。 このプロセスは反復的であるため、問題を修正するのに役立ち、それほど時間はかかりません。 そのような会議は、部門別会議に変える必要はありません。 これはリラックスした雰囲気の中で一対一の会話である必要があります。 そのため、複雑な性格の問題も解決できます。

ビッグブラザーになる。 リードは、そのユニットの運用に責任を負います。 彼は、各開発者の出力機能のタスク、期限、品質に注意する必要があります。 ただし、その過程で極端に進まないでください。 「節度ですべてが良い」ということわざはここで完璧に機能します。 すべてが順調に進んでいる場合は、干渉しないようにしてください。 同時に、常に脈動を把握し、危機的状況を防止してください。 従業員は、プレッシャーをかけないときに最も快適に働きますが、同時に、コントローラーではなくアドバイザーである目に見えない「兄貴」の影響を感じます。

「フェースレスコード」を実装します。 最も長くて最も難しいプロセスは、自分の部署のコードを「書面のないコード」にすることです。それを書いたスタイルで判断することが不可能な場合です。 この方向は正確で困難です。 変動が可能な場合は、いくつかのキャンプに出くわします。 危機が発生した場合、「その後彼らはそう決めたが、悪いことが判明し、今ではすべてのマイナス面が浮上している」というあなたの住所には落ちないように、外交的に各問題を解決する必要があります。 他の人は、あなたが開発し調整する基本的なソリューションで作業することを忘れないでください。 彼らにとって便利にしてください。

椅子が早く切れないようにする方法

クラシック-最も生産的な開発者がリーダーになるとき。 多くの場合、管理者は機能を高速化することで、平均的な開発者と同じくらいのことができ、さらに責任を引き受けることができると考えています。 プログラムする労働時間の割合を契約に直接登録するように依頼できます。 責任の領域は完全に異なり、あなたの責任は変化しています。 2つのシナリオがあります。

• 開発者としてもチームリーダーとしても間に合うように、より多くの仕事を始めます。 これは通常燃え尽きにつながります。
• 以前と同じように動作します。 その結果、リードの機能とタスクの両方を実行する時間がありません。

新しい役割を交渉する段階で、事前に新しい役割からの質問と期待のリストを検討します。 あなたに何が期待されているか尋ねてください。 具体的に何をする必要があるかを理解し、それを明確にします。 それから初めて仕事に取り掛かります。 そうしないと、開発期限に間に合わず、プロセス、トレーニングシステム、およびその他すべてのタスクを調整しません。 会社のマネージャー、開発者、その他の人々との関係は、何らかの形で悪化します。 あなたは、あなたが会社の利益のために週末に背を向けられているヒーローだと思うでしょう。 しかし実際には、彼らはあなたが頼ることができない人になっています。 結局のところ、タスクが実行されるかどうか、およびどの程度うまくいくかは不明です。

だからこそ、なぜプログラムする必要があるのか​​、どのくらいの時間、そしてそれが部門や会社全体に与えるものなのかを明確に規制する必要があります。 共通のソリューション、ライブラリ、または標準のアーキテクチャを設計する時間の約30％を話している場合-1つのこと。 これは、コードを忘れてグローバルに見ないように、日常的なタスクを実行しないようにするのに役立ちます。 しかし、約70％または90％の時間を言われた場合、人々はチームリーダーが必要な理由を理解できません。 または、40時間以上働くことを事前に計画します。 改善方法を合理的に説明するか、単に応答を拒否することができます。 期待について話すのが最善です。

開発計画を立てます。 少なくとも来年は、自分自身と部門の発展のための明確な計画を立てる必要があります。 これには、共通プロセスの開発、基本的な共通ソリューションの作成、講義コース、または学校の作成があります。 すべては、会社の現在のニーズに基づいています。 目標がコードの書き方を学ぶことであれば、アーキテクチャとメタ原則への移行です。 市場で自分自身を宣言する場合-会議や出版物への参加。 そのような計画がない場合、いくつかの問題が始まります。

• 人々はあなたが何をしているのか理解していない。
• 自分が何をしていて何をする必要があるかを自分で理解していない。 完全に制御できないカオスになります。

メンターを見つけます。 すでにこのように行った人がいるのは素晴らしいことです。 彼があなたの質問に率直に答えることができれば-これは大きなプラスであり、それを使用しないことは大きな間違いです。 理想的には、これがプラットフォームのリーダーであり、あなたが個人的にスペシャリストとして知っていて尊敬している場合です。

考えないでください。 誤解した場合に直接対話する習慣を身につけてください。 多数の問題が解決されますが、個人的な葛藤を含め、それ以上のものには成長しません。

進捗を追跡します。 すぐに実装プロセスの指示と制御を開始する必要があります。 これにより何が得られますか？ 単純な委任により、一見重要な定型タスクの作成を停止し、計画の一部であるタスクを実行できるという事実。

自動化。 さらに、CI / CD /静的アナライザー、コードジェネレーター、ベースライブラリなどの形式のさまざまな種類の最適化。 これにより、将来の時間を節約できます。

時間管理と委任

開発者の1人が1週間ソフトウェア過酷な状態に陥り、完成した機能で戻ってきますが、誰かが毎日の制御を必要としています。 観察、分析、論理的思考は、誰が誰であるかを理解するのに役立ちます。

デリゲート。 主なことは、ほとんどのタスクを委任できること、また委任する必要があることを理解することです。 最初の段階では、さらに多くのケースがあるように見えるかもしれません。 特に、アーキテクチャの決定を書くなどの重要な責任を持つ開発者である場合。 必要な能力を備えた人が近くにいないことがわかるかもしれません。 したがって、能力を成長させる必要があります。 最初の段階で受け入れるのは難しいかもしれませんが、これはあなたの立場で唯一の正しい方法です。

時間を制御します。 タスクに割り当てられた時間を追跡します。 それは戦術的および戦略的タスクについてです。 毎日の仕事については話していないが、それが主な成功要因になるだろう。 戦術ミッションとは、基本的なライブラリ、文書化されたプロセス、または学習プロセスを作成するという形で、特定の大規模なミッションを達成することを意味します。 戦略の下で-開発ベクトルの定義。 どの時点でObjective-Cを使用しますか？ より効率的に機能するようにエコシステムを形成する方法は？ ビジネス上の問題を解決する効率を高めるには、何をする必要がありますか？ これらは戦略的な問題の例です。 それらは最も複雑で最長ですが、あなたの明日はそれらにかかっています。

重要なポイントは、あなたが理解している限り、人々にとって何が面白いかです。 これは、開発者の開発とエコシステムの特定のコンポーネントの研究の両方の追加要因として使用できます。 開発者は原則として、暇なときに面白いことをするのが好きです。 これで彼らを助けることができます。 人にとって本当に面白いものを理解することだけが重要です。

エラー、マイナス、デメリット

あなたは長い間、あなたが素晴らしい人であり専門家であるということについて美しく話すことができます。 しかし、何もしない人だけが間違っていないという事実は残っています。 そして、人が快適ゾーンから離れ始めるほど、エラーの可能性が高くなります。 フルタイムの開発者から管理職への具体的な離脱は、チームや社内の他の部門との強い相互作用を意味します。 人にとって新しい非標準的な状況が現れるのは論理的です。 そして、彼は常にそれらを解決する方法を知っているわけではありません。

不快な状況に直面したとき、最初にすべきことは、あなただけがそれを修正でき、他の誰もそれを修正できないことを理解することです。 そして、引きずる時間が長いほど、時間の銃は最後に強くなります。 次に、抽象化から具体的な例に移りましょう。

意思決定。 人々が上からチームに降ろされることが起こります。 ここですぐにルールを明確に述べる必要があります。チームを構築する決定を完全に拒否する権利を持っているか、なぜそのように機能するのかを経営陣に説明する必要があります。 理想的には、最も一般的なプラクティスは、チームリーダーがチームを結成することです。 意思決定がリード自身によって行われたため、道徳的責任が増大します。

個人的な資質。 チームには、何らかの理由であなたに合わない人がいます。 同時に、あなたが彼を雇ったか、すでに彼がいたか、または横から与えられたかはまったく関係ありません。 すべての人が間違っていて、あなたも例外ではありません。 特に最初の段階では、すべてのインタビューは、人がチームにどれだけ収まるかを理解することに基づいているのではなく、バイナリツリーの要素を見つけるアルゴリズムの問​​題を解決する方法を知っているかどうかに基づいています。 アルゴリズムは1日で学習でき、フレームワークは1日目の最初のアプリケーションから1か月の深い没入までのデューデリジェンスで学習できることを理解する必要があります。 また、個人の資質である「抽象的なコード感覚」は、日、週、月、月で修正することはできません。 この問題では、さらに、hrに焦点を当てる必要はなく、これが彼らの仕事であると仮定する必要はありません。 結局、人は会社での勤務期間中に、時間ではなくほとんどの時間をあなたと一緒に働くからです。

短所には、時間の経過とともに技術スキルが低下するという事実も含まれます。 これは同時に神話と真実です。 リードの役割により、プログラミングのメタ原理で、いくつかの技術的側面をより広く見ることができます。 また、iOS 10で新しいCallKitフレームワークをプログラミングする方法と、そのインターフェイスメソッドを知ることができないという事実は、存続するのは困難ですが、一般的には可能です。

出てくる

長い間、私のチームのメンバーは誰も辞めなかったことに誇りを感じていました。 週末に私の自由時間の一部がかかったとしても、人を助けることは一定の義務だと考えました。 しかし、あらゆるレベルのマネージャーがすべきことは、人を導き、助けることであり、彼のためにやることではないことを一度だけ理解する必要があります。 問題を特定するためにいくつかの個人的な会話をしてください。 期待の矛盾がなく、両方が理解できるように、問題に対処する必要があります。 問題を解決するための戦略を構築し、厳重に管理します。 これはうまくいかないかもしれません。 問題があなたにないことを確認するために、チームの別の開発者に、パフォーマンス/資格または単なる道徳的なチームワークの評価において、何らかの独立した専門家として行動するよう依頼してください。 あなたの意見が同意したら、疑いの影なしで去りなさい。 したがって、あなたはあなたの神経とチームメンバーの神経の両方を保護します。 そして、その人自身でさえ、これがそれが終わった方法であることをしばらくして感謝するでしょう。 時間が経ち、経験が増えるほど、間違いを犯したかどうかを理解する時間が短くなります。

競合状況もあることを事前に理解する必要があります。 しかし、ほとんどの場合、これは個人的な会話を通して決定されます。 直接話すだけですが、非常に難しい場合があります。

スケーラブルな回路を構築します。 「全能リング」の役割からの逸脱

開発者からリードについてよく耳にするネガティブストーリーの1つは、リードがすべての興味深い部分を自分自身に持っていくということです。 最も一般的な問題であるリードから別のフィードバックを受け取ります-タスクがあり、それはすべてではありません!!! 111を委任することはできません。

• 時間は限られたリソースです。 リードが彼の仕事ではなく面白い仕事をする場合、その仕事は単純に行われません。
• ほとんどの能力を1人でまとめることにより、完全にスケーラブルなシステムを実現できます。 そして、最も興味深いのは、バスファクターを取得することです。 もちろん、これは給料について議論する際に操作することができますが、実際にはあなたはリードとしてより良くなるのではなく、力を奪うだけです。
• あなたのチームは成長していません。 確立されたプロセスは存在しないため、誰も理解していません。

ランドマークまたは誇大広告のKPI全体は、チームにのみ存在します。 団結したクールなチームがあれば、すぐに製品を作り、プロセスに従うことができます-あなたは良いリードです。 他の人のさまざまな種類の能力を徐々に増やしてみてください。 これは、本人自身の意識的な選択であり、上から課される慣行ではないことが不可欠です。

将来の成長オプション

「次は何ですか？」という質問がすでにあったので、開発者のときは、チームリーダーの段階でそれを確認します。 また、ここでは、以前に分析したスキームに従うこともできます。 唯一の問題は、マネージャーとして開発する価値があるのか​​、それともさらに開発に向けてさらに深くなるのか

建築家の役割。 それを試してみると、この質問に明確に答えることができます。 しかし、先ほど言ったように、最初の数か月間は彼に自問しないでください。 通常の快適ゾーンの外側にいるため、デフォルトでは、人はインセンティブに否定的に反応する傾向があります。 少なくとも基本的なことを理解してから、決定を下してください。

リーダーになったらどうするか

チームリーダーの役割とマネージャーの役​​割には、ビジネス、時間、テクノロジー、会社自体のビジョンの外部および内部要因に依存する多くの特定の機能があります。 リードになった場合、まず最初に：

• 部門でワークプロセスを設定します。 同時に、可能な限りそれらを文書化します。
• 従業員のトレーニングについて考えてください。
• さまざまな種類のタスクを委任するための正しいシステムをセットアップし、それらの実装を直接指示および制御します。
• 奇妙な状況で対話する。 真実は論争の中で生まれます。 この方法でのみ、人々を理解し、彼らがあなたを理解しているという確認を受け取ります。

私の場合は何がうまくいったのでしょうか。 主な教義は、すべてに経験が伴うということです。 もちろん、その方向で作業する場合。 時間が経っても問題は消えません。あなたはそれらを解決する方法を学ぶだけです。

自分の経験だけでなく、他の人の間違いからも学ぶことができることを忘れないでください。 チームリーダーはクールです。

ソースのリスト

S.マッコネル。 ソフトウェアプロジェクトはいくらですか

J.ハンク・レインウォーター猫の放牧方法

デビッド・ハイネマイヤー・ハンソンとジェイソン・フリード。 再加工