Todos imaginamos aproximadamente cómo es el desarrollo en una empresa grande y cómo el desarrollo pequeño puede diferir de él. Pero, ¿qué sucede si el tamaño de una empresa cambia rápidamente y el número de empleados aumenta diez veces en un par de años? Cuando una startup crece rápidamente y necesita adaptarse a nuevas circunstancias sobre la marcha, ¿cómo afecta esto a todo (desde los procesos hasta las tecnologías)?
ManyChat participará en nuestra conferencia HolyJS, que es exactamente lo que está sucediendo. Por lo tanto, solicitamos soporte técnico para el desarrollo del front-end
Evgeny Kuvshinov y específicamente sobre ManyChat, y en general sobre cómo es el desarrollo (front-end) en una startup.
- Primero, cuéntenos brevemente qué hace en ManyChat y qué hace la compañía misma.- Vine a la compañía como un desarrollador front-end, seis meses después crecí como líder del equipo front-end. Entonces todavía teníamos equipos tan funcionales: frente, atrás, pruebas, producto. Y después de reconstruir todos nuestros procesos en LeSS, volví al desarrollo y casi no tenía tareas organizativas previas. Estoy comprometido con la experiencia del usuario, trato de relacionarme con la parte del producto, en parte crezco como gerente de producto, pero al mismo tiempo escribo código constantemente.
Como empresa, ayudamos a las empresas a utilizar el canal de comunicación relativamente nuevo, Facebook Messenger. ManyChat es una plataforma para crear rápida y fácilmente bots de chat para Messenger. No se trata de inteligencia artificial, no de intentos de emular la comunicación humana, sino de escenarios en los que esto no es necesario. Con la ayuda de nuestros bots, puede simplemente enviar correos, y puede configurar cosas interactivas más complejas como pedidos, reservas, programas de fidelización. También se realizan de forma visual y clara, y esto lo puede hacer un dueño de negocio bastante avanzado o un vendedor sin habilidades de programación.
Puedes ver cómo funcionan los bots en Messenger en general, usando un ejemplo específico: a tiempo para HolyJS, creamos un
bot especial .
- Seguramente escuchas constantemente las palabras "Pero los robots de chat fallaron hace un par de años". ¿Su experiencia muestra que, en general, en un determinado contexto, son bastante apropiados?- si. Quizás, sobre todo, la conveniencia no está probada ni siquiera por nuestro caso, sino por la plataforma WeChat. Este es un mensajero que casi todo el mundo usa en China, hay muchas empresas en él y cosas como pedir pizza o un taxi en China ahora están sucediendo activamente a través de WeChat. Y esto muestra que ciertos escenarios interactivos de comunicación humana y comercial realmente funcionan bien, es conveniente para ambas partes.
Y esos usos que fueron exagerados hace un par de años, como si pudieras hablar con un bot como persona y él ofrecerá la mejor versión de un vuelo a un avión, bueno, eso realmente no funciona muy bien.
Y estamos implementando algo cercano a WeChat, pero en otros mercados: en primer lugar, en EE. UU., Aunque también en todo el mundo. Tenemos un número bastante grande de clientes de Europa, y también en países cercanos a China, muchos ahora usan Facebook Messenger.
- Pasando al tema del crecimiento: ¿cuánto tiempo ha aparecido la empresa y cómo ha crecido desde ese momento hasta nuestro tiempo?- La compañía apareció en 2015. Comenzó con el hecho de que su cofundador Mikael Jan necesitaba hacer un boletín en Telegram (entonces todavía no había canales allí). Se dio cuenta de que era bastante complicado y que una herramienta especial sería útil. Como resultado, Michael y Anton Gorin crearon una plataforma para crear bots en Telegram. La plataforma comenzó a crecer lo suficientemente rápido, llegaron al acelerador de arranque en el Valle.
Y mientras estaban en el acelerador, Facebook abrió la API para Messenger. Y ese fue el momento en que decidieron hacer un giro brusco, hacer un nuevo producto específicamente para Facebook Messenger. La audiencia mensual de Messenger es de 1.400 millones de personas, y en Facebook muchas empresas tienen sus representaciones en forma de páginas oficiales. Y para estas páginas puedes crear bots.
Inicialmente, había tres empleados: Michael, Anton y otro desarrollador que hicieron la primera versión de la interfaz. En el otoño del mismo año, se recibieron las primeras inversiones y quedó claro que puede comenzar a expandir el equipo. Luego, yo y otros tres desarrolladores vinimos a la compañía, así que a fines de 2016 éramos siete. Y ahora, dos años después, ya somos más de cincuenta, y el crecimiento continúa.
Si observa los números de la plataforma en sí, entonces ya tenemos más de 400,000 bots conectados. Y estamos creciendo bien en términos de indicadores financieros: en este momento somos una empresa rentable, mientras continuamos buscando inversiones para crecer aún más activamente. El año que viene planeamos duplicar al menos en términos de número de personas.
- Las startups son un campo muy experimental en el que se hace mucho por prueba y error (como el pivote mencionado, cuando comenzamos con un concepto y luego cambiamos sobre la marcha). ¿Cómo afecta esto al desarrollo? ¿Esto significa que siempre debe estar preparado para la situación "la característica que implementó será eliminada"?- De hecho, existe tal cosa que puede hacer alguna función, pero al final no será demandada por los usuarios, tendrá una baja adopción. O puede que no llegue a la producción en absoluto, porque nosotros mismos, mirando lo que sucedió, entenderemos que no nos gusta.
Para minimizar la cantidad de tales situaciones, lo primero en lo que pensamos (ni siquiera durante el desarrollo, sino al comienzo del desarrollo del producto de una característica) es la motivación. Por qué lo estamos haciendo, para quién, cuánto afectará a los usuarios existentes, cuánto nos gusta a nosotros mismos (estaremos contentos y orgullosos de que tal cosa haya aparecido en nuestro producto). Habiendo decidido la motivación, tal vez realizando encuestas en nuestra comunidad de usuarios u otras entrevistas con nuestros usuarios, comenzamos a desarrollarnos. A continuación, preparamos la función para el sprint, tal proceso se llama PBR (Refinamiento de la cartera de productos): primero va a la cartera, luego sube en la clasificación y, en algún momento, ya bien descrito, puede caer en la carrera.
Directamente en el sprint, lo primero que hacemos es que si no entendemos cómo se verá, hacemos algunas maquetas y prototipos. Pero, por extraño que pueda parecer, a veces ya está hecho con el desarrollo. Porque a veces es muy difícil entender cómo se sentirá el usuario con la interfaz, simplemente haciendo algún tipo de diseño e ilustraciones.
Muy a menudo, en la parte frontal, creamos prototipos o características interactivas que, en principio, ya funcionan, puede hacer clic y sentirlos. Y luego, en estrecha colaboración con los diseñadores, llevamos estos prototipos a una opción que entrará en producción. Pero, sin embargo, al crear estos prototipos aquí, tampoco es raro cuando lo haces, miras y te entiendes "no, no se detendrá, es un inconveniente". Intentamos usar nuestro propio producto, hacer bots, de modo que incluso antes de que nuestros usuarios descubran dónde pueden surgir algunos problemas. Bueno, en general, nos enfocamos en la experiencia del usuario, estamos tratando de construir la plataforma más fácil de usar.
- Con el rápido crecimiento de la empresa, probablemente se dé cuenta del hecho de que los procesos que funcionaron para varias personas dejan de funcionar cuando se trasladan a docenas de personas. ¿Cómo ha cambiado su desarrollo desde el punto de vista organizacional?- Fue dificil. A principios de año, tuvimos una situación bastante difícil, cuando realizamos varias funciones durante varios meses, constantemente pudieron "terminarlo un poco y ponerlo en producción", pero esto "todavía un poco" no llegó.
Cuando comenzamos, éramos siete. Teníamos un scrum, había sprints, todo estaba construido y funcionaba lo suficientemente bien. Cuando crecimos hasta 20-30 personas, nosotros, como en muchas compañías, aparecíamos equipos funcionales: backend, frontend. Con sus propios procesos, con sus propios sprints dentro, con sus propias colas de tareas. Y no realizamos tareas que se denominan específicamente "tal y tal característica que traerá tal y tal beneficio a tal y tal usuario". Las tareas de cada equipo fueron llamadas en el espíritu de "frontend: para reorganizar una parte de la interfaz así, agregue algún botón".
Y eso fue malo por muchas razones. En primer lugar, cuando tenemos muchas colas y piezas diferentes de la misma tarea empresarial, tienen prioridades diferentes, se hace casi imposible entender cuándo la tarea estará completamente lista. Y se hace más difícil para un desarrollador específico entender lo que está haciendo. Debido a que hace una pieza descrita para él, y cómo los usuarios se regocijarán por el resultado, no lo sabe, porque puede que ni siquiera sepa mucho por qué esto es necesario.
En algún momento, nos dimos cuenta de que esto es imposible a continuación. Sí, puedes sintonizar un poco, iterar, continuar realizando sprints y stand-ups diarios (que comenzaron a tomar más de media hora, porque fueron atendidos por todo el equipo, pero que no dieron nada). Pero estas son medidas cosméticas que no resuelven el problema principal.
Y en ese momento uno de los muchachos de la compañía nos informó que existía algo llamado LeSS o Scrum a gran escala: un scrum para equipos ya grandes y en crecimiento. Después de sentarse varias noches en las salas de negociación, discutir todo lo que sucede con nosotros, el CEO y el CTO (Mika y Anton) tomaron una decisión comercial muy difícil: tiraremos todo el proceso de desarrollo (cómo diseñamos las características, implementamos y desplegamos) a la basura. Terminaremos el sprint ahora, y luego construiremos todo de nuevo.
La decisión fue difícil, y al darnos cuenta de que estábamos haciendo esto, pensamos durante mucho tiempo: "Maldición, ¿funcionará o no?" Pero decidimos intentarlo de todos modos, recurriendo al libro sobre LeSS y a entrenadores certificados. Comenzaron de una manera nueva, formaron equipos multifuncionales: al principio eran tres. Lanzamos sprints semanales cortos de acuerdo con las reglas de LeSS (reglas en el sentido de qué conjunto de reuniones debería ser en estos sprints). No le diré todos los detalles, pero durante el primer sprint semanal de las ocho tareas que parecen estar pendientes de nosotros que no pudimos implementar durante varios meses, lo hicimos en producción, si no todos, entonces la mayoría. Y simplemente no entendimos lo que estaba sucediendo. ¿Cómo es eso? ¿Por qué no pudimos hacer esto antes? ¿Y por qué sucedió? Fue genial y comenzamos a avanzar, asumir nuevas tareas, resolverlas en equipos multifuncionales mucho más rápido.
Por supuesto, también hubo algunas dificultades y malentendidos. Pero en general, probablemente, para la mayoría del equipo, el proceso emergente es muy popular, ya que el tiempo de comercialización de nuestras características se ha reducido significativamente, puede hacer todo muy rápidamente, implementarlo en producción. Y además de esto, tratamos de transmitir comentarios de nuestros usuarios para que los desarrolladores puedan ver cuánto les gusta a las personas lo que hacen.
Otro punto interesante fue cómo desplegamos la interfaz después de cambiar a LeSS. Nos dimos cuenta de que ahora estamos divididos en equipos multifuncionales separados, y la primera vez (al menos antes de que la comunidad de front-end comience a trabajar), nos comunicaremos mucho menos. Y aprendimos a desplegar la interfaz en cualquier momento "con el clic de un dedo", cuando la necesitamos ... Tuvimos una sola reunión antes del inicio de un nuevo sprint, donde dijimos que tenemos nuestra sucursal principal, y se puede implementar en cualquier momento . Antes de eso, pensé que definitivamente deberíamos construir un sistema de pruebas de IU de integración que verificara cada ensamblaje, que debería haber un gran porcentaje de cobertura, y solo si es "verde" podemos rodar. Pero fue un sueño imposible, porque el producto está creciendo muy rápido y, en este caso, no importa cuánto lo intentes, aún no podrás mantener un gran porcentaje de cobertura. Como resultado, habiendo acordado con todos los desarrolladores y otorgándoles esta responsabilidad, logramos asegurarnos de que ahora el código de nuestra sucursal principal realmente siempre funcione y siempre podamos tomar y desplegar cualquier ensamblaje que necesitemos desde allí.
- Wow, gracias por la respuesta detallada. Me gustaría suponer que, además de la transición descrita, también debería haber una transición de apilamiento completo a una especialización estrecha: cuando solo unas pocas personas hacen todo en el proyecto, uno tiene que hacer varias cosas, y cuando más de cincuenta, todos tienen un círculo claro tareas Es asi?- Cuando éramos pocos, realmente teníamos que resolver muchos problemas de diferentes áreas. Por ejemplo, durante algún tiempo estuve involucrado en la administración del sistema y configuré un sistema de CI. Y ahora, con la transición a LeSS, esto es mucho menos.
Pero esto no significa que ahora todos estén encerrados en roles estrechos. Cuando vienes a la empresa, tienes la competencia principal (ya sea al menos un back-end, al menos un diseñador), y nadie te impedirá bombear esta vertical en particular al espacio, pero al mismo tiempo, LeSS ofrece una oportunidad (solo una oportunidad) para desarrollarse en direcciones relacionadas .
Estamos divididos en pequeños equipos de scrum estándar en los que hay seis (más o menos tres) personas que se reúnen y se sientan al lado de las mesas adyacentes. Esto significa que el front-end siempre puede comunicarse tanto con el back-end como con el diseñador. Además del hecho de que la buena comunicación se construye de esta manera, también puedes aprender de estos tipos. Y damos la bienvenida si la persona que está involucrada en el frente, por ejemplo, para este sprint quiere asumir una pequeña tarea de backend y bombear esta área. Debido a que cuanto más conocimiento tenga de diferentes áreas, más se enfocará en todo el producto y luego podrá resolver mejor sus problemas. Cuando comienzas a entender por qué los diseñadores hacen esto, por qué los expertos en productos lo hacen, a veces puedes comenzar a construir una interfaz tú mismo, que luego simplemente les muestras y dicen "sí, genial". Y, en consecuencia, puede hacer su trabajo más rápido.
- Las startups están a la vanguardia del progreso. ¿Significa esto que al elegir tecnologías puede arrastrar fácilmente algo completamente nuevo a la producción? ¿Y hay alguna precaución para que esto no se convierta en una búsqueda de "cosas nuevas y brillantes" que puedan dañar a las empresas?- La respuesta corta es sí, es posible una supernova, genial e interesante, agradecemos esto en todos los sentidos. Pero, por supuesto, hay ciertos criterios para la introducción de nuevas tecnologías.
Si encuentra alguna tecnología que le interese, entonces debe llevarla a la comunidad. Aunque ya no tenemos un equipo de front-end en nuestra empresa, hay una comunidad de front-end en la que periódicamente nos reunimos y discutimos estos temas. Allí puedes decirle a todos por qué es genial y por qué será más fácil vivir con él en el futuro. Algunas empresas probablemente tienen algún tipo de sistema de selección específico, una tabla complicada con comparaciones que debe completarse. No tenemos nada de eso, todas las decisiones se toman al nivel de algunas sensaciones muy subjetivas, pero al mismo tiempo, aparecen tecnologías realmente buenas e interesantes con la suficiente rapidez.
A veces hay cosas que aún no han llegado al lanzamiento. Comenzamos a usar la biblioteca para crear paneles en React, cuando todavía estaba lo suficientemente crudo, y, por lo que recuerdo, incluso un poco fue donado. Comenzamos a usar Babel 7 con algún tipo de beta, porque nos permitió construir el proyecto un poco más rápido que el anterior.
Y, probablemente, nadie en el equipo se quejó de que quería algo nuevo, pero le dijeron: "No, tenemos esa política, no haremos eso". Y aunque no puedo recordar un solo problema que podría causar ese enfoque, dar la bienvenida a nuevas tecnologías interesantes. Es muy extraño para mí, porque, en mi experiencia previa, tomé muchas decisiones equivocadas a este nivel. Pero en ManyChat, tal vez solo con la ayuda de la comunidad, tal vez por alguna otra razón, no tenemos estos archivos cuando elegimos algo, y luego tuvimos que tomar y reescribir la mitad del código base a otra tecnología, porque este no ha entrado
- Más información sobre el "consejo del progreso": me gustaría suponer que una startup te permite respirar con calma "no tienes que lidiar con un código heredado". Es asi?- Bueno, todos entienden la palabra "legado" a su manera. Si lo entendemos, por ejemplo, como un código de más de tres años, entonces en una empresa menor de tres años, por supuesto, no lo es. Pero puede ajustar este concepto, entonces tendremos un porcentaje de código heredado. Desde el punto de vista de que fue escrito no hace tres años, sino solo hace unos meses, pero entonces no sabíamos cómo hacer algo correctamente, pero ahora hemos aprendido que podemos hacer cien líneas en lugar de mil, y lo harán Lo mismo es aún más confiable. Tal código, por supuesto, es inevitable. Pero no hay nada para lo que tengamos que buscar algún tipo de "desarrolladores barbudos", porque solo ellos conocen este lenguaje de programación y no podemos rechazarlo.
- ¿Cuánto contribuye el desarrollo de inicio a la "construcción de bicicletas"? Mientras que las compañías gigantes están haciendo todo dentro, ¿no estás preparado? ¿O es una startup un lugar en el que todos hacen lo suyo?- Para nosotros, el valor comercial es lo primero. Ya somos rentables, pero si disminuimos la velocidad y comenzamos a perder ante alguien, será muy doloroso. Por lo tanto, si el desarrollo de terceros es consistente con los requisitos comerciales, resuelve problemas comerciales y no tiene grandes problemas, entonces podemos tomarlo y usarlo de manera segura. - - , , . — - .
— , ? , - «»?— , — . , , , , - , - . : , .
. 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 . - - , : , . , , , , . .
— . , , , . - , - ?— , , . , - , . , - , .
: - -, - - , , , . , , . , , - -. , , , , . -, , , , .
