Habréでは、インターネットプロジェクトのマネージャーのかなりの数が、デザイナー、プログラマーなどの開発者と通信しています。 私自身の経験から、他の人によって誤解される瞬間がしばしばあることを知っています。 どういうわけか両方が相互理解を達成するのを助けるために、ロブ・ウォリングによる記事の要約を提供します
お金は強力な動機付けですが、時にはそれは優秀な労働者の闘争における最終的かつ決定的な要因ではありません。
1.成功し始める
これは悲しい真実ですが、多くのソフトウェア開発プロジェクトは失敗します。 各開発者は、ストックストーリーと貧弱なプロジェクト管理の反例を持っています。
現実的な期限はプロジェクトの成功の基盤です。 開発者は、機能するだけでなく、恥ずかしがらず、誇りに思うソフトウェアを作りたいと考えています。 この原則は、多くの場合、管理者が設定した目標とは異なります。
一般に、時間不足で最初に苦しむのは品質と信頼性です。 あなたが開発者にもたらすことができる最も悪は、彼にでたらめをさせることです。 彼らの労働の誇りは後で議論できますか?
作業は迅速に行うだけでなく、効率的に行う必要があります。 私が話をした開発者の一人は、「品質は予算と機能性と同じくらい重要です。」と言いました。
2.素晴らしいリーダーシップ
優れたプロジェクト管理は、プロジェクト自体にとっても、優れた管理によって動機付けられる人々にとっても重要です。 これは、独立した視点に耳を傾け、高品質の製品を開発するのにかかる費用を知り、迅速に意思決定を下し、チーム全体の責任を負うことができることを意味します。
3.新しいことを学ぶ
人間の行動の研究は、新しいことを学ぶと、より快適に感じることを示しています。 コロンビア大学の2人の研究者は、作業がより多様になったり、主題に関するより広範な知識を必要とする場合、労働者は平均20%増加することをいとわないと結論付けました。 実際、私たちは楽しくて面白い仕事に有利になるように低い給料を選択します。これにより、知識を拡大し、深めることもできます。
私が知っているすべての開発者は、新しいテクノロジーで遊ぶのが大好きです。 誰もが新しいことを学ぶ必要性を満たす機会を持つべきです。 従業員に学ばせてください。そうすれば、小さな窓から古い食べ物が出される窓のない地下室でも、仕事で幸せになります。 そして、彼らはプロモーションについて言及しません。
4.創造性と実際の問題の解決
開発者は挑戦されるのが大好きです。 彼らは戦いをせずに退屈しています:彼らはメールをチェックし始め、DiggとSlashdotにアクセスし、ブログを読んで、おじさん、IDisposableインターフェイス、またはセントメアリーのような形のトーストについてチャットするためにオンラインになっている友達を見ます。
夜明け前に技術的な問題を解決する開発者に何回も尋ねられましたが、それについて尋ねられなくても、誰も残業についてst音を立てることはありませんでした。 最高の開発者はただ問題解決を生きています。 これらの人々のほとんどは、問題が解決するまで問題を残しません。さらに、タスクが非標準的なアプローチを必要とするという事実によって彼らはさらに遅れます。
5.議決権
開発者は、壊れたシステムまたはプロセスについて最初に知る人たちです。 私が聞いたとき、「誰かに私の問題に耳を傾け、真剣に受け止めてほしい。 私は、メモリの量、ハードディスクの数、プロセッサのクロック速度が会社の管理にとって単に興味のない場所で働いていました。 十分なディスク容量がないため、一時ファイルを削除する必要がありました。 時代遅れの機器で作業するのは面倒です。」
開発者が言うとき、誰かが彼の話を聞くべきです。 複数の開発者が同じことについて話すとき、誰かがそれらに耳を傾け、迅速に行動する必要があります。
6.ハードワークの表彰
開発者は、自分自身や友人に感銘を与える難しいタスクや仕事が大好きです。
7.重要なものを作成する
私たちはボスニアの医師ではなく、スーダンの食品運搬業者でさえありませんが、それでも多くの人々は、世界に役立つ何か、社会的、技術的な何かを同時にしたいと考えています。 物流システムを作成したシステムエンジニアは、プレスが毎日流通するために機械が移動する経路の走行距離を短縮し、1年に15回強制的に立ち上げられるプログラムを作成したプログラマーよりも大きな喜びを感じます。
ラベルの変更を伴うコードスニペットのコピーと貼り付けは、実際には見かけほど興味深い仕事ではありません。
8.ソフトウェア開発に過度の官僚主義を伴うべきではない
私は2001年から3年間契約に取り組んでいます。 この間、私は大量のWebアプリケーションを作成しました。 何をどのように行うかを正確に知っていれば、簡単にコードを記述できました。 1人の開発者と一緒に、私たちはカップルのために大量のソフトウェアを作成しました。 そして、ここで、私の次の仕事で、ソフトウェア生産は重りをドラッグすることと比較することができました。 新しいページを作成するたびに、変更を承認するために6人が招集されました。 開発は5倍長く続きました。 これはかなり面倒です。 人々の集まりがなくても意思決定ができるため、非常に簡単です。
9.少数の制限
ひどいコード、インターフェースのバグ、および不十分に設計されたデータモデルが好きな人はいません。 制限が多すぎると、クリエイティブな要素が減り、変更に関する決定を下すために会議を集める必要が生じ、一般に、プロジェクトの作業で最高の結果を出したいという欲求がすべて失われます。