柔軟性のないプログラマーに対処する


17

長い間プロジェクトに取り組んでいるプログラマーは柔軟性に欠けることがあり、それらを推論することが難しくなります。たとえ彼らを納得させたとしても、彼らは私たちの提案を実行する可能性は低いでしょう。

たとえば、最近、ビルドとリリースのプロセスが複雑すぎて不要な障害物があるプロジェクトに参加しました。

欠陥管理ツールとバージョン管理ツールを統合するだけで、いくつかの開発オーバーヘッド(いくつかのスプレッドシートを埋めるなど)を取り除くことを提案しました(どちらもIBM-Rationalツールであるため、統合は非常に簡単な1回限りの作業です)。また、Maven&Antなどのツールを使用すると(プロジェクトにはJavaといくつかのCOTS製品が含まれます)、ビルドとリリースを簡略化でき、手動のエラーと介入を減らすことができます。

私は何とか他の人を納得させ、概念実証を開発する努力をする準備ができています。しかし、「シニア」開発者は喜んではありません。おそらく、現在のプロセスが彼の価値を高めているからでしょう。

チーム内で摩擦を発生させずにこの状況をどのように処理しますか?


2
いくつかの具体的な例で質問を拡大する必要があると思います。そうでなければ、「スティックで頭を打つ」、「やめる」、「ホワイトペーパー、グラフ、パワーポイントプレゼンテーションを書いてアイデアを伝える」だけが、あなたが期待できる唯一の答えです...
ディーンハーディング

「彼らは船上で提案をすることを
固く

明確化のおかげで、それは質問をはるかに価値があり便利なものにします、IMO。+1!
ディーンハーディング

2
プログラミングを十分に長くすると、最終的には精神病院に配置されると考えていました。
マーシー

5
@ Marci-Iは常に、ソフトウェア開発の分野で人口の一部が精神衛生病院を避けることができると信じてきました。制度化されるべきではないのではなく、一部の開発チーム内に隠れることができます。
ジムラッシュ

回答:


21

あなたは新しいチームメンバーであり、チームの仕組みの基本的な側面を変更したいと考えています。幸運を祈ります。あなたの将来の幸せなチームを感じます。

OK、実用的なアドバイス:

チームに自分自身を証明します。 技術的および信頼性の観点からこれを行う必要があります。人々にあなたをフォローしてもらいたい場合は、そうする理由を与える必要があります。

方法論の歴史を理解する。 なぜ存在するのですか?当時どのような問題を解決していましたか?あなたのソリューションが本当にチームの利益であることを確認してください。あなたの変更はもっと良いかもしれませんが、チームが抱えている問題を実際には解決しないかもしれません。

あなたの障害を知りましょう。 彼らの抵抗の理由を見つけ、それらのアイテムに取り組みます。

変更のエージェントになりたい場合は、変更の成功エージェントになる方法を学びます。ここで入手できるよりもはるかに多くの情報を提供するために利用できる多数の書籍やその他の情報源。

そして、はい、あなたの幸運を祈っています。しかし、あなたの幸福とあなたのチームの幸福のために、それについて賢くしてください。正しい道を作るためにエネルギーを投資せずにプロセスを変更したいというあなたの願望は、善よりもはるかに害を及ぼす可能性があります。


方法論の歴史を理解するために+1。多くの場合、非常に合理的な基礎を持っている不合理に見えるものがあります。多くの場合、問題はプロセスが間違っているということではなく、それとその背後にある理由がひどく説明されているということです。 。
ジョンホプキンス

1
@Jon Hopkins:代わりに、プロセスは間違っていますが、実際の問題に対するひどく考えられた応答で生じました。どちらの場合でも、新人の提案は、実際の問題を理解していないという完全に正当な理由で拒否され、新人の唯一の希望は、現在のプロセスに至った歴史と問題を理解することです。
デビッドソーンリー

@David-それは確かに可能ですが、私たちのポイントは私が思うと同じです-詳細や歴史を想定して試して理解してから電話をかけてください。
ジョンホプキンス

2
技術的な無知以外の理由でチームが「間違っている」ことをまだ見ていません。これは、「新しい男」が他の誰よりもよく知っているが、この「信頼できる」問題のために聞かれない別のケースのようです。
ウェインモリナ

