90日で開発者からPMに

最近、ITの分野で特定の傾向が観察されています。 スタートアップは管理を怠り、すべての決定は通常創業者によって下されます。 スタートアップが成長し始めると、新しい従業員が必要になります。 そして、マネージャーが緊急に必要です。 創設者は彼の最高の開発者に助けを求めます。「私は困っています。 私の代わりにこのチームを管理できますか？」

Twitterの開発部門の元ディレクターであるDavid Loftnessesは何度も同じ開発者であり、過去20年間でXmarksやGeoworksを含む6つのIT企業がこの質問に取り組んできました。 開発者とマネージャーの職務間でこのような移行をいくつか行った後、Loftnessは他の開発者が上級職で働くスキルを習得するのを支援し始めました。

少し前まで、彼はこの分野での経験を共有し、開発者がマネージャーになろうとする90日間の計画を作成しました。 このユニークな記事では、将来のマネージャーが優先順位を付け、自信を保ち、仕事の結果を分析できるようにするために、彼の計画を詳細に説明しています。 したがって、彼らはより速く開発し、他の従業員をサポートし始めます。

なぜ計画が必要なのですか

「多くの記事が管理のトピックについて書かれていることを誰もが知っています。 しかし、これらの記事は互いに矛盾しているだけでなく、重要な点を見逃しているように思えました、とロフトネスは言います。 -マネージャーとして成長し続けるかどうかを選択できる期間限定の計画を作成したかった。 これが、開発者が成功するリーダーになるのに役立つ90日間の計画を作成するための私のアプローチです。」

彼は、IT企業がしばしば開発者を指導者の地位に任命することを強いられていることに気づいた後、この計画を立てることに決めました（意見や実務経験に関係なく） 一方では、マネージャーになる開発者は、製品開発で重要な役割を果たすテクノロジーとビジネスプロセスの深い知識をすでに持っています。 ただし、これらの新しいリーダーは、原則として、人々を管理する方法がわかりません。

調査中、ロフトネスは、リーダーになる前に、平均して15人のマネージャーのうち1人だけが計画的なトレーニングを受けたことを発見しました。 どの方法がマネージャーのトレーニングで最も効果的であることが判明したかという質問に答えると、ほぼ75％が試行錯誤の方法を示し、半分は部下のフィードバックに言及し、40％は他のマネージャーを観察したと述べました。

これは、ロフトネス自体の意見と一致します。「マネージャーとして働き始めたばかりの頃、少なくとも最初の6か月間、私は他の人の後に繰り返しました。 スケジュールを編集するとき、「おそらく会議を開く必要がある」と考えました。 そして、私たちは会議を開き始めました。 基本的に、私は自分の周りで起こっていたすべてをコピーしました。」

これは何につながりますか？ 開発チームは、管理経験のない技術専門家によって主導され始めます。 新たに作られたマネージャーは、最も難しい状況に任命されているため、多くの場合、さらに難しい状況に対処する必要があります。

ロフトネス90日間プランは、管理者が3か月で新しいポジションをナビゲートするのに役立ちます。 計画は、自己教育（1〜30日目）、リズムの検索（31〜60日目）、自己分析（61〜90日目）の3段階で構成されています。 しかし、まず第一に、マネージャーになるかどうかを決定する必要があります。 多くの人が信じているよりもはるかに重要です（そして、より深刻な結果を伴います）。

0日目：あなたが辞任しなければならない単純な真実

ほとんどの開発者はプログラミングに多くの時間を費やしているため、割り当てられていない場合、リーダーとしての役割を引き受けることはありません。 潜在的なマネージャーは、経験豊富なマネージャーによってのみ識別できます。 「時間が経つにつれて、そのような開発者を選択するとき、内なる本能が機能するはずであることに気付きました」とLoftness氏は言います。 「しかし、将来のマネージャーが、コードから離れた彼にとってまったく新しい立場にいる自分を精神的に想像できない場合、これは結果をもたらしません。」 ロフトネスは、最高の若いリーダーがこの状況を完全に理解し、受け入れることを発見しました。

