私たちLaterは、長年にわたって電気通信事業者向けの課金の開発に携わっており、 Planadoの現場従業員を管理するためのサービスを開発しています。
請求は複雑な製品であり、独自の特徴を持つ作業が行われます。 まず、数万および数十万ではなく、数百のインスタンスによって展開される非常に専門的なエンタープライズレベルのツールです。 第二に、システムは24x7x365モードで動作するはずです。 そして最も重要なことは、お金を数えるのは請求であるということです。つまり、それはあらゆる企業のインフラストラクチャの重要な要素です。
以前の記事では、このようなシステムの技術サポートを整理する方法と、その実装を専門家に任せたほうがよい理由について説明しました。 今日は、開発プロセスに適用すべきアプローチに焦点を当てます。
すぐに将来の改善について考えてください
特定の分野の問題を解決するために、ソフトウェアが常に求められます。この場合、これらは請求業務です。 同時に、初期段階で顧客が策定したタスクは不完全な場合が多く、製品の作成と使用のプロセスで発生する可能性のあるすべての問題を考慮していません。 この場合、問題を回避することは困難です。
私たちに近い電気通信業界のイラスト-事業者ごとに異なる課金オプションが必要です。 テレコム業界はさまざまな地域で独自の特性を持つことができます。たとえば、ノリリスクとマガダンでは有線通信チャネルはなく、衛星のみが利用可能です。 したがって、ここでのインターネットアクセスは非常に高価であり、トラフィッククォータ付きの料金はまだ使用されています。 中央アジアの一部の国（アフガニスタンなど）とアフリカ（ナイジェリア）でも同じ状況です。
加入者ベースのサイズも重要な場合があります。小規模な連邦政府のプロバイダーのプロセスは異なって構築されます。
これはすべて、考えられるすべての顧客の要求を満たすシステムを作成することが不可能であることを意味します。 ただし、将来のユーザーが製品を完成させる方向を予測することはできます。
設計段階でこれを行うと、多くの問題を回避できます。 同時に、アーキテクチャに固有のすべての可能性を実現する必要はまったくありません。それらを、ほとんど血を流さずに、「クランチ」なしで実装できることが重要です。
このようなエラーを回避する方法の主な秘密は簡単です。アクションを実行する前にサブジェクト領域を真剣に分析する必要があります。 たとえば、必要に応じて、Laterでは、顧客とのコミュニケーション、顧客のビジネスタスクへの没入、一般に受け入れられているプラクティスの研究、機能要件の開発など、顧客とのコミュニケーションの時間の最大20％を大幅に改善する必要があります。 特定の顧客が必要とするものだけに改訂を制限すると、他の顧客には役に立たなくなります。 シリアルソフトウェア製品の場合、これらは保証された損失です。
広大さを受け入れようとしないでください
将来の製品の改善を予測することは良いことですが、このアプローチには問題があります。 ドメインモデルの不当な拡張は、面倒な技術的ソリューションにつながります。そのため、メンテナンスに費用がかかり、顧客がそれらを使用することは困難になります。
私たちの観察によると、多くのユーザーの希望-非常に人気のあるものでも-実際には、製品が作成されたサブジェクト領域ではなく、以前の経験によって決定される可能性があります。 たとえば、多くの人は最初に自分で請求書を書き込もうとし、次にこのアプローチの悪さを認識して、シリアルソリューションに切り替えたいと考えています。
ここでの問題は、samopisnyシステムでの作業中（通常は数年）に、会社の従業員とそのリーダーが最適でないソリューションに慣れることです。 そして、彼らは新製品に同じ「クランチ」を見たいと思っています。 それらを実装するには、システムアーキテクチャを破壊し、安定性を低下させ、サポートと実装を複雑にします。
たとえば、多くのお客様から、請求時に新しいサブスクライバーを接続するプロセスを自動化するよう求められました。 彼らはそれに慣れて、たくさんのアプリケーションがありました、そして、我々はそれについて行きました。 1年後、私たちは誤解していることに気付きました。機能が制限されすぎており、記述されたコードが請求の問題の解決を複雑にしました。 主題分野を研究した後、私たちは正しい決定に至り、 別の製品でアプリケーションの処理を取り出し、それをオープンソースにしました。
したがって、顧客の声に耳を傾けることは必要かつ重要です。 ただし、禁止リストにいくつかの機能を追加することを恐れずに、彼らのアイデアに批判的である必要があります。 そして、それを実装するように依頼する顧客を拒否します。 常に廃業に陥っている彼らの本当の問題を確認し、同僚の経験を研究し、すぐにすべてを行うことは、はるかに便利です。
コードを何度も書き直す準備をする
高品質のアーキテクチャソリューションは、安定した運用と、製品のサポートと運用のための時間とリソースを節約するという事実に適しています。 ただし、複雑な製品の場合、すぐにすべてを実行することはほとんど不可能です-確かに、システムの一部の要素は最適に動作せず、それについて何かをする必要があります。
改良が必要な場所を理解することは非常に困難です。 このような状況の例として、Hydra課金システムのシステムイベント機能の開発があります。 このようなイベントは、システムからの特定のアクションを必要とする重要なパラメーターの何らかの変更を意味します。たとえば、アカウントの残高がゼロになった場合、サブスクライバーはサービスへのアクセスを無効にする必要があります。 明らかに、この場合のイベントは、サブスクライバーに関する情報（識別子、MACアドレスなど）を伝達する必要があります。 これらはすべて設計段階では正しく論理的であるように見えましたが、問題が始まりました。 たとえば、特定の状況下では、システムはサブジェクトエリアで期待どおりに動作しませんでした。誰かがサービスコードを変更し、アクセス接続コマンドで使用された場合、すべてのサブスクライバーのイベントを再作成する必要がありますか？
イベントの実施に時限爆弾が置かれたことが判明しました。 時間が経つにつれて、このモジュールのコードは非常に複雑になり、アクセス不足の問題が絶えず発生し、それについてすぐにはわかりませんでした-このサブスクライバーで何かが直接発生するまでイベントは再作成されず、これが発生したときにメディアを呼び出す必要がありました理由を特定します。 開発者は、一方を修正しても他方が壊れないように、このコードに触れることを恐れていました。
そのため、最初は良さそうに見えたアイデアには、コンセプトを完全に変更する必要がありました。簡単で楽しいとは言えませんが、選択の余地はありませんでした。 これには常に準備する必要があります。 私たちの経験から、今回の書き直しはすべてを正しく行う機会を与えてくれることが示唆されていますが、そのためには準備作業を行い、以前のアプローチの欠点を深く分析する必要があります。
おわりに
課金を含む複雑なシステムを使用する場合、すべてを一度に正しく行うことは不可能です。 ただし、いくつかの簡単なルールに従うことで、発生する可能性のある問題の数が減り、将来の製品での作業が容易になります。