マネージャーがプログラミング言語を選択する方法
管理者がプロジェクトに使用するプログラミング言語を課すことができる、そしてしばしば課すことは誰にとっても秘密ではありません。
私自身プログラマーなので、これを理解することはできませんでした。
でも今はそうだと思います。JoelSpolskyがポッドキャストで「世界中のすべての会計士が知っているから」QuickBooksを使うべきだと言ったとき、私はちょうど啓示を受けました。これは、「Javaを選んだので、世界中のすべてのプログラマーが知っているからです」と非常に似ていることに私を驚かせました。
同じ問題を別の観点から見てきたので、会計についてはあまり知りませんが、プログラミングについてはある程度知っています。プロジェクトに適したプログラミング言語を選択するために、プログラマーがどのように役立つか疑問に思っています。 ？
多くのプログラマーが犯す間違いは、技術的なメリットのみに基づいてポイントを論じる（または単に同意する、または同意しない）ことです。経営陣、そしてビジネス全体として、ビジネスケースとビジネスのメリットを最初に議論し、次に技術的メリットを議論する必要があります。
これは、プログラミング言語の選択を超えて、事実上すべての技術的な決定に行き渡ります。
例を挙げましょう：PC。 Joelは、（正しく）開発者の時間は高価であるため、開発者には一流のマシンが必要だと主張しています。これで彼は完全に正しいです。しかし、あなたはこれをどのように主張しますか？シンプル：
例：1日に約20回、コードのビルドを行います。毎回3分かかります。高速のPCがあれば、1.5分でビルドできます。したがって、2年ごとに1,000ドル追加すると、1日30分追加で取得できます。プログラマが10万ドルを稼ぐ場合（少なくとも別の50％のコストがかかります）、これは年間約10,000ドルに相当します。
しかし、反対側で主張しているのは、HRがポリシーとPCに関しては1つのサイズを決定するので、コールセンターの従業員が25,000ドル稼ぎ、プログラマーが4回稼いで、何らかの理由で同じPCを持っているはずです。
テクノロジープラットフォームと言語には、さまざまな決定要因が含まれます。
- 特定のベンダーとの戦略的関係。あなたの会社がマイクロソフトゴールドパートナー（または現在呼ばれているもの）の場合は、JavaまたはPython in;
- PCの費用は予算から発生するため、IT部門は特定の構成について議論します。
- Linuxを実行している人がいないため、全員がWindows 2000を実行する必要があるとITが判断しました。
- 会社がすでに持っている他のシステム（たとえば、他のすべてにJavaを使用する場合、それ自体では最善の選択ではないかもしれませんが、これに使用することは理にかなっています）。
- 単に経験の欠如から、異なるプラットフォームまたは言語への嫌悪を危険にさらす;
- 開発者を幸せにするよりも、上級管理職とリスクを議論することに関心があります。
- 一部のマネージャーは、自分の手が結ばれているという理由だけで決定を下します。
- 予算上の理由がありますが、PVCS、Rationalが製造したものなど、高価なブーストグルを家の外に出しておくので、これもあなたに有利に働く可能性があります。
- オープンソースライセンスに対する法務部門の嫌悪;
- 技術スタッフを計画およびプロジェクト見積もりに関与させない。
- 特定のプラットフォームに関するマネージャー側の知識（技術者もこれを犯していますが、どちらの場合も必ずしも悪いことではありません-知っている悪魔を上手に実行できる多くのツールがあります）。
- 技術スタッフの経験。それらがすべてC＃のバックグラウンドである場合、なぜJava、PythonまたはRubyを使用するのでしょうか？
- 他の多くの理由
どのような場合でも、理由を理解する必要があり（そして、いくつかの理由があることを保証します）、それらの条件でメリットを主張します。何人かのプログラマーはこの部門で非常にナイーブであり、そのような決定はほとんど常に多くの要因が作用しているとき、無知または正当性によってさえ行われると考えているようです。
私の会社での感想：マネージャーがプログラミング言語を選択するとき、彼らは通常非常に保守的に行います-チームで現在利用可能なプログラミングスキルの種類を考慮して（そして追加のスキルを簡単に雇うことが容易であるかどうか） ）、それが十分に確立された言語であるかどうかに関係なく、現在のインフラストラクチャに適合するものを選択しようとし、それを既存のインフラストラクチャに適合させるための大きな努力を引き起こさないようにします。プログラマーがプログラミング言語を選択するとき、物事はしばしば少し異なる傾向があります-彼らはしばしば新しい挑戦をしたいと思い、最新のホットトレンドを手に入れ、彼らが新しいことを学ぶことができるものを選びたいです。
理想的には、マネージャーと開発チームの間で長所と短所を話し合い、問題に最も適したソリューションを見つけることがすべてです。これは通常、多くの話と説得力を必要とします:-)
返答は遅くなりますが、まだ返答がありませんので、試してみます。私はそれを2つの質問として取り上げ、それらに別々に答えようとします：
マネージャーはプログラミング言語をどのように選択しますか？
組織の規模とマネージャーの経験に大きく依存しますが、一般的には、現在の状況と将来のシナリオと要件を評価する必要があります。これは通常 [〜＃〜] pestle [〜＃〜] または同様の分析を通じて行われ、各カテゴリにいくつかのサンプルを提供するだけです。
- 政治
- 「IBMを買収しても誰も解雇されなかった」-安全な選択。
- CEOは、Javaはかっこいい-誇大広告です。
- チーフアーキテクトは.NETが大好きです-ペットプロジェクト。
- 言語は敵対的な競争相手によって制御されています-なぜGoogleはC＃に依存していないのですか？.
- 経済的
- ライセンス費用。
- 開発者トレーニングのコスト。
- コードベースの移行コスト。
- ソーシャル
- チームからの賛同。
- 社内でのスキルの可用性（トレーニングの必要性、継続性）。
- 市場でのスキルの可用性。
- 開発チーム内の現状に対する脅威。
- 十分に大きな実践コミュニティの利用可能性。
- 技術
- 生産性の向上。
- 品質の向上。
- 既存のコードベースと相互運用する機能。
- 標準の順守。
- 成熟。
- 法的
- ライセンス条項。
- 技術管理（誰が技術を所有および管理するか。将来のライセンス戦略はどのようなものになると思われるか？）
- 法規制の遵守。
- 環境
- 会社内の既存のインフラストラクチャ。
- 会社内の既存のスキル。
- 外部パートナーとの統合。
- 幅広い環境による技術サポートのレベル。
次に、基準に一致する一連の言語をさらに評価します [〜＃〜] swot [〜＃〜] 、コスト ベネフィット分析 または同様の方法を使用します。
プロセス全体はかなり複雑になる可能性がありますが、最終的には、ほとんどの企業またはプロジェクトチームは、必要な機能を引き続き提供できる現在の状況を考えると、最も安全なオプションを選択します。多くの場合、それは現在のプラットフォームに長く留まることを意味します。
プログラマがプロジェクトに適切なプログラミング言語が選択されていることを確認するにはどうすればよいですか
うまくいけば、典型的なプログラマーは通常、意思決定プロセスへの全入力の6分の1しか持っていないと実証されました。そして原則として、彼女または彼は主に言語能力だけに興味があります！
ええと、決定に影響を与える最良の方法は、選択プロセスの全体像を持っているようです。チーム内外の同盟関係を築き、事柄の技術的な側面についての良いブリーフを作成し、言語能力だけに集中しないようにしてください。
そしてもちろん、プロジェクトまたは開発マネージャー（または他の担当者）が評価プロセス全体を実行することの利点を確認し、別のプロジェクトに切り替えることのリスクと不確実性を考慮する準備ができている場合、その立場に入る必要がありますそもそも言語。これを実現するには、次のことを実証する必要があります。
- 現在のプラットフォームはもはや適切ではありません。
- 新しいプラットフォームは、面倒をはるかに上回る利点を約束します。
しかし、「私が好きな言語を職場で使用するための最良の方法は何ですか」と尋ねたとしたら、答えはおそらく「すでにその言語を使用している会社に参加するか、自分の会社を始める」でしょう。
マネージャーAは、夏の隠れ家に行き、マネージャーBに会います。
A：では、会社ではどの言語を使用していますか？ B：ああ、私たちはCA Visual Objectsを使用しています。これにより、無人偵察機はCOBOLよりもはるかに生産的になります。
そして、これが決定が下された方法です。実話の終わり。
すべてのプラットフォームには良い面と悪い面があります。 .NETはクールでパワフルですが、Windowsサーバーにほとんどこだわっています。 Rubyはクールですが遅いです。Haskellの開発者を見つけるのは難しいでしょう。
重要なのは、言語はプロジェクトの速度やコードの美しさだけでなく、マネージャーが気にするものにも影響を与えるということです。ですから、彼らに影響を与えたいのであれば、今彼らは彼らの好みを好み、可能な限り多くの良い面を彼らの視点から見つけるべきです。
懸念を分離することによって。ビジネスはビジネスの決定を担当し、テクノロジーは技術の決定を担当する必要があります。私は「受け入れられた責任」という言葉が好きです。責任を負う場合は、問題の領域に関係する選択をするように要求します。ビジネスは私と私の技術部門の同僚にビジネス上の要求を与え、私たちは提供する責任を受け入れる方法の1つまたは2つの選択肢で答えます。 「Python or C＃」で実行する」のようにすることはできません。
「私たちはここで2つの異なる責任を受け入れることができます。この方法を採用すれば、これを迅速に提供でき、これらのビジネス要求を非常によく満たすことができます。これらは少し難しいです。この方法で実行することもでき、これらのビジネス要求に切り札が与えられます。代替案Aはこれらのリソースを必要とし、代替案Bはこれとこれも行う必要があることを意味します...」
次に、ビジネスが選択しますが、ビジネスは技術的なものではなく、ビジネス上の影響に基づいて選択することに注意してください。そして、技術者が技術部の責任を受け入れる準備ができていない代替案の中から選択することはできません。
マネージャーになります。 （ニヤリ）
真剣に、あなたは問題を問題の意思決定者と話し合い、あなたの議論を提起する必要があるだけです。彼らがreallyの間違った決定に固執することを選択した場合、彼らの一般的な能力はおそらくそれほど熱くなく、他に何かすることを探す価値があるかもしれません。
あなたが話していることとJoelが話していたことの違いは、プログラミングはコアコンピテンシーであり、会計はそうではないということです。 Quickbooksを使用するポイントは、おそらく、あなたが会計士であるnotであり、会計士がそれを支援できるためです。ただし、プログラミングがコアコンピテンシーであり、おそらくプログラマである場合は、ゲームのルールが少し異なります。
それはマネージャーの人格に大きく依存します：
流行語に行くものがあります。ちょうど彼らが好きな流行語を見つけて、あなたがあなたが使いたい言語と一緒に彼と話すときにそれを使う。
他の人たちは、自分が知っていることだけを信頼します（たとえば、VB 6.0など）。選択した言語を理解しやすくします（「ご存知のとおり、古き良きVBと同じです」あなたがHaskellについて話しているなら...）
しかし、実際には、ほとんどのマネージャーは私たちがオタクを考えたいほど愚かではありません。ここで重要なのは、彼らの見解を理解することです。彼らは通常、特定の技術的な詳細については気にせず、結果を気にします。ですから、.netまたはJavaまたはDelphiなど、この素晴らしいクールな機能を備えたものは何でもないことを伝えないでください。（ここに言語を入力してください）が良い選択であることを伝えてください。 [〜＃〜] a [〜＃〜]はこのようなプロジェクトの開発時間を短縮するため、またはその機能[〜＃〜] b [〜＃〜]は、バグを減らし、テストに必要な時間を短縮します。ただ、彼の嘘をつかないようにしてください。
言い換えると、彼を賢い存在のように扱います（彼はおそらくそうです）。
非常に一生懸命使用するように求められている言語について考えてください。仕事に適した言語ではないことを確認してから、その仕事に使用する別のより良い言語について提案するかどうかマネージャーに尋ねてください。言語が仕事に適していないことを証明できる情報を提供し、彼の発言を確認してください。傷つけることはできません。 :)
多くの場合、プログラミング言語の選択はビジネス上の決定です。顧客/ユーザーは気にしません。ここに短い引用があります（ http://www.ericsink.com/bos/Geeks_Rule.html から）：
プログラミング言語は主にビジネス上の理由で選択されます。私が使用したい言語には技術的なメリットを上回るビジネス上の不利益があるため、私はほとんどの時間を本当に嫌いな言語の作業に費やしています。それがゲームの性質です。状況（私の選択）を受け入れるか、新しい雇用主を見つけることができます。 JavaまたはPythonまたは使用中の何かはオプションではありません。
まず第一に、プログラミングはもう一つの芸術です。芸術の非常に論理的な形。あなたのマネージャーが彼の並外れたソフトウェアプロジェクトに熱心であるならば、それはある意味で傑作の作品であり、その熱心なマネージャーに以下を尋ねてください：
レンブラントにかかるエネルギーと時間はどれくらいか追加好きなブラシではなく、注意深くペイントしたブラシ400年前、彼の作品が有名になる前に、経営陣の配慮が彼に渡されました。彼の絵はあなたが考える価値があるのでしょうか。
同様に、使用する言語をプログラマに伝える場合は、一貫性を保ち、使用するブラシサイズをペインタにも伝えます。または、毎日、そして（ほとんどの傑作のように）夜それを使用する必要がある人々にこの選択を任せてください！
これらは異なる概念です。
会計するとき、あなたはあなたの結果を共有します：税、法律、投資家などのために。彼らはあなたの労働の結果を見るためのツールを必要とします、そしてこのツールはよく知っている必要があります。
プログラミング時には、Windowsで実行できる.exeファイルを出力する限り、任意のツールを使用します。これは、会計の場合の、Quick Booksで読める文書とまったく同じです。
したがって、トースターを開発する場合は、内部のドキュメントを中国語で自由に保管できますが、英語のマニュアルを用意することをお勧めします。
もう1つあります。会社のルールで、コードの結果が製品自体ではなく、そのソースコードであると想定している場合、確実に彼らは（希望する言語を選択することによって）どのように見えるかを決定できます。
彼らが何を選択するかは、その目標に依存します。簡単に置き換え可能なプログラマーが必要な場合は、Javaを選択します。別の部門に送信する場合は、その部門の要件などになります。
私の経験では、それは常に次の要素に依存しています。
- 言語を使用するためのリソースはありますか？
- 言語を維持するためのリソースはありますか？
- 言語を使用および維持するためのリソースがない場合、それらのリソースを取得することはどのくらい困難/コストがかかりますか？
- 言語の「未来」は何ですか（それは周りにあり、しばらく使用されますか？）
プロジェクトが特定の言語/プラットフォーム/テクノロジー/フレームワークのみが提供するものを必要としない限り、それは私たちがすでに知っていて使用しているものに帰着します。新しい人を雇うことも、既存のプログラマーを訓練することも、ほとんどの企業にとってかなり費用がかかります。採用するときは常に言語を考慮し、候補者がおそらくどの言語を使用するかを確実に把握します。
うまくいけば、あなたはマネージャでもあり、この種の決定においてプログラマを代表できるプログラマがいることでしょう。そうでない場合、それは危険な状況であり、そのような決定が行われていることがわかっている場合は、マネージャーと話し合う必要があります。