web-dev-qa-db-ja.com

ソフトウェアを開発するために会社とどのように交渉しますか?

私はプログラマーです。5万から10万行のコードが予想されるソフトウェアを開発しています。プラグインを作成して、他のソフトウェアとのツールへのインターフェイスを開発する会社を雇いたいと思います。この会社は過去に成功しており、私はそれらを使用することをお勧めしました。

しかし、私はこれまで交渉したことがなく、どのように交渉したのかわかりません。小売業では、一方は弁護士にできるだけ多くのものを入れさせ、もう一方はできるだけ多くのものを取り除くと聞きました。別の業界では、ディストリビューターや出版社がロイヤルティの大部分を約束すると聞きましたが、製品がうまくいったとしても、それらを目にすることは決してありません。

このプラグインの価格設定と場合によってはタイムラインについて、ソフトウェア会社とどのように交渉しますか?彼らは私が何をすると思うのですか?彼らに何を期待すべきですか?

4
user2528

交渉はゲームではありません。

小売業では、一方は弁護士にできるだけ多くのものを入れさせ、もう一方はできるだけ多くのものを取り除くと聞きました。

誤り。

別の業界では、ディストリビューターや出版社がロイヤルティの大部分を約束すると聞きましたが、製品がうまくいったとしても、それらを目にすることは決してありません。

誤り。

これが何が起こるかです。

あなたには要件があります、彼らはそれらの要件を満たすために申し出をします。彼らは必要な時間とお金を指定する必要があります。あなたはそれを受け入れるか、それを拒否することができます。

あなたが受け入れるなら、それは良いことです。あなたは彼らの申し出が好きだった。それはあなたがそれを理解し、彼らが提供する自信があるほど完全でした。

あなたが拒否した場合、あなたは彼らが彼らの申し出で行うことができる改善を提案するのがよいでしょう。あなたの「改善」が不可能であるか、賢明でないか、悪いビジネスである可能性があります。また、「改善」とは、元の要件に対する変更であり、範囲を縮小したり、リスクを軽減したり、何らかの方法で必要なものを構築するのを安価にしたりする場合があります。

それで全部です。政治や労働争議、人々のファンタジービジネス誌の記事で耳にするような「交渉」はありません。

それは単にあなたの要件とその申し出についての会話です。

badポリシーは、提案依頼書1つ、提案1つ、最終承認/拒否パス1つです。これは政府では一般的であり、一部の企業はこのモデルに従おうとしています。それは良い公共政策ですが、悪いビジネスです。それはすべての入札者にとって最も公平で公平です。透明性のある政府運営には不可欠です。品質、サービス、または製品がビジネスに適している場合、企業はこのレベルの透明性を必要としません。

より良いポリシーは、可能な作業範囲について話し合う長引く会話であり、あなたとベンダーの両方が責任を持って行動し、あなたが何を得るかを定義します必要ではなくあなたが望むかもしれないと思ったもの。次に、実際に何に対して責任のある価格とスケジュールを取得できます必要

私は、笑いながら曖昧でありながら完全に「必須」である要件の単一のリストを持っている多くの企業のために多くの提案を書きました。ばかげた音の気まぐれのいくつかを削除することを提案するとき、彼らはこれを私たちの側で「完全な」提案を書くことを望まないものとして扱います。

6
S.Lott

あなたが彼らと交渉するとき、あなたが望むもののために一律の価格を手に入れるようにしてください。私の経験では、企業は必要な作業を過小評価する傾向があり、その作業をどのように行うかを制御することはできません。時々、彼らがそれが簡単だと思うか、あなたが「より小さな」顧客であるならば、彼らはジュニアプログラマーをその仕事に置くか、それを彼らの最優先事項にしないでしょう。彼らが時給を請求する場合、これは多くのお金を費やすことになる可能性があります。

あなたが欲しいものを正確に説明してください。彼らがあなたにタイムラインを与えることを確認し、それが理にかなっていることを確認するためにそれを注意深くチェックしてください。繰り返しになりますが、最終結果の定価を取得してみてください。あなたの期待が何であるかを正確に説明する契約があることを確認してください。良い会社はあなたのビジネスを得るために彼らができるすべてをしようとしているべきです、それであなたがあなたのニーズにしっかりしていることを確認してください。

お役に立てれば!

3
Chad La Guardia

I.ドラフト。まず、あなたが何を望んでいるのかをよく理解してください。将来の機能は不明確かもしれませんが、あなたが今書きたいもののすべての部分について非常に良い考えを持っているはずです。請負業者のマネージャー/デザイナーと話し合います。彼らはしばしばいくつかの非常に良いアイデアと顧客が持っているよりも顧客が望むかもしれないもののより良い手がかりを持っています。もちろん最後の言葉はあなたのものですが、これらの人々はしばしば「何がうまくいくか」「何ができるか」「何が予算をはるかに超えているか」そして「他の人が何を試みたが単にうまくいかなかったか」を知っています。

