Miroのエンジニアリング責任者であるIvanDyomshinが、会社の製品開発、技術変更、プロセスの進化について語っています。

これは、ミロのエンジニアリング責任者であるIvan Dyomshinに、製品開発の構造、前面と背面の技術変更、テストの進化、エンジニアの採用と開発のプロセスについてのインタビューの概要です。







完全な2時間バージョンは、HexletYouTubeチャンネルで表示できます。



目次：



製品と会社の歴史

• RealtimeBoard→ミロ

製品開発の仕組み

• 作業環境
• スタック、モノリス
• リリース

テクノロジーの選択と進化

• フラッシュ→キャンバス
• Angular→React
• サーバーとデータベース
• Java
• 進化のテスト
• 負荷の増加とリファクタリング

開発中のプロセス

• テクニカルソリューションとコードレビュー
• 人事考課
• 採用エンジニアのしくみ
• ジュニアポジション

製品と会社の歴史

Miroは、ビジュアルコラボレーションのためのオンラインコラボレーションホワイトボードプラットフォームです。キーワードはそれぞれコラボレーション、コラボレーションです。効果を測定するための主要な指標は、製品で発生するコラボレーションボードとコラボレーションセッションの数です。



すでに単なる製品を超えているため、私たちは自分たちをプラットフォームと呼んでいます。オープンAPI、マーケットプレイス、開発者のオフィスがあるため、どの企業も製品を自社で拡張できます。



私たちのターゲットオーディエンスは、同じまたは異なるオフィスで運営されている製品チームです。ほとんどの場合、ミロはワークショップ、戦略的セッション、ブレーンストーミング、機敏な実践（計画、回顧）の実施に使用されます。







ミロで開発をリードしています。私はPermで育ち、ここに住み続けています。歴史的に、会社は創業者の出身地であるPermに登場しました。現在、開発部門のほとんどがここにあり、2019年にアムステルダムに2つ目のエンジニアリングオフィスを立ち上げ、積極的に開発しています。



以前は、開発者として分析データウェアハウスを構築し、それらを設計し、大規模なプロジェクトを主導するというカスタム開発に携わっていました。2016年、同社が30人を雇用したときに彼はミロに入社しました。それ以来、私たちは大きく成長しました。現在、5つのオフィス、400人、そのうち140人がエンジニアです。







同社は2011年に設立されました。私たちの最大の機能は、現在も会社の約半分を占める製品開発でした。

名前の変更

2015年にブランド変更を検討しましたが、2018年に変更することになりました。以前の名前であるRealtimeBoardは長く複雑です。それはしばしば間違えられたり、RTBに短縮されたり、最悪の場合、完全に忘れられたりしました。その上、それは感情的ではなく、その背後にある物語はありません。私たちは、新しい名前を短く、容量が大きく、話しやすく、思い出深いものにしたかったのです。



その結果、アーティストのジョアン・ミロの作品に触発され、彼の姓をタイトルに選びました。調査自体と名前の選択には数か月かかり、さらに数か月かけて新しいブランドを立ち上げました。このプロジェクトの足跡をたどって、プロジェクトでの作業がどのように調整されたかについての一連の記事と、許可されたユーザーを古いドメインから新しいドメインにシームレスに移行するための小さいながらも重要な技術的問題についての別の記事があります。





私たちもユーザーもすぐに新しい名前に慣れました。私たちは急速に成長しているため、数百万人の新規ユーザーは、私たちが別の方法で呼ばれたことすら知りません。リブランディングの素敵なボーナスだっ賞我々は欧州の機関と一緒に再ブランディングの一環として開発されたアイデンティティのための欧州デザイン賞から、Vruchtvlees。

ミロでの製品開発の仕組み

170人の製品開発チーム全体がPermとAmsterdamにあり、エンジニア、製品、製品設計者、スクラムマスターです。



以前は、非常に多くの人が1つの製品に取り組むことができるとは想像しがたいものでした。しかし、今日、Uber、Slack、Atlassianには、同じ製品に取り組んでいる何千人ものエンジニアがいることを私は知っています。私たちは成長を続けており、明らかに今は十分ではないことを理解しています。私の頭の中の次の目標は開発中の300人であり、それから私たちはさらに成長し続けます。それはあなたの頭の中の単なる数字ではありません。私たちは戦略的な計画を立てており、2年後、5年後のどこになりたいか、そしてそのために何をする必要があるかを理解しています。



