彼らは2009年にウェビナーについて話し始めました。それ以来、多くの企業が仕事でこの形式を使用しています。 当初、スカイプに代わるものとして登場しました-多数の参加者との企業コミュニケーション-今ではさまざまな方向に拡大しています。 ウェビナーを使用して、インタラクティブな会議や遠隔講座、マーケティング会議、会議を開催します。
しかし、ユーザーのタスクはますます多くなり、新しいニーズが生じました。 改革の時点では、プラットフォームは6年前であり、顧客のすべての問題を解決することはできませんでした。
この間、私たちのアイデア、一般的なビジネス要件、ユーザーフィードバックから生まれた潜在的なタスクを大量に蓄積しました。 ユーザーが目標を達成し、新製品の基盤を作成するのに本当に役立つものを強調する必要がありました。
2014年7月、ゼロから始めることにし、新しいソフトウェアの作成を開始しました。 サービスを徐々に改良することは可能でしたが、多くのアイデアを既存のシステムに技術的に統合することはできませんでした。 新製品の主な要件は6つあります。
新製品の6つの重要な要件
1番 ユーザーの目標に対する最大限のコンプライアンス
このサービスは、企業研修、有料ワークショップ、ビジネス相談など、あらゆる使用目的に価値があるものでなければなりません。 たとえば、マーケティング担当者は、ウェビナーの参加者に関する最も詳細な統計情報を取得したいと考えています;従業員を認定するには、知識をテストおよび評価する能力が必要です。
2番 プラットフォームを初めて知った人
古いバージョンのユーザーが新しいプラットフォームに切り替えることや、経験の浅いユーザーにとっては、サービスの内部設定を管理する方法を理解することは心理的に困難です。 参加者は、ウェビナーのメインシナリオに従って実施される機能を紹介し、技術的な問題がある場合は支援する必要があります。 私たちは「生きた」システムを構築したかったのです。それ自体が指導を必要とし、指示を必要としません。
番号3。 サービスの技術面
将来のフラッシュプレーヤーについては幻想がありません。それを拒否する必要があることは明らかです。 この方向への最初のステップは、HTML5でのシステムインターフェース全体の実装、つまりブラウザーの「ネイティブ」テクノロジーでした。
これにより、ユーザーのコンピューターの負荷が軽減され、サービス内のマイクロインタラクションが改善されます。
番号4。 モバイルアプリ
今日、ほとんどすべての人がポケットにスマートフォンを持っているため、リスナー向けのウェビナーへの参加は、深い技術的知識がなくてもシンプルで快適なものでなければなりません。 古いバージョンを含むすべてのサービスでは、学生は多数のウェビナーを覚えて、アプリケーションに入るときに入力する必要があります。 システムはユーザー名も覚えていません。 この原則を放棄することを固く決意しました。
5番 完全な箱入りソリューション
3台のサーバー、3つのウェビナー開発者、1週間の設定-これは、古い箱入りバージョンのインストール方法です。 全体的な労力を削減し、企業顧客がすべてを自力で行えるようにする必要があることを理解しました。
No. 6。 モダンな外観
インターフェイスには、「これは便利な技術製品です」と表示されます。 したがって、私たちは外観に関する作業を真剣に受け止め、設計事務所のRageに関与しました。
このような大量のタスクを実装するには、開発者には十分なものがありませんでした。 そのため、研究開発部門を拡張することにしました。 この場合、期限を守る必要がありました。 この期間は1年半でした。
チームの募集方法
ジュリア、人事マネージャーウェビナー：
タスクは簡単ではありませんでした-R＆D部門を数回増やすこと。 これらは、プロセスにすばやく参加し、一緒に複雑な技術製品をゼロから作成できる人でなければならないことを理解していました。 経験豊富な技術者と野心的な学生の両方が来ました。 基本的な知識（そして何よりもまず、優れた学術的準備）と、複雑なタスクを目の当たりにした輝きに注目しました。
選択は3つの段階で行われました：予備的なオンラインテスト、チームリーダー（フロントエンド、バックエンド、またはモバイル開発マネージャー）とのインタビュー、および最終段階-テクニカルディレクターとのインタビュー。
テストでは、基本的なプログラミングタスクを提供しましたが、特定の開発言語へのバインドはありませんでした。 この段階で、人々の80％が排除されました。 ティム・リードは、彼の分野の実践について伝えました。 テクニカルディレクターは最終的な評決を出しました。もう1つマイナス70％です。 しかし、彼らが申し出をした場合、誰も拒否しませんでした。
ウラジミール、フロントエンド開発マネージャーのウェビナー：
申請者は、JSとブラウザが全体としてどのように機能するかについて十分に理解している必要があります。 忙しいサービスがあり、クライアントコードには多くの作業があります。 実行中に正確に何が起こるかを理解することが重要です。 これは、個人アカウント、ファイルマネージャー、アドレス帳、およびウェビナールーム自体です：ビデオ会議、プレゼンター、スクリーンショット、チャットなど。
アナトリー、ウェビナーバックエンド開発マネージャー：
インタビューの主な段階は、建築ソリューションの構築でした。 候補者が顧客にシステムを提供する必要がある1時間のタスクを行いました。 彼らは、タスクの設計とスケーリングを理解し、ソリューションを最適化する能力を期待していました。 負荷の高いプロジェクトでの優れたOOP知識と経験があることが重要です。
R＆D部門でのみ1年半で400件のインタビューが行われました。
サービスのベータ版がリリースされた時点での開発部門の構成：
- 5人のバックエンド開発者
- 5人のフロントエンド開発者
- 1人のインターフェースデザイナー
- 1人のAndroid開発者
- 1 iOS開発者
- 2人のVKS開発者
- テスター1人
どうでしたか
R＆D部門は午前10時から11時までに機能するようになりました。 毎日は朝の計画から始まりました。 最初に、タスクを書き留め、各人がタスクリストを閉じている間、全員が座って仕事をします-この間、同僚の何人かはフロントエンド-バックエンドの助けなどを必要とするかもしれません。 。 一日の終わりに、彼らは誰が何をしたかをチェックしました。
アナトリー、ウェビナーバックエンド開発マネージャー：
私のグループの主なタスクは、プロジェクトに吹き込み、システムのコア、つまりインターフェースの背後にあるユーザーから隠されているすべてのものを実装することでした。 入力されたデータの保存、ユーザーからユーザーへのデータの迅速な配信、24x7プラットフォームの中断のない動作の確保、すべてのシステムノード（メディア、フロント、API、ストレージ、タスク設定、プロアクティブな監視システム、プリントサーバー、ビデオサーバー）のリンクに多大な労力がかかりましたキャプチャなど）。
チームでは、主な役割を紹介しました。
- 復習者 。 他の開発者のコードを表示することに従事し、コードを書くための認められた規制や規則を順守します。
- バグ修正 。 すでに記述されているコードのエラーを修正します（ほとんどの場合）。
- 研究者 アーキテクチャ/インフラストラクチャのいくつかの基本的な変更の必要性を調査します。
どんなに一生懸命努力しても、開発の最終段階にはまだ多くの未完のタスクがあります。 最後の2週間は特に困難でした。 しかし、私たちは納期を守り、すべてを高品質で行いたいと考えました。
マイケル、ウェビナーCTO：
私のチームの基本的なルールは、あなたの言葉に答えることです。 開発では、締め切りを破るのが好きで、何年もの間すべてが引きずられます。 間に合うことを理解しました。 他のオプションはありませんでした。 しかし、望ましい結果を達成するためには、多くの時間と労力をかける必要がありました。 そして、私は言った：「皆さん、私たちがこれをするまで、あなたの妻、家族と交渉してください。」 もちろん、彼らには選択肢がありました。 しかし、誰もがそれにサインアップしました。
会社側の緊急期間を少し緩和しようとしました。定期的にオフィスで夕食を注文し、会社のタクシーの代金を支払いました。 レッドブルを購入し、高い結果を得るために調整しました。
Andrey、ウェビナー開発者：
一般的に、雰囲気は涼しかったです。 ビデオコンポーネントを挿入し、それをプラットフォームと同期するという2つの大きなタスクがあったときは困難でした。 しかし、これは気が散る貴重な経験です。
結果
ユーザーのニーズを調査した後、プラットフォームを使用するための各シナリオを作成しました。 トレーニング、マーケティングイベント、会議など、あらゆる目的に機能を追加しました。 参加者と連携するために、タグ付きのアドレス帳を作成し、ファイルマネージャーによるドキュメントのスルー検索を導入し、ソースから訪問者への詳細な統計を作成し、調査とテストの形式を多様化しました。
ウェビナーごとに、ランディングページが自動的に生成されるようになりました。 企業スタイルのパターンでも、ウェビナーの管理者が選択した写真でもかまいません。 HTMLメールテンプレートも非常に柔軟です。
サービス内で、トレーニングWebiBotを作成しました。これは、個人アカウントでのプロンプトと通知のシステムです。 Webbotはプラットフォームを導入し、ブロードキャスト時に問題がある場合に役立ちます（カメラ/マイクからの信号がなく、いくつかのオーディオデバイスが接続されています）。
Webbotを開発して、技術的な問題を指摘し、解決方法を説明し、サービスの新機能について説明する本格的なアシスタントにすることを計画しています。 将来、アプリ内メッセージはユーザーと通信するためのシステムの作成を完了し、各クライアントはユーザーにとって本当に価値のある通知のみを受け取ります。
技術的な部分に関しては、次のステップはフラッシュを完全に拒否することです。フラッシュは今でもオーディオとビデオの送信に使用しています。 2つの潜在的な領域があります。
WebRTC Firefoxブラウザー用にWebRTCを使用してオーディオおよびビデオ伝送を実装することができましたが、残念ながら、このテクノロジーは公式の標準ではないため、完全に使用することはできません。
ブラウザ用のプラグイン 。 ここではすべてがより透明です-管理者権限なしで99％のケースでプラグインをインストールできます。これにより、フラッシュを忘れて高品質のオーディオとビデオを取得でき、デスクトップのデモ用の追加アプリケーションを拒否できます。
モバイルアプリケーションの場合、サービスの各ユーザーは個人のアカウントを持ち、すべての招待状を確認したり、イベントに関する情報を取得したり、イベントに参加したりできます。 ウェビナー中に、参加者はすべてのコンテンツを表示し、チャットに書き込み、質問をすることができ、ブロードキャストの可能性のおかげで、イベントの主催者になることができます。
結論
なぜ製品を更新したのですか？ 新しいプラットフォームのアイデアは、単に注目を集めたいという願望ではありません。 ウェビナーは新しいコミュニケーション標準であることを示したいと思います。 そして、その可能性を最大限に引き出すために、あらゆる使用目的に適した柔軟なプラットフォームが必要です。
この間に理解したこと：
- リスクを負う必要がありますが、それが正当化され、必要なリソースがすべて揃っている場合のみです。 機能を徐々に補完し、新しいチップを順次導入することができます。 しかし、各イノベーションが他の要素に変化をもたらすシステムになると、ゼロから始める方が良いでしょう。 私たちは意図的にこのステップを踏んで、何年も伸びる可能性のあるものを一から作成しました。 原則として、人々は本質的に保守的ですが、グローバルな目標とそれを達成するためのステップを見た場合、これは変化を恐れる理由ではありません。
- 製品の更新は、会社全体の更新です（特に、この製品が唯一の場合）。 新しいプラットフォームでは、ウェビナーの概念を実際に再考しました。 マーケティング戦略からクライアントとの連携まで。 最新のインターフェースの作成から、根本的に新しいコーポレートアイデンティティ、つまり会社とともに発展する生成的アイデンティティまで。
- 新製品のリリースは、最初の段階にすぎません。 最も難しいことは、リリースの後に、言葉の文字通りの比fig的な意味で壊れないことです。 製品をリリースするのはいつも恐ろしいことです。何かを完成させて完成させることができるようです...しかし、これはリリース後、何百ものレビューや提案が来て初めて起こります。 すべてを管理することが重要な場合は、障害に迅速に対応してください。 私たちにとって、この期間は始まっています。 そして、私たちはあなたのコメントを待っています！