II。良いスペック。これは成功の80%です。

すべてを自分で設計する必要はありませんが、これらの人々が魔法のようにあなたの頭をのぞき、あなたが何を望んでいるのかを知っていると期待しないでください。彼らは彼らが欠けているものを言うでしょう、そしてあなたは記入するべきです。それがあなたにとって取るに足らないか重要でないように思われるとしても、ただ彼らをユーモアを交えてください。プロジェクトの完全な範囲を取得したら、それを修正したままにしてください。仕様を絶えず変更することほど、生産性を損なうものはほとんどありません。プログラマーはそれに対処できますが、時間がかかり、価格が上がり、最終製品の品質が低下します。ですから、あなたが望むものについて、十分に前もって、完全にそして有能に計画し、後の変更を最小限に抑えるようにしてください。そうすれば、すべてが非常に満足するでしょう。プロジェクトの一部について確信が持てない場合は、モジュール化してください。「これは後で要求する機能です。」、「現在不明/未定義」は完全に問題なく、半分定義されたものよりも優れています。これにより、プログラマーは、書き方が完全にわからないもののコードをいじくり回さずに、拡張機能のフックを残すことができます。 「どうにかして、それがどのように機能するかを見せてください。それが私が望んでいたものであるかどうかを教えます」は、これまでで最悪のアプローチです。

III。締め切り。

妥当な期限を設定し、予約の2倍の時間を確保します。一般的なジョークは、アプリの最初の90%を作成するのに、割り当てられた時間の90%を費やすことです。残りの10%を書くと、2番目にかかります。サポート/デバッグは少なくとも作成と同じくらいのリソースを消費するため、これは真実です。締め切りが遅れることを期待してください。彼らは常に遅れ、慌てず、寛容ですが、ある程度のプレッシャーを保ちます。そして、取引にサポート契約を含めることを忘れないでください。

IV。ライセンス。

ライセンスに注意してください。コードの作業を委託して、コードベース、著作権などすべてを購入できます。これにより、コストは高くなりますが、より良い利益とより低い長期コストが保証されます。または、アプリを注文してライセンスを購入するだけで、ソフトウェア会社が著作権を保持し、アプリを他の人に販売することができます。それでも、契約で更新とサポートを手配します。これは、確立された評判の良いソフトウェアではスキップできます。締め切りの遅れによる無限の価格上昇に同意しないでください。また、締め切りの遅れを厳しく罰しないでください。未完成の製品の展開を強制するよりも、プロジェクトが遅れて終了する方がよいでしょう。

V.監視。

連絡を取り合い、テストバージョンを要求し、進捗状況を最新の状態に保ち、プログラムのテストバージョンを定期的に確認して、作成されているものが目的のものであるかどうかを確認します。完璧なスペックを書ける人はほとんどいません。あなたができることはほとんどありません。プログラマーは仕様に書き込みますが、あなたが書いたものはあなたが望んでいたものではないかもしれないので、彼らが間違った方向に進んでいるなら、早い段階で彼らに知らせたほうがいいです。いくつかのことは、あなたが意図したよりもはるかに簡単に実行できるように見えるかもしれません。それが理にかなっているなら、聞いて、考え直して、受け入れてください。いくつかのことははるかに困難または不可能に見えるかもしれないので、それらを犠牲にするか、将来のバージョンのために延期する準備をしてください。そして、あなたがそれらを望むと思う場所に機能を追加したくなるのと同じくらい、それを次のバージョンに延期してください。バグは冷静に言及されるべきです。それらは発生し、修正する必要がありますが、これは正常です。完成品のスペック違反は積極的に追求していきます。これは起こってはならないことです。 (もちろん、与えられた部分が「まだ実装されていない」または「進行中の作業」でない限り)。

VI。展開。

一晩で100%の生産性が向上するとは思わないでください。システムが初日から動作し始めたら、幸運を感じます。エラーが発生します。それらは修正される予定です。従業員は新しいシステムを理解するのに時間がかかります。約2週間から1か月後、ボトルネックの特定を可能にするのに十分なスキルを持った人々とほぼスムーズに操作できるように、すべてをアイロンがけする必要があります。あなたが発見するすべての(多数の)バグとともに、最初のアップデートでそれらを修正してもらいます。展開から半年以内に、完全に機能し、スムーズに機能するアプリケーションを期待してください。

2
SF.