マネージャーは、3つの方向での行動に備えなければなりません。

「約2年前、私たちの開発者の一人が私に尋ねました：「私は準備ができていることをどのように理解しますか？」ロフトネスは言います。

答える前に、彼は小さな図を描きました。

「開発チームを制御するだけでなく、3つの異なる方向で行動しなければならないことを最終的に理解したら、準備が整います」とLoftness氏は言います。

以下に、これらの3つの分野と、すべての潜在的なリーダーが答えを知っておくべき質問を示します。

• あなたのチーム。 開発チーム、特に元同僚を効果的に管理できますか？ あなたの仕事が何であるかを完全に理解していますか？ チームの目標を実現する責任を負いますか？
• あなたの同僚。 他のマネージャーと効果的に仕事をし、彼らとの対立を避けることができますか？ 同僚と効果的にコミュニケーションをとっていますか？
• あなたの上司。 忙しい上司に、このプロジェクトやそのプロジェクトの状況を簡単かつ明確に説明できますか？ あなたがリーダーに同意しないとき、あなたの視点を守ることができますか？

さらに、ロフトネスは、最も成功しているリーダーが同時に上司の指示に従い、チームを管理し、同僚とやり取りできることを指摘しています。 「これが一連のアクションではなく、タスクのリストであることを想像してください」とLoftnessが追加します。 「リストにある3つのタスクすべてが完了していることを確認する必要があります。たぶんすぐではなく、最初の90日以内に。」

あなたの仕事があなたをどのように動機付けるかを前もって決めてください。

「これはまったく別の仕事です。 ロフトネス氏によると、いくつかのタスクを完了するとすぐに、自分をマネージャーと呼ぶことができるとは思わないでください。 -今、あなたの肩にあなたの病棟の幸福と効果に対する責任があります。 結果に対して責任を負いますが、すべてを単独で処理することはできません。」

マネージャーとして、あなたは助手席で運転しているのではなく、運転しています。 これはあなたをやる気にさせるはずです。 そうでない場合、おそらくこの作業はあなたのためではありません。

他の従業員の責任を負う前に、この地位に就いた理由を慎重に分析する必要があります。 何があなたを動かしているのかを正直に自問してください。 ロフトネスは、善意と悪意が初心者のマネージャーをどのように高めたり台無しにしたかを見ました。 特別な注意を払う必要があるいくつかの事柄はここにあります：

上司を喜ばせるためにマネージャーになってはいけません。 「あなた自身の幸福を犠牲にして上司を幸せにしたいという願望は、就任するのに最適な理由ではありません」とロフトネスは言いました。 -あなたのリーダーがあなたの友人または元同僚であるとき、それは簡単ではありません。 そもそも、なぜそれが必要なのか考えてみてください。

キャリアのはしごを上に移動するマネージャーにならないでください。 多くのIT企業では、開発者と管理者のキャリア成長は並行しています。 「チームを率いていきたい。 ただし、状況を批判的に評価する必要があります。この役割を引き受ける準備はできていますか？ すぐに就任して失敗すると、前進ではなく後退になります。」

チームのみのマネージャーにならないでください。 mart教者の役割を果たしていた場合は、速度を落としてください。 ヒロイックな行為-そしてその後の浮き沈み-は今ではもっと意味があります。 「チームのために自分を犠牲にすることができるかどうかを判断するには、自分自身を十分に知る必要があります」とロフトネスは語った。 「同僚の生活を楽にしたいという願望は高貴ですが、これがあなたが改善したい唯一の理由であるならば、長期的には合理的ではありません。」

あなたの成長が他の従業員の成長に依存している場合、マネージャーになります。 「ある夏、2人の開発者がマネージャーになりました。 このとき、新しいインターンが来ました。 最初のマネージャーは、研修生が彼に執着していると絶えず不満を言っていました。 2番目は、これを若い開発者に何か新しいことを教える機会だと考えていた、とLoftnessは言います。 「管理者も仕事の技術的な部分を好むかもしれませんが、他の人の開発を支援するとき、彼らは完全に満足します。」

