すべてがうまくいきます！
エグゼキューターは問題を解決し、マネージャーは歩くだけで邪魔になるという一般的な信念があります。 しかし、プロジェクトにマネージャーがいない場合はどうなりますか？ 状況を想像してください：怒った手紙がサポートに到着します：「ボタンを押しましたが、500番目のエラーがあります！」 そして、手紙は1つではありません。つまり、問題は大規模です。
バグは誰に渡すべきですか？ サポートが問題がクライアント側で発生したと仮定し、JavaScriptプログラマーにバグを与えたとします。 JavaScriptプログラマーは説明を見て、次のように述べています。「ほとんどの場合、問題はサーバーにあります。 私はそれとは何の関係もありません。」 テクニカルサポートはうなずき、サーバープログラマーに行きます。 サーバープログラマーは、サーバーに問題はなく、コードは信頼でき、すべてが機能するはずだと述べています。 サポートは管理者に送られます。 管理者はプロセッサ、ディスク使用量、空き容量、ログを確認しますが、犯罪者も見つけません。
この時点から、プロジェクトで発生した問題は、「誰の側にも」ありませんでした。誰も自分の責任を考えず、その解決に取り組む必要があるとは考えません。 そして誰もが理解できます。誰もが独自の使命、開発計画を持っています。新機能を見ることは、神秘的な500分の1を選別することよりもはるかに興味深いです。 その結果、すべてがよくできていて忙しい-ユーザーだけがまだ悪いです。
もちろん、これが唯一可能なシナリオ開発コースではありません。 プロジェクトマネージャーのポストを持つ人がいないチームもありますが、それでも問題は解決されます。 ただし、これは、チームメンバーの1人が実際にマネージャーの機能を実行するためです。
では、プロジェクトにまだPMがいると仮定した場合、上記の状況はどのように変化しますか？
ルール＃1：問題はあなたのものになる
まず、問題の所有者を見つけました。これは実際、PMです。 すべての技術者は、問題が彼らにあるのではないことを確信できますが、プロジェクトマネージャーは、ユーザーの問題を自分の問題とみなす義務があります。
ルール＃2：ユーザーは嘘をつかない
これは覚えておくことが重要です。レポートがどんなに狂ったように見えても、特にそれが類のないものである場合、真実はおそらくそこに書かれています。
ルール＃3：ユーザー以外は誰も信用しない
Dr. Houseのスタイルのこの論文は、検討中の状況で非常によく説明されています。サポートをバイパスし、真実を達成しようとする人を信じるなら、誰も問題を抱えていないことがわかります。 しかし、ユーザーは嘘をつかないことを覚えています！
ルール＃4：上記の問題を解決する
問題があり、それが私たちのものであることがわかった後、それを解決し始めるのは良いことです。 常に上から、つまり症状が現れる場所から始めなければなりません。 私たちの場合、症状はユーザーがボタンを押すことであり、その結果、500番目のエラーを受け取ります。
もちろん、Ajaxエンドからの500番目の答えをユーザーから隠すスタブを配置した場合、これは問題を解決しません（ユーザーが遅かれ早かれそれについて知り、もちろん文句を言うという事実は言うまでもありません）。 これから、PMaの5番目のルールに従います。
ルール5：症状ではなく原因を排除します
検討中の状況では、理由の一番下に到達するために、マネージャーはレイアウトデザイナーに移動し、UIで500番目のエラーを表示するケースを見つけます。 レイアウトデザイナーは何に答えますか？ 「サーバーから間違った答えを受け取ったとき。」 -「それでは、サーバーからどのような回答を得ましたか？」-PMは興味を持っています。 「ステータス500」、レイアウト設計者は答えます。 サーバーがコード500で応答を返すと、500番目のエラーが表示されます。これが当てはまる場合（そして、誰も信頼できないことを覚えています）、サーバーで何が起こるかを知る必要があります。そのように動作し始めます。
ルール6：最大の怠lazの原則
プロジェクトマネージャーは最大の怠inessの原則に基づいて行動する必要があるため、この時点でクライアント側のプログラマを信頼し、さらに先へ進む必要があります。
ルール7：問題はPMの責任範囲
この段階で、経験の浅い条件付きPMはどのように行動できますか？ 「彼らはそこで何らかの形で彼ら自身の間で同意するだろう」という希望で、サーバープログラマーにレイアウトデザイナーを送ってください。
開発者が自分のデバイスに任せたらどうなりますか？ タイプセッターがサーバープログラマーに来て、500番目のエラーを報告し、「ああ、まあ、これですべてです」という答えを受け取ります。 タイプセッターは同意します：「ええ、はい、ポイントはデータベースにあります。」 その後、両方ともプログラムにさらに分岐します-結局のところ、ベースはすべてのせいにすることです（これが真実であるという事実ではなく、そうであっても-ユーザーにとっては簡単ではありません）。 その後、1日、2週間、1週間が経過します。この間、マネージャーは問題が修正されたと確信しています。 ユーザーが同じ問題について不平を言う技術サポートから別の怒った手紙を受け取るまで、私は確信しています。 現時点では、条件付きPMは次のように考えています。 しかし、私たちは発見しました！」 そこで彼は、プロジェクトマネージャーの7番目のルールにたどり着きました。私は問題を解決しますが、他の人々はそれらを解決する義務はありません。 まあ、彼らが決定すれば、しかし必須ではありません。
したがって、このような状況では、優れたプロジェクトマネージャーがプログラマーのところに行く必要があります。
ルール8：すべてのステップを記録する
プログラマーは当然、500のエラーには多くの理由があり、本番からのログにはアクセスできないため、何が問題なのかわからないことを彼に伝えます。 ここでは若干の余談が必要です。ログが存在すると、開発者とマネージャーの両方の生活が大幅に簡素化されます。 プログラマが本番からログにアクセスできないことは、解決可能な問題です。 運用環境から開発ネットワークへのログ配信を構成できます。管理者を介して開発者を動機付け、利用可能なすべての方法を使用してログを整理する必要があります。 Cookie、ユーザーデータ、その他の不要なものはすべて削除できますが、ログが必要です。
最もハードコードなオプションを考えてみてください。最近のプロジェクトマネージャーは、ログのインポートを構成していません。本番のデータは本番のみです。 解決方法は1つしかありません。管理者にアクセスして、ログを要求してください。 私たち全員がそれほど悪いわけではなく、まだログがあると仮定します。 しかし、それらは簡潔に「500」と書かれており、それ以上のことは書かれていません。
ルール＃9：主なものを忘れないでください
マネージャーが犯す可能性のある次の間違いは、プログラマーに言うことです。 ロギングを行い、」問題を忘れます。 それは何につながりますか？ 第一に、もちろん、開発者はすべてのケースをロギングでカバーするわけではなく、第二に、ロギングを開発する過程で、もちろん、最初の問題を忘れます。
この状況での動作の正しい計画は次のとおりです。開発者に、他のサービス、データベース、およびバックエンドがどこに行き、エラーが発生する可能性があるかを伝えます。 その後、考えられるすべてのケースを慎重に誓約する必要があります。 この問題が生きている場合は、すぐにログインし、すぐにホットフィックスを展開する必要があります。
そのため、ログが記録され、それらから、サービスが何らかのデータベースまたは他のサービスにアクセスできなかったことが明らかになります。 現時点では、ログを開発者に見せて自分で把握できるようにするか、アーキテクチャに没頭してすべてを自分で確認できるようにするという2つのオプションがあります。
ログ、管理者、その他の即興の助けを借りて、問題の原因が見つかったら、問題の解決に直接進む必要があります。 私たちの場合、SQLクエリの最適化またはAPIの使用、または攻撃的に単純なもののいずれかを使用できます。おそらく、開発者が承認サービスにアクセスして間違ったクライアントIPを送信した結果、エラーが表示される可能性があります。
ルール＃10：症状が消えていることを確認する
エラーの考えられる原因が特定された後、マネージャーはその決定をシステムのこの部分の責任者に委任します。 今、最も重要なことは、症状が消えていることを確認することです。 これは1つの方法でしか確認できません-すべてが問題ないかどうかをバグレポーターから確認するためです。 問題が解決されたと見なされるのは、この後のみです。
真空の完璧なマネージャー
私のプレゼンテーションでは、プロジェクトマネージャーはITのスーパーヒーローであり、自分ですべてを行うことが判明しました。ログを見て、アーキテクチャを知っており、何かが発生した場合は問題を解決できます。 そのような場合は発生しますが、もちろんこれは必要ありません。 ほとんどのマネージャーは、自分自身が何かを見たり修正したりできる正気のプロに囲まれています。 しかし、それでも、私たちが始めた場所を覚えておくことは重要です。開発者は、問題は自分の側にないと信じがちであり、プロジェクトマネージャーはユーザーの問題を苦痛と見なします。 そして、それに応じて動作します。
技術者ではない
私の話からの別の重要な結論：プロジェクトマネージャーは技術者である必要はありません。 「私はどんな問題に対しても責任がある」、「ユーザーは嘘をつかない」、「誰も信用してはいけない」と自分に言うために、特別な技術スキルは必要ありません。 もちろん、技術的背景からの利点があります-それは正しい方向に頭脳を構築し、誰を信頼することが不可能であるかを理解するのに役立ちます-しかし、これはマネージャーにとって重要ではありません。 さらに、多くの場合、問題を解決する過程で、開発者がタスクを非常に練り上げているため、開発者自身が既にその解決方法を理解しており、管理上の決定は必要ありません。
次のシリーズで
この記事では、プロジェクトマネージャーの観点からプロジェクトの問題を解決することについての考えを共有しました。 PMaには他にも多くの興味深いタスクがあります。期限とリスクを管理する方法、新しい機能を迅速かつ効率的に作成する方法です。 これについては、次の記事で説明します。
デニス・アニキン、
Mail.Ru Mailのテクニカルディレクター