組織構造に関しては、フロントエンド、バックエンド、QAなどのギルドがあります。プロジェクトに取り組むために、それらは機能横断的なチームに結合されます。



チームは主要な領域に分散しています。

• 横型製品は、ステッカー、テキスト、形状、フレームなど、すべてのユーザーに表示される主な製品機能です。
• システムの方向性-コアプラットフォームとインフラストラクチャを担当します。
• 成長-ユーザー数の増加に関するすべて：アクティベーション、エンゲージメント、リターン、収益化。
• Enterprise — , . -, Miro, . -, SaaS-, . , , .
• — 2019 . API, , marketplace, — , , .
• — , . , , , Miro, : Meetings & Workshops, Ideation & Brainstorming, Research & Design, Agile Workflows, Strategy & Planning, Mapping & Diagramming.
  
  
  
  : , , . , . , : - .

エンジニアの主なソフトウェア：IntelliJ Idea、Jira、Slack、Zoom、Miro、Confluence。ほとんどの従業員はMacBookで作業し、ほとんどのエンジニアはMacBook Proで作業し、一部の従業員は必要に応じてより強力なマシンを購入します。



社内ミーティング、ワークショップ、ブレーンストーミングセッション、計画など、独自の製品を毎日使用しています。これにより、製品のすべてのイノベーションをすばやくテストでき、コードだけでなくユーザーとしても製品を最初から使用する新しい開発者の適応を大幅に簡素化できます。これは私たちの文化の重要な部分です-私たちは私たち自身が快適で楽しく使用できる製品を作ります。

スタック、モノリス

フロントはTypescript、React、AngularJSです。バックエンドはJavaです。データベース-クラスター通信用のRedis、Postgres-HazelcastおよびActiveMQ。同じデータセンターのAmazonでホストしています。本番環境には約400台のサーバーがあります。ユーザーボードを処理するアプリケーションサーバーは最大100台まで可能で、すべてが自動的に調整されます。



Atlassianのスタック（Jira、Bitbucket、Bamboo）と、Bambooにボルトで固定され、すべてをサーバーにロールアウトできる独自のスクリプトを使用します。これまでのところ、すべてのリリースは1つの大きなフロントリリースと1つの大きなバックリリースです。現在、これらのリリースをさらに増やす方法を検討しています。



私たちの主なアプリケーションはモジュラーモノリスです。API、ボード、サービス機能を担当するモジュールがあります。モノリスは、モジュールで必要なサーバーに展開されますが、1つの大きな部分ですべてのサーバーに連続して展開されるわけではありません。つまり、さまざまな役割のサーバーもあります。



アプリケーション内には、すぐに個別に実行した多くの統合と追加サービスがあり、チームは他のフロントとバックから個別にリリースします。



小さな会社の場合、サービスのインフラストラクチャを囲うのではなく、モノリスから始める方がはるかに簡単です。しかし今では、1つの一般的なモノリスでは個々の方向（水平製品、プラットフォーム、エンタープライズなど）をスケーリングできないことがわかったため、単一のモノリスを残すアプローチを開発しています。

リリース

アセンブリ自体は、ユニットテストの実行を含めて15〜20分かかります。エンドツーエンドのテストには最大40分かかる場合があります。マスターをリリースするまで、プロセス全体で1時間半から2時間かかります。これは長い間ですが、まだここで取り組むべきことがあります。



5分ごとにリリースするのがおそらく理想的です。しかし、このために、私たちはまだそれほど大きなチームを持っておらず、それほど多くの毎日の聴衆もいません。頻繁なリリースでは、少数のユーザーに変更をロールアウトすることですべてが問題ないことをすばやく確認できるため、大勢のユーザーが重要です。

テクノロジーの選択と進化

テクノロジーの選択は次のように扱われるべきだと私は信じています。何を選択しても、特に会社と製品が成長する場合は、いつかそれを変更する必要があります。したがって、テクノロジーを変更するプロセスは正常です。テクノロジーは重要ですが、企業の発展のさまざまな段階で異なる方法で扱う必要があります。



始めたばかりで製品市場に適合したものを探している中小企業は、迅速に運営され、MVPを迅速に構築し、迅速に廃棄します。複雑な技術的ソリューションを作成するよりも、市場を見つけることが彼らにとってより重要です。しかし、市場が見つかると、成長とセキュリティのための安全マージンを作成できるため、技術的なソリューションが前面に出てきます。



まず、技術を変えて解決したい問題を理解しようとします。次に、多くの調査を行い、代替案を検討し、パフォーマンスをテストします。これは、私たちが実装しようとしている技術的な解決策で行われます。「市場で最初に聞いたものを取り上げるのではなく、問題を解決するのに最も適したものを調査して研究します」。



大規模な製品やチームでは、テクノロジーの変更は重要な戦略的決定です。製品開発の部分的または完全な停止、チームの新しいタスクへの切り替えなどにつながる可能性があります。それは長くて費用がかかりますが、これが時間内に行われない場合、発生した問題ははるかに困難をもたらす可能性があります。



前後にいくつかの大きな技術シフトがありました。下記は用例です。

フラッシュ→キャンバス

2015年まで、フロント全体がFlashを使用していましたが、Flashが停止し始め、HTMLとCanvasに切り替えました。スタックの変更は、製品のパフォーマンスと使いやすさに良い影響を与え、オーディエンスの顕著な増加につながりました。移行には約1年かかり、大規模で複雑なプロジェクトでした。このプロジェクトの詳細に関する記事。



現在、WebGLへの移行を検討していますが、その価値があるという明確な証拠はまだありません。

Angular→React

過去数年間で、AngularJSからReactに徐々に移行してきました。主な理由：

• Reactはより良いタイピングを可能にし、後でそれはコードのより良いリファクタリングを可能にし、何も落ちないことを保証します。
• React . «» , Angular . Angular, React, .
• React , Angular JS .

2015年に、HetznerリースサーバーからAmazonホスティングに切り替えました。 1年以上の間、メインデータベースをRedisからPostgreSQLに移行するプロジェクトがありました。 ：私たちは、この記事持つデータ移行のプロジェクト管理を、フェールオーバークラスタを作成します。







私たちのケースは、ストレージのキー値からSQLデータベースに移動しているという事実によって複雑になっています。多くのリファクタリングがあります。アプリケーションが停止しないように、すべてを行うことが重要です。データベースはアプリケーションの基盤であるため、運転中の車のホイールを変更するようなものです。ボードの内容については、実際にはメンテナンスなしですべてを行いました。はい、移行プロセスは遅れましたが、ユーザーは何も気付かず、製品は機能しました。



製品の安定性が重要な焦点です。ユーザーはMiroに多くのコンテンツを保存します。したがって、ユーザーがセッションまたは会議をスケジュールし、そのためのコンテンツボードを準備し、その時点で製品が利用できない場合、これは失敗であり、コンテンツを使用できません。条件付きズームはすぐにハングアウトに置き換えることができますが、コンテンツをすばやく置き換えることはできません。したがって、私たちの重要なタスクの1つは、ユーザー向けのコンテンツを常に利用できるようにすることです。

Java

Javaは、私たちが見つけることができる生産性と開発者リソースの点で私たちを大いに助けてくれます。エンジニアの再トレーニングにうんざりしているため、BookingがPearlからJavaに切り替わっていることを知っています。



C ++および.Netのエンジニアが来て、正常に適応します。経験豊富な開発者で、さまざまなテクノロジーを試し、システムの構築方法を知っている場合は、新しい言語に飛び込むのはそれほど難しくありません。重要なことは、エンジニアが適切な解決策を考え出すことであり、彼は間違いなくその言語に身を置くことができるでしょう、私はこれを信じています。

進化のテスト

当初は手動テストしかありませんでした。リリースは2〜3週間ごとに展開され、リリースの準備には1週間かかりました。数日で回帰テストを実行→重大なバグを見つける→正しい→手動テストを再度実行します。複数のチームがあった場合は機能しましたが、20のチームがある場合、すべてを手動でテストすることは不可能です。



そこで、自動化について考え始めました。まず、回帰テストを完全に取り除くために自動テストを作成しました。現在、開発サイクル全体を通じて適切な品質管理プロセスの設定に取り組んでいます。品質について考えるのが早ければ早いほど、エッジケースを見つけ、それらをテストする方法を理解します。これにより、最終的にコストが削減され、開発プロセスがスピードアップします。セールで見つけたバグは、リリースをロールバックして修正するための時間とリソースの価値があるだけではありません。このバグは製品の全体的なユーザーエクスペリエンスに影響を及ぼし、そのエクスペリエンスを修正するには非常に費用がかかります。



QAギルドがあり、エンジニアは現在実装する必要のあるプロセスを決定し、品質戦略を策定します。その後、各QAエンジニアは、チームが自国でこれらのプロセスを実装するのを支援します。

• QA- -, . QA , . .
• QA , .
• QA , , .

カナリアリリースは、少数のオーディエンスに機能を展開し、何かを見逃していないかどうかを確認するときにテストする方法でもあります。チェックボックスを使用して大規模な新機能をリリースし、ベータテストへの参加を希望するベータユーザーに展開します（製品マネージャーは調査インタビューでこれについて学習します）。ベータ版とアルファ版のユーザーの数には必然的に私たちのチームが含まれます。そもそも私たちはすべての新機能を自分たちで展開します。







QAプロセスのすべての段階の詳細な説明。

負荷の増加とリファクタリング

2020年のテレワークへの大規模な移行により、ユーザーベースは急増し、年間のインフラストラクチャとアプリケーションの復元力は数週間でなくなりました。負荷が急激に増加した最初の週に、すべての製品開発を停止し、チームの方向を変えて、障害耐性とパフォーマンスに取り組みました。



製品内の同期ジョブの数が増えるにつれて、バックエンドだけでなく、フロントエンドとクライアントにも安全マージンが必要になりました。以前の20人が同時に1つのボードで作業できたとすると、現在は300人になります。当社のフロントエンドエンジニアは多くのことを行い、負荷パフォーマンスに取り組み続けています。たとえば、ボードのリストを含むダッシュボードを他のすべてとは別にロードし、以前よりも高速に実行します。また、ユーザーがダッシュボードからではなくボードに直接アクセスする場合は、ボードのコードとコンテンツを他に何もせずにロードする必要があります。



ユーザーがボードからフィードバックとコンテンツをより速く取得できるように、多くのリファクタリングを行います。その後、すべての主要機能（スクリプト、インターフェイス）がゆっくりと起動します。これを行うために、コードを「レイジー」モジュールに分割することに切り替えました。これにより、約3分の1加速し、来月にはさらに2倍の積載を予定しています。



ボード上のパフォーマンスに関しても同じです。ユーザーが実行しているコンピューターの速度とリソースをめぐって争いがあります。誰もが優れたマシンでオンラインになったわけではありません。誰かが古い、パフォーマンスの低い家庭用ラップトップを棚から引き出しました。しかし、私たちの製品はどのラップトップでもうまく機能するはずです。これは、私たちが現在多く取り組んでいるもう1つの大きなトリックです。

開発中のプロセス

テクニカルソリューションとコードレビュー

すべてのタスクは、製品ソリューションの準備から始まります。製品ソリューションは、「私たちは何をするつもりですか？」という質問に対する答えです。製品戦略とOKRに基づく製品マネージャーは、現在製品に欠けているユーザーを見つけるために多くの調査を行っています。調査に基づいて、製品はソリューションを説明します。フードギルドは解決策について話し合い、必要に応じて修正します。



製品ソリューションに基づいて、「これをどのように行うのか」という質問に答える技術ソリューションが形成されます。これは、機能を実装するチームのエンジニアによって開発されます。技術ソリューションは、いくつかのレビュープロセスを経ます。

• 機能に交差点があるチームと。
• アーキテクチャで触れるコンポーネントのセキュリティレビュー。
• 結果をどのように展開するか。

その後、開発自体が始まります。コードレビューによって開発が遅くならないことが重要であるため、最近、2つのコードレビューを義務的に受け取る代わりに、コンポーネントレベルで個人的な責任を導入しました。現在、コードレベルでは、この部分の責任者が常にわかっているため、開発中のコミュニケーションが大幅に容易になります。したがって、コードに変更を加えるとすぐに、このコードの所有者であるレビュー担当者が自動的に割り当てられます。コードがあなたのものである場合、レビューはあなたのチームのメンバーによって行われます。



なぜ私たちは個人的な責任を導入したのですか？以前は、製品全体がどのように機能するかを知っていて、コードのどの部分でもチェックできる「オールディーズ」という人が何人かいました。しかし、製品が成長するにつれて、これらの人々の能力が不足し始め、開発で起こっていることすべてについて知ることができなくなりました。コードレビュープロセスは残りのプロセスを遅くし始めました、コードレビューのために誰に行くべきかは明確ではありませんでした。次に、特定の製品ブロックに必要なすべての能力を、それらに取り組むチームにもたらし始めました。そのため、チームは独自にコードレビューを実施することができました。かつて、これは私たちが大幅にスピードアップするのに役立ちました。

人事考課

会社には等級があり、そのおかげで、誰がどの能力を持っているか、どの等級に対応しているか、そして最も重要なことに、誰もが先に進むために何をする必要があるかを理解しています。パフォーマンスレビューは年に2回行われ、各人の現在の状況を把握し、パーソナライズされたフィードバックを得るのに役立ちます。



この写真に基づいて、チームリーダーは各チームメンバーと個人的な開発計画を作成します。従業員自身がどこで開発したいかを述べ、パフォーマンスレビューは彼の長所とギャップを強調します。



その後、定期的に1〜2週間に1回、チームリーダーと従業員が1対1の会議を開き、計画された方向への動きについて話し合い、追跡します。この運動の結果に基づいて、1年半で学年と給与が増加します。







すべてがチームリーダーとまったく同じです。さらに、外部トレーニングと外部メンタリングがあります。



残念ながら、人々は会社ほど速く成長しないことがよくあります-それは大丈夫です。会社の成長は従業員の成長に直接依存するため、私たちはトレーニングに多くの投資をする準備ができています。外部コースの補償があり、推奨コースとメンターがあります。強制トレーニング（英語など）を100％補償し、残りの50〜50を補償するように努めているため、結果には相互の責任があります。



私たちはめったに会議に行きません。私たちは、現時点で私たちに関連があり、十分な知識がない技術や事例について話しているものを選択しようとしています。

採用エンジニアのしくみ

私たちの採用チェーンは、ロシアとヨーロッパの標準です。ロシアでは、採用の目標到達プロセスがすでに狭いため、最初の面接は採用担当者ではなく、採用担当者が履歴書を処理して要件に適さない欠員を取り除いた後、すぐに採用マネージャー（通常は人を採用するチームのチームリーダー）が実施できます。



ロシアでは、リスクを冒したくないという理由で、ヨーロッパに比べて積極的に仕事を探しているエンジニアははるかに少ないと感じています。そして、孤立のために多くの企業がリスクゾーンに入ると、人々はリスクを冒して転職する傾向がさらに弱まりました。



いずれにせよ、採用チェーンは、採用担当者または採用マネージャーが実施する候補者との電話インタビューのスクリーニングから始まります。スクリーニングの目的は、候補者が欠員の主要な要件にどのように適合するかをすばやく理解することです。



スクリーニング後、テストタスク、そして技術面接。これには、とりわけ、テストタスクの議論が含まれます。次に、候補者が勤務するチームとのミーティング。私たちにとって、これは必須のステップです。これは、まず候補者の技術的スキルではなく、候補者の文化的適合性を理解するのに役立つためです。



すべてのインタビューの後、参加者からフィードバックを収集し、オファーを出します。



テストタスクを評価するには、ポイントシステムを使用し、結果をランク付けして、最良の結果を確認します。上級職では、候補者が優れた公開リポジトリを持っている場合、テストタスクをキャンセルすることがあります。

ジュニアポジション

リモートワークに移る前に、私たちはジュニアスペシャリストと仕事を始めました。あまり積極的ではありませんが、卒業生のジュンを雇いました。離れた場所に搭載するのは非常に困難であり、これまでのところ経験がほとんどないため、このストーリーを完全に凍結しました。したがって、少なくとも3〜4年の経験を持つミドルに焦点を当てます。



しかし、私たちがジュニアと一緒に仕事をしたときでさえ、彼らが非常に迅速に学び、適応できるように、彼らが1年で中途半端に成長できることが私たちにとって重要でした。

高い雇用要件

非常に高い要件のために私たちが仕事を得るのは非常に難しいという伝説があります。これは完全に真実ではありません。



チームリーダーのポジションを持つ候補者は、私たちの内部基準によれば、中間のインタビューのために私たちに来ることがよくあります。これは、ポジションを追求するために、人を雇うためだけに、現在の能力を超えるポジションをいくつかのステップで与える準備ができている企業に来るためです。その結果、結果は不利益になります。その人はまだ必要なレベルまでポンプを上げていませんが、彼はすでに高い位置を占めています。そうすれば、他の会社で同じ役職に就くことはないので、彼は会社を辞めることはほとんどできません。



雇用の最大の阻害要因は英語です。以前は英語の知識がなくても雇用できましたが、今では不可能であり、数か月でそれを汲み上げることは不可能です。仕事の最初の数週間のエンジニアは、英語のドキュメントを読み、同僚と英語で連絡し、総会に出席する必要があります。そのほとんどは英語で行われます。言語。



製品は成長しており、新しい興味深いタスクが出現しているため、Permとアムステルダムの両方でエンジニアリングの分野で常に多くのオープンポジションがあります。