@ウェイン:それが単に技術的な無知であるならば、知識のギャップを単に指摘するだけで十分でしょう。そうではないことを考えると、それは無知以上のものです。多くの人々は、その性質と状況により、変化に抵抗しています。理由については、たくさん。「なぜ人々が変化に抵抗するのか」という単純な検索は、多数の有用な結果をもたらします。
ジムラッシュ

7

私はあなたが言及した立場にいます。私は何年もJava開発者として過ごし、最終的には全員がSmalltalkを使用する仕事に就きました。私の最初の反応は「OMG、彼らはこの時代遅れの技術を使用している」であり、JavaソリューションでSmalltalk固有の問題の解決を試み始めました。他の開発者にとって私が頭痛の種だったに違いないと想像することができ、彼らは情熱を持ってJavaを嫌っていました。

Smalltalk言語のコツをつかみ、好きになることを学び始めたのは、数か月の間に2人の上級開発者から指導を受けながら作業する中規模のプロジェクトが与えられたときでした。その仕事を辞め、Java開発に戻ってから、会社が使用する言語に関係なくプロジェクトを実行して実装できるという点で、はるかに柔軟に感じています。これらの人々に理解してもらうための核となることは、言語は媒体に過ぎないということです。また、私は自分自身にLispとErlangを習得するために時間をかけましたが、それはすべての人でうまくいくとは限りません。

チームビルディング戦略として、苦労している人々に7週間で7つの言語をお勧めします。

また、これらの人々がより柔軟になるためにどれだけの時間を投資することになるかということにもなっていると思います。ほとんどの大学(少なくとも私が見た大学)の問題は、あなたが述べたように特定の言語に偏っており、その学生が「制度化」されることです。あなたの戦略の一部は、チームの柔軟性を養うことだと思います。これは、ドメイン駆動開発で補完できます。

(1)ドメインのモデル化(単純なもの)(2)2つの異なる言語(JavaとLisp)を使用して実装する

繰り返しますが、これは彼らが上記を行う意欲があり、これを達成するために自分の時間を投資する意思があるという仮定の下にあります。

お役に立てれば


1
「この本」の代わりに、リンクで本のタイトルを使用してください。読者がクリックするかどうかを決定するための手順が1つ少なくなります。特に以前にそれを読んだ人。
-Huperniketes

Huperniketesのヘッドのおかげで、これを入力したときはかなり興奮し、入力した内容の健全性チェックに戻りませんでした。
荒涼とした惑星

4

私はここでまったく間違った道を歩んでいるかもしれませんが、同じ問題がより広い規模で一般的であり、人間の保守主義に関連しているように思えます。多くの人が言及できないほどの理由で、よく知られている行動パターンの変更を拒否することがよくあります。

ロシアの開発者であるため(したがって、合理的な西洋のプラグマティズムはあまり見られません)、他の誰かの靴を履こうとするよりもはるかに説得力がないという実用的な理由があります。

つまり、シニアプログラマーは、現在の作業スキームに関連する自分の立場を高く評価しているということです。おそらく、あなたは彼に、物事を行う新しい方法が彼の立場をさらに価値のあるものにするだろうと確信させるべきであり、それをする多くの方法があります。たとえば、あなたに彼にあなたのアイデアを実際に発音させて信用を得ることができます。または、彼が排他的に制御できる特定の場所を見つけることができます。

あなたの考えの明らかな利点の外で柔軟であることは、ここであなたの魔法の呪文かもしれないと信じています。


クレジットが必要な場合はクレジットを与える必要があります。上級者はシステムの実装を引き続き主導することができますが、提案を提供し、実装のほとんどの詳細を作成したものにクレジットを与える必要があります。それは公正です。
Htbaa

それは倫理であり、常に考慮されるべきです。しかし、非常に戦略的なルールのセットであるため、倫理は必ずしもすぐに結果が得られるとは限りません。
エトランジャー

2
@Htbaa-実際に仕事を成し遂げることは、おそらく誰もが正当な信用を得られるようにするためにより重要です。それに直面しましょう:人生は公平ではありません。
スティーブンC