共感を示すことができる場合は、マネージャーになります。 これは、優れたリーダーの主な資質の1つです。 「誰もが共感する能力を持っているわけではありませんが、その存在を確認する方法の1つを知っています。 職場で発生した紛争について従業員に話してもらいます。 それから私は彼らに、その瞬間に他の人の頭で何が起こっていたかを説明するように頼みます」とロフトネスは言います。 「他の人が特定のアクションを実行したい理由を説明できれば、これは共感のサインであり、優れたマネージャーのサインです。」

他の人に期待する信頼を示すことができれば、マネージャーになります。 おそらく最も重要なヒント：嘘をつかないでください。 重要なニュースを部下に「内密に」伝えないでください。 信頼関係を維持するだけでなく、確立する別の効果的な方法があります。 「優れたリーダーは、優れたインタビュアーのようなものです」とロフトネスは言いました。 -最高のインタビュアーは、彼ら自身が彼らの対談者に期待することをします。

彼らは事件を伝え、面白い話を共有し、見返りに同じことをします。 明らかに、彼らは議論プロセス全体を制御しようとはしません。彼らは通常、ほとんど何も与えませんが、見返りに多くを得ます。 マネージャーについても同じことだと思います。 質問をし、対談者があなたに無関心ではないことを示すと、感情を共有し、自分自身に対する自信を呼び起こす機会が得られます。

あなたの同僚が仕事で困難を経験していること、そしてあなたの助けを提供するために彼に近づいた最初の人の1人を見るなら、これは良い兆候です。

プログラミングに別れを告げる準備をします。 他の開発者を率いるようになると、技術的な問題のプログラミングと解決はあなたの直接の責任ではなくなります。 ほとんどの新しいマネージャーはこれに対応できず、慣れるのは簡単ではありません。

「適応には時間がかかることがあり、適応が速ければ速いほど、有能なリーダーになるのが早くなります」とロフトネスは言いました。 「もちろん、それはすべて会社の現在の状況に依存しますが、学ぶ必要がある資料の量を考えると、将来のマネージャーは1年間プログラムしないように準備する必要があるように思われます。」

自分で判断する：ほとんどの開発者は、プログラミングの基礎を学び、仕事を得るために大学で4年間過ごします。 この時間の一部を管理スキルの学習に充てる方が賢明ではないでしょうか？ あなたがその年にプログラミングなしでできるかどうかを決めるのはあなた次第です。

Loftnessがコードからリラックスする必要があると言ったとき、彼はそれを書くことを意味することは注目に値します。 「リーダーにとって、コードを書くよりも読むことができることがはるかに重要です。 各リーダーは自分でコードを書きたいという欲求があり、これによりメイン作業から気が散ります、とロフトネスは言います。 -部下が何をしていて、どの段階にいるのかを知るために、多くのコードを読む必要があります。そして、適切な手段を講じます。 誘惑に負けず、マネージャーの職務から逃れるためだけに自分でコードを書いてはいけません。」

ロフトネスでは、多くのマネージャーがこのような移行中に問題を経験しています。 「彼が昇進することを知っていたが、彼が何をするかわからなかった開発者が1人いました。 その結果、経営陣は彼にとって予想以上に厳しいテストであることが判明しました。 彼は私と他のマネージャーを見ました。 彼は、幹部が大量の手紙、会議、コンピューター以外の仕事に散らばっているのを知っていました。」 しかし、彼はプログラミングなしで自分にとってどれほど難しいかを考えなかったので、結局、彼は普通の従業員のままでした。

新しいビジネスと同様に、現在直面している最も重要なタスクは常に不快感を引き起こします。 これは正常です。

「アップグレード後すぐに、プログラミングに慣れなかったため、プログラミングを停止しませんでした。そのため、タスクに迅速に対応しました。 しかし、私はそれを後悔しなければなりませんでした」とロフトネスは言います。 -私は上司に予定より遅れていることを伝えず、私のチームのメンバーの1人について批判的な評価をしませんでした。 部下の仕事の結果にもっと注意を払えば、もっと早く彼の職務に対処できなかった人を解雇したでしょう。 これは、最終的に開発者、プロジェクト、およびチーム全体に利益をもたらすでしょう。 もっと早くプログラミングを停止する必要がありました。」

