「カスタムソフトウェア会社」は技術的な負債をどのように処理しますか？

「カスタムソフトウェア会社」とは何ですか？

「カスタムソフトウェア会社」とは、主にカスタムの1回限りのソフトウェアを構築することで収益を得ている会社を意味します。例は、代理店またはミドルウェア企業、またはRedifyのような請負業者/コンサルタントです。

「カスタムソフトウェア会社」の反対は何ですか？

上記のビジネスモデルの反対は、展開可能なデスクトップ/モバイルアプリであろうとSaaSソフトウェアであろうと、長期的な製品に焦点を当てている企業です。

技術的負債を積み上げる確実な方法：

私は、一連のSaaS製品に集中しようとする会社で働いています。ただし、特定の制約のために、特定のクライアントの意志に屈することがあり、そのクライアントにのみ使用できるカスタムソフトウェアのビルドを終了します。

これは技術的な負債を負う確実な方法です。これで、コア製品に何も追加しない、維持するソフトウェアが少しあります。

カスタム作業が技術的な負債を増やす確実な方法である場合、代理店はそれをどのように処理しますか？

それで私は考えました。ビジネスモデルの中心としてコア製品を持っていない企業は、常にカスタムソフトウェア作業を行っています。彼らはどのように技術的負債の概念に対処しますか？どうして彼らを技術的な破産に追い込まないのですか？

ユーザー固有の要件を、誰にとっても役立つものに曲げることができれば、すばらしいことです。クライアントが機能の継続的なサポートコストを支払う意思がある場合も、素晴らしいです。しかし、あなたが小さなチームであり、すべての機能をサポートするのに苦労している場合は、最低限必要な機能についていくつかの難しい決定を下し、コードベースからそれらをルート化するためにいくらかの時間を費やすだけです。

SaaSを使用すると、使用状況の統計を収集できます。誰が何を使用しているかを追跡できるように、まだ持っていない場合は、機能のツールを検討する必要があります。私たちの経験では、最も慣用的な顧客は通常最も機能不全でもあります。MS-Accessへのエクスポートボタンを与えるまで、足を踏みつけて息を止めた男は、おそらく1年以上使用していません。1人の顧客だけがそれらを使用している場合でも、一部の機能は生き続けます。なぜなら、その顧客は大声で、何かが彼の満足のいくものではないたびに他の場所に行くと脅すからです。この機能を廃止すると、今では顧客に費用がかかる可能性がありますが、その機能をサポートするのに費やす時間は、長年にわたって何十人もの顧客に費用がかかる可能性があります。これは、管理チームの品質の尺度であり、

機能を中止する場合は、6か月から3年が妥当である前もって、顧客（または少なくとも影響を受けるユーザー）に事前に決定を発表するようにしてください。実際、ユーザー固有の機能を構築することに同意することに気付いた場合、営業スタッフに最初から有効期限を設定してもらうことができます。それを「サポートライフタイム」と呼び、彼らがそれをより長く望むほど、より多くのお金がかかることを明確にします。エクスポートされたXMLファイルをMS-access形式に変換するスクリプトや、より優れたRDBMSを選択するためのアドバイスなど、機能が使用されたときにクライアントが無駄にならないように、クライアントに回避策を提供してください。

予防策として役立ったのは、営業チームからレポートを毎月開発チームと経営陣に送ることです。このレポートは、クライアントからのフィードバックを網羅しています。どの機能が最も人気があり、どの機能が最も要求されているか、どの機能が最も話題になっていますか。これは、開発者の場合は興味深いですが、本当のメリットはセールスチームにあります。セールスチームは、機能リクエストの無限のストリームを送信して優先順位付けを行うのではなく、全体像のコンテキストで各機能についてもう少し考えていますどのクライアントが最も音量が大きかった。その結果、各機能が製品の全体的な価値提案のどこに当てはまるかをより意識しているため、交渉での新機能のリクエストに関して、営業スタッフをより厳しくすることができました。

多数の自動化されたテストを備えたモジュール式コードを使用すると、製品に機能をハッキングして再びハッキングする際に役立ちますが、最終的にはこれはプログラミングの問題ではなく管理上の問題です。コードを書いて販売するのはばかげている。

カスタム開発リクエストに直面したとき、リクエストを3つの山に分割するクールなフィルターでフィルターします。

1. 誰にとっても便利で、実装が比較的簡単な素晴らしいもの
2. 誰にとっても便利で実装が難しい素晴らしいもの
3. とにかくそれらを本当に必要としないこの1つのクライアントにのみ必要な愚かなもの

• カテゴリ1は、現在の開発サイクルで実装されます。
• カテゴリ2は、次の開発サイクルで実装されます。
• カテゴリ3には、1人月の開発期間の見積もりがあります。ほとんどのクライアントは、その要求に値しないことに気付きます。

正直なところ、これは決して失敗することはなく、カテゴリ3の機能を実装することになったとは思いません。そしてもちろん、顧客は誰も歩きませんでした（そうでなければ、販売は私にこれをやらせさせなかっただろう:)

（この経験はISV企業でのものでした）

特定の制約のために、特定のクライアントの意志を曲げることがあり、そのクライアントでのみ使用できるカスタムソフトウェアの構築を終了します。

問題は、1つのクライアントだけに使用されるコードを作成していることではありません。問題は、1つのクライアントにのみ使用されるコードを、その機能を必要としない他の多くのクライアントに販売する製品に組み込むことです。

ビジネスモデルの中心としてコア製品を持っていない企業は、常にカスタムソフトウェア作業を行っています。彼らはどのように技術的負債の概念に対処しますか？どうして彼らを技術破産に追い込まないのでしょうか？

