私のキャリアの過程で、私は複数の実際のソフトウェアプロジェクトに参加し、意思決定、実践の採用、チームビルディング、採用、スキルの配布など、すべてのレベルで物事がどのように行われるかを観察しました。明らかに、アプローチが異なれば結果も異なります。 。改善志向のタイプの人である私は、自分の仕事を支援するための最も効果的な実践と最も実践的なトリックに気づき、収集しました。

観察から学ぶことは、それを行うのに困難で長い方法です。代わりに、この知識を本から早く選んでいただければ幸いです。残念ながら、このトピックについては何も見つかりませんでした。それで、私は自分の経験をこの種の知識の他の探求者と共有することに決めました。うまくいけば、それは彼らに数年の個人的な研究を救うでしょう。

この記事では、頑丈で信頼性の高い製品を製造することで、業界の平均的なパフォーマンスを上回る方法を学びます。 ソフトウェア メンテナンスが5〜10倍少ない製品。過去10〜15年間で、私（個人的にもチームも）はすべての期待を上回り、成功の痕跡を残していると、偽りの謙虚さなしに言うことができます。マネージャーはこれ以上幸せになることはできません。

私のチームが非常に短い時間枠で重要なプロジェクトを立ち上げた後、上級管理職から「ハイパフォーマンスチーム」賞を授与されました。夜や週末に滞在することなく、このすべてが自分自身を疲れさせます。ただの普通の仕事。

ご覧のとおり、効果的なソフトウェア作成の知識自体が力です。実は、平易な言葉で説明しても、多くの人が理解できない黒魔術のようなものです。無料で入手できます。ソフトウェア制作の魔術師として認識されたい場合は、このまま読み進めてください。

これは誰のためですか？

ここで重要、重要、重要な免責事項を作成させてください。

私はこれを生産性の向上を必要としている人々に向けます。人生のすべてが生産性に関するものではありません。すべてのソフトウェアプロジェクトでもありません。自分のパフォーマンスで判断されない場合があります。明らかに、これらの慣行はそのときは役に立ちません。

これらの手法は、チームリーダー、アーキテクト、およびプロジェクトマネージャーにとって最も役立ちますが、上級のソフトウェア開発者もこれらの手法の恩恵を受けることができます。

ルール1：ITの考え方を理解する

IT業界は、科学、テクノロジー、アート、ビジネスが混在しています。これらの側面を十分なレベルで理解せずにそこをナビゲートすることは非常に困難です。最大の問題は、業界自体が非常に複雑であるということです。したがって、ベストプラクティスも複雑です。あなたは多くを学び、成功するために多くを練習することによってあなたの知識を検証する必要があります。

信じられないほどの技術更新率はそれを二重に困難にします。 10年前に学んだことはもう必要ありません。したがって、あなたは加速したペースで学ぶ必要があります。

以上をまとめると、IT分野での成功は、生来のスキルや気持ちではなく、実例に基づいていると言えます。決して「腸をたどる」ことも、自分の気持ちだけに基づいて信じることもありません。

新しいアイデアを採用する際のベストプラクティスは、誰かが以前にそれを実行し、それが機能したことを確認することです。

はいの場合、そのアイデアは検討する価値があります。それ以外の場合は、このパスを選択することでチームの生活がどのように改善されるかについて、非常に適切で詳細な説明を求めてください。このテストに合格した場合は、環境に適合していることを実験的に証明する軽量の概念実証プロジェクトをスケジュールします。

ここで理解しておくべき重要なことは、ソフトウェアの問題を解決する方法はたくさんあるので、正しい解決策も間違った解決策もないということです。ただし、ソリューションには良い理解と悪い理解があります。

人がアイデアを詳細に明確に表現したり、このソリューションの採用からチームの成功へのリンクを引き出して他のチームメンバーを説得したりできれば、その人のビジョンに頼ることができ、成功の可能性が高くなることを期待できます。

ルール2：ソフトウェアの作成方法とソフトウェア開発の方法を混在させないでください

ソフトウェアの生産は、ソフトウェア開発に基づいています。ただし、これら2つの目標、考え方、および実践はまったく異なります。これらの領域の1つから別の方法で問題を解決しようとすると、ばかげた結果が得られます。違いを理解し、これらの世界のそれぞれに適切な方法を使用することが重要です。

ソフトウェア開発は、アートとクラフトの組み合わせです。アートコンポーネントは、自動化ツールやソフトウェア開発方法に関係なく、常に存在します。したがって、開発タスクを解決するには、最大限の集中力と、他のすべての気を散らす信号からのシールドが必要です。

