なぜWebアプリケーションのメンテナンスはもっと重要なものでなければならないのか
公開: 2022-03-10従来のソフトウェア開発者は、私たちから秘密を隠してきました。 それは論争の的となった事実でさえありません。 それは彼らのビジネスモデルの一部です。
私たちが仕事や無料のsyslogマネージャーなどのビジネスで日常的に使用するツールを作成しているハイエンドのエンタープライズソフトウェアベンダーや小規模なソフトウェアハウスについて話しているかどうかは関係ありません。 正面と中央にあります。 彼らが隠さず、私たちが支払うことに慣れてきた追加費用。
それで、この秘密は何ですか？
ええと、多くの伝統的なソフトウェアベンダーは、彼らが書いたソフトウェアを維持することで、最初の販売よりも多くのお金を稼いでいます。
納得できませんか？
「総所有コスト」という用語をすばやく検索すると、Gartner（強調鉱山）のこのような定義がたくさん表示されます。
[TCOは]アプリケーションの実装、運用、サポート、保守、拡張、および廃止にかかるコストです。
さらに、スタンフォード大学によるこの論文は、メンテナンスは通常、ソフトウェア製品のTCOの60％から90％に相当すると主張しています。
それを少しの間沈めることは価値があります。 継続的なサポートおよびメンテナンスプランを販売することで、初期購入価格を大幅に上回ります。
メンテナンスをプッシュしません
私が見ている問題は、Web開発業界では、Webアプリケーションのメンテナンスが私たちが焦点を当てているものではないということです。 毎月のリテーナのアイデアが好きなので、提案に入れるかもしれませんが、単純なハウスキーピングタスクや新機能のリクエストをカバーする可能性があります。
クライアントが私たちが本質的な改善と見なすものにお金を払うことを望んでいると確信していないので、後の反復のために私たちの見積もり内に本質的なアップグレードと最適化を隠すことは前例のないことではありません。 私たちはそれらを裏口から入れようとします。 言い換えれば、従来のソフトウェアと同様に、これらのアプリケーションを維持する必要があるということは、オープンで透過的ではありません。
理由はともかく、将来に向けて問題を積み上げていることが明らかになりつつあります。 私たちが構築しているソフトウェアアプリケーションは、長期にわたってここにあります。 従来のソフトウェアベンダーのように考える必要があります。 当社のソフトウェアは、今後10年または15年間稼働し続けるため、適切に保守する必要があります。
では、どうすればこれを変更できますか？ 業界として、物事が安全で最新の状態に保たれるように、クライアントを保護するにはどうすればよいでしょうか。 同様に、どうすればメンテナンスパイの一部を手に入れることができますか？
メンテナンスとは？
2012年の論文EffectiveApplication Maintenanceで、HeatherSmithとJamesMcKeenは、メンテナンスを次のように定義しています（強調は私のものです）。
アプリケーションを新しいサーバーに移植する、別のオペレーティングシステムとインターフェイスする、新しいリリースにアップグレードする、税率表を変更する、または新しい規制に準拠する（すべてアプリケーションが必要）メンテナンス。 その結果、メンテナンスは、アプリケーションの生産性や費用対効果を維持するためのアップグレードに重点が置かれます。 フォーカスグループが好むアプリケーションメンテナンスの定義は次のとおりです。障害を修正するためのアプリケーションの変更。 パフォーマンスを向上させるため。 または、変更された環境または変更された要件にアプリケーションを適合させるため。 したがって、既存のアプリケーションに新しい機能を追加すること（つまり、拡張機能）は、厳密に言えば、メンテナンスとは見なされません。
つまり、メンテナンスは、ソフトウェアアプリケーションが確実かつ確実に機能し続けるために、ソフトウェアアプリケーションで実行する必要のある重要な作業です。
新しい機能を追加しているわけではありません。 ログファイルをチェックしたり、バックアップが実行されたことを確認したりしていません（これらはハウスキーピングタスクです）。 コードと基盤となるプラットフォームに取り組んでおり、最新の状態であり、ユーザーが期待するとおりに機能し、ライトが点灯したままであることを確認しています。
次にいくつかの例を示します。
テクノロジーとプラットフォームの変更
サードパーティのライブラリを更新する必要があります。 基盤となる言語には更新が必要です。たとえば、PHP5.6からPHP7.1への更新は、最新のオペレーティングシステムが定期的に送信します。 これを維持することはメンテナンスであり、特定のことを行う古い方法が非推奨になるにつれて、コードベースの変更が必要になることもあります。スケーリング
アプリケーションが大きくなるにつれて、リソースの問題が発生します。 1日あたり10,000トランザクションで正常に機能したコード内のルーチンは、1時間あたり10,000で苦労します。 アプリケーションを監視する必要がありますが、アラートがトリガーされたときにアクションを実行する必要もあります。バグ修正
明白ですが、明示する価値があります。 ソフトウェアにはバグがあり、修正する必要があります。 プロジェクトの出荷後に少量の無料のバグ修正を含めたとしても、ある時点でクライアントはこれらの支払いを開始する必要があります。
販売するのは難しいですか？
興味深いことに、私が同僚とこれについて話し合うとき、彼らは彼らがメンテナンスを必要としていることをクライアントに納得させるのは難しいと感じています。 彼らは、クライアントに予算がなく、高すぎるものに出くわしたくないと心配しています。
さて、ここにあります：それは実際にはかなり簡単な販売です。 私たちはビジネスマンと取引をしているので、商業的な観点からメンテナンスについて話し合う必要があります。 ビジネスマンは、資産にはメンテナンスが必要であると理解しています。そうしないと、資産は負債になります。 これは、もう1つの標準的な継続的な毎月のオーバーヘッドです。 ビジネスを行うためのコスト。 これを提案に入れて、フォローアップする必要があります。
非常に効果的な方法は、メンテナンスをコアに組み込んだリテーナを提供するだけでなく、次のようなクライアントのために多くの追加の価値をバンドルすることです。
- 進捗状況とKPI（トラフィック、コンバージョン、検索ボリュームなど）に関するレポート
- サイトへの小さな調整のために毎月限られた「無料」時間
- ダウンタイム、サーバーの更新、または完了した開発作業に関するレポート
- 質問に答えるために電話であなたまたはあなたのチームの特定のメンバーにアクセスする
確かに、あなたは保持者にクライアントのお金を節約させ、それ自体で支払うことができます。 この良い例は、オフライン処理のために毎月簡単なレポートを取得するか、データベースからエクスポートするというクライアントの要件です。
開発日数を見積もって、（おそらく当初の想定よりも複雑な）レポートユーザーインターフェイスを構築するか、代わりにクライアントをリテーナに向けることができます。 開発者が事前設定されたSQLクエリを手動で実行して同じデータを手動で提供するためのタスクを毎月その中に含めます。
あなたやあなたのチームにとっての些細な仕事。 クライアントにとって多くの価値があります。
実用例
もちろん、あなたはあなた自身の提案を書く方法を持っているでしょう、しかしここに例のピッチからのいくつかの抜粋があります。
将来のビジョンを描く可能性のある提案のセクションに、メンテナンスに関する何かを追加できます。 長期的な関係を築くことについての種を植える機会としてこれを使用してください。
あなたは長期的なリスクを最小限に抑えることを目指しています。
アプリケーションのパフォーマンスが高く、安全性が維持され、作業が容易であることを確認する必要があります。
また、あらゆるビジネス資産にとってメンテナンスがいかに重要であるかを理解しています。
後で、成果物のセクションで、スタンドアロンオプションとして、または継続的な保持者にバンドルされて、メンテナンスに関する部分を追加できます。
次の例では、シンプルに保ち、プリペイド開発リテーナにバンドルしています。
すべてのクライアントが、メンテナンスをWebサイトの重要なオーバーヘッドと見なすことを強くお勧めします。 最新のWebアプリケーションは、家や車と同じようにメンテナンスが必要です。 資産を維持して、後で負債になる具体的なリスクを軽減します。
アプリケーションのメンテナンスを常に把握し、新しい機能を追加することに熱心なクライアントとして、一般的なメンテナンスと開発の保持者として、月にN日（開始点として）をお勧めします。
開発者が少なくとも[週/月のある期間]システムで作業するように物事を広げ、[同じ期間]に問題が発生した場合に開発者がより重要なものに切り替えることができるという明確な利点を提供します。 。 優先順位に応じて、すべての時間を新機能の作業に費やしたり、メンテナンスで分割したりすることができます。 通常、新機能と重要なメンテナンスを75％/ 25％分割することをお勧めします。
前述のように、これは、パフォーマンスレポート、バックアップの確認などのハウスキーピングタスクの実行、進捗状況と優先順位について話し合うための毎月の電話など、他の付加価値のある継続的なサービスと一緒にメンテナンスをまとめる絶好の機会でもあります。
おそらくあなたが見つけることは、あなたが作品を着陸させた後、保持者は再び言及されないということです。 プロジェクトの開始時に検討することがたくさんあるので、これは理解できますが、プロジェクトが終了しているので、プロジェクトのオフボーディングプロセスの一部として再導入する絶好の機会です。
これがフェーズ2について話している場合でも、単に最終的な請求書を紹介して引き渡す場合でも、メンテナンスについて思い出させてください。 継続的なトレーニング、報告、およびサポートの利用可能性を彼らに思い出させます。 それらの同じ商業用語で話すことを忘れないで、保持者を推し進めてください：彼らの新しい資産は光沢を維持する必要があります。
メンテナンスが煩わしいことはありますか？
よくある誤解は、メンテナンス保持者が追加の負担になる可能性があるというものです。 懸念されるのは、クライアントが常にあなたに電話をかけ、あなたのリテーナの一部として小さな調整を求めていることです。 これは、小規模なチームや単独のコンサルタントにとって特に懸念事項です。
ただし、通常はそうではありません。 たぶん最初は、クライアントは解決する必要のある障害のリストを持っているでしょうが、これは当然のことです。 あなたが経験を積んでいるなら、あなたはそれを期待しています。 これらは、通信チャネルを改善し（課題追跡システムを使用）、すべての要求をまとめて、つまり1回のヒットで処理することで簡単に管理できます。
アプリケーションが成熟すると、ティックオーバーモードになります。 これは、保持者が両方の当事者にとって特に価値がある場所です。 それは明らかにあなたがリテーナーをどのように構成したかに依存しますが、あなたの観点からは、あなたは毎月あなたがどれほど価値があるかをクライアントに思い出させるよう努めています。 月次レポートを送信し、そのルーチンの速度低下をどのように修正したか、サーバーが今週のグローバルOSエクスプロイト用にパッチを適用されたことを伝えることができます。
もちろん、追加料金がかかる多くの新しい要求された機能に取り組むこともできました。 あなたのクライアントの観点から、彼らはあなたがそこにいるのを見て、彼らは進歩を見て、そして彼らは彼らのリストから「ウェブサイトについての心配」を取り除くようになります。 明らかに、「それらのクライアント」は存在します。したがって、最も重要なことは、保持者の言い回しを正しくし、それに応じて期待を管理することです。
クライアントが月額料金が安いことを期待している場合は、プッシュバックまたは再交渉してください。 月次レポートやその他の補助的なタスクを提供する中で、月に2時間のメンテナンスとハウスキーピングを行うためにあなたにお金を払うことはまさにそれです。 多くのアドホックな変更を行うのは空白のチェックではありません。 含まれているものと含まれていないものを彼らに思い出させてください。
どうすればメンテナンスが簡単になりますか？
最後に、クライアントに最高の価値を保証し、生活を楽にするために、アプリケーションを構築するときにこれらの戦術のいくつかを使用してください。
ロングタームサポート（LTS）
- 十分に文書化されたLTSリリースとアップグレードパスを備えたテクノロジープラットフォームを使用します。
- 進行中のOS、言語、フレームワーク、およびCMSのアップグレードは、すべてのプロジェクトで予想および考慮に入れる必要があるため、LTSバージョンを追跡するのは簡単です。
- すべてがサポートされているバージョンで実行されている必要があります。 そうでない場合は、大きなアラームベルが鳴っているはずです。
良好なプロジェクト衛生
- 機能バックログまたは問題追跡システムでメンテナンスタスクを公開し、クライアントと優先順位について合意します。 メンテナンスタスクを隠さないでください。
- コードレベルと機能テストにより、特に問題のあるコードを監視でき、リファクタリングのためにモジュールを引き出すときに役立ちます。
- アプリケーションを監視し、ボトルネックとエラーがどこにあるかを理解します。 問題は開発バックログに追加され、それに応じて優先順位が付けられます。
- サポートリクエストを監視します。 エンドユーザーは、メンテナンス要件を示す可能性のある有用なフィードバックを提供していますか？
アプリケーションはポータブルである必要があります
- 開発者なら誰でも、あなただけでなく、ローカルで簡単にシステムを起動して実行できるはずです。 仮想サーバーまたはコンテナーを使用して、アプリケーションの開発バージョンが本番バージョンと同一であることを確認します。
- アプリケーションは十分に文書化されている必要があります。 少なくとも、プロビジョニングと展開のワークフロー、およびライブに展開するために必要な特別な呪文を書き留めておく必要があります。
メンテナンスは本物のWin-Winです
メンテナンスは、アプリケーションを安全に静止できるようにするために必要な作業です。 これは標準的なビジネスコストです。 ソフトウェアアプリケーションの存続期間中の総所有コストの平均75％。
専門家として、私たちは最初からメンテナンスについてクライアントを教育することに注意を払う義務があります。 クライアントに具体的な価値を提供しながら、ここで追加収入の大きな機会があります。 あなたは継続的な商取引関係を維持することができ、彼らが新しい要件を持ったときに彼らが最初に頼る人になります。
リテーナを通じて価値を提供し続けることで、クライアントとの信頼を築くことができます。 拡張機能や新機能を提案するためのプラットフォームを入手できます。 勝つ可能性が高い作品。 クライアントは生涯コストを削減し、リスクを軽減し、パフォーマンスやセキュリティについて心配するのをやめます。
あなた自身、あなたのクライアント、そして私たちの業界全体を支持してください：ウェブアプリケーションのメンテナンスをもっと重要なものにするのを手伝ってください。