チームで働くかどうか?

チームワーク








チームで、通常の開発者の観点から、チームで、プロジェクトマネージャーの観点から、チームで操作し、組織の観点から作業する方が良いという考えは頻繁に発生しますが、これらのステートメントに対する実用的な議論はほとんどありません。 したがって、私はこのギャップを埋め、チームの利点を正当な理由で証明したいと考えています。



この記事は、はっきりと目に見えて議論の余地のない4つの主要な利点に分けられます。これらの利点に基づいて、組織でのチームワークの合理的な導入を開始できます。 実際、利点ははるかに大きく、それらの説明に関する作業は一連の本を作成するのに役立ちます。



そしてもう一つ。 組織を構築するための代替モデルとして、「孤独なプログラマー」のモデルを呼び出します。



チームの結束


チームの結束








どんな組織も主に人であり、彼らがより多くの何かの一部を感じ、どれだけ互いに助け合うかは、彼らが快適に感じるかどうかに依存するため、チームワークのこの利点から正確に始めましょう。組織全体のパフォーマンス。



一緒に-私たちは一人で強さ-私たちは誰もありません。 チームとして働くことで、どんな複雑なタスクでも、単独で行うよりも速く、より良く、より楽しく完了します。 また、「エンドカスタマーにチームを使用する方が費用がかからない」という疑問が生じた場合でも、自信を持って回答します。いいえ。 同じタスクで作業するときにチームと1人のプログラマの工数を数えると、チームの支出が少なくなることが実験的にわかっています。 信じられない場合は、確認できます。



毎日同じ人と仕事をしていると、従業員はチームに近づき、職場での永続的な感覚が得られます。これは「孤独なプログラマー」のモデルにあまり欠けており、職場で不必要なストレスを引き起こします。 もちろん、キャラクターを「挽く」には少し時間がかかりますが、「挽く」後の期間と比較しても重要ではありません。



チームでは、開発者はいつでも友人のサポートと助けを頼りにすることができますが、「孤独なプログラマ」のモデルでは、これを行うことはできません。友人はいつでも追加のタスクや新しいプロジェクトなどでイライラする可能性があるためです



新しい従業員はより簡単にチームに参加します。仕事を開始するタスクとその実行方法を選択する必要がないため、チームが彼のためにそれを行うため、そのような人は彼のキャリアの最初にリラックスする機会がなくなり、そのような従業員ははるかに速く開発できるようになります。



思考の統一


思考の統一






さまざまな開発者が同じ問題をさまざまな方法で解決できることは秘密ではありません。おそらく、各開発者は、タスクのソリューションスキームをめぐる紛争がそのようなソリューションの実装よりもはるかに時間がかかる状況に直面しました。 この状況は、開発者が互いに長時間作業する場合、ワークフローから容易に除外されます。この場合、不必要な紛争に時間を浪費することなく、単一のソリューションを選択して常に使用します。 さらにもう1つ、チームの決定は常により客観的かつ最適であるため、チームが開発した製品はより適切に機能します。



そして、開発者の日常生活でよくあるもう1つの状況があります。別の開発者が行っていたプロジェクトの一部を緊急に修正する必要があり、それを修正する方法がわかりません。 そして、「孤独なプログラマー」モデルではど​​うなりますか? 最良のシナリオでは、彼らは指でそれを行う方法と、最悪のシナリオではあなた自身が探している場所をあなたに説明し、多くの時間を失います。 チームが問題を解決する際に一般的なアプローチを使用する場合、このタスクは再び自己排除されます。 開発者は検索も質問もしません。



最後の1つはコミュニケーションの問題です。 開発者は同じ人と長い間仕事をしてきたので、意見を一言で伝えることができ、言葉の底から同僚を理解することができます。これは、プロジェクトに関する極端な読書の状況では非常に重要です。



統一コーディング標準


統一コーディング標準








そして、あなたの組織では、不十分に書かれたコードに専念している論争とresみがいくつありますか?

チームワークの過程で、開発者は同じように考えるだけでなく、同じコードを記述し始めます。よく説明された共通のコーディング標準がなくても、大きな負荷やイニシエーターの不足を考慮してそれらを記述する方法はありません。 「研削」のプロセスにおける標準であり、暗黙のうちにそれらに従って、それらを補足します。だれも議論したくないので、これは事実です。



また、新しい従業員は、すべてのチームプロジェクトで統一されたフォーマットのコードが存在することや、古い従業員が他の人のコードを書き直そうとしないことを考慮して、新しいプロジェクトを積極的にトレーニングすることを考慮して、これらの標準をすばやく理解して使用できるようになります。



外的要因に対する耐性


外的要因に対する耐性








何かを非常に緊急に仕上げる必要があるようなことがあったことがありますが、コーダーがなければ簡単に不可能ですが、そうではありませんか? Webサーバー管理者が最も都合の悪い瞬間に適切な場所にいない場合、この厄介な気持ちを理解していると思いますが、htaccessを修正する必要があります。 または、アプリケーションが不適切に更新された後、フロントエンドプログラマが病気になりました。

したがって、クロスファンクショナルチームアプローチを使用する場合、上記の状況ではアプリケーションの開発とサポートを停止することはできませんが、少し遅くするだけです。 実際、チームである閉じた社会では、従業員は知識と経験をより積極的に共有し、専門分野でチームの各メンバーを育成します。 その結果、しばらくして、各従業員が異なる役割を果たし、必要に応じて病気または不在の同僚を置き換えることができるチームができました。 したがって、開発者またはレイアウト設計者のフロントエンドを強調することについての質問は、それ自体ではなくなりません。

機能横断型チームは同時に複数のプロジェクトに簡単に対応し、十分な数の従業員を抱えて最大5つのプロジェクトを容易に開発およびサポートすることに言及する必要があります。 これは個人的な経験から取られたもので、必要に応じて確認できます。



集中管理


集中管理








従業員の仕事の成果と欠点を追跡することは難しくありませんが、そのような従業員は10人未満ですが、それ以上の従業員がいると、「仕事での偉業」や「仕事への欲求の明確な緩和」が見過ごされることがよくあります。 会社のスタッフが多いほど、気付かない人が増えます。 これは事実です。



しかし、各従業員からチーム1に責任のレベルを移した場合、チームは従業員がリラックスすることを許可しない刺激者になります。 そして、数十人の従業員の間でよりも、いくつかのチームの間で成果や欠点を見る方がはるかに簡単です。

したがって、多くの従業員を複数のチームに分割する-リーダーシップの仕事にかかる時間が短縮され、昇進と処罰の複雑なプロセスが大幅に簡素化されます。



結論


私たちの急速に発展している世界では、組織内と組織外の柔軟な人が勝つので、組織をさらに組織化し、一般従業員のレベルでチームワークを導入する手段を軽視すべきではないと思います。 この投稿は、チームを紹介するためのガイドではありませんが、チームワークについての私の考えだけなので、厳密に判断しないでください。



最後に、集団主義のメリットに関する素晴らしいビデオをお勧めします。







試して、要求して、動かして、手を伸ばしてください!



All Articles