経験豊富な開発者をやる気にさせる最善の方法は、すべての人的要因を排除した純粋な技術形式でタスクを提示することです。すべての要件は、技術用語でも表現する必要があります。それらは、単独の研究段階で目標に向かってナビゲートできるように、簡単に検証できる必要があります。

対照的に、ソフトウェアの生産は、 経営管理 ドメイン。あなたは、顧客が何を必要としているかを一方から知っており、あなたが自由に使えるチームリソースをもう一方から知っています。だから今、あなたは目標を達成するためにあなたのチームの努力を向けようとします。一方、進行速度を見積もり、上司に精通した計画を提示することもできます。そこにある重要なスキルは、顧客の希望を理解し、チームの強みを理解し、正式な計画とスケジュールを伝えることです。

そうは言っても、ソフトウェア開発における多くの役割が、チームリーダー、アーキテクト、アナリスト、プロジェクトマネージャーなど、ビジネスとテクノロジーの間の架け橋を築く上で、これらの両方の世界で働いていることを強調したいと思います。これらの役割を担う人々は、2つの現実の面の間を簡単に歩き回り、ビジネスについて話すときと芸術について話すときを理解できる必要があります。

ルール3：永続ストレージを人間の記憶の拡張として使用する

人間の記憶は、容量は驚くべきものですが、限界があります。あなたは予測できない正確さと持続時間で物事を覚えています、そして忘れたとき、それを思いのままに思い出す方法はありません。

そのため、永続メモリストレージを使用して、予測可能な速度で移動します。これは、事後ずっと作成して他の人が使用できるように作成したユーザーマニュアルのような正式なドキュメントに関するものではありません。これは、ソフトウェア開発プロセスを実行するのに役立つ作業中に、ドキュメントを文字通りメモリの外部拡張機能として使用することです。

重要なタスクや複数の人が関与するタスクに直面するときはいつでも、途中で自分の考えや計画を文書化することをお勧めします。できるだけ安くするようにしてください。会社のロゴが記載された正式なドキュメントを作成しないでください。良いツールは会社でしょう ウィキ プロジェクトスペースが含まれています。タスクまたは問題専用のページを作成します（30秒）。その後、アイデアが浮かんだり、他の人と話し合ったりするたびに更新します。

会話を一時停止して、この考えが頭に浮かんでいる間にすぐに更新してください。

会議では、「ちょっと待って、これを置いて」と言い、10〜30秒かけて書面で表現します。文章は広範であってはなりませんが、アイデア全体を紙に移すように、完全で一貫性のあるものにする必要があります。後で、あなたやあなたのパッセージを読んでいる他の人は、あなたが今それを理解しているのと同じくらい明確にそれを理解するべきです。このトリックは多くの時間を節約しますが、その場で文書化することができます。

資本予算プロセスの最後のステップは

この手法には2つの目的があります。

まず、石に強く押し込むことで、成功への道のりをロックします。誰かが何かを忘れたり、同じことを何度も繰り返したり、すでに交渉された同じことを再交渉したりするリスクはもうありません。

第二に、あなたはあなたの心をクリアし、あなたを悩ませていた問題を捨てます。今、あなたの心は次の挑戦に飢えています。なんと生産性の向上でしょう。

これは、あらゆるサイズのプロジェクトまたはタスクに適用されます。大きなものの場合は、プロジェクトが進むにつれて徐々に大きくなるページの階層を持つ大きなスペースがあります。ここでの重要な概念は、タスクを開始する前にドキュメントスペースと構造を準備して、クイックメモリダンププロトコルを確立することです。

技術的なアナロジーを好む人々のために、私は私たちの心を、巨大な処理能力を備えているが操作メモリが限られているプロセッサと比較します。基本的に、一度に1つのことについて考えることができます。この例えでは、ドキュメントは永続的なストレージとして機能しますが、精神は反復的なアプローチで複雑な問題を解決します。ある時点で、次の反復を開始し、前のドキュメントを読み、現在の状態を運用メモリにロードして、しばらく考え、新しい結果でコードとドキュメントを更新することにします。それが完了するまで段階的に。

上記のすべてが言われているように、私は人々が一度に多くのタスクを処理することを奨励しません。それどころか、タスクが少ないほど良いです。ただし、実際に人間が最適化する作業状況は多くありません。マルチタスクが必要になる場合があり、何らかの方法で処理する必要があります。上記のトリックは、それをより適切に処理するのに役立ちます。

ルール4：正式な時間見積もりで時間を無駄にするのをやめる

