/写真： Joshua Blount CC
Habréのブログでは、クラウドサービスの使用方法とIaaSの機会の範囲について書いています。 また、サービスやアプリケーションの効果的な開発のトピックについても触れます。たとえば、先週、開発チームと効果的にやり取りする方法に関するいくつかのヒントをマネージャーに提供した資料を公開しました。
今日は、労働時間のトピックに触れたいと思います。 ソーシャルサービスQuoraのユーザーの1人が、開発者の間で激しい議論を巻き起こす質問をしました。 彼は、プログラマを週に80時間以上オフィスに滞在させる方法を見つけようとしました。 このトピックに興味があり、開発者自身がそれについてどう考えているかを見ることにしました。
表面的な外観
ソフトウェア開発から遠く離れた人々は、残業の従業員のモチベーションを高めるための質問の著者に標準的なアドバイスを与えました。 マネージャーは、オフィスでプログラマーが去りたくない条件を作成することをお勧めしました。無料の食べ物、運動器具、寝る場所、シャワー、娯楽です。 議論の参加者によると、このアプローチは、そのようなオフィスに住むことが自宅で暮らすよりも魅力的である単一のプログラマーに特に有効です。
開発者の生産性の低さは、チームに彼の例で彼女を鼓舞する強力で権威あるリーダーがいないという事実とも関連していました。 問題を解決するのは簡単です。プログラミングの分野に精通し、熱意をもって開発チームに感染するプロジェクトマネージャーを引き付ける必要があります。 もちろん、経営陣がスタッフに週80時間働くことを望んでいる場合、その人はそれ以上ではないにしても同じくらい働くべきです。
会社が株式を使った支払いを行う場合、報酬の額はまともなはずです-少なくとも従業員の給与に匹敵します。 しかし、経営者が生産性の向上を望んでいる場合、報酬は適切でなければなりません-従業員の能力に応じて、2倍、3倍、10倍の給与。
多くの人は、興味深い問題を解決できれば開発者自身が疲労困pointするまで働くと指摘しました。 プロジェクトが退屈で日常的なものである場合は、人を正しく動機付け、退屈なタスクを別の観点から提示するだけで済みます。開発者自身が熱狂的にそれを実行し始めます。
従業員は、たとえば癌診断技術や指紋認識システムなど、社会的に有用なプロジェクトに取り組んでいることに気付いた場合、内発的な動機を取得します。 この場合、開発者は外部からの動機を必要としません。
そして、もっと深く掘るなら？
ただし、上記の回答の割合は非常に少ないです。 回答したプログラマーのほとんどは、この質問でより深い背景、つまり労働力を評価する問題と部下を尊重する問題を見ました。
ほとんどの人は、プログラマが最適な生産性を達成するために週に60〜80時間働く必要がないと言います。 すべては、生産性がオフィスで費やされる時間と同一ではないためです。 プログラマは週に100時間オフィスに座ることができますが、半分以上の時間にわたって抽象的なアクティビティで忙しく、暴力的なアクティビティの幻想を作り出しているとしたら、何が良いでしょうか？
マネージャーが開発者の作業を勤務時間ごとに評価する場合、経験の浅いため、だまされる可能性があります。 賢明な開発者は、規制された期限よりはるかに早くプロジェクトを完了できることを知っていれば、時間ベースの作業の提供を拒否しません。
プログラミングに精通していない人が、働くプログラマとそのようなふりを区別しないことは注目に値します。 同じことは、書かれたコードの量を支払う場合にも当てはまります。ソフトウェア開発から遠く離れている人は、最も単純な操作であっても、任意の多数の行で記述できることを知りません。
プログラマの時間を評価することは困難です。 彼はインスピレーションがないので、彼は一日中インターネットに座ることができ、夕方にはシャワーを浴びて、働くコードを思いつきます。 インスピレーションは週末の夜に来る可能性があるため、開発者は自分の時間内に作業する必要がありますが、雇用主が支払うことはほとんどありません。
プログラマーは、経営陣が自分の仕事を適切に評価できないと不満を言っています。 マネージャーは、アプリケーションに新しいボタンを追加するように依頼することがありますが、その背後には何百行ものコードと何時間もの操作があることに気づきません。 タスクがプログラマーに馴染みがあり、彼が過去の経験に頼って数日でコードを書いた場合、働いた時間だけに彼に支払うことは不公平で攻撃的です。 雇用主は、人件費を評価する際に、オフィスで費やされた時間だけでなく、経験とスキルも考慮する必要があることを理解する必要があります。
このトピックにはひげを生やした逸話があり、質問に答えた開発者の一人が共有しました。
男は車を持っていたが、ある日彼女は故障した。 彼は自分で修理しようとしましたが、成功しませんでした。 彼はさまざまなメカニズムに目を向けましたが、どれも成功しませんでした。 しかし、かつて、1人の自動車整備士が自動車の修理を志願し、通常よりも10倍多く車を求めました。 男は同意した。 それからメカニックはナットを取り、二度考えずにボンネットの下のどこかに置いた。 車が始動しました。
「1,000ドルかかる」とメカニックは言った。
-冗談ですか？ あなたはわずか3分間働いた！ -男はinした。
自動車整備士の返信先：
-ナットを取り戻しますか？
この話には別のバリエーションがあります：
ある女性は、当時あまり知られていないアーティストだったピカソに、自分の肖像画を描くように頼みました。 マスターは30秒で画像をスケッチしました。 そして言った：
-いつかこの傑作は百万ドルかかる
-傑作？ あなたは書くのにたった30秒しか費やしませんでした-女性は驚きました。
「私の愛する人、30秒で傑作を作成する方法を学ぶのに30年を費やしました」とピカソは答えました。
80時間をダイヤルするには、ほぼ毎日12時間働く必要があります。 週に168時間あります。 これらのうち、睡眠に56時間、仕事に7時間、仕事に80時間、料理と食事に約17時間、家事にさらに7時間を費やしています。 家族とのコミュニケーション、スポーツ、レクリエーション、自己啓発にどれくらいの時間が残っていますか？ 週30分！ 1日5分！
MD.comテクノロジーディレクターのブライアンフォックスは 、彼の苦い経験を語ります。「私は自分の人生を気にしない人々のために働きました。 私が去りたかったとき、彼らは私がこれをしたい理由を理解しませんでした、彼らは私を愛し、報酬を増やし、労働条件を改善することを申し出たと確信しました。
はい。インターネットには、眠れぬ夜の長い絵の具や、飲酒したコーヒー1リットルを描く開発者の話がたくさんあります。 そして、彼らは自分自身に非常に忠実です。 しかし、開発者は一定の範囲を超えて、限られた時間だけ働いていました。
研究では 、短期プロジェクトではリサイクルが正当化されることが示されています。 ただし、数週間の緊急作業の後、従業員の生産性は必然的に低下します。 短期的なプロジェクトはスプリントに匹敵しますが、通常の仕事はマラソンのようなものです。
1日8時間で最大の生産性に達することができますが、「蒸気を使い果たす」時間がないので、週40時間の勤務が標準と見なされます。 最高のパフォーマンスは、就業日の開始から約2時間後に達成されます。これが「加速」の時間です。
営業日の終了の2時間前に、生産性が低下し、気が散り始め、同僚と話し、夕方の計画を立てます。 したがって、私たちは公式の8時間ではなく、1日約4時間働いています。
さらに、労働日が8時間を超えると、労働災害の数が大幅に増加します 。 プログラマーの仕事は危険とは言えませんが、毎週残業をしていると、疲れた従業員は帰宅途中などの不快な状況で事故に遭う可能性があります。
/写真ネイサン CC
プログラミングは創造的であると同時に単調で疲れる仕事であり、休息の欠如は人の創造性を殺します。 疲れた開発者は、関数の名前をより長く覚え始め、ぼんやりした状態になり、技術的な決定を下すのが難しくなります。
これにより、コードに多数のエラーが発生し、プログラムにバグが発生します（開発者は、バグの数は久しぶりに2〜3倍増加すると主張しています）。 残業代の支払いに加えて、デバッグのための時間も支払う必要がある場合、雇用主がこのような状況から恩恵を受けることはまずありません。
では、開発チームの「ハンプに座って」ではなく、プロジェクトをより早く終了するために、どのように生産性を高めることができますか？ 解決策があります-より多くの開発者を雇ってください。 プログラマに週80時間働くようにしたい場合は、週40時間働くチームの数を2倍にします。
初心者と同じ量の作業を短時間で実行できる経験豊富なプログラマーを詳しく調べる価値があります。 IBM OS / 360の開発を説明する「神話上のマンマン」という本は、最も非生産的なショットの10倍の生産性を持つ開発者をどのように選択したかを説明しています。
プログラマを雇うとき、人は自分のスキルを評価できなければならないことに注意してください。スキルは、人の外見や卒業した教育機関の名前などの要因に依存しません。
前者に集中できるように、プログラマーの活動の主要なタスクと副次的なタスクを強調します。 開発チームのマイクロマネジメントを排除し、ビジネスの儀式（会議、会議、レポート）の期間を最小限に抑えます。
逆説があります：開発者が経営陣とコミュニケーションをとる場合-彼は仕事をしない、開発者が会議でズボンを座る場合-彼は仕事をしませんが、同僚とプログラミングの問題について議論する場合-彼は仕事をします。
おわりに
アプリケーション開発者は、特別なアプローチが必要なワーカーのカテゴリであることを覚えておくことが重要です。 常に時間外労働を強制しないでください-これは生産的な活動の幻想を作成するだけです。 しかし、この声明は他の職業に関連して真実です。
管理者は、部下も問題、欲求、家族、友人を持つ人々であることを理解する必要があります。 有能な人員の選択と価値ある目標の存在により、組織内に信頼できる友好的な雰囲気を作り出すことは、労働生産性の問題を含む会社の問題のほとんど（内部環境に依存）を解決します。
PSブログの興味深い資料：