Hay una frase popular "rasca tu propio picor": si quieres crear un nuevo producto, haz uno que tú mismo te falte. En este caso, comprende mejor cómo hacerlo bien.
Adam Carmi era muy consciente de la falta de una herramienta de prueba visual que ayudara a las personas a no romper los ojos en busca de un diseño viajado. Y al final, creó dicha herramienta, adaptando la inteligencia artificial para esto, y se convirtió en uno de los cofundadores de Applitools. Suena como un trabajo soñado: cuando luchas con el dolor que conoces, sientes que estás cambiando el mundo para mejor. Pero, ¿qué dificultades enfrenta un especialista en TI cuando el destino de una empresa entera depende de él?
Y dado que la herramienta Applitools en sí también necesita ser probada, Adam aprendió mucho sobre cómo probar proyectos con IA. Mañana en Heisenbug, hablará sobre cómo hacer esto, y su informe se transmitirá en vivo , para que todos puedan verlo en vivo. Mientras tanto, le preguntamos sobre ambos temas: cómo se siente crear una empresa y cosas relacionadas con las pruebas y la IA.
Vida de inicio
Evgeny Trifonov ( phillennium ): Fuiste empleado durante muchos años y luego decidiste crear una startup. ¿Cómo sucedió esto y cuál fue el impulso?
Adam: Mi trabajo anterior era una compañía de seguridad de la información. Trabajé allí por 8 años. Creo que puedes imaginar cuántas interfaces de usuario hay en un producto de seguridad. Una gran cantidad de registros, cuadros, gráficos, consultas y alertas. Y alrededor de todo esto había una gran cantidad de IU no obvia.
Todo se complicó por el hecho de que esta interfaz de usuario se tradujo a 6 idiomas y se suministró bajo cinco marcas diferentes. Para probar todo manualmente desde el principio hasta el final en todas las variaciones, tomó algo alrededor de una semana. Hubo 20 probadores que hicieron esto en cada iteración. Es decir, si un lanzamiento requiere varias iteraciones, entonces esto requiere un ciclo de lanzamiento de al menos 2-3 meses.
Por lo tanto, en esos años cuando trabajaba allí, carecía de soluciones para este problema. Por supuesto, nos dedicamos a la automatización. El selenio todavía era un producto joven, lo usamos, pero no cubría la interfaz de usuario. Les expliqué constantemente el problema a los vendedores de la época (HP, Microsoft e IBM) y pedí una solución. La respuesta siempre ha sido una: es imposible. Para verificar que la interfaz se vea como debería (en lugar de simplemente "funcionar como debería"), siempre se necesitarán probadores manuales.
Al escuchar esta respuesta durante años, decidí involucrarme en un instrumento para mi equipo como un proyecto paralelo. He estado escribiendo código desde hace 10 años, realmente me gusta, puedo hacerlo. Y, por lo tanto, incluso cuando dirigía un gran equipo, siempre tenía proyectos favoritos: escribía juegos para mis hijos, y luego jugaba con cosas interesantes. Y realmente quería resolver este problema. Inmediatamente vi lo difícil que era, pero solo me estimuló a trabajar más y a tomar una decisión.
En aproximadamente un año de trabajo, logré sentar las bases. Y para entonces, la compañía donde trabajaba fue comprada por otra. Y decidí emprender mi propio negocio en lugar de mudarme a otro.
En general, mi motivación era trabajar en algo que me interesara a nivel tecnológico. No tenía ambición de convertirme en un gran hombre de negocios. Era solo una cuestión de poder trabajar en lo que me fascinaba.
Eugene: Cuando la gente de TI encontró empresas, a menudo no son los problemas tecnológicos los que son el problema, sino el lado comercial. Tenías experiencia en puestos gerenciales, ¿cuánto te ayudó? ¿Recomiendas obtenerlo antes de crear tu empresa?
Adam: Para empezar, quiero señalar que no se debe confundir la experiencia de gestión con los negocios. Estas son cosas muy diferentes.
Ser un técnico es una habilidad separada. Atrae a personas con talento, los inspira a trabajar duro, se asegura de que permanezcan en su equipo durante muchos años y el trabajo los cautiva. Creo que esto se debe en gran parte a ser un buen ingeniero y no está relacionado con los negocios.
Hay personas que creen: como estoy creando una startup, seré CEO. Yo mismo lo sé todo, nadie es mi asesor. Mucha gente piensa y falla. Incluso aquellos que se han convertido en muy buenos CEOs. Puedes cometer cualquier error de esta manera.
Mi posición era completamente diferente. Inmediatamente dije que no tenía idea de cómo ser un CEO. Por lo tanto, dije: busquemos a alguien que ya sepa qué hacer y que tenga experiencia relevante en este asunto. Y que sea CEO, y yo seré responsable del componente técnico.
Esto no garantiza en absoluto que en este caso todo salga bien, pero al menos no pierdo el tiempo cometiendo errores que pueden evitarse por completo si una persona experimentada se ocupa de esto.
Antes de que la compañía en la que trabajé durante 8 años fuera absorbida, nuestro CEO vino a contarme sobre esto, comenzamos a pensar en planes para el futuro, y le dije en lo que ya estaba trabajando en ese momento. Inmediatamente se interesó, investigó la situación adecuadamente, decidió unirse a mí y desde entonces ambos trabajamos en Applitools.
Repito, creo que un ingeniero no es la mejor opción para una startup. Las posibilidades no están de tu lado. Vale la pena encontrar a alguien que sepa lo que está haciendo. Esto aumentará las posibilidades de éxito, aunque no garantiza nada.
Eugene: Lo tengo. Y en esta situación, cuando las tareas comerciales complejas estaban en otra persona, ¿qué es lo más sudoroso para usted?
Adam: Me hizo sudar ... No quiero entrar en detalles sobre las dificultades específicas de Applitools. Creo que esto: es genial que los emprendedores en ciernes sean muy ingenuos. Por supuesto, este es un cliché que todo el mundo repite, pero hasta que lo haga usted mismo, ni siquiera puede imaginar la presión, la incertidumbre, los altibajos psicológicos que atraviesa con la empresa. El mismo día puede parecer que conquistarás el mundo y que tendrás que despedir a todos. Se necesita tiempo para adaptarse a esto y comenzar a ver las cosas en perspectiva. Es muy dificil.
Bueno, existen las dificultades habituales: que el producto funcione correctamente, que se ocupe del componente de ingeniería y que trabaje duro.
Mikhail Druzhinin ( xomyakus ): Parece que el desarrollo es una parte simple. Ella es al menos predecible.
Adam: exactamente.
Durante la primera parte de la vida de una startup, cuando no está claro si sobrevivirá, no es fácil encontrarse en una situación en la que descubra que ya no tiene dinero. Usted ya ingresa en sus ahorros personales para pagar salarios a los empleados. Aquellos a quienes previamente convenció con la ayuda de su carisma para abandonar sus lugares y trabajar para usted por un salario más bajo simplemente porque creen en usted.
Pero incluso cuando dejó el modo de supervivencia, tiene un excelente producto y clientes, si recaudó fondos, tiene inversores que esperarán a obtener ganancias de sus inversiones. Ahora hay una presión constante para crecer y desarrollarse a un ritmo muy alto, y esto requiere un enfoque creativo y mucho trabajo, porque tienes que lidiar con este crecimiento.
Digamos que sus ventas ascendieron a X millones por año, y se regocija en el éxito. Pero el año que viene tienes que vender el doble, ¿cómo hacerlo?
Michael: Dijiste acerca de la creatividad, ¿qué significa exactamente esto?
Adam: Usualmente piensas: hice un gran producto, ahora todo el mundo lo usará.
La realidad es que el mundo está realmente muy ocupado. El mundo no tiene idea de tu existencia. El mundo siempre tiene 10 cosas diferentes que hacer, y no puedes controlar dónde estarás en esta lista. Y no tienes mucho dinero para conocerte. El dinero es el presupuesto para publicidad, conferencias, seminarios web, ventas personales. Todo esto cuesta solo una tonelada de dinero.
Y la creatividad aquí significa pensar más allá de los estereotipos y utilizar enfoques que requieren poco dinero y recursos. Applitools puede hacer esto, nos permite tomar una nueva altura cada año. Pero cada vez tenemos que ir más allá.
Michael: Exactamente, necesitas pensar más ampliamente. Noté que muchos desarrolladores y evaluadores piensan de manera muy directa, solo ven una solución al problema. Se necesitan cinco meses y muchos recursos para las pruebas. Luego se les dice: ya sabes, solo queda un mes, y luego todos moriremos. ¡Aquí es donde comienza la creatividad!
Adam: Sí, por supuesto. También existe la creatividad, que concierne al producto en sí: siempre necesita mantenerse al día, hacer algunas cosas más rápido y de manera más eficiente. Esto es evidente.
Eugene: Volviendo al tema del crecimiento: ¿cuántas personas trabajan hoy en Applitools y qué tan rápido está creciendo este número?
Adam: 110 personas trabajan hoy. Y a principios de 2018, había unos 20 de nosotros. El crecimiento fue rápido, cinco veces en un par de años.
Eugene: Impresionante, sí. ¿Pero fue difícil a tal ritmo de crecimiento, cuando muchas personas nuevas vienen, mantener la cultura de la empresa?
Adam: gran pregunta. Desde mi propia experiencia, me di cuenta de lo importante que es una cultura empresarial bien definida. Parece que ahora podría hacer un informe completo sobre este tema.
Para empezar, el concepto de cultura corporativa en Israel no está muy desarrollado. Si alguien está tratando de hacer esto, la reacción de la gente es "oh, esto es una mierda corporativa".
Y para nosotros se ha convertido en un punto de partida. ¿Qué decidí hacer con Applitools como gerente de I + D? Mirando hacia atrás en mi experiencia en otras compañías, quería realizar un experimento: en general, no se me permitirá bajar el listón cuando reclute personas, solo tome excelentes especialistas y eso es todo. Sin compromisos. Fue muy dificil.
Por supuesto, los primeros empleados son aquellos a quienes conoce personalmente y a quienes convenció para que fuera con usted. Pero después de eso se vuelve muy difícil crecer. A veces nos lleva de 6 a 8 meses encontrar al empleado adecuado.
Pero con el tiempo, se vuelve más fácil, porque su equipo ya tiene muchos especialistas fuertes y conocen a otros muchachos talentosos. Y cuando estos talentosos comienzan a buscar trabajo, ven los nombres de los empleados de su empresa, y hay oradores sólidos de conferencias internacionales, bien conocidos en la comunidad local. Y luego se vuelve fácil: están más interesados en ir a usted que en una gran empresa.
Esto nos permitió crear un proceso de desarrollo único, que es incluso difícil de llamar un proceso. Cada uno de nuestros desarrolladores tiene la responsabilidad de todo lo que sucede. No tenemos sprints, lanzamientos planificados, ni siquiera requerimos que el equipo del producto proporcione una especificación completa.
Es suficiente que tengas una idea y que seas responsable de su implementación. Usted mismo está buscando la información que necesita, usted mismo está buscando personas que lo ayuden. Si no sabe cómo hacer algo, usted es responsable de aprender cómo hacerlo.
Así que logramos crear algo especial. Y cuando atrajimos una gran cantidad de inversión y supimos que creceríamos, me preocupé mucho. ¿Cómo preservar nuestra singularidad y no destruirla durante el crecimiento, cuando el equipo de ingeniería se triplica?
La decisión fue arreglar este proceso y definir claramente la cultura.
Empecé contratando a un muy buen personal que trabajaba para Dropbox. De hecho, reunió a todo el equipo de Dropbox, y ahora se considera uno de los mejores lugares para trabajar en el mundo. Ella tiene mucha experiencia. Simplemente nos sentamos y comenzamos a escribir un borrador de nuestra nueva cultura.
Presentamos nuestros logros a los Timlids, quienes rechazaron por completo todo esto. Y se enojaron mucho. Y entonces comenzó el diálogo. En el proceso de discusiones con una gran cantidad de comentarios, pudimos formular lo que significa trabajar en nuestra empresa. Obtuvimos una lista de valores con los que todos los líderes de equipo estuvieron de acuerdo.
Tomó varios meses, pero al final, cuando presentamos el resultado a todo el equipo, la gente lo recogió de inmediato. Inmediatamente sintieron que las palabras expresan exactamente por qué trabajar en nuestra empresa es tan emocionante. Esta vez recibimos una excelente respuesta.
Ahora salvaguardamos religiosamente estos valores y nos aseguramos de que al expandir el estado, no haya conflictos con ellos. Nos ayuda a tomar decisiones y mantener la atmósfera, y espero que en el futuro continúe ayudando.
Eugene: Otro detalle interesante sobre Applitools: su sede se encuentra en Silicon Valley, pero la I + D está en Israel. ¿Puedes decir por qué?
Adam: En primer lugar, cuando comienzas una empresa, al principio trabajas desde casa, desde un café cerca de tu casa o viajas.
Mi empresa fue fundada y creció en Israel, porque hay mucha TI. Y solo por nuestra actividad en Israel, logramos extendernos al resto del mundo. Cuando una gran empresa tiene un equipo en Israel, y utilizan algún tipo de herramienta en este equipo, como resultado, otros equipos de esta empresa (en los EE. UU., Gran Bretaña, en otro lugar) ven esto. Y si utiliza esta herramienta, su producto de repente tiene clientes extranjeros, aunque no haya participado en marketing o ventas en el extranjero.
Pero desde algún punto quieres estar más cerca de tus clientes. Y como empresa que atrae inversiones, desea estar más cerca de los inversores que tienen la cantidad adecuada. Los fondos israelíes trabajan principalmente con startups en las primeras etapas, por lo que es más difícil obtener grandes cantidades de ellos. O su inversión es menos útil, porque no tienen conexiones como los fondos de riesgo de los Estados Unidos. Es útil estar cerca de estas personas y mantener relaciones con ellas. Después de todo, quiero estar en una situación en la que los inversores quieran invertir en usted y recurrir a usted (y usted acepte aceptar dinero o no), y no correr detrás de ellos.
También quiero estar más cerca del cliente, y ya tenemos docenas de gerentes de ventas. ¿En qué región de EE. UU. Pueden las empresas participar más activamente con nosotros? Nuestra oficina para estos empleados se encuentra allí, y esta es también la sede ubicada al lado de los inversores.
Y la I + D, que comienza en Israel, sigue ahí. Aquí hay excelentes especialistas, y al mismo tiempo mantener un equipo de ingenieros aquí es mucho más barato que en Silicon Valley, y la competencia por el talento no es tan alta. Por todas estas razones, estoy encantado de permanecer aquí en Israel, al frente de la oficina israelí. Esto es bueno para mí y para la empresa. Y mis dos socios han estado en San Francisco durante casi cuatro años.
Michael: Y además de la barra alta que mencionaste cuando contrataste, ¿utilizas algún otro truco para evitar que el nivel de calidad disminuya con un rápido crecimiento?
Adam: Puedo decirte lo que estoy haciendo ahora (tal vez esto cambie en el futuro).
Creo firmemente que un buen desarrollador hace que el software funcione realmente. Él no crea dicho software con el que ya ha terminado, pero otros aún necesitan probarlo. Es su trabajo hacer que realmente funcione. No me importa cómo lo hace. No importa si prueba todo manualmente cada vez o automatiza las pruebas. Realmente no me importa Pero este es su trabajo y su tarea.
En general, los chicos que escriben los algoritmos y el backend están más satisfechos con este estado de cosas. Pero el front-end no está muy contento, porque probar la interfaz de usuario es mucho más difícil que la API con pruebas unitarias.
Hay un problema con todo esto. Por supuesto, lo más probable es que tenga un desarrollador que comprenda que debe probar todo lo que escribe. Él sabe que este es su trabajo y aceptó. Pero cuando preguntas: "¿Está todo bien probado?" Y él responde "Sí", esta es una respuesta muy subjetiva. Hizo algo, pero puede ser el 50% de lo que se suponía, y se escribió a sí mismo en un cuaderno "después del lanzamiento, será necesario volver a esto".
E incluso una revisión del código no nos dará una imagen completa de lo que está sucediendo, porque el empleado que realizó la revisión del código también estaba ocupado. Él dice que hubo algunas pruebas, y miró algunas de ellas, todo está bien, sigamos adelante.
Es por eso que tengo un director de calidad (no QA).
Él tiene su propio equipo. Su objetivo en la compañía es asegurarse de que todo se pruebe y que los desarrolladores realmente cubran todo. En pocas palabras, todo lo relacionado con la calidad debe ser probado. El director de calidad tiene mucha autoridad y libertad. Si me dice que algo no está cubierto lo suficiente, no emprenderemos nada hasta que lo resolvamos.
Su equipo también ayuda al equipo de desarrollo a llenar los vacíos. A veces, los problemas se descubren retrospectivamente cuando el equipo correspondiente está ocupado con algunas funciones y no tienen tiempo para cambiar, entonces el equipo del director de calidad puede asumir estas tareas.
Y, sin embargo, este equipo es responsable de las pruebas de extremo a extremo, que afectan a diferentes equipos y productos. Esta es una zona difícil de cubrir para los equipos de ingeniería: pueden descubrir de qué son responsables ellos mismos, pero cuando algo afecta a varios equipos o productos a la vez, es difícil esperar que uno de ellos haga frente a esto y se comprometa a responder para todo No funciona así. Por lo tanto, el director de calidad es responsable de pruebas tan complejas. Él puede venir y decirme "Necesito recursos de ingeniería para eso", porque para alguna parte de la prueba puede que no los tenga.
Así es como funciona en general, aunque hay aspectos. Cuando trabajas en una compañía de cinco personas, no importan, pero cuando tienes una oficina en otra parte del mundo y hay apoyo, de repente surge mucha comunicación en relación con cada lanzamiento. Si algo no funciona como debería, o si aparece algo nuevo, los clientes comienzan a hacer preguntas de soporte. Y si no saben lo que ha cambiado, entonces no podrán responder bien.
Entonces, parte del esfuerzo se ha dedicado a crear comunicación: informes muy informativos que responden a todas las preguntas principales sobre los cambios, y también me muestran que todo ha sido probado. Si no todo, ¿dónde están las brechas? Y para tales informes generales, el equipo de calidad también es responsable, asegurándose de que todos sepan lo que está sucediendo. Esto proporciona a la empresa una sensación de alta calidad, no solo en términos de pruebas y cobertura.
Michael: Haces una herramienta de prueba, pero ¿cómo pruebas esta herramienta? ¿Cómo se usa Applitools para probar Applitools?
Adam: Tanto todas las pruebas visuales como las pruebas de IU funcionales en Applitools se realizan usando Applitools. Por supuesto, hay algo que se prueba manualmente y que no tiene sentido probar a través de la interfaz de usuario y está cubierto a través de la API. Pero con el componente visual, tenemos comida sólida para perros.
Lo lanzaremos varias veces al día, pero no podemos hacerlo para que el usuario vea los cambios. El equipo de desarrollo no debe cambiar la interfaz de usuario sin pasar por el proceso de notificación de soporte adecuado para que sepan cómo responder preguntas.
Por lo tanto, generalmente sucede así: si la interfaz de usuario cambia, estos cambios se desarrollan en una rama separada o enmascarados por una bandera, pero los cambios de fondo se vierten varias veces al día. Tenemos versiones periódicas con grandes características visibles en la interfaz de usuario. También tenemos una hoja de ruta para preparar a los clientes para los cambios, estamos desarrollando una campaña de mapeo y escribiendo documentación para todos los cambios.
Y parte de este proceso: antes del gran lanzamiento, además de la prueba automática, probamos un poco todo manualmente y también recurrimos activamente a las pruebas de investigación. En la semana anterior al lanzamiento, damos soporte a la versión final, se les enseña a usar los cambios. Cuando prueban todo ellos mismos, saben todo sobre los cambios.
Ese es todo el llamado proceso. Por supuesto, hay algunas partes cuando la interfaz de usuario se prueba manualmente, aunque básicamente todas son pruebas automáticas.
Realmente me gusta (y creo que las compañías también) que utilizamos activamente nuestro propio producto. Cada uno de nuestros equipos puede elegir cualquier tecnología, pero aún así prefiere la nuestra. También es genial sentir que estás haciendo algo que todo el mundo está usando: compañías como Apple, Netflix, Dropbox, IBM.
Pruebas e IA
Eugene: desde el momento de las pruebas, pasemos a su informe. Se llama "IA y pruebas", y esto se puede interpretar de diferentes maneras: tanto como "Probemos algo con la ayuda de AI" como como "Probemos la IA en sí". Primero punteemos la IA: ¿de qué se habla?
: — , AI. - AI, ? , — , , .
, — , AI. 80% , AI.
: «I» , . ?
: .
« , , , ». , AI . , , . .
, . , .
, — . , . , . , , .
AI . AI — , , , .
: AI AI?
: . Applitools Applitools, , AI-. , - AI AI.
, , « ». , , « ».
— , . — , , , .
: , Applitools, AI - — , ?
: . AI «» . , AI . , — :
- AI. Esto es muy importante
- AI, , AI
- AI , -
— «self-healing tests». , UI , «», .
AI? . : , .
: , , . - — , . . - , , — «». , UI , , .
: , , , AI.
, , AI. , ! .
, , , , . - , . , , . , .
: . , - , . « », . «, , , - ».
: . . , , . , . , , . , . , , . , ?
, . , . , : 100%, . . , .
: Heisenbug , . , , ?
: . , , . , . , , .
, . . , , , , . . . , - , . Por qué .
: . ?
: . , .
, . , - , . , — , , , , .
, . . , , , . , , .
, . , , . .
Heisenbug, 5 . Heisenbug , . , Heisenbug , , ( , ).