2つのプロジェクトは同じではありません。次回同様のプロジェクトを行うときは、顧客、目標、チームが異なります。多分異なる技術ですら。標準のツールとコンポーネントを使用している場合でも、それらの構成とアーキテクチャをカスタマイズする必要があります。ソフトウェアプロジェクトを扱うときは、50％から100％のカスタム作業が含まれることに注意してください。それらは、研究、議論、思考、試行、および他の非常に予測不可能な活動を必要とします。実際には、表面に表示されるものとまったく同じプロジェクトタイプであるように見えるものと、以前に行ったこととで大きな違いが生じる場合があります。ひいては、新しいプロジェクトタイプを正確に見積もることはほとんど不可能です。

それが非常に予測不可能な場合、プロジェクトマネージャーはどのようにプロジェクトスケジュールを提示し、それに固執することになっていますか？

文献に記載されているこれを行うための1つの形式手法があります。つまり、プロジェクト全体をより小さなステップに分割するには、各ステップにかかる時間を見積もり、個々のピースの作業長を組み合わせてプロジェクトの合計の長さを計算します。 MBAコースで教えられているこの方法の背後にある理論はたくさんあります。

残念ながら、しかし、数学の量はそれを保存することはできません。この方法は、非常に時間がかかることは言うまでもなく、完全に使用できず、実用的でないという点で、悪名高いほど不正確です。方法論の狂信者の間でさえ、調整なしで正式な計算方法を使用しているプロジェクトマネージャーを見たことがありません。会社がそのような方法の使用法を厳密に課したときでさえも！実際、最高のパフォーマンスを発揮するマネージャーは、以下に説明するように、まったく異なる代替方法を使用します。

優れたプロジェクトマネージャーは、過去の多くのプロジェクトを調査および観察することで、自分の直感を調整します。

優れたプロジェクトマネージャーは、プロジェクトタイプ、環境、関連するリソース、組織タイプ、および実際のプロジェクトの長さに影響を与える他のすべての作業面に注意を払います。もちろん、自分の過ちだけから学ぶ必要はありません。このような観察は、直接的にも間接的にも行うことができます。たとえば、本を通して、または他の人によって行われたプロジェクトを研究することによって、あるいは単に知識人を人に渡すことによってさえ。このような統計的なトップレベルの知識は、個人的なプロジェクトスケジュールのナビゲーションを改善します。

上記の方法の2つの重要な結果を強調したいと思います。

まず、経験を積むと推定精度が向上します。経験の浅い人がどんな強力な方法論を持っていても、それを上手にできる方法はありません。第二に、最良の見積もりでさえ、統計的な観点からのみ有効です。つまり、特定のプロジェクトには4か月から12か月かかる可能性があると言えます。これが正しいと仮定すると、プロジェクトが8か月の平均時間にわたって実行される可能性が50％あることを理解する必要があります。

統計的予測を理解することは、そのような信じられないほどの効果があります。賢明なマネージャーは、そのようなプロジェクトに12か月の見積もりを入れて、それを早期に完了することでみんなを驚かせます。言い換えれば、チームがプロジェクトのスケジュールに従うことを誰も期待していません。

プロジェクトマネージャーとその上司への一般的なアドバイスは、正式な時間見積もり方法論に時間を浪費するのをやめることです。代わりに、プロジェクト期間に関する統計情報の収集を奨励し、この情報を会社全体で共有してください。そのようなアプローチが全社的に実施され、奇跡的な予測精度をもたらした企業を私は知っています。

ルール5：タスクの切り替えと優先順位の調整のコストを理解する

人間の精神は驚くほど自然に設計されています。信じられないほどですが、限界があります。言い換えれば、特定の領域および特定のタイプのタスクで優れているように設計されています。

開発者の心は、ソフトウェア開発において間違いなく大きな資産です。プロジェクトマネージャーとして、それをよりよく理解し、最高のパフォーマンスを発揮できる位置に配置することに興味がありますか？

あまり理論を避けて、簡単に言えばみましょう。理論は、あなたが自分自身または他の人からの経験から学ぶ必要がある前に、あなたをここまでしか連れて行かないことを忘れないでください。

人間の精神には、強力な問題解決とアイデア生成の可能性があります。残念ながら、この可能性を常に活用できるとは限りません。主な理由は、アイデアの生成をサポートするために、問題のすべての部分を同時にアクティブなメモリにまとめておく必要があるためです。そのため、複雑な問題の解決は、タスクが一般化または再定式化されて重要でない部分を切り取り、同時にメモリに保持される要素の数を減らすときに、単純化の段階を経ます。言い換えれば、1つの非常に狭い複雑な問題または複数の単純な問題のいずれかを解決できます。

ただし、比率は線形ではありません。同時に行うことの数を増やすと、問題解決能力が大幅に損なわれます。そのため、人類は常に雇用されており、人生の最適化として役割の分離を採用します。 2人が別々に2つのタスクに取り組んでいると、両方が同時に両方のタスクに取り組んでいる場合よりも、ブレークスルーが速くなります。