「「アシスタント」と「アンカー」の違いを確認できる必要があります」と彼は言います。 新しいマネージャーは、病棟が仕事をより良く、より速くするためにすべてを行う場合、「アシスタント」として機能します。 ただし、他の人に開発の機会を与えずに、すべての作業を自分でやろうとすると、彼はチーム全体の「アンカー」になります。

「信頼するが、検証する」とロフトネスは言う。 -従業員がコードを記述する方法を常に監視する必要はありません。 ただし、重要な点に注意を払い、作業の成功または失敗について肯定的または否定的なコメントを述べることは価値があります。 さらに、あなたがまだ同意していない場合でも、時々、彼ら自身のアイデアを実施する自由を彼らに与えてください。 これはあなたの信頼を示す最良の方法です。

「将来のマネージャーが何か新しいことに挑戦したい瞬間を探してみてください。 もちろん、現在のタスクが重要であり、その失敗がプロジェクト全体を混乱させる可能性がある場合、これは適切なタイミングではありません。 しかし、従業員がXを作成したい場合があり、Yを作成した方が良いと思われます。なぜそうするのかを説明してください。 従業員がこれに成功したかどうかに関係なくXを作成できるようにすることで、彼に自分自身を信頼させることになります。

チームと積極的に関わる準備をしてください。 LoftnessがTwitter開発部門のディレクターになった後、彼はすぐに、プログラミングではなく、人々とのコミュニケーションが彼の成功につながることに気付きました。 「私は、テクノロジー担当副社長が立ち上げた主要なプロジェクトを担当しました。 私の上司は仕事が多すぎたので、彼は私にこのプロジェクトを引き受けるように頼みました。 彼の唯一の目標は、製品を発売することでした。」

Loftessは、できるだけ早く製品を立ち上げるために、すぐにさらに3人の開発者を必要としました。 そのうちの1人はかなり慎重であることが判明し、プロジェクトの詳細とその主な目標についてロフトネスに質問し始めました。 「当時、それは当社の主要プロジェクトでした。 彼はTwitterを救わなければならなかった、そして誰もそれを疑わなかった」とロフトネスは回想する。 -しかし、この開発者が私にいくつかの深刻な質問をした後、間違った製品を作成し、このプロジェクトを閉じたことがわかりました。 結局、私たちは別の道を進むことにしましたが、これは私たちのチームとTwitterのリーダーシップのターニングポイントでした。」

マネージャーになるという決定は、製品に直接取り組むのではなく、部下が何をしているのかをよりよく理解し、作業効率を最大化するために、常にコミュニケーションの機会を探すことを意味します。 以下に、ロフトネスがチームとの相互作用を改善するために使用する2つの非自明な方法を示します。

将来の計画に関する継続的なコミュニケーション。 「おそらく、これは最初の会議では起こりませんが、すぐにあなたの従業員が何を目指しているかを知る必要があると思いますか？ 将来の仕事の目標は何ですか？ 通常、彼らは「ただ開発者になりたい」と言っています。

ただし、たとえば、「数年後にマネージャーになりたい」、「いつかスタートアップを立ち上げたいので、これに役立つすべてのことを学ぶ必要がある」、「認められた技術専門家になりたい。」 それはともかく、これらの質問をし、このトピックについて従業員と定期的にコミュニケーションを取ることが非常に重要です。

順次アクションのリストを作成します。 「毎週月曜日の朝に上司と会い、午後にチームとミーティングを行い、火曜日から各従業員と個別に話します。 この一連のアクションのおかげで、情報は最上部から送信されるため、開発者は常にすべての問題について最新情報を入手できます。 そうしないと、プロセス全体の速度が低下し、自分または他の誰かの情報が失われます。 このような一貫性のない相互作用により、マネージャーは簡単に何かを見逃す可能性があります。」

