Wir alle stellen uns grob vor, wie Entwicklung in einem großen Unternehmen aussieht und wie sich kleine Entwicklung davon unterscheiden kann. Aber was passiert, wenn sich die Größe eines Unternehmens schnell ändert und sich die Anzahl der Mitarbeiter innerhalb weniger Jahre verzehnfacht? Wie wirkt sich dies auf alles aus (von Prozessen bis zu Technologien), wenn ein Startup schnell wächst und Sie sich unterwegs an neue Umstände anpassen müssen?
ManyChat wird an unserer HolyJS-Konferenz teilnehmen, genau das passiert. Aus diesem
Grund haben wir den technischen Support für die Entwicklung des Frontends von
Evgeny Kuvshinov und speziell für ManyChat gebeten und allgemein darüber, wie es ist, (Front-End-) Entwicklung in einem Startup durchzuführen.
- Sagen Sie uns zunächst kurz, was Sie bei ManyChat tun und was das Unternehmen selbst tut.- Ich bin nur als Front-End-Entwickler zum Unternehmen gekommen, sechs Monate später bin ich zum Leiter des Front-End-Teams herangewachsen. Dann hatten wir noch solche Funktionsteams - vorne, hinten, testen, Produkt. Und nachdem wir alle unsere Prozesse auf LeSS neu aufgebaut hatten, kehrte ich zur Entwicklung zurück und hatte fast keine vorherigen organisatorischen Aufgaben. Ich beschäftige mich mit User Experience, versuche mich auf den Produktteil zu beziehen, teilweise als Produktmanager zu wachsen, aber gleichzeitig ständig Code zu schreiben.
Als Unternehmen unterstützen wir Unternehmen bei der Nutzung des relativ neuen Kommunikationskanals Facebook Messenger. ManyChat ist eine Plattform zum schnellen und einfachen Erstellen von Chat-Bots für Messenger. Hier geht es nicht um künstliche Intelligenz, nicht um Versuche, die menschliche Kommunikation zu emulieren, sondern um Szenarien, in denen dies nicht erforderlich ist. Mit Hilfe unserer Bots können Sie einfach Mailings durchführen und komplexere interaktive Dinge wie Bestellungen, Reservierungen und Treueprogramme konfigurieren. Sie werden auch visuell und klar ausgeführt, und dies kann entweder von einem ziemlich fortgeschrittenen Geschäftsinhaber oder einem Vermarkter ohne Programmierkenntnisse durchgeführt werden.
An einem bestimmten Beispiel können Sie sehen, wie Bots im Allgemeinen in Messenger funktionieren: Pünktlich zu HolyJS haben wir einen
speziellen Bot erstellt .
- Sicherlich hört man ständig die Worte "Aber die Chat-Bots sind vor ein paar Jahren gescheitert." Zeigt Ihre Erfahrung, dass sie in einem bestimmten Kontext im Allgemeinen durchaus angemessen sind?- Ja. Vielleicht am allermeisten wird die Zweckmäßigkeit nicht einmal durch unseren Fall, sondern durch die WeChat-Plattform bewiesen. Dies ist ein Messenger, den fast jeder in China benutzt, es gibt viele Unternehmen darin, und Dinge wie die Bestellung von Pizza oder ein Taxi in China geschehen jetzt aktiv über WeChat. Und dies zeigt, dass bestimmte interaktive Szenarien der menschlichen und geschäftlichen Kommunikation wirklich gut funktionieren und für beide Seiten praktisch sind.
Und diese Verwendungen, die vor ein paar Jahren ein Hype waren - wie Sie mit einem Bot als Person sprechen können und der die beste Version eines Fluges zu einem Flugzeug anbietet -, funktioniert wirklich nicht sehr gut.
Und wir implementieren etwas in der Nähe von WeChat, aber in anderen Märkten: in erster Linie in den USA, aber auch auf der ganzen Welt. Wir haben eine ziemlich große Anzahl von Kunden aus Europa, und auch in Ländern in der Nähe von China verwenden viele jetzt Facebook Messenger.
- Wenden wir uns dem Thema Wachstum zu: Wie lange ist das Unternehmen schon erschienen und wie ist es von diesem Moment an bis zu unserer Zeit gewachsen?- Das Unternehmen erschien im Jahr 2015. Es begann damit, dass sein Mitbegründer Mikael Jan einen Newsletter über Telegramm schreiben musste (damals gab es dort noch keine Kanäle). Er erkannte, dass es ziemlich kompliziert war und ein spezielles Werkzeug nützlich sein würde. Infolgedessen haben Michael und Anton Gorin zunächst eine Plattform für die Erstellung von Bots in Telegram erstellt. Die Plattform begann schnell genug zu wachsen, sie drückten den Startbeschleuniger im Tal.
Und während sie im Beschleuniger waren, öffnete Facebook die API für Messenger. Und das war der Moment, in dem sie beschlossen, einen scharfen Dreh zu machen, um ein neues Produkt speziell für Facebook Messenger zu entwickeln. Das monatliche Publikum von Messenger beträgt 1,4 Milliarden Menschen, und auf Facebook haben viele Unternehmen ihre Darstellungen in Form von offiziellen Seiten. Und für diese Seiten können Sie Bots erstellen.
Anfangs gab es drei Mitarbeiter: Michael, Anton und einen anderen Entwickler, der die allererste Version des Frontends erstellt hat. Im Herbst desselben Jahres gingen die ersten Investitionen ein und es wurde klar, dass Sie beginnen können, das Team zu erweitern. Dann kamen ich und drei andere Entwickler zum Unternehmen, und Ende 2016 waren wir sieben. Und jetzt, zwei Jahre später, sind wir bereits mehr als fünfzig, und das Wachstum geht weiter.
Wenn Sie sich die Nummern der Plattform selbst ansehen, dann haben wir bereits mehr als 400.000 verbundene Bots. Und wir wachsen in Bezug auf Finanzindikatoren gut: Wir sind bereits im Moment ein profitables Unternehmen, während wir weiterhin nach Investitionen suchen, um noch aktiver zu wachsen. Nächstes Jahr wollen wir zumindest die Anzahl der Personen verdoppeln.
- Startups sind ein sehr experimentelles Feld, in dem viel durch Versuch und Irrtum getan wird (wie der erwähnte Pivot, als wir mit einem Konzept begonnen und dann unterwegs geändert haben). Wie wirkt sich das auf die Entwicklung aus? Bedeutet dies, dass Sie immer auf die Situation vorbereitet sein müssen, dass "die von Ihnen implementierte Funktion verworfen wird"?- In der Tat gibt es so etwas, dass Sie einige Funktionen ausführen können, aber am Ende wird es von den Benutzern nicht nachgefragt, es wird nur eine geringe Akzeptanz haben. Oder sie kommt überhaupt nicht zur Produktion, weil wir selbst, wenn wir uns ansehen, was passiert ist, verstehen, dass es uns nicht gefällt.
Um die Anzahl solcher Situationen zu minimieren, ist das allererste, woran wir denken (nicht einmal während der Entwicklung, sondern zu Beginn der Produktentwicklung eines Features), die Motivation. Warum machen wir das, für wen, wie sehr wird es bestehende Benutzer beeinflussen, wie sehr mögen wir es selbst (werden wir froh und stolz sein, dass so etwas in unserem Produkt aufgetaucht ist). Nachdem wir uns für die Motivation entschieden haben, vielleicht durch Umfragen in unserer Benutzergemeinschaft oder andere Interviews mit unseren Benutzern, beginnen wir uns zu entwickeln. Als nächstes bereiten wir die Funktion für das Sprinten vor. Ein solcher Prozess wird als PBR (Product Backlog Refinement) bezeichnet: Zuerst geht es zum Backlog, dann geht es dort in der Bewertung nach oben, und irgendwann kann es, bereits gut beschrieben, in den Sprint fallen.
Direkt im Sprint machen wir als Erstes einige Modelle und Prototypen, wenn wir nicht verstehen, wie es aussehen wird. Aber egal wie seltsam es klingen mag, manchmal ist es bereits mit der Entwicklung fertig. Weil es manchmal sehr schwierig ist zu verstehen, wie sich der Benutzer mit der Benutzeroberfläche fühlt, indem er einfach Layouts erstellt und Illustrationen zeichnet.
Sehr oft erstellen wir am Frontend Prototypen oder interaktive Funktionen, die im Prinzip bereits funktionieren. Sie können darauf klicken und sie fühlen. In enger Zusammenarbeit mit Designern bringen wir diese Prototypen zu einer Option, die in Produktion gehen wird. Wenn Sie diese Prototypen hier erstellen, ist es jedoch auch nicht ungewöhnlich, dass Sie sie erstellen, schauen und sich selbst verstehen: "Nein, es wird nicht aufhören, es ist unpraktisch." Wir versuchen, unser eigenes Produkt zu verwenden, Bots zu erstellen, damit unsere Benutzer bereits herausfinden, wo Probleme auftreten können. Im Allgemeinen konzentrieren wir uns auf die Benutzererfahrung und versuchen, die benutzerfreundlichste Plattform zu erstellen.
- Mit dem schnellen Wachstum des Unternehmens stoßen Sie wahrscheinlich auf die Tatsache, dass Prozesse, die für mehrere Personen funktionierten, nicht mehr funktionieren, wenn Sie zu Dutzenden von Personen wechseln. Wie hat sich Ihre Entwicklung aus organisatorischer Sicht verändert?- Es war schwierig. Zu Beginn des Jahres hatten wir eine ziemlich schwierige Situation, als wir mehrere Features für mehrere Monate machten, konnten sie es immer "ein bisschen fertigstellen und in die Produktion rollen", aber dieses "noch ein bisschen" kam nicht.
Als wir anfingen, waren wir sieben. Wir hatten ein Gedränge, es gab Sprints, alles war gebaut und lief gut genug. Als wir auf 20 bis 30 Personen angewachsen waren, erschienen wir, wie in vielen Unternehmen, als funktionale Teams: Backend, Frontend. Mit eigenen Prozessen, eigenen Sprints und eigenen Aufgabenwarteschlangen. Und wir haben keine Aufgaben ausgeführt, die speziell als "so und so eine Funktion, die dem einen oder anderen Nutzen für diesen und jenen Benutzer bringt" bezeichnet werden. Die Aufgaben jedes Teams wurden im Sinne von „Frontend: Um einen solchen Teil der Benutzeroberfläche neu anzuordnen, fügen Sie also eine Schaltfläche hinzu“ aufgerufen.
Und das war aus vielen Gründen schlecht. Erstens, wenn wir viele verschiedene Warteschlangen und Teile derselben Geschäftsaufgabe haben, die unterschiedliche Prioritäten haben, wird es fast unmöglich zu verstehen, wann die Aufgabe vollständig fertig sein wird. Und es wird für einen bestimmten Entwickler schwieriger zu verstehen, was er tut. Weil er ein für ihn beschriebenes Stück macht und sich die Benutzer dann über das Ergebnis freuen, weiß er es nicht, weil er möglicherweise nicht einmal in vielerlei Hinsicht weiß, warum dies alles notwendig ist.
Irgendwann wurde uns klar, dass dies als nächstes unmöglich ist. Ja, Sie können ein wenig stimmen, iterieren, weiterhin Sprints und tägliche Stand-Ups durchführen (was länger als eine halbe Stunde dauerte, weil sie vom gesamten Team besucht wurden, aber nichts gaben). Dies sind jedoch kosmetische Maßnahmen, die das Hauptproblem nicht lösen.
Und in diesem Moment teilte uns einer der Mitarbeiter des Unternehmens mit, dass es so etwas wie LeSS oder Large-Scale Scrum gibt: ein Scrum für bereits große und wachsende Teams. Nachdem wir mehrere Abende in den Verhandlungsräumen gesessen und alles besprochen hatten, was mit uns passiert, haben CEO und CTO (Mika und Anton) eine sehr schwierige Geschäftsentscheidung getroffen: Wir werden den gesamten Entwicklungsprozess (wie wir Features entwerfen, implementieren und einführen) in den Papierkorb werfen. Wir werden den Sprint jetzt beenden und dann alles neu bauen.
Die Entscheidung war schwierig, und als wir merkten, dass wir das taten, dachten wir lange: "Verdammt, wird es funktionieren oder nicht?" Wir haben uns jedoch entschlossen, es trotzdem zu versuchen und uns dem Buch über LeSS und zertifizierten Trainern zuzuwenden. Sie starteten neu, bildeten funktionsübergreifende Teams - am Anfang waren es drei. Wir haben kurze wöchentliche Sprints gemäß den LeSS-Regeln gestartet (Regeln im Sinne der Versammlungsreihe für diese Sprints). Ich werde Ihnen nicht alle Details erzählen, aber für den ersten wöchentlichen Sprint der acht Aufgaben, die uns zu hängen scheinen und die wir mehrere Monate lang nicht ausrollen konnten, haben wir in der Produktion ausgerollt, wenn nicht alle, dann das meiste davon. Und wir haben einfach nicht verstanden, was los war. Wie so? Warum konnten wir das vorher nicht tun? Und warum ist es passiert? Es war sehr cool und wir begannen weiterzumachen, neue Aufgaben zu übernehmen und sie in funktionsübergreifenden Teams viel schneller zu lösen.
Natürlich gab es auch einige Schwierigkeiten und Missverständnisse. Aber im Großen und Ganzen ist der aufkommende Prozess wahrscheinlich für den größten Teil des Teams sehr beliebt, da sich die Markteinführungszeit für Funktionen erheblich verkürzt hat. Sie können alles sehr schnell erledigen und in die Produktion einführen. Außerdem versuchen wir, Feedback von unseren Benutzern zu vermitteln, damit Entwickler sehen können, wie sehr die Leute das mögen, was sie tun.
Ein weiterer interessanter Punkt war, wie wir das Frontend ausrollen, nachdem wir zu LeSS gewechselt sind. Wir haben festgestellt, dass wir jetzt in separate funktionsübergreifende Teams aufgeteilt sind, und beim ersten Mal (zumindest bevor die Front-End-Community ihre Arbeit aufnimmt) werden wir viel weniger kommunizieren. Und wir haben gelernt, das Frontend jederzeit "auf Knopfdruck" auszurollen, wenn wir es brauchen ... Wir hatten ein einziges Meeting vor dem Start eines neuen Sprints, bei dem wir sagten, dass wir unseren Hauptzweig haben und es jederzeit ausrollen kann . Vorher hatte ich mir überlegt, dass wir definitiv ein System von Integrations-UI-Tests erstellen sollten, das jede Baugruppe überprüft, dass es einen großen Prozentsatz der Abdeckung gibt und nur wenn es "grün" ist, können wir rollen. Aber es war ein Wunschtraum, denn das Produkt wächst sehr schnell. In diesem Fall können Sie, egal wie sehr Sie es versuchen, immer noch keinen großen Prozentsatz der Abdeckung behalten. Nachdem wir uns mit allen Entwicklern einig waren und ihnen diese Verantwortung übertragen haben, haben wir es geschafft, dass der Code aus unserer Hauptniederlassung jetzt wirklich immer funktioniert und wir von dort aus einfach jede benötigte Baugruppe nehmen und ausrollen können.
- Wow, danke für die ausführliche Antwort. Ich möchte davon ausgehen, dass neben dem beschriebenen Übergang auch ein Übergang von „Full Stacking“ zu einer engen Spezialisierung stattfinden sollte: Wenn nur wenige Leute alles im Projekt tun, müssen wohl oder übel verschiedene Dinge tun, und wenn mehr als fünfzig, hat jeder einen klaren Kreis Aufgaben. Ist das so?- Als wir wenige waren, mussten wir wirklich viele Probleme aus verschiedenen Bereichen lösen. Zum Beispiel war ich einige Zeit mit der Systemadministration beschäftigt und habe ein CI-System eingerichtet. Und jetzt, mit dem Übergang zu LeSS, ist dies viel weniger.
Dies bedeutet jedoch nicht, dass jetzt jeder in engen Rollen gefangen ist. Wenn Sie zum Unternehmen kommen, haben Sie die Hauptkompetenz (sei es ein Back-End, mindestens ein Designer), und niemand wird Sie davon abhalten, diese bestimmte Vertikale in den Raum zu pumpen. Gleichzeitig bietet LeSS die Möglichkeit (nur eine Gelegenheit), sich in verwandte Richtungen zu entwickeln .
Wir sind in kleine Standard-Scrum-Teams unterteilt, in denen sechs (plus oder minus drei) Personen versammelt sind und neben benachbarten Tischen sitzen. Dies bedeutet, dass das Front-End immer sowohl mit dem Back-End als auch mit dem Designer kommunizieren kann. Neben der Tatsache, dass coole Kommunikation auf diese Weise aufgebaut ist, können Sie auch von diesen Jungs lernen. Und wir begrüßen es, wenn die Person, die zum Beispiel an der Front für diesen Sprint beteiligt ist, eine kleine Backend-Aufgabe übernehmen und diesen Bereich pumpen möchte. Denn je mehr Wissen Sie aus verschiedenen Bereichen haben, desto mehr konzentrieren Sie sich auf das gesamte Produkt und schaffen es dann besser, Ihre Probleme zu lösen. Wenn Sie verstehen, warum Designer dies tun, warum Produktexperten dies tun, können Sie manchmal selbst eine Benutzeroberfläche erstellen, die Sie ihnen dann einfach zeigen, und sie sagen „Ja, cool“. Und dementsprechend können Sie Ihre Arbeit schneller erledigen.
- Startups stehen an der Spitze des Fortschritts. Bedeutet dies, dass Sie bei der Auswahl von Technologien leicht etwas völlig Neues in die Produktion ziehen können? Und gibt es Vorsichtsmaßnahmen, damit dies nicht zu einem Streben nach „glänzenden neuen Dingen“ führt, die Unternehmen schaden könnten?- Die kurze Antwort lautet ja, eine Supernova, cool und interessant ist möglich, wir begrüßen dies in jeder Hinsicht. Natürlich gibt es bestimmte Kriterien für die Einführung neuer Technologien.
Wenn Sie eine Technologie finden, die Sie interessiert, müssen Sie sie der Community zur Verfügung stellen. Obwohl wir kein Front-End-Team mehr in unserem Unternehmen haben, gibt es eine Front-End-Community, in der wir solche Themen regelmäßig sammeln und diskutieren. Dort kann man jedem sagen, warum es großartig ist und warum es in Zukunft einfacher sein wird, damit zu leben. Einige Unternehmen haben wahrscheinlich ein spezifisches Auswahlsystem, eine komplizierte Tabelle mit Vergleichen, die ausgefüllt werden müssen. Wir haben so etwas nicht, alle Entscheidungen werden auf der Ebene einiger sehr subjektiver Empfindungen getroffen, aber gleichzeitig erscheinen wirklich gute und interessante Technologien schnell genug.
Manchmal gibt es Dinge, die die Veröffentlichung noch nicht erreicht haben. Wir haben angefangen, die Bibliothek zu verwenden, um Panels in React zu erstellen, als sie noch roh genug waren, und soweit ich mich erinnere, wurde dort sogar ein bisschen gespendet. Wir haben angefangen, Babel 7 mit einer Art Beta zu verwenden, weil es uns ermöglichte, das Projekt etwas schneller als das vorherige zu erstellen.
Und wahrscheinlich hat sich niemand im Team jemals darüber beschwert, dass er etwas Neues Cooles wollte, aber sie sagten zu ihm: "Nein, wir haben eine solche Politik, das werden wir nicht tun." Und obwohl ich mich nicht an ein einziges Problem erinnern kann, das einen solchen Ansatz verursachen würde, begrüße ich neue interessante Technologien. Es ist sehr seltsam für mich, weil ich in meiner vorherigen Erfahrung auf dieser Ebene viele falsche Entscheidungen getroffen habe. Aber in ManyChat, vielleicht nur mit Hilfe der Community, vielleicht aus einem anderen Grund, haben wir diese Dateien nicht, wenn wir etwas ausgewählt haben, und dann mussten wir die Hälfte der Codebasis auf eine andere Technologie übertragen. weil dieser nicht eingetreten ist.
- Mehr zum "Tipp des Fortschritts": Ich möchte davon ausgehen, dass Sie mit einem Startup ruhig atmen können, "Sie müssen sich nicht mit einem Legacy-Code befassen". Ist das so?- Nun, jeder versteht das Wort "Vermächtnis" auf seine Weise. Wenn wir damit beispielsweise einen Code meinen, der älter als drei Jahre ist, dann ist dies in einem Unternehmen unter drei Jahren natürlich nicht der Fall. Aber Sie können dieses Konzept verschärfen, dann haben wir einen gewissen Prozentsatz an Legacy-Code. , , , , - , , , . , , , . , - « », , .
— «»? - , ? , -?— business value. , -, . , -, , - , . - - , , . — - .
— , ? , - «»?— , — . , , , , - , - . : , .
. 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 . - - , : , . , , , , . .
— . , , , . - , - ?— , , . , - , . , - , .
: - -, - - , , , . , , . , , - -. , , , , . -, , , , .