もう1つの重要な人間の精神特性は、コンピューターのようにタスクをすぐに切り替えることができないことです。確かに、あなたはただ意のままに何かについて考えるのをやめることはできません。すぐに新しいコンセプトについて考え始めることもできません。そのような精神的な慣性は、航空交通管制のオペレーターによって完全に説明されています。彼らはレーダーを見て全体像を見ていますが、すばやく操作するには、レーダーをメモリにロードする必要があります。新しいオペレーターがシフトチェンジで古いものを交換できるようになるまで、画面を見るのに10分かかります。

さらに悪いことに、私たちは物事を思いのままに忘れることができません。私たちが学んだことはすべて私たちのそばにとどまり、時間とともに徐々に消えていき、新しい知識に使用できるスペースを占有します。さらに悪いことに、この影響は、時には「未完成のビジネス」の感覚によって悪化します。完成したものや、将来必要になることのないものを忘れるのははるかに簡単です。一方、後で終了するために物事を脇に置くと、脳は「将来の参照用」とマークされた情報を自然につかみ、新しい知識をその場所に置きたがりません。

はい。タスク切り替えのアイデアの概要を説明したので、実際の（いわば）思考実験でどのように機能するかを見てみましょう。

10人の通常の開発者が10個の通常のタスク（1人につき1つのタスク）に取り組んでいると想像してください。それらを完全な気晴らしのない環境に閉じ込めることができると仮定すると、各タスクは、単一の心によって一定の時間内に解決することができます。最長の単一タスクを完了するのにかかる時間と同じくらい、すべてがかかります。

それでは、同じ精神実験を繰り返しましょう。今回は、（重要な）理由もなく、開発者間でタスクの割り当てを絶えず切り替えます。毎日、各開発者は取り組むべき新しいタスクを取得します。さらに良いことに、1時間ごとに切り替えましょう。彼らはどれくらい早く終わると思いますか？多分決して。

最初のシナリオのプロジェクトマネージャーは、プロジェクトを効果的に実行することができました。 2番目はなんとかそれを「実行」しました、それは確かに…彼らがその死を促進したという意味で。おめでとう。プロジェクトを殺すこの手法は、単なる時間の浪費に加えて、従業員の士気をゼロにするため、非常に効果的です。

このような「タスクカルーセル」を体験すると、達成感が失われ、このプロジェクトがどこにも行かないことに気づきます。

それがそのような純粋に学術的な方法で彼らに提示されるとき、ほとんどの人々は上記の例に同意するでしょう。しかし、実際の生活では、彼らはわずかな圧力の下で突然すべてを忘れます。ビッグボスが進捗レポートを要求するか、顧客が特定の機能の実装日について質問します。ほとんどすべての外部イベントにより、プロジェクトマネージャーがチームに急いで行き、懸念を表明した後、タスクの再割り当てと優先順位の調整が急増します。あちこちで少し時間を稼ごうとすると、最終的にはプロジェクトをさらに軌道に乗せないことになります。

これは、残念ながら、非常に頻繁に発生する実際のシナリオです。

優れたマネージャーは立ち上がって、感情的な衝撃波を吸収し、それを生産的な将来のディスカッションアイテムに変換することで、このような小さな混乱からチームを保護します。それは感情的には間違いなく難しいことですが、チームを良好なリズムに保ち、チームに成果をもたらす唯一の方法です。

ルール6：システム設計を改善する方法としてアーキテクチャレビューを使用する

IT業界は次の概念で運営されています 以上 -そして 下 -エンジニアリング。面接で出てくると、誰もが過剰設計は悪いと言います。質問自体が「多すぎる」を意味する「オーバー」の否定的な意味合いを伝えているので、それは答えるのが簡単です。実際の実用的な知識は、アーキテクチャが過剰に設計されたときにそれを認識し、初期段階でそれを回避する方法です。

それについての私の実証済みの指針をいくつか挙げさせてください。

まず第一に、必要なすべての機能を提供する別のより単純なソリューションがある場合、ソリューションは過剰に設計されていると見なすことができます。つまり、より単純な解決策がわからない場合は、誰かがあなたの間違いを証明しない限り、提供できる最も単純な解決策があなたの目に最適なものです。

私たちの架空のアーキテクトが真にソリューションの完成を目指している場合、通常のアーキテクチャレビューはそれが十分に最適であることを保証します。残念ながら、アーキテクチャのレビューには、少なくとも数人の他の資格のあるアーキテクトが必要です。多くの場合、利用できない、または実用的でないという危険があります。ピアレビューがない場合、建築家はよくある間違いを犯しがちです。それらを1つずつ確認し、それぞれについて考えられる解決策について話し合いましょう。

