"Hacer lo más mínimo posible y lo sacar lo más rápido posible"

Si hace sugerencias que se pueden excluir de la primera iteración, conviértalas en un problema separado que vincule. No escribas un plan grande; solo escriba el primer paso. Confía en que sabrás mejor cómo proceder después de que se libere algo.

Lo está haciendo bien si está un poco avergonzado por el conjunto de características mínimas enviadas en la primera iteración.

Este valor es el que la gente más subestima cuando se une a Willay. El impacto tanto en su proceso de trabajo como en cuánto logra es mayor de lo previsto.

Al principio, duele tomar decisiones rápidas y ver que las cosas cambian con menos consulta. Pero con frecuencia, la versión más simple resulta ser la mejor.

Las personas que se unen a Willay dicen que ya practican la iteración. Pero este es el valor que es más difícil de entender y adoptar. La gente está entrenada para que si no entregas algo perfecto o pulido, habrá un problema.

Si haces solo una pieza de algo, tienes que volver a ella. Hacer todo parece más eficiente, aunque no lo sea. Si la imagen completa no es clara, es posible que su trabajo no se perciba como desea que se perciba. Parece mejor hacer un producto integral.

Ven que otros miembros del equipo de Willay son realmente efectivos con la iteración, pero no saben cómo hacer la transición, y es difícil sacudirse el temor de que la iteración constante pueda conducir al envío de trabajo de menor calidad o a un producto peor.

Es posible enviar un producto mínimamente viable sin dejar de cumplir con los estándares de calidad documentados.

La forma de resolver esto es escribir solo lo que puedes hacer con el tiempo que tienes para este proyecto en este momento. Eso podría ser 5 minutos o 2 horas. Piensa en lo que puedes completar en ese tiempo que mejoraría la situación actual. La iteración puede ser incómoda, incluso dolorosa. Si está haciendo la iteración correctamente, debería serlo. Revertir el trabajo a un estado anterior es positivo, no negativo.

Rápidamente estamos recibiendo comentarios y aprendiendo de ellos. Hacer un pequeño cambio evitó una reversión más grande y facilitó la reversión. Sin embargo, si tomamos medidas más pequeñas y enviamos características más pequeñas y simples, recibimos comentarios antes.

En lugar de perder tiempo trabajando en la función equivocada o ir en la dirección equivocada, podemos enviar el producto más pequeño, recibir comentarios rápidos y corregir el rumbo. La gente podría preguntar por qué algo no fue perfecto. En ese caso, mencione que fue una iteración, que pasó solo "x" cantidad de tiempo en ella, y que la próxima iteración contendrá "y" y estará lista en "z".

No Esperes

No esperes Cuando tenga algo de valor, como una posible publicación de blog o una pequeña solución, impleméntela de inmediato. En este momento, todo está fresco en tu cabeza y tienes la motivación. La inspiración es perecedera. No espere hasta tener una mejor versión. No espere hasta grabar un mejor video. No espere un evento (como Contribute). El inventario que no se libera es una responsabilidad, ya que debe administrarse, se vuelve obsoleto y se pierde la retroalimentación que habría recibido si lo hubiera implementado de inmediato.

Establecer Una Fecha De Vencimiento

Siempre tratamos de establecer una fecha de vencimiento. Si es necesario, cortamos el alcance. Si tenemos algo planeado para una fecha específica, hacemos esa fecha. Por ejemplo, enviamos más de 100 lanzamientos el día 22 del mes. Pero cada uno de ellos no contiene todas las características que planeamos. Si planeáramos un anuncio para una fecha determinada, podríamos anunciar menos o indicar lo que aún es incierto. Pero establecemos una fecha de vencimiento porque tener algo disponible genera confianza y nos brinda una mejor retroalimentación.

Limpieza Sobre Cierre De Sesión

Como se discutió en la entrevista de “X“ sobre la iteración, esperar la aprobación puede ralentizar las cosas. Podemos evitar esto con la automatización (p. ej., pruebas de rendimiento de la migración de la base de datos) o la limpieza después del hecho (Refactor a Pajamas if something was added that isn't coherent), pero tratamos de asegurarnos de que las personas no tengan que esperar cerrar sesión Comience impactando a la menor cantidad de usuarios posible

Si realiza una implementación gradual de su cambio, prefiera: pocos usuarios sobre muchos usuarios, usuarios internos (dogfooding) sobre los externos, entornos sobre los que obtiene comentarios más rápidos (SaaS) sobre los de comentarios bajos (autogestionados), etc.

Reducir El Tiempo De Ciclo

Las iteraciones cortas reducen nuestro tiempo de ciclo.(por amplificar)

Trabajar Como Parte De La Comunidad

Las iteraciones pequeñas facilitan el trabajo con la comunidad en general. Su trabajo se parece más a nuestro trabajo, y nuestro trabajo también es más rápido para recibir comentarios.

Cambio Mínimo Viable (MVC)

Recomendamos que los MVC sean lo más pequeños posible. Busque siempre hacer el cambio más rápido posible para mejorar el resultado del usuario. Si valida que el cambio agrega más valor del que hay ahora, entonces hágalo. No hay necesidad de esperar por algo más robusto. Hay más información en el manual del producto, pero esto se aplica a todo lo que hacemos en todas las funciones. Específicamente para los MVC de productos, existe la responsabilidad adicional de validar con los clientes que estamos agregando una funcionalidad útil sin errores obvios o problemas de usabilidad.

Under Construcción

A medida que tengamos más usuarios, pedirán estabilidad, especialmente en nuestra UX. Siempre debemos optimizar a largo plazo. Esto significa que los usuarios tendrán inconvenientes a corto plazo, pero los usuarios actuales y futuros disfrutarán de un mejor producto al final.

Educar a los usuarios sobre el plan a largo plazo ayuda a crear una comprensión compartida de cómo un pequeño cambio se convertirá gradualmente en algo más. Por ejemplo, podríamos compartir cómo un menú desplegable se convertirá en una solución mucho más matizada en el futuro.

Podemos tomar los siguientes pasos para articular nuestro plan: Abra un problema de comentarios que proporcione contexto sobre el MVC inicial Asegúrese de que la página de instrucciones articule un plan a largo plazo (ejemplo) Anuncie el MVC en una publicación de lanzamiento, enlace al problema de comentarios y enlace a la página de instrucciones (Me falta poner ejemplos).

Gracias a Alejandro Cantillo por el formato y Ricardo Mena por leer esto y pulirlo para que sea más digerible la información, a Alejandro Terán, Adrián Enríquez y Luiggy Macias