自分で考えてみましょう:複雑な製品を自分で実装する必要がない理由





私たちLaterは、通信事業者 (有線および無線インターネット、TVおよび電話、トランクおよび衛星プロバイダーのプロバイダー)向けの課金を 8年間開発しており、この間に80以上の実装プロジェクトに参加しました。



以前の資料の1つで、課金のような複雑なシステムを独自に開発する決定が問題につながる理由について説明しました。 問題は、開発者から既製の箱入り製品を購入するだけでは、自分の明るい未来を保証するのに十分ではないということです。 複雑なシステムを採用して実装することはできません。その結果、各プロジェクトは予測不可能な結末を伴う真のクエストに変わります。



問題は何ですか



課金などの高度な製品の実装は、非常に難しいプロセスです。 このシステムは「ボックス化」と呼ばれる場合がありますが、実際には、それを使用するすべての企業は非常に大きく異なります。主に通信事業者について話しています。 これは、起こりうる問題に対する標準的な解決策が存在しないことを意味します。そのたびに、プロセスはまったく新しい独自の方法で進むことができます。



そのため、このようなシステムの独立した実装は、結果として節約したい欲求が追加の費用につながる状況に会社を導くことがほとんど保証されています。



高品質のドキュメントを持っている場合でも、システムの購入者である会社の専門家が分析するのに多くの時間がかかります。 彼らは直接仕事にそれを使うことができました。 つまり、ビジネスはこの段階で損失を被り始めます。



明らかに、専門家が何らかの種類の手術を定期的に行うと、この場合の作業速度が向上します。 このようなシステムは今後数年間選択されるため、課金の導入は通常の運用のカテゴリに分類されません。 これは、購入したソリューションの展開に、この製品の多数の実装を実行した専門家が行った場合よりもはるかに時間がかかることを意味します。 テレコムなどの競争の激しい分野では、遅延はビジネスに深刻な損害を与える可能性があります。競合他社は眠らず、積極的にサービスを開発し、顧客に新しい興味深い条件を提供します。



別の重要なポイント-同じ問題を解決する複雑なシステムのイデオロギーは、実際には非常に大きく異なる場合があります。 結果として、これは移行をさらに複雑にします-古いツールの原則は、多くの場合新しいツールに適用されます。 原則として、これには何も良いことはありません。



請求の分野の例-ある電気通信事業者の1人の物理的な加入者は、たとえば、異なるアパートやサービスについて複数の契約を結んでいる場合があります。 Hydraの請求システムでは、同じIvan Ivanovを扱っていることがわかっている場合、そのデータはすべて1つの顧客エンティティに削減されますが、すべてが間違っているシステムがあります。 私たちの実務では、顧客がそのような製品から切り替えて、そのようなIvan Ivanovから複数の加入者を作成するように依頼される場合があります-各契約またはサービス(インターネット、テレビ、電話など)に1人



これにより、システムのロジック全体が破壊されます。そのような「分岐」または「動揺」したサブスクライバーに関する統計を保持し、レポートを作成することは非常に困難です。 その結果、顧客は、発生した問題を何らかの形で軽減できるシステムの改善を要求しましたが、システムが規定のスキームに従って最初に実装された場合、それらはまったく存在しませんでした。



最後に、誰もエラーの影響を受けません。また、複雑なシステムを実装する場合、エラーを回避することはできません。 そして、これは、多くの時間、神経、エネルギーを費やした後でも、いつでも問題が発生する可能性のある乱気流ゾーンに入るだけであることを意味します。 一部のエラーはすぐには表示されません。 したがって、複雑なシステムを購入し、個別に設定して問題なく戦闘モードで起動すると、状況が発生する可能性があります。 しかし、しばらくすると、突然の大災害が発生します。



同じ請求が重要なビジネスITシステムの1つであるという事実を考慮すると、わずかなミスでも重要な結果につながる可能性があります。



たとえば、ある時点で、特定の数のユーザーへのサービスの提供が、料金プランまたはサブスクリプションの設計の誤りのためにブロックされる場合があります。 ロイヤルティプログラムの場合、数か月でエラーが発生する可能性があります。古いユーザーは、追加サービスの割引やサブスクリプションを誤ってキャンセルしてしまうことはありません。 システム開発者の助けを借りて実装すると、そのような典型的なエラーは発見され、中和されます。