最も一般的な間違いの1つは、ビジネスの目的を考慮せずに設計することです。仕事の活動は、最終消費者の満足度や会社の成功、または同様のビジネスニーズに結び付けられるべきであることは明らかです。しかし、多くの場合、そのような目的を考慮せずに全体的または部分的に設計されたアーキテクチャを見ることができます。理由はないか、要約すると、できるだけ多くの現代的なベルとホイッスルを使用することになります。

この場合の建築家は、消費者が支払ったことをしません。むしろ、彼らは彼ら自身の楽しさと喜びのためにかっこいいおもちゃで遊んでいます。これは、正式な業界では決して受け入れられません。それでも、とにかくそれはかなり頻繁に起こるようです。

時々、問題は建築家の個性と特定の技術やツールへの執着にあります。彼らはそれらを使用するのが好きで、解決しようとしているビジネスニーズを首尾一貫して説明することはできません。それに近いのは、人々が小さな断片から何かを構築する以外に何も知らない別のケースです。確かに、外部のイベントは、デザインの世界に飛び込み、実際のクライアントに戻らないという衝動を引き起こします。最初のトリガーは有効なビジネス入力である可能性がありますが、現実からの長期的な分離は、アートワークの有用性を低下させます。

これの治療法は非常に簡単ですが、自己規律が必要です。優れた建築家は、なぜそれが必要なのかを明確かつ正直に答えられるまで、ペンや紙に触れてはなりません。このようなニーズはさまざまな形で発生する可能性があります。これは、正式な要件、製品の改善に対する暗黙の必要性、または以前の設計の効果を低下させる新しいテクノロジーの出現である可能性があります。いずれにせよ、建築家自身が原動力を理解している限り、それは正式な引き金となるべきではありません。次に、この力を設計品質の最終的な検証として使用できます。

もう1つのより難しい検出可能な問題は、ブロックアーキテクチャの考え方に関連しています。そのような精神を持つ人々は、すべてに解決策があると信じており、その解決策は常にビルディングブロックとして実装されています。つまり、アーキテクチャ全体を評価することなく、機能をコンポーネントに直接変換します。それらは、そのような機能の必要性が生じたときに、システムに必要な機能を提供するコンポーネントを接続するだけかもしれません。ほとんどの場合、これは正式な要件を満たしますが、システムは一貫性のない状態のままになります。新しいブロックは、開発、サポート、さらには会社のライセンスモデルに対する既存のシステム互換性に基づいて選択されたものではありません。そのため、チームは既存の構成を変更するか、既存のシステム容量を介してこの機能を実装しようとします。その結果、システムのサポートとメンテナンスは徐々に複雑な悪夢に変わり、パフォーマンスが低下します。

システムのエンジニアリングは芸術であり、新しいコンポーネントを追加する必要があるのか​​、それとも回避できるのかを予測することは不可能であるため、この問題の簡単な解決策はありません。ベストプラクティスは、メンテナンスとアーキテクチャの問題のバックログを時間の経過とともに蓄積し続け、その後、システムアーキテクチャ全体を定期的にレビューすることです。この定期的なレビューでは、出現したテクノロジーも考慮に入れる可能性があります。したがって、アーキテクチャレビューの一般的な目的は、問題を修正することではなく、廃止の迫り来る必然性に対して、望ましい改善とシステム全体の潜在的な実行可能性を評価することです。

ルール7：バリューチームプレーヤー

ほとんどのIT業界の専門家は、面接で彼らが優れたチームプレーヤーであるかどうか、またはチームでうまく機能するかどうかを尋ねられました。それでも、おそらく誰もそれの明確な定義を文献で見たことがありません。明らかに、そのような人は一般的にチームの成功に貢献しますが、実際にそのような成功を保証する独特の個人的な資質を定義できる人はほとんどいません。

私は多くの人々がさまざまなレベルで働いているのを観察し、彼らの個人的な資質がプロジェクトの進捗にどのように影響するかを見ました。チームワークに最も役立つ個人的な資質に関して、以下の指針を提示したいと思います。

コミュニケーション

もちろん、何よりも重要な品質はコミュニケーション能力です。

コミュニケーション能力がゼロの人を想像してみてください。確かにチームメンバーからのフィードバックを受け取らないと、チームメンバーは完全に役に立たなくなります。これは非常に明白であるため、インタビュー中に実際にこのスキルを測定している人は誰もいません。これは、人が上手に話すことができる限り、スキルが十分なレベルにあることを意味します。

