現在、ITでの作業は、よく知られた理由から非常に人気のある傾向です。 そして、ますます多くの若者がこの特定のビジネスに専念することを決めます。 ただし、コードの作成は万人向けではないため、初心者の選択は、ビジネス分析、テスト（もちろん、手動）、採用、またはプロジェクトマネージャーなどの非技術的なIT専門分野に左右されることがよくあります。 さらに、初心者とは、昨日の学生と他の分野での経験のある人の両方を意味します。 プロジェクトマネージャーとして、さらに詳しく説明したいと思います。
最近では、リーダーやビジネスオーナーの地位が魅力的で、10年後には誰も管理できないのではないかと思います...理由はわかりませんが、英語の知識があり、リーダーシップ、モチベーション、管理に関するベストセラーの本を読んでさえいると信じられていますPMシートの完璧な候補者。 「プロジェクトを管理するために何がありますか。タスクを配り、監視し（厳しく厳しく）、顧客とチャットしました。それが仕事、それから仕事です。」
私はあなたを怒らせるために急いで。 プロジェクト管理に関する知識の分野は、開発者の知識と同じくらい広範です。 他のIT専門分野と同様に、PMの役割には、継続的な自己トレーニングと自己改善のための努力が必要です。 ええ、そうです、あなたはまだ知識とスキルの点であなたよりも多くの点で優れている人々と一緒に仕事をしなければなりません。
この記事では、本質的にエラーであるPMの一般的なアクションについて説明したいと思いますが、最善の意図と知識と経験の欠如を組み合わせることによってコミットされます。 「良いことをしないでください-悪はありません」という言葉は、若いマネージャーの素朴さの結果を非常に明確に示しています。
アクションNo. 1「誰かにタスクを任せるかどうか」
典型的な状況は、マネージャーがすべての必要な情報を提供せずに、またはその人が実際にそれを完了するために必要なものを詳しく調べることなく、チームの誰かにタスクを委託する場合です。 もちろん、彼はそのようなアプローチを「委任」と呼びます-結果に対する責任を持つタスクの転送。
結果。 タスクは遅延するか、正しく完了しないため、プロジェクトに悪影響を及ぼします（結局、このようなシナリオは想定していませんでした）。 そして、もちろん、「あるべきすべてを」しない部下は有罪になります。
思考の出発点。 開始するには、委任という用語をよく理解してください。
委任とは、タスク、権限、または責任の譲渡であり、その達成のための資金と結果の品質に対する実行者の責任を同時に提供することで、誰かに目標を設定します。
V.V. グルホフ（「管理」。大学の教科書、第3版）
定義からわかるように、適切な委任のために、マネージャーはその人がタスクを完了するために必要なすべてのものを持っていることを確認する必要があります（目標、知識、権限、情報へのアクセスなどを理解する）。 したがって、次回タスクを任せるときは、 要求する前にまず説明するか、教える必要があることを忘れないでください 。
アクション番号2「そして、助けましょう...」
最善の意図から、一部のマネージャーは、できる以上に助けることが自分の義務だと考えています。 そして、デザインでレイアウトを検証し、要件を修正し、Sabtaskiを分解し、テストし、まだ仕事をするために...マネージャーは、直接的な義務を果たす代わりに、単に武装したシヴァに変わります。小さくなっているのではなく、逆です。
結果。 他の誰かの仕事にtoれているPMは、焦点を失い、チームと一緒にプロジェクトを正常に実装するという主なタスクに対処できなくなりました。
思考の出発点。 このトピックは、Ken BlanchardのOne-Minute ManagerとMonkeysで美しく明らかにされています。 主なアイデアは、他の誰かの仕事を実行するための努力を分散させることではなく 、可能な限りあなたの当面の責任のために時間を解放することです（結果の生成、新しいアイデアの管理、統合、開発、実装）。
アクションNo. 3「すべての点でお客様と合意しました」
残念ながら、チームのタスクを単純に「下げる」ことは非常に一般的です。 PMは、目標、優先順位、何かをしている理由が会社や顧客にとって非常に重要であるということについて、追加情報を公開する必要はないと考えています。 私たちは「説明する時間がない」という原則に取り組んでいます。 しかし、無駄に！
結果。 無知なチームはしばしば間違った方向に進み、アイデアを共有する機会がありません（そして、これは非常に大きな損失だと信じています）。結果はスプリントやプロジェクトの失敗にさえなります。
思考の出発点。 常にチームに必要なことだけでなく、理由も伝えてください。 第一に、このようなアプローチは信頼できる関係を構築するのに役立ちます。なぜなら、単に指示を与えるだけでなく、人々を連れ去り、プロジェクトの作成に最大限の役割を果たすように動機付けるからです。 第二に、顧客の前で失敗に対して自分自身を保証します。 チームが何を行っているかをよりよく理解するほど、エラー、矛盾、およびリスクをより迅速に特定できます。
アクションNo. 4「月曜日から私たちは新しい方法で生きる」
ここでは、若いPMが頻繁に実装することを好む無謀な変更について説明します。 ほぼすべての書籍、記事、またはレポートで、プロジェクトで提示された資料の実験とテストの呼び出しを見つけることができます。 私はこの経験的アプローチに完全に同意しますが、それでも危険に満ちています。 多くの経験豊富な開発者は、そのような変更について懐疑的です。彼らの経験では、すでにこれを経験しているからです。
結果。 新しいファッショナブルな用語が豊富にあり、宣伝されている作業方法をプロジェクトでそのまま最高の結果で引き出しても、何の結果も得られません。 最悪の場合、このようなグローバルな突発的な変更により、作業が完全に停止し、必要に応じて、プロジェクトの麻痺に混乱と混乱が生じる可能性があります。
思考の出発点。 問題を十分に深く研究し 、新しいアプローチの本質と目的を理解していることを確認してください。 会社の一般的な特性、文化、ポリシーを考慮して、プロジェクトで新しいアプローチをどのように適応させるかを考えてください。 段階的に実装します 。 これにより、チームに負担をかけすぎないようにし（誰も現在のタスクをキャンセルしていない）、追加の調整が必要であることに気付き、結果を測定して客観的な結論を導き出すことができます。 チームに新しいアプローチを提示し、意見を求めます。 チームがあなたのサポーターになることは非常に重要です。結局のところ、彼らは毎日新しいプロセスで作業しなければなりません。
アクションNo. 5「すべてを正しくやった」
多くの場合、障害の障害がチームメンバーの中からその所有者を見つける必要がある場合に観察されます。 そして最も悲しいことは、この男自身が問題が彼にあることに完全に同意するということです。 間接的または直接的に、ほぼ90％のケースで、何が起こったかの責任は経営者にあることに注意することができます。 結局のところ、プロジェクトの最適なプロセスを整理し、順守するのはPMであり、スムーズな作業に役立つように設計されています。 そして、プロセスの失敗はマネージャーの責任の範囲であり、マネージャーは何かがうまくいかなかったことを時間内に単に気づかなかった。
結果。 何が起こったのかを誤解するため、「火を消す」以外の措置は取られないため、同様の問題が将来発生します。
思考の出発点。 このような逸脱を慎重に分析してください 。 問題の本当の原因を探し 、負の結果に対する責任をチームと分かち合う勇気を持ってください。 原因を取り除いて初めて、この問題がもう気にならないことを確信できます。 あなたの間違いを認めることで、チームからも尊敬を得るでしょう。 そして、リーダーシップを尊重しなければ、疑う余地はありません。
アクションNo. 6「これを3年間行ってきましたが、うまくいきます」
マネージャーの自信に関連するもう1つのケースは、学ぶことをためらうことです。 たとえば、すでにある程度の経験があり、すでに必要なスキルと知識をすべて持っていると思います。 しかし、実際には、過去に開発された方法が新しいプロジェクト（会社）で結果を達成するのに役立つという保証はありません。 きっと新鮮なアイデアや洞察が必要になります。
結果。 ITコミュニティの成果を頑固に無視すると、プロジェクトを実施する方法が新しい顧客や雇用主に合わなくなる可能性があります。 あなたは恐竜のようになり、突然大都市の真ん中にいることに気づくでしょう。
思考の出発点。 常に新しい知識を受け入れます。 新しいトレンドをフォローし、文学、ブログを読み、ビデオ会議を見ます。 幸いなことに、インターネットには膨大な量のさまざまな有用な情報があります。 欲望だけが必要です。
結論として、私は厳密な唯一のマネージャーの時代が歴史に残っていることに注意したいと思います、そして私はPMが主な仕事が助けることであるチームの本格的な選手であると思います。 円滑化はPMの重要な焦点になりつつあります。 チームで友情を築き、専門家として各メンバーの成長を促進し、ユーザーにとって必要かつ有用な製品を生産し、顧客とのパートナーシップを構築できるようにするために、それが現代のプロジェクトマネージャーの努力のすべてです。 常識が虚栄心に勝つことを望み、そのようなプロフェッショナルは、会社の規模や名前に関係なく、すぐにあらゆるプロジェクトで見つけられることを願っています。 そして、PMの役割を選択することを固く決めた場合は、長い間知られている「レーキ」をバイパスして、正しい方法で進んでください。