ご覧のように、マネージャーの地位に就く前であっても、よく考えて準備し、詳細な計画を立てる必要があります。 これらすべてを早く実行し、目標をどのように達成するかを決定するほど、さらなる作業の準備が整います。 あなたがリーダーになることについて心を変えていないなら、これはあなたが次にしなければならないことです。

1〜30日目：独学

マネージャーになることを決めた場合、最初の月を独学で過ごす必要があります。 このために、Loftnessはいくつかの方法を提供します。

自習の時間を確保します。 管理の知識を得るための簡単で効果的な方法は、スケジュールにこれを確保することほどありません。 これは余分な時間であり、新しい従業員とのミーティングや、知識を実践する個々の会話はカウントされません。 「真剣に、カレンダーを開いて、自分のために別の時間を取っておきます」とLoftnessは言います。 「現時点では、メンターとのミーティングであれ、管理方法に関する文献を読んだりであれ、あなたはより良いマネージャーになるためにあらゆることをします。」

以下は、ロフトネスが各マネージャーのために読むことを推奨している資料です。

• 「 人的要因。 成功したプロジェクトとチーム 」Tom DeMarcoとTimothy Lister。 常に本：一部の詳細はすでに時代遅れですが、原則と基本的なアプローチは依然として関連しています。
• 「 神話上のマンマンまたはソフトウェアシステムの作成方法 」Frederick P. Brooks Jr. 「特効薬はありません」という記事を含む最新版に慣れておくことをお勧めします。
• 「 主なことは、すべての規則を破ることです 」、マーカスバッキンガムとカートコフマン。 彼らは、優れたリーダーになるために何をする必要があるかについて、ギャラップ研究所からの多くの情報を分析しました。

さらに、ガバナンスの特定の原則を要約した優れた作家が数多くいます。 中でも、 Joel Spolsky 、 Randy （ニックネームMichael Lopp）、 Bob Suttonを強調する価値があります。 彼らのすべての判断を真実と見なさないでください。チームをより良く管理する方法のアイデアを形成するためにそれらを使用してください。

自己啓発に従事していることを隠さないでください。 若いリーダーはチームからすぐに学びますが、他のトリックも使用します。 「独学の時間を確保するときは、隠さないでください」とロフトネスは言います。 -チームにスケジュールが表示されます。 多くのマネージャーは、カレンダーを調べることを許可していないため、チームを混乱させたり警告したりする可能性があります。 従業員は、彼らから利益を得始める前であっても、あなたの努力に感謝します。 カレンダーで時間を選択し、タイトルを付けるだけです（例：「マネージャーのスキルの平準化」）。

メンター（または2人、3人）になるマネージャーを見つけます。 ロフトネスがインタビューしたマネージャーのほぼ半数は、経営経験のあるメンターからアドバイスを求めたことはありませんでした。 これは逃した機会です。 「最初の1か月で、上司に良いメンターをアドバイスしてもらいます。 しかし、彼にメンターになるように頼まないでください」とロフトネスは言います。 -上司から必要な推奨事項を既に受け取っているはずです。 少なくとも部分的に別の方向で働いている人を見つけてください。彼はあなたに追加のアドバイスやアドバイスを与えることができます。

あなたのリクエストに感謝するマネージャーの数に驚くでしょう。 「TwitterとAmazonのディレクターは、ほとんどの場合、初心者エグゼクティブを支援する時間を確保する準備ができています」とLoftness氏は言います。 -誰かに直接尋ねることができない場合は、リクエストについて経営陣に連絡してください。 質問は非常に単純でなければなりません。「時間をかけて管理に関するいくつかの質問に答えてくれる人が必要です。 誰もが今無料ですか？」

31〜60日目：リズムを見つける

2か月目の目標は、リズムを見つけるのに役立つスケジュールを作成することです。それは、プログラマーとして働いたときのリズムとは大きく異なります。 以下は、ロフトネスと彼がインタビューした他の多くのマネージャーからのヒントです。

