La cantidad de pruebas que necesita un producto depende de cuánto importa si el producto está roto, qué tan fácil es descubrir rápidamente si está roto una vez que se envía y qué tan fácil puede solucionarlo una vez que descubra que está roto.
Cuando estaba en la Búsqueda de Google, había relativamente pocas pruebas de nuevas funciones antes de lanzarlas. Esto tenía sentido porque el peor de los casos de “resultados de búsqueda que se veían raros” no era tan malo, las métricas revelaron malos lanzamientos muy rápido y el mal código podría revertirse muy rápidamente.
Cuando estaba en Intel, hubo una gran cantidad de pruebas de un producto antes del envío. Eso tenía sentido porque el peor de los casos de un procesador que no funciona podría ser muy malo, y es muy difícil reparar un procesador defectuoso una vez que se ha vendido.
- ¿Cuáles son algunas métricas clave que los PM consideran al desarrollar nuevas funciones en Yammer?
- Gestión de productos: para una nueva característica de un producto, ¿cómo se define el éxito y cómo se mide?
- ¿Cuáles son las herramientas y habilidades esenciales para el desarrollo de productos?
- ¿Crea un nuevo documento de requisitos de producto (PRD) para cada versión?
- ¿Cuál es la mejor manera de trazar un mapa de ruta del producto y crear listas detalladas de características para el desarrollo de software?
En general, compare el “costo de la prueba” con el “costo por hora de que el producto está en mal estado” * “número de horas que el producto probablemente seguirá en mal estado”.
