「常に進化する必要があります」：Evgeny Kuvshinov（ManyChat）とのスタートアップ開発に関するインタビュー

大企業では開発がどのように見え、小企業ではどのように開発と異なるかを大まかに想像します。 しかし、企業の規模が急速に変化し、従業員数が数年で10倍に増えた場合はどうなりますか？ スタートアップが急速に成長し、外出先で新しい状況に適応する必要がある場合、これはすべて（プロセスからテクノロジーまで）にどのように影響しますか？



ManyChatは、HolyJS会議に参加する予定です。 そのため、フロントエンドのEvgeny Kuvshinovの開発 、特にManyChatの技術サポート、および一般的にスタートアップでの開発（フロントエンド）の開発について技術サポートを依頼しました。



-まず、ManyChatで何をしているか、会社自体が何をしているかを簡単に教えてください。



-私はちょうどフロントエンド開発者として会社に来ました。6か月後、私はフロントエンドチームリーダーに成長しました。 その後、フロント、バック、テスト、製品などの機能的なチームがまだありました。 そして、LeSSですべてのプロセスを再構築した後、開発に戻りましたが、以前の組織的なタスクはほとんどありませんでした。 私はユーザーエクスペリエンスに携わっており、製品の部分に関係するよう努めており、一部は製品マネージャーとして成長していますが、同時にコードを常に書いています。



会社として、私たちは企業が比較的新しいコミュニケーションチャネルであるFacebook Messengerの使用を支援しています。 ManyChatは、メッセンジャー用のチャットボットをすばやく簡単に作成するためのプラットフォームです。 これは人工知能に関するものではなく、人間のコミュニケーションをエミュレートする試みに関するものではなく、これが不要なシナリオに関するものです。 ボットの助けを借りて、ニュースレターを作成したり、注文、予約、ロイヤルティプログラムなどのより複雑なインタラクティブな設定を行うことができます。 また、視覚的かつ明確に行われます。これは、かなり高度なビジネスオーナーまたはプログラミングスキルのないマーケティング担当者が行うことができます。



特定の例を使用して、Messengerでのボットの一般的な動作を確認できます。HolyJSに合わせて、 特別なボットを作成しました。







-確かに「数年前にチャットボットは失敗しました」という言葉を常に聞きます。 あなたの経験は、一般的に、特定の状況において、それらが非常に適切であることを示していますか？



-はい。 おそらく何よりも、便宜性は私たちの場合でさえ証明されず、WeChatプラットフォームによって証明されます。 これは中国ではほとんどすべての人が使用しているメッセンジャーであり、多くのビジネスがあり、中国でのピザやタクシーの注文などがWeChatを通じて活発に行われています。 そしてこれは、人間とビジネスのコミュニケーションの特定のインタラクティブなシナリオが本当にうまく機能することを示しており、両者にとって便利です。



そして、数年前に誇大宣伝されていた使用法-あなたが人間としてボットと話すことができ、彼が飛行機へのフライトの最高のバージョンを提供するように-そう、それは本当にうまく機能しません。



そして、WeChatに近いものを実装していますが、他の市場でも、そもそも、米国でも、世界中にあります。 ヨーロッパにはかなりの数の顧客がいます。中国に近い国では、多くの人がFacebook Messengerを使用しています。



-成長のトピックに移ります。会社はどのくらいの期間登場し、その瞬間から現在までどのように成長しましたか？



-会社は2015年に登場しました。 それは、共同設立者のミカエル・ヤンが電報でニュースレターを書く必要があったという事実から始まりました（まだチャンネルはありませんでした）。 彼はそれが非常に複雑であり、特別なツールが有用であることを認識しました。 その結果、MichaelとAnton Gorinは、Telegramでボットを作成するためのプラットフォームを最初に作成しました。 プラットフォームは十分に急速に成長し始め、バレーのスタートアップアクセラレータにヒットしました。



そして、彼らがアクセラレーターにいる間、Facebookはメッセンジャー用のAPIを開きました。 そして、Facebook Messenger専用の新製品を作るために、彼らが鋭いピボットをすることを決めた瞬間でした。 メッセンジャーの毎月のオーディエンスは14億人で、Facebookでは多くの企業が公式ページの形で表象しています。 これらのページでは、ボットを作成できます。



当初、3人の従業員がいました：Michael、Anton、およびフロントエンドの最初のバージョンを作成した別の開発者。 同じ年の秋に、最初の投資を受けて、チームの拡大を開始できることが明らかになりました。 その後、私と他の3人の開発者が会社に来たので、2016年の終わりには7人でした。 そして今、2年後、すでに50人以上が存在し、成長が続いています。