コミュニケーションは二者択一のyes / noスキルではありません。それは情報転送ウィンドウのようなものです。幅が広いほど、情報交換はより速く、より明確になります。

コミュニケーションスキルは、その人が持っている他のすべてのスキルの乗数です。

そのウィンドウの開放性の範囲は人口によって大きく異なるため、そのようなウィンドウの幅の測定はチームプレーヤーの重要な特性です。私たちはこの文脈で情報を伝えることについて話しているが、スムーズに話したり、人々を励ましたり、やる気を起こさせたり、話したりコミュニケーションしたりして組織化することについて話しているのではないことに注意してください。

コミュニケーションスタイルも関係ありません。情報は、口頭、テキスト、写真、または混合方法で配信できます。人は速くまたは遅く話すことができます。彼らはあなたの目を見ていつも笑顔のように友好的であるかもしれません、あるいは彼らは目をそらして単調な声で話すことができます。スタイルは同僚の個人的な認識に影響を与える可能性がありますが、その意味を明確に理解している限り、どのスタイルでも十分です。

コミュニケーション能力の検出と測定に関する実際の事例に移りましょう。

一般的なコミュニケーションスキルには2つの主要な側面があります。まず、情報を共有する意欲です。共有したい人もいれば、情報を隠そうとする人もいます。その傾向は多かれ少なかれ自然ですが、自己の動機付けと訓練によってゆっくりと変えることができます。ある種の情報共有意欲を示している人は、将来的にもそれを実証すると考えて間違いありません。そのため、その特性は、チームでの候補者の将来の成功を予測するのに適しています。

実生活では、情報を隠そうとしている人は簡単に目立ちます。彼らは通常、実際に必要なものではなく、意図的に役に立たない情報を提供しようとします。または、予備的な質問をして、情報の流れを内側に向け、「知る必要がある」出来事への回答を最小限に抑えます。彼らの戦術がどうであれ、最終的には彼らから必要な情報を入手できなかった、または情報を入手するには余分な労力が必要だと感じるでしょう。

一部のタイプのオープンな人はあなたの質問をよりよく理解するためにあなたに予備的な質問をし、そして最も便利な方法であなたに答えを提供するかもしれないので、意図を理解することは重要です。情報を隠そうとしている人は、会話を遠ざけるためだけに追加の質問をし、代わりに最初の質問に答えることはありません。

コミュニケーションスキルのもう1つの部分は、リスナーに合わせて調整する機能です。

人によって、トピックの理解レベル、コミュニケーションスタイル、さらには特定の詳細への関心が異なります。一部のコミュニケーションの賢い人々は、それを理解し、特定の情報を提供するための答えを準備するリスナーの能力に応じて、会話の流れを変えるでしょう。そのような準備では、リスナーの関心を絞り込むためにいくつかの予備的な質問が行われる場合があります。コミュニケーションの違いを「解決」する能力は、ほとんどすべての場合に理解を得ることができるので、本当に素晴らしいスキルです。一方、柔軟な話し手は、誤解の解決できない行き止まりに陥ることがあります。

長所と短所を理解する

チームプレーヤーに不可欠な別の個人的な品質に焦点を当てましょう。

ほとんどの人は、コラボレーションを促進し、生産性を高めるために、チーム環境は周囲の平均的な世界よりも友好的であるべきだということに同意するでしょう。したがって、チームが各メンバーの長所と短所を理解してタスクを適切に分散し、短所を長所でカバーすることが重要です。この道の最初のステップは、すべてのメンバーがお互いに対して自分のスキルを正直に測定することです。心理的には、自分の弱点を他の人から隠して自分自身を守る傾向があるため、これは難しいかもしれません。

ここで、フレンドリーなチームの雰囲気が役立ちます。

信頼を築くのは二人の仕事です。

したがって、新しいメンバーはチームルールに従ってプレーすることが期待されています。残念ながら、友好的な環境でも警戒を緩めることができない人もいます。彼らは一生を通じて一匹狼のように振る舞います。これは彼らよりも強いです。悲しいことに、そのような態度はチームの努力に貢献しません。

インタビューでそのような一匹狼を認識する簡単なテクニックがあります。彼らは自分たちが何かを知らないことを決して認めません。もちろん、人々は最善を尽くし、すべての能力を発揮し、すべての困難な問題を解決しようとするのが好きです。それでも、誰にとっても知識の限界があります。私たちの限界は私たちのスキルを形作ります。制限を認めないということは、候補者が何でも屋であり、すべてに等しく何も得意ではないことを意味します。

