Nous imaginons tous à peu près à quoi ressemble le développement dans une grande entreprise et à quel point un petit développement peut en différer. Mais que se passe-t-il si la taille d'une entreprise change rapidement et que le nombre d'employés décuple en quelques années? Lorsqu'une startup se développe rapidement et que vous devez vous adapter à de nouvelles circonstances en déplacement, comment cela affecte-t-il tout (des processus aux technologies)?
ManyChat participera à notre conférence HolyJS, c'est exactement ce qui se passe. Par conséquent, nous avons demandé un support technique pour le développement du frontend d'
Evgeny Kuvshinov et spécifiquement sur ManyChat, et en général sur ce que c'est que de faire du développement (front-end) dans une startup.
- Tout d'abord, dites-nous brièvement ce que vous faites chez ManyChat et ce que fait l'entreprise elle-même.- Je suis arrivé dans l'entreprise en tant que développeur front-end, six mois plus tard, j'ai grandi à la tête de l'équipe front-end. Ensuite, nous avions encore de telles équipes fonctionnelles - avant, arrière, tests, produit. Et après avoir reconstruit tous nos processus sur LeSS, je suis retourné au développement et je n'avais presque plus de tâches organisationnelles précédentes. Je suis engagé dans l'expérience utilisateur, j'essaie de me relier à la partie produit, de grandir en partie en tant que chef de produit, mais en même temps d'écrire constamment du code.
En tant qu'entreprise, nous aidons les entreprises à utiliser le canal de communication relativement nouveau, Facebook Messenger. ManyChat est une plate-forme pour créer rapidement et facilement des robots de discussion pour Messenger. Il ne s'agit pas d'intelligence artificielle, pas de tentatives d'émulation de la communication humaine, mais de scénarios où cela n'est pas nécessaire. Avec l'aide de nos bots, vous pouvez simplement créer des newsletters et configurer des choses interactives plus complexes comme les commandes, les réservations, les programmes de fidélité. Ils sont également faits visuellement et clairement, et cela peut être fait par un propriétaire d'entreprise assez avancé ou un agent de commercialisation sans compétences en programmation.
Vous pouvez voir comment les bots fonctionnent dans Messenger en général, en utilisant un exemple spécifique: à temps pour HolyJS, nous avons créé un
bot spécial .
- Vous entendez sûrement constamment les mots "Mais les robots de chat ont échoué il y a quelques années." Votre expérience montre-t-elle qu'en général, dans un certain contexte, sont-elles tout à fait appropriées?- Oui. Peut-être surtout, l'opportunité n'est pas prouvée même par notre cas, mais par la plate-forme WeChat. C'est un messager que presque tout le monde utilise en Chine, il y a beaucoup d'entreprises et des choses comme commander des pizzas ou des taxis en Chine se produisent maintenant activement via WeChat. Et cela montre que certains scénarios interactifs de communication humaine et commerciale fonctionnent vraiment bien, c'est pratique pour les deux parties.
Et ces usages qui étaient hype il y a quelques années - comme vous pouvez parler avec un bot en tant que personne et il offrira la meilleure version d'un vol à un avion - eh bien, cela ne fonctionne vraiment pas très bien.
Et nous mettons en œuvre quelque chose de proche de WeChat, mais sur d'autres marchés: en premier lieu, aux États-Unis, mais partout dans le monde également. Nous avons un nombre assez important de clients européens, et dans les pays proches de la Chine également, beaucoup utilisent désormais Facebook Messenger.
- Passons au thème de la croissance: depuis combien de temps l'entreprise est-elle apparue, et comment s'est-elle développée de ce moment à notre époque?- L'entreprise est apparue en 2015. Cela a commencé avec le fait que son co-fondateur Mikael Jan avait besoin de faire une newsletter sur Telegram (alors il n'y avait pas encore de chaînes). Il s'est rendu compte que c'était assez compliqué et qu'un outil spécial serait utile. En conséquence, Michael et Anton Gorin ont d'abord créé une plate-forme pour créer des robots dans Telegram. La plate-forme a commencé à croître assez rapidement, ils ont frappé l'accélérateur de démarrage dans la vallée.
Et alors qu'ils étaient dans l'accélérateur, Facebook a ouvert l'API pour Messenger. Et c'est à ce moment-là qu'ils ont décidé de faire un pivot pointu, de créer un nouveau produit spécialement pour Facebook Messenger. L'audience mensuelle de Messenger est de 1,4 milliard de personnes, et sur Facebook de nombreuses entreprises ont leurs représentations sous forme de pages officielles. Et pour ces pages, vous pouvez créer des bots.
Initialement, il y avait trois employés: Michael, Anton et un autre développeur qui ont fait la toute première version du frontend. À l'automne de la même année, les premiers investissements ont été reçus et il est devenu clair que vous pouvez commencer à agrandir l'équipe. Ensuite, moi et trois autres développeurs sommes venus dans l'entreprise, donc fin 2016, nous étions sept. Et maintenant, deux ans plus tard, nous sommes déjà plus de cinquante et la croissance continue.
Si vous regardez les numéros de la plate-forme elle-même, nous avons déjà plus de 400 000 robots connectés. Et nous progressons bien en termes d'indicateurs financiers: nous sommes déjà en ce moment une entreprise rentable, alors que nous continuons à rechercher des investissements afin de croître encore plus activement. L'année prochaine, nous prévoyons de doubler au moins en termes de nombre de personnes.
- Les startups sont un domaine très expérimental où beaucoup est fait par essais et erreurs (comme le pivot mentionné, lorsque nous avons commencé avec un concept, puis changé en cours de route). Comment cela affecte-t-il le développement? Cela signifie-t-il que vous devez toujours être préparé à la situation "la fonctionnalité que vous avez implémentée sera supprimée"?- En effet, il y a une telle chose que vous pouvez faire une fonctionnalité, mais au final, elle ne sera pas demandée par les utilisateurs, elle sera peu adoptée. Ou bien elle n’arrivera peut-être pas du tout à la production, car nous-mêmes, en regardant ce qui s’est passé, comprendrons que nous n’aimons pas cela.
Pour minimiser le nombre de telles situations, la toute première chose à laquelle nous pensons (même pas pendant le développement, mais au début du développement du produit d'une fonctionnalité) est la motivation. Pourquoi le faisons-nous, pour qui, dans quelle mesure cela affectera-t-il les utilisateurs existants, dans quelle mesure nous l'aimons nous-mêmes (serons-nous heureux et fiers qu'une telle chose soit apparue dans notre produit). Après avoir décidé de la motivation, peut-être en menant des sondages dans notre communauté d'utilisateurs ou d'autres entretiens avec nos utilisateurs, nous commençons à nous développer. Ensuite, nous préparons la fonctionnalité pour le sprint, un tel processus est appelé PBR (Product Backlog Refinement): d'abord, il va dans le backlog, puis il monte là-haut dans la note, et à un moment donné, déjà bien décrit, il peut tomber dans le sprint.
Directement dans le sprint, la première chose que nous faisons est que si nous ne comprenons pas à quoi cela ressemblera, nous faisons des maquettes et des prototypes. Mais, aussi étrange que cela puisse paraître, il est parfois déjà fait avec le développement. Parce que parfois, il est très difficile de comprendre comment l'utilisateur se sentira avec l'interface, simplement en faisant des mises en page et en dessinant des illustrations.
Très souvent, à l'avant, nous réalisons des prototypes ou des fonctionnalités interactives qui, en principe, fonctionnent déjà, vous pouvez cliquer dessus et les ressentir. Et puis, en étroite collaboration avec les designers, nous apportons ces prototypes à une option qui entrera en production. Mais, néanmoins, lors de la création de ces prototypes ici, il n'est pas rare non plus que vous le fassiez, que vous regardiez et que vous vous compreniez "non, ça ne s'arrêtera pas, c'est gênant". Nous essayons d'utiliser notre propre produit, de créer des robots, afin que même avant que nos utilisateurs découvrent où certains problèmes peuvent survenir. Eh bien, en général, nous nous concentrons sur l'expérience utilisateur, nous essayons de créer la plate-forme la plus facile à utiliser.
- Avec la croissance rapide de l'entreprise, vous tombez probablement sur le fait que les processus qui ont fonctionné pour plusieurs personnes cessent de fonctionner lors du passage à des dizaines de personnes. Comment votre développement a-t-il changé d'un point de vue organisationnel?- C'était difficile. Au début de l'année, nous avons eu une situation assez difficile, quand nous avons fait plusieurs fonctionnalités pendant plusieurs mois, ils ont constamment pu «finir un peu et le mettre en production», mais ce «encore un peu» n'est pas venu.
Lorsque nous avons commencé, nous étions sept. Nous avons eu une mêlée, il y avait des sprints, tout était construit et allait assez bien. Lorsque nous sommes passés à 20-30 personnes, nous sommes apparus, comme dans de nombreuses entreprises, des équipes fonctionnelles: backend, frontend. Avec ses propres processus, avec ses propres sprints à l'intérieur, avec ses propres files d'attente de tâches. Et nous n'avons pas fait de tâches qui soient spécifiquement appelées "telle ou telle fonctionnalité qui apportera tel ou tel avantage à tel ou tel utilisateur". Les tâches de chaque équipe ont été appelées dans l'esprit de «frontend: pour réorganiser un tel morceau de l'interface, ajoutez un bouton».
Et c'était mauvais pour de nombreuses raisons. Tout d'abord, lorsque nous avons plusieurs files d'attente et éléments de la même tâche métier, ils ont des priorités différentes, il devient presque impossible de comprendre quand la tâche sera complètement prête. Et il devient plus difficile pour un développeur spécifique de comprendre ce qu'il fait. Parce qu'il fait un morceau décrit pour lui, et comment les utilisateurs se réjouiront ensuite du résultat, il ne sait pas, car il ne sait même pas à bien des égards pourquoi tout cela est nécessaire.
À un moment donné, nous avons réalisé que cela était impossible ensuite. Oui, vous pouvez régler un peu, répéter, continuer à effectuer des sprints et des stand-ups quotidiens (qui ont commencé à prendre plus d'une demi-heure, car ils ont été suivis par toute l'équipe, mais qui n'ont rien donné). Mais ce sont des mesures cosmétiques qui ne résolvent pas le problème principal.
Et à ce moment-là, l'un des gars de l'entreprise nous a informés qu'il existait une chose appelée LeSS ou Scrum à grande échelle: une mêlée pour des équipes déjà grandes et en croissance. Après avoir passé plusieurs soirées dans les salles de réunion, à discuter de tout ce qui se passait, le PDG et le CTO (Mika et Anton) ont pris une décision commerciale très difficile: nous allons jeter tout le processus de développement (comment nous concevons les fonctionnalités, implémentons et déployons) à la poubelle. Nous terminerons le sprint en cours, puis nous reconstruirons tout.
La décision a été difficile et, réalisant que nous faisions cela, nous avons longuement réfléchi: "Bon sang, ça va marcher ou pas?" Mais nous avons décidé de l'essayer tout de même, en nous tournant vers le livre sur LeSS et vers des formateurs certifiés. Ils ont commencé d'une manière nouvelle, ont formé des équipes interfonctionnelles - au départ, il y en avait trois. Nous avons lancé de courts sprints hebdomadaires selon les règles LeSS (règles dans le sens de quel ensemble de réunions devraient être sur ces sprints). Je ne vous dirai pas tous les détails, mais pour le premier sprint hebdomadaire des huit tâches qui semblent nous pendre que nous n'avons pas pu déployer pendant plusieurs mois, nous nous sommes lancés en production, sinon tous, puis la plupart. Et nous ne comprenions tout simplement pas ce qui se passait. Comment ça? Pourquoi ne pourrions-nous pas faire cela avant? Et pourquoi est-ce arrivé? C'était très cool et nous avons commencé à avancer, à assumer de nouvelles tâches, à les résoudre dans des équipes interfonctionnelles beaucoup plus rapidement.
Bien sûr, il y a eu aussi des difficultés et des malentendus. Mais dans l'ensemble, probablement, pour la plupart de l'équipe, le processus émergent est très populaire, car le délai de commercialisation a considérablement diminué pour les fonctionnalités, vous pouvez tout faire très rapidement, passer à la production. Et en plus de cela, nous essayons de transmettre les commentaires de nos utilisateurs afin que les développeurs puissent voir à quel point les gens aiment ce qu'ils font.
Un autre point intéressant a été la façon dont nous déployons le frontend après notre passage à LeSS. Nous avons réalisé que nous sommes maintenant divisés en équipes interfonctionnelles distinctes et la première fois (au moins avant que la communauté frontale ne commence à fonctionner), nous communiquerons beaucoup moins. Et nous avons appris à déployer le frontend à tout moment «d'un simple clic de doigt», quand nous en avons besoin ... Nous avons eu une seule réunion avant le début d'un nouveau sprint, où nous avons dit que nous avions notre branche principale, et elle peut être déployée à tout moment . Avant cela, je pensais que nous devrions certainement construire un système de tests d'interface utilisateur qui vérifierait chaque assemblage, qu'il devrait y avoir un énorme pourcentage de couverture, et seulement s'il est "vert", nous pouvons rouler. Mais c'était un rêve de pipe, car le produit se développe très rapidement, et dans ce cas, peu importe vos efforts, vous ne pourrez toujours pas conserver un pourcentage énorme de couverture. En conséquence, après avoir convenu avec tous les développeurs et leur avoir confié cette responsabilité, nous avons réussi à nous assurer que le code de notre branche principale fonctionne désormais toujours et que nous pouvons toujours prendre et déployer tout assemblage dont nous avons besoin à partir de là.
- Wow, merci pour la réponse détaillée. Je suppose que, en plus de la transition décrite, une transition de «l'empilage complet» à une spécialisation étroite devait également avoir lieu: quand seulement quelques personnes font tout dans le projet, bon gré mal gré doit faire une variété de choses, et quand plus de cinquante personnes, tout le monde a un cercle clair tâches. En est-il ainsi?- Quand nous étions peu nombreux, nous avons vraiment dû résoudre de nombreux problèmes dans différents domaines. Par exemple, pendant un certain temps, j'ai été engagé dans l'administration système et mis en place un système CI. Et maintenant, avec la transition vers LeSS, c'est beaucoup moins.
Mais cela ne signifie pas que maintenant tout le monde est enfermé dans des rôles étroits. Lorsque vous arrivez dans l'entreprise, vous avez la compétence principale (que ce soit au moins un back-end, au moins un concepteur), et personne ne vous empêchera de pomper cette verticale particulière dans l'espace, mais en même temps, LeSS offre une opportunité (juste une opportunité) de se développer dans des directions connexes .
Nous sommes divisés en petites équipes de mêlée standard dans lesquelles il y a six (plus ou moins trois) personnes réunies et assis à côté des tables adjacentes. Cela signifie que le front-end peut toujours communiquer avec le back-end et le concepteur. Outre le fait que la communication cool est construite de cette manière, vous pouvez également apprendre de ces gars-là. Et nous nous félicitons si la personne impliquée dans le front, par exemple, pour ce sprint veut entreprendre une petite tâche back-end et pomper cette zone. Parce que plus vous avez de connaissances dans différents domaines, plus vous vous concentrez sur l'ensemble du produit, et vous réussissez mieux à résoudre vos problèmes. Lorsque vous commencez à comprendre pourquoi les concepteurs font cela, pourquoi les experts en produits le font, vous pouvez parfois commencer à créer une interface vous-même, que vous leur montrez ensuite simplement, et ils disent «oui, cool». Et, en conséquence, vous pouvez faire votre travail plus rapidement.
- Les startups sont à la pointe du progrès. Est-ce à dire que lorsque vous choisissez des technologies, vous pouvez facilement faire glisser quelque chose de complètement nouveau dans la production? Et y a-t-il des précautions pour que cela ne se transforme pas en poursuite de «nouvelles choses brillantes» qui pourraient nuire aux entreprises?- La réponse courte est oui, une supernova, cool et intéressante est possible, nous nous en félicitons à tous points de vue. Mais, bien sûr, il existe certains critères pour l'introduction de nouvelles technologies.
Si vous trouvez une technologie qui vous intéresse, vous devez l'apporter à la communauté. Bien que nous n'ayons plus d'équipe front-end dans notre entreprise, il existe une communauté front-end dans laquelle nous nous réunissons et discutons périodiquement de ces questions. Là, vous pouvez dire à tout le monde pourquoi c'est génial et pourquoi il sera plus facile de vivre avec à l'avenir. Certaines entreprises ont probablement une sorte de système de sélection spécifique, un tableau compliqué avec des comparaisons qui doivent être remplies. Nous n'avons rien de tel, toutes les décisions sont prises au niveau de sensations très subjectives, mais en même temps, des technologies vraiment bonnes et intéressantes apparaissent assez rapidement.
Parfois, il y a des choses qui n'ont pas encore atteint la sortie. Nous avons commencé à utiliser la bibliothèque pour créer des panneaux dans React, alors qu'elle était encore assez brute, et, pour autant que je m'en souvienne, même un peu a été donné. Nous avons commencé à utiliser Babel 7 avec une sorte de bêta car cela nous a permis de construire le projet un peu plus rapidement que le précédent.
Et, probablement, personne dans l'équipe ne s'est jamais plaint qu'il voulait quelque chose de cool, mais ils lui ont dit: "Non, nous avons une telle politique, nous ne le ferons pas." Et même si je ne me souviens pas d'un seul problème qui provoquerait une telle approche, accueillir de nouvelles technologies intéressantes. C'est très étrange pour moi, car, dans mon expérience précédente, j'ai pris beaucoup de mauvaises décisions à ce niveau. Mais dans ManyChat, peut-être juste avec l'aide de la communauté, peut-être pour une autre raison, nous n'avons pas ces fichiers lorsque nous avons choisi quelque chose, puis nous avons dû prendre et réécrire la moitié de la base de code dans une autre technologie, parce que celui-ci n'est pas entré.
- Pour en savoir plus sur la "pointe du progrès": je veux supposer qu’une startup vous permet de respirer calmement "vous n’avez pas à faire face à un code hérité". En est-il ainsi?- Eh bien, tout le monde comprend le mot «héritage» à sa manière. Si nous entendons par là, par exemple, un code de plus de trois ans, alors dans une entreprise de moins de trois ans, bien sûr, ce n'est pas le cas. Mais vous pouvez resserrer ce concept, nous aurons alors un certain pourcentage de code hérité. Du point de vue qu'il a été écrit il n'y a pas trois ans, mais il y a seulement quelques mois, mais alors nous ne savions pas comment faire quelque chose correctement, mais maintenant nous avons appris, nous pouvons faire cent lignes au lieu de mille, et ils le feront la même chose est encore plus fiable. Un tel code, bien sûr, est, il est inévitable. Mais il n'y a rien pour lequel nous aurions à chercher des «développeurs barbus», car seuls ils connaissent ce langage de programmation, et nous ne pouvons pas le refuser.
- Dans quelle mesure le développement des startups contribue-t-il à la «construction de vélos»? Alors que les entreprises géantes font tout à l'intérieur, n'êtes-vous pas à la hauteur? Ou une startup est-elle un tel endroit où chacun fait son propre truc?- Pour nous, la valeur commerciale passe avant tout. Nous sommes déjà rentables, mais si nous ralentissons et commençons à perdre contre quelqu'un, ce sera très douloureux. , -, , - , . - - , , . — - .
— , ? , - «»?— , — . , , , , - , - . : , .
. 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 . - - , : , . , , , , . .
— . , , , . - , - ?— , , . , - , . , - , .
: - -, - - , , , . , , . , , - -. , , , , . -, , , , .
