退屈だと感じられたプロジェクトで開発者を動機付けましたか？

マネージャーとして、私は常に最先端の仕事を生み出せるとは限りません。一部のプロジェクトはメンテナンスモードで実行され、会社の健全なフリーキャッシュフローを生成します。

開発者として、このプロジェクトに取り組むには何が必要ですか？私は作品のブランド変更を考えていましたが、ここで多くの助けを借りてできました。

編集：提案をありがとうございました。ここまでは次のとおりです。

1. 開発者の関心ごとの仕事のローテーション
2. 柔軟な作業環境
3. ペットプロジェクトに取り組む時間を割り当てる
4. 社会と楽しみ
5. プロジェクトのブランディング
6. これを他のプロジェクトの足がかりとして使用してください

保守モードのプロジェクトの場合、次に何が起こるかを考えてください。最終的にそれらはあなたの顧客にとって魅力的ではなくなるでしょうか？陳腐化を避けるために、新しい機能、パフォーマンスの向上、または単純化が必要ですか？やり直す場合、一部のプロジェクトをマージできますか？異なるツール、言語、またはプロセスで構築する必要がありますか？誰も考慮していない改善点や指示はありますか？開発者にこれらの質問のいくつかに答えてもらいます。プロトタイプを構築します。新しい言語またはフレームワークを試してください。プロジェクトに新しいモバイルインターフェイスを提供します。

迫り来る締め切りがない場合、代替案を試すのは簡単です。退屈な時間を使用して、競合他社を打ち負かします。

あなたは彼らに彼らの時間を占める何かを提供する必要があります。メンテナンスモードのプロジェクトでは、多くの場合、各開発者が週に40時間必要としません。もしそうなら、おそらくソフトウェアに何か問題があるかもしれませんが、あなたが質問した方法に基づいて、私はあなたが開発者を占有するアイデアを探していると仮定しています。あなたの財政予算が何なのかわかりませんが、ソフトウェア会議に送るようなインセンティブが役立つと思います。別の提案として、週に15時間程度、自分の興味を探求することを明示的に許可することが含まれます。ソートアルゴリズムやデータベース設計などの調査に興味があるかもしれません。それはあなたのビジネスに直接関係しないかもしれませんが、私はあなたが最終的に彼らの知識の増加から利益を得ないだろうと想像することはできません。ただ何もせずに仕事をさせないでください。仕事があまりない場合は、他の人と時間を割くようにします。ウェブをランダムに閲覧しているだけでなく、少し探検させていることを確認するために、彼らがしていることの要約を求めるのは公平だと思います。

プロジェクトに取り組むことを楽しくします。

実際、興味深いプロジェクトは非常にまれです。また、調査によると、従業員の幸福は社会と楽しみに大きく依存しています。彼らは、なぜ現在の仕事を辞めないのかと尋ねられたとき、同僚に大々的に言及します。

だから、建物で叫ぶのではなく笑うのを聞くとき、あなたはいつも幸せであるべきです。

私にとって、その状況での一番の動機付けは、特に良い仕様の形で、非常に明確な目標です。または、最高というよりも、提供するために残した数少ないものの1つです。そこにある理由は、作品自体が面白くない場合、私がそのつまらないものの束をやり直すことを知ることは、さらに大きな動機付けになるということです。ただし、それはプログラマが仕様の価値を明確に認識していることに依存する場合があります。

もう一つは、つまらないものであっても、収入を生み出すプロジェクトは皆の利益のためであることを明確にすることです-収入も仕事もないなど、仕事をする必要があります。機内で。これを明示的に指摘してください。時には人々は気づかないことがあります。

次に、負荷を分割します。退屈で迷惑な仕事の制限を設定する方法を試してください（仕事の種類に応じて、平日を分割し、タスクを分割するなど）。楽しいこと。

次に、楽しいものでそれを均等にしてみてください。そして、開発者と話をして、彼らは良いアイデアを持っているかもしれません。

「鈍い」プロジェクトの認識を変更する必要があります。健康的な収入を生み出せば、それは非常に難しいことではありません。

多くの場合、これらのプロジェクトは、平凡で平凡であることに満足しているプログラマーに適しています。ご存知のように、プログラミングに情熱を傾けておらず、それを単に支払いの方法と見なしている人々です。さて、理解してください。彼らは弱いプログラマであり、あなたは彼らの人生を惨めにしたいので、私はこれを言っていません。私はこれを言っているのは、これらは通常、自分の仕事が人生の充実の源になるとは思わない種類の人々だからです。それの音によって、これらの音は、圧力の低い、安定した収入の流れのように聞こえます。おそらく、これらの労働者は、簡単で低圧力の仕事を喜んで受けます。

もちろん、それはあなたに彼らに退屈な仕事を与えて、それらを忘れることができるという意味ではありません。「Aプレイヤー」に80％の楽しいタスク/ 20％の退屈なタスク、「Bプレイヤー」を50/50、「Cプレイヤー」を20/80にすることができます。

開発者は、うんざりするような仕事をすることで、自分のペット/オープンソース/興味深いプロジェクトに取り組んで、有給の時間を稼ぐことができます。これらのタイプのプロジェクトで、特に作業が社内のプロジェクトまたはプログラムで行われている場合、サポートを提供します。それはGoogleが使用する戦略だと思う？

退屈で面白くないプロジェクトに携わったことがないことを認めなければならないので、あなたの質問を理解できるかどうかはわかりません。そして、私は生活のためのエンタープライズシステムを開発しています。:)真剣に、実際には、プログラマーは「退屈な」作業に悩まされるのは予想よりはるかに少ないことがわかりました。誰もチェックしていないタイムシートに記入するような無駄な作業は、はるかに大きな問題です。言われていること：

プログラマーの好みを知ってください。GUIが嫌いなプログラマーもいれば、SQLから遠ざかるプログラマーもいます。あるプログラマにとって退屈なタスクは別のプログラマにとって楽しいかもしれないので、その設定を尊重するようにしてください。何らかの理由でこのような方法で作品を分割できない場合は、競争を増やすことで面白くしてください-誰が最初に自分のパートを完成させるか、コードの最も少ない部分のスコアボードを作って競争させてくださいQAのバグ。マイクロソフトは、さまざまなアプローチでプログラマーを競争させ、最終的に最良のアプローチを選択するか、各アプローチの最良の部分を最終製品に組み込む企業文化で知られています。

製品の一部を所有し、それを管理することで、エンゲージメントも大幅に増加します。対照的に、誰かがあなたの作品を管理することほど退屈なものはありません。また、誰もが嫌う繰り返しのタスクがある場合は、全体像を説明します-それはやらなければならないことであり、毎週それを行う人をローテーションすることは通常十分すぎるほどです。

私は、この種のプロジェクトをより興味深いプロジェクトへの道として使用することに成功しました。

新規および中間レベルの開発者がすべて、「ほとんどの場合他のプロジェクトに参加している」上級開発者に質問する「鈍い」プロジェクトで開始し、メンテナンス領域でより良いことをすることを明確にした場合新しい仕事に将来関与する可能性があります。次に、まともなチームがいると仮定し、時々チームの変更を実際にフォローし、新しい仕事で時々メインの開発者を引き込みます。

悪いチームや非常に良いチームがある場合、このアプローチはうまくいかないかもしれません。