あなたが専門家を雇うとき、あなたはおそらくそのような人々を避けたいでしょう。その上、その傲慢な態度には、しばしば別の危険信号が伴います。それは、助けを求めたがらないということです。チームワークには、助けを求める能力が絶対に不可欠です。それがなければ、私たちはそれほど速く進歩し発展することはできません。そのような頑固な人は会社のリソースと時間を燃やし、困難な仕事と無期限に戦いますが、チームメートに助けを求めることは決してありません。面接でそのような候補者を見つける簡単なトリックがあります。意味をなさない質問をするか、意味のない用語について言及します。普通の、理想的には好奇心旺盛な人は、彼らが知らないと言って、それが何であるかを尋ねるでしょう。たとえあなたが正しい答えも間違った答えもないこと、そして「私は知らない」が彼らを失格にしないことを強調したとしても、防御的な人は決してそれをしません。

ルール8：チームワーク組織に焦点を当てる

チームワークの編成に関する情報は、上記の以前のトピックほど少なくなっています。チームワークの方が優れていることは誰もが知っていますが、チームを構築して維持する方法は謎のままです。ただし、チームビルディングのすべての側面を網羅することが不可能な場合でも、ここでは少なくともいくつかの重要なチームビルディング手法を探ることができます。

専門知識の構築

各ITプロジェクトは一意です。それで成功するためには、プロジェクトの詳細を学び、習得する必要があります。それらには、技術的知識と非技術的知識の両方が含まれる場合があります。非技術的知識の例としては、管理者、顧客、技術サポートチームなどのパーソナルネットワークがあります。特別な技術的知識は、一般的なITスキルに加えて追加の詳細です。

たとえば、プロジェクトをビルドするためにMavenを知る必要がある場合があります。ただし、正確なビルド構造、プロパティの場所、およびフィルタリングは、プロジェクトごとに異なります。他の種類の知識と同様に、そのような詳細を習得するには時間がかかります。それに投資する時間が長ければ長いほど、彼らはより良いパフォーマンスを発揮することができます。時間はあなたが持っている最も貴重な資源です。チームメンバーをできるだけ長く同じ機能領域に集中させて、専門知識を活用し、さらに発展させて、チームのパフォーマンスを常に向上させたいと考えています。

残念ながら、それを無期限に行うことはできません。一方から、人々はただ退屈するかもしれません。反対側からは、専門知識を失うリスクがあり、予期せずプロジェクトが危険にさらされます。

チームのパフォーマンスをそれほど損なうことなく、マイナス面に対処する方法があるかどうかを見てみましょう。

ほとんどの知的労働者は自然な学習者です。彼らは彼らがそれに優れているまで特定の分野を学びたいと思っています。

チームメンバー間で重点分野を分散し、チームメンバーに専門知識を蓄積させます。ある時点で、それらはこのプロジェクトの範囲で意味のある十分に高いレベルに達します。余分な学習努力は、現時点ではそれを大幅に改善することはありません。やる気と挑戦がなければ、賢い人々は退屈し、仕事を嫌い始めます。

彼らのために他の場所で学習の可能性を開くことによってこれを防ぎます。プロジェクトと会社の技術スタックについて常に情報を提供し、新たな課題を切り開きます。彼らの関心がプロジェクトの範囲内にある場合は、チームに挑戦し続けると同時に、有用なチームスキルセットを拡張するという二重の報酬が得られます。ただし、自己啓発は、プロジェクトの当面のニーズと交差していなくても、退屈を避けるのに適しています。チームの専門家の頭脳が関与している限り、彼らは心の奥底ですでに学習したプロジェクト領域をサポートし続けます。

会社を辞めるとき、チームの専門家は専門知識の大部分を彼らと一緒に持ちます。使用できる対策の1つは、その場で更新できるドキュメントを広く配布することです。前述の「永続メモリストレージ」について考えてみてください。

それでも、プロジェクトマネージャーは、可能であればチームメンバーの頭の知識を複製したいと考えています。すべての専門家のうち2人がいることは、2倍の費用がかかりますが、そのための簡単な解決策になります。しかし、それを行うためのよりスリムな方法があります。秘訣は、ほとんどの開発者に複数の分野の専門知識を開発させ、各プロジェクトの側面が少なくとも1人の深い専門家によってカバーされるようにすることです。同時に、専門知識の深さとともに幅を広げるために、数人のシニアメンバーを選びました。通常、この役割は、チーム開発リーダーまたはアーキテクトが最もよく果たします。チームリーダーは、すべてのチームメンバーと対話し、すべてのタスクの実装に参加します。彼らはプロジェクトのあらゆる側面を活用し、プロジェクトの内部をすべて理解することができます。このようにして、専門家の1人を失った場合でも、リーダーが引き継ぎ、後任者を雇って訓練できるようになるまでプロジェクトの進行を続けることができます。