会議をキャンセルします。 逆説的に思えるかもしれませんが、管理者が犯す最も一般的な間違いは、会議に常に参加することです。 「適切なタイミングで会議をキャンセルし、それを行うのは良い習慣であると私には思えます」とロフトネスは言いました。 -間違いなく、他の人の努力を尊重する必要がありますが、常にあなたの時間を大切にしてみてください。

他のマネージャーが出席している、または多くの人が参加しているため、会議に招待されます。 最初は、彼を訪問しなければならないと感じるかもしれません。 個人的には、マネージャーに「この会議は私の現在の仕事を果たすのに役立ちますか？」

開発者の時間に関しては、彼らの意見を尊重し、大切にすることが重要です。 「一度、部下について不満を言うのが好きな男性と仕事をしました。 彼はかつて私に尋ねました：「あなたはスーザンが最後の3つの会議にいないことを知っていますか？ 「スーザンは自分で決定を下すことができると説明しました。もし彼が会議に出席する必要があると思うなら、彼はそれが重要だと納得させなければなりません。」

あなたの時間を大切にしますが、他の人を損なうことはありません。 この30日間、チームとの定期的な会議をスケジュールし、管理スキルを向上させるための時間を確保しました。 開発者の時間を犠牲にしてではなく、時間を大事にしてください。 「開発者と会う必要がある場合は、仕事の邪魔にならないように、勤務時間の最初と最後に時間を割り当てようとします」とLoftness氏は言います。 「一日の始めの1時間は、真ん中の30分よりはるかに短い時間です。」

自分で「イベントループ」を作成します。 イベントのサイクルは、マネージャーが定期的に見る必要がある特別なリストです-毎日、毎週、毎月。 「それをコンパイルする目的は、あなたが誤って忘れてしまうかもしれない重要なことをするのに時間をかけることを確実にすることです」とロフトネスは言います。 -毎週や毎月、頻繁に調べるのに慣れるのはより困難です。 あなたが習慣になることが重要です。」 以下は、マネージャーイベントループの例です。


マネージャーイベントサイクル-デビッドロフトネス

イベントのサイクルで効果的に作業するには、スケジュールの時間を割り当てて、質問の各ブロックをタイムリーに確認して回答する必要があります。 スケジュールを変更したり、イベントのサイクルの表示を延期したりする必要がある場合は、大丈夫です。少なくとも情報に基づいた選択を行うことで、必要に応じて優先順位を変更することができます。

場合によっては、問題の解決を延期しないでください。 « . – , – . – , . , ».

61-90: : ?

90- . . -, , , . -, , . , , :

? , « , ». . . , , .

« . . , , – . – . - , ».

, . : .

. , , . « . , – . – . , .

, . , , , , . , , .

90 , , , .

, : , . , . , : , .

? , . , , :

• ? ?
• ?
• ?

90 , . , , . , , - .

, – , , . « , . , , , ? ? – . – , ».

, ? « – – », – . , - .

, , . , 90 , . , , . , , .

? « , – . – , , , . ». 90 : , , , ?

, . , - ? , .

, . . « , , , , , – . – ». , , , . , . , .

90: ,

90- , . 90 , , . , – ! .

, :

90- . , 90- . « , , , – . – 90 – , ». , , , .

, , . , : , , . , . «, , , , – . – , . , , , ».

, . « , , – . – . , , . , , , ».

, .

« 90 . , – . – , – , ».

, . , , , , . 90:

, . , . , , .

. , . , . , , . , , .

, . , . , . « , , – . – .

, , , . , , , : «, , . : ». , ».

. . , , . , « » « » .

, , , , . 90 , , , .

– , . , . ロフトネスのGaiamTV製品開発ディレクター、ジェシー・ウィーバーは、次のように述べています。ソムリエはミニコルクせん抜きを使用せず、ミニチュアソーは木こりと重宝しません。良いマネージャーになるという目標を自分で設定し、計画に固執します。」

トピックに関する別の資料：開発の最初の段階でのエラーの防止-デスクチェックと開始ミーティング。