Falei com os fundadores da startup ElectroNeek: Sergey (CEO), Dmitry (CIO) e Mikhail (CTO). No final da entrevista - um vídeo onde o robô está sendo montado ao vivo.
- Dmitry, por favor mande uma foto para o KDPV, onde vocês estão todos juntos.
- Acredite ou não, não nos encontramos muito em dois anos ainda)
A ElectroNeek desenvolve um ecossistema de produtos de software que podem ser usados para criar robôs que repetem qualquer ação de funcionários de escritório em um computador com qualquer aplicativo instalado nele. Assim, é possível robotizar total ou parcialmente os processos na empresa. A ElectroNeek se especializou em trabalhar com integradores de sistemas e equipes de TI criando centros de competência RPA, ou seja, seus produtos são voltados para quem desenvolve robôs em grande número, e não resolve vários problemas específicos de automação local.
RPA (Robotic Process Automation) é uma tecnologia que ajuda a automatizar tarefas diárias e repetitivas. O RPA permite que você literalmente emule as ações de um usuário comum em um computador. Você passou o mouse sobre o botão e clicou, depois inseriu o texto com o teclado e pressionou "Enter". Isso é exatamente o que RPA é. Conforme a demanda aumentou, os fornecedores de RPA começaram a desenvolver suas soluções para fornecer mecanismos de automação mais flexíveis. Existem integrações com linguagens de programação, com tecnologias como OCR, eles estão pensando seriamente em introduzir o aprendizado de máquina. Os robôs agora podem ser lançados simultaneamente, em uma programação, remotamente, etc. Exemplos de casos: um , dois , três , quatro, cinco .
- O que é um robô?
Mikhail: A robotização é uma emulação de uma pessoa. Uma pessoa pode ser imitada em diferentes formas. Você pode fisicamente. O robô anda como um humano. O robô clica no monitor como um humano. Digitando como um humano. Nunca existe uma emulação humana completa. Mas o aspecto da emulação humana é a robotização.
- Mikhail, o Yandex te caçava, mas você ainda decidiu trabalhar na ElectroNeek, qual a sua motivação para trabalhar em uma startup, e não em um emprego garantido e caloroso?
Mikhail: Quando você trabalha em uma startup, você mesmo é o ferreiro de sua própria felicidade, mas na empresa você é limitado.
- Michael, como você foi pego?
Mikhail: Naquela época, eu já havia saído de Akronis por um ano, parei de ver meu vetor de desenvolvimento, queria estudar diferentes tecnologias, fiz projetos de estimação. Eu queria fazer algo meu e estava procurando uma equipe. Nesse ínterim, Dimitri e Sergei estavam procurando um CTO e gritaram com seus conhecidos. Eu conhecia Dmitry da universidade, embora não nos comunicássemos muito, então nos reunimos. Eu estava pronto para esta proposta.
Eu precisava entender se acredito ou não no projeto. Nós nos encontramos com Sergei em um café, ele descreveu muito superficialmente o que é Electroneek e, após a reunião, estudei independentemente o tópico RPA com mais detalhes, olhei para os concorrentes.
Voltamos a telefonar, já eram três. Sergey e eu estávamos sentados um ao lado do outro, e Dmitry estava na América naquela época. Conversamos sobre o produto, como eles o veem, onde pretendem desenvolver, para quem é, como vamos nos destacar e porque existe “mais um construtor de robôs” no mercado.
Vi que há demanda, pelo menos na Rússia. Dmitry falou sobre o mercado global, em particular sobre os Estados Unidos. Ele já trabalhou na Ernst & Young e dirigiu RPA para empresas Fortune 500 lá, então ele conhecia bem a demanda.
Sergey e Dmitry decidiram se diferenciar dos concorrentes com uma UX simples e conveniente, para tornar a robotização mais acessível para empresas de qualquer tamanho. Eu precisava saber se meus co-fundadores em potencial entendem como será a interface, qual é exatamente o seu aspecto legal. Ouvi a resposta honesta "Não sabemos". Os caras no momento não sabiam exatamente o que deveria ser, mas planejavam tentar descobrir.
Essa honestidade e franqueza eram importantes para mim. Eu gostei que eles fossem honestos sobre a situação. Isso é importante para relacionamentos futuros. Dizer tudo como é, e se a pessoa for adequada, ela vai entender. Quando você é honesto, se uma ombreira sair em algum lugar, você pode imediatamente ver como resolver o problema, independentemente de quem fez a bagunça.
- Como era o Electroneek antes de você entrar no projeto?
Michael:Antes de mim, havia um protótipo funcional que poderia ser mostrado. Foi um projeto no GitHub para mostrar o que eles estão prestes a fazer.
Quando cheguei, eles me mostraram um protótipo, falaram sobre os concorrentes, sobre as tarefas que precisavam ser resolvidas e pediram para fazer bem . Não no joelho, mas por muito tempo, para que possa se desenvolver. Mas não havia tempo para sentar por muito tempo para se desenvolver, era preciso ir para a batalha mais rápido. Era preciso correr para os clientes, era preciso atrair dinheiro. Portanto, desde os primeiros dias comecei a escrever código. Eu já estava familiarizado com o Electron naquela época. (Electron é uma estrutura que permite escrever aplicativos de desktop usando a pilha de tecnologia da web.)
- O que torna o desenvolvimento de um produto RPA diferente do resto?
Sergey:Qual é a diferença entre o desenvolvimento de uma plataforma RPA e um produto "em si"? A plataforma RPA, em particular ElectroNeek, é uma ferramenta de desenvolvimento. Um meio de criar algo interagindo com algo terceiro. Este não é um produto separado como o CRM, que por si só e apenas às vezes por meio da API interage com outra coisa.
Um usuário baseado no ElectroNeek cria uma solução de software (robô) que irá interagir com outros produtos que estão em constante mudança: navegadores, desktops. Você não controla o ambiente com o qual o resultado do desenvolvimento irá interagir. Isso impõe enormes demandas de qualidade, experiência do usuário e desenvolvimento de soluções de produtos.
- Por que outro produto RPA no mercado?
Sergey:as pessoas costumam nos procurar e dizer: "Por que você está desenvolvendo quando pode ir a algum site, baixar um módulo clicker RPA pronto e fazer?" Sim, ele pode abrir um notebook, se familiarizar com um Internet Explorer, abrir o Google. Mas assim que você for além (assim que XPath ou seletores aparecerem), diferentes variantes de sites, governo ou ecossistemas SaaS, você enfrentará o fato de que não está pronto e não funciona. E então, se você está desenvolvendo sua própria plataforma, você precisa se adaptar às mudanças e, se tudo já estiver conectado, você não poderá se adaptar às mudanças de forma flexível. Tínhamos no piloto.
- Como você escolheu a pilha de tecnologia?
Michael:O projeto implicava que haveria um desktop e uma web-part, uma frente clássica, um verso clássico e um aplicativo de desktop. E no início o projeto não envolvia uma grande equipe. Compreendi que nos primeiros meses estaria sozinho, não planejávamos expandir em um ritmo grandioso.
Eu precisava fornecer algum tipo de estação múltipla para que 1-3 pessoas pudessem fazer tudo. É por isso que escolhemos Electron. Ele permite que você escreva um aplicativo de desktop, back-end e front-end na mesma linguagem (temos TypeScript).
No futuro, você pode fazer especialização, mas no início é muito conveniente quando todos podem fazer tudo.
Como regra, há um problema de alternar o contexto do back-end para o front-end. Por exemplo, apoio em python, frente em JavaScript, combinação popular. E mesmo que uma pessoa combine isso em si mesma, será caro e difícil para ela mudar de um idioma para outro. E quando você resolve um problema, você muda frequentemente, não é conveniente. Nós nos livramos disso, nada muda ao alternar: um idioma, uma abordagem, até mesmo tudo parece o mesmo.
Procurei então bibliotecas que pudessem fechar imediatamente algumas das minhas tarefas e não tentei escrever tudo sozinho.
No início, você não precisa tentar algo de bicicleta. Leve já pronto, se atender às suas necessidades. Talvez então você realmente precise retirar esta peça e substituí-la pela sua. Mas, ao mesmo tempo, você terá imediatamente uma peça de trabalho.
Peguei uma biblioteca pronta para visualização. Nosso principal produto é um ambiente de desenvolvimento, e há uma visualização de fluxograma. Naturalmente, eu não o escrevi, mas peguei a biblioteca joinjs de código aberto. Ele permite que você trabalhe no nível SVG. Desenhe interfaces usando imagens vetoriais.
Estamos sentados nele há muito tempo. Às vezes pensamos que vamos nos livrar dela, isso pode ser feito a qualquer momento, mas até agora ela está realizando todas as tarefas e segurando a carga.
É importante escrever tudo de maneira modular para que você possa jogar fora algumas partes e não se confundir com sua própria teia de código. A abordagem modular permite que você se livre rapidamente das bibliotecas.
Nosso programa não é apenas um editor de fluxograma, ele resolve um problema específico - ele automatiza a área de trabalho. Você o usa para gerenciar aplicativos de desktop.
Uma parte importante do nosso programa é uma biblioteca de baixo nível para interagir com os aplicativos, como pressionar um botão, contar uma imagem, criar uma captura de tela.
Peguei a biblioteca C # padrão UIAvtomation, que também era usada por nossos concorrentes naquela época. Recentemente, substituímos por um mais moderno.
Essa biblioteca tinha um wrapper, uma API bastante estreita que usamos. Então, fomos capazes de descartar esta biblioteca, anexar uma nova e colá-la com um adaptador a esta API. Acontece de forma rápida e indolor, e deve ser feito.
- Como os recursos foram implementados?
Mikhail: Conversei com os cofundadores, eles tinham experiência em integrar a solução de um concorrente, eles entenderam quais recursos eram necessários. Eles me deram uma lista de recursos que usaram muito. Comecei a fazer um por um.
Literalmente um ou dois meses depois, começamos a fazer um projeto piloto para o Russian Post.
Resolvemos o problema da automação de descarregamento para eles. Eles tinham um aplicativo desktop de RH para gerenciamento de currículos. Não havia interface e você tinha que tirar todos os currículos de lá. Não havia API, nem banco de dados, e eles não podiam retirá-los.
Apenas clicamos neste aplicativo, retiramos os dados de lá e os colocamos no disco.
A solução principal não foi difícil, escrevi o algoritmo em poucas horas, mas o diabo está nos detalhes. Muitas nuances: documentos de diferentes tipos, alguns tipos de campos podem não existir, etc. Passei mais algum tempo terminando.
Para cada recurso, eu me perguntei qual solução preciso agora para que no futuro eu possa resolver problemas desse tipo. Se um recurso passou neste filtro, eu o adicionei. No início, os recursos são adicionados sem muita discussão. A base de código é pequena, adicionada, experimentada, removida, é fácil.
Quando o aplicativo já é grande, cada recurso precisa de uma discussão. O que o recurso afetará, se ele quebra algo e se temos outra maneira. No início são fáceis de ver as características, não partem nada, porque ainda não há nada a partir.
- Qual foi a escala do trabalho para o Russian Post?
Mikhail: O aplicativo continha todos os funcionários dos Correios russos em todo o país. É impossível gritar com as mãos.
O que nosso robô estava fazendo. Ele entrou em uma pesquisa com filtros vazios. O resultado é uma lista de todos os funcionários com rolagem em várias telas. Você precisa clicar em cada elemento da lista na planilha, uma janela se abre, há uma parte dos dados e vários botões que abrem outras janelas. Todas as janelas tiveram que ser abertas, todos os dados tiveram que ser costurados, as janelas tiveram que ser fechadas novamente e ir para o próximo item na lista. E com essas iterações para roubar tudo. Aqui está um resumo aproximado do processo.
O piloto era mutuamente gratuito e não o colocamos no estado de produção. Para nós mesmos, fizemos uma prova de conceito: na plataforma você pode resolver esses e aqueles problemas, você pode ir com isso para arrecadar dinheiro, você pode vender para os clientes e terminar em movimento. Isso é o que começamos a fazer.
- Como você atraiu investimentos?
Michael:Precisávamos de um protótipo funcional que impressionasse os investidores. A interface da solução para Russian Post não era bonita, foi feita por mim, e eu não sou designer. Eu criei para mim o modo IDE WebStorm Dark.
Os primeiros estágios do protótipo
ElectroNeek em 2021
Os investidores sabem como usar a imaginação. Você pode mostrar a eles um protótipo torto e dizer como ele mudará e eles entenderão. O protótipo pode até ter muitos bugs, mas o principal é mostrar um grão de significado para que o investidor possa captar a essência. O cliente precisa mostrar um produto pronto e bonito. Pessoas adequadas entendem a diferença entre um MVP e um produto final. E é melhor não trabalhar com inadequados. Você leva investidores há muito tempo, é agradável trabalhar com pessoas adequadas.
- Como foram as demonstrações para investidores?
Michael:Digamos que eu escrevi uma nova funcionalidade e amanhã de manhã ela precise ser demonstrada aos investidores. Eu entendo que não pode ser mostrado neste formulário. Talvez algo esteja sendo conectado, talvez não haja um bom exemplo para mostrar a funcionalidade. Eu sento lá terminando a noite, inventando exemplos, pegando insetos para que pareça bom de manhã. De manhã venho sem dormir para a demonstração. Mostro o produto aos investidores. Quase sem dormir, mas com sucesso.
No início, não há maneira sem ele. Não há processo de desenvolvimento normal quando há um ambiente de desenvolvimento completo, ambiente de teste, classificação e produção. Existe apenas um ambiente, é tanto para você em pé quanto para a produção. Você é o único e sua tarefa é fazer isso mais rápido. E você trabalha como um cirurgião que acabou de se preparar para a operação e "abriu" o código, e eles falam para ele: "Bom, vamos costurar mais rápido e vamos lá."
Eu tinha que fazer tudo e acompanhar. Enquanto a aplicação é pequena, cabe bem na cabeça, um bom desenvolvedor é capaz de fazer tudo sozinho e não perder nada. Quando o aplicativo cresce, não é mais possível ficar sem QE.
Sergei: Tínhamos recursos limitados, recebíamos apenas 150.000 dólares, dos quais 70.000 em dinheiro, bastava para terminar o protótipo em um produto normal e mostrar as primeiras vendas na Rússia e nos EUA. Em seguida, eles levantaram US $ 0,5 milhão. Mostramos vendas rápidas. Os investidores acreditaram em nós.
Michael:Assim que apareceu o dinheiro, começaram a ampliar a equipe para fazer um bom produto o mais rápido possível. O que significa "bom"? Você não precisa de um produto perfeito desde o início, embora possa ser feito. Isso é um engano. Muitas pessoas sabem fazer isso perfeitamente, mas leva muito tempo. Se rápido e bom, então muito caro. Tudo é impossível de uma vez. Assim, ele deve ser feito bem o suficiente aqui . Bom o suficiente para vender.
Você pode criar um produto com bugs, se eles não forem críticos, não atire na perna, e você pode adicionar recursos mais rápido. As pessoas compram um produto com bug, veem um bug, um relatório sobre isso, a gente conserta aí mesmo. As pessoas veem feedback. Não tem problema.
- Como você contrata desenvolvedores?
Michael:Eu me concentro mais na habilidade do que na experiência. A experiência é importante, mas o desenvolvimento é algo em que você precisa aprender algo constantemente. Quando você tiver que arrastar uma nova biblioteca para o projeto, a probabilidade de saber que ela é não será muito alta. O conhecimento básico é importante. Precisávamos de conhecimento de TypeScript, demorou muito tempo para retreinar em outra linguagem. A estrutura é desejável saber. Estamos usando do Angular.
É importante para nós que uma pessoa possa resolver rapidamente um problema complexo sem erros, ou com erros fáceis de corrigir, que surgirão durante a execução. Uma pessoa deve ser capaz de pensar muito. Se ele for capaz de pensar muito, para entender que tipo de casos extremos existem em geral, então isso é legal.
Muitas vezes acontece que as pessoas escrevem um programa, mas simplesmente não pensam em alguns casos. E quem ele vai pensar deles? O controle de qualidade também pode não pensar neles. E então eles atiram. Ao mesmo tempo, os dados iniciais são suficientes para prever esses casos extremos. Para mim, essa é a diferença entre um desenvolvedor promissor e um pouco promissor: quantos casos difíceis no início ele é capaz de antecipar.
- Quantas pessoas estão aí agora?
Mikhail: Seis pessoas - desenvolvimento central, que fazem a plataforma diretamente. Quatro pessoas que estão notornar as soluções reutilizáveis da plataforma. Eles usam a plataforma, além de ferramentas adicionais em linguagens de script, e fazem projetos específicos. Estou falando apenas de desenvolvedores agora. Há também um departamento de QA, uma equipe de produto separada.
- Como você mudou de codificação para responsabilidades gerenciais como um CTO?
Mikhail: Depois de receber o investimento, estive ativamente escrevendo código por vários meses. Embora tivéssemos contratado o controle de qualidade, eu não tinha muita certeza deles. Eu mesmo escrevi a revisão do código.
Então eu vi no quadro kanban que eu era um pescoço estreito. E eu entendo que é hora de largar as rédeas, de aceitar que os problemas vão passar por mim na produção.
Eu revi as coisas mais críticas. Começou a confiar no controle de qualidade. Foi um processo gradual de abrir mão do controle. Quando você passa tudo por você, tem certeza do resultado. Você vê tudo, pode resolver todos os problemas sozinho. Mas esta não é uma história escalonável. Ela é boa no início, então você precisa se livrar dela às escondidas. Então, eu gradualmente me desliguei, revisei apenas os pontos críticos e então parei de escrever e revisar completamente. Agora todo mundo está fazendo isso sem mim.
- Agora que você aceitou a queda na qualidade, o que vem a seguir?
Mikhail: Olha, não tenho mais a opção de revisar o código, já passamos por isso. O que mais eu posso fazer? Agora você pode ajustar as coisas do processo.
Digamos que os desenvolvedores mesclem recursos de qualidade não muito alta no branch principal. Provavelmente, algo está errado com a revisão. Veremos. Você observa o que as pessoas estão revisando. Aha, para chamar a atenção da galera para isso. Você vai para as instruções. Processos de depuração. Procurando pontos fracos. Você não tenta trabalhar, você cria processos.
É aqui que os desenvolvedores revisam, mas os recursos ainda não estão muito mesclados. Vamos adicionar um teste de recurso antes de mesclá-lo. Adicionado. O que aconteceu? Agora, o QA não tem tempo para testá-los. Ok, provavelmente nem todos os recursos precisam ser testados dessa forma, mas apenas os mais perigosos que afetam todo o projeto. Você está se equilibrando
Não existe um modelo para empresas diferentes, mas a abordagem geral é a mesma - para testar seu sistema e consertar gargalos de maneira processual. Então, já é uma história escalável.
Minha tarefa é encontrar o gargalo onde está o problema do processo, conversar com as pessoas e implementar uma solução de trabalho.
Idealmente, se eu me afastar, tudo funcionará. É impossível no início. Afaste-se, tudo está quebrado. E agora deve ser que eu me afastei por um mês e nada quebrou.
- Como saber quando contratar uma pessoa especial?
Mikhail: Existe o suficiente para este pescoço estreito de um homem? Se uma pessoa estiver pelo menos 70% ocupada com essa tarefa, você poderá contratar. Se você precisa de uma pessoa 5% do tempo, provavelmente você mesmo pode cuidar disso.
- O que você está fazendo agora?
Mikhail: Ainda estou no comando dos processos. E vou lidar com eles por muito tempo.
Estou discutindo recursos, como Sergey. É aqui que nosso produto cresce. Ele passa por seu próprio prisma, eu, pelo meu.
Somos desenvolvedores escrevendo uma ferramenta de desenvolvedor. Não sou capaz de acompanhar todos os recursos que fazemos, mas analiso os importantes, complexos, críticos ou interessantes e dou feedback para a equipe de produto, que otimizará o recurso com base nele. Não estou no negócio de descrever, mas de ouvir o que eles vão fazer e dar feedback. Sergey está fazendo o mesmo em termos de recursos. Isso é algo que definitivamente não vamos abandonar. É importante entender para onde o produto está se movendo, para onde o estamos desenvolvendo.
- Como você estuda?
Michael:Em primeiro lugar, declaro o problema claramente. A experiência de vida já permite que você decida muito. Já sei muito mais do que quando me formei na universidade, mas ainda há problemas que não sei resolver.
Primeiro, descubro qual é o problema. Digamos que eu não tenha algum tipo de ferramenta. Eu procuro no Google, assisto o YouTube ou algum curso, descubro como os profissionais de uma determinada área fazem.
Por exemplo, como você testa aplicativos grandes quando há muitos testes manuais? Não temos tempo, o que fazer?
Se você não foi um bom controle de qualidade no passado, indiretamente entende o que é o quê, mas pode não conhecer algumas nuances. Abro o YouTube, ouço uma palestra de controle de qualidade de uma hora com muitos anos de experiência, entendo que o que ouvi pode ser aplicado, tento, analiso. Se servir, eu deixo.
É impossível saber tudo. A tarefa de qualquer gestor é aprender tudo o que for possível, delegar e de forma a reter a função de controle.
Defina a estrutura em que as pessoas trabalham e controle o resultado dentro dessa estrutura. Eles tomam decisões por conta própria.
Se houver um problema no mercado, a decisão pode ser tomada sem mim. O controle de qualidade diz que a tarefa é crítica e pode decidir reverter. Eu não preciso acordar para isso. O principal é que as pessoas entendam a estrutura.
- Conselhos para si mesmo na sua juventude?
Michael:No início parecia-me que no início tinha que aprender muito. Algo que ainda não sei. Não consigo escrever um site, não consigo escrever um back-end. Queria primeiro fazer um curso ou terminar uma universidade. Na verdade. Pegue e experimente. O Google é uma ótima ferramenta, tudo está lá. Resolva problemas pontualmente. Você não sabe como para fazê-lo especificamente, e aprender a fazer isso especificamente . Você não sabe como configurar o nginx, então estude isso especificamente.
Você não pode aprender tudo. É muito demorado fazer um curso de programação de várias semanas. Melhor começar a programar. Aqueles problemas que surgirão para você e os resolverá. É mais rápido assim. E ainda mais imerso no problema do que lendo um livro. Se você ler 600 páginas de capa a capa, o conhecimento será superficial. O conhecimento é mais profundo na experiência.
Eu "descobri o Google" no sentido de que posso, com meu conhecimento, fazer coisas complexas no Google e encontrar soluções pontuais para plugues. Foi assim que me desenvolvi no futuro.
Eu leio livros seletivamente. Quando estava resolvendo um problema, encontrei um fragmento que descreve a solução. Os artigos são iguais. Você também não pode assistir às palestras na íntegra. As aulas teóricas são de 4 horas. Encontre o código de tempo, basta olhar a parte interessante, pode ser o suficiente.
- Conte-nos sobre os Controles de Organização de Serviço (SOC)?
Sergey: Se você deseja fazer um aplicativo SaaS no mercado americano, especialmente algo que funcione em empresas com mais de 200-500 pessoas, a questão sobre o SOC (Security Organization Control) surgirá imediatamente. Enquanto você não o tem, todos perguntam a ele. Esta é uma história que penteia as políticas da organização, a distribuição por nível de direitos e acesso, como desenhar o código, os auditores vêm e verificam.
Até que você tenha, todos os clientes normais pedem e não assinam o contrato. Assim que aparece, e você diz “aqui está, se você quiser mandar denúncia”, o cliente responde que não é necessário, “não queremos ler a denúncia”.
Leva quatro meses, é colocado em ordem e está sendo verificado. Um conjunto de atividades que afeta toda a pilha de tecnologia. Michael pode dizer, ele conduziu esse processo completamente.
Mikhail: Somos uma organização que presta serviços a clientes. O SOC trata das ferramentas que temos dentro de nós para garantir a segurança, disponibilidade e continuidade do serviço e a segurança dos dados. Todas essas coisas que interessam a grandes clientes e pouco a pequenas organizações.
Se nosso cliente for uma grande organização, a falta de SOC pode ser um problema para eles. Seus regulamentos não permitem trabalhar com você. Portanto, em um determinado momento ela veio à tona para nós.
Ou você tem essa certificação, SOC (ainda é caro para uma startup), ou a empresa lhe envia um questionário de várias páginas sobre como você está seguro. Você lê e não entende a metade.
Você pode encher por muito tempo, porque logo de cara, nem sempre fica claro do que se trata o discurso. Além disso, enquanto você preenche, você entende que não temos isso. E este não é o caso. E isso também não está lá. E não adianta enviar este questionário. E não parece tão difícil fazer essas coisas acontecerem. Mas isso deve ser feito.
Em algum momento, percebemos que tais clientes vêm até nós, a gente preenche seus questionários há muito tempo, mas como resultado da transação não tem. Decidimos lidar com esse problema.
Esta certificação é um processo contínuo de monitoramento. Não que você tenha feito isso uma vez e pronto. Você tem que colocar alguns tipos de "caixas de seleção" regularmente. Seus dados são sempre criptografados durante a transmissão. Você tem dados que estão sempre criptografados nos servidores, caso eles desapareçam em algum lugar do disco rígido, ninguém vai tirar nada de lá. Existem muitos exemplos desse tipo e outros mais sofisticados também.
Quando você começa a pesquisar no Google como fazer isso, você encontra uma folha A4 de 60 folhas, o que fazer e como fazer. E cada ponto precisa ser desmontado, porque você não entende. Parece um trabalho muito longo.
Ok, esse é o caminho que seguiremos por muito tempo. Ou talvez possamos encontrar uma empresa que tornará nossa vida mais fácil? Nossa empresa. Naquela época, já estávamos no Y Combinator. Fizemos essa pergunta para os caras de lá, fomos solicitados por ex-alunos do YC que irão automatizar essa história. O serviço não é gratuito, mas compramos um serviço deles. Este é algum tipo de painel de administração no qual você integra todos os seus serviços. JetSuit, Bitbucket, Gitlab, Jira, AWS, Azure, quem tem o quê. O próprio programa estuda onde você tem quais configurações e diz quais e onde você está faltando. Você corrige pontualmente e todos os itens nesta planilha são fechados automaticamente.
Em seguida, um auditor é convidado, que confirma que tudo realmente está lá e faz um “teste”. É assim que simplificamos nossa vida.
Para as grandes empresas, trata-se de uma formalidade, sem a qual não poderiam ir mais longe e colaborar connosco. Bem, como uma vantagem, um aumento real na segurança do cliente.
- Conte-nos sobre o Y Combinator através dos olhos de um desenvolvedor?
Mikhail: Eu realmente não entendia para que servia YC. Estava claro que isso era prestígio. E o objetivo específico era difícil para mim entender. Eu li sobre como pode estar lá. Era difícil para mim imaginar que tipo de experiência útil alguém poderia ter ali. Eu estava bastante cético quanto ao fato de que iria melhorar como profissional. Mas entendi que esse foi um marco útil para a empresa como um todo.
Se falarmos sobre o resultado. Temos mais benefícios comerciais. Eles também ajudaram com recursos técnicos e continuam ajudando. Fizemos uma infraestrutura mais correta na nuvem.
A principal lição dessa história é que, se você estiver pronto para usar os produtos que a YC oferece, pronto para se aprofundar em seu entendimento, isso será uma grande vantagem.
Terminamos o YC em março de 2020, fechamos a rodada com US $ 2,5 milhões. Um crescimento significativo da equipe de desenvolvimento e das tarefas começou.
- Como você chegou à equipe de produto atual?
Mikhail: Nossos produtos são bastante complexos, você precisa ser um desenvolvedor para entender um produto para desenvolvedores. Você precisa entender do ponto de vista do desenvolvedor quais recursos implementar, como nossos clientes os utilizam. Por outro lado, vale a pena ser um bom empresário, um pesquisador de mercado. Combine todas essas competências. Existe alguma dificuldade com isso.
Sergey:Nos últimos 4-5 meses, de março a agosto, contratamos pela primeira vez um gerente de produto com experiência em RPA. Trabalhamos com ele por vários meses e não obtivemos nenhum resultado. Não contratamos um gerente de produto da série “Vamos contratá-lo e o ouro jorrará imediatamente”, queríamos chegar a um entendimento claro de quais recursos estamos fazendo, eles são necessários para capturar o mercado futuro, para resolver problemas específicos do cliente, para upsell. Pegamos o produto por métricas bastante mensuráveis e o discutimos. Infelizmente, ambos os produtos estavam rolando. A culpa também é nossa. Contratamos pessoas que se ofereceram para fazer o longa, "porque é lindo". Quanto dinheiro ela vai trazer? Bem, é difícil contar ... Quem ela vai ajudar? Como isso pode ajudá-lo a ganhar negociações atuais, ou pelo menos não perdê-las? Não conseguimos construir tal história.
Com o que acabamos. Um esquema super confortável para nós, que impulsiona muito a nossa empresa.
Temos um gerente de produto UX, um gerente de produto de tecnologia, temos um chefe de engenharia, temos um CTO e temos um CEO como representante comercial. Formamos uma mercearia onde o produto é “cortado” em diferentes partes. UX, análise de novos recursos, engenharia. Mikhail e eu desempenhamos o papel de facilitadores no caso de priorização. Também sou responsável pelos recursos de vendas. Dmitry analisa como os recursos do produto são ou podem ser traduzidos em oportunidades e ferramentas de marketing, como nossa biblioteca global de bots criada por clientes e parceiros.
Temos sessões espontâneas para discutir assuntos sérios. Também temos uma teleconferência semanal de hora e meia onde planejamos o próximo sprint, que já foi priorizado dentro da empresa. Novos recursos surgem em três trilhas: bugs - corrigimos algo que não funciona, retarda a venda ou interfere nos clientes atuais; UX - corrigimos o atual, pois sabemos que o produto sempre pode ser melhorado; adicionamos algo novo ao produto, o que nos permitirá ser mais eficazes no futuro. Trabalhamos em tal estrutura. Gostaríamos de falar com uma pessoa que esteja envolvida em todo o produto, mas até agora parece-nos difícil.
Eu gostaria de aconselhar futuros empreendedores, especialmente técnicos, a não considerar apenas uma opção (que o CEO deve encontrar um product owner), mas que existe um formato de interação distribuída que dá um resultado.
- É possível com a ajuda do seu robô fazer farm em jogos de computador, clica no YouTube?
Dmitry: Em nossa base, um cliente fez um robô que liga a chaleira.
Sergey: O robô pode pressionar qualquer botão. Oferecemos uma ferramenta de desenvolvimento. O que os clientes constroem é responsabilidade das pessoas. Você pode construir o que quiser.
Sergey:Tínhamos uma história. O cliente comprou o serviço e escreveu: “Eu escolhi especificamente a garota menos desenvolvida na direção de TI de nossa empresa, a Olya. E assim "Olya" foi capaz de criar um robô com a ajuda do ElectroNeek. Se "Olya" pode fazer isso, então qualquer pessoa na minha empresa pode. Estou comprando um produto de você! " Este é um alto indicador de facilidade de uso. Embora a maioria dos desenvolvedores juniores ou intermediários nos usem. Eles recebem um produto, em qualquer stack (web, desktop, tem API ou não), criam um aplicativo (um robô?), Essa é a liberdade que nosso produto dá.
Dmitriy:Quando um produto chega aos investidores em um estágio inicial, a história com Olya se repetia lá, há Oli entre os investidores. Houve situações em que parceiros dos principais fundos americanos entraram no produto (Gary Ten da Initialized, um ex-parceiro YC e investidor da Coinbase e Instacart). O parceiro começou a montar o robô com as mãos.
Bônus: coletar um robô ao vivo
Consulte Mais informação
- Lançamento HN: ElectroNeek (YC W20) - Encontre e automatize automaticamente o trabalho de rotina
- Como quatro russos criaram uma fábrica de "funcionários digitais" e ganharam US $ 1 milhão com ela
- electroNeek RPA - robôs de software ajudam pessoas
- Sobre a robotização de negócios com Farida Roslovets e a diretora da empresa RPA electroNeek