3

私が働いているソフトウェア会社では、生産性を向上させるために新しいツールをインストールすることをほとんどの人が恐れています。彼らは私に次のような言い訳をします：

  • 他のものをインストールする必要はありません。
  • 私はこれを自分で行うことができます。
  • など...他の多くの根拠のない議論。

eコマースビジネスでは、エンドユーザーは何もインストールする必要がなく、すべてをWebから管理する必要があり、開発者は生産性とチームワークを向上させるために何かをインストールする必要があります。

  • バージョン管理システム
  • ビルド ツール (ANT、NANT、Maven、継続的インテグレーション、CSS フレームワーク)
  • 統合開発環境
  • フレームワーク (単体テストなど)
  • 等...

他にどのようにすれば、お粗末な音を立てずに自分の主張を伝えることができますか?

4

7 に答える 7

3

あなたの説得のポイントは、会社でのあなたの立場に依存します。プログラミングチームの新しくインストールされたマネージャーである場合は、予算を承認して実装を開始してください。

あなたがチームリーダーである場合は、最も苦痛なものを選び、少なくともあなたのチームのために解決するためのリソースを求めることから始めます。2、3か月後に、上司に具体的な改善を示し、その観点から賛同して他のチームにプッシュダウンさせます。すすぎ、次の痛みのポイントで繰り返します。1年以上かかる場合がありますが、反復型開発の場合と同様に、環境の変更（特に、直接担当していない場合）は反復型である必要があり、説教することを実践するだけで、優れた場合に最も強力な影響力があります。他の人はヒラメをします。

バージョン管理を行っていない場合は、それを最も早く実装することが最も重要です。

私が通常実装する順序は次のとおりです。

  1. バージョン管理（git、subversion）
  2. バグ追跡（trac）
  3. 朝のスクラムミーティング
  4. 新機能の追跡、文書化、および見積もりツール（ピボット追跡、混合）
  5. テストフレームワーク
  6. 継続的なビルド
于 2010-04-21T12:29:51.647 に答える
2

When you're trying to convince management of something, give advantages AND disadvantages. Try to stay objective, and give figures where possible. This will help you convince management (and indeed yourself). It gives management (and your team) confidence if they know you've actually thought something through.

For instance, I worked at a place, and we were looking at improving the speed of the ANT build. It was 8 minutes. I changed it a bit, and it was 3 minutes afterwards. Was it worth it?

We had 8 developers. Lets say they do 3 builds a day.

That is 8 developers * 3 builds per day * 200 days a year = 24000 minutes = about 50 man days.

That is, for a team of 8, if you save them 15 minutes a day, you'll get an extra two man months work from the team each year.

This not only helps you convince people/managers of the worth of what you're doing, but also helps you convince yourself.

P.S. About 6 months previously, we didn't have ANT, and the build was a series of 12 .bat files which had to be run in order. It tooks about 2 hours to correctly build. THAT change was easier to sell to the management.

于 2010-04-21T13:47:38.663 に答える
2

私はすべてのツールを、ツールがどれだけの時間/お金/...を節約できるかという観点から位置づけます。それを使うとはどういう意味で、使わないとはどういう意味ですか。

ツールを使用しない場合の仕事への悪影響を強調します。

于 2010-04-21T12:08:40.950 に答える
0

私は悪魔の擁護者を少しの間演じます、そして時々、最新の最も光沢のあるツールをインストールすることはおそらく最良の解決策ではないと言います。

例えば：

  • 製品をリリースしようとしていて、何かが壊れた場合に構成を修正するために時間を費やす余裕がない場合、または単に以前のように機能させることを学ぶ場合。

  • IDEを本当によく知っている場合は、IDEを完全に構成し、必要なすべてを実行します。（私はここでダイハードviとemacsユーザーを考えています）

  • 同僚がツールの管理/アップグレード/修正に多くの時間を費やし、実際に結果を出しているのを目にしたとき

  • ツールが未成熟/不安定/サポートされていない場合

  • ..。

とはいえ、バージョン管理を使用しない理由はありません。

于 2010-04-21T14:00:11.903 に答える
0

あなたの会社にはモートがたくさんいるように思えます。非常に悲しい状況です。

于 2010-07-09T17:41:14.867 に答える
0

重要なポイントは、誰かの言い訳をどれだけうまく合理化できるかということです。誰かがそれを必要としないと言ったら、それは正しいです。ただし、ツールを使用することで得られるメリットがあるかもしれませんが、ガイダンス、理解、ツールの使用方法を学ぶ苦痛に耐える準備ができている人も必要です。これは、誰かが何か新しいことを試してみたり、それによるメリットが見られなかったりすることを恐れている可能性があることを理解することをお勧めします. 他の誰かが自分の言っていることを動かしている感情を持っているかもしれないと理解するのはとても難しいですか?

議論に根拠がないように見えるかもしれませんが、彼らの視点から物事を見るようにしてください。以前に単体テストを行ったことがない場合、なぜ単体テストが優れているのかをどのように知ることができるでしょうか? 他の人が何年も何年も持っていた場合、他の人が基本的なものと見なす可能性のあるツールやその他の分野の構築にも同じことが当てはまります。

于 2010-04-21T14:08:19.333 に答える
0

私の 2 ペンスのアドバイス - 何か新しいものや異なるものを使用するよう経営者やビジネスの誰かを説得する必要がある場合は、それが収入の増加につながることを伝える必要があります (生産性の向上やビジネスの手作業の時間の節約などの利点による)等）。

しかし、確かに、今日の環境では、組織の労働者や開発者が新しいツールや技術を試したり使用したりすることに熱心ではないことを聞くのは本当に悲しいことです. また、あなたの技術責任者にあなたのケースを提出してみてください。彼らはそれを真剣に受け止めてくれると確信しています。

于 2010-04-21T12:32:57.470 に答える