SipuniテレフォニーといくつかのCRMの統合の開発がどのように私たちの研究室になり、私たちが使用する技術だけでなく、社内のプロセスにも影響を与えました。
テレフォニーとCRMの統合が必要な理由
テレフォニーとCRMの統合により、たとえば営業部門の作業が簡素化されます。 着信または発信コールでは、連絡先とトランザクションが自動的に作成されます。 顧客の番号はすぐに連絡先に入力され、目標到達プロセスの最初のステップで新しい取引が表示されます。
自動取引。 店舗名と顧客番号が含まれています。 タグでは、コールトラッキングからの顧客ソース。
マネージャは、誰が発信しているか、CRMの連絡先とトランザクションへの回線とリンクを示す通知を受け取ります。
着信通知
不在着信の場合、そのようなクライアントにコールバックする必要性に関するタスクが自動的に作成されます。
コールトラッキングが接続されると、クライアントが呼び出している広告を確認できます。 また、UTMタグは連絡先フィールドに分類されます。
連絡先が既にCRMに存在する場合、着信コールで、PBXはその連絡先を担当するマネージャにコールを転送します。
多数のCRMの統合開発の難しさ
すでにamoCRMと統合されていました。 しかし、PBXコードと密接に関連していたため、新しい統合を接続するのが困難でした。 そのため、別の統合サービスを作成することにしました。
最初は、いくつかのCRM用のユニバーサルAPIを作成したかったのです。 しかし、私たちはこの考えを放棄しました。 各CRMには独自の概念があり、たとえば、amoCRMには連絡先と取引があるため、RetailCRMにはクライアントがあります。 ユニバーサルAPIを作成すると、さまざまなCRMの概念と機能制限が置き換えられます。
このようなソリューションが見つかりました。各CRMに対して、PBXからイベントを受け取り、ロジックに従ってイベントを処理し、連絡先、リード、または顧客を作成する独自のモジュールです。 これにより、これらのモジュールを均一に使用すると同時に、特定のCRMの機能を損なうことがなくなりました。
設定のユーザーインターフェイスも、CRMごとに個別です。 そのタスクは、設定ツリーを目的のCRMモジュールに転送することです。
多数のCRMの統合を作成する複雑さは、アルゴリズムではなく、プロジェクトの組織にあります。 CRMの数が増えても、CRMを接続する時間が長くならないようにシステムを設計する必要があります。
その結果、新しいCRMを簡単に接続できるフレームワークを開発しました。 これはすぐにはうまくいきませんでした;便利になる前に、フレームワークを3回完全にやり直さなければなりませんでした。
製品の品質に影響を与えた技術
このプロジェクトの前は、継続的な統合手法は使用していませんでした。 この手法では、コードが変更されるたびに、サーバーでテストが自動的に実行され、製品が検証されます。 彼女は製品の品質を大幅に改善しましたが、最初は非常に面白そうでした。
継続的な統合には、Buildkite.comを使用します。 ジェンキンスはマスターしませんでした、誰も彼に慎重に対処する時間を持っていませんでした。 Buildkiteは簡単で、すべてが1日で準備できました。
Buildkite.comインターフェース
継続的な統合により、単体テストに対する態度が変わりました。 彼らは、いくつのエラーが明らかになるかを示しました。 今では、それが慣習的または必要だからではなく、コードが機能しているという自信を与えているからです。
最初の問題とテクニカルサポートと連携する新しいプロセス
顧客が新しい統合の使用を開始すると、最初のエラーが発生しました。 たくさんのコメントと提案がありました。 技術サポートの同僚は、単に顧客のエラーを開発者に伝えました。 プログラマーはログを分析してエラーに対処しただけだったため、開発は停止しました。 多くのエラーは類似していましたが、依然として時間を費やしていました。
テクニカルサポートの同僚と協力する方法を変える必要があることが明らかになりました。
エラーを記録するために、彼らはJiraの代わりにAsanaの使用を開始しました。 技術サポート担当者がタスクをすばやく作成して準備の通知を受け取ることができるシンプルなツールが必要でした。
アーサナのエラーのリストの例
次に、同僚にログへのアクセスを許可しました。 このプロジェクトでは、GrayLogの使用を開始しました。Webインターフェイスにログを表示し、必要なエントリをすばやく見つけます。
ログ内のメッセージはロシア語で作成されました。 私たちは通常それらを英語で書くので、これが価値があるかどうか長い間疑っていました。 ログがより明確で読みやすくなりました。
現在、テクニカルサポートの同僚は、エラーをプログラマに渡す前に、最初にログ自体を確認し、開発者の関与なしにほとんどの問題を解決します。
製品テスト、テクノロジーが再び役立ちます
製品の新しいバージョンをリリースするたびに、すべてのCRMのすべての機能を確認する必要があります。 これを行うには、クリックするもの、呼び出す場所、何をすべきかを示すテストケースを使用します。 新しいCRMが追加されたため、多くのテストケースがあり、それらとの作業を自動化したいという要望がありました。
これがテストケース管理ツールと呼ばれることを学びました。 少数の候補者のうち、彼はtestlodge.comに立ち寄った。 製品の検証は、さまざまなCRMのテストをさまざまな人に割り当てることができたため、より便利で便利になりました。
テストカード、それは何をすべきかと期待される結果を示しています。 下のボタンのいずれかをチェックしてクリックしてください。
テスト実行の概要
プログラミングの負債
どのプロジェクトでもそうですが、時には何かをすばやく行う必要があります。 プロジェクトには、開発者が不満を抱いている場所があります。最適ではないコードや不便なコードです。 これは、プロジェクトのサポートだけでなく、チームのモチベーションにも影響します。
この問題を解決するために、1日から1週間をリファクタリングに充てることができるとディレクターに同意しました。 プログラマーは、請負業者としてではなく、ホストとしてコードを扱い始めました。 何かがうまくいかない場合は、やり直してください。他のタスクがあることを心配しないでください。 この日は順序を復元します。
おわりに
わずか1つのプロジェクトでいくつかの新しいツールを会社に導入し、従業員の作業プロセスを変更しました。 これらの変更のおかげで、製品の開発速度と品質が向上しました。これは、会社自体が少し変わったことを意味します。
大きなプロジェクトは、その結果だけでなく、会社の前向きな変化にとっても価値があることがわかりました。