あなたは正しいと思いますスティーブンC
Htbaa

3

私は何とか他の人を納得させ、概念実証を開発する努力をする準備ができています。しかし、「シニア」開発者は喜んではありません。おそらく、現在のプロセスが彼の価値を高めているからでしょう。

シニア開発者の性格に悪い思いを投げかけるのではなく(悪い動き)、おそらく彼が熱狂的でない理由を理解してみるべきです:

  • たぶん、彼はあなたが自分の考えを売り越している人々の一人だと思う。たぶん、彼はあなたがそれらを届けることができると疑っています。

  • たぶん、彼はあなたが問題を誇張していると思う。(彼らはそんなに悪くなることはできません...)

  • たぶん彼は、あなたが技術的リスクを完全に把握していないと考えています。

  • たぶん彼は、今やるべきより重要なことがあると考えています(知っている)。

  • たぶん、あなたは彼を間違った方法でこすりつけるだけかもしれません。

私のアドバイスは、彼に自分自身を証明することです。実際に与えられたプロジェクトを実行することによって。彼があなたの能力と判断をもっと信頼するなら、この問題を再訪してください。

今すぐ「プロセス改善」ラインを追求したい場合、私のアドバイスは小さなステップでゆっくりと行うことです。

提案された変更がグループの生産性、さらには既存のソフトウェアを維持する能力に大きな影響を与えるリスクがあることは間違いありません。その場合、担当者は上級管理職から最も高い評価を受けるでしょう。


2

特に何について制度化されましたか?技術、パターン、実践?

彼らが長い間組織/プロジェクトにいれば、彼らはシニア開発者であり、それらの呼び出しを行う責任/経験を持ち、5猿実験のように条件付けされるだけでなく、プロジェクトで経験を積んだ可能性があります。

彼らを納得させるための解決策は主題が何であるかに依存します。パターン/テクノロジーがすでに選択されている場合、正当な理由があり、仕事を捨てて再確認することを正当化するために変更するより良い理由がなければならないからですもしそうなら、解決策は、建築家/上級開発者が会議を開催して、最良の解決策を民主的に決定することです。


1

チームが本当に不必要な障害物を抱えているなら、彼らはおそらくあなたがそれらを修正するのを手伝ってもらえることを最も喜んでいるでしょう。ただし、彼らがそこにいる理由は非常にあり、長い間みんなに売り過ぎてから「ああ、まあ、私の素晴らしいアイデアはうまくいかない」と言わなければならない場合は愚かに見えるでしょう。

最初に調査してから、先に進みます。また、改善を提案する方法を示すことができることは、手を振るよりもはるかに優れていることに注意してください。


1

私はあなたが「柔軟性に欠けるプログラマ」であると言いたいです。あなたはプロジェクトに慣れていませんが、あなたのアイデアは最高であり、プロジェクトをリードし、より長く、システムの内外を知っている人はロッカーから外れていると主張しています。

私は非常に経験が豊富で、非常に高い評価を受けており、トラチームのメンバーとして苦労しているプロジェクトを修正するために頻繁に割り当てられています。それでも私は、時間、理由、チームのダイナミクス、プロジェクト、およびその実践を学ぶために時間を割いており、乱暴に行ってこれがどのように間違っているかを伝えません。実際、私は彼らがしていることを間違っているとは決して言いません。それは私が望む応答を得られず、通常彼らがしていることは間違っていません。

各プロジェクトは一意です。各チームはユニークです。あなたやあなたの開発者にとってあなたのソリューションは良いかもしれませんが、リード、顧客、ビジネス、プロジェクトにとっては良くないかもしれませんが、あなたはプロジェクトをより良く知る経験がないので、あなたは知りませんその答え。


0

人々にあなたがしたいことをさせる最良の方法は、すべてを彼らの考えだと思わせることです。したがって、直接提案する代わりに、オプションを提示してください。あなたのアイデアが他の選択肢よりも明らかに優れている場合、上級開発者にそれらを選択して自分のものにする機会を与えてください。クレジットを取得することを心配しないでください。重要な人々は何が起こっているかを知るでしょう。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.