また、原則として、実装のタスクを開発者ではなく外部のアウトソーシングスペシャリストに保存して転送することは、常に可能であるとは限りません。 たとえば、ロシアの請求市場にはそのような独立した専門家がいないだけでなく、すべての請求システム開発者でさえも顧客の展開を支援しているわけではありません。 そのため、さまざまなオプションからシステムを選択する際に、開発者が顧客が作成したシステムの実装を支援するという事実を考慮する必要があります(他に注意する必要があることは、ここで書きました)。



起こりうる問題は明らかであり、やらなければならないことは、すべてがスムーズに進むように開発者を引き付けることだけです。 残念ながら、これでも十分ではありません。



あなたはまだ働かなければなりません



複雑な技術製品を導入する場合の「ここにお金があり、利益を上げる」という方針は、プロジェクトを請負業者に移転することのすべての利点を打ち消すことができます。 実装者は助けが必要です-ビジネスに関連する特定の問題について助言し、仕事に必要なシステムへのアクセスを提供します。 また、ネットワーク機器の再構成や、古い課金ソフトウェアから請負業者へのデータのアップロードなど、一部の作業は、多くの場合(常にではないが)単に不採算です。



これを無視すると、専門家は仕事をすることができなくなります。 さらに、あらゆる種類のしゃっくりが時間の無駄につながり、プロジェクトの納期が近づいているときに近い将来に発生するラッシュは、エラーの数が増加します。



つまり、開発者が作成したソリューションの実装に開発者を引き付けることから得られる多くの利点は、単に無駄になります。 これを回避するには、1人の顧客の努力だけでは不十分であり、開発者自身が実装プロセスを適宜編成する必要があります。



対処方法:プロジェクトアプローチ



私たちが実施した独自のHydra課金システムの100を超える実装の経験により、もう1つの非常に快適な結論を下すことができます。 会社の経営陣が可能な限り建設的に構成され、新しいシステムとその実装に投資する準備ができている場合でも、これは常にこの会社の技術スペシャリストの動機になります。



その結果、ほとんどの顧客は実装プロジェクトを管理できません-開始する前に、請負業者(つまり、私たち)を積極的に監視する必要があるように思われますが、多くの場合、反対に、顧客を制御する必要があります。 これは、顧客が怠けているか悪いからではありませんが、客観的な理由で-通信事業者には「余分な」従業員がいないため、現在のタスクがすべてロードされ、新しい請求の残業の実装に対処する必要があります。



その結果、プロジェクトは必ずしも時間通りに終了しませんでした。 実装契約に署名しただけで、数か月間システムが起動するまで、この方向で作業を延期し、今より関連性の高い何かをする誘惑があります。 これは、たとえば、顧客のエンジニアが請求書を「記入」して設定するためのテストベンチを準備するまで数ヶ月待つことができるという事実に変換されます。 まず、1週間は仮想マシンを提供しませんが、ポートが開いていないため接続できません。システムが再起動し、スタンドへのアクセスが再び失われます。このような「重要な」タスクを解決するには最大1か月かかります。



その結果、締め切りが切れそうになると、原則として、マネージャーは顧客企業の専門家に圧力をかけ始めます。 多くの場合、新しい課金システムへの移行を遅らせることは不可能であるため、過去数週間で数か月を無駄にした後、ギャップ全体に追いつく必要があります。



同様の状況に繰り返し直面したため、課金を導入する作業を再フォーマットする必要が生じました。 現在、このようなプロジェクトの管理について全責任を負っています。このため、会社にはチームワークプロジェクト管理システムのすべての情報を管理する専任の従業員がいます。



プロジェクトに必要なすべての段階、完了しなければならないタスク、およびその後ロック解除される作業領域を明確に示しています。 また、双方の課題を解決する責任者も示されています。







したがって、作業のすべての段階を追跡し、完了した作業を正しく記録し、自分で行う必要があり、顧客の専門家の前に置く必要がある将来のタスクを計画するタスクがあります。



その結果、両側のエンジニアの作業の有効性が大幅に向上します。開発会社の従業員は、プロジェクトを行う必要がある時期と時期をよりよく理解し、クライアントの代表者はプロセス全体がどの段階であるかを理解します。 このようにして、潜在的な問題を深刻な問題に発展する前に特定できます。



その他のITインフラストラクチャ関連の記事:






All Articles