Todos nós imaginamos como é o desenvolvimento em uma grande empresa e como o desenvolvimento pequeno pode diferir dela. Mas o que acontece se o tamanho de uma empresa mudar rapidamente e o número de funcionários aumentar dez vezes em dois anos? Quando uma startup cresce rapidamente e você precisa se adaptar a novas circunstâncias em movimento, como isso afeta tudo (de processos a tecnologias)?
O ManyChat estará participando da nossa conferência HolyJS, que é exatamente o que está acontecendo. Portanto, solicitamos suporte técnico para o desenvolvimento do front-end de
Evgeny Kuvshinov e especificamente sobre o ManyChat, e em geral sobre como é fazer desenvolvimento (front-end) em uma startup.
- Primeiro, conte-nos brevemente o que você faz no ManyChat e o que a própria empresa faz.- Eu vim para a empresa apenas como desenvolvedor front-end, seis meses depois cresci como líder da equipe de front-end. Ainda tínhamos equipes funcionais - frente, verso, teste, produto. E depois que reconstruímos todos os nossos processos no LeSS, retornei ao desenvolvimento e quase não havia tarefas organizacionais anteriores. Estou engajado na experiência do usuário, tento me relacionar com a parte do produto, crescer parcialmente como gerente de produto, mas, ao mesmo tempo, constantemente escrever código.
Como empresa, ajudamos as empresas a usar o relativamente novo canal de comunicação, o Facebook Messenger. ManyChat é uma plataforma para criar rápida e facilmente bots de bate-papo para o Messenger. Não se trata de inteligência artificial, não se trata de tentativas de imitar a comunicação humana, mas de cenários em que isso não é necessário. Com a ajuda de nossos bots, você pode apenas fazer boletins e configurar coisas interativas mais complexas, como pedidos, reservas e programas de fidelidade. Eles também são feitos visual e claramente, e isso pode ser feito por um empresário bastante avançado ou por um profissional de marketing sem habilidades de programação.
Você pode ver como os bots funcionam no Messenger em geral, usando um exemplo específico: em tempo para o HolyJS, criamos um
bot especial .
- Certamente você ouve constantemente as palavras "Mas os bots de bate-papo falharam alguns anos atrás". Sua experiência mostra que, em geral, em um determinado contexto, elas são bastante apropriadas?Sim. Talvez, acima de tudo, a conveniência não seja comprovada nem pelo nosso caso, mas pela plataforma WeChat. Este é um messenger que quase todo mundo usa na China, há muitas empresas nele, e coisas como pedir pizza ou um táxi na China agora estão acontecendo ativamente através do WeChat. E isso mostra que certos cenários interativos de comunicação humana e comercial realmente funcionam bem, é conveniente para ambas as partes.
E aqueles usos que eram exageros há alguns anos - como você pode se comunicar com um bot como pessoa e ele oferecerá a melhor versão de um voo para um avião - bem, isso realmente não funciona muito bem.
E estamos implementando algo próximo ao WeChat, mas em outros mercados: em primeiro lugar, nos EUA, embora em todo o mundo também. Temos um número bastante grande de clientes da Europa e, também em países próximos à China, muitos agora usam o Facebook Messenger.
- Voltando ao tema do crescimento: há quanto tempo a empresa surgiu e como cresceu desde esse momento até os nossos dias?- A empresa apareceu em 2015. Tudo começou com o fato de que seu co-fundador, Mikael Jan, precisava fazer um boletim informativo sobre o Telegram (então ainda não havia canais lá). Ele percebeu que era bastante complicado, e uma ferramenta especial seria útil. Como resultado, Michael e Anton Gorin criaram uma plataforma para a criação de bots no Telegram. A plataforma começou a crescer rápido o suficiente, eles atingiram o acelerador de inicialização no vale.
E enquanto eles estavam no acelerador, o Facebook abriu a API para o Messenger. E foi nesse momento que eles decidiram fazer um giro acentuado, para criar um novo produto especificamente para o Facebook Messenger. A audiência mensal do Messenger é de 1,4 bilhão de pessoas, e no Facebook muitas empresas têm suas representações na forma de páginas oficiais. E para essas páginas você pode criar bots.
Inicialmente, havia três funcionários: Michael, Anton e outro desenvolvedor que criou a primeira versão do frontend. No outono do mesmo ano, os primeiros investimentos foram recebidos e ficou claro que você pode começar a expandir a equipe. Então, eu e três outros desenvolvedores viemos para a empresa, então no final de 2016 éramos sete. E agora, dois anos depois, já existem mais de cinquenta de nós e o crescimento continua.
Se você observar os números da própria plataforma, já temos mais de 400.000 bots conectados. E estamos crescendo bem em termos de indicadores financeiros: já no momento somos uma empresa rentável, enquanto continuamos buscando investimentos para crescer ainda mais ativamente. No próximo ano, planejamos dobrar pelo menos em termos de número de pessoas.
- As startups são um campo muito experimental, onde muito é feito por tentativa e erro (como o pivô mencionado, quando começamos com um conceito e depois mudamos em movimento). Como isso afeta o desenvolvimento? Isso significa que você sempre precisa estar preparado para a situação "o recurso que você implementou será descartado"?- De fato, existe algo que você pode fazer com algum recurso, mas no final não será procurado pelos usuários, terá baixa adoção. Ou ela pode não chegar à produção, porque nós mesmos, olhando o que aconteceu, entenderemos que não gostamos.
Para minimizar o número dessas situações, a primeira coisa em que pensamos (nem mesmo durante o desenvolvimento, mas no início do desenvolvimento de um recurso) é a motivação. Por que estamos fazendo isso, para quem, quanto isso afetará os usuários existentes, o quanto gostamos de nós mesmos (ficaremos felizes e orgulhosos de que algo assim tenha aparecido em nosso produto). Tendo decidido a motivação, talvez por meio de pesquisas em nossa comunidade de usuários ou de outras entrevistas com nossos usuários, começamos a desenvolver. Em seguida, preparamos o recurso para a sprint, um processo chamado PBR (Refinamento do backlog do produto): primeiro ele vai para o backlog, depois sobe na classificação e, em algum momento, já bem descrito, pode cair no sprint.
Diretamente no sprint, a primeira coisa que fazemos é que, se não entendermos como será, faremos alguns modelos e protótipos. Mas, não importa o quão estranho possa parecer, às vezes isso já é feito com o desenvolvimento. Porque às vezes é muito difícil entender como o usuário se sentirá com a interface, simplesmente fazendo alguns tipos de layouts e ilustrações.
Muitas vezes, no front-end, criamos protótipos ou recursos interativos que, em princípio, já funcionam, você pode clicar e senti-los. E então, em um trabalho próximo com designers, levamos esses protótipos a uma opção que entrará em produção. Mas, no entanto, ao criar esses protótipos aqui, também não é incomum quando você faz, olha e se entende "não, não vai parar, é inconveniente". Tentamos usar nosso próprio produto, fazer bots, para que mesmo antes de nossos usuários descobrirem onde podem surgir alguns problemas. Bem, em geral, nos concentramos na experiência do usuário, estamos tentando criar a plataforma mais fácil de usar.
- Com o rápido crescimento da empresa, você provavelmente se depara com o fato de que processos que funcionavam para várias pessoas deixam de funcionar quando se deslocam para dezenas de pessoas. Como o seu desenvolvimento mudou do ponto de vista organizacional?Foi difícil. No início do ano, tivemos uma situação bastante difícil, quando fizemos vários recursos por vários meses, eles foram capazes de "terminar um pouco e colocar na produção", mas esse "ainda um pouco" não veio.
Quando começamos, éramos sete de nós. Tivemos um scrum, houve sprints, tudo foi construído e estava indo bem o suficiente. Quando crescemos entre 20 e 30 pessoas, nós, como em muitas empresas, aparecíamos equipes funcionais: back-end, front-end. Com seus próprios processos, com seus próprios sprints internos, com suas próprias filas de tarefas. E não realizamos tarefas que são chamadas especificamente "tal e tal característica que trarão tal e tal benefício a tal e tal usuário". As tarefas de cada equipe foram chamadas no espírito de "front-end: para reorganizar essa parte da interface, então adicione um botão".
E isso foi ruim por vários motivos. Antes de tudo, quando temos muitas filas e partes diferentes da mesma tarefa de negócios, elas têm prioridades diferentes, torna-se quase impossível entender quando a tarefa estará completamente pronta. E fica mais difícil para um desenvolvedor específico entender o que está fazendo. Como ele faz uma peça descrita para ele e como os usuários se alegram com o resultado, ele não sabe, porque talvez nem saiba de várias maneiras por que tudo isso é necessário.
Em algum momento, percebemos que isso é impossível a seguir. Sim, você pode ajustar um pouco, repetir, continuar executando sprints e levantamentos diários (que começaram a demorar mais de meia hora, porque eram atendidos por toda a equipe, mas que não davam nada). Mas essas são medidas cosméticas que não resolvem o problema principal.
E, naquele momento, um dos funcionários da empresa nos informou que havia uma coisa chamada LeSS ou Large-Scale Scrum: um scrum para equipes já grandes e em crescimento. Depois de passar várias noites nas salas de reunião, discutindo tudo o que estava acontecendo, o CEO e o CTO (Mika e Anton) tomaram uma decisão de negócios muito difícil: jogaremos todo o processo de desenvolvimento (como projetamos recursos, implementamos e implementamos) no lixo. Terminaremos o sprint agora e depois construiremos tudo de novo.
A decisão foi difícil e, percebendo que estávamos fazendo isso, pensamos por um longo tempo: "Porra, vai funcionar ou não?" Mas decidimos tentar da mesma forma, recorrendo ao livro sobre LeSS e aos treinadores certificados. Eles começaram de uma maneira nova, formaram equipes multifuncionais - no início havia três deles. Lançamos sprints semanais curtos de acordo com as regras do LeSS (regras no sentido de que conjunto de reuniões deve haver sobre esses sprints). Não vou contar todos os detalhes, mas, para a primeira corrida semanal das oito tarefas que parecem pendurar em nós, que não pudemos lançar por vários meses, lançamos na produção, se não todas, na maior parte. E nós simplesmente não entendemos o que estava acontecendo. Como assim? Por que não conseguimos fazer isso antes? E por que isso aconteceu? Foi muito legal e começamos a seguir em frente, assumir novas tarefas, resolvê-las em equipes multifuncionais muito mais rapidamente.
Claro, também houve algumas dificuldades e mal-entendidos. Mas, no geral, provavelmente, para a maioria da equipe, o processo emergente é muito popular, porque o tempo de colocação no mercado de nossos recursos foi significativamente reduzido, você pode fazer tudo muito rapidamente, implementar a produção. Além disso, tentamos transmitir feedback de nossos usuários para que os desenvolvedores possam ver o quanto as pessoas gostam do que fazem.
Outro ponto interessante foi como lançamos o frontend depois que mudamos para o LeSS. Percebemos que agora estamos divididos em equipes multifuncionais separadas e, pela primeira vez (pelo menos antes que a comunidade front-end comece a funcionar), comunicaremos muito menos. E aprendemos a implantar o frontend a qualquer momento "com o clique de um dedo", quando necessário ... Tivemos uma única reunião antes do início de um novo sprint, onde dissemos que possuímos nossa filial principal e que pode ser implementada a qualquer momento . Antes disso, eu pensava que deveríamos criar definitivamente um sistema de testes de interface do usuário de integração que verificasse todos os assemblies, que deveria haver uma porcentagem enorme de cobertura e, somente se for "verde", podemos rolar. Mas foi um sonho, porque o produto está crescendo muito rapidamente e, nesse caso, por mais que você tente, você ainda não será capaz de manter uma porcentagem enorme de cobertura. Como resultado, tendo concordado com todos os desenvolvedores e dando a eles essa responsabilidade, conseguimos fazê-lo para que agora o código de nossa filial principal realmente funcione sempre e possamos sempre executar e montar qualquer montagem que precisarmos a partir daí.
- Uau, obrigado pela resposta detalhada. Gostaria de supor que, além da transição descrita, também deveria ocorrer uma transição de “empilhamento total” para uma especialização estreita: quando apenas algumas pessoas fazem tudo no projeto, querendo ou não precisam fazer uma variedade de coisas e, quando mais de cinquenta, todos têm um círculo claro tarefas. É isso mesmo?- Quando éramos poucos, realmente tínhamos que resolver muitos problemas de diferentes áreas. Por exemplo, durante algum tempo eu estava envolvido na administração do sistema e configurei um sistema de IC. E agora, com a transição para o LeSS, isso é muito menos.
Mas isso não significa que agora todos estejam presos em papéis estreitos. Quando você chega à empresa, tem a principal competência (seja pelo menos um back-end, pelo menos um designer) e ninguém o impede de bombear exatamente essa vertical para o espaço, mas, ao mesmo tempo, o LeSS oferece uma oportunidade (apenas uma oportunidade) para se desenvolver em direções relacionadas .
Somos divididos em pequenas equipes de scrum padrão, nas quais há seis (mais ou menos três) pessoas reunidas e sentadas ao lado de mesas adjacentes. Isso significa que o front-end sempre pode se comunicar com o back-end e o designer. Além do fato de que a comunicação legal é construída dessa maneira, você também pode aprender com esses caras. E é bem-vindo se a pessoa que está envolvida na frente, por exemplo, neste sprint, quer assumir uma pequena tarefa de back-end e bombear essa área. Como quanto mais conhecimento você tem de diferentes áreas, mais se concentra em todo o produto e consegue gerenciar melhor seus problemas. Quando você começa a entender por que os designers fazem isso, por que os especialistas em produtos fazem isso, às vezes você pode começar a criar uma interface, que você simplesmente mostra a eles, e eles dizem "sim, legal". E, consequentemente, você pode fazer seu trabalho mais rapidamente.
- As startups estão na vanguarda do progresso. Isso significa que, ao escolher as tecnologias, você pode facilmente arrastar algo completamente novo para a produção? E existem precauções para que isso não se transforme em uma busca de "coisas novas e brilhantes" que possam prejudicar as empresas?- A resposta curta é sim, uma supernova, legal e interessante é possível, congratulamo-nos com isso em todos os sentidos. Mas, é claro, existem certos critérios para a introdução de novas tecnologias.
Se você encontrar alguma tecnologia que lhe interessa, precisará trazê-la para a comunidade. Embora não tenhamos mais uma equipe de front-end em nossa empresa, existe uma comunidade de front-end na qual periodicamente reunimos e discutimos essas questões. Lá, você pode dizer a todos por que é ótimo e por que será mais fácil viver com ele no futuro. Algumas empresas provavelmente têm algum tipo de sistema de seleção específico, uma tabela complicada com comparações que precisa ser preenchida. Não temos nada disso, todas as decisões são tomadas no nível de algumas sensações muito subjetivas, mas, ao mesmo tempo, tecnologias realmente boas e interessantes aparecem com rapidez suficiente.
Às vezes, existem coisas que ainda não chegaram ao lançamento. Começamos a usar a biblioteca para criar painéis no React, quando ele ainda estava bruto o suficiente e, tanto quanto me lembro, até um pouco foi doado. Começamos a usar o Babel 7 com algum tipo de beta porque nos permitiu construir o projeto um pouco mais rápido que o anterior.
E, provavelmente, ninguém na equipe jamais reclamou que queria algo novo, mas eles disseram a ele: "Não, temos uma política assim, não faremos isso". E embora eu não consiga me lembrar de um único problema que causaria essa abordagem, recebi novas tecnologias interessantes. É muito estranho para mim, porque, na minha experiência anterior, tomei muitas decisões erradas nesse nível. Mas no ManyChat, talvez apenas com a ajuda da comunidade, talvez por algum outro motivo, não temos esses arquivos quando escolhemos algo e, em seguida, tivemos que pegar e reescrever metade da base de código em outra tecnologia, porque este não entrou.
- Mais informações sobre a "dica do progresso": quero supor que uma startup permita respirar calmamente "você não precisa lidar com um código legado". É isso mesmo?- Bem, todo mundo entende a palavra "legado" à sua maneira. Se queremos dizer com isso, por exemplo, um código com mais de três anos, em uma empresa com menos de três anos, é claro que não. Mas você pode reforçar esse conceito, pois teremos uma porcentagem do código legado. Do ponto de vista de que foi escrito não há três anos, mas apenas alguns meses atrás, mas não sabíamos como fazer algo corretamente, mas agora aprendemos que podemos fazer cem linhas em vez de mil, e elas farão o mesmo é ainda mais confiável. Esse código, é claro, é inevitável. Mas não há nada pelo qual precisaríamos procurar alguns "desenvolvedores barbudos", porque apenas eles conhecem essa linguagem de programação e não podemos recusá-la.
- Quanto o desenvolvimento de uma startup contribui para a "construção de bicicletas"? Enquanto empresas gigantes estão fazendo tudo por dentro, você não consegue? Ou uma startup é apenas um lugar onde todos fazem suas próprias coisas?- Para nós, o valor do negócio vem em primeiro lugar. Já somos lucrativos, mas se desacelerarmos e começarmos a perder para alguém, será muito doloroso. Portanto, se o desenvolvimento de terceiros for consistente com os requisitos de negócios, resolver problemas de negócios e não apresentar grandes problemas, poderemos utilizá-lo e usá-lo com segurança. - - , , . — - .
— , ? , - «»?— , — . , , , , - , - . : , .
. 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 . - - , : , . , , , , . .
— . , , , . - , - ?— , , . , - , . , - , .
: - -, - - , , , . , , . , , - -. , , , , . -, , , , .