彼らは製品を届けます。そして、彼らは先に進みます。契約に基づいて製品を開発している場合、そのプロジェクトで行うことはすべてそのクライアントのみです。開発中に発生した可能性のある技術的負債は、契約終了後にクライアントの問題になり、開発者は別のクライアントの別のプロジェクトに移ります。

もちろん、安っぽい仕事をしてもいいという意味ではありません。あなたの一番の目標は、クライアントがあなたと働き続けたいと思うことであり、質の高い仕事をすることがそこに到達する方法です。また、契約開発者にとって技術的な負債が問題にならないということでもありません。一貫してきれいなコードを自分で書いたとしても、ある時点で、すでに借金の山が生じているプロジェクトに取り組むために雇われる可能性があります。それは良いかもしれません（クライアントは混乱をきれいにするためにあなたにお金を払いたいです）またはそうでないかもしれません）。

カスタム作業は技術的負債を生み出すことが保証されているという前提に同意しません。技術的負債を回避することは、特定の種類の機能を回避することを意味するものではありません。不必要な硬直性、依存関係の問題、およびコードベースの変更を困難にする（高価な）ものを回避することを意味します。カスタム機能はこれを意味するものではなく、機能の狭いベースを意味するだけです。したがって、彼らの鍵は、実装から可能な限り多くの一般的で再利用可能なロジックを考慮し、カスタムの一時的なものを、要求する顧客に展開できる独自のスタンドアロンモジュールのままにすることです。

たとえば、顧客がイントラネットにインストールする内部Webアプリケーションである成果物があるとしましょう。ある日、ブラウザインターフェースの代わりに「リッチクライアント」デスクトップアプリケーションを備えたバージョンを作成する場合、顧客が来て、会社にお金でいっぱいのダンプトラックを運転することを提案します。システムが適切に設計され、依存関係が適切に管理されている場合、これはドメイン、データアクセス、およびサービスコンポーネントを再利用して、新しいプレゼンテーションコンポーネントを作成するだけです。1999年に戻りたい顧客が1人だけいて、そのためのデスクトップアプリケーションを持っている場合でも、技術的な負債は考慮されません。

多くのことと同様に、プロジェクトの状況、契約企業の管理レベル、カスタムソフトウェアがライフサイクル全体にわたって契約企業によって管理されているかどうか、量コードベースへのアクセス権を持つ他の人々による「干渉」、関係するすべての人々の態度、プロジェクトの複雑さ、および使用される方法論の...私は本当に続けることができました。

すべてのシステムにはある程度の技術的負債があります。場合によっては、きれいなコードベースを常に維持するために努力している開発者側の熱心な努力により、これは特に目立たないかもしれませんが、システムは完璧ではなく、大規模な再設計により、一見無害でありながら長年の問題が明らかになります。それでは、契約会社はこれをどのように処理しますか？

多くの場合、そうではありません。多くの場合、ソフトウェアはある会社によって作成され、別の会社によって修正されます。また、契約中の各会社が厳しい期限に取り組み、コードをクリーンに保つ時間を正当化しないため、コードベースが本当に台無しになるのは珍しいことではありません（場合によってはほとんどテストされていません）締め切りに間に合わないリスクがある場合

また、契約したプロジェクトを適切に管理するだけでなく、既存のコードベースを見つけたときよりも良い状態に保つための時間を見つける会社もあります。彼らはしばしば慎重な計画でこれを行い、技術的負債の源泉を識別します-通常は新しい仕事に最も影響を与えるものです-そして彼らは技術的負債の管理に貢献するテストケースと修正を提供する戦略を考案し、それらすべてをプロジェクトスケジュールに組み入れます。

カスタムソフトウェアであることは、中心的な製品を書くこととは対照的に、技術的な負債を保証しますか？短い答えはノーですが、積極的に対処しないと技術的な負債が発生する可能性があります。これは、他のソフトウェアプロジェクトと同じです。ライフサイクル全体でプロジェクトを完全に制御する場合、技術的負債に対処するより良い機会があります。そうでない場合は、前の会社が残したコードから生じた技術的負債に対処する必要があります。

一方、あなたの質問があなたのビジネスモデルに関係なくソフトウェアを書くことが技術的負債の保証であるかどうかを尋ねることであったなら。答えは絶対でしょう。本当の問題は、どの企業が技術的負債をどのように処理するかです。スケジュールされた時間に発生して対処するか、できるだけ早く技術的負債を完済するために、継続的な方法でクリーンなコードベースを管理しますか？その答えは、企業の個々の優先事項と、発生した技術的負債が財政的に関連するかどうかにかかっています。

カスタムソフトウェアは技術的な負債を保証するものではありませんが、2つのマスターにサービスを提供することは保証されます。

カスタムソフトウェア会社は、手元のタスクにぴったり合ったソフトウェアを構築し、配信し、必要に応じて保守します。本当にカスタムソフトウェアは、頻繁に追加される新しい機能を必要としません。

この質問で説明されている問題は、製品会社がカスタム機能を他の一般的な製品に組み込むときです。製品が完全にカスタマイズされている場合、ある顧客の要件が変更された場合にのみ製品が移動します。製品が完全に汎用的なものである場合、より魅力的にするために新しい機能が追加されたときにのみ動きます。しかし、他の点では汎用製品にカスタム機能がある場合、異なる速度で移動するコードの2つのチャンクが密接に接触しています。地震を引き起こす構造プレートのように、これらのコードチャンク間のインターフェイスは、問題が発生する「ホットスポット」です。