同じアイデアのもう1つのフレーバーは、隣接する領域で開発者をクロストレーニングし、開発者が同僚の作業を観察、学習、場合によっては試すことができるようにすることです。このクロストレーニングは大規模である必要はないため、開発者の主要なタスクへの集中を妨げたり、生産性を妨げたりすることはありません。リーダーシップとクロストレーニング開発者全体で専門知識を開発することで、予期しない人生の犯人に対する保護のクッションが構築され、プロジェクトリソースを操作する時間ができます。

気晴らしを最小限に抑える

ソフトウェア開発は、複雑で創造的な問題解決の連鎖です。業界の発展に伴い、これらの複雑な問題はますます自動化されていますが、作業は簡単にはなりません。それはまだ大量の芸術と個人の洞察を含んでおり、それは予測するのが非常に難しく、時にはさらに難しいものです。

開発者は武器の端です。それらの濃度は、武器の先端の硬さに相当します。彼らの焦点を増やすと、バターを通してホットナイフのような問題を切り抜けます。それらの気をそらすと、鈍い棒でバターを不器用に突くことになります。

これは強調しすぎることはできません。問題を解決しない作業は、やる気や余分な努力によって強化される可能性があります。 問題解決の仕事のために、あなたは平凡な世界から最大限の分離を必要とします。 日常の問題をすべて残すことは困難であり、優れたプロジェクトマネージャーは、肉体的および精神的な意味で静かな開発環境を構築する必要があります。開発者の職場は、感覚遮断タンクに類似している必要があります。

物理的には、これは閉じた作業スペースとして実装されます。すべてのチームメンバーは、少なくとも孤独に飛び込むことができる場所にキューブを持っている必要があります。大きな音や通路での会話は避けてください。迅速な対人コミュニケーションは、電子メールとチャットによって維持する必要があります。大規模なグループは、他の人の気を散らさないように、会議に密室を使用する必要があります。これは、かつてのオフィスライフのかなり標準的な写真です。

Javaでメモリリークを検出する方法

残念ながら、オープンスペースのパラダイムは、大規模なオフィスでもますます広く採用されています。私は彼の流行に対して警告します。さらに悪いことに、トップマネジメントはオープンスペースとともに、その場でのチームの会話を奨励しています。つまり、本質的には、関与していないチームメンバーの頭上で別の列の人に叫ぶことです。 1日に20回の大音量の会話によって中断された開発者には、集中力の断片が残っていません。確かに主要なパフォーマンスキラー。

学習曲線を考慮に入れる

知識自体が力です。これは、ITなどの複雑な業界に特に当てはまります。ここでのすべてのタスクには、学習、調査、実装という定期的なサイクルがあります。特に学習段階は非常に貴重です。より良い理解はより良くそしてより速い実装を可能にするだけでなく、何かを達成するために渡されなければならない特定の知識の閾値があります。もちろん、過剰学習にも意味がありません。各スキルは、制作のニーズに一致する必要があり、それをはるかに上回ってはなりません。

ただし、多くの場合、開発者は反対方向にプレッシャーをかけられます。学習をやめ、生産する以外に何もしません。学習はタスクの進行状況バーを動かさないため、無駄な労力として認識されます。これは、家に座ってこの記事を読んで、解決するのが本当に簡単な問題のようです。しかし、実際の生活では、わずかな仕事のプレッシャーがすべてのマネージャーを それ 誰もが「学習をやめて始めなさい」と主張する要求の厳しい馬鹿 やって すでに何か。」私は、その正確な言葉を私のキャリアを通して何度も聞いたことがあると誓います…優れたマネージャーとチームリーダーは、プログレスバーを直接増加させなくても、学習がプロセスの重要な部分であることを理解する必要があります。

競争力のある開発ワークショップの構築

上記のヒントとコツは、効果的なソフトウェア制作の専門知識のサブセットです。それらを理解して実際に適用することで、生産効率を少しずつ向上させることができます。それらがほとんど接続されておらず、理論的根拠が不足していると思うなら、あなたは絶対に正しいです。

競争力のある開発ワークショップを構築することは、単一の分野のタスクではないことを強調したいと思います。隣接する複数の分野の知識と専門知識が必要です。そのような専門知識を構築することは大変な仕事です。すべての問題を一度に解決する単一の理論的根拠やアイデアはありません。そのような銀の弾丸を信じることは、本当の目標からあなたをそらすのに役立つだけです。

職場でこれらのヒントを試して、永続的に採用する価値があるかどうかを確認してください。それらが役に立った（または役に立たなかった）場合は、下にコメントを残して、あなたの経験を共有してください！