¡Felices fiestas amigos! En preparación para el comienzo del nuevo año laboral, estamos completando una serie de materiales de la conferencia FrontTalks 2018. Esta es una conferencia de Andrei Salomatin
filipovskii_off , desarrollador de Polychops. Andrei ofrece un enfoque equilibrado para la creación de prototipos: pasar de los artesanos que llevan a cabo las órdenes a los investigadores, aprender a trabajar con incertidumbre y, posiblemente, mantener la razón incluso sin un plan claro.
La retroalimentación cuantitativa es la prueba AV, los resultados binarios, cuando gana la Opción A o la Opción B. Eso es todo lo que podemos obtener de los ciclos cuantitativos. Es como si estuviéramos en una habitación oscura y no hay nada visible, pero tenemos un puntero láser. De vez en cuando, lo iluminamos en las esquinas, resaltamos algunos puntos y entendemos lo que hay en ellos.
¿Qué nos gustaría en su lugar? Un usuario que describirá esta habitación oscura, que la conoce mucho mejor que nosotros.
- Hola a todos! Me gustaría hablar sobre la creación de prototipos: por qué hacer prototipos, qué obtenemos de esto y cómo hacerlos, usando ejemplos.
Comenzaré con una pequeña historia. En 2012, me uní a esta startup, un ciervo maravilloso. Teníamos algo así como una plataforma publicitaria, vine como desarrollador de Java. Está claro que grandes volúmenes de tráfico, tareas interesantes, el equipo está loco, todo es maravilloso. Hemos estado trabajando durante aproximadamente ocho meses, con la cabeza en el teclado, creamos funciones muy interesantes, cambiamos rápidamente todo. Pero en 2013, el venado se pone loco.
Que paso Pensé en esto durante mucho tiempo, posteriormente trabajé como desarrollador frontend y backend para diferentes compañías, luego fui líder de equipo y luego gerente de producto. Trabajó tanto en startups como en empresas de outsourcing, en grandes empresas. Principalmente enfocado en startups.
También hice algunos de estos proyectos. Tuve la suerte de trabajar en MoscowJS, Frontend Union Conf y RadioJS. Tal vez nos cruzamos contigo en alguna parte. Ahora estoy haciendo Code Podcast, un podcast en inglés sobre conceptos comunes en programación, y Polychops, un proyecto para músicos que funciona en un navegador y te ayuda a practicar el instrumento, a obtener más tiempo y práctica.
¿Qué le pasó a HeyMoose? La compañía tenía personas muy inteligentes que ahora trabajan como desarrolladores senior en Microsoft o se han convertido en STO. Hicimos lo que mejor hicimos: resolvimos problemas técnicos complejos de forma rápida e interesante. Pero algo salió mal.
Y algo va mal con muchas empresas, especialmente las nuevas empresas. La mayoría de las empresas emergentes se agotan por dos razones: o no entienden el producto, en algún lugar lo pierden o se quedan sin dinero. Muy a menudo se les acaba el dinero porque están buscando un producto y no lo encuentran lo suficiente.
Pero, ¿por qué no se cierra el desarrollo personalizado en las empresas de outsourcing? ¿O por qué las grandes empresas no cierran? Parecen ser más lentos. Como regla, los equipos allí están al menos menos motivados. Cual es la diferencia Los mecanismos de trabajo son los mismos: en el desarrollo personalizado, escribimos TK o pedimos TK a los clientes, nos lo pintan, nos lo dan, hacemos maquetas, código y lo escribimos, el mismo proceso. ¿Qué hay en una startup que en las grandes empresas puede haber prácticas avanzadas? De todos modos Entonces, ¿por qué se agotan las startups?
Imaginemos primero una situación hipotética: un gerente de producto se nos acerca y nos pregunta si podemos agregar un metrónomo que funcione en un navegador, emitir un sonido con intervalos periódicos y visualización sincronizada, de modo que diferentes luces brillen a un ritmo con el metrónomo uno a uno. Y para que todo esto sea exacto, independientemente de lo que esté sucediendo en la computadora, otros procesos, etc.
¿Quién está 100% seguro de que podemos hacer esto usando el navegador y la API del navegador? Ni una sola persona. ¿Quién está 80% seguro de que probablemente podamos hacer esto? 3-4 manos. ¿Quién está seguro de 50 a 50? La mayoría. ¿Quién está seguro de que no podemos hacer esto en absoluto? Honestamente
El siguiente ejemplo. Supongamos que estamos trabajando en otra compañía en un banco móvil. Pensamos más sobre el producto y creemos que es necesario aumentar el número de usuarios que utilizan nuestro banco móvil. Se nos ocurrió una función: ahora el usuario puede compartir una compra o reponer una cuenta en las redes sociales. El dinero vino a él, es así en Facebook, mira, el dinero ha venido a mí. ¿Crees que esto ayudará a atraer a más usuarios? ¿Quién está 100% seguro de esto? Ni uno solo. ¿Quién está 100% seguro de que esto no nos ayudará de ninguna manera? Dos o tres manos El resto está en algún punto intermedio.
Y el último ejemplo. Hacemos un servicio en la nube, abrimos nuestra empresa. El servicio en la nube recopilará registros de proyectos, de la interfaz y del backend en pequeñas y medianas empresas, los agregará, el aprendizaje automático, la inteligencia artificial y todo eso. Lo venderemos ¿Quién está seguro de que esto es 100% de éxito o 100% de pérdida? Un par de personas
Solo hay una respuesta correcta a todas estas tres preguntas: "probablemente". Estamos 50–80% seguros de las respuestas a algunas de las preguntas. Mucho depende del contexto, de la implementación. El mismo metrónomo con visualización: trabajé en él, no puedes hacerlo funcionar en todos los contextos: por ejemplo, con auriculares Bluetooth. Pero se puede hacer para dos o tres casos generalizados. En mi opinión, esto es "probablemente", y hay una razón por la cual las startups se están cerrando, por lo que HeyMoose se puso loco. Tal vez haremos algo bueno, o tal vez solo estamos perdiendo el tiempo. Y no tenemos forma de entender qué tan seguros estamos de lo que estamos haciendo.
Un poco de teoría ¿Cuál es la diferencia entre desarrollo personalizado y startups? La diferencia está en contexto. Estamos en este contexto de incertidumbre; tenemos una probabilidad de éxito y una probabilidad de fracaso. Es como si tratamos de usar los mismos métodos y prácticas cuando corremos en el suelo y cuando corremos en el espacio sin gravedad. Parece que estamos corriendo, pero no pasa nada. ¿Qué estamos haciendo mal?
Esta incertidumbre proviene de tres áreas principales. Proviene del mercado, porque no sabemos claramente qué otras compañías están involucradas en la agregación de registros. ¿Quizás este mercado ya ha sido capturado por alguien? ¿Qué demografía en el mercado, cuáles son los precios? La incertidumbre puede provenir de un producto. No sabemos qué problema tiene nuestro cliente y cómo resolverlo. Este es un ejemplo de un banco móvil. Parece que entendemos, pero no estamos seguros de si los usuarios tienen este problema y cómo resolverlo.
Y hay problemas de implementación. Un ejemplo con un metrónomo. No sabemos al 100% si esto es teóricamente posible o no.
U otro ejemplo. No tenemos ningún problema con el mercado o el producto si inventamos una cura para el cáncer, que es solo una píldora, aceptada y saludable. Pero hay una gran cantidad de incertidumbres sobre cómo implementar esta píldora. Estamos en la niebla de la guerra, pero al mismo tiempo nos comportamos como si la niebla no existiera, porque tenemos los mismos principios que funcionan en el desarrollo personalizado. Simplemente los movemos a nuestro contexto de incertidumbre.
Pretendemos que esta niebla no existe, no hay incertidumbre. Y estamos tratando de predecir el futuro. Cuando comencé a trabajar como gerente de producto, me sorprendió, después del proceso de desarrollo, cuánta adivinación debería producir el gerente de producto. Cuando se reporta al director oa otra persona, tiene que parecer confiado, tiene que decir que haremos esto o aquello, tomar el mercado para septiembre, todo va a doler. Todo esto, bien hecho, lo pensé todo. Aunque, de hecho, entiendo que nada de esto existe, solo estoy adivinando las cartas y tratando de parecer seguro con ellas. No tenemos una cultura de trabajo con incertidumbre, con probabilidad. Además, para parecer expertos, debemos luchar constantemente por una reputación, tener confianza, hablar sobre lo que debemos hacer, en lugar de lo que debemos verificar o de lo que no estamos seguros.
Nosotros, especialmente los desarrolladores, todavía tenemos una tendencia a pensar en lo que sabemos, entendemos y podemos controlar. Como desarrolladores, realmente nos gusta planificar arquitecturas, pensar en el futuro, no repetirnos, programar patrones y todo eso.
Los diseñadores también sufren de esto. Les gusta pensar en el futuro, hacer diseños perfectos, etc. Somos expertos, aunque en realidad es posible que necesitemos convertirnos en otra persona.
¿Cómo lidiamos con la incertidumbre? ¿Qué métodos de lucha tenemos? El primer método es el más importante: poner todas las cartas sobre la mesa, admitir que no estamos seguros de ningún problema. Podemos estar 50% seguros, pero para probar la hipótesis, necesitamos dos días. Entonces, ¿por qué no vamos y probamos la hipótesis? Podemos estar 90% seguros de que el producto despegará, pero necesitamos ocho meses para implementar este producto y probar la hipótesis. ¿Iremos y lo comprobaremos? ¿O tal vez pensaremos en cómo reducir la incertidumbre al 90 o 100%?
Esta es la primera forma. Es necesario colgar un distintivo sobre esta incertidumbre, decir qué tan grande o pequeño es, cuánto trabajo se requiere para resolverlo, etc.
La segunda forma en que la humanidad ha estado trabajando durante los últimos 500 años es el método científico. No es perfecto, tiene sus propios errores, pero este es el mejor mecanismo que tenemos en este momento. El método científico dice: para resolver la incertidumbre, primero adivinamos, formulamos una hipótesis basada en nuestras conclusiones, luego pensamos en un experimento que confirmará o refuta esta hipótesis, luego realizamos un experimento, observamos los números y entendemos si nuestra hipótesis es cierta.
En desarrollo, especialmente en el front-end, tenemos una oportunidad única de ejecutar estos experimentos a una velocidad muy alta. Este método se llama creación de prototipos. El prototipo es una forma de lidiar con la incertidumbre. Esto no es una invención de producto, no la creación de algo ideal que los usuarios usarán. Esta es una oportunidad para aprender más sobre el mundo que nos rodea. Aprendemos esto creando ilusiones. El prototipo es una ilusión, no un producto. Es como si estuviéramos construyendo el escenario en el escenario del teatro o en el escenario para hacer películas. Esto es solo una ilusión. El objetivo es reducir la incertidumbre.
La creación de prototipos funciona en dos contextos: en el contexto de la implementación, cuando no sabemos teóricamente desde el punto de vista de la API, es posible o no, y en el contexto del producto cuando no sabemos qué problema tiene el usuario y cómo resolverlo. La creación de prototipos no funciona realmente en la investigación de mercado; Excel existe para esto.
El punto es que cuando trabajamos en un prototipo, necesitamos abandonar la forma de pensar como expertos. Necesitamos olvidar estos patrones de programación, debemos olvidar cómo hacemos productos ideales, porque no lo hacemos. Estamos tratando de aumentar la investigación, nos estamos convirtiendo en científicos.
Por lo tanto, en lugar de pensar en arquitecturas, necesitamos encontrar una forma de iterar muy rápidamente. En lugar de aproximarse y pensar en el futuro, debe pensar en cómo hacerlo ahora, en poco tiempo.
En lugar de pensar en tu reputación, en lo que sucederá si digo que estoy seguro o no ... En cambio, tengo que renunciar a mi reputación y convertirme en un recién llegado. Dunce ¿Cómo hacemos esto? ¿Qué cosas específicas podemos aplicar para convertirnos en novatos?
El primer y más importante punto es la retroalimentación. Incluso antes de planificar nuestro prototipo, dibujar un diseño u otra cosa, pensamos en a quién le mostraremos estos modelos o prototipos, cómo probaremos el producto y qué estamos tratando de obtener de este experimento. Cuanto más corto sea este ciclo de retroalimentación, mejor para nosotros.
Un ejemplo de la vida personal. Productive Mobile es la compañía para la que trabajé recientemente, una startup, se les ocurrió una plataforma que le permite crear una aplicación móvil desde un sitio web de manera tan fácil de arrastrar y soltar. Lo vendimos a grandes corporaciones porque tienen productos como SharePoint o SAP que no pueden usarse en un teléfono móvil, pellizcar zoom, eso es todo. Les ofrecimos una opción: puede hacer una aplicación móvil basada en un sitio real, por ejemplo, en una semana. El problema es que teníamos un equipo de desarrollo muy fuerte y un ciclo de ventas muy largo. Cuando vende un producto de una compañía del tamaño de Daimler o BMW, el ciclo de ventas es de al menos 8 meses. Durante este período, un equipo de desarrolladores talentosos puede presentar muchas solicitudes.
¿Qué hemos hecho y qué nos ayudó? Creamos un mini equipo de usuarios dentro de nuestra empresa que utilizaron el producto. Y la cantidad de funciones que comenzamos a hacer y lanzar disminuyó. Pero al mismo tiempo, la calidad de las funciones aumentó n veces. Y cuando nos acercamos a nuestro usuario y le dijimos que teníamos tal y tal plataforma, probémoslo, por alguna razón, las situaciones de emergencia se detuvieron cuando estábamos así: no pensamos en eso, esto es algo nuevo. Comenzamos a crear características que realmente comenzaron a traer resultados. Esto se debe al hecho de que simplemente redujimos el ciclo de retroalimentación.
Un ejemplo con un metrónomo, el proyecto Polychops en el que estoy trabajando ahora. En primer lugar, creamos un video en poco tiempo, que publicamos en algún lugar de Internet. En él, le preguntamos qué le parece este concepto, qué piensa al respecto. Según las revisiones, no solo apreciamos lo interesante que es esto. Todavía tenemos pistas con las que podemos hablar, a quienes podemos invitar a llamadas, entrevistas, probar un prototipo, etc.
Tratamos de recibir comentarios muy temprano. Y no solo cualquier comentario, sino cualitativo, no cuantitativo.
Cual es la diferencia La retroalimentación cuantitativa es la prueba AV, los resultados binarios, cuando gana la Opción A o la Opción B. Eso es todo lo que podemos obtener de los ciclos cuantitativos. Es como si estuviéramos en una habitación oscura y no hay nada visible, pero tenemos un puntero láser. De vez en cuando, lo iluminamos en las esquinas, resaltamos algunos puntos y entendemos lo que hay en ellos.
¿Qué nos gustaría en su lugar? Un usuario que describirá esta habitación oscura, que la conoce mucho mejor que nosotros. Necesitamos entrevistas de alta calidad, llamadas, algo más para recibir información de los usuarios en forma expandida.
Un ejemplo de una empresa que depende en gran medida de los comentarios cuantitativos es Booking.com. En mi opinión, hay algo para trabajar en su sitio.
Uno de los prototipos del proyecto en el que estoy trabajando es una característica con la que una persona puede grabarse a sí misma y, al mismo tiempo, reproducir por sí misma cómo jugó bajo el metrónomo, bueno o malo. Inventamos esta característica porque solicitamos comentarios de calidad de las personas que probaron el prototipo. Una de las personas escribió que todo es genial, me gusta la parte del metrónomo, pero sería genial exportar esta pista con el metrónomo como pista de audio. Somos así, es ilógico, ¿por qué? Él dice: "Inserto esto en mi programa para trabajar con música, luego me escribo y luego puedo escuchar si me pongo al ritmo o no". Somos así, es brillante.
Pero en lugar de solo exportar, decidimos probar la hipótesis. Hablamos con la gente, les preguntamos si se escuchan a sí mismos cuando tocan con el metrónomo. Muchos dijeron que sí, a menudo tenemos un programa, un metrónomo, otro programa, una grabadora de voz en el teléfono o en otro lugar, simplemente grabamos y nos escuchamos. Somos así: somos programadores, podemos combinar esto en una sola aplicación. Como resultado, obtuvimos esta característica. Nunca lo habríamos adivinado si acabáramos de hacer una prueba AV.
La parte más importante del prototipo es la interfaz. En un sentido global. Si tenemos algún tipo de servicio con algún tipo de API, entonces nuestra interfaz es una API, con lo que el usuario interactúa. Si estamos trabajando en un metrónomo, nuestra interfaz es la parte visual y el sonido. Si solo estamos trabajando en una aplicación móvil, nuestra interfaz es una interfaz visual. En el prototipo, la interfaz es la única parte importante. Todo lo demás podemos fingir, reemplazar con felpa.
Otro ejemplo de Productive Mobile. En algún momento, decidimos reescribir la API interna en este editor de arrastrar y soltar de aplicaciones móviles. API le permite a JS revivir algunas partes complejas de su aplicación móvil. Como gerente de producto, podría escribir una especificación y dársela a los desarrolladores. Estoy seguro de que en un máximo de un mes todo estaría listo, probado y maravilloso. Pero decidimos probar un camino diferente. Acabamos de documentar la API que teníamos en nuestra cabeza, en papel, y le dimos este documento a las personas que estaban creando aplicaciones móviles. Preguntaron: si tuviera una API de este tipo, ¿cómo construiría sus aplicaciones en teoría?
Tomaron otro papel, lo revisaron todo. Sin implementación La API no funcionó en esta etapa. Entonces hicimos 5-10 iteraciones antes de darnos cuenta de qué forma debería ser la API. Ahorramos una gran cantidad de tiempo para la implementación. Después de entender el formulario, documentamos la especificación y la implementamos. Todo se ha vuelto maravilloso.
Otro ejemplo del metrónomo. La primera idea para Polychops es un metrónomo para trabajar con polirritmias. Hicimos el primer prototipo en unos 20 minutos, escribió en Flash. Así es como se veía. Hubo incluso un sonido. Simplemente fuimos y se lo mostramos a otros músicos, preguntamos: ¿qué les parece? Esto es lo único importante.
Luego hicimos un metrónomo real en el navegador, funcionó, animación, bla, bla, todo es hermoso.
Video del metrónomo de Polychops Pero tardó aproximadamente un mes y medio, y el prototipo anterior tardó 20 minutos.
Centrarse en la interfaz.
Para ahorrar tiempo, use un sistema de diseño. Un ejemplo rápido de Polychops.
A la izquierda está el prototipo inicial, donde solo tenemos todos los botones, pensamos en toda la interacción nosotros mismos. Después de un tiempo, decidimos que necesitábamos un menú, navegación, menús desplegables, algo más. Podríamos sentarnos y pensar con los diseñadores cada menú desplegable, cada botón, pero esto es una gran cantidad de tiempo, que en principio no necesitamos gastar. Por lo tanto, tomamos el sistema de diseño terminado, tomamos el diseño del material, tienen todo perfectamente documentado. Atornillado, todo está bien.
Robar No robar a los competidores. No tiene sentido robar a los competidores. Si algo funciona para los competidores, no necesita verificarlo, solo necesita copiarlo. Roba productos que son paralelos al tuyo, que no son exactamente tu producto, sino algo similar.
Otro ejemplo de Polychops. La interfaz de grabación está prácticamente eliminada de los programas de sonido existentes, como Logic. Naturalmente, lo simplificamos enormemente, pero las personas ya entienden cómo usar Logic, lo que significa que pueden entender cómo usar Polychops.
. , . .
: , . , , .
, , . , , . , , , , , . .
— . , , . , .
, , — . . , React . React, React. , , , Redux Apollo, . . .
— . , , — . , - , . , , , , , . -, . . -, , — , . , , , , , .
, , . . , . — , , .
, . , . . , . . . — , . , .
? « ?» — , . ?
. , . . 10% , , 10%, , — .
. , 90% , . , , 10%. — , . .
, . Productive Mobile , . , , - , .
. React, — React Native. , , — React, React Native. - : «, React Native, , ». .
? . , , 10 React Native , React Native-. , - , , . , , , «write once — use anywhere». Android iOS . . , , , . — , - , - . — .
, , … ?
Polychops - , . , , , , , . - , , . . .
Espero que lo intentes tú mismo. Quizás no trabajas en una startup, pero tu empresa tiene proyectos en los que existe incertidumbre. Es importante para mí que lo piense, hable con su equipo, con sus gerentes, piense en cómo trabajar con incertidumbre, cómo construir sus procesos, para que el proceso de toma de decisiones mejore, para que deje de perder el tiempo en cosas que no son necesarias.Si tienes éxito y haces un gran producto, espero que en algún momento sea uno de tus usuarios más felices. Gracias