金持ちになる幸運な人々を除いて、ほとんどの人は最初のビジネスを始めるときにお金を借ります。 そして、彼らはこの投資が報われることを望んでいます。 これは、借金が良いことの例です。
同じことが技術的負債にも当てはまります。 インターネット上の無数の記事は、それを取り除くか、少なくとも減らす方法を教えています。 これらの記事はすべて、回避する必要があるある種のモンスターによる技術的義務を示しています。 そしてうまくいかなかった場合は、一生懸命に戦います。
私の仕事における技術的義務を歓迎します。 明らかに、一般的なケースでは、誰かに借りがあるとあまり良くありません。 しかし、時には借金は利用可能な最も小さな悪かもしれません。 これが非常に簡単であることを証明するために-技術的な負債がとても恐ろしいなら、大企業は決してそれを持たなかっただろう（翻訳者のメモ：正直に言うとまあまあの議論）。
この投稿では、ビジネスを発展させるために行われる通常のローンのような技術的負債がどれだけあるかを示したいと思います。 そして、そのようなローンを取るかどうかを決定するときに考慮する必要があるもの。
技術的負債とは何ですか？
プログラムを開発するとき、開発の速度と得られるものの品質との間で絶えずバランスを取る必要があります。 リリースを予定通りに行うには、松葉杖とハックを使用して開発の品質を犠牲にしなければならないことがよくあります。 この修正は通常、将来のリリースに移されます。実際には、「技術的負債」と呼ばれます。
技術的な負債は多くの理由で発生します。 開発のお客様は、古い問題の修正やさらなる開発のための強固な基盤の作成よりも、タイミングと機能に重点を置くことができます。 退化したケースでは、顧客は通常これらのことを無視し、チームに「時間通りの機能」のみを要求します。
最終的に、技術的負債は、製品の使用を徐々に停止するユーザーに問題をもたらします。 そして、開発者と管理者の両方による技術的負債を無視することは、その蓄積にのみ貢献します。
技術的負債をいつ借りるか
技術的負債を伴うリリースのタイミングを理解することは、芸術でもあり科学でもあります。
融資を受けるとき、最も重要なことの1つは金利です。 明らかに、高金利のサメの貸し手から融資を受けることは最善のアイデアではありません。
技術的な負債についても同じことが言えます。 下記のルールと常識に基づいて、どのような種類の「割合」で支払うかを理解する必要があります。 ほとんどの場合、毎月支払われる利子が理にかなっていれば、技術的負債は非常に良いことです。
技術的負債の「金利」を計算するために、次の手法を提案します。
- コードは製品のコア機能の一部ですか？ もしそうなら、技術的な負債は非常に高価になる可能性があります。 たとえば、Logz.ioチームは、単一のクライアント用の内部管理コンソールまたは難解な機能を開発する際に、技術的な負債を簡単に負います。 ただし、コア機能であるログ処理と分析に技術的な義務を負わないようにあらゆる努力を払っています。
- 将来の困難は？ 技術的負債は将来の開発にどのように影響しますか？ 関連する機能とタスクにどのような影響がありますか？ 開発した機能が周辺機器であり、今後数か月で積極的に使用する予定がない場合は、技術的な負債が役立ち、開発者がメイン製品で作業する時間を空けることができます。
- 「クランチ」のその後の除去の価格？ 多くの場合、パッチの修正には、バージョン間の複雑なアップグレード、下位互換性の喪失、またはコードリファクタリングへの多大な投資が必要になる場合があります。 これは、そのような場合、「金利」が非常に高くなることを意味します。
- 顧客への影響？ 使用される「クランチ」と「パッチ」は、ユーザーにどのような影響を与えますか？ 月に一度バグの出現につながる場合-それらは不快なバグであり、発生した場合にユーザーは何をしますか？
技術的な負債を恐れないでください
技術的な負債は、私たちが時々対処しなければならないものです。 そして、それはすべて、経済学者が「機会の価格」として定式化するという問題に帰着します。つまり、「X」を作るには、まず「Y」を作らなければなりません。
チームがパッチと松葉杖の修正に1日費やしている場合、この日は新しい機能の開発に費やされません。 同様に、新しい機能に関する1日の作業は、古いバグの修正に費やされません。
会社のリーダーシップのトップから開発状況を見てください。 開発に費やしたすべての費用を、マーケティング、管理費、その他のビジネスニーズに費やすことはできなくなりました。 同じことが逆の方向でも機能します。 決定は優先度に基づいて行われ、ほとんどの場合、技術的負債の優先度は低くなります。
金融の世界からの類推をします。 会社に100万ルーブルの通常の非技術的負債があるとします。 そして、月に150万の収入。 会社はすべての負債をすぐに返済する必要がありますか？ もちろん違います。 結局、残りの50万人は給与、家賃、その他の必要なものを支払うのに十分ではありません。
正しい解決策は、負債の段階的な支払いです。 利益が負債の支払いよりも速く成長する限り、それは悪いことではありません。 彼は投資です。
私たちが企業として成長していることを示しているため、技術的な負債を歓迎します。顧客がログを操作するのに役立つ新機能と製品をリリースします。 開発チームがマイナーな松葉杖の修正にあまりにも多くの時間を費やしている場合、これは利点ではなく停滞のリスクになります。
特にソフトウェア開発では、完璧なものはありません。 開発者は自分の仕事を誇りに思っており、バグのないソフトウェアを見たいと思っていますが、全体像を見て、開発だけでなく会社のニーズも考慮に入れようとしています（翻訳者注：ほとんどの場合、プログラマは家に帰ってビールを飲みたいのですが、シリコン谷は少し間違っています）。
技術的な負債を減らす時が来ました。 しかし、これはほとんどのプログラマーが考えるほど重要ではありません。 将来的には、この議論を続け、技術的負債を減らすための最良の技術について話しますが、必要以上に早くはしません。
翻訳者から：技術的義務に専念している技術伝道者の記事を読むこともお勧めします。 彼はすべてを少し暗いトーンで説明しました、明らかに、その人はスタートアップの幸運ではなかったようです
資金調達。