効果的なソフトウェア生産のための8つのルール

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

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

この記事では、メンテナンスが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か月の見積もりを入れて、それを早く完了することでみんなを驚かせるでしょう。 言い換えれば、チームがプロジェクトのスケジュールを1日に従うことを誰も期待していません。

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

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

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

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

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

彼らのために他の場所で学習の可能性を開くことによってこれを防ぎます。 彼らにプロジェクトと会社の技術スタックを知らせ続け、新しい挑戦を切り開いてください。 彼らの関心がプロジェクトの範囲内にある場合は、チームに挑戦し続けると同時に、有用なチームスキルセットを拡張するという二重の報酬が得られます。 ただし、自己啓発は、プロジェクトの当面のニーズと交差していなくても、退屈を避けるのに適しています。 As long as the team expert brains are engaged, they keep supporting already-learned project areas in the back of their minds.

When leaving the company, team experts take a big portion of expertise with them. One of the countermeasures you can use is to widely disseminate documentation that can be updated on the fly. Think of the “persistent memory storage” mentioned earlier.

Still, a project manager would love to duplicate knowledge in team member heads if possible. Having two of every expert would be a simple solution for that, albeit twice as expensive. But there is a leaner way to do it. The trick is to let most of your developers develop expertise in multiple areas, so that each project aspect is covered by at least one deep expert. At the same time, chose a few senior members to grow the breadth along with the depth of their expertise. Usually, this role is best played by a team development lead or an architect. The team lead interacts with all team members and participates in all task implementations. They can tap into each and every aspect of the project, understanding all of its internals. This way, even if you lose one of the experts, the leader can take over and keep on the project progressing until you can hire and train the replacement.

Another flavor of same idea is to cross-train developers in adjacent areas, letting them to observe, learn, and occasionally try their peers' work. Keep in mind that this cross-training needn't be extensive, so it doesn't disrupt focus on developers' primary tasks and doesn't impede productivity. Developing expertise across leadership and cross-training developers builds you a cushion of protection against unforeseen life culprits and allow you some time to maneuver with project resources.

Minimizing Distraction

Software development is a chain of complex and creative problem solving. Even though, with industry development, these complex problems get more and more automated, the work doesn't become easier. It still involves a large amount of art and individual insight, which is very hard to predict and sometimes even harder to wrangle.

Developers are the edge of the weapon. Their concentration is equivalent to the hardness of the weapon's tip. Increase their focus and you'll cut through problems like a hot knife through butter. Distract them and you'll end up clumsily poking at the butter with a blunted stick.

This cannot be over emphasized: Non-problem-solving work can be intensified with motivation or extra effort. For problem solving work, you need maximum detachment from the mundane world. It is difficult to leave all everyday problems behind, and a good project manager should build a quiet development environment in both the physical and mental senses. A developer's workplace should be analogous to a sensory deprivation tank.

Physically, this is implemented as a closed work space. Every team member should have a cube at least where they can dive into solitude. It is preferable to avoid loud noises and aisle conversations. Quick interpersonal communications should be maintained by emails and chats. Large groups should use closed rooms for their meetings to not distract others. This is a pretty standard picture for office life as it used to be.

Unfortunately, the open space paradigm is being adopted more and more widely even in large offices. I would warn against his fad. Even worse, together with open spaces, top management encourages in-place team conversations. That is, in essence, shouting to a person in another row over an uninvolved team member's head. A developer that is interrupted by loud conversation twenty times a day won't have a shred of concentration left. Certainly a major performance killer.

Allowing for a Learning Curve

Knowledge itself is power. This is especially true for such a complex industry as IT. Every task here has its regular cycle: learn, research, implement. The learning phase in particular is invaluable. Not only does better understanding allow better and faster implementation, there are certain knowledge thresholds that must be passed in order to achieve something at all. Of course, there is no point in over-learning either. Each skill should match the production need and not much above it.

However, often, developers are pressured in the opposite direction; to stop learning and to do nothing but produce. Learning is perceived as wasted effort, as it doesn't move the task progress bar. This seems like a really easy problem to solve, sitting at home and reading this article. Yet in the real life, the slightest work pressure turns every manager into that demanding idiot who insists that everybody “stop learning and start doing something already.” I swear, I have heard those exact words so many times throughout my career… A good manager and team leader should understand that learning is an important part of the process even if it doesn't directly increment the progress bar.

Building a Competitive Development Workshop

The tips and tricks presented above are a subset of effective software production expertise. By understanding and applying them in real life, you'll improve your production effectiveness little by little. If you think they are largely unconnected and lacking a theoretical base, you are absolutely right.

I would like to highlight that building a competitive development workshop is not a single-discipline task. It requires knowledge and expertise in multiple adjacent areas. Building such expertise is a hard work. There is no single theoretical base or idea that would solve all your problems at once. Believing in such a silver bullet just serves to distract you from the real goal.

Try out these tips at work to see if they are worth adopting permanently. If you find them useful (or not), leave a comment below and share your experience!