それでは、開発者がストリーム状態に移行して生産性を最大限に発揮できないようにする12の項目のリストを見ていきましょう。 最も重要なものから重要性の低いものに移行しようとします。 オプションとコメントを提案してください！
誰かがお金と労力を費やす価値があるかどうか疑っている場合、プログラマーに支払われた金額を覚えておいてください。 生産性の10％の増加でさえ、かなりの現金です！
1）会議およびその他の注意散漫
私の意見では、開発者の注意をそらすことが芽の生産性を殺す最も確実な方法です。 彼は、中断された場所から単純に連れて行くことはできません。 彼は最初にプロセスに戻る必要があり、それから思考の連鎖全体を適切な瞬間に行く必要があります-これだけでも30分以上かかることがあります。 そして、そのような中断が多くなると、刺激が蓄積され、作業の質が低下し、バグが多く表示され、このリストを継続できます。
「タスクを開始しようとするときに気が散るほど、試行と試行の間に時間が経過し始めます。 午前中ずっと引っ張られていたとしても、その日が非生産的であることが判明したことは驚くべきことではありません。」-Redditの匿名開発者
さて、会議はどうですか？ 他の注意散漫との唯一の違いは、事前に計画されていることです。 そしてそれは状況を悪化させるだけです。 プログラマが仕事の中断を前もって予想している場合、問題の解決を進めることは困難です。 したがって、1、2時間で計画会議に行かなければならない場合、ほとんどの場合、彼はどのプロジェクトでも重要なことを実行できません。結局、ほとんどのエンジニアリングタスクには時間がかかります。
ポールグラハムが言ったように、「1回の会議で半日を殺すことができます。時間は2つの期間に分かれており、深刻なことはできません」
この状況を回避する方法は？ 長い間これにすべてが描かれているので、言い訳はありません。 計画会議は一日の始めに、または夕食の直前に配置するだけでよいので、必要なく人々を仕事からそらす必要はありません。
2）ニッピック
あらゆる種類のマネージャーのうち、何らかの理由で介入するマネージャーは、おそらく従業員の生産性に最悪の影響を及ぼします。 もちろん、これはまた、この特定のタイプが特に多数の会議を開催し、予期しない理由で開発者の注意を要求する傾向があるという事実の影響を受けます。 しかし、これが唯一のポイントではありません。 そのような行動は信頼の欠如を示し、その結果、人々は自分には何もできないと考えられており、専門的なスキルに疑問を抱いています。 プログラマーが無限の休憩にもかかわらず仕事をするモチベーションを持っていたとしても、そのような態度は彼女を完全に打ち負かすでしょう。 結果は、パフォーマンスの1つの低下に限定されません。 侵入型管理者は、特に従業員に会社または少なくともチームを退職させることがよくあります。
3）不明
明確性の欠如は、多くの異なる例で説明できます。 たとえば、「動作しない、修正する」という精神のバグレポートです。明らかに、開発者が動作に必要なすべての情報を提供するわけではありません。 ところで、この特定のケースでは、バグレポート用のテンプレートの導入が役立つ場合があります。
または別の場合：製品の一部のあいまいな要件。 このような入門的な開発者は、自分が想像するとおりに作業を開始するだけで、マネージャーは予想されるユーザーの行動のより詳細な説明を受け取り、最初からやり直す必要があります。
不明確に設定された優先度は、同じカテゴリに属します。 プログラマーは、最初から何をすべきかについて頭を悩ましていますが、これを避けることは非常に簡単です。 まあ、彼らがこれに従事していない理由をマネージャーに報告する必要がある場合（誰も注文を規定していないという事実にもかかわらず）、あなたはこれが彼らを素晴らしいものにすることを確信できます。
4）カモメマネージャー
これを聞いたことがありますか？ ワークフローにまったく参加していないマネージャーがいます...誰かに急に飛び込んで間違えた瞬間を除きます。 「これはダメで、これもダメですが、まったく見ていません」と飛びました。 認めなければならない、私は比較が好きですが、その背後にある現象は私たちが望むよりもはるかに一般的です。 この振る舞いは開発者に非常に悪い影響を与えます。多くの人は何時間も作業気分を整えなければならず、誰かが一日中ストリームから脱落します。
5）ローレルの盗難
マネージャーや他のプログラマーの一人が、あなたが数週間苦労したことを自分に帰したと思ったことはありますか？ 開発者は、何よりもプロ意識を重視しています。 他の人のメリットを盗むことは、自分の能力を膨らませるために人の能力を否定するようなものです。 そのようなことが非常に緊張した状況につながり、長い間チーム全体のパフォーマンスを「落とす」可能性があると信じているため、この点を十分に高くしました。
6）家具：騒音、動き、作業空間の設計...
他の職業の人にとっては奇妙に思えるかもしれませんが、プログラマにとっては、作業の過程で環境が多くを決定します。 ホワイトノイズ（エアコンの音、路上からの車やトラックの音）を発声すると、集中力が向上します。 それが私たちの多くがヘッドフォンを使っている理由です！ ところで、私は最近RainyMoodを発見しました-素晴らしいことです！
ただし、人の周りに常に何らかの動きがあるようにオフィスが設計されている場合、これは逆の効果をもたらします。 さらに、モニターが、画面上にあるものを常に見るようにインストールされている場合、不必要なストレスと不必要な理由が生じ、開発者がビジネスから気を散らすことになります。
7）プロジェクト境界のオフセット
プロジェクト管理では、この用語は、プロジェクトのボリュームが手に負えないほど成長している状況に使用されます。 これは通常、最初は厳密に定義および文書化されていないか、プロセスで監視されていなかったときに発生します。
国境の移動により、比較的単純なリクエストが混乱したモンスターになり、多くの時間を食い尽くします！ そしてほとんどの場合、これは製品がすでに開発中のときに始まります。
例として単純な関数を取り上げます。
- 最初のバージョン（実装前）：関数は「ロケーションマップの表示」として定義されています
- 2番目のバージョン（最初の反復がほぼ終了したとき）：説明が「3Dロケーションマップの表示」に変わります
- 3番目のバージョン（2回目の反復がほぼ終了したとき）：説明が「ユーザーが移動できる3Dロケーションマップを表示する」に変更されます。
8）製品の機能決定プロセス
一見理解できないように見えるかもしれませんが、実際にはすべてが単純です。 製品の担当者が、特定の機会に対する視聴者の関心について仮説をテストせずに（フィードバックまたはその他の方法で）優先順位を付け、開発者がこれらの機会が単に使用されていないことに気付いた場合、彼らは彼らの仕事は意味をなさず、モチベーションは崩壊します。 私たちは皆、私たちが世界に何らかのマークを残していると感じたいと思っています。これは開発者にとって特に重要です！
9）技術的負債を無視する
技術的義務とは、製品をより迅速に展開するために、ソリューションの選択とコードの作成において一定のストレッチを許可するという意識的な決定です。 ある程度の技術的負債は必然的にプロジェクトで発生し、短距離での締め切りに役立ちます。 ただし、長期的にはシステムの複雑さが増し、開発者の作業が遅くなります。 プログラミングから遠く離れた人々は、生産性に対するこれらのプロセスの影響を過小評価することが多く、この状況で問題が発生し始めます。 リファクタリングが常に優先リストの外側にあると、従業員の生産性が低下するだけでなく、製品の品質も低下します。
10）さまざまなツールと機器
開発者は毎日多くのツールを使用して、コードを記述、プッシュ、およびマージします。 彼らがプロセスを自動化するために管理すればするほど良い。 古代のツールがパフォーマンスに直接影響することは言うまでもありません。 また、1台のラップトップ上または追加の画面上で、作業の多くを決定します。 鉄の価格をプログラマの給与と比較すると、生産性が5％上昇しても、すべてのコストが確実に支払われます！ チームに使用したい機器とツールを提供するだけです（機器の場合、ソリューションは個別、ツールの場合は集合的でなければなりません）。
11）ハウツードキュメント
プログラミングを教える過程で、できるだけ早く、できるだけ頻繁にコードにコメントを追加し始める必要があることを私たちは皆学びました。 アイデアは、コメントが多すぎる方が十分ではない場合よりも良いというものでした。 残念ながら、多くの人々はこれを誤解し、各行に明確化が必要であると判断しました。 そのため、 Jeff Atwoodの記事 「コメントのないコード」から、次のようなサンプルがあります。
r = n / 2; // Set r to n divided by 2
// Loop while r — (n/r) is greater than t while ( abs( r — (n/r) ) > t ) { r = 0.5 * ( r + (n/r) ); // Set r to half of r + (n/r)
}
このコードが何をするのか理解していますか？ だから私は何も理解していませんでした。 問題は、ここではすべてがどのように機能するかについて多くのことを述べていますが、なぜこれが必要なのかについては語っていません。 プログラムでバグが発生し、そのようなコードフラグメントが内部で見つかったと仮定した場合、状況を把握するのに役立ちません。
12）非常に厳しい締め切り
最後の点は、マネージャーが開発者に必要な時間を大まかに見積もってから、この見積りを過小評価してもらい、最終日と期限を魔法のように一致させるように依頼する傾向に関係しています！ 同時に、管理者は、開発者が「期限を自分で設定する」ため、対応する期限にサインアップしたことを意味し、上級管理職に転送できる最終的に承認されたオプションであると考えます。
開発者は、そのような期限は完全な狂気であり、その期限内に維持することは不可能であると信じています。 チームには不和があり、誰も集中できません。
しかし、それは開発者だけのものですか？
これらの12のポイントすべてを見ると、それらはほとんどの場合、プロジェクトに関わるすべての人に関連していることに気付くでしょう。 プログラマーの場合、彼らの仕事はプロセスに深く没頭する必要があるため、彼らは特に重要です。
言及された点のいくつかがあなたの会社にとって典型的なものであることに気付いた場合、開発者のチームとこのリストに沿って進み、それらと対話を行い、問題が発生する場所とそれらを解決する最善の方法を見つけてください。 彼らが何と言っても、このフィードバックとコメントを真剣に受け止めることは非常に重要です。 過去30年間、テクノロジーの面で多くの変化がありましたが、チームワークの基本原則は変わりません。生産性を議論するときは、ヒューマンファクターを考慮する必要があります。 作業プロセス、環境、チームの習慣を改善し、最大の生産性を達成する方法を伝える機会を与えます。