Startups: Refinado UX vs. Despliegues rápidos
Una startup, por definición, es una entidad con recursos limitados. Esos recursos podrían ser presupuesto, tiempo, talento o cualquier cosa relacionada, pero lo cierto es que, de hecho, existe algún tipo de limitación en los recursos; de lo contrario, no sería una puesta en marcha.
Es por esto que muchos estilos de administración han sido probados y probados en batalla para enfrentar el desafío que está lanzando, y funcionando, una de estas bestias de tiempo y energía. Y a lo largo de los años, parece haber dos escuelas de pensamiento independientes que han surgido en el mercado: el lanzamiento pobre y la gran acumulación.
El lanzamiento lean implica cosas como procesos de desarrollo ágiles, pruebas de usuario, validación de ideas, programación útil, desarrollo impulsado por el comportamiento y muchos otros. Luego, por otro lado, tiene la versión grande antes del lanzamiento: en este modelo, uno podría perder toneladas de tiempo, y los desarrolladores en un proyecto para asegurarse de que esté completo antes de que un solo cliente lo vea una vez.
Estas dos escuelas de pensamiento tienen sus ventajas y desventajas, como se podría imaginar, y cada una de ellas tiene gerentes que creen en ellas casi hasta el extremo. A través de este artículo, podemos descubrir cuáles no son testarudos y cuáles lo son. O podemos encontrar algo sorprendente. Vamos a sumergirnos
Tener una experiencia de usuario refinada
Seamos realistas, el diseño es enormemente importante. De hecho, el diseño es tan importante que ha superado casi por completo los procesos de algunas startups. Se centran todo su tiempo y energía en la experiencia del usuario, y al llegar a una función completa afirman que tienen poco tiempo para cualquier otra cosa, y tal vez con razón. Ahora, el otro lado no diría que es la manera correcta, pero dejaremos ese argumento para más adelante. Por ahora, estamos hablando del mundo de un pulido UX y conjunto de características antes del lanzamiento.
El lado positivo de un refinado UX
Aprovechando la marca completa
La marca es un tema masivo, y es por esta misma razón que parece que las personas sienten la necesidad de trabajar de esta manera. Sienten que, si van a lanzar, deberían lanzarse con todo lo que su marca representa, incorporarse al sitio desde el primer día. El clásico, "v1 debería ser característica completa" es algo que he escuchado de los gerentes con frecuencia. Y hay un buen razonamiento detrás de esto. No quieren que su sitio web refleje lo que no son, y ahí radica la farsa. Obtendremos más en esto en la sección de contras, pero esto puede llevar a un serio deslizamiento de características. Mi lema es que si te diriges a un espacio donde hay competidores marcados quizás más que cualquier otro espacio en línea (piensa: Dropbox o Apple), entonces quizás quieras considerarlo seriamente, porque en ese caso la marca será muy importante. Sin embargo, uno puede casarse con un lanzamiento magro con una tecnología fabulosa y una buena marca, todo en uno, que también discutiremos más adelante.
Recibir interés inmediato
Otro aspecto positivo en lo que se refiere a la implementación refinada y pulida es que puede atraer a más usuarios por adelantado debido al fantástico diseño y la atención de servicio completo que se brinda a todo el producto. Al menos, eso es lo que nos encanta asumir. De forma realista, sin embargo, también puede ser una barrera para la entrada. He visto usuarios que sienten que un producto es demasiado grande o tiene demasiadas características para que sientan que quieren algo cuando se trata de usarlo, y rebotan en menos de un minuto. Ocurre todo el tiempo, y es muy triste honestamente. Odio ver cómo las ideas de los empresarios o incluso de los gerentes son absorbidas por los tubos debido a la característica de fluencia demasiado frecuente. Aunque sucede, todavía no impide que los empresarios sientan que el interés se incrementará diez veces si completan su producto por completo antes del lanzamiento. Este es un grande.
Al ser una característica completa
Si llegas a esta etapa y estás viviendo en este campamento, entonces es más que probable que la función esté completa en este punto. Hemos hablado de esto un poco hasta ahora en las secciones anteriores, pero aquí es donde se vuelve interesante. Mucho, y me refiero a muchas start-ups que sienten que necesitan estar completas antes de que puedan cobrar, o que tengan un impacto en ese sentido. No digo que el argumento no tenga algún mérito, pero creo que ha sido exagerado a lo largo de los años. Desde mi punto de vista y de lo que he visto a lo largo de los años, simplemente puede preguntar si los usuarios pagarían por un producto antes de desarrollarlo por completo. Ahora, digamos que estabas emocionado por ser una característica completa, y realmente querías que todo estuviera dentro. Bueno, podrías lanzar una versión mínima de cada función. Algo que representa las características en cuestión, o tal vez incluso los videos de los que faltan. Tenga en cuenta que hay formas de completar una función sin estar allí.
La desventaja de un UX refinado
Feature creep
Este es un error común cuando se trata de UX pulido y cuenta con un enfoque completo para iniciar una nueva empresa. Y esto es lo que llamamos una situación llamada espiral de la muerte del fenómeno de la característica. Los gerentes o propietarios sentirán la necesidad de agregar más y más características al producto a medida que completa otras, hasta que literalmente no hay nada que hacer, sino agregar más funciones. En algunos casos, es un ciclo interminable, y especialmente en los casos en que no se establecen pautas o especificaciones rígidas .
Desarrollo de cascadas
El desarrollo de cascadas es una estafa por derecho propio, y no sin controversia. Un flujo de trabajo de cascada típico se ve así: idea, diseño, desarrollo, prueba, mantenimiento. Hay algunas personas que prosperan en ese entorno, pero al menos un número igual lo encuentran absolutamente perjudicial. O es un proceso bastante estándar que se siente muy normal para la mayoría de nosotros, y sin embargo, para ideas que pronto se harán evidentes, a menudo puede ser perjudicial para el envío de un producto.
La razón no está necesariamente en el modelo del sistema en sí, sino en el hecho de que usted tiene equipos separados que realizan el trabajo y que cada uno de ellos está siendo microgestionado por gerentes individuales. Por ejemplo, un flujo típico puede verse así: una idea está formada por el fundador / empresario; contrata a un equipo de diseño y desarrollo, y tal vez a gerentes o directores creativos para cada equipo; la idea se pasa al diseño, para crear maquetas, esas maquetas se convierten en documentos de Photoshop que van y vienen con el propietario y el director creativo hasta que son perfectos; luego, sin ningún consenso sobre lo que es posible, se pasa al desarrollo para ser creado; y luego de ir y venir con el líder del equipo de desarrollo, el propietario y posiblemente incluso el director creativo, encuentran un terreno de encuentro y terminan el producto.
Lo que no mencioné, sin embargo, es que cada uno de esos pasos involucró probablemente entre 50 y 100 correos electrónicos individualmente, y esa es una estimación conservadora (muy conservadora). Como puede ver, eso no es realmente eficiente, porque en cualquier momento el propietario y el fundador podrían agregar más trabajo que no estaba en el plan, o cambiar las cosas. Micromanaging a menudo no es la mejor opción cuando se trata de desarrollo de software, y sin embargo, el sistema de cascada parece prosperar en un estilo de gestión de este tipo.
Siempre tenlo en cuenta, y si no trabajas bien siendo microgestionado, avísale a tu jefe. Recuerde, siempre es mejor ser franco y honesto acerca de un posible futuro improductivo que ir por ese camino siendo realmente improductivo. Y también tenga en cuenta que hay más problemas típicos de microgestión que están en preparación para este sistema; desde mi experiencia personal no es ideal.
Entonces, ¿qué es ideal? Bueno, eso es subjetivo, pero puedo decir que, en mi experiencia, la capacidad de lanzar rápidamente e iterar durante los tiempos de ciclo me ha dado a mí y a mis equipos la posibilidad de enviar una mayor cantidad de productos de la que podríamos tener con Waterfall. Entonces, ¿qué es este misterioso sistema mágico de envío de productos?
Despliegues rápidos y el inicio ligero
La pobre puesta en marcha es algo que, en mi opinión, revolucionó nuestra comunidad. Y eso se debe principalmente a que se basa en algo llamado circuito de retroalimentación de aprender a construir y medir.
El arte del despliegue rápido (a menudo puede ser una página simple que pregunta si los usuarios pagarían por esto, o puede ser un producto básico) es algo que la gente ha perfeccionado a lo largo de los años, y a medida que me siento más afianzado en nuestra mundo de la tecnología, siento que es cada vez más importante.
Lo más importante aquí es la aceptación y validación del mercado. Una pregunta clave: ¿quién dice que el código que está escribiendo tiene sentido? Vivimos en un día y una época en que la gente realmente no puede desperdiciar ni un gramo de su precioso tiempo. Es un momento de hacerlo o romper sus actitudes, e ir a lo grande o irse a casa con mentalidades. Es un momento en que la realidad nos golpea en la cara todos los días cuando no podemos comprar alimentos o pagar el alquiler, y es por eso que es más importante asegurarse de que no se está gastando la codificación de algo que nadie usará.
No tiene que ser un genio en marketing, pero sí necesita comprender un estado mental experimental. El estado constante de beta es una metáfora brillante de esto. Nunca deberíamos envolvernos en nuestro orgullo tanto que ni siquiera podemos cambiar un artículo en un proyecto. Tenemos que recordar que la vida es experimental, y que cuanto antes se dé cuenta de esto, mejor: y no hay mejor manera que con el arranque lean.
El lado positivo de la pobre puesta en marcha
Comentarios del usuario
Usar un método como este es algo parecido a que le digan sobre un stock antes de que llegue a su punto máximo. Esta es una excelente forma de obtener información sobre su grupo demográfico objetivo principal y obtener la validación antes de perder el tiempo.
Así es como lo haces. Obtenga una página de destino y muestre lo que hace su producto o servicio de una manera muy bella y explicativa. Gaste algo de dinero en esta parte si lo desea, porque es lo más importante. Luego, ingrese un simple registro con su dirección de correo electrónico si le interesa. Hecho. Ahora, puede que no parezca que estás haciendo mucho, pero estás haciendo bastante en la realidad. Está validando un mercado de producto o mercado de servicios completo con una página. No está gastando meses y miles de dólares para construir algo innecesario que nadie usará, simplemente está creando una cosa para saber si vale la pena.
Ha habido personas que lanzan 5 páginas de servicio similares a las que acabo de decir, y las que reciben más comentarios son las que siguen. Es un acto brillante, y puede verse como una inversión de muchas maneras. Está obteniendo beneficios de su inversión y, si no, está saliendo del mercado antes de perder muchas ganancias potenciales. Creo que a Warren Buffet le encantaría esto.
Ciclos de iteración más rápidos
Una de las mejores cosas para hacer el desarrollo de productos de una manera ligera es que a menudo encontrará que sus ciclos de iteración son mucho más rápidos, y en algunas compañías envían códigos más de 20 veces al día. Hay una gran cantidad de filosofía detrás de esto, por ejemplo, cómo en Facebook cuando un nuevo ingeniero es llevado a bordo reciben 5 correcciones de errores en su correo electrónico de bienvenida en su primer día. Mucho del razonamiento detrás de hacer este tipo de cosas es que si configuras tu sistema de manera que se rompa cada vez que un nuevo empleado se une a él, entonces no es él sino tu sistema el que está roto.
Desarrollo ágil
El desarrollo ágil es, en esencia, pasar de una cosa pequeña a la siguiente lo más rápido posible. Luego pasas de cada sprint al sprint siguiente, que a menudo está definido por una historia de usuario y que es simplemente un usuario en tu sitio que quiere un poco de funcionalidad. Es muy similar a las pruebas en Rails u otro marco, ya que solo está haciendo todo lo que necesita y nada más. Uno puede ahorrar una gran cantidad de tiempo haciendo el desarrollo de esta manera.
La desventaja de la pobre puesta en marcha
Una pequeña desventaja que puede ocurrir cuando eres un usuario del desarrollo ágil y del sistema de arranque lean, es que el sitio puede cambiar a lo largo del tiempo. Ahora, lo ideal sería que esto ocurriera debido a la solicitud de un usuario, pero aún así puede ser discordante para algunos usuarios.
Así que hacerlo con clase y elegancia es importante. Especialmente si es un producto que les importa. No desarraigue la base de usuarios central de su producto como lo hizo Digg v4, sino que proporcione detalles sobre lo que está haciendo y por qué, y si todo lo demás falla, desista.
Siempre asegúrese de usar algo como git o subversion para guardar versiones de su producto. De hecho, lo hago como ramas, por lo que siempre podemos retroceder si es necesario.
En conclusión
Si su inicio es tan avanzado técnicamente que no importa, vaya con el despliegue rápido. La gente se preocupará por el cambio tecnológico que están viendo. Sin embargo, si estás compitiendo en un espacio con competencia masiva , quizás una combinación de ambos sea lo mejor. En resumen, siempre haz lo mejor que puedas con un UX refinado, pero hazlo en ráfagas cortas y ágiles.