Hablé con los fundadores de la startup ElectroNeek: Sergey (CEO), Dmitry (CIO) y Mikhail (CTO). Al final de la entrevista, un video donde se ensambla el robot en vivo.
- Dmitry, envía una foto para el KDPV, donde están todos juntos.
- Lo crea o no, todavía no nos conocemos tanto en dos años)
ElectroNeek desarrolla un ecosistema de productos de software que pueden usarse para crear robots que repiten cualquier acción de los empleados de oficina en una computadora con cualquier aplicación que esté instalada en ella. Así, es posible robotizar total o parcialmente los procesos en la empresa. ElectroNeek se especializa en trabajar con integradores de sistemas y equipos de TI que crean centros de competencia RPA, en otras palabras, sus productos están destinados a quienes desarrollan robots en grandes cantidades y no resuelven varios problemas específicos de automatización local.
RPA (Robotic Process Automation) es una tecnología que ayuda a automatizar las tareas repetitivas diarias. RPA le permite emular literalmente las acciones de un usuario normal en una computadora. Pasó el mouse sobre el botón e hizo clic, luego ingresó el texto con el teclado y presionó "Enter". Esto es exactamente lo que es RPA. A medida que aumentaba la demanda, los proveedores de RPA comenzaron a desarrollar sus soluciones para proporcionar mecanismos de automatización más flexibles. Hay integraciones con lenguajes de programación, con tecnologías como OCR, están pensando seriamente en introducir el aprendizaje automático. Los robots ahora se pueden lanzar simultáneamente, en un horario, de forma remota, etc. Ejemplos de casos: uno , dos , tres , cuatro, cinco .
- ¿Qué es un robot?
Mikhail: La robotización es una emulación de una persona. Una persona puede ser emulada de diferentes formas. Puedes físicamente. El robot camina como un humano. El robot hace clic en el monitor como un humano. Escribiendo como un humano. Nunca hay una emulación humana completa. Pero el aspecto de la emulación humana es la robotización.
- Mikhail, Yandex te buscó, pero aún así decidiste trabajar en ElectroNeek, ¿cuál es tu motivación para trabajar en una startup y no en un trabajo cálido garantizado?
Mikhail: Cuando trabajas en una startup, tú mismo eres el forjador de tu propia felicidad, pero en la empresa eres limitado.
- Michael, ¿cómo te atraparon?
Mikhail: Para ese momento, ya había dejado Akronis por un año, dejé de ver mi vector de desarrollo, quería estudiar diferentes tecnologías, hacía proyectos para mascotas. Quería hacer algo por mí mismo y estaba buscando un equipo. Mientras tanto, Dimitri y Sergei estaban buscando un director de tecnología y lanzaron un grito a sus conocidos. Conocía a Dmitry de la universidad, aunque no nos comunicamos mucho, así que nos juntamos. Estaba listo para esta propuesta.
Necesitaba entender si creo en el proyecto o no. Nos reunimos con Sergei en un café, me describió muy superficialmente qué es Electroneek y, después de la reunión, estudié de forma independiente el tema de la RPA con más detalle, miré a los competidores.
Llamamos de nuevo, ya tres de nosotros. Sergey y yo estábamos sentados uno al lado del otro, y Dmitry estaba en Estados Unidos en ese momento. Hablamos sobre el producto, cómo lo ven, dónde planean desarrollar, para quién es, cómo nos destacaremos y por qué hay “un robot constructor más” en el mercado.
Vi que hay demanda, al menos en Rusia. Dmitry habló sobre el mercado global, en particular sobre los Estados Unidos. Anteriormente trabajó en Ernst & Young y dirigió RPA para compañías Fortune 500 allí, por lo que conocía bien la demanda.
Sergey y Dmitry decidieron diferenciarse de la competencia con una UX simple y conveniente, para hacer que la robotización sea más accesible para empresas de cualquier tamaño. Necesitaba saber si mis posibles cofundadores entienden cuál será la interfaz, cuál es exactamente su frescura. Escuché la respuesta honesta "No lo sabemos". Los chicos en este momento no sabían qué debería ser exactamente, pero planeaban intentar averiguarlo.
Esa honestidad y franqueza fue importante para mí. Me gustó que fueran honestos sobre la situación. Esto es importante para las relaciones futuras. Para decir todo como es, y si una persona es adecuada, lo entenderá. Cuando sea honesto, si sale una jamba en alguna parte, puede ver de inmediato cómo resolver el problema, independientemente de quién haya cometido un error.
- ¿Cómo era Electroneek antes de que te unieras al proyecto?
Miguel:Antes que yo, había un prototipo funcional que podía mostrarse. Fue un proyecto en GitHub para mostrar lo que están a punto de hacer.
Cuando llegué, me mostraron un prototipo, me hablaron de los competidores, de las tareas que debían resolverse y me pidieron que las hiciera bien . No en la rodilla, sino durante mucho tiempo, para que se pueda desarrollar. Pero no había tiempo para sentarse durante mucho tiempo para desarrollarse, era necesario ir a la batalla más rápido. Era necesario correr hacia los clientes, era necesario atraer dinero. Por eso, desde los primeros días comencé a escribir código. Ya estaba familiarizado con Electron en ese momento. (Electron es un marco que le permite escribir aplicaciones de escritorio utilizando la pila de tecnología web).
- ¿Qué hace que el desarrollo de un producto RPA sea diferente del resto?
Sergey:¿Cuál es la diferencia entre el desarrollo de una plataforma RPA y un producto "en sí mismo"? La plataforma RPA, en particular ElectroNeek, es una herramienta de desarrollo. Un medio para crear algo interactuando con algo tercero. Este no es un producto separado como CRM, que en sí mismo y solo a veces a través de la API interactúa con otra cosa.
Un usuario basado en ElectroNeek crea una solución de software (robot) que interactuará con otros productos que están en constante cambio: navegadores, computadoras de escritorio. No controlas el entorno con el que interactuará el resultado del desarrollo. Esto impone enormes exigencias a la calidad, la UX y el desarrollo de soluciones de productos.
- ¿Por qué otro producto RPA en el mercado?
Sergey:la gente a menudo viene a nosotros y nos dice: "¿Por qué está desarrollando cuando puede ir a algún sitio web, descargar un módulo de clicker RPA listo para usar y hacerlo?" Sí, puede abrir un cuaderno, sentirse cómodo con un explorador de Internet, abrir Google. Pero tan pronto como vaya más allá (tan pronto como aparezcan XPath o selectores), diferentes variantes de sitios, gobiernos o ecosistemas SaaS, se enfrentará al hecho de que no está listo y no funciona. Y luego, si está desarrollando su propia plataforma, necesita adaptarse a los cambios, y si todo ya está cableado, entonces no puede adaptarse de manera flexible a los cambios. Lo teníamos en el piloto.
- ¿Cómo eligió la pila de tecnología?
Miguel:El proyecto implicaba que habría un escritorio y un elemento web, un frente clásico, un reverso clásico y una aplicación de escritorio. Y al principio, el proyecto no involucró a un gran equipo. Comprendí que los primeros meses estaría solo, no planeábamos expandirnos a un ritmo grandioso.
Necesitaba proporcionar algún tipo de estación múltiple para que entre 1 y 3 personas pudieran hacer todo. Por eso elegimos Electron. Te permite escribir una aplicación de escritorio, backend y frontend en el mismo lenguaje (lo tenemos TypeScript).
En el futuro, puede hacer especialización, pero al principio es muy conveniente cuando todos pueden hacer todo.
Como regla general, existe el problema de cambiar el contexto del backend al frontend. Por ejemplo, respaldo en python, frente en JavaScript, combinación popular. E incluso si una persona combina esto en sí mismo, le resultará costoso y difícil cambiar de un idioma a otro. Y cuando resuelve un problema, cambia a menudo, no es conveniente. Nos deshicimos de esto, nada cambia al cambiar: un idioma, un enfoque, incluso todo parece igual.
Luego busqué bibliotecas que pudieran cerrar inmediatamente algunas de mis tareas y no intenté escribir todo yo mismo.
Al principio, no es necesario que intentes andar en bicicleta. Llévelo confeccionado si se adapta a sus necesidades. Quizás entonces realmente tengas que sacar esta pieza y reemplazarla por la tuya. Pero al mismo tiempo, inmediatamente tendrás una pieza de trabajo.
Tomé una biblioteca lista para usar para la visualización. Nuestro producto principal es un entorno de desarrollo y hay una visualización de diagrama de flujo. Naturalmente, no lo escribí yo mismo, sino que tomé la biblioteca joinjs de código abierto. Te permite trabajar a nivel svg. Dibuja interfaces usando imágenes vectoriales.
Hemos estado sentados en él durante mucho tiempo. A veces pensamos que nos desharemos de ella, esto se puede hacer en cualquier momento, pero hasta ahora ella está realizando todas las tareas y sosteniendo la carga.
Es importante escribir todo de forma modular para que puedas tirar alguna pieza y no confundirte en tu propia red de código. El enfoque modular le permite deshacerse rápidamente de las bibliotecas.
Nuestro programa no es solo un editor de diagramas de flujo, sino que resuelve un problema específico: automatiza el escritorio. Lo usa para administrar aplicaciones de escritorio.
Una parte importante de nuestro programa es una biblioteca de bajo nivel para interactuar con aplicaciones, cómo presionar un botón, contar una imagen, crear una captura de pantalla.
Tomé la biblioteca de C # estándar UIAvtomation, que también fue utilizada por nuestros competidores en ese momento. Lo hemos reemplazado recientemente por uno más moderno.
Esta biblioteca tenía un contenedor, una API bastante estrecha que usamos. Luego pudimos descartar esta biblioteca, adjuntar una nueva y pegarla con un adaptador a esta API. Ocurre de forma rápida y sin dolor, y debe hacerse.
- ¿Cómo se implementaron las funciones?
Mikhail: Hablé con los cofundadores, tenían experiencia en la integración de la solución de un competidor, entendieron qué características se necesitaban. Me dieron una lista de funciones que usaban mucho. Empecé a hacerlos uno por uno.
Literalmente, uno o dos meses después, comenzamos a hacer un proyecto piloto para Russian Post.
Hemos resuelto el problema de la automatización de descarga para ellos. Tenían una aplicación de recursos humanos de escritorio para la gestión de currículums. No había interfaz y había que sacar todos los currículums de allí. No había API, ni base de datos, y no podían sacarlos.
Simplemente hicimos clic en esta aplicación, extrajimos los datos de allí y los pusimos en el disco.
La solución principal no fue difícil, escribí el algoritmo en unas horas, pero el diablo está en los detalles. Muchos matices: documentos de diferentes tipos, algunos tipos de campos pueden no existir, etc. Dediqué más tiempo a terminar.
Para cada función, me pregunté qué solución necesito ahora para poder resolver problemas de este tipo en el futuro. Si una característica pasó este filtro, la agregué. Al principio, las funciones se agregan sin mucha discusión. El código base es pequeño, agregado, probado, eliminado, es fácil.
Cuando la aplicación ya es grande, cada función necesita una discusión. A qué afectará la característica, si rompe algo y si tenemos otra forma. Al principio, es fácil de aserrar las características, no rompen nada, porque todavía no hay nada que romper.
- ¿Cuál fue la escala del trabajo para Russian Post?
Mikhail: La aplicación incluía a todos los empleados del Correo Ruso en todo el país. Es imposible gritarlo con las manos.
Qué estaba haciendo nuestro robot. Entró en una búsqueda con filtros vacíos. El resultado es una lista de todos los empleados que se desplazan por varias pantallas. Debe hacer clic en cada elemento de la lista en la hoja, se abre una ventana, hay una parte de los datos y varios botones que abren otras ventanas. Todas las ventanas tenían que abrirse, todos los datos tenían que unirse, las ventanas tenían que volver a cerrarse e ir al siguiente elemento de la lista. Y con ese tipo de iteraciones para robarlo todo. Aquí hay un resumen aproximado del proceso.
El piloto fue mutuamente libre y no lo llevamos al estado de producción. Para nosotros mismos, hicimos una prueba de concepto: en la plataforma puede resolver tal y cual problema, puede ir con esto para recaudar dinero, puede vender a los clientes y terminar sobre la marcha. Eso es lo que empezamos a hacer.
- ¿Cómo atrajo inversiones?
Miguel:Necesitábamos un prototipo funcional que impresionara a los inversores. La interfaz de la solución para Russian Post no era bonita, la hice yo y no soy diseñador. Hice para mí, modo IDE WebStorm Dark.
Las primeras etapas del prototipo de
ElectroNeek en 2021 Los
inversores saben cómo usar la imaginación. Puede mostrarles un prototipo torcido y decirles cómo cambiará y lo entenderán. El prototipo puede incluso tener fallos y fallos, pero lo principal es mostrar una pizca de significado para que el inversor pueda captar la esencia. Los clientes deben mostrar un producto hermoso y listo para usar. Las personas adecuadas entienden la diferencia entre un MVP y un producto final. Y es mejor no trabajar con inadecuados. Toma inversores durante mucho tiempo, es agradable trabajar con personas adecuadas.
- ¿Cómo fueron las demostraciones a inversores?
Miguel:Digamos que escribí una nueva funcionalidad y mañana por la mañana hay que demostrarla a los inversores. Entiendo que no se puede mostrar de esta forma. Tal vez algo se esté conectando, tal vez no haya un buen ejemplo para mostrar la funcionalidad. Me siento ahí terminando por la noche, inventando ejemplos, atrapando insectos para que se vea bien por la mañana. Por la mañana vengo sin dormir para la demostración. Muestro el producto a los inversores. Casi sin dormir, pero con éxito.
Al principio, no hay forma sin él. No hay un proceso de desarrollo normal cuando hay un entorno de desarrollo completo, un entorno de prueba, una clasificación y una producción. Solo hay un entorno, es para usted tanto de pie como de producción. Eres el único y tu tarea es hacerlo más rápido. Y usted trabaja como un cirujano que se acaba de preparar para la operación y "abre" el código, y le dicen: "Bueno, cosémoslo más rápido y vámonos".
Tenía que hacer todo y mantenerme al día. Mientras la aplicación sea pequeña, cabe bien en la cabeza, un buen desarrollador es capaz de hacer todo por sí mismo y no perderse nada. Cuando la aplicación crece, ya no es posible prescindir de QE.
Sergei: Teníamos recursos limitados, recibimos sólo 150.000 dólares, de los cuales 70.000 fueron en efectivo, esto fue todo lo que se necesitó para terminar el prototipo a un producto normal y mostrar las primeras ventas en Rusia y Estados Unidos. Luego recaudaron $ 0.5 millones. Mostramos ventas rápidas. Los inversores creyeron en nosotros.
Miguel:Tan pronto como apareció el dinero, comenzaron a expandir el equipo para hacer un buen producto lo antes posible. ¿Qué significa "bueno"? No necesita un producto perfecto desde el principio, aunque se puede hacer. Esto es un error. Mucha gente sabe cómo hacerlo a la perfección, pero lleva mucho tiempo. Si es rápido y bueno, entonces demasiado caro. Todo es imposible a la vez. En consecuencia, debe hacerse lo suficientemente bien aquí . Lo suficientemente bueno para vender.
Puede crear un producto con errores, si no son críticos, no disparar en la pierna y puede agregar funciones más rápido. La gente compra un producto con un error, ve un error, un informe al respecto, lo solucionamos allí mismo. La gente ve los comentarios. No hay ningún problema.
- ¿Cómo contratas desarrolladores?
Miguel:Me concentro más en la capacidad que en la experiencia. La experiencia es importante, pero el desarrollo es algo en lo que constantemente tienes que aprender algo. Cuando tenga que arrastrar una nueva biblioteca al proyecto, la probabilidad de que sepa que no será muy alta. El conocimiento básico es importante. Necesitábamos conocimientos de TypeScript, nos llevó mucho tiempo volver a capacitarnos en otro idioma. Es deseable conocer el marco. Estamos usando de Angular.
Para nosotros es importante que una persona pueda resolver rápidamente un problema complejo sin errores, o con errores fáciles de solucionar, que saldrán durante la ejecución. Una persona debería poder pensar mucho. Si es capaz de pensar mucho, de entender qué tipo de casos de esquina hay en general, entonces esto es genial.
A menudo sucede que la gente escribe un programa, pero simplemente no piensa en algunos casos. ¿Y quién pensará en ellos? Es posible que QA tampoco piense en ellos. Y luego disparan. Al mismo tiempo, los datos iniciales son suficientes para predecir estos casos de esquina. Para mí, esta es la diferencia entre un desarrollador prometedor y uno poco prometedor: cuántos casos de esquina al principio es capaz de anticipar.
- ¿Cuántas personas hay ahora?
Mikhail: Seis personas - desarrollo central, que crean la plataforma directamente. Cuatro personas que están enHacer de la plataforma soluciones reutilizables. Utilizan la plataforma, además de herramientas adicionales en lenguajes de scripting, y realizan proyectos específicos. Ahora solo estoy hablando de desarrolladores. También hay un departamento de control de calidad, un equipo de producto independiente.
- ¿Cómo pasó de la codificación a las responsabilidades de gestión como CTO?
Mikhail: Después de recibir la inversión, estuve escribiendo código activamente durante varios meses. Aunque contratamos a QA, no estaba muy seguro de ellos. Yo mismo escribí la revisión del código.
Luego vi en el tablero kanban que era un cuello estrecho. Y entiendo que es hora de soltar las riendas, de aceptar que los problemas se me pasarán por alto en la producción.
Revisé las cosas más críticas. Comenzó a confiar en QA. Fue un proceso gradual de soltar el control. Cuando pasas todo por ti mismo, estás seguro del resultado. Usted ve todo, puede detectar todos los problemas usted mismo. Pero esta no es una historia escalable. Ella es buena al principio, luego debes deshacerte de ella a escondidas. Así que gradualmente lo dejé ir, revisé solo los lugares críticos y luego dejé de escribir y revisar por completo. Ahora todo el mundo lo hace sin mí.
- Ahora que ha aceptado la caída de la calidad, ¿qué sigue?
Mikhail: Mira, ya no tengo la opción de revisar el código, ya hemos pasado por esto. ¿Que más puedo hacer? Ahora puedes ajustar las cosas del proceso.
Digamos que los desarrolladores fusionan características de calidad no muy alta en la rama principal. Probablemente algo anda mal con la revisión. Ya veremos. Observa lo que la gente está revisando. Ajá, para llamar la atención de los chicos sobre esto. Vas a las instrucciones. Procesos de depuración. Buscando puntos débiles. No intentas trabajar, creas procesos.
Aquí es donde los desarrolladores revisan, pero las características aún no están muy fusionadas. Agreguemos una prueba de funciones antes de fusionarla. Adicional. ¿Qué sucedió? Ahora QA no tiene tiempo para probarlos. De acuerdo, probablemente no todas las funciones deban probarse de esta manera, sino solo las más peligrosas que afectan a todo el proyecto. Estás equilibrando
No existe una plantilla para diferentes empresas, pero el enfoque general es el mismo: probar su sistema y solucionar los cuellos de botella de manera procedimental. Entonces ya es una historia escalable.
Mi tarea es encontrar el cuello de botella donde está el problema del proceso, hablar con la gente e implementar una solución funcional.
Idealmente, si me hago a un lado, entonces todo funciona. Es imposible al principio. Hazte a un lado, todo está roto. Y ahora debería ser que me alejé durante un mes y nada se rompió.
- ¿Cómo saber cuándo contratar a una persona especial?
Mikhail: ¿Hay suficiente para este hombre de cuello estrecho? Si una persona está ocupada al menos en un 70% con esta tarea, entonces puede contratar. Si necesita una persona el 5% del tiempo, probablemente pueda manejarlo usted mismo.
- ¿Qué estás haciendo ahora?
Mikhail: Todavía estoy a cargo de los procesos. Y me ocuparé de ellos durante mucho tiempo.
Estoy hablando de características, como Sergey. Aquí es donde crece nuestro producto. Lo pasa por su propio prisma, yo por el mío.
Somos desarrolladores que escriben una herramienta de desarrollo. No puedo realizar un seguimiento de todas las funciones que hacemos, pero analizo las importantes, complejas, críticas o interesantes y doy retroalimentación al equipo de producto, que optimizará la función en función de ella. No estoy en el negocio de describir, sino de escuchar lo que van a hacer y dar retroalimentación. Sergey está haciendo lo mismo en términos de funciones. Esto es algo que definitivamente no dejaremos pasar. Es importante comprender hacia dónde se mueve el producto, dónde lo estamos desarrollando.
- ¿Cómo estudias?
Miguel:Primero, explico el problema claramente. La experiencia de vida ya te permite decidir mucho. Ya sé mucho más que cuando me gradué de la universidad, pero todavía hay problemas que no entiendo cómo resolver.
Primero, averiguo cuál es el problema. Digamos que no tengo ningún tipo de herramienta. Busco en Google, veo YouTube o algún curso, averiguo cómo lo hacen los profesionales en un campo en particular.
Por ejemplo, ¿cómo se prueban aplicaciones grandes cuando hay muchas pruebas manuales? No tenemos tiempo, ¿qué hacer?
Si no eres un QA genial en el pasado, entonces entiendes indirectamente qué es qué, pero es posible que no conozcas algunos matices. Abro YouTube, escucho una conferencia de control de calidad de una hora con muchos años de experiencia, entiendo que lo que he escuchado se puede aplicar, lo intento, lo analizo. Si cabe, lo dejo.
Es imposible saberlo todo. La tarea de cualquier gerente es aprender todo lo que sea posible, delegar y de tal manera que se mantenga la función de control.
Establezca el marco en el que trabajan las personas y controle el resultado dentro de este marco. Toman decisiones por su cuenta.
Si hay un problema en el mercado, la decisión se puede tomar sin mí. QA dice que la tarea es crítica y puede decidir retroceder. No necesito despertarme para esto. Lo principal es que la gente entienda el marco.
- ¿Un consejo para ti en tu juventud?
Miguel:Al principio me pareció que al principio tenía que aprender mucho. Algo que aún no sé. No puedo escribir un sitio web, no puedo escribir un backend. Primero quería hacer un curso o terminar una universidad. Realmente no. Tómalo y pruébalo. Google es una gran herramienta, todo está ahí. Resuelva los problemas puntualmente. Usted no sabe cómo a hacerlo específicamente, y aprender a hacer que específicamente . No sabe cómo configurar nginx, así que estudie esto específicamente.
No se puede aprender todo. Toma demasiado tiempo tomar un curso de programación de varias semanas. Mejor empieza a programar. Aquellos problemas que te surgirán y resolverlos. De esta manera es más rápido. E incluso más inmerso en el problema que leyendo un libro. Si lee 600 páginas de cabo a rabo, el conocimiento será superficial. El conocimiento es más profundo en la experiencia.
"Descubrí Google" en el sentido de que puedo, con mi conocimiento, hacer cosas complejas, buscar en Google y encontrar soluciones puntuales para enchufes. Así es como me desarrollé en el futuro.
Leo libros de forma selectiva. Cuando estaba resolviendo un problema, encontré un fragmento que describe la solución. Los artículos son iguales. Tampoco puede ver las conferencias en su totalidad. Las conferencias tienen una duración de 4 horas. Encuentra el código de tiempo, solo mira la parte interesante, puede ser suficiente.
- ¿Cuéntenos sobre los controles de organización de servicios (SOC)?
Sergey: Si desea hacer una aplicación SaaS en el mercado estadounidense, especialmente algo que funcione en empresas con más de 200-500 personas, la pregunta sobre SOC (Security Organisation Control) surgirá de inmediato. Mientras no lo tengas, todos le preguntan. Esta es una historia que peina las políticas de la organización, la distribución por el nivel de derechos y acceso, cómo diseñar el código, los auditores vienen y comprueban.
Hasta que no lo tengas, todos los clientes normales lo piden y no firman el contrato. Tan pronto como aparece y dices "aquí lo tenemos, si quieres enviar un informe", los clientes responden que no es necesario, "no queremos leer el informe".
Lleva cuatro meses, se pone en orden y se está revisando. Un conjunto de actividades que afecta a toda la pila de tecnología. Michael se da cuenta de que impulsó este proceso por completo.
Mikhail: Somos una organización que brinda servicio a los clientes. SOC se trata de qué herramientas tenemos dentro de nosotros para garantizar la seguridad, disponibilidad y continuidad del servicio y la seguridad de los datos. Todas aquellas cosas que interesan a los grandes clientes y poco interés a las pequeñas organizaciones.
Si nuestro cliente es una organización grande, entonces la falta de SOC puede ser un problema para ellos. Sus regulaciones no permiten trabajar contigo. Por lo tanto, en cierto momento salió a la superficie para nosotros.
O tiene esta certificación, SOC (todavía es costoso para una empresa incipiente), o la empresa le envía un cuestionario de varias páginas sobre cómo está seguro. Lo lees y no entiendes ni la mitad.
Puedes llenarlo durante mucho tiempo, porque De buenas a primeras no siempre está claro de qué se trata el discurso. Además, mientras completa, comprende que no tenemos esto. Y este no es el caso. Y esto tampoco está ahí. Y no tiene sentido enviar este cuestionario. Y no parece tan difícil hacer que sucedan estas cosas. Pero esto debe hacerse.
En algún momento, nos dimos cuenta de que esos clientes vienen a nosotros, llenamos sus cuestionarios durante mucho tiempo, pero como resultado de la transacción no hay. Decidimos ocuparnos de este problema.
Esta certificación es un proceso de seguimiento continuo. No es que lo hicieras una vez y eso es todo. Tienes que colocar algún tipo de "casillas de verificación" de forma regular. Sus datos siempre están encriptados durante la transmisión. Tiene datos que siempre están encriptados en los servidores, en caso de que desaparezcan en algún lugar del disco duro, nadie sacará nada de allí. Hay muchos ejemplos de este tipo y también otros más sofisticados.
Cuando comienzas a buscar en Google cómo hacer esto, encuentras una hoja A4 de 60 hojas, qué hacer y cómo hacerlo. Y hay que desmontar cada punto, porque no lo entiendes. Parece un trabajo muy largo.
De acuerdo, este es el camino que seguiremos durante mucho tiempo. ¿O tal vez podamos encontrar una empresa que nos haga la vida más fácil? Nuestra compañía. En ese momento, ya estábamos en Y Combinator. Les hicimos esta pregunta a los chicos de allí, nos lo pidieron los ex alumnos de YC que automatizarán esta historia. El servicio no es gratuito, pero les compramos un servicio. Se trata de una especie de panel de administración en el que integra todos sus servicios. JetSuit, Bitbucket, Gitlab, Jira, AWS, Azure, quién tiene qué. El programa en sí mismo estudia dónde tienes qué configuraciones y dice qué y dónde te estás perdiendo. Lo corrige puntualmente y todos los elementos de esta hoja se cierran automáticamente.
Después de eso, se invita a un auditor, quien confirma que todo está realmente ahí y establece una "prueba". Así simplificamos nuestra vida.
Para las grandes empresas, esto es un trámite, sin el cual no podrían ir más allá y cooperar con nosotros. Bueno, como un plus, un aumento real en la seguridad del cliente.
- Háblenos de Y Combinator a través de los ojos de un desarrollador.
Mikhail: Realmente no entendí para qué era YC. Estaba claro que esto era prestigio. Y el objetivo específico fue difícil de entender para mí. Leí sobre cómo puede estar ahí. Fue difícil para mí imaginar qué tipo de experiencia útil se podría obtener allí. Estaba bastante escéptico sobre el hecho de que mejoraría como profesional. Pero entendí que se trataba de un hito útil para la empresa en su conjunto.
Si hablamos del resultado. Obtuvimos más beneficios comerciales. También ayudaron con recursos técnicos y siguen ayudando. Hicimos una infraestructura más correcta en la nube.
La principal conclusión de esta historia es que si está listo para usar los productos que ofrece YC, listo para profundizar en su comprensión, esto será una gran ventaja.
Terminamos YC en marzo de 2020, cerramos la ronda con $ 2.5 millones. Se inició un crecimiento significativo tanto del equipo de desarrollo como de las tareas.
- ¿Cómo llegaste al equipo de producto actual?
Mikhail: Nuestros productos son bastante complejos, es necesario ser desarrollador para comprender un producto para desarrolladores. Debe comprender, desde el punto de vista del desarrollador, qué funciones implementar, cómo las usan nuestros clientes. Por otro lado, vale la pena ser un buen empresario, un investigador de mercados. Combine todas estas competencias. Hay alguna dificultad con esto.
Sergey:Durante los últimos 4-5 meses, de marzo a agosto, primero contratamos a un gerente de producto que tenía experiencia en RPA. Trabajamos con él durante varios meses y no obtuvimos ningún resultado. No contratamos a un gerente de producto de la serie "Lo contrataremos y el oro se derramará de inmediato", queríamos llegar a una comprensión clara de las funciones que estamos haciendo, son necesarias para capturar el mercado futuro, para resolver problemas específicos del cliente, para aumentar las ventas. Tomamos el producto por métricas bastante medibles y lo discutimos. Desafortunadamente, ambos productos estaban rodando. Esto también es culpa nuestra. Contratamos gente que se ofreció a hacer la función, "porque es hermosa". ¿Cuánto dinero traerá ella? Bueno, es difícil de contar ... ¿A quién ayudará? ¿Cómo puede ayudarlo a ganar las operaciones actuales, o al menos a no perderlas? No logramos construir una historia así.
Con qué terminamos. Un esquema súper cómodo para nosotros, impulsa mucho a nuestra empresa.
Tenemos un gerente de producto de UX, un gerente de producto de tecnología, tenemos un Jefe de Ingeniería, tenemos un CTO y tenemos un CEO como representante comercial. Hemos formado una oficina de abarrotes donde el producto se “corta” en diferentes partes. UX, análisis de nuevas funcionalidades, ingeniería. Mikhail y yo desempeñamos el papel de facilitadores en el caso de la priorización. También soy responsable de las funciones de ventas. Dmitry analiza cómo las características del producto son o pueden traducirse en oportunidades y herramientas de marketing, como nuestra biblioteca global de bots creada por clientes y socios.
Tenemos sesiones espontáneas para discutir temas serios. También contamos con una llamada semanal de hora y media donde planificamos el próximo sprint, que ya ha sido priorizado dentro de la empresa. Las nuevas características vuelan en tres pistas: errores: arreglamos algo que no funciona, ralentiza la venta o interfiere con los clientes actuales; UX - arreglamos el actual, porque sabemos que el producto siempre se puede mejorar; Agregamos algo nuevo al producto, lo que nos permitirá ser más efectivos en el futuro. Trabajamos en ese marco. Nos gustaría llegar a una persona que esté involucrada en todo el producto, pero hasta ahora nos parece que es difícil.
Me gustaría aconsejar a los futuros emprendedores, especialmente a los técnicos, que no intenten considerar solo una opción (que el CEO debe encontrar un propietario de producto), sino que existe un formato de interacción distribuida que da un resultado.
- ¿Es posible con la ayuda de su robot cultivar en juegos de computadora, clics en YouTube?
Dmitry: En nuestra base, un cliente hizo un robot que enciende la tetera.
Sergey: El robot puede presionar cualquier botón. Damos una herramienta de desarrollo. Lo que los clientes construyen sobre él es responsabilidad de las personas. Puedes construir lo que quieras.
Sergey:Teníamos una historia. El cliente compró el servicio y luego escribió: “Elegí específicamente a la chica menos desarrollada en la dirección de TI en nuestra empresa, Olya. Y así "Olya" pudo crear un robot con la ayuda de ElectroNeek. Si "Olya" puede hacerlo, cualquiera en mi empresa puede hacerlo. ¡Te estoy comprando un producto! " Este es un alto indicador de facilidad de uso. Aunque la mayoría de los desarrolladores de nivel medio o junior nos usan. Reciben un producto, en cualquier pila (web, escritorio, hay API o no), crean una aplicación (¿un robot?), Esa es la libertad que da nuestro producto.
Dmitriy:Cuando un producto llega a los inversores en una etapa temprana, la historia con Olya se repitió allí, hay Oli entre los inversores. Hubo situaciones en las que socios de los principales fondos estadounidenses ingresaron al producto (Gary Ten de Initialized, un ex socio de YC e inversionista en Coinbase e Instacart). El socio comenzó a montar el robot con las manos.
Bono: recolectar un robot en vivo
Lee mas
- Lanzamiento de HN: ElectroNeek (YC W20): busque y automatice automáticamente el trabajo de rutina
- Cómo cuatro rusos crearon una fábrica de "empleados digitales" y ganaron $ 1 millón con ella
- electroNeek RPA: los robots de software ayudan a las personas
- Sobre robotización de negocios con Farida Roslovets y el director de la empresa RPA electroNeek