クライアントに技術文書と単体テストを提供しないことは理にかなっていますか？

企業向けの製品を作成する契約を結んでいる独立ベンダーとして、設計ドキュメント、アーキテクチャ図、単体テストなどを省いてソースコードとユーザードキュメントのみを出荷するのが妥当です（基本的に、製品を実行するために厳密に必要でないもの、またはそれを拡張する）？

目標は、最終製品をクライアントが拡張できるようにして、無料ではなく、内部で開発を進めることができるようにすることです。彼らは、いくつかの設計上の決定などを理解するためにソースを深く掘り下げる必要があり、導入される回帰を防ぐために独自の包括的なテストを作成する責任があります。

ここでの考え方は、コードをわかりにくくすることではありません。私は、元の作者であったことから得た「内部知識」と専門知識のおかげで、拡張機能の作成を請け負う将来の機会を作りたいと思っています。

これは非倫理的と見なされますか？

編集：契約は現在交渉中であるため、最終的な成果物を構成するものの問題はしっかりと決定されていません。さらに、私は製品の所有権を維持することを述べるべきでした。私はクライアントに使用ライセンスのみを付与します。この詳細は、これが悪い形式と見なされるかどうかに違いをもたらしますか？

契約上、必要なドキュメントの範囲に関する何らかの句を含めるのが賢明です。彼らはあなたにそれらをわかりやすく専門的な形式で提示することであなたに報酬を与えるべきです（ナプキンのスケッチをやり直してください）。

求められ、支払われたことだけを行うことは非倫理的ではありませんが、情報を差し控えるために自分の道を行くのは間違っています。

文書化が不十分で複雑なアプリで私が操作できないと言ったら、私が会社に欠かせないある種の天才よりも、あなたは悪いプログラマーだと思う傾向があります。物事を正しく行うための評判を築きます。

単体テストとドキュメントの開発に料金を請求しましたか？彼らは請求書を支払いましたか？もしそうなら、彼らは彼らがあなたに支払ったものを受け取る権利があります。

それ以外の場合は、来週、p.se.comで「請負業者に、私たちが支払ったすべての技術文書と単体テストを強制するように強制するにはどうすればよいですか？」というタイトルの質問が表示されます。

あなたは自分を傷つけているだけです。彼らの内部スタッフがあなたがやったことを見て、文書の完全な欠如を見つけた場合、彼らはあなたがばかげていると考え、将来あなたを保持する可能性が低くなります。

これらのどれがあなたを説明していると思いますか：

ソフトウェアの設計と作成、ビジネス上の問題の確定、およびプロジェクト全体の管理に関する専門知識に対して報酬が支払われます。あなたは彼らにライセンス料を請求します、彼らはソフトウェアやデザインを所有していません、そして彼らに気分を良くするためだけにソースコードを彼らに渡します-彼らは本当にそれを使用する権利を持っていません。

または

彼らのためにソフトウェアを設計および作成するための時間の対価が支払われています。彼らはビジネスの問題を知っており、プロジェクトを管理しています。彼らは、デザイン、ソフトウェア、ソースコード、および請求対象の時間内に作成するすべての作業成果物を所有しています。彼らは、それらすべてを自由に使用する完全な権利を持っています。

これら2つの設定を混ぜて一致させようとしないでください。最初に追加料金（より多くのスキルを持ち、より多くのリスクを負っているので）またはより少ない料金（最終的に所有量が少なくなるため）または同じ料金（それらのバランスが取れていると思われる場合）です。 1つ目は、情報を保留するのではなく、素晴らしいことで何度も再雇用されます。2番目の方法で生活していて、最初の方法に移行したい場合は、設計ドキュメントを共有しない以外にも多くのことができます。

そうですね、そうです。

ここで答える必要のある質問は本当に2つあります。両方に対処します。

• 私がください持っているクライアントにその文書を提供するために？
• そのドキュメントをクライアントに提供する必要がありますか？

私がください持っているクライアントにその文書を提供するために？

あなたは彼らがあなたがそれらを提供するだろうというあなたの契約が言うものを彼らに提供しなければなりません。私の意見では、これは、ドキュメントも提供せずにソースコードを合理的に維持または変更できない場合は、適切なドキュメントも提供する必要があることを意味します。

1976年の著作権法に基づく米国著作権局の下で作成された作品を見て、ドキュメント、単体テストなどが実際にクライアントによって所有されているかどうかを確認することをお勧めします。もしそうなら、あなたは間違いなくそれらを彼らに提供したいと思います。

そのドキュメントをクライアントに提供する必要がありますか？

あなたが彼らと再びビジネスをしたい場合、または彼らに他の人にあなたを推薦したい場合、あなたは彼らをあなたのビジネスの熱狂的なファンに変えるために必要なあらゆる仕事をする必要があります。

つまり、最高品質のソースコード、適切にコメントされたソースコード、および彼らが興味を持っている他のすべてのものを彼らに引き渡す必要があります。私のアドバイスは、あなたが彼らと会って成果物を渡すとき、それらにユニットテストを与える準備をすることなどです。あなたがすべての大きな重要なことを終えたら、「さて、これらのコンポーネントの単体テストも生成しました。それらも必要ですか？」

あなたの顧客との忠誠心を生み出すために努力し、あなたは将来再び彼らのビジネスを手に入れるでしょう。

この時点で、契約書または書面による合意/文書があり、それらに提出する必要のあるすべての文書がリストされていると思います。

そうでない場合は、製品をカスタマイズするには、ユーザーガイドのカスタマイズを超えて、内部コードの動作に関する追加の知識が必要であることを明確にすることができます。そして、あなたが交渉の立場にあるなら、あなたは彼らに更なる強化のためにあなたに連絡して、それのために支払われるように彼らに頼むことができます。

私が理解していることから、あなたはすでに彼らの製品のコードを書くために報酬を得ています、すなわち彼らはそれを所有しています。したがって、すべてを文書化せずに立ち去ると、彼らはそれを非倫理的だと見なす可能性があります。

高レベルのアーキテクチャと主要な機能拡張を探す場所へのポインタを含むスケルトンアウトラインドキュメントを作成することをお勧めします。重要なファイルなどはどれですか。あなたの仕事が良ければ、彼らはさらなる仕事のためにあなたに戻ってきてくれるでしょう。

私はこの記事が好きです：http : //unixwiz.net/techtips/be-consultant.html

あなたが説明していることは、あなたと二度と仕事をすることについての暖かいファジー感を私に与えません。

あなたは天才かもしれませんが、もしあなたがバスから死んでしまったら、私はあなたから買ったものを維持する必要があります。

あなたが私にその能力を与えないなら、私は二度とあなたを雇うつもりもありませんし、私が扱う何かのためにあなたを雇うことも勧めません。

ここで、同じ製品を他の会社に販売できる「カスタムシュリンクラップ」などのバイナリを販売している場合、製品を販売しているので、「情報が少ない」モデルを使用するほうが合理的です。

違いは、ソースを使用して、ソースコードを変更できる機能を購入することです。ただし、バイナリでは、それを実行する機能を購入するだけです。