プラットフォーム自体の数を見ると、すでに40万を超えるボットが接続されています。 また、財務指標の面でも順調に成長しています。すでに収益性の高い企業ですが、さらに積極的に成長するために投資を探し続けています。 来年、少なくとも人数で倍増する予定です。



-スタートアップは、試行錯誤によって多くのことが行われる非常に実験的な分野です（前述のピボットのように、1つのコンセプトから始めて、外出先で変更したとき）。 これは開発にどのように影響しますか？ これは、「実装した機能が破棄される」という状況に常に備える必要があるということですか？



-確かに、いくつかの機能を作成できるものがありますが、最終的にはユーザーからの需要はなく、採用率は低くなります。 または、彼女は本番にまったく行かないかもしれません。私たち自身は、何が起こったのかを見て、私たちはそれが好きではないことを理解するからです。



そのような状況の数を最小限に抑えるために、私たちが最初に考えるのは（開発中であっても、機能の製品開発の最初に）動機付けです。 なぜ、誰のために、それが既存のユーザーにどの程度影響するか、自分自身でどれだけ気に入っているか（そのようなことが製品に登場したことを喜んで誇りに思います）。 ユーザーコミュニティでアンケートを行ったり、ユーザーとのインタビューを行ったりすることで、動機付けを決定し、開発を開始します。 次に、スプ​​リント用の機能を準備します。このようなプロセスはPBR（製品バックログ調整）と呼ばれます。最初にバックログに入り、次に評価で上昇し、ある時点で既に十分に説明されているように、スプリントに分類されます。



スプリントで直接、最初に行うことは、それがどのように見えるかを理解していない場合、モックアップとプロトタイプを作成することです。 しかし、それがどんなに奇妙に聞こえるかに関係なく、時には開発ですでに行われています。 なぜなら、単にレイアウトを作成してイラストを描くだけでは、ユーザーがインターフェースをどのように感じるかを理解するのが非常に難しいからです。



フロントエンドでは、原則として既に機能しているプロトタイプまたはインタラクティブ機能を作成することが多く、クリックしてそれらを感じることができます。 そして、デザイナーとの緊密な連携により、これらのプロトタイプを実稼働に移行するオプションにします。 しかし、それにもかかわらず、ここでこれらのプロトタイプを作成するとき、それを作成し、見、そしてあなたが「いいえ、来ない、それは不便です」と自分自身を理解するとき、それはまた頻繁な現象です。 ボットを作成するために独自の製品を使用して、ユーザーが問題が発生する可能性のある場所を見つける前であっても、それを試みます。 まあ、一般的に、私たちはユーザーエクスペリエンスに焦点を当て、最も使いやすいプラットフォームを構築しようとしています。



-会社の急速な成長に伴い、数十人に切り替えたときに、数人のために働いていたプロセスが機能しなくなるという事実に気付くでしょう。 組織の観点から開発はどのように変化しましたか？



-難しかったです。 年の初めには、かなり困難な状況がありました。数か月間、いくつかの機能を実行したとき、それらは常に「もう少し仕上げて運用環境に展開する」ことができましたが、この「まだ少し」は発生しませんでした。



私たちが最初に始めたとき、私たちは7人いました。 スクラムがあり、スプリントがあり、すべてが構築され、十分にうまくいきました。 20〜30人に成長したとき、多くの企業と同様に、機能チーム（バックエンド、フロントエンド）が登場しました。 独自のプロセス、内部に独自のスプリント、独自のタスクキューを使用します。 また、「そのようなユーザーにそのようなメリットをもたらすような機能」と特に呼ばれるタスクは実行しませんでした。 各チームのタスクは、「フロントエンド：そのようなインターフェイスの一部を再配置し、ボタンを追加する」という精神で呼び出されました。



そして、それは多くの理由で悪かった。 まず、同じビジネスタスクの多くの異なるキューと部分があり、それらが異なる優先度を持っている場合、タスクがいつ完全に準備できるかを理解することはほとんど不可能になります。 また、特定の開発者が自分が何をしているかを理解することはより困難になります。 彼は彼のためにいくつかの部分を説明し、ユーザーが結果を後で喜ぶ方法を作るので、これがなぜ必要なのかさえ知らないかもしれないので、彼は知りません。



ある時点で、これが次に不可能であることを認識しました。 はい、少し調整して繰り返し、スプリントと毎日のスタンドアップを実行し続けることができます（チーム全体が参加したため、30分以上かかりましたが、何もしませんでした）。 しかし、これらは主な問題を解決しない表面的な対策です。



そしてその瞬間、会社のメンバーの1人が、LeSSまたはLarge-Scale Scrumと呼ばれるものがあることを私たちに知らせました。すでに大規模で成長しているチームのためのスクラムです。 会議室で数晩座って、私たちと起こったことをすべて話し合った後、CEOとCTO（ミカとアントン）は非常に難しいビジネス上の決定を下しました：開発プロセス全体（機能の設計、実装、展開）をゴミ箱に捨てます。 進行中のスプリントを終了し、すべてを新しく構築します。



決定は難しく、私たちがこれを行っていることに気づき、長い間考えていました。「くそ、うまくいくかどうか？」しかし、LeSSと認定トレーナーに関する本を参照して、すべて同じように試すことにしました。 彼らは新しい方法でスタートし、機能横断型のチームを作りました-最初は3人でした。 私たちは、LeSSルール（これらのスプリントでのミーティングのセットの意味でのルール）に従って、短い週ごとのスプリントを開始しました。 詳細はお伝えしませんが、私たちにかかっていると思われる8つのタスクの最初の週のスプリントでは、数か月間ロールアウトできなかったため、すべてではないにしても本番でロールアウトしました。 そして、何が起こっているのか理解できませんでした。 どうして？ なぜこれができなかったのですか？ そして、なぜそれが起こったのですか？ とてもクールで、私たちは先に進み、新しいタスクを引き受け、部門を越えたチームでそれらをより速く解決し始めました。



もちろん、いくつかの困難と誤解もありました。 しかし、おそらく、おそらく、チームの大半は新しいプロセスを本当に気に入っています。これは、機能の市場投入までの時間が大幅に短縮されたため、すべてを非常に迅速に実行でき、運用環境に展開できるためです。 これに加えて、私たちはユーザーからのフィードバックを伝えて、開発者が自分の仕事をどれだけ気に入っているかを確認できるようにします。



もう1つの興味深い点は、LeSSに切り替えた後のフロントエンドの展開方法です。 私たちは現在、複数の職務にまたがるチームに分かれていることに気づき、初めて（少なくともフロントエンドコミュニティが機能を開始する前に）コミュニケーションが少なくなります。 そして、必要なときにいつでも「指先で」フロントエンドをロールアウトすることを学びました。新しいスプリントの開始前に1つの会議があり、メインブランチがあると言い、いつでもロールアウトできます。 。 その前に、すべてのアセンブリをチェックする統合UIテストのシステムを確実に構築し、カバレッジの大部分があり、それが「グリーン」である場合にのみロールバックできると考えていました。 しかし、製品は非常に急速に成長しているため、それは夢のようなものでした。この場合、どんなに一生懸命努力しても、カバレッジの大きな割合を維持することはできません。 その結果、すべての開発者に同意し、この責任を与えることで、メインブランチのコードが実際に常に機能し、そこから必要なアセンブリをいつでも取り出して展開できるようになりました。



-うわー、詳細な答えをありがとう。 説明した移行に加えて、フルスタックから狭い専門への移行があったはずだと思います：プロジェクトですべてを行うのは少数の人だけであり、別のことをしなければならず、50人を超えると誰もが明確な円を描くタスク。 そうですか？



-私たちが少人数だったとき、さまざまな分野から多くの問題を本当に解決しなければなりませんでした。 たとえば、私はしばらくの間、システム管理に従事し、CIシステムをセットアップしました。 そして今、LeSSへの移行により、これははるかに少なくなりました。



しかし、これは誰もが狭い役割に縛られているという意味ではありません。 あなたが会社に来たとき、あなたは主な能力を持っています（少なくともバックエンド、少なくともデザイナー）、そして誰もあなたがこの特定の垂直を宇宙に汲み上げるのを止めることはありませんが、同時に、LeSSは関連する方向で開発する機会（ちょうど機会）を提供します。



私たちは小さな標準スクラムチームに分かれており、6人（プラスまたはマイナス3人）が集まって、隣接するテーブルの隣に座っています。 これは、フロントエンドが常にバックエンドとデザイナーの両方と通信できることを意味します。 クールなコミュニケーションがこのように構築されているという事実に加えて、これらの人から学ぶこともできます。 そして、例えば、このスプリントのためにフロントに関与している人が、小さなバックエンドのタスクを引き受けて、この領域をポンプでくくることを望むならば、我々は歓迎します。 さまざまな分野から得た知識が多ければ多いほど、製品全体に集中できるようになり、問題をよりうまく解決できるようになります。 デザイナーがこれを行う理由、製品の専門家が行う理由を理解し始めると、自分でインターフェイスを作成し始め、それを単純に表示して、「はい、クール」と言うことがあります。 そして、それに応じて、より速く仕事をすることができます。



-スタートアップは進歩の最前線にいます。 これは、テクノロジーを選択するときに、まったく新しいものを簡単に本番環境にドラッグできるということですか？ また、これが企業に害を及ぼす可能性のある「光沢のある新しいもの」の追求にならないように注意事項はありますか？



-簡単な答えは：はい、超新星、クールで面白いことが可能です。あらゆる方法でこれを歓迎します。 しかし、もちろん、新技術の導入には一定の基準があります。



興味のある技術を見つけたら、それをコミュニティに持ち込む必要があります。 社内にフロントエンドチームはもうありませんが、フロントエンドコミュニティがあり、定期的にそのような問題を収集して議論しています。 ここで、なぜこれが素晴らしいのか、なぜ今後一緒に住みやすいのかをみんなに伝えることができます。 一部の企業は、特定の選択システム、つまり入力が必要な比較を含む複雑なテーブルを持っている可能性があります。 そのようなものは何もありません。すべての決定は非常に主観的な感覚のレベルで行われますが、同時に非常に優れた興味深い技術が十分に迅速に現れます。



まだリリースに達していないものがあります。 ライブラリを使用して、Reactでパネルを作成し始めました。まだ十分に未加工だったので、覚えている限りでは、ほんの少しでも寄付されました。 ある種のベータ版でBabel 7の使用を開始しました。以前のプロジェクトよりも少し速くプロジェクトを構築できたからです。



そして、おそらく、チームの誰も彼が新しいクールなものを望んでいると不平を言ったことはありませんでしたが、彼らは彼に言いました：「いいえ、私たちはそのようなポリシーを持っています、私たちはそれをしません」 そして、このようなアプローチを引き起こす単一の問題を思い出すことはできませんが、新しい興味深い技術を歓迎します。 以前の経験では、このレベルで多くの間違った決定を下したため、それは私にとって非常に奇妙です。 しかし、ManyChatでは、おそらくコミュニティの助けを借りて、何か他の理由で、何かを選択したときにこれらのファイルがなかったので、コードベースの半分を別のテクノロジーに書き換える必要がありました。これは入っていないからです。



-「進行のヒント」についての詳細：スタートアップが「レガシーコードを扱う必要がない」と落ち着いて息を吹き込むことができると思います。 そうですか？



-さて、誰もが「レガシー」という言葉を独自の方法で理解しています。 たとえば、3年以上前のコードを意味する場合、もちろん3年未満の会社ではそうではありません。 しかし、この概念を厳しくすることができます。そうすれば、レガシーコードの一部が得られます。 3年前ではなく、ほんの数か月前に書かれたという観点からは、その後、私たちは何かを正しく行う方法を知りませんでしたが、今では、1000行ではなく100行を実行できることを学びました。同じことがさらに信頼できます。 もちろん、そのようなコードは避けられません。 しかし、このプログラミング言語を知っているのは彼らだけであり、それを拒否することはできないため、「ひげを生やした開発者」を探す必要があるものは何もありません。



-スタートアップ開発は「自転車の構築」にどの程度貢献していますか？ 巨大企業は内部ですべてを行っていますが、あなたはそれをしていませんか？ それとも、スタートアップは誰もが自分のことをするような場所なのでしょうか？



-私たちにとって、ビジネス価値が第一です。 私たちはすでに利益を上げていますが、速度を落として誰かに負け始めると、非常に苦痛になります。 したがって、サードパーティの開発がビジネス要件と一致し、ビジネス上の問題を解決し、大きな問題がなければ、安全にそれを使用できます。 - - , , . — - .



— , ? , - «»?



— , — . , , , , - , - . : , .



. ManyChat React, Baobab. , React . view React, store Baobab. , , .



2017 . React, Redux middleware – Thunk Fetch API. , . , , , , .



— , , , . -, «» ?



— c , Flow, — Flow Builder. , :







, , 2D-. Flow Builder PixiJS — WebGL/Canvas.



. , . PixiJS requestAnimationFrame . , , , , . ( 12- MacBook, , ). , , , .



, , -, - , - , , , . 2D-.



— «»? , , ?



— , , , , , … , HTML, Canvas WebGL , . Pixi, .



: , Canvas, - WebGL. Pixi , , . , - . , issue, GitHub , , , .



, , , Canvas , HTML CSS. , Flexbox layout', . . Canvas, : Canvas, textarea, CSS scale , : Canvas - , HTML.



, . , Pixi - , , Flow Chart . - - , : , . , , , , . .



— . , , , . - , - ?



— , , . , - , . , - , .



: - -, - - , , , . , , . , , - -